web-dev-qa-db-ja.com

ADFS-プロバイダーの信頼とADからのクレームの組み合わせ

SharePoint 2013インストールの実装の一環として、Windows Server2012R2でADFSを使用してSSOを構成しました。

2つの別個のADフォレストがあり、1つはHosted SharePoint/ADFSの一部として、もう1つはオンサイトの企業フォレストです。

現在、企業のADをClaims Provider TrustのSharePoint ADFSとして設定しています。企業のADからSharePointに電子メール属性を正常に渡すことができます。

私が達成したいのは、Hosted AD Forestアカウントを使用したログオンの一部として、Corporate ADからの何らかの形式のクレームインジェクションです。
具体的には、ユーザーはSharePointライセンスを決定するセキュリティグループのメンバーになります。セキュリティ上の理由から、企業ADからこのクレーム情報を取得したくないので、ユーザーはライセンスステータスを変更できます。

したがって、すべてのユーザーは実際には両方のフォレストにADアカウントを持っています。サインインプロセスの一部として企業の資格情報を入力することにより、シングルサインオンが提供されます。

hosted ADFSからincoming Email Address Claimに一致する独自のADフォレスト内のユーザーを検索し、Corporate ADFSを挿入するようにRole claimに指示する方法はありますか。 hosted forestと上記の電子メールの主張？

私が達成しようとしていることについては、下の写真を参照してください（MSペイントの簡単な描画でごめんなさい！）： ADFS Problem Description

ステップ4と5を達成するにはどうすればよいですか？

現在のクレームルール
Hosted ADFS、Acceptance Transform RulesのCorporate Claim Provider Trust：

  1. 受信メールアドレスの要求をパススルーし、すべての値をパススルーする

Hosted ADFSの場合、Issuance Transform Rules、SharePoint Relying Party：

  1. LDAP属性をクレームとして送信する（UPN-> UPN、トークングループ->ロール、電子メールアドレス->電子メール）
  2. 受信メールアドレスの要求をパススルーし、すべての値をパススルーする
authenticationsingle-sign-onadfs
4
Antix

はい、うまくいくはずです。ホストされたADFSでクレームルールを制御し、クレームにCorp ADFSからのキーがある場合は、そのキーを使用して通常のAD検索クレームルールを実行できます。

2
paullem

最終的にこれが機能するようになりましたが、実際には思ったほど悪くはありませんでした。SharePoint証明書利用者にカスタムIssuance Transform Ruleをコーディングする必要がありました。

これは私が思いついたものです：

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]
 => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", "http://schemas.Microsoft.com/ws/2008/06/identity/claims/role"), query = "userPrincipalName={0};userPrincipalName,tokenGroups;MYDOMAIN\accountthatdoesnotexist", param = c.Value);

基本的に、これは、受信クレームセットで電子メールアドレス要求が定義されている場合、ADに電子メールアドレスを照会し、email addressに一致するuserPrincipalNameを見つけることを示しています。次に、必要なupnおよびtokenGroupsクレームとしてupnおよびrole属性を返すだけです。

これをルール番号1として証明書利用者に挿入しました。一部のユーザーはサードパーティのADFSを認証しないため、これにより、互換性が最も高まると思います。

[AD属性の送信]テンプレートを使用するときにデフォルトのクレームコードを検査した後、ルールがwindowsaccountname claimを受信した場合にのみ実際に実行されます（このクレームは、ユーザーがサードパーティのADFSなしでサインインした場合にのみ証明書利用者に渡されます） ）。

したがって、ユーザーがwithout a third party ADFSにサインインしている場合、ActiveDirectory属性ストアがemail address claimを送信しないため、カスタムルールが無視されるという状況があります。さらに、ユーザーがWITH a third party ADFSにサインインしている場合、windowsaccountnameクレームが設定されていないため、Send LDAP Attributesルールは無視されます。

最後に、最初の試みで、イベントログにエラーメッセージが表示されたため、ホストされたADで従来のドメイン\ユーザー名アカウントではなくUPNのみを使用しているため、最初は行き詰まっていると思いました。

Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.AttributeStoreQueryFormatException: 
POLICY3826: 
User name '[email protected]' in LDAP query';userPrincipalName,tokenGroups;[email protected]' 
is not in the required 'domain\user' format.

ただし、私にとって朗報は、domain\usernameのusername部分が実際には無視されることです。 https://technet.Microsoft.com/en-us/library/adfs2-help-attribute-stores%28WS.10%29.aspx

QUERY = <QUERY_FILTER>;<ATTRIBUTES>;<DOMAIN_NAME>\<USERNAME>

クエリのこの部分は、LDAPクエリを実行するために接続するドメインコントローラーを識別して特定します。

また、Active Directory属性ストアの場合でも、USERNAMEは無視されることに注意してください。

したがって、LDAPフィルターがデフォルト（クエリフィルターが空白のままの場合）userPrincipalNameではなくsamAccountNameで一致するように少し調整することで、これは完全に機能するようになりました。

0
Antix