Azure MFA Server と Active Directory 間のディレクトリ統合
Azure MFA Server を Active Directory や別の LDAP ディレクトリと統合するには、Azure MFA Server の [ディレクトリの統合] セクションを使用します。 そのディレクトリ スキーマに合わせて属性を構成したり、自動ユーザー同期を設定したりすることができます。
重要
2022 年 9 月、Microsoft は Azure Multi-Factor Authentication Server の廃止を発表しました。 2024 年 9 月 30 日以降、Azure Multi-Factor Authentication Server のデプロイでは、多要素認証 (MFA) 要求機能が提供されなくなり、組織で認証が失敗する可能性があります。 認証サービスが中断されることなくサポート状態を維持するには、組織が、最新の Azure MFA Server 更新プログラムに含まれている最新の移行ユーティリティを使用して、クラウドベースの Azure MFA サービスにユーザーの認証データを移行する必要があります。 詳細については、MFA Server の移行に関する記事を参照してください。
クラウドベースの MFA の使用を開始するには、「チュートリアル: Azure Multi-Factor Authentication を使用してユーザーのサインイン イベントのセキュリティを確保する」を参照してください。
設定
既定では、Azure Multi-Factor Authentication (MFA) Server は、Active Directory からユーザーをインポートするか同期するように構成されます。 [ディレクトリの統合] タブでは、この既定の動作をオーバーライドしたり、別の LDAP ディレクトリ、ADAM ディレクトリ、または特定の Active Directory ドメイン コントローラーにバインドしたりできます。 LDAP を委任するため、RADIUS ターゲットとしての LDAP バインドのため、IIS 認証のための事前認証、またはユーザー ポータルのためのプライマリ認証としての LDAP 認証の使用も提供します。 次の表で、個々の設定について説明します。
注意
ディレクトリ統合では、Active Directory Domain Services 以外のディレクトリの操作は保証されません。
特徴量 | 説明 |
---|---|
Active Directory を使用する | インポートと同期のために Active Directory を使用するには、[Active Directory を使用する] オプションを選択します。 これが既定の設定です。 注:Active Directory 統合が正しく機能するためには、対象のコンピューターをドメインに参加させ、ドメイン アカウントでサインインする必要があります。 |
信頼できるドメインを含める | エージェントに、現在のドメイン、フォレスト内の別のドメイン、またはフォレストの信頼に関係するドメインによって信頼されているドメインへの接続を試行させるには、 [信頼できるドメインを含める] チェック ボックスをオンにします。 信頼できるドメインからユーザーをインポートしないまたは同期しない場合は、パフォーマンスを向上させるためにチェックボックスをオフにします。 既定値はオンです。 |
指定の LDAP 構成を使用する | インポートと同期のために特定の LDAP 設定を使用する場合は、この LDAP を使用するオプションを選択します。 注:LDAP を使用することを選択した場合、ユーザー インターフェイスの参照が Active Directory から LDAP に変更されます。 |
[編集] ボタン | [編集] ボタンを使用して、現在の LDAP 構成設定を変更できます。 |
属性スコープ クエリを使用する | 属性スコープ クエリを使用するかどうかを示します。 属性スコープ クエリを使用すると、別のレコードの属性内のエントリに基づいてレコードを制限する効率的なディレクトリ検索を実行できます。 Azure Multi-Factor Authentication Server は、属性スコープ クエリを使用して、セキュリティ グループのメンバーであるユーザーを効率的にクエリします。 注: 属性スコープ クエリがサポートされていても、使用してはならない場合があります。 たとえば、セキュリティ グループに 1 つ以上のドメインのメンバーが含まれている場合、Active Directory で属性スコープ クエリを実行すると問題が発生する可能性があります。 その場合は、チェック ボックスをオフにしてください。 |
次の表で、LDAP 構成設定について説明します。
特徴量 | 説明 |
---|---|
サーバー | LDAP ディレクトリを実行するサーバーのホスト名または IP アドレスを入力します。 セミコロンで区切ることで、バックアップ サーバーも指定できます。 注:バインドの種類が SSL (TLS) の場合、完全修飾ホスト名を指定する必要があります。 |
ベース DN | すべてのディレクトリ クエリの開始元となるベース ディレクトリ オブジェクトの識別名を入力します。 例: dc=abc、dc=com |
バインドの種類 - クエリ | LDAP ディレクトリの検索にバインドする際に使用する適切なバインドの種類を選択します。 これは、インポート、同期、およびユーザー名の解決のために使用されます。 匿名 - 匿名バインドが実行されます。 バインド DN とバインド パスワードは使用されません。 これは、LDAP ディレクトリで匿名バインドが許可され、適切なレコードと属性のクエリの実行できるアクセス許可がある場合にのみ機能します。 シンプル - LDAP ディレクトリにバインドするために、バインド DN とバインド パスワードがプレーン テキストとして渡されます。 これは、サーバーに到達可能か、またバインド アカウントに適切なアクセス権があるかを検証するテスト目的で使用します。 適切な証明書をインストールした後は、SSL を使用してください。 SSL - LDAP ディレクトリにバインドするために、バインド DN とバインド パスワードが SSL を使用して暗号化されます。 LDAP ディレクトリで信頼されている証明書をローカルにインストールしてください。 Windows - Active Directory ドメイン コントローラーまたは ADAM ディレクトリに安全に接続するために、バインド ユーザー名とバインド パスワードが使用されます。 バインド ユーザー名が空白の場合、ログオンしたユーザーのアカウントがバインドするために使用されます。 |
バインドの種類 - 認証 | LDAP バインド認証を実行するときに使用する適切なバインドの種類を選択します。 バインドの種類については、「バインドの種類 - クエリ」の説明を参照してください。 たとえば、クエリで匿名バインドを、セキュリティで保護された LDAP バインド認証で SSL バインドを使用できます。 |
バインド DN またはバインド ユーザー名 | LDAP ディレクトリへのバインド時に使用するアカウントのユーザー レコードの識別名を入力します。 バインドの識別名は、バインドの種類がシンプルまたは SSL 場合にのみ使用します。 バインドの種類が Windows のときに、LDAP ディレクトリにバインドするときに使用する Windows アカウントのユーザー名を入力します。 空白にした場合、ログオンしたユーザーのアカウントがバインドするために使用されます。 |
バインド パスワード | LDAP ディレクトリへのバインドに使用されるバインド DN またはユーザー名のバインド パスワードを入力します。 Multi-Factor Auth Server AdSync サービスに対してパスワードを構成するには、同期を有効にし、ローカル コンピューターで AdSync サービスを実行しておく必要があります。 パスワードは、Multi-Factor Auth Server AdSync Service を実行しているアカウントの [Windows に格納されているユーザーおよびパスワード] に保存されます。 パスワードは、Multi-Factor Auth Server ユーザー インターフェイスを実行しているアカウントと、Multi-Factor Auth Server サービスを実行しているアカウントにも保存されます。 パスワードはローカル サーバーの [Windows に格納されているユーザーおよびパスワード] にしか保存されないため、この手順は、パスワードへのアクセスが必要なすべての Multi-Factor Auth Server で行う必要があります。 |
クエリ サイズの上限 | ディレクトリ検索で返されるユーザーの最大数のサイズ制限を指定します。 この制限は、LDAP ディレクトリの構成と一致する必要があります。 ページングがサポートされない大規模な検索では、インポートと同期は、バッチでユーザーの取得を試みます。 ここで指定されるサイズ制限が、LDAP ディレクトリで構成された制限より大きい場合、一部のユーザーが欠落する可能性があります。 |
テスト ボタン | LDAP サーバーへのバインドをテストするには [テスト] をクリックします。 バインドをテストするために [Use LDAP (LDAP を使用する)] オプションを選択する必要はありません。 これにより、LDAP 構成を使用する前にバインドをテストできます。 |
フィルター
フィルターを使用して、ディレクトリ検索の実行時にレコードを制限する条件を設定できます。 フィルターを設定することで、同期するオブジェクトの範囲を指定できます。
Azure Multi-Factor Authentication には、次の 3 つのフィルター オプションがあります。
- コンテナー フィルター - ディレクトリ検索の実行時にコンテナー レコードを制限するために使用するフィルター条件を指定します。 Active Directory と ADAM の場合、通常は (|(objectClass=organizationalUnit)(objectClass=container)) が使用されます。 その他の LDAP ディレクトリでは、ディレクトリ スキーマに応じて、各コンテナー オブジェクトの種類を制限するフィルター条件を使用してください。
注: 空白のままにした場合は、((objectClass=organizationalUnit)(objectClass=container)) が既定で使用されます。 - セキュリティ グループ フィルター - ディレクトリ検索の実行時にセキュリティ グループ レコードを制限するために使用するフィルター条件を指定します。 Active Directory と ADAM の場合、通常は (&(objectCategory=group)(groupType:1.2.840.113556.1.4.804:=-2147483648)) が使用されます。 その他の LDAP ディレクトリでは、ディレクトリ スキーマに応じて、セキュリティ グループ オブジェクトを種類ごとに制限するフィルター条件を使用してください。
注: 空白の場合は (&(objectCategory=group)(groupType:1.2.840.113556.1.4.804:=-2147483648)) が既定で使用されます。 - ユーザー フィルター - ディレクトリ検索の実行時にユーザー レコードを制限するために使用するフィルター条件を指定します。 Active Directory と ADAM の場合、通常は (&(objectClass=user)(objectCategory=person)) が使用されます。 その他の LDAP ディレクトリでは、ディレクトリ スキーマに応じて、(objectClass=inetOrgPerson) またはそれに類似する条件を使用する必要があります。
注: 空白の場合は (&(objectCategory=person)(objectClass=user)) が既定で使用されます。
属性
特定のディレクトリの属性を必要に応じてカスタマイズできます。 カスタム属性を追加し、必要な属性のみを対象とするように同期を微調整できます。 各属性フィールドの値には、ディレクトリ スキーマで定義されている属性の名前を使用します。 それぞれの機能については、以下の表で詳しく説明します。
属性は手動で入力でき、属性の一覧内の属性と一致させる必要はありません。
機能 | 説明 |
---|---|
一意識別子 | コンテナー、セキュリティ グループ、およびユーザー レコードの一意識別子として機能する属性の属性名を入力します。 Active Directory では、これは通常は objectGUID です。 その他の LDAP 実装では、entryUUID またはそれに類似する名前が使用されることがあります。 既定値は objectGUID です。 |
一意識別子の型 | 一意識別子属性の型を選択します。 Active Directory では、objectGUID 属性の型は GUID です。 その他の LDAP 実装では、ASCII バイト配列型または文字列型が使用されることがあります。 既定値は [GUID] です。 同期項目はその一意識別子によって参照されるため、この型を正しく設定することが重要です。 ディレクトリから目的のオブジェクトを直接検索するときに一意識別子の型が使用されます。 ディレクトリに実際に保存されている値が ASCII 文字のバイト配列のときに型を [文字列] に設定すると、同期が正常に機能しなくなります。 |
識別名 | 各レコードの識別名を含む属性の属性名を入力します。 Active Directory では、これは通常は distinguishedName です。 その他の LDAP 実装では、entryDN またはそれに類似する名前が使用されることがあります。 既定値は distinguishedName です。 識別名のみが含まれている属性が存在しない場合は、AD パス属性を使用できます。 パスの "LDAP://<サーバー>/" 部分は自動的に削除され、オブジェクトの識別名だけが残ります。 |
コンテナー名 | コンテナー レコード内の名前を含む属性の属性名を入力します。 この属性の値は、Active Directory からインポートするとき、または同期項目を追加するときに、コンテナー階層に表示されます。 既定値は name です。 注: コンテナーごとに異なる属性をその名前に使用する場合は、複数のコンテナー名属性をセミコロンで区切って指定します。 コンテナー オブジェクトで見つかった最初のコンテナー名の属性が、名前を表示するために使用されます。 |
セキュリティ グループ名 | セキュリティ グループ レコード内の名前を含む属性の属性名を入力します。 この属性の値は、Active Directory からインポートするとき、または同期項目を追加するときに、セキュリティ グループ リストに表示されます。 既定値は name です。 |
ユーザー名 | ユーザー レコード内のユーザー名を含む属性の属性名を入力します。 この属性の値は、Multi-Factor Auth Server ユーザー名として使用されます。 2 つ目の属性を 1 つ目の属性のバックアップとして指定できます。 2 つ目の属性は、1 つ目の属性にユーザーの値が含まれていない場合にのみ使用されます。 既定値は userPrincipalName と sAMAccountName です。 |
名 | ユーザー レコード内の名を含む属性の属性名を入力します。 既定値は givenName です。 |
姓 | ユーザー レコード内の姓を含む属性の属性名を入力します。 既定値は sn です。 |
電子メール アドレス | ユーザー レコード内の電子メール アドレスを含む属性の属性名を入力します。 電子メール アドレスは、ようこそメールと更新メールをユーザーに送信するために使用されます。 既定値は mail です。 |
ユーザー グループ | ユーザー レコード内のユーザー グループを含む属性の属性名を入力します。 ユーザー グループを使用して、Multi-Factor Auth Server 管理ポータルでエージェントとレポートのユーザーをフィルター処理できます。 |
説明 | ユーザー レコード内の説明を含む属性の属性名を入力します。 説明は、検索にのみ使用されます。 既定値は description です。 |
通話の言語 | ユーザーに対する音声通話で使用する言語の短縮名を含む属性の属性名を入力します。 |
テキスト メッセージの言語 | ユーザーに対する SMS テキスト メッセージで使用する言語の短縮名を含む属性の属性名を入力します。 |
モバイル アプリの言語 | ユーザーに対する電話アプリのテキスト メッセージで使用する言語の短縮名を含む属性の属性名を入力します。 |
OATH トークンの言語 | ユーザーに対する OATH トークンのテキスト メッセージで使用する言語の短縮名を含む属性の属性名を入力します。 |
勤務先の電話番号 | ユーザー レコード内の勤務先の電話番号を含む属性の属性名を入力します。 既定値は telephoneNumber です。 |
自宅の電話 | ユーザー レコード内の自宅の電話番号を含む属性の属性名を入力します。 既定値は homePhone です。 |
ポケットベル | ユーザー レコード内のポケットベルの番号を含む属性の属性名を入力します。 既定値は pager です。 |
携帯電話 | ユーザー レコード内の携帯電話の番号を含む属性の属性名を入力します。 既定値は mobile です。 |
Fax | ユーザー レコード内の Fax 番号を含む属性の属性名を入力します。 既定値は facsimileTelephoneNumber です。 |
IP 電話 | ユーザー レコード内の IP 電話の番号を含む属性の属性名を入力します。 既定値は ipPhone です。 |
Custom | ユーザー レコード内のカスタム電話番号を含む属性の名前を入力します。 既定値は空白です。 |
拡張機能 | ユーザー レコード内の内線番号を含む属性の属性名を入力します。 内線番号フィールドの値は、代表電話番号に対する内線番号としてのみ使用されます。 既定値は空白です。 内線番号属性が指定されていない場合は、電話属性の一部として内線番号を含めることができます。 その場合は、正しく解析されるように、内線番号の前に "x" を付けてください。 たとえば 555-123-4567 x 890 は、555-123-4567 が電話番号として、890 が内線番号として解析されます。 |
[既定値に戻す] ボタン | すべての属性を既定値に戻すには、 [既定値に戻す] をクリックします。 既定値は、通常の Active Directory または ADAM スキーマで正常に動作します。 |
属性を編集するには、[属性] タブの [編集] をクリックします。属性を編集するためのウィンドウが表示されます。 表示する属性を選択できるウィンドウを開くには、各属性の横の [...] を選択します。
Synchronization
Azure MFA ユーザー データベースは、Active Directory や他のライトウェイト ディレクトリ アクセス プロトコル (LDAP) ディレクトリとの間でユーザーの同期状態を維持することができます。 このプロセスは Active Directory からユーザーを手動でインポートすることと似ていますが、Active Directory に対してユーザーとセキュリティ グループの変更を定期的にポーリングします。 また、コンテナー、セキュリティ グループ、または Active Directory から削除されたユーザーは無効になるか、削除されます。
Multi-Factor Auth ADSync サービスは、Active Directory の定期的なポーリングを実行する Windows サービスです。 これを Azure AD Sync または Microsoft Entra Connect と混同しないでください。 Multi-Factor Auth ADSync は類似するコード ベースに基づいて構築されていますが、それは Azure Multi-Factor Authentication Server に固有のサービスです。 このサービスは停止状態でインストールされ、実行するように構成されたときに Multi-Factor Auth Server サービスによって開始されます。 複数のサーバーを対象とする Multi-Factor Auth Server 構成がある場合でも、Multi-Factor Auth ADSync は単一のサーバーでのみ実行できます。
Multi-Factor Auth ADSync サービスは、変更を効率的にポーリングするために Microsoft によって提供された DirSync LDAP サーバー拡張機能を使用します。 この DirSync コントロールの呼び出し元は、"ディレクトリの変更を取得する" 権限と、DS-Replication-Get-Changes 拡張コントロール アクセス権を持っている必要があります。 既定では、これらの権限は、ドメイン コントローラーの管理者と LocalSystem アカウントに割り当てられます。 Multi-Factor Auth AdSync サービスは、既定で LocalSystem として実行するように構成されます。 したがって、最も簡単な方法は、サービスをドメイン コントローラーで実行することです。 サービスを常に完全同期を実行するように構成した場合は、より低いアクセス許可を持つアカウントで実行できます。 効率は落ちますが、要求されるアカウント権限が低くなります。
LDAP ディレクトリが DirSync に対応していて、かつ DirSync を使用するように構成されている場合、ユーザーとセキュリティ グループの変更に関するポーリングは、Active Directory の場合と同じように動作します。 LDAP ディレクトリが DirSync コントロールをサポートしていない場合、完全同期は各サイクル中に実行されます。
[同期] タブの各設定については、以下の表でさらに詳しく説明します。
特徴量 | 説明 |
---|---|
Active Directory との同期を有効にする | オンにした場合、Multi-Factor Auth Server サービスは、Active Directory の変更を定期的にポーリングします。 注:Multi-Factor Auth Server サービスで変更の処理を開始する前に、少なくとも 1 つの同期項目を追加し、[今すぐ同期] を実行する必要があります。 |
同期間隔: | Multi-Factor Auth Server サービスが、ポーリングと変更の処理を実行するために待機する時間間隔を指定します。 注:指定する間隔は、各サイクルの先頭と先頭の間の時間です。 変更の処理時間が間隔時間を超過した場合、サービスは次のポーリングをすぐに実行します。 |
Active Directory にないユーザーを削除する | オンにした場合、Multi-Factor Auth Server サービスは、Active Directory で削除されたユーザーの廃棄状態を処理し、関連する Multi-Factor Auth Server ユーザーを削除します。 |
常に完全同期を実行する | オンにした場合、Multi-Factor Auth Server サービスは常に完全同期を実行します。 オフにした場合、Multi-Factor Auth Server サービスは、変更されているユーザーのみをクエリすることで増分同期を実行します。 既定の設定はオフです。 オフの場合、ディレクトリが DirSync コントロールをサポートし、ディレクトリにバインドするために使用されるアカウントが、DirSync の増分クエリを実行するためのアクセス許可を持っている場合にのみ増分同期が実行されます。 アカウントに適切なアクセス許可がない場合、または複数のドメインが同期に関係している場合、Azure MFA Server は完全同期を実行します。 |
無効なユーザーまたは削除するユーザーがしきい値を超えたときに管理者の承認を必須にする | 同期項目は、項目のコンテナーまたはセキュリティ グループのメンバーでなくなったユーザーを無効にするか削除するように構成できます。 安全のために、無効にするか削除するユーザーの数がしきい値を超えたときに、管理者の承認を要求することができます。 オンにした場合、指定したしきい値に達したときに承認が要求されます。 既定値は 5 で、指定範囲は 1 ~ 999 です。 承認は、まず管理者に電子メール通知を送信することで実施されます。 電子メール通知により、ユーザーの無効化と削除を確認して承認するための指示が出されます。 Multi-Factor Auth Server ユーザー インターフェイスが起動され、承認を求めるメッセージが表示されます。 |
[今すぐ同期] ボタンを使用して、指定した同期項目の完全同期を実行できます。 完全同期は、同期項目の追加、変更、削除、または順序変更を行った場合に、常に実行する必要があります。 また、Multi-Factor Auth AdSync サービスは、増分変更用のポーリングを開始する時点を設定するため、そのサービスを運用する前にも実行する必要があります。 同期項目に対する変更が行われたにもかかわらず完全同期が実行されていない場合は、今すぐ同期するように求められます。
管理者は、 [削除] ボタンを使用して、1 つ以上の同期項目を Multi-Factor Auth Server の同期項目の一覧から削除できます。
警告
削除された同期項目レコードは復元できません。 同期項目レコードを誤って削除した場合は、追加し直す必要があります。
同期項目は、Multi-Factor Auth Server から削除されています。 Multi-Factor Auth Server サービスは、それらの同期項目を処理しません。
管理者は、[上へ移動] ボタンと [下へ移動] ボタンを使用して、同期項目の順序を変更できます。 同じユーザーが 1 つ以上の同期項目 (コンテナーとセキュリティ グループなど) のメンバーである場合があるため、順序は重要です。 同期中にユーザーに適用される設定は、ユーザーが関連付けられている一覧の最初の同期項目から使用されます。 このため、同期項目は優先順位に従って配置する必要があります。
ヒント
同期項目を削除した後、完全同期を実行する必要があります。 同期項目を並べ替えた後、完全同期を実行する必要があります。 完全同期を実行するには、 [今すぐ同期] をクリックします。
Multi-Factor Authentication サーバー
追加の Multi-Factor Authentication サーバーを、バックアップ RADIUS プロキシ、LDAP プロキシ、または IIS 認証として機能するように設定できます。 同期構成は、すべてのエージェント間で共有されます。 ただし、Multi-Factor Authentication サーバー サービスは、これらのエージェントのいずれかのみで実行できます。 このタブで、同期するために有効にする必要がある Multi-Factor Authentication サーバーを選択できます。