皆さんこんにちは。国井です。
ADFSトレーニングテキスト全文公開チャレンジの10回目となる今回はAzure AD Connectを利用したID連携のための環境づくりについて解説します。
■ ■ ■
Active Directory と Azure AD の間でのディレクトリ同期を担当する Azure Active Directory Connect ツールは、同期元となる Active Directory ドメインと同期先となる Azure AD ディレクトリをそれぞれ自由に指定することができ、次のようなパターンでの同期設定ができます。
■1つのドメイン (フォレスト) から 1 つの Azure AD ディレクトリへ同期
■複数のドメイン (フォレスト) から 1 つの Azure AD ディレクトリへ同期
一方、AAD Connect では複数の Azure AD ディレクトリを同期先として指定することはできません。複数の Azure AD ディレクトリを同期先として使用する場合には、マイクロソフトが有償で提供するディレクトリ同期製品である、Microsoft Identity Manager (MIM) を利用する必要があります。
ディレクトリ同期ツールには、いずれもマイクロソフトのディレクトリ同期製品である Microsoft Identity Manager (MIM) のエンジンが使われており、ディレクトリ同期を実行すると MIM のコンポーネントを利用して Active Directory と Azure AD の同期が行われます。
ディレクトリ同期ツールは Active Directory と Azure AD の間で直接同期を行っているわけではなく、ディレクトリ同期ツールの中に作成されるメタバース (Metaverse) と呼ばれるデータベースに一旦格納し、それから同期処理を行います。
メタバースは様々なディレクトリ データベースからディレクトリ固有の情報を取り除き、汎用的な情報だけを保存することで、他のディレクトリデータベースへスムーズな同期を実現します。たとえば、Active Directory におけるユーザー名を表す sAMAccountName 属性は、他のディレクトリ データベースでは使われることの無い、Active Directory 固有の情報です。こうした情報はメタベースに格納する際に sAMAccountName 属性から username 属性に変換するなどの処理を施してから格納します。このような処理を行うとき、変換処理を行う前のデータを格納する場所としてコネクタスペース (CS) が用意されています。
一方、Active Directory からメタバースへデータを格納する際、一時的な領域として用意されているコネクタ スペースへのデータ格納処理を Import、コネクタスペースからデータを変換し、格納する処理をSynchronization と呼んでいます。
メタバースにデータを格納するための処理として使われる、コネクタスペースや格納処理を表すImport/Synchronization はすべて Management Agent (MA) と呼ばれる設定で定義されます。ディレクトリ同期ツールでは、Active Directory とメタバースをつなぐ MA として Active Directory Connector があらかじめ用意されています。
メタバースに格納されたデータは最終的に Azure AD に同期しますが、メタバースから Azure AD への書き込み処理は Windows Azure Active Directory Connector MA で定義されている Export 処理によって実現します。
スタートメニューから Synchronization Service を実行し、[Management Agents] タブをクリックするとメタバースにつながる MA を 2 つ確認することができます。ひとつが Active Directory につながる Active Directory Connector、もうひとつが Azure AD につながる Azure AD Connector です。それぞれの MA による Import、Synchronization、Export の各処理は既定で 30 分おきに実行され、その結果は miisclient.exe の [Operations] タブで確認することができます。それぞれの MA の処理は次の順序で行われるため、[Operations] タブを確認することで、正しくディレクトリ同期が行われているか確認できます。[Operations] タブを確認すると、同期処理が次のような順序で行われていることが確認できます。
① Active Directory Connector の Delta Import Delta Sync
② Windows Azure Active Directory Connector の Delta Import Delta Sync
③ Windows Azure Active Directory Connector の Export
①～③の処理結果をクリックすると、左下ペインにメタバースまたは Azure AD に登録されたオブジェクトの数やそれぞれのオブジェクトに関する情報をクリックして確認できるため、同期時にどのようなオブジェクトが同期されたかも同時に確認できます。
AAD Connect による同期対象のカスタマイズを行う方法には、Synchronization Service ツールを利用する方法と、Synchronization Rules Editor ツールを利用する方法があります。
■Synchronization Service ツール
Synchronization Service ツールでは、同期するドメインまたは OU の限定ができます。Synchronization Service ツールの Active Directory Connector MA のプロパティから [Configure Directory Partitions] をクリックして設定します。[Select Directory Partitions] 欄でフォレスト内で同期対象とするドメインを選択、または [Containers] 欄でドメイン内で同期対象とする OU を選択することができます。
補足：現在では、Azure AD Connectのセットアップウィザード内で同期対象OUは選択できるようになっています。
■Synchronization Rules Editor ツール
Synchronization Rules Editor ツールでは、ユーザーやグループなど、同期すべき対象に対して 2 つのディレクトリ間でどのようにマッピングさせるかを定義しています。マッピング設定は、メタバースに登録する方法を定義している Inbound (Inbound Synchronization Rule : ISR) と Outbound (Outbound Synchronization Rule : OSR) の 2 つから構成されており、それぞれのマッピング ルールにはディレクトリ間のオブジェクトをどのような属性をキー属性としてマッピングするかを定義する Provision ルールと、その他の属性をどのようにマッピングするかを定義する Join ルールがあります。
AAD Sync で同期対象を一部のユーザーまたはグループに限定したい場合、Active Directory MA のInbound ルールを作成し、同期対象を属性の単位で定義できます。
SyncRulesEditor.exe を利用してディレクトリ同期対象のカスタマイズを行う場合、既定のルールではなく、必ず新規に Inbound – Join ルールを作成し、条件設定を行います。
SyncRulesEditor.exe では、Active Directory MA からメタバースへ同期する際に、CloudFiltered = Trueの値を設定することで、Azure AD への同期が抑制されます。そのため、ルール作成時に、Transformations項目で CloudFiltered = Trueの値を設定します。
一方、CloudFiltered = Trueの値を適用するオブジェクトの指定は ルール内のScoping Filter 項目から行います。Scoping Filter の中で「同期させたくない」オブジェクトの条件を指定します。例えば、ユーザーの description 属性に NOSYNC という値が設定されている場合には同期しないという条件を設定するのであれば、Scoping Filter で description equal NOSYNC となるように設定します。
SyncRulesEditor.exe によるルール作成を行う際、CloudFiltered = True を設定する Transformations 項目から直接条件を設定することも可能です。Transformations 項目から条件を設定するときは、IIF 関数を利用します。IIF 関数とは、条件と条件を満たすときに設定する値を同時に設定できる関数で、次のような要領で記述します。
IIF(条件, 条件に合致するときの値, 条件に合致しないときの値)
CloudFiltered 属性の値として、IIF 関数を利用し、条件には同期させないオブジェクトの情報を入力し、条件に合致するときの値に TRUE、条件に合致しないときの値に NULL を設定します。以上を踏まえ、SUPPORT_338945a0 ユーザーが同期されないように構成する場合、次のような IIF 関数式を書きます。
IIF([sAMAccountName] = “SUPPORT_338945a0”, True, NULL)
IIF 関数で複数の条件を設定するときは || を使います。sAMAccountName 属性が存在しない場合 (IsPresent([sAMAccountName])=False と記述)、または SUPPORT_338945a0 ユーザーの場合には同期されないように構成するときは、次のような IIF 関数式を書きます。
IIF(IsPresent([sAMAccountName]) = False || [sAMAccountName] = “SUPPORT_338945a0”, True, NULL)
その他、IIF 関数内の条件部分には次のような式を記述することができます。
■department (部署属性) が 営業 ではない場合
[department] <> “営業”
■PhysicalDeliveryOfficeName (事業所属性) に 東京または大阪の場合
[PhysicalDeliveryOfficeName] = “東京” || [PhysicalDeliveryOfficeName] = ”大阪”
■sAMAccountName の最初から 4 文字が AAD_ の場合
Left([sAMAccountName], 4) = “AAD_”
■sAMAccountName に } という文字が含まれる場合
InStr([sAMAccountName], “}”) > 0
■sAMAccountName の最初から 4 文字が CAS_ でかつ後続に } という文字が含まれる場合
Left([sAMAccountName], 4) = AAD_ && InStr([sAMAccountName], “}”) > 0
■特定の OU (ou=sales,dc=example,dc=com) に含まれる場合
Right([distinguishedName], 26) = “ou=sales,dc=example,dc=com”
ディレクトリ同期ツールではなく、Azure AD に直接ユーザーを作成した場合、既定でそのユーザーは Active Directory ユーザーと関連付けられず、別々のユーザーとしてみなされます。
もし、Azure AD に作成したユーザーを後から Active Directory ユーザーと関連付けを行いたい場合、SMTP マッチと呼ばれる関連付けを行います。SMTP マッチはディレクトリ同期を行う際、Azure AD と AD ユーザーの次の値が同じであれば、自動的に関連づけを行います。
■Azure AD ユーザー：Exchange Online のプライマリ SMTP アドレス
■AD ユーザー：ユーザーの mail 属性または proxyAddresses 属性
Exchange Online のプライマリ SMTP アドレスは Office 365 管理ポータルから [管理] – [Exchange] をクリックして Exchange 管理センターに移動し、該当するユーザーのプロパティから [電子メールオプション] で確認できます。[電子メール オプション] 画面に複数の SMTP アドレスが登録されている場合、SMTP: または smtp: でアドレスが表示されますが、プライマリ SMTP アドレスは SMTP: で始まる値で表示されます。
これまで、ADFS サーバーを利用した ID 連携の方法について解説しました。実際の運用では ADFS サーバーを複数台のサーバーで運用することにより、継続してサービスを利用できるように構成できますが、万が一 ADFS サーバーが全く利用できなくなった場合には、ID 連携を利用せずに、ディレクトリとパスワードを同期する運用に切り替えることができます。
ID 連携から同期 ID に切り替える操作は Azure AD PowerShell の以下のコマンドレットを実行します。
Set-MsolDomainAuthentication -Authentication Managed `
-DomainName <ドメイン名>
Azure AD PowerShell では Convert-MsolDomainToStandard コマンドレットを別途用意していますが、このコマンドレットは ADFS サーバーが動作している前提で利用するため、ADFS サーバーに障害が発生したときの運用には向きません。
また、フェデレーション ID から同期 ID に切り替わるとき、マイクロソフトが公表する情報に基づくと、2～3 時間程度の待ち時間が発生します。そのため、切り替わるのに要する時間よりも早く ADFS サーバーの復旧が可能であれば、同期 ID に切り替えるよりもサーバーの復旧を行うべきでしょう。
ADFS サーバーも、ディレクトリ同期ツールも、永続的に使用不能になった場合、同期 ID からクラウド ID に切り替える選択肢があります。しかし、クラウド ID への切り替え処理には最大 72 時間を要する上、ディレクトリ同期ツールが実行できなくても同期された ID は引き続き利用可能なため、クラウド ID への切り替えではなく、ディレクトリ同期ツールの再構築による対応を行うことをお勧めします。
もし、同期 ID からクラウド ID への切り替えを行う場合、Office 365 管理ポータルの [ユーザーとグループ] からディレクトリ同期の [非アクティブ化] をクリックして、処理を行います。
ADFS サーバーやディレクトリ同期ツールを含む SSO 環境のディザスタ リカバリーを行う際、あらかじめ遠隔地に DR サイトを用意しておき、障害発生時に DR サイトに切り替えて、引き続きサービスを提供する運用方法があります。
SSO 環境で DR サイトへの切り替えを行う場合、これまでに登場した、次のテクノロジーを組み合わせることによって切り替えができますので、手順をメンバーで共有したり、自動化させたりしながら、すばやく切り替えられるようにしてください。
■ドメインコントローラーの切替
ADFS サーバーがトークンを発行する際、Active Directory ユーザーの認証も同時に行うため、DR サイトからでもドメインコントローラーにアクセスできる必要があります。そのため、DR サイトにも追加のドメイン コントローラーを 1 台用意してください。
■ADFS サーバーの切替
現在使用している ADFS サーバーからセカンダリとして構成している ADFS サーバーへ切り替える場合、セカンダリの ADFS サーバーから PowerShell の以下のコマンドレットを実行します。
Set-ADFSSyncProperties -Role PrimaryComputer
ADFS サーバーが組み込みのデータベースを利用して運用されている場合、ADFS サーバー間では 5 分に一度、データベースの複製を行います。しかし、データベースの内容には ADFS 管理ツールで設定した内容しか含まれないため、直近で管理ツールから設定変更を行っていない限り、複製されていないことが別のトラブルを引き起こすことは考えられないでしょう。
また、クライアントコンピューターからの名前解決要求に対して DR サイトの ADFS サーバーが処理を受け付けられるよう、フェデレーションサービス名の DNS レコードを書き換えてください。
■Web アプリケーション プロキシの切替
現在使用しているWeb アプリケーション プロキシを別の Web アプリケーション プロキシへ切り替える場合に、Web アプリケーション プロキシ サーバー上で行う操作はありません。ただし、Web アプリケーションプロキシが正常に動作するためには、名前解決が正しく行われる必要があります。具体的には次の2つの点に注意してください。
1 つは Web アプリケーション プロキシが ADFS サーバーにアクセスする際の名前解決です。DR サイトに切り替えて運用している場合、Web アプリケーション プロキシがアクセスする ADFS サーバーは DR サイトの ADFS サーバーになります。DR サイトの ADFS サーバーにアクセスできるよう、Hosts ファイル等を書き換えておいてください。
もう 1 つはクライアントコンピューターが Web アプリケーション プロキシ にアクセスする際の名前解決です。一般に外部に公開されている DNS サーバーに Web アプリケーション プロキシの IP アドレスが登録されていますが、この情報を DR サイトの Web アプリケーション プロキシをポイントするように設定変更します。
■ディレクトリ同期ツールの切替
ディレクトリ同期ツールはステージングモードを有効にしておくことで、待機系のサーバーをあらかじめ用意しておくことができます。もし DR サイトにステージングモードのサーバーを実装している場合、ステージングモードを無効にして、ディレクトリ同期が開始できるように構成してください。なお、本番系と待機系では設定を同期する機能がないため、もし SyncRulesEditor.exe などで設定を変更している場合、その設定は手動で待機系にも同じ設定を施しておいてください。
編集後記
Azure AD ConnectとADFSサーバーの冗長構成について解説しました。
Azure AD Connectは今でも通用する話でADFSを使わない人でも役立てる場面もあるのではないかと思います。
どうでもいいことですが、このころはAzure Active Directory Connectの短縮名って、AAD Connectか、Azure AD Connectか、など揺れていましたね。明日もお楽しみに！
