Microsoft Dynamics CRM and GP

l4jn3 (l4jn3)

Edited by varun.kavoori1.5210444522562532E12 September 5, 2018 at 1:29 AM

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.

Expand Post

l4jn3 likes this.

l4jn3 (l4jn3)
Edited by varun.kavoori1.5210444522562532E12 September 5, 2018 at 1:29 AM
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.
Expand Post
l4jn3 (l4jn3)
Edited by varun.kavoori1.5210444522562532E12 September 5, 2018 at 1:29 AM
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.
Expand Post
Hugh Kelley (Customer)
Edited by varun.kavoori1.5210444522562532E12 September 5, 2018 at 1:27 AM
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/">

Expand Post
7zhjh (7zhjh)
9 years ago
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?
Expand Post

Your Privacy

Your Privacy

Strictly Necessary Cookies

Strictly Necessary Cookies

Functional Cookies

Functional Cookies

Performance Cookies

Performance Cookies

Share or Sell of Personal Data

Share or Sell of Personal Data

Advertising Cookies

Your Privacy

Your Privacy

Strictly Necessary Cookies

Strictly Necessary Cookies

Functional Cookies

Functional Cookies

Performance Cookies

Performance Cookies

Share or Sell of Personal Data

Share or Sell of Personal Data

Advertising Cookies