Dynamics CRM integration with SiteMinder via ADFS

It's important that we integrate Microsoft products together with 3rd party identity providers. This allows us to execute on our mission to empower everyone on the planet to do more and achieve more. Understanding how we use federated identities to connect users with CRM services is critical to achieving this. This post will detail the requirements for connecting Dynamics CRM with CA Single Sign-On (SSO), formerly SiteMinder. We use ADFS as an intermediary, as CRM supports it out of the box.

To start things off, you first must configure Dynamics CRM in an IFD configuration. This enables CRM to authenticate users based on claims authentication. Follow one of the many configuration guides to configure CRM to authenticate to ADFS using Active Directory. CRM relies on ADFS using the WS-Federation protocol and supports SAML based tokens. A CRM deployment can only be attached to one method of user authentication. If we configure CRM to authenticate to ADFS, we can then enable ADFS to authenticate users from multiple identity providers. Your Relying Party Trust for CRM in ADFS should pass through PrimarySID and UPN, while issuing WindowsAccountName as a Name claim. For example:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]
=> issue(claim = c);
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
=> issue(claim = c);
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

Once you successfully authenticate users to CRM via ADFS using the Active Directory Claims Provider Trust, establish a partnership between ADFS and SiteMinder. This requires creating a Claims Provider Trust (manually) for SiteMinder in ADFS, specifying the service URL (SAML 2.0 endpoint), and importing the token-signing certificate. In this scenario, I used SSL connections on port 443 for both ADFS and SiteMinder endpoints, so I did not enable encryption of the SAML assertions. Your configuration may vary.

In my customer's configuration, SiteMinder issues a NameID claim (assertion). Add a custom claims rule to the SiteMinder claims provider trust to pass through the NameID claim:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"]
=> issue(Type = c.Type, Issuer = "ADFS", OriginalIssuer = "SiteMinder", Value = c.Value, ValueType = c.ValueType);

It's important to note that the predefined pass through rule in ADFS for NameID didn't work for me. It requires you to specify the NameID format, while the above custom rule just issues the claim with the same type that it comes in with. Now that we have a claim rule to pass through NameID from SiteMinder, open the claim rules for your CRM Relying Party Trust. There are only two claims that CRM requires. You must issue a UPN claim [http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn] and a Name claim [http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name]. PrimarySID is optional and not required. The UPN claim must be in the standard UPN format of 'user@domain.com'. For the Name claim however, CRM doesn't actually want the user's name (Display Name/Common Name). It is looking for a claim value in the format of 'DOMAIN\User', similar to WindowsAccountName or sAMAccountName. So again; the claim must be of type Name and the claim value must be in a 'DOMAIN\User' format.

Add a couple of custom rules to transform your NameID claim into something that CRM will accept. For example:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer != "AD AUTHORITY"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", Issuer = "ADFS", OriginalIssuer = "SiteMinder", Value = c.Value + "@contoso.com", ValueType = c.ValueType);
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer != "AD AUTHORITY"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name", Issuer = "ADFS", OriginalIssuer = "SiteMinder", Value = "CONTOSO\" + c.Value, ValueType = c.ValueType);

So in this example, if your NameID claim value was '1234567890', then you would be issued a UPN claim with a value of '1234567890@contoso.com'. You would also be issued a Name claim with a value of 'CONTOSO\1234567890'. To complete the configuration in CRM, login with an Administrator account via ADFS/AD and manage users. Add a new user with an account name of '1234567890@contoso.com', using the proper format for your environment. Clear your cache and/or open an InPrivate copy of your browser to test with. Once you visit your CRM Organization page, you should be redirected to ADFS and presented with Home Realm Discovery. Select your SiteMinder IDP and authenticate. After successfully authenticating, you should be redirected back to ADFS, and then CRM logging you in successfully.

Troubleshooting: Depending on your environment and configuration, you will likely need to review Event Logs in CRM, Event Logs in ADFS, logs for SiteMinder, and most importantly, use Fiddler to trace down issues with this configuration. One issue we faced was that after the partnership was established, ADFS would throw the following error:

System.Xml.XmlException: ID4262: The SAML NameIdentifier 'SAML2_IDP' is of format 'urn:oasis:names:tc:SAML:2.0:nameid-format:entity' and its value is not a valid URI.
   at Microsoft.IdentityModel.Tokens.Saml2.Saml2SecurityTokenHandler.ReadNameIDType(XmlReader reader)

This was solved by changing the NameID assertion in the SiteMinder partnership to issue type 'urn:oasis:names:tc:SAML:2.0:assertion' instead of type 'urn:oasis:names:tc:SAML:2.0:nameid-format:entity'. Another issue we encountered was that CRM specifies an AuthN context and passes the WAUTH parameter in the URL. This effectively asks ADFS to only use Windows Claims Authentication. To resolve this, we had to enable a setting that ignores the AuthN context in the SiteMinder partnership configuration. Without ignoring the AuthN context enabled, ADFS fails with an error that the IDP is not using the proper AuthN context. Of course this is by design for CRM, and ignoring it in SiteMinder was the final hurdle to making this configuration work. This integration was achieved using Dynamics CRM 2011, ADFS 3.0 (2012 R2), and SiteMinder.

Now what if you have both internal and external users, with internal users also having an Active Directory account? My customer synchronizes a custom attribute in Active Directory that matches the SiteMinder NameID value. The customer wanted internal users that authenticate via SiteMinder to appear to as if they had logged in via AD. Here's an example:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"), query = "siteMinderID={0};userPrincipalName,objectSid,sAMAccountName;CONTOSO\svc-adfs", param = c.Value);

The claim rule queries AD for the custom AD Attribute named siteMinderID. You have to pass the name of your ADFS service account to properly query a domain controller. For more information on custom ADFS/AD queries, review my other blog post: Querying attributes from Active Directory using ADFS with a 3rd party Identity Provider.

Dade Register

Microsoft Premier Field Engineer

Comments (3)

  1. Sham Bothe says:

    Hi Dade Register,

    I have query based on blog. My requirement is to use Siteminder as provider but DO NOT WANT partnership(Claim provider Trust) with ADFS. Can Siteminder alone would work for Dynamics CRM for Claim Based Authentication?



    1. Hello Sham,

      Based on my understanding and while testing with my customer, CRM requires a WS-Federation endpoint and does not support SAML 2.0. CRM also adds the WAUTH parameter, which would need to be ignored. While it may be possible to implement this with SiteMinder, this is not a scenario I tested.



  2. Romain says:


    Very useful post, thank you !

    Does Dynamics 365 App for mobiles and tablets will work in this scenario ?

    If yes, is there some prerequisites and constraints ?
    And if not, do you know the reason why ?

    Many thanks,

Skip to main content