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?

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

Thanks. Thought I was under directory services.

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:

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.

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).

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:

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.

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.

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 9 hours 2 minutes ago