【2024年11月28日開催】Microsoftのクラウド認証基盤サービス「Entra ID」を触ってみよう

2024年10月15日

全体説明

本勉強会について

  • Microsoftのクラウド認証基盤サービス「Entra ID」の勉強会です。
  • 調査会社のガートナー社によると、「Entra ID」はクラウド認証基盤の分野においてリーダーに位置付けられており、非常に需要が高い製品です。
  • 本勉強会のハンズオンは初級者向けの内容となっています。今までEntra IDを操作したことがない人が対象となります。
  • 後半のデモは、少しレベルが上がります。

タイムテーブル

概要説明： 19:00-19:10（10分）

ハンズオン：19:10-20:10（60分）

デモ（一部ハンズオン）：20:10-20:55（45分）

クロージング、アンケート：20:55-21:00 （5分）

事務局からの連絡事項等

  • 質問事項はチャットに投稿いただければ順次回答させていただきます。
  • 各セクションの間で質問時間を設けますので、そちらでも口頭で質問いただけます。
  • 本ハンズオン環境は勉強会終了後に利用できなくなります。

概要説明

Entra ID とは

クラウド上で「認証」と「認可」の機能を提供するサービス（一般的には、IDaaSと呼ばれています）

認証：通信相手が誰であるか確認すること

認可：特定の条件に対して、アクセス権限をあたえること

使い始める方法

  • クラウドサービス認証基盤ですので、サーバ構築は不要です。
  • Microsoft 365またはAzureの利用を開始すると、Entra テナントが用意されます。

できること

  • ユーザの管理
  • 多要素認証
  • シングルサインオン
  • オンプレActive Directoryとの連携
  • きめ細やかな認可設定（条件付きアクセス） 　などなど

ライセンス

  • 無料版と有料版があります。（有料版も複数分かれている。１ユーザ899円/月～）
  • 上述のできることのうち「条件付きアクセス」以外は無料版で利用できる機能です。

オンプレミスActive Dicrectory(AD)との違い（ひと昔前まで、Entra IDは、Azure Active Directory という名称でした。）

■社内向けか？社外（クラウドサービス）向けか？

Active Directory は、社内システムに対してSSO機能を提供する

Entra IDは、クラウドサービスに対してSSO機能を提供する

ハンズオン

全体

前提

  • 参加者は全員同一のEntra ID テナント（@M365x88711330.onmicrosoft.com）で作業していただきます
  • 他の人が作成したリソース（ユーザ、グループ）を削除しないように注意してください
  • 会社の端末では、会社独自のセキュリティ設定などの理由により、Azure Portalへログインできない場合がありますので、個人所有端末の利用を推奨します。
  • 本手順は、ブラウザの環境として、EdgeのInPrivate ウィンドウ、または、Chromeのシークレット ウィンドウの使用を前提としています。

ハンズオン開始前の準備

  • 事務局から本日利用いただくユーザアカウントが記載されたスプレッドシートをご連絡します。
  • スプレッドシートの中で、ご自身が使いたいAzureユーザアカウントの右側のセルにご自身の「connpassのユーザ名」を記載してください。
  • スマホに、Microsoft Authenticatorがインストールされていない方はインストールをお願いします（インストールサイト：Microsoft のスマートフォン認証アプリ | Microsoft Security ）

ハンズオンで利用するユーザアカウント

本ハンズオンでは２つのAzureユーザアカウントを利用します。

①west-sec-user×××@M365x88711330.onmicrosoft.com（本ハンズオンでは「管理者ユーザ」と呼びます）

  • 事務局にて事前に作成済みのユーザアカウントです
  • 管理者ロールが付与されています。
  • 最初はこちらのアカウントでAzure Portalへログインします
  • 初期パスワードは全員共通です（別途チャットでご連絡します）

②west-sec-user×××-2@M365x88711330.onmicrosoft.com（本ハンズオンでは「一般ユーザ」と呼びます）

  • ハンズオン参加者にて作成いただくユーザアカウントです
  • 管理者ロールは付与されていません（一般ユーザ相当のユーザアカウントです）

ハンズオンのコツ

ハンズオンでは２つのユーザアカウントを交互に利用します。

一つ目のユーザアカウントはEdge(InPrivateウィンドウ)を利用し、もう一つのユーザアカウントはChrome（シークレットウィンドウ）を使うといったようにブラウザを使い分けると、都度ログアウト/ログインが不要となり、ハンズオンがスムーズとなります。

ハンズオン内容

Azure Portalへログイン （アカウント：管理者ユーザ）

以下のURLへアクセスします。

https://azure.microsoft.com/ja-jp/get-started/azure-portal

「サインイン」を選択します。

認証が求められるので、管理者ユーザのアカウントを入力し、サインインします

次に初期パスワードを入力し、「サインイン」を選択します。

初期パスワードと変更後パスワード（好きな値でOK）を入力して、初期パスワードを変更します。

変更後のパスワードは忘れないようにメモをしておいてください。

多要素認証の設定が求められれます。「次へ」を選択します。

本テナントでは、多要素認証として「Microsoft Authenticator」のみ利用が許可されています。

「次へ」を選択します。

「次へ」を選択します。

自身のスマホにインストールされている「Microsoft Authenticator」で、以下のQRをスキャンします。

スマホ（Microsoft Authenticator）での操作

※利用しているスマホ種別やMicrosoft Authenticatorの利用実績（初回か、2回目以上か）などによって画面が異なる場合あります。

※操作途中で、PINコードの入力が求められることあります。ご自身のスマホに設定されているPINコードを入力してください。

自身のスマホで「Microsoft Authenticator」アプリを起動します。

画面上部にある「＋」を選択します。

「職場または学校アカウント」を選択します。

「QRコードをスキャンします」を選択します。

QRコードスキャンが起動しますので、PC画面に表示されているQRコードをスキャンします。
（この操作により、Azureユーザアカウント（管理者アカウント）と、お手元のスマホのMicrosoft Authenticatorが１対１で紐づきます）

QRコードスキャン後は、PC側の操作に移ります。

PCでの操作

「次へ」を選択します。

2桁の数字が表示されます。

スマホのMicrosoft Authenticatorでは、数字の入力が求められますので、上記数字を入力し、「はい」を選択します。

★以下は、スマホ側の画面です。

PC側では以下の画面が表示されますので、「次へ」を選択します。

「完了」を選択します。

「はい」を選択します。

「キャンセル」を選択する

以下の画面が表示されれば、Azure Portalへのログイン成功です。

ユーザ作成 （アカウント：管理者ユーザ）

ユーザ作成のハンズオンになります。

画面上部の検索窓に「entra」と入力し、表示される候補の中から「Microsoft Entra ID」を選択します。

「管理」→「ユーザ」と選択します。

「＋新しいユーザ」→「新しいユーザの作成」を選択します。

以下の値を入力（既定値からの変更点のみ記載）し、一般ユーザを作成していきます。

■基本

「×××」の部分は、各自のAzureユーザアカウントの数字を入力してください

①ユーザプリンシパル名：west-sec-user×××-2

②表示名：west-sec-user×××-2

また、③コピーボタンを選択して、初期パスワードをコピーします（後程使うので、メモで控えておいてください）。

④「レビューと作成」を選択します。

「作成」を選択します。

ユーザが問題なく作成できているか確認していきます。

①検索窓に「west-sec-user×××-2」を入力します。

②ユーザ（west-sec-user×××-2）が作成されていることを確認します。

次に、作成したユーザ（west-sec-user×××-2）でAzure Portalにログインしていきます。

方法は以下２つありますが、①が推奨です。

① 別の種類のブラウザのInPrivate ウィンドウ/シークレット ウィンドウを利用する（推奨）
（例：west-sec-userの操作でEdgeのInPrivateウィンドウを使っていた方は、west-sec-user×××-2の操作では、Chromeのシークレットウィンドウを使う）

②現在使用しているブラウザでアカウントを切り替える

  • ②-1：画面右上のアカウントを選択します
  • ②-2：「別のアカウントでサインインする」を選択します
  • ②-3：別画面へ遷移するので、「＋別アカウントを使用する」を選択します。
  • ②-4：「west-sec-user×××-2@M365x88711330.onmicrosoft.com」でサインインし直します。

「west-sec-user×××@M365x88711330.onmicrosoft.com」「west-sec-user×××-2@M365x88711330.onmicrosoft.com」の両アカウントでAzure Portalにログインした後は、切り替え先のアカウント（②-5）を選択してアカウントを切り替えます（以下の例は「west-sec-user×××-2」から「west-sec-user×××」へ切り替える手順です）

演習（3～5分）

一般ユーザ「west-sec-user×××-2@M365x88711330.onmicrosoft.com」でAzure Portalにログインしてください。

ログインするまでに、「パスワードの変更」や「Microsoft Authenticatorとの紐づけ」が必要になります。

操作に迷った方は、こちらがヒントになります。

操作確認（アカウント：一般ユーザ）

一般ユーザ（権限なし）では、Azure Portalでの操作が制限されることを確認していきます。

画面上部の検索窓に「entra」と入力し、表示される候補の中から「Microsoft Entra ID」を選択します。

「管理」→「ユーザ」と選択します。

「＋新しいユーザ」を選択します。

表示される「新しいユーザの作成」がグレーアウトしていて、管理者アカウントでは操作できた「新しいユーザの作成」ができなことを確認します。

サインアウト、再サインイン失敗操作（アカウント：一般ユーザ）

次の項にて実施するサインインログ確認のハンズオンにおいて、サインイン失敗ログを使うため、意図的にサインイン失敗操作をして、サインインログに、サインイン失敗ログが記録されるようにします。

画面右上のアカウントを選択し、「サインアウト」を選択します。

一般ユーザ（west-sec-user×××-2）を選択して、サインアウトします。

以下の画面に遷移するため「別のアカウントを使用する」を選択します。

「west-sec-user×××-2@M365x88711330.onmicrosoft.com」を入力します。

パスワード入力画面において、適当なパスワードを入力し、サインインを意図的に失敗させます。

以下の画面が表示されていればOKです。

サインインログ確認（アカウント：管理者ユーザ）

画面上部の検索窓に「entra」と入力し、表示される候補の中から「Microsoft Entra ID」を選択します。

「管理」→「ユーザ」と選択します。

検索窓に「west-sec-user×××-2」を入力し検索します。

「west-sec-user×××-2」が検索結果に表示されるので、選択します。

「west-sec-user×××-2」の画面が表示されるので、「サインインログ」を選択します。

表示されるサインインログの中から「状態」列が、「失敗」になっているログを探し選択します。

「アクティビティの詳細：サインイン」の画面が表示されるので、「エラーの理由」を確認します。

管理者によるパスワードリセット（アカウント：管理者ユーザ）

一般ユーザから「パスワードがわからなくなって、Azure PortalやM365にサインインできない」といわれたときの対応方法です。

「west-sec-user×××-2」の概要ページにて、上部メニューから「パスワードのリセット」を選択します。

パスワードのリセット画面が表示されるので「パスワードのリセット」を選択します。

「一時パスワード」（初期パスワード）が、表示されるのでメモしておきます。

演習（2分）

一時パスワード（初期パスワード）を使って、「west-sec-user×××-2@M365x88711330.onmicrosoft.com」でAzure Portalにログインしてください。一時パスワードの変更が求めらるため、パスワードを変更してください。
（一般ユーザで利用していたブラウザは一度すべて閉じ、ブラウザを再起動した上で、ログイン試行をしてください）

管理者によるアカウントの無効化（アカウント：管理者ユーザ）

休職するユーザなどに対して、、一時的にアカウントを無効にすることが可能です。

画面上部の検索窓に「entra」と入力し、表示される候補の中から「Microsoft Entra ID」を選択します。

「管理」→「ユーザ」と選択します。

検索窓に「west-sec-user×××-2」を入力し検索します。

「west-sec-user×××-2」が検索結果に表示されるので、選択します。

「アカウントの状態」の「編集」を選択します。

「有効なアカウント」のチェックを外し、「保存」を選択します。

演習（2分）

「west-sec-user×××-2@M365x88711330.onmicrosoft.com」でAzure Portalにログイン試行してください。
（一般ユーザで利用していたブラウザは一度すべて閉じ、ブラウザを再起動した上で、ログイン試行をしてください）

以下の画面が表示されればOKです。

管理者によるアカウントの有効化（アカウント：管理者ユーザ）

以降のハンズオンのために、無効化したアカウントを有効化します。

「アカウントの状態」の「編集」を選択します。

「有効なアカウント」のチェックをつけて、「保存」を選択します。

ユーザ削除と復元（アカウント：管理者ユーザ）

ユーザ削除

画面上部の検索窓に「entra」と入力し、表示される候補の中から「Microsoft Entra ID」を選択します。

「管理」→「ユーザ」と選択します。

検索窓に「west-sec-user×××-2」を入力し検索します。

「west-sec-user×××-2」が検索結果に表示されるので、選択します。

画面上部メニューの「削除」を選択します。

「削除」を選択します。

演習（2分）

「west-sec-user×××-2@M365x88711330.onmicrosoft.com」でAzure Portalにログイン試行してください。
（一般ユーザで利用していたブラウザは一度すべて閉じ、ブラウザを再起動した上で、ログイン試行をしてください）

以下の画面が表示されればOKです。

ユーザ復元

画面上部の検索窓に「entra」と入力し、表示される候補の中から「Microsoft Entra ID」を選択します。

「管理」→「ユーザ」と選択します。

「削除済みのユーザー」を選択します。

検索窓に「west-sec-user×××-2」を入力し検索します。

「west-sec-user×××-2」が検索結果に表示されるので、選択します。

「ユーザの復元」を選択します。

「OK」を選択します。

「すべてのユーザー」を選択します。

検索窓に「west-sec-user×××-2」を入力し検索します。

「west-sec-user×××-2」が検索結果に表示されることを確認します。

演習（2分）

「west-sec-user×××-2@M365x88711330.onmicrosoft.com」でAzure Portalにログイン試行してください。
（一般ユーザで利用していたブラウザは一度すべて閉じ、ブラウザを再起動した上で、ログイン試行をしてください）

Azure PortalにログインできればOKです。

グループの違い

・Microsoft 365グループ
　社内外のユーザー間での共同作業に使用される。ShrepointやTeamsなどのコラボレーションサービスが含まれ、Teams作成時に自動的に作成されるグループはMicrosoft 365グループになります。

・セキュリティグループ
　今回主に利用するグループ。Sharepointサイトなどのリソースへのアクセスを許可するために使用される。また、グループへのライセンス割り当てやエンタープライズアプリケーションの割り当ても可能。

その他のグループ
・配布グループ
　ユーザーのグループにメール通知を送信するために使用される。
・メールが有効なセキュリティグループ
　Sharepointなどのリソースへのアクセスを許可し、それらのユーザーにメールで通知を送信するために使用される。

グループの作成（アカウント：管理者ユーザ）

グループ作成のハンズオンになります。

「管理」→「グループ」を選択する。



「新しいグループ」を選択する。



新しいグループを作成するために、必要な情報を入力します。
「XXX」の部分は、各自のAzureユーザアカウントの数字を入力してください

①グループの種類：セキュリティ

②グループ名：west-sec-groupXXX

③所有者・メンバー：選択なし
　ここで所有者やメンバーを追加することも可能だが、今回は別の方法でユーザー追加を実施する。

④「作成」を選択する



上記で「作成」を選択後、すべてのグループから、
先ほど自身で作成したグループ（グループ名：west-sec-groupXXX）が存在しているかを確認する。


先ほど作成したグループへのメンバ追加



自分が作成したグループへのメンバー追加を実施する。
先ほどの画面から自分の作成したグループ「west-sec-groupXXX」を選択する。
その後、下記のメンバー追加を進めていく。

①「管理」→「メンバー」を選択する。

②「＋メンバーの追加」を選択する。


管理者ユーザ「west-sec-userXXX」を追加する。
「XXX」の部分は、各自のAzureユーザアカウントの数字を入力してください

①検索窓に「west-sec-userXXX」を入れる

②候補に挙がってくる管理者ユーザを選択する

③「選択」を選択する。



メンバーが追加されていることを確認する。

①「更新」を選択する。

②先ほど追加した管理者ユーザ「west-sec-userXXX」が追加されていることを確認する。

グループ（事務局が作成したグループ）へのロール追加（デモのみ）

ここからは、事務局が作成したグループにて「グローバル閲覧者」というロールを割り当てることで、グループに参加しているユーザへのロール付与を実施していきます。

ロール追加はハンズオンはなく、デモのみとなります。

現状、一般ユーザーでAzure Portalに入ると、ロールが割り当たっていない状況なので、下記のようにログ確認などの権限がなくグレーアウトしていると思います。
今回、「グローバル閲覧者」の権限を付与しますので、ロール付与後にログ確認ができるようになるところをデモ画面にて確認いただければと思います。



以下、デモで説明する内容となります。


それでは、事務局が作成したグループ「west-sec-groupadmin」にロールを割り当てていく作業を実施していきます。すでに事務局が作成した一般ユーザを追加している状態です。
まず、ロールを割り当てたいグループ（事務局が作成したグループ「west-sec-groupadmin」）を開きます。


①「管理」→「割り当てられたロール」を選択する。

②「＋割り当ての追加」を選択する

①ロールの選択：グローバル閲覧者
　タブを開くと様々なロールが選択肢として表示されますので、「グローバル閲覧者」を選択する。（検索窓で「グローバル閲覧者」を検索するとすぐ出てきます。）

②「次へ」を選択する。


「設定」の画面で以下の情報を入力する。

①割り当ての種類：アクティブ

②理由の入力：イベント利用での権限付与

③「割り当て」を選択する。

ロールの割り当てが実施できているかを確認する。

①「最新情報に更新」を選択する。

②「グローバル閲覧者」のロールが表示されていれば、割り当て完了です。

ここからは実際に、ユーザにロールが割り当たっているかを確認していきます。

「管理」→「ユーザー」を選択する。


①検索窓に一般ユーザ「west-sec-userXXX-2」を投入する。

②一般ユーザ「west-sec-userXXX-2」を選択する。


①「割り当てられたロール」を選択する。

②「グローバル閲覧者」のロールが追加されていることを確認する。

実際に、ユーザ側でどのように画面が変わっているのかを見てみます。
ロールの割り当て前は、サインインログなどを確認できない状態だったと思います。
設定後は、下記のように画面が変わり、ログ確認ができるようになっています。

以上でグループでのハンズオンとデモはすべてとなります。

＜参考＞グループに割り当てられたロールを削除してみる。
事務局が作成したグループ「west-sec-groupadmin」のロールを削除すると一般ユーザに割り当てられたロールも自動的に削除されるのか。


事務局が作成したグループ「west-sec-groupadmin」を開く。
①「グローバル閲覧者」の操作から「削除」を選択する。

②注意ポップが出てくるので、「はい」を選択する。

ロールが削除されたことを確認する。


一般ユーザのロールを見に行く。
一般ユーザのロールも自動的に削除されていることを確認する。
※こちらも繁栄に時間がかかる可能性があるため、削除されていなければ、画面上部の「最新情報に更新」から更新を実施してください。

デモ（一部ハンズオンあり）

オンプレADとのID統合

デモ内容

・オンプレADにユーザを追加したら、Entra IDにユーザが追加されることを確認しよう

■オンプレAD　→ Entra ID 差分同期コマンド（ Entraコネクト上で実施）

Start-ADSyncSyncCycle -PolicyType Delta

■解説補足

・オンプレADの状態がそのままEntra IDに上書きされるわけではない（オンプレADに存在するユーザが、Entra ID側に追加されるイメージ）★Entra IDにのみ存在するユーザは、同期によって削除されない

・すでにEntra IDに存在するユーザを、オンプレADのユーザと紐づけて、オンプレAD側でユーザ管理を一元化することも可能

Powershellによるユーザ一括作成

Entra IDを操作するには、２つの方法があります

Power shellを利用することで、正確に大量のユーザ作成が可能となります。

デモ内容

Powershellで大量のユーザを簡単に作成できることを確認しよう

Powershellを使い、csvファイルに記載されているユーザに関する情報（ユーザ名、パスワードなど）を読み込み、ユーザ作成コマンドを実行します。

■利用するcsvファイル

■コマンド（説明用）

$csvPath = "C:\Users\〇〇\resource-data.csv"
#（コマンドの説明）
# ユーザ情報が記載されたcsvファイルの場所を変数（$csvPath）に格納します

Connect-MgGraph -Scopes "User.ReadWrite.All"
#（コマンドの説明）
#　Entraに接続

Import-Csv $csvPath | foreach {
    New-MgUser -DisplayName $_.DisplayName -PasswordProfile @{ForceChangePasswordNextSignIn = $true; Password = $_.Password} -AccountEnabled -MailNickName $_.MailNickName -UserPrincipalName $_.UserPrincipalName
}
#（コマンドの説明）
#　csvファイルを読み込み、各行における各列の値をパラメータとして、ユーザ作成コマンド（New-New-MgUser）を全行分繰り返し実行します。

■コマンド（投入用）

$csvPath = "C:\Users\tsuru\デスクトップ\デモ\ユーザ作成自動化\resource-data.csv"

Connect-MgGraph -Scopes "User.ReadWrite.All"

Import-Csv $csvPath | foreach {
    New-MgUser -DisplayName $_.DisplayName -PasswordProfile @{ForceChangePasswordNextSignIn = $true; Password = $_.Password} -AccountEnabled -MailNickName $_.MailNickName -UserPrincipalName $_.UserPrincipalName
}

シングルサインオン

デモ内容 (SalesforceへのSSO)

今回は、Salesforceの無料アカウントを準備し、SSOを実現してみたいと思います。

エンタープライズアプリケーションにSalesforceを追加し、追加したアプリケーションの中での設定を実施していく流れになります。途中、Salesforceの画面にも遷移しますが、SSOしたいアプリケーションによって確認方法等は変わることになりますので、ご注意ください。

まずは、エンタープライズアプリケーションに、Salesforceを追加します。

ホーム画面から「エンタープライズアプリケーション」を選択する。

①「管理」→「すべてのアプリケーション」を選択する。

②「＋新しいアプリケーション」を選択する。

①検索窓に「Salesforce」を入力する。

②「Salesforce」を選択する。

③「名前」に任意の名前を入力する。
　今回は。「デモSSO_Salesforce」

④「作成」を選択する。

上記の作業でエンタープライズアプリケーションへの登録は完了です。
ここからはアプリケーション内での設定に移ります。

まずは、登録したアプリケーションへSSOさせるユーザを割り当てていきます。

①「デモSSO_Salesforce」の設定画面に入ります。

②「管理」→「ユーザーとグループ」を選択する。

③「＋ユーザーまたはグループの追加」を選択する。


①「ユーザーとグループ」を選択する。

②割り当てるユーザーを選択する。

③「選択」を選択する。

アプリケーションを割り当てるユーザのロールを選択します。
①「ロールを選択してください」を選択する。

②「Standard User」を選択する。

③「選択」を選択する。

④「割り当て」を選択する。


ユーザが追加されたことを確認する。

これでアプリケーションへのユーザの割り当ては完了です。

ここからアプリケーションのシングルサインオン設定に移ります。

①「管理」→「シングルサインオン」を選択する。

②「SAML」を選択する。

基本的なSAML構成にある「編集」を選択する。


識別子・応答URL・サインオンURLにSSOを実施する先のURLを入力し、「保存」を選択する。
※SalesforceにおけるURLの確認方法は次に解説


SalesforceのURLを確認する手順は以下。

Salesforceへサインイン後、設定画面へ入ります。
①「会社の設定」→「私のドメイン」を選択する。

②現在の[私のドメイン]のURLを確認する。

こちらのURLを上記の識別子・応答URL・サインオンURLに投入する。

次にSAML証明書をダウンロードし、Salesforce側へインポートしていく作業になります。

SAML証明書にある「証明書（未加工）」とフェデレーションメタデータXMLをダウンロードしておきます。

Salesforce側でSSOの設定を入れていきます。
まずは、SAMLの有効化を実施します。
①「ID」→「シングルサインオン設定」を選択する。

②シングルサインオン設定の「編集」を選択する。

「SAMLを有効化」にチェックを入れ、「保存」を選択する。

次に、先ほどAzure Portalでダウンロードした証明書をインポートします。
SAMLシングルサインオン構成から「メタデータファイルから新規作成」を選択する。

「ファイルを選択」から先ほどAzure Portalでダウンロードした、「XMLファイル」を選択し、「作成」を選択する。


SAMLシングルサインオン構成に遷移するので、下記の情報を入力します。
①「名前」で任意の名前を入力する。

②「API参照名」で任意の名前を入力する。

③「IDプロバイダーの証明書」のファイル選択で、Azure Portalでダウンロードした「.cer」ファイルを選択する。

④「保存」を選択する。


最後にSalesforce側の認証設定で、シングルサインオンによる認証を選択肢に加えます。

①「会社の設定」→「私のドメイン」を選択する。

②認証設定の「編集」を選択する。

認証サービスで、先ほど設定した「デモSSO」を選択し、「保存」を選択する。

上記の作業でSSO設定は終了となります。
実際にSSOができるのか確認します。

新しくシークレットブラウザを開き、Microsoft 365へサインインを実施します。


サインインが完了したので、SalesforceへのサインインでSSOが実現できるかを確認します。
SAML設定の際に、識別子URLやサインオンURLで使用した独自のURLを利用し、サインイン画面に入ります。
以下の画面で、「次を使用してログイン　SSO」をクリックする。


認証情報が求められることなく、Salesforceにサインインすることができました。
これでSSOの確認も完了です。

条件付きアクセス

■通常の認可プロセス

■条件付きアクセスの認可プロセス

デモ内容 (特定のIPアドレスからの接続のみを許可する条件付きアクセスの設定方法)

今回は、特定のIPアドレスからのサインインは許可し、それ以外のIPアドレスからのサインインは拒否するという、ロケーションベースの条件付きアクセスの設定を行ってみます。
具体的には、講師（足立）環境でのIPアドレスのみアクセスを許可し、それ以外の場所（IPアドレス）からのアクセスを拒否するという設定を実施します。ですので、今回の条件付きアクセスの設定後、皆様はAzure Portalへのログインができなくなることを確認してみてください。

まずは、条件付きアクセスの設定画面に進みます。
ホーム画面から、「セキュリティ」を選択する。

「セキュリティ」のページへ遷移後、「条件付きアクセス」を選択する。

ネームドロケーションから、アクセスを許可するロケーション（IPアドレス）を作成します。
①「ネームドロケーション」を選択する。

②「＋IP範囲の場所」を選択する。

③「名前」に任意の名前を入力する。

④「新しいIPv4またはIPv6の範囲を入力してください」に、アクセスを許可するIPアドレスを入力する。

⑤「作成」を選択する。

先ほど作成したロケーションが作成されていることを確認する。

ここから実際に条件付きアクセスのポリシーを作成していきます。
①「ポリシー」を選択する。

②「＋新しいポリシーを作成する」を選択する。

ポリシーの中身の設定に移ります。
①「名前」に任意の名前を入力します。

②「割り当て」にて、対象とするユーザーと対象外のユーザーを選択する。
※今回は、対象をすべてのユーザにしますが、すべてのユーザにした場合に、誤った設定を入れてしまうと、
全ユーザがアクセス拒否され誰も入れない状態になる可能性があるので、adminアカウントなど必要最低限のアカウントを対象外にすることを推奨します。

「ターゲットリソース」を選択し、対象となるリソースと対象外のリソースを選択します。
すべてのアプリを対象にすることも可能であり、特定のリソースを選んで対象とすることも可能です。

「ネットワーク」にて、ポリシーの対象となるネット―ワーク範囲と対象外とするネットワーク範囲を設定します。
今回は、特定のIPアドレスのみアクセスを許可（ポリシー対象外）、それ以外のIPアドレスはアクセスを拒否（ポリシー対象）とします。
ですので、対象となるネットワークには、「任意のネットワークと場所」を選択する。
対象外のネットワークには、「選択したネットワークと場所」を選択し、先ほど作成したロケーション「デモ講師用ロケーション」を設定する。

①「アクセス制御」→「許可」を選択する。

②「アクセスのブロック」を選択し、「選択」を選択する。

③ポリシーの有効化を「オン」を選択し、「作成」を選択する。
※ポリシーの有効化にある「レポート専用」は、管理者が環境で条件付きアクセス ポリシーを有効にする前に、ログからその影響を評価することができます。ポリシーを有効化する前に想定通りの動きをしているかを確認する場合はこちらを選択してください。


条件付きアクセスが作成されているかを確認します。

こちらでロケーションベースの条件付きアクセス設定は完了です。
一般ユーザで一度Azure Portalをサインアウトし、サインインを実施してください。
皆様の環境ではAzure Portalへのサインインがブロックされることなどを確認いただければと思います。

WEST-SEC,コミュニティ活動

Posted by mitsuru