As a Microsoft Partner, Gold certified, and experienced Dynamics CRM ISV since v 1.0, we set out to integrate one of our CRM 4.0 projects into CRM 2011 Beta. We quickly stood up a single server system to get the developers started and would follow-up with IFD afterwards. Since IFD setup is different than it was for CRM 4.0, we had to also setup an AD FS 2.0 server.
Downloading AD FS 2.0 was straightforward and seemed to install and configure by the book. The problem we ran into was deciphering the documentation for CRM 2011 Beta and Claims based authentication and IFD configuration.
We managed to get fairly close to a working IFD solution. AD FS 2.0 appeared to be doing its job by allowing a login but upon redirecting to CRM we were presented with the ubiquitous error “Invalid User Authorization” which translated to the organization could not be identified - also depicted in the URL below.
A review of the CRM Trace log in its default location C:\Program Files\Microsoft Dynamics CRM\Trace revealed the following errors – trimmed for brevity:
[2010-10-24 22:42:28.546] Process: w3wp |Organization:00000000-0000-0000-0000-000000000000 |Thread: 3 |Category: Platform.Sdk |User: 00000000-0000-0000-0000-000000000000 |Level: Error | ServiceModelTraceRedirector.TraceData
[2010-10-24 22:42:28.725] Process: w3wp |Organization:00000000-0000-0000-0000-000000000000 |Thread: 16 |Category: Exception |User: 00000000-0000-0000-0000-000000000000 |Level: Error | CrmException..ctor
and this from the Application log in Event Viewer (also trimmed)
Log Name: Application
Source: ASP.NET 4.0.30319.0
Date: 10/24/2010 10:42:29 PM
Event ID: 1309
Task Category: Web Event
Event code: 3005
Event message: An unhandled exception has occurred.
Event time: 10/24/2010 10:42:29 PM
Event time (UTC): 10/25/2010 2:42:29 AM
Event ID: e89163e8f686404c960b18b0a357cca5
Event sequence: 5
Event occurrence: 1
Event detail code: 0
Application domain: /LM/W3SVC/1/ROOT-1-129324480343019563
Trust level: Full
Application Virtual Path: /
Application Path: C:\Program Files\Microsoft Dynamics CRM\CRMWeb\
Machine name: CRM2011B
Process ID: 4800
Process name: w3wp.exe
Account name: DEVDOMAIN\crm2011betasvc
Exception type: CrmException
Exception message: The current organization id could not be determined.
at System.Web.Compilation.BuildManager.CreateInstanceFromVirtualPath(VirtualPath virtualPath, Type requiredBaseType, HttpContext context, Boolean allowCrossApp)
at System.Web.UI.PageHandlerFactory.GetHandlerHelper(HttpContext context, String requestType, VirtualPath virtualPath, String physicalPath)
at System.Web.HttpApplication.MapHttpHandler(HttpContext context, String requestType, VirtualPath path, String pathTranslated, Boolean useAppConfig)
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)
The real clue here being the Organization and User data was null so no real attributes were being passed from AD FS to CRM so troubleshooting AD FS was a good starting point.
Searching the internet revealed clues here and there until we ran across a couple of posts in the Microsoft CRM 2011 Beta forum where Matios suggested using an LDAP Claims rule and his suggestion was reinforced by Zegor so we concluded his solution worked more than once and in different environments. We set out on a path of trying different permutations of LDAP claims rules to no avail.
We dialed up AD FS 2.0 Tracing by following this article on Diagnostics in AD FS:
When editing the Microsoft.IdentityServer.ServiceHost.Exe.Config file change the switch value from ‘Off’ to ‘Verbose’. These values are case SeNsiTiVE by the way because we received a flurry of errors when we tried setting the values to ‘verbose’ instead of ‘Verbose’ and restarting ADFS service.
In the meantime, we replied to the aforementioned forum post and asked for some detail on the LDAP claims rule – Patrick Verbeeten was in the thread and he replied very quickly, on a Saturday nonetheless. By this time we felt we were well versed in AD FS claim rules, at least, enough to know his response made sense, unfortunately it did not have immediate positive results.
Upon reviewing the AD FS 2.0 Tracing Debug Log:
LDAPAttributeStoreReader: No results were returned for LDAP query with filter ‘samAccountName=sbarr_engage2day.com’.
We found that the samAccountName attribute was not yielding results when the LDAP query was initiated against the Attribute Store (Active Directory). We tried to get more detail by running Process Monitor and Wireshark (my long time favorites for troubleshooting) but could not see a valid response; however, we did see the LDAP traffic between the AD FS server and the domain controller.
Finally, it dawned on me that the AD FS 2.0 service account must not have permissions to execute an LDAP query. Upon applying ‘List Contents’ permissions (actually dropping the service account into the Pre-Windows 2000 Compatible Group since it already had those permissions) the result was immediately positive. We were able to login successfully to the CRM 2011 organization on the first attempt following a restart of the ADFS service.
The LDAP rule that ultimately worked was as follows:
In Ad FS 2.0 | Trust Relationships | Claims Provider Trusts, right-click Active Directory, select Edit Claims Rules
Add Rule… |enter appropriate Claim rule name | Select attribute store Active Directory
Under Mapping of LDAP attributes to outgoing claim types: set the LDAP Attribute to User-Principal-Name and set the Outgoing Claim Type to UPN
The only necessary Relying Party Trust claim rule necessary from the IG is the Pass through rule for UPN.
The net result is that IFD works as advertised when using the undocumented LDAP claims rule. Don’t forget to modify the CRM web.config file <authentication strategy> element from “OnPremise” to “ServiceProviderLicenseAgreement” and restart IIS.
No related posts.