locked
ADFS 2.0 Invalid Name ID Policy Help. RRS feed

  • Question

  • I have a relying party trust set up with a vendor using their metadata. I am redirected to the correct ADFS authentication page on my ADFS server, but am getting an InvalidNameIDPolicy error. 

    What I'm receiving:
    urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress

    So, when I look at my response, I'm getting:

    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Requester"> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy"

    I just need to send the user's email address back. I've tried mapping the outgoing claim type of email address to name ID and EmailAddress but neither seem to work. If I need to create a transform rule, I have no idea what it needs to be. From everything I've ready, if they sent nameid-format:unspecified, it would work. Any help is greatly appreciated. 


    Jeff Green MCSA/MCSE 2003, MCITP 2008

    Monday, April 1, 2019 8:46 PM

Answers

  • If you just use the first rule you will issue the mail address as NameID and it will look like this in the SAML Token:

    <Subject>
      <NameID>bill.gates@contoso.com</NameID>
      ...
    </Subject>

    Your Service Provider needs a "Format" which has to do with the SAML 2.0 Protocol standard when parsing your SAML Token.

    So your second rule adds this "Format" so that they can successfully parse your SAML Token:

    <Subject>
      <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">bill.gates@contoso.com</NameID>
      ...
    </Subject>

    Some SAML 2.0 Protocol stacks are simply more strict when it comes to this than others.

    Sometimes this "Format" is ignored/optional even though they list it/them in their Federation Metadata XML and sometimes it's strictly required or the Service Provider won't accept the SAML Token. I've come across both situations.

    My guess is that the original idea was that you could pass different data as NameID to the same Service Provider and by looking at the "Format"-parameter they could figure out what exactly you were sending and use it accordingly.

    Other formats are:

    • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
    • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    • urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
    • urn:oasis:names:tc:SAML:2.0:nameid-format:entity
    • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

    By using Fiddler and looking at the SAML Request (RST/Request for Security Token) you can see if they are requesting any of these formats or not.





    • Edited by MolokoVelocette Friday, April 12, 2019 9:24 AM
    • Marked as answer by SnG 2K Tuesday, April 23, 2019 1:57 AM
    Friday, April 12, 2019 9:10 AM

All replies

  • Ask the vendor what policy they need and we will help you crafting the rule you need to send them the proper information. It's quite straight forward once you know when they need.


    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Tuesday, April 2, 2019 2:57 PM
  • Please post your Claim Rules and the RST (SAML Request) from the vendor here.
    Wednesday, April 10, 2019 2:28 PM
  • Here is a little update. I set up two claim rules:

    Rule 1: LDAP Attribute: email, Oitgoing claim type: email

    Rule 2: Transform ruleIncoming claim type: E-Mail AddressOutgoing claim type: Name ID Outgoing Name ID format: Email Pass through all claim rules

    This now gives me a success status message when I look at the SAML response. I do get a message that says the email address wasn’t found in their database but I believe that’s going to be on their end, as I’m sending the correct address. I feel like everything is set up correctly on my end at this point but I’m curious why I need both of those rules. Would someone mind explaining that to me? Thank you for your help.


    Jeff Green MCITP 2008


    • Edited by SnG 2K Thursday, April 11, 2019 7:56 PM
    Thursday, April 11, 2019 7:52 PM
  • If you just use the first rule you will issue the mail address as NameID and it will look like this in the SAML Token:

    <Subject>
      <NameID>bill.gates@contoso.com</NameID>
      ...
    </Subject>

    Your Service Provider needs a "Format" which has to do with the SAML 2.0 Protocol standard when parsing your SAML Token.

    So your second rule adds this "Format" so that they can successfully parse your SAML Token:

    <Subject>
      <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">bill.gates@contoso.com</NameID>
      ...
    </Subject>

    Some SAML 2.0 Protocol stacks are simply more strict when it comes to this than others.

    Sometimes this "Format" is ignored/optional even though they list it/them in their Federation Metadata XML and sometimes it's strictly required or the Service Provider won't accept the SAML Token. I've come across both situations.

    My guess is that the original idea was that you could pass different data as NameID to the same Service Provider and by looking at the "Format"-parameter they could figure out what exactly you were sending and use it accordingly.

    Other formats are:

    • urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified
    • urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress
    • urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
    • urn:oasis:names:tc:SAML:2.0:nameid-format:entity
    • urn:oasis:names:tc:SAML:2.0:nameid-format:persistent

    By using Fiddler and looking at the SAML Request (RST/Request for Security Token) you can see if they are requesting any of these formats or not.





    • Edited by MolokoVelocette Friday, April 12, 2019 9:24 AM
    • Marked as answer by SnG 2K Tuesday, April 23, 2019 1:57 AM
    Friday, April 12, 2019 9:10 AM
  • Thank you for the clarification. So, they ended up having to change the Name ID format to unspecified on their end and everything started working as it was supposed to.

    Jeff Green MCSA/MCSE 2003, MCITP 2008

    Tuesday, April 23, 2019 1:57 AM