web-dev-qa-db-ja.com

ADFS経由で認証するときに「InvalidNameIdPolicyException：MSIS7070」が発生するのはなぜですか？

BomgarアプライアンスにADFS認証（サーバー2012）をセットアップしようとしています。 ADFSとBomgarの両方がVMware Workstation仮想マシンで実行されています。 ADFSはIdP（ https：//wodan-kaveh.ingi.local にあります）として機能しており、Bomgarは依拠当事者（ https：// cenhelm にあります）です。 ）。これはデモ環境であるため、現在WindowsHOSTSですべてが解決されています。

証明書利用者のメタデータをBomgarからADFSにインポートし、FederationMetadata.xmlをADFSからBomgarにインポートしました。 BomgarはブラウザーをADFSログインページに正常に参照し、そこでADユーザーとの認証に成功し、ブラウザーはADFSログインページからBomgarに正常に戻されます。ただし、その時点で、Bomgarログインフォームから認証失敗メッセージを受信し、ADFSはイベントID 364をログに記録し、ChromeのSAMLメッセージデコーダーは "urn：oasis：のStatusCode値をログに記録します。 names：tc：SAML：2.0：status：InvalidNameIDPolicy "。

ADFSエラーは、NameIDPolicyが満たされていないことを示しています。 stackoverflowの質問16403359には、ADFSイベントログの次の行を示す回答があります。「実際のNameIDプロパティ：null。」;ただし、私のADFS証明書利用者信頼構成のNameIDが入力されています。これは、Bomgarの信頼設定の[識別子]タブで確認できます。

ADFSの経験がある人は、このnull NameID/InvalidNameIDPolicyの問題について知っていますか？

ADFSイベントID364

Encountered error during federation passive request. 

Additional Data 

Protocol Name: 
Saml 

Relying Party: 
https://cenhelm 

Exception details: 
Microsoft.IdentityServer.Protocols.Saml.InvalidNameIdPolicyException: MSIS7070: The SAML request contained a NameIDPolicy that was not satisfied by the issued token. Requested NameIDPolicy: AllowCreate: True Format: urn:oasis:names:tc:SAML:2.0:nameid-format:persistent SPNameQualifier: . Actual NameID properties: null.
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolManager.Issue(HttpSamlRequestMessage httpSamlRequestMessage, SecurityTokenElement onBehalfOf, String sessionState, String relayState, String& newSamlSession, String& samlpAuthenticationProvider, Boolean isUrlTranslationNeeded, WrappedHttpListenerContext context, Boolean isKmsiRequested)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.RequestBearerToken(WrappedHttpListenerContext context, HttpSamlRequestMessage httpSamlRequest, SecurityTokenElement onBehalfOf, String relyingPartyIdentifier, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, String& samlpSessionState, String& samlpAuthenticationProvider)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSerializedToken(HttpSamlRequestMessage httpSamlRequest, WrappedHttpListenerContext context, String relyingPartyIdentifier, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSecurityToken(SamlSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
   at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.Process(ProtocolContext context)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

SAMLメッセージデコーダーの出力

# 3 - SAMLResponse via post binding, at 2016-09-28 18:45:14.920Z (UTC)
<samlp :Response ID="_5c2e83d2-dad5-45e8-ad6f-061dade744fd"
       Version="2.0"
       IssueInstant="2016-09-28T18:45:14.837Z"
       Destination="https://cenhelm/saml/sso"
       Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified"
       InResponseTo="BG_0658b1fe7ad38b90b836fda526fc1853bd76485b"
       xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
  <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://WODAN-KAVEH.ingi.local/adfs/services/trust</Issuer>
  <ds :Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:SignedInfo>
      <ds :CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
      <ds :SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
      <ds :Reference URI="#_5c2e83d2-dad5-45e8-ad6f-061dade744fd">
        <ds:Transforms>
          <ds :Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
          <ds :Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
        </ds:Transforms>
        <ds :DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
        <ds:DigestValue>g5s0YwnOGbEqRgTqeJDVQxgj16OBVKixtvoESNGODPk=</ds:DigestValue>
      </ds:Reference>
    </ds:SignedInfo>
    <ds:SignatureValue>RExxLxsgjwjbOlGST9lzrwGzj/WhvIvH4ZxP1YplnHNaXjGOKZQDrkuaW78EGdwjgoTKph5iBk1R21PLxHxIKx9DL/z/wpCDhOQzyfPTv39qo3OjEATwUakiukvL98y5AypdFtUSK7BzJvjN0TqgfpJpIWj6ritf0cGeSLl3SuGxlcWwrqcAgpxyIXL15rtQk6pGgIBszSGNeeN5kTKr+Z+kZu95uFF0M7yMbObYom2BXGA9KgOmGqnadCcw80nzI3g78E0I1ZWegmgmiBbnXIfDWuLDiblrLGOg3bJNZu4yflYH5JpjHQyWI9Hg05l3yT5dxOcFaij6XNnLi2XHkQ==</ds:SignatureValue>
    <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
      <ds:X509Data>
        <ds:X509Certificate>MIIC6DCCAdCgAwIBAgIQcVPohCxdOadDkqvGcnn2bTANBgkqhkiG9w0BAQsFADAwMS4wLAYDVQQDEyVBREZTIFNpZ25pbmcgLSBXT0RBTi1LQVZFSC5pbmdpLmxvY2FsMB4XDTE2MDkwNzE5MzExOFoXDTE3MDkwNzE5MzExOFowMDEuMCwGA1UEAxMlQURGUyBTaWduaW5nIC0gV09EQU4tS0FWRUguaW5naS5sb2NhbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJw7gnkL08KQLatfhG36r4Bi1yCl9cfpM8S70eXIZ2ZH+ViIJAWcmlSWa63YKmRrkHoZjviUxlC1r/TMZ6MZKwAA0zACYniTiApjhgYi3A9U7jhuvC6IZhWxKeopt0siOYw8Bbkp4XTVBe9P2apyOjpNYc1SMeerYHKqNkATnx9/EGJD8nTR0Tz13VXYNw4Aepok4jE/U3LH9z7PJ0ZVUXGOXJ4anE/5L4lqtfJEYitoc/E2pML4Sqy4cWI4T9AfQlbxw2HGiDZbDtICKOp7Mi6PKHCNFS6ruxAReKt6ggYwPz21Sf6/9cAuMrnR/vvsrd20ZCjYuFora71FyGq/+Q0CAwEAATANBgkqhkiG9w0BAQsFAAOCAQEATlkg3oo9odZTjS0c90DMGXxGXA3TYUWZ/glIXP42Sdhi67OOqj8FaB6OFfEXJTn3i/PHbDiFh/oT19SwvdoFchB+hfNLAdFRPU0EsGoioWa1RvSWfNG6CMzXrdluiuoXpWVewgWs53+FPFIX8ACJcVvdxlM6vJn473TjEJPgVKnR9RYKoosmWCxDG5/aWLc4UkUuIoHk1lbnJ1VHPDr/vE8fy4XxzcfjPcmw5xQvx0FWbEqBBewVfGZuOQtMSPdKGQqDa71iIq3tuyIqe4e9jLEbgxV5NDEV63yl8rkKk0HRDpS9jO5eatnUEX7fElrBXWBjapZ+6B55DY4JGlUbLA==</ds:X509Certificate>
      </ds:X509Data>
    </KeyInfo>
  </ds:Signature>
  <samlp:Status>
    <samlp :StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester">
      <samlp :StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy" />
    </samlp:StatusCode>
  </samlp:Status>
</samlp:Response>
RelayState
https://cenhelm/saml
# 2 - SAMLRequest via redirect binding, at 2016-09-28 18:45:14.797Z (UTC)
<samlp :AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
       xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
       ID="BG_0658b1fe7ad38b90b836fda526fc1853bd76485b"
       Version="2.0"
       IssueInstant="2016-09-28T18:45:01Z"
       Destination="https://wodan-kaveh.ingi.local/adfs/ls/"
       ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
       AssertionConsumerServiceURL="https://cenhelm/saml/sso">
  <saml:Issuer>https://cenhelm</saml:Issuer>
  <samlp :NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
         AllowCreate="true" />
</samlp:AuthnRequest>
RelayState
https://cenhelm/saml
# 1 - SAMLRequest via redirect binding, at 2016-09-28 18:45:01.643Z (UTC)
<samlp :AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
       xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
       ID="BG_0658b1fe7ad38b90b836fda526fc1853bd76485b"
       Version="2.0"
       IssueInstant="2016-09-28T18:45:01Z"
       Destination="https://wodan-kaveh.ingi.local/adfs/ls/"
       ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
       AssertionConsumerServiceURL="https://cenhelm/saml/sso">
  <saml:Issuer>https://cenhelm</saml:Issuer>
  <samlp :NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
         AllowCreate="true" />
</samlp:AuthnRequest>
RelayState
https://cenhelm/saml
SAML Message Decoder
CLEAR ALL
samladfs
1
David Dietrich

「永続的な名前識別子」のクレームルールを追加する必要があります。

  1. 証明書利用者信頼を選択し、カスタム発行変換ルールを作成して、一意のユーザー識別子クレームを作成します。
  2. 次に、永続的な識別子のクレームを名前識別子のクレームに変換します。

詳細なステップバイステップとルールの詳細、あなたはチェックすることができます ここ

3
Bifeng Dong - MSFT