Here I’m assuming that we are using ADFS 2.0, for SSO to O365 services:
1. Active Directory replication issue
If AD replication is broken, changes made to user/group may not be in sync across DCs. Between DCs, we may have password/upn/groupmembersip/proxyaddress mismatch that will affect the ADFS response (authentication and claims), as it may go to different DCs for Authentication and LDAP query.
One should start looking at the DCs in the same site as ADFS, probably a ‘Repadmin /showreps’ or a ‘DCdiag /v’ should tell if there is a problem on the DCs, ADFS is most likely to contact.
We can also collect AD replication summary to ensure that AD changes are getting replicated across to all DCs correctly. I have found “repadmin /showrepl * /csv > showrepl.csv” output to be helpful.
2. Account locked out or disabled in Active Directory.
When getting authenticated via ADFS, the end user is not going to get an error stating that the account is locked or disabled.
With the ADFS auditing or Audit logon events enabled – we should be able to find if the authentication failed due to incorrect password, account disabled /locked etc.
Enable ADFS and Logon auditing on the ADFS servers.
1. Use local or domain policy to enable Success and failure for
o Computer configuration\Windows Settings\Security setting\Local Policy\Audit Policy
- Audit logon event
- Audit Object Access
2. Disable the following policy
o Computer configuration\Windows Settings\Security setting\Local Policy\Security Option – “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings.” – Disabled
If you want to configure this via advanced auditing, then follow the steps in the link below:
http://technet.microsoft.com/en-us/library/adfs2-troubleshooting-configuring-computers(v=WS.10).aspx#bkmk_ConfigureAuditing
3. Configure ADFS for auditing:
o Open the AD FS 2.0 Management snap-in.
To open the AD FS 2.0 Management snap-in, click Start, point to Programs, point to Administrative Tools, and then click AD FS 2.0 Management.
o In the Actions pane, click Edit Federation Service Properties.
o In the Federation Service Properties dialog box, click the Events tab.
o Select the Success audits and Failure audits check boxes
4. Run ‘Gpupdate /force’ on the server
3. SPN registered incorrectly
Duplicate SPN or SPN registered under the an account other than the ADFS service account.
Ensure that SPN HOST/ADFSservicename is added under the Service account running the ADFS service, in an ADFS Farm setup. For ADFS standalone setup, where the service is running under the ‘Network Service’, the SPN need to be under the server computer account, hosting ADFS.
Ensure that there are not Duplicate SPNs for the ADFS service, as it may cause intermittent authentication failure with ADFS.
Use ‘SETSPN –L serviceaccount’ to list the SPN,
‘SETSPN –A HOST/ADFSservicename serviceaccount’ to Add the SPN
and ‘SETSPN –X’ to check for duplicate SPN.
4. Time sync issue on ADFS server and ADFS proxy
Ensure that the time on the ADFS server and the proxy is in sync, when the time on ADFS server is off by more than 5 minutes, from that on the DCs, we get authentication failures. When the time on ADFS proxy is off sync as compared to ADFS, the proxy trust would get affected and broken, which will start failing the request coming via the ADFS proxy.
5. Duplicate UPNs in AD.
One time I came across an issue where we were able to authenticate via ADFS when using SAMAccountName but failed when using UPN. We eventually found that users were failing to authenticate using UPN because the AD had 2 users with the same UPN. It’s possible to end up with 2 users with the same UPN when users are added and modified using scripting, ADSIedit etc.
In the above scenario, when using UPN the user was getting authenticated against the duplicate user, hence the credential supplied were not getting validated.
You can use queries like below to check if there are multiple objects in AD with same values for an attribute.
“Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN“
Make sure that the UPN on the duplicate user is renamed, so that authentication request with the UPN get validated against the correct Objects.
6. UPN mismatch between Office 365 and On-premise
For a federated user to get authenticated to O365 via a Token from ADFS, we need to ensure that the UPN of the user in the Token issued by ADFS, should be the same as the logon name for the user in O365.
One common cause leading to this issue is when the UPN of a synced user is changed in AD without updating the online directory. Here one can either correct the User’s UPN in AD, to match the related user’s logon name or change the Logon name of the related user in the Online directory, using cmdlet - “Set-MsolUserPrincipalName -UserPrincipalName [ExistingUPN] -NewUserPrincipalName [DomainUPN-AD]”
7. Token signing certificate mismatch between ADFS and Office 365.
This is one of the most command issues. ADFS uses the Token signing certificate to sign the Token sent to the user or application. The trust between the ADFS and O365 is a federated trust based on this token signing certificate, i.e. Office 365 verifies that the Token received is signed using a token-signing certificate of the claim provider (ADFS service) it trust.
Now when the Token signing certificate on the ADFS is changed as a result of Auto Certificate Rollover or Admins intervention (after or before certificate expiry), then the details of the new certificate needs to be updated on the O365 tenant for the federated domain, which does not happen automatically and requires Admin intervention.
While in a broken state when the Primary Token signing certificate on the ADFS is different than what O365 knows about, the Token issued by ADFS is not trusted by O365 and hence the federated user is not allowed to logon.
We can use ‘Get-MsolFederationProperty -DomainName <domain>’ to dump the federation property on ADFS and O365. Here you can compare the TokenSigningCertificate thumbprint, to check if O365 tenant configuration for your federated domain is in sync with ADFS. If you find a mismatch in the Token-Signing certificate configuration, use the following command to update it, “Update-MsolFederatedDomain -DomainName <domain> -SupportMultipleDomain”
You can also run the below tool to schedule a task on the ADFS server that will monitor for the Auto-certificate rollover, of the Token signing certificate and update O365 tenant automatically.
Microsoft Office 365 Federation Metadata Update Automation Installation Tool
http://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc
Verify and manage single sign-on with AD FS
http://technet.microsoft.com/en-us/library/jj151809.aspx
8. ADFS proxy trust with ADFS service, might be BROKEN.
During the ADFS proxy configuration wizard, we provide a domain user account to authenticate with ADFS service and establish Trust between ADFS service and ADFS proxy. Later, the AD FS proxy server periodically renews the proxy trust token with the AD FS Federation Service to maintain AD FS proxy server in a working state. By default AD FS proxy server tries to renew proxy trust token every 4 hours.
For a number of reason, the ADFS proxy trust may get broken, like, Time sync issues, Problem with ADFS server, connectivity issues with ADFS service etc. When this happens you should see more errors (mainly 364) under the ADFS 2.0 > Admin event log. In this scenario, you will be able to authenticate with ADFS, bypassing the proxy.
Quick method to reset the ADFS proxy trust with backend is by re-running the ADFS proxy configuration wizard. If you see the event 391 followed by 245 then we are good on the proxy.
Troubleshooting federation server proxy problems with AD FS 2.0
http://technet.microsoft.com/en-us/library/adfs2-troubleshooting-federation-server-proxy-problems%28WS.10%29.aspx
9. Issuance Authorization claims rules in RP, denying access to user.
On the ADFS Relying party Trust, you can configure the Issuance Authorization rules that can be used to control whether an authenticated user should be issued a token for an Relying Party. We can use the claims issued to this user to make that decision like DENY access to a user if he is a part of a group (group being pulled up as a claim).
If certain federated user are unable to get through via ADFS, you may want to check the “Issuance Authorization rules” for the Office 365 RP and check if it has ‘PERMIT All’. If not, go through the custom authorization rules to check if the condition in that rule will evaluate true for the affected user.
Limiting Access to Office 365 Services Based on the Location of the Client
http://technet.microsoft.com/en-us/library/hh526961(v=ws.10).aspx
Understanding Claim Rule Language in AD FS 2.0
http://social.technet.microsoft.com/wiki/contents/articles/4792.understanding-claim-rule-language-in-ad-fs-2-0.aspx
10. “Issuance Transform claim” rules for the Office 365 RP not configured correctly, in a scenarios where you have multiple TLD (Top level domain). You might have issues login in if ‘Supportmultipledomain’ switch was not used when creating and updating RP trust with O365
SupportMultipleDomain switch, when managing SSO to Office 365
http://blogs.technet.com/b/abizerh/archive/2013/02/06/supportmultipledomain-switch-when-managing-sso-to-office-365.aspx
11. Stale cached credentials in Windows Credential Manager
At times when login in from a workstation to the portal or using outlook, when being prompted for credentials, we might have selected save credentials/password, which in turn may have saved the credentials for the target (O365 or ADFS service), in the Windows Credentials manager (Control Panel\User Accounts\Credential Manager). This should help prevent credentials prompt for some time, but may cause a problem after the user password has changed and the credentials manager is not updated. Then you always end up sending the stale credentials to the ADFS service and fail to authenticate.
Removing or updating the cached credentials, in Windows Credential Manager may help.
12. Connectivity issues, when connecting via firewall/reverse proxy > ADFS proxy > ADFS service
We might not be able to authenticate a federated user if we cannot reach the ADFS proxy or ADFS server via the ADFS proxy. Might be an issue with the external firewall not routing traffic to the ADFS proxy from the Internet. Might be the load balancer managing traffic to the ADFS proxy servers or ADFS service.
Communication issue for some time between the ADFS proxy and ADFS service may have caused the ADFS proxy trust renewals to fail, breaking the Trust. Rerunning of the ADFS proxy configuration may help in this case
It could also be a problem with DNS name resolution for ADFS service
13. ADFS service account does not have READ access to on the ADFS token signing certificate’s private key.
a. When you add a new Token-Signing certificate, you receive a warning reading: "Ensure that the private key for the chosen certificate is accessible to the service account for this Federation Service on each server in the farm":
b. Click Start, Run, type MMC.exe, and press Enter
c. Click File, Add/Remove Snap-in
d. Double-click Certificates
e. Select Computer account and click Next
f. Select Local computer and click Finish
g. Expand Certificates (Local Computer), expand Personal, and select Certificates
h. Right-click your new Token-Signing certificate, select All Tasks, and select Manage Private Keys
i. Add Read access for your AD FS 2.0 service account and click OK
j. Close the Certificates MMC
14. “Extended Protection” for Windows Authentication is enabled for ADFS/LS – may cause issues with specific browsers
At times you may see ADFS repeatedly prompting for credentials, this could be related to “Extended protection” that is enabled for Windows Authentication for the ADFS/LS application, in IIS
When Extended Protection for Authentication is enabled, authentication requests are bound to both the Service Principal Names (SPN) of the server to which the client tries to connect and to the outer Transport Layer Security (TLS) channel over which Integrated Windows Authentication happens. Extended protection enhances the existing Windows Authentication functionality to mitigate authentication relay or "man in the middle" attacks. Certain browsers/fiddler cannot work with “Extended protection”, it would throw repeated prompts followed by access denied. Disabling “Extended protection” helps is such scenario.
Browser Issues with Extended Protection for Authentication
http://technet.microsoft.com/en-us/library/hh852537.aspx
AD FS 2.0: Continuously Prompted for Credentials While Using Fiddler Web Debugger
http://social.technet.microsoft.com/wiki/contents/articles/1426.ad-fs-2-0-continuously-prompted-for-credentials-while-using-fiddler-web-debugger.aspx
15. Lastly if none of the above causes are true, then create a support case with Microsoft and ask them to check if the User account shows consistent under the O365 tenant.
More info
Error message from AD FS 2.0 when a federated user signs in to Office 365: "There was a problem accessing the site"
http://support.microsoft.com/kb/2383983/EN-US
A federated user is repeatedly prompted for credentials when he or she connects to the AD FS 2.0 service endpoint during Office 365 sign-in
http://support.microsoft.com/kb/2461628/EN-US
Regards
Abizer