Microsoft Dynamics CRM and GP Skip to main content
https://support.okta.com/help/answers?id=906f0000000i0bgia0&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fanswers
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Andrew CliffAndrew Cliff 

Microsoft Dynamics CRM and GP

Is it possible to use Okta to sign into Microsoft Dynamics CRM and GP?
Corbett Merrill - AdminCorbett Merrill - Admin
Sorry, no direct answer here but...

I attempted this by configuring a generic SAML Okta app and then pointed the CRM 2016 Claims Based Auth Wizard to the Okta metadata but CRM always says "The federation metadata URL is not available".  I haven't been able to get past this.

Based on this article (https://support.onelogin.com/hc/en-us/articles/210131883-Configuring-SAML-for-Microsoft-Dynamics-CRM) from OneLogin (does this get me banned?) it makes it sound possible.  SAML is after all standards based.
Corbett Merrill - AdminCorbett Merrill - Admin
After lots of trial and error, it turns out this is possible.  CRM doesn't use SAMLP but WS-Fed and to accomplish this:
Create a new Okta app based on the "Template WS-Fed" with the following settings
-Web Application URL: https://crmserver.domain.com
-Realm: https://crmserver.domain.com
-ReplyToURL: https://crmserver.domain.com
-Name ID Format: Unspecified
-Audience: https://crmserver.domain.com
-Assertion Auth. Context: Integrated Windows Authentication
-Group Filter: NA (this is because CRM doesn't use groups so there is no sense sending them in the assertion)
-Username Attribute Statements: None
-Custom Attribute Statements: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn|appuser.userName|http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier (note: your CRM user names and Okta user names must be in the UPN format [ie. username@domain.com])
Once the Okta App is created get the Okta Metadata URL and download the Okta signing cert.
Use IIS generate a self signed cert.  This will be used for CRM assertion encryption.
Use the CRM Deployment Manager to Configure Claims Based Authentication
-Input the Metadata URL
-Select the self signed cert generated using IIS
At this point you would think things are good but I ran into an big issue.  The configuration wizard reads the metadata fine but doesn't automatically pull the Okta signing cert into the CRM configuration database.  This means the assertions generated from Okta aren't trusted.  When this happens you get the error "ID4175: The issuer of the security token was not recognized by the IssuerNameRegistry. To accept security tokens from this issuer, configure the IssuerNameRegistry to return a valid name for this issuer."

To combat this you need to use PowerShell to import the Okta cert.  The cert needs to be imported as a TrustedIssuer type, but for some reason the PS command will not allow that cert type.
Set-CrmCertificate : Source    : mscorlib
Method    : HandleReturnMessage
Date    : 2:22:44 PM
Time    : 6/2/2016
Error    : Message: TrustedIssuer is not supported settable Certificate Type through DWS.
ErrorCode: -2147220970
Stack Trace    :
Bummer!  So I used the following:
Set-CrmCertificate -DataFile C:\okta.cert -StoreName "My" -CertificateType "AppFabricIssuer" –StoreLocation “LocalMachine” –StoreFindType “FindBySubjectDistinguishedName”
Don't let the store location fool you, it isn't stored in the cert store but the cert content is actually stored in the CRM Config database.  Once the cert is imported then you can go into the MSCRM_CONFIG database and edit the new certificate entry in the Certificates table by changing the Type from AppFabricIssuer to TrustedIssuer.  There may be a better way of doing this that I'm not aware of.

Once all of this is setup, get Fiddler running and attempt some claims based authentication between Okta and Dynamics CRM.
Hugh KelleyHugh Kelley
Worked for me too.  The only part I'd add to Corbett's steps concerns the realm/entityID.   Our CRM deployment insisted on putting a trailing "/" on the entityID (as seen from its own FederationMetadata.xml file) so I had to add that same trailing "/" to the realm specified in Okta.

[APPURL]/FederationMetadata/2007-06/FederationMetadata.xml
<EntityDescriptor ID="........"    entityID="https://appname.domain.xyz/">


 
Douglas KrauseDouglas Krause
We are considering adding GP to our Okta install. Glad to hear it can be done. Can you share details on the GP environment [where hosted, etc] or other information to consider when planning this implementation?