I recently setup CRM 2015 and ADFS 3.0 (the version that comes on Server 2012 R2, aka ADFS 2.2) on new servers for a customer. Everything configured fine and initial tests proved successful when logging in with the domain admin account used to set everything up. However, I quickly found an issue when other users tried to access CRM via the external URL. At the ADFS login page, a user would enter his or her credentials as usual and try to login but rather than giving a 302 redirect back to CRM for access, it redirected back to the ADFS login page. This presented no errors on screen or in the CRM event viewer – it was as if I never tried logging in. If I purposefully entered invalid credentials, it provided the error regarding incorrect user ID or password so I knew authentication against AD was taking place successfully and that something was wrong with the passing of the token. Also of note was the fact that despite the external URL not working, all users were able to access CRM just fine using the internal (pass-through auth) URL.
Nothing appeared in the ADFS Admin event viewer logs but upon closer inspection, the Security log in the event viewer on the ADFS server was loading up with Audit Failure notifications – Event ID 4625. The failure reason indicated “Unknown user name or bad password” for the ADFS service account. As any logical person would assume, I figured the account was locked out, the password expired, or I entered invalid credentials during setup. Unfortunately, upon resetting the password in Active Directory, the audit failures persisted.
After some digging around, I uncovered that adding the ADFS service account to the Windows Authorization Access Group in Active Directory was the resolution. The members of this group have access to the computed tokenGroupsGlobalAndUniversal attribute on User objects. I added the account to the group, restarted the ADFS service, and all users were then able to access CRM via the external URL as expected!
UPDATE (1/27/16) - While adding the ADFS service account to the Windows Authorization Access Group fixed the issue for most users accessing CRM, it managed to rear its ugly head for a handful of users again. The fix this time was similar - I added the account to the Pre-Windows 2000 Compatible Access Group. Users in this group have read access over all users in the domain. Typically, the 'Everyone' group is present in here by default so this is not usually an issue but this customer in particular removed it. So to conclude, make sure group membership is set on both of these groups if you are experiencing the loop issue.
What a great article. If you work with such complicated systems as CRM you might probably be interested in writing
ReplyDeletedata room providers comparison . I suppose your followers will like the topic.
I have now experienced this issue as well and was happy to find this solution. Out of curiosity I've continued to research to find a concrete answer as to why this issue pops up, rather than being there from the onslaught of ADFS' installation. In my case, running Exchange 2013's setup.exe /PrepareAD, which adds the Exchange Servers group into the Windows Authorization Access Group, appears to be the trigger of this issue. However, I'm nearly positive that before doing this, the ADFS service account wasn't a member of the group. I will have to redo an ADFS setup in my lab to see whether or not that happens.
ReplyDeleteI've migrated tot ad fs on windows server 2019 and got this problem. Your solution adding the Windows Authorization group helped! Thanks!
ReplyDeleteI'm a bit late to the game but having had the same problem that drove me nuts... Here is my solution.
ReplyDeleteAfter enabling the trace log in event viewer :
- Start Event Viewer
- Right click on : Applications and Services Logs --> View --> Show Analytic and Debug Logs
- Right click on : Applications and Services Logs/AD FS Tracing/Debug --> Enable Log
I found an error event 153 with following description :
S4U Logon for user with upn 'john.smith@contoso.com' threw the following exception : 'The encryption type requested is not supported by KDC'
At this point it was easy... You google the error and the first site you find is an article for MS with a solution.
In short...
You open the properties of the service account used by your ADFS service.
You go on the "Account" tab
and you enable following options :
- This account supports Kerberos AES 128 bit encryption
- This account supports Kerberos AES 256 bit encryption
Knowing that I found that nowhere else... I post it here for others, so they don't get to the verge of insanity as I did.
This saved my day. MS Kudos Gage! :)
ReplyDelete