#はじめに
以前はオンプレミス AD と Office 365 間でシングル サインオンの環境を構成するためには、間に AD FS サーバーを立てて AD FS と Office 365 間で信頼関係を結んで構成する必要がありました。
現在、といっても数年前からですが、Azure AD Connect を利用してパススルー認証およびシームレス シングル サインオンを構成することで、AD FS サーバー無しで Office 365 にオンプレミス AD ユーザー上の資格情報を利用してシングル サインオン環境を構成することが可能になっています。
まず前置きとして、本記事は参考レベルとしてください。
詳細な手順については、下記 Microsoft の公開情報に設計からテストまで一連の手順が細かく載っています。
-参考情報
Azure Active Directory パススルー認証によるユーザー サインイン
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/hybrid/how-to-connect-pta#next-steps
※上記サイトの「AD FS からパススルー認証への移行」のリンクをクリックし、Word 形式のファイルをダウンロードしてください。
#AD FS からパススルー認証＋シームレス シングル サインオンに移行するメリットについて
物理的に AD FS サーバーが減るだけではなく、以下のようなメリットを享受することができます。
#####運用コスト削減
AD FS でフェデレーション ファームの構成をして可用性を高めるという運用をする必要がなくなる
AD FS 上で構成している証明書の管理をする必要がなくなる
#####リスクの軽減
AD FS のクレーム ルールによる複雑な運用から Azure AD による条件付きアクセスに切り替えることで制御方法が簡素化できる
(※条件付きアクセスは Azure AD Premium P1 ライセンスが必要)
証明書の有効期限が切れて、フェデレーション認証が失敗するというリスクがなくなる
#####柔軟性とセキュリティ
AD FS の機能から Azure AD による、スマート ロックアウトやパスワード保護ポリシーなどを活用することで、ブルート フォース、パスワード スプレー、およびその他の悪意のある攻撃からユーザー アカウントを保護できるようになる
#####堅牢な監査と使用状況の追跡
Azure AD の監査機能を使用すると、Azure AD のサインイン ログを基に、ユーザーがクライアントやデバイスからサインインしている場所やデバイスなど、ユーザー認証のサインイン アクティビティに関してより容易に、詳細なログを確認することができるようになる
#前提条件
この検証を行うにあたり、以下条件を満たしておく必要があります。
-
最新の Azure AD Connect を利用する
-
アウトバウンドのポート 80/443/8080 を許可する。Azure AD Connect サーバーおよび PTA エージェントをインストールする予定のサーバーから Azure AD に対して許可されている必要がある。ポート 443 が使用できない場合、認証エージェントはポート 8080 経由で 10 分ごとに状態を報告する動作になる。ポート 8080 は、ユーザーのサインインには使用されない。
-
サーバーと Azure の間にファイアウォールがある場合は、次の項目を構成します。
認証エージェントが次のポートを使用して Azure AD に送信リクエストを送れるようにします。
| ポート番号 | 用途 |
|---|---|
| 80 | SSL 証明書を検証する際に証明書失効リスト (CRL) をダウンロードする |
| 443 | サービスを使用したすべての送信方向の通信を処理する |
| 8080 | ポート 443 が使用できない場合、認証エージェントは、ポート 8080 経由で 10 分ごとにその状態を報告します。 この状態は Azure AD ポータルに表示されます。 ポート 8080 は、ユーザー サインインには 使用されません。 |
ファイアウォールが送信元ユーザーに応じて規則を適用している場合は、ネットワーク サービスとして実行されている Windows サービスを送信元とするトラフィックに対して以下のポートを開放します。
3-1. ファイアウォールまたはプロキシが DNS ホワイトリストを許可している場合は、 *.msappproxy.net と *.servicebus.windows.net への接続をホワイトリストに登録できます。 そうでない場合は、毎週更新される Azure データセンターの IP 範囲へのアクセスを許可します。
3-2. 認証エージェントは初回の登録のために login.windows.net と login.microsoftonline.com にアクセスする必要があるため、 これらの URL にもファイアウォールを開きます。
3-3. 証明書の検証のために、URL mscrl.microsoft.com:80、crl.microsoft.com:80、ocsp.msocsp.com:80、www.microsoft.com:80 のブロックを解除します。 他の Microsoft 製品でもこれらの URL を証明書の検証に使用しているので、URL のブロックを既に解除している可能性もあります。
4.PTA エージェントをインストールするサーバーは、Windows Server 2012R2 または Windows Server 2016 で実行されていること。
5. Azure AD グローバル管理者アカウントを利用できること。
6. ドメイン管理者アカウントを使用できること。
7. 対象の Azure AD テナントで Exchange Online と Skype for Business Online の先進認証が有効になっていること。
8. すべての Office クライアントに対して先進認証が有効になっていること。
#やってみる
作業の概要は下記のとおりです。
-
シームレス シングル サインオンの準備
-
サインイン方法の変更パススルー認証とシームレスな SSO の有効化
2-1. Azure AD Connect を利用し、ユーザー サインインを AD FS からパススルー認証＋シームレス シングル サインオンに変更
2-2. パススルー エージェントをインストール -
接続テスト
#####1. シームレス シングル サインオンの準備
IE 、Chrome 、Edge を利用してオンプレミス AD から発行された Kerberos チケットを Azure AD 側のエンドポイントに送るために、各 Windows コンピュータのブラウザのイントラネット ゾーンに Azure AD URL 「https://autologon.microsoftazuread-sso.com」 を明示的に追記する必要があります。
こちらの手順は以下 Microsoft 公開情報にも記載されているのでご参考まで。
-参考情報
手順 3:機能をロールアウトする
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/hybrid/how-to-connect-sso-quick-start#step-3-roll-out-the-feature
オンプレミス AD サーバーで「グループ ポリシーの管理」を開きます。
「ユーザーの構成」→ 「ポリシー」→「管理用テンプレート」→「Windows コンポーネント」→ 「Internet Explorer」→「インターネット コントロール パネル」→ 「セキュリティ ページ」の順に選択し、「サイトとゾーンの割り当て一覧」を選択し右クリックにて「編集」をクリックします。
ここにゾーンの割り当てを入力してください。の右にある「表示」をクリックします。
表示するコンテンツの画面にて値の名前を「https://autologon.microsoftazuread-sso.com」 とし、値を「1 (イントラネット ゾーンを示す)」を入力し、「OK」をクリックします。
設定後、「適用」→「OK」の順にクリックします。
「ユーザーの構成」→ 「ポリシー」→「管理用テンプレート」→「Windows コンポーネント」→ 「Internet Explorer」→「インターネット コントロール パネル」→ 「セキュリティ ページ」→「イントラネット ゾーン」の順に選択し、「スクリプトを介したステータス バーの更新を許可する」を選択し右クリックにて「編集」をクリックします。
当該のポリシーを「未構成」から「有効」に変更し、「OK」をクリックします。
グループ ポリシーが適用されると、対象のコンピューターの IE インターネット オプションのローカル イントラネットの Web サイトの欄に、設定した「https://autologon.microsoftazuread-sso.com」 がセットされていることを確認できます。
#####2. サインイン方法の変更パススルー認証とシームレスな SSO の有効化
まず、Azure AD Connect を使い、ユーザー サインインの認証方法を AD FS からパススルー認証＋シームレス シングル サインオンに変更します。
Azure ポータルで確認すると、現状は下記画面ショットのとおり、フェデレーション認証になっています。
PowerShell では「Get-MsolDomainFederationSettings -DomainName <フェデレーション ドメイン名>」で確認できます。
#######2-1. Azure AD Connect を利用し、ユーザー サインインを AD FS からパススルー認証＋シームレス シングル サインオンに変更
具体的な手順を書いていきます。Azure AD Connect を起動し、「構成」をクリックします。
追加のタスク画面より「ユーザー サインインの変更」をクリックし、「次へ」をクリックします。
対象の Azure AD テナントのグローバル管理者の資格情報を入力し、「次へ」をクリックします。
ユーザー サインインの画面に遷移します。現行の設定は以下画面ショットのとおり、「AD FS とのフェデレーション」が選択されています。
サインイン方式を「パススルー認証」と「シングル サインオンを有効にする」にチェックを入れます。
また、「Azure AD ドメインとユーザーは、フェデレーション認証からマネージド認証に変換されます。チェックボックスをオンにしてこれを確認してください。」のチェックボックスをあわせて有効にする必要があります。
「次へ」をクリックします。
シングル サインオンを有効にするの画面にて、「資格情報の入力」をクリックします。
正しく資格情報を入力するとグリーンのチェックマークが付きます。「次へ」をクリックします。
処理の内容を確認します、「構成」をクリックすることで、以下処理が行われます。
・認証エージェントがインストールされる。
・パススルー認証が有効になる。
・フェデレーション認証からマネージド認証に変更になる。
・シームレス シングル サインオンが有効になる。
構成が完了しましたの画面にて、「終了」をクリックします。
Azure ポータルの「Azure Active Directory」→「Azure AD Connect」の順にクリックし、「ユーザー サインイン」の項目を確認すると、下記画面ショットのとおり、フェデレーション認証が「無効」になり、「シームレスなシングル サインオン」と「パススルー認証」が「有効」になっていることが確認できます。
また、！マークは、認証エージェントを「3つ」以上構成することで可用性を高めるよう警告がでていることを意味しています。
公開情報では以下のように記載があります。
運用環境では、テナントで少なくとも 3 つの認証エージェントを実行することをお勧めします。 認証エージェントの数は、テナントあたり 40 個に制限されています。 また、ベスト プラクティスとして、認証エージェントを実行するすべてのサーバーは Tier 0 システムとして扱うようにしてください
#####2-2. シームレス シングル サインオンの準備
上記画面ショットの「パススルー認証」のリンクをクリックすると、以下画面ショットのように、認証エージェントがインストールされているサーバーを確認できます。また、エージェントを「ダウンロード」をクリックすることで入手できます。
使用条件に同意してダウンロードする、をクリックし、インストーラーを任意のフォルダに保存します。
本来は 3 つエージェントを構成する必要がありますが、今回は 2 つエージェントを構成します。
サーバー内でインストーラーをダブルクリックすると以下画面ショットが表示されるので、「Install」をクリックします。
アカウントにサインインの画面にて、対象の Azure AD テナントのグローバル管理者の UPN を入力し、「次へ」をクリックします。
パスワードを入力し、「サインイン」をクリックします。
インストールに成功したことを確認し、「Close」をクリックします。
再度 Azure ポータルを確認すると、！マークが消えていることが確認できます。
パススルー認証の画面でもエージェントが追加されていることが確認できます。
#####3. 接続テスト
まずは、パススルー認証の動作を確認するために、InPrivate モードで Edge を起動し、「www.office.com」にアクセスします。
オンプレミス AD から同期したユーザーの UPN を入力し、「次へ」をクリックします。
AD FS の認証画面にリダイレクトされないことを確認します。
パスワードを入力し、「サインイン」をクリックします。
Office 365 ポータルにサインインできることを確認します。
次に、通常のブラウザーモードで Chromeを起動し、「https://myapps.microsoft.com/shyamag.work」 を入力します。
シームレス シングル サインオンにより、資格情報を入力する必要がありません。
アクセス パネルにアクセスできることが確認できました。
これだけだとイメージしづらいかもしれないので、Fiddler を取りました。
注目すべきは以下 2 行です。(15行目と16行目です)
autologon.microsoftazuread-sso.com への認証要求が 401 で返されています。(15行目)
この段階でシームレスシングル シングル サインオンの認証フェーズに遷移しています。
また、次の行(16行目)でブラウザーが Active Directory のコンピューター アカウントである「AZUREADSSOACC」 に Kerberos チケットを要求し、Active Directory が対象のコンピューター アカウントの Kerberos チケットをブラウザーに返し、チケットを受け取ったブラウザーが Azure AD に返したことで、レスポンスコードが「200」になっていることが分かります。
※実際には Fiddler ではトークンの中身までは確認することはできません。
401 でシームレス シングル サインオンの認証に移行した後に、「200」ではなく「403」などのエラーコードが返ってきている場合は、Kerberos チケットを Azure AD に返すことができず、シームレス シングル サインオンに失敗します。
#おわりに
今回は AD FS を利用したフェデレーション認証から、パススルー認証＋シームレス シングル サインオンに切り替える手順を実際に試してみました。
必要な要件を満たすことができれば、比較的容易に認証方式を変更することが可能となります。
詳細な手順は「はじめに」の項目で案内した公開情報を参考にして欲しいですが、実際に今回ご案内した手順を試してみることで、動作を確認することができますので、移行を検討されている方は是非一度検証してみてください。
今回の記事が少しでも参考になれば幸いです。