1

I am trying to set up ADFS authentication (Server 2012) to a Bomgar appliance. Both ADFS and Bomgar are running in VMware Workstation virtual machines. ADFS is acting as the IdP (located at https://wodan-kaveh.ingi.local), and Bomgar is the Relying Party (located at https://cenhelm). Everything is resolving in the Windows HOSTS right now as this is a demo environment.

I've imported the Relying Party metadata from Bomgar to ADFS and the FederationMetadata.xml from ADFS to Bomgar. Bomgar successfully refers the browser to the ADFS login page, I can successfully authenticate with my AD users there, and the browser is successfully referred back to Bomgar from the ADFS login page; however, at that point, I receive an authentication failure message from the Bomgar login form, ADFS logs Event ID 364, and the SAML Message Decoder for Chrome logs a StatusCode value of "urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy".

The ADFS error indicates that NameIDPolicy is not satisfied. Question 16403359 over on stackoverflow had an answer pointing out this line in ADFS event log: "Actual NameID properties: null."; however, the NameID in my ADFS Relying Party Trusts config is populated. I can see this under the "Identifiers" tab of the trust config for Bomgar.

Does anyone with ADFS experience know about this null NameID / InvalidNameIDPolicy problem?

ADFS Event ID 364

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 Message Decoder output

# 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

migrated from security.stackexchange.com Sep 28 '16 at 19:43

This question came from our site for information security professionals.

3

You need to add "Persistent name identifier" claim rules:

  1. Choose your Relying Party Trust and make a custom issuance transform rule to create unique user identifier claim.
  2. Then transform persistent identifier claim into Name Identifier claim.

Detail steps by step and rule detail, you can check here

  • I already had a Persistent Identifier rule set up; however, after reading the article you referenced, I adjusted it to use the "Incoming claim type" of "Windows account name" instead of "ID" (which is what I had before). That worked! Thanks for your help :) – David Dietrich Oct 3 '16 at 18:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.