locked
ADFS SSO and SAML RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    We use a third party application that is currently using CAS for SSO. We want the application to use ADFS SSO.

    I followed tons of articles on the Internet on setting it up right because the vendor didn't have any documentation on how to make it work with ADFS. They support simple SAML authentication and need the attribute to be passed on as "NameID". The attribute to use from active directory is the sAMAccountName.

    So this was what was done:

    1. created a relying party trust with endpoint set to point to the vendor's saml link with binding set to "POST". SHA-1 was used.

    2. Created a issuance transform rule that used LDAP attribute "SAM-Account-Name" and outgoing claim type as "NameID".

    This doesn't work. The vendor says that they see saml connection from our end but the value being passed is NULL. A trace from fiddler shows
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:InvalidNameIDPolicy" />

    So basically, here is what we need:

    pass the samaccountname from active directory to their SAML service as "NameID". Can someone please advise on how exactly this can be done?

    Tuesday, September 1, 2015 9:59 PM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Got it to work...phew!

    The first rule was correct.
    The second rule was created as

    Incoming claim type: E-mail Address

    Incoming name ID format : unspecified

    Outgoing claim type: Name ID

    Outgoing name ID format: Email

    Not sure if the vendor did anything on their end. But this worked.

    • Marked as answer by HuckleberryFinn Wednesday, September 2, 2015 10:00 PM
    Wednesday, September 2, 2015 10:00 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi HuckleberryFinn,

    Thanks for your post.

     I suggest you refer to the ADFS forum to get professional support for ADFS related problems :

    Claims based access platform (CBA), code-named Geneva Forum

    https://social.msdn.microsoft.com/Forums/vstudio/en-us/home?forum=Geneva

    Best Regards,

    Mary Dong

    Please remember to mark the replies as answers if they help and unmark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, September 2, 2015 2:28 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Thanks. Thought I was under directory services.
    Wednesday, September 2, 2015 4:18 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    I've found SAML Tracer is an easier tool for this (vs fiddler).

    Anyway, in my case, I wanted to send these two attributes for a 3rd party trust. See the image here, which worked for me:


    Mike Crowley | MVP
    My Blog -- Baseline Technologies


    • Edited by Mike Crowley Wednesday, September 2, 2015 4:38 PM fixed hyperlink to saml tracer
    • Proposed as answer by Mike Crowley Wednesday, September 2, 2015 4:45 PM
    Wednesday, September 2, 2015 4:36 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks Mike. In our case, they want us to send the sAMAccountName as "NameID". The SAML in their application looks for "NameID" attribute.

    The email does not match the username for us.

    Wednesday, September 2, 2015 5:35 PM
  • Question
    Sign in to vote
    0
    Sign in to vote
    Yes, I was just using this as an example. the AD attribute is on the left and the xml attribute is on the right. Verify with SAML Tracer (or fiddler).


    Mike Crowley | MVP
    My Blog -- Baseline Technologies

    Wednesday, September 2, 2015 7:41 PM
  • Question
    Sign in to vote
    1
    Sign in to vote

    from the other thread:

    Thanks Mike. In our case, they want us to send the sAMAccountName as "NameID". The SAML in their application looks for "NameID" attribute. 

    The email does not match the username for us.

    so samaccountname goes on the left and nameid goes on the right.

    You should look at the XML itself to verify its not actually null. in some cases i've found the LDAP attribute name isn't the same name i was expecting (on the AD side)

    also, make sure your issuance rule is set properly. eg:


    Mike Crowley | MVP
    My Blog -- Baseline Technologies




    • Edited by Mike Crowley Wednesday, September 2, 2015 7:48 PM
    Wednesday, September 2, 2015 7:46 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    The application admin told us that they saw the SAML connection from their side but nothing was being passed over.

    Since you mention that the LDAP attribute listed could differ, where do I go and look for the XML file?

    The issuance authorization rule is set properly.

    Wednesday, September 2, 2015 8:30 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
     => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"), query = ";sAMAccountName;{0}", param = c.Value);

    I believe we are pulling the right attribute, that is, sAMAccountName.

    Wednesday, September 2, 2015 8:43 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Got it to work...phew!

    The first rule was correct.
    The second rule was created as

    Incoming claim type: E-mail Address

    Incoming name ID format : unspecified

    Outgoing claim type: Name ID

    Outgoing name ID format: Email

    Not sure if the vendor did anything on their end. But this worked.

    • Marked as answer by HuckleberryFinn Wednesday, September 2, 2015 10:00 PM
    Wednesday, September 2, 2015 10:00 PM