MSIS9642の根本的な原因は、ADFS 2016 の新しい OpenID Connect アプリケーション グループ機能がアプリケーションにアクセス トークンを発行する必要があることです。このトークンには、ユーザー ID が含まれている必要があります。トークンを発行するために、サブシステムは、インバウンドクレームのどのクレームがユーザーを一意に識別するために使用されるかを理解する必要があります。
AnchorClaimTypeという新しいプロパティがクレーム プロバイダー信頼モデルに追加されました。
ADFS を最初にインストールすると、AD AUTHORITY のビルトイン Claim Provider Trust が登録され、AnchorClaimTypeの値が
foo://schemas.microsoft.com/ws/2008/06/identity/claims/ windowsaccountname
これは、powershell コマンドget-adfsclaimsprovidertrustを使用して確認できます。
これが、Active Directory に対する認証時に OpenID が機能する理由です。
新しい Claim Provider Trust を作成するとき、システムはAnchorClaimTypeを設定しません。OpenID システムは、一意のユーザー ID を構成するインバウンド クレームがわからないため、トークンを発行できません。これが、外部クレーム プロバイダーの信頼に対して認証するときに OpenID が機能しない理由です。
この問題を解決するには、いくつかのアクションを実行する必要があります。
a) Windows Server 2016 RTMを実行していることを確認します残念ながら、AnchorClaimType を設定するための powershell 属性が CTP に存在せず、UI を使用してプロパティを設定できません。
b) ユーザー ID を表すインバウンド トークンからクレームを選択し、クレームの種類を識別します。この例では、Azure Active Directory とフェデレーションし、nameを選択しました。タイプは foo://schemas.xmlsoap.org/ws/2005/05/identity/claims/ name です。
c) powershellを使用して、Claim Provider TrustのAnchorTypeClaimを選択したタイプに設定します。
set-adfsclaimsprovidertrust -targetidentifier識別子-AnchorClaimType http://schemas.xmlsoap.org/ws/2005/05/identity/claims/ name
( powershell get-adfsclaimsprovidertrust から識別子を取得)
d) プライマリ入力クレーム (この場合は Name) の値を通過する受信ルールを少なくとも 1 つ作成します。
お役に立てれば