I am experiencing challenges logging in to CRM from the Outlook client when the user does not reside in Active Directory.
Some of our CRM users do not have Active Directory credentials. Instead they log in to an IBM Websphere environment using LDAP credentials. We have configured CRM for IFD and have deployed Shibboleth Idp to act as the identity provider to ADFS/CRM for these users. Web single sign-on (passive federation) to CRM for these users works perfectly.
The Outlook client for CRM however uses ws-trust (active federation) for authentication and not passive federation the way the browser does. Unfortunately Shibboleth Idp does not support ws-trust so I need a different ws-trust security token service (STS) to enable our LDAP users to use the Outlook client.
I have tested a few different ws-trust STS servers (OpenAM, Thinktecture Identity Server V2.0) but to no avail. All of the documentation around claims-based authentication for CRM seem to center around web single sign-on and does not address active federation with the Outlook client. The only information I have managed to gather around this issue is specifying the HomeRealmUrl registry setting in the HKLM\SOFTWARE\Policies\Microsof\MSCRMClient key. Most of the blogs/forums that mention this seem to refer to specifying the active federation endpoint from another ADFS server fronting Active Directory. None I have found seem to have integrated a non-ADFS ws-trust STS.
I have tried specifying the HomeRealmUrl value but without any documentation as to types of bindings that the Outlook client expects from the STS it is hit and miss at best.
Has anyone successfully deployed a CRM IFD where users from a non-active directory ADFS claims provider can sign in to the CRM Outlook client? If so:
- Which STS did you use or did you build one yourself?
- What bindings did you use for the STS?
- Did you need any special ADFS configuration other than registering the STS as a claims provider?
