Active Directory フェデレーション サービス (AD FS) では、ユーザーのログオンとこれらのユーザーのセキュリティ要求の抽出にアカウント ストアが使用されます。1 つのフェデレーション サービスに対して複数のアカウント ストアを構成したり、これらの優先順位を定義したりすることができます。フェデレーション サービスとアカウント ストアとの通信には、LDAP (ライトウェイト ディレクトリ アクセス プロトコル) が使用されます。AD FS では次の 2 つのアカウント ストアがサポートされています。
-
Active Directory ドメイン サービス (AD DS)
-
Active Directory ライトウェイト ディレクトリ サービス (AD LDS)
AD FS は、エンタープライズ規模の AD DS の展開または AD LDS のインスタンスの両方に対応します。AD DS と一緒に使用する場合、AD FS は Kerberos、X.509 デジタル証明書、およびスマート カードを含む強力な認証テクノロジを利用できます。AD LDS と一緒に使用する場合、AD FS は、ユーザーを認証する手段として LDAP バインドを使用します。
AD DS アカウント ストア
AD FS は AD DS と密接に統合されています。AD FS により、ユーザー属性が取得され、AD DS に対するユーザーの認証が行われます。また、AD FS では Windows 統合認証と AD DS により作成されるセキュリティ トークンが使用されます。
AD DS にログオンするユーザーのユーザー名は、ユーザー プリンシパル名 (UPN) 形式 (user@adatum.com)、またはセキュリティ アカウント マネージャー (SAM) アカウント名形式 (adatum\user) のどちらかになります。
ユーザーのログオン時にはアクセス トークンが生成されます。アクセス トークンには、ユーザーのセキュリティ識別子 (SID) と、そのユーザーが属しているすべてのグループが含まれています。ユーザーが起動したすべてのプロセスには、アクセス トークンのコピーが割り当てられます。
ユーザーのログオンおよび偽装後に、ユーザー SID がアクセス トークンから列挙されます。その後、SID は組織グループの要求にマップされます。
注意 | |
アカウントのフェデレーション サービスで Windows の信頼オプションを有効にすると、実際の SID をインターネット経由でリソース パートナー組織に送信することになりますが、これはセキュリティ リスクとなる可能性があります。これらの SID は AD FS の SAML (Security Assertion Markup Language) トークンにパッケージ化されます。そのため、フォレストの信頼のあるフェデレーション Web SSO デザインを使用している場合にのみ、このオプションを有効にしてください。このデザインは、同じ組織内部で安全な通信を確立することを目的としています。 |
オブジェクトの LDAP の検索にフェデレーション サービス アカウントを使用した場合、電子メール要求、共通名要求、およびカスタム要求は、AD DS で定義されたユーザー オブジェクト属性から抽出されます。
フェデレーション サービス アカウントは、ユーザー オブジェクトにアクセスできる必要があります。このユーザー オブジェクトが、フェデレーション サービス アカウントの存在するドメインとは異なるドメインに存在する場合、ユーザー オブジェクトのドメインには、フェデレーション サービス アカウントのドメインに対する AD DS ドメイン信頼が設定されている必要があります。
どのようなユーザー名であっても、指定された名前が AD DS や、AD DS により (直接的にまたは推移的に) 信頼されているディレクトリすべてに存在するかどうかを直接決定する方法はありません。ポリシー制限のためログオンに失敗した場合のみ、AD DS は正式なエラーを返します。ポリシー制限エラーには次のものがあります。
-
アカウントが無効である。
-
アカウント パスワードの期限が切れている。
-
アカウントは、このコンピューターへのログオンを許可されていない。
-
アカウントにはログオン時間の制限が設定されていて、この時間にはログオンが許可されていない。
これ以外の場合、AD DS アカウント ストアのログイン エラーは、常に、権限がないことを表し、次に優先順位の高いアカウント ストアが試行されます。アカウント ストアのログイン エラーの詳細については、「AD FS のトラブルシューティング」を参照してください。
AD LDS アカウント ストア
AD LDS では、AD DS ディレクトリ サービスに必要な依存関係がなくても、ディレクトリ対応アプリケーションのデータを保存および取得できます。AD LDS では、AD DS と同じ機能が数多く提供されますが、ドメインやドメイン コントローラーの展開は不要です。AD DS アカウント ストア情報を使用する場合と類似した方法で、AD FS はユーザー属性を取得し、AD LDS と照合してユーザーを認証できます。
注 | |
AD FS は、アカウント名の一部にかっこを含む AD LDS アカウントは認証できません。ユーザー名に左かっこを含むアカウントは、LDAP 検索エラーの原因となります。これはユーザー名が無効な LDAP フィルターを形成するからです。 |
フェデレーション サービス アカウントは、LDAP によるオブジェクトの検索の実行に使用される要求を取得します。詳細については、「要求とは」を参照してください。これは、次の 2 つの手順で実行されます。
-
まず、フェデレーション サービス アカウントはユーザー オブジェクトを見つけるために、与えられたユーザー名と同じように構成された属性を持つオブジェクトを検索します。フェデレーション サービス アカウントは、Kerberos または NTLM 暗号化を使用して、この通信を保護します。
注 この手順では、フェデレーション サービスがメンバーとなっているドメインを信頼している、ドメインに AD LDS サーバーを参加させる必要があります。
-
次に、ユーザーの資格情報を検証するために、LDAP バインドが行われ、発見されたユーザー オブジェクトが与えられたパスワードにバインドされます。この信頼ポリシーで、AD LDS アカウント ストア属性に対する Transport Layer Security (TLS) および Secure Sockets Layer (SSL) が構成されている場合、ユーザーの資格情報は保護されます。
重要 AD LDS サーバーとフェデレーション サーバーの間のトラフィックについては、TLS/SSL や Internet Protocol security (IPsec) などの方法で保護することを強くお勧めします。
指定されたユーザー名を使った LDAP クエリから複数のオブジェクトが返された場合、認証は失敗したと見なされます。
ユーザー アカウントは、最初に AD LDS アカウント ストア内で検索されるように構成されている場合はそこで検索され、その後、他の LDAP ストアがその順序で構成されます。いずれかのストアでユーザー アカウントが見つかった場合は、ユーザーの正式なログオンが行われ、ユーザーのログオン要求を処理するための他のアカウント ストアの呼び出しは行われません。
ユーザーのログオン要求の優先順位を決定する
ユーザーが AD FS クライアントを通じて、AD DS または AD LDS にログオンを要求すると同時に、この要求は指定されたアカウント ストアに渡されます。ただし、アカウント ストアの Uniform Resource Identifier (URI) が指定されていない場合、フェデレーション サービスは優先順位に従って、個々のストアに対してユーザーのログオンを試行します。以下の場合、認証結果が返されます。
-
構成済みのストアが 1 つのみで、資格情報の検証情報が返された。
-
ストア URI がログオン要求で指定されており、資格情報の検証情報が返された。
-
ストアの 1 つによる認証の結果が権限のあるものであった。
-
ストアの 1 つによる認証が正常に終了した。
アカウント ストアを無効にする
アカウント ストアには、それぞれ有効または無効のマークを付けることができます。無効なアカウント ストアは、アカウント ストア関連の操作には参加しません。現在無効になっているアカウント ストアからの要求を持つ Cookie は破棄または削除され、クライアントはログオン ページに導かれます。