Partager via

Possible causes of Authentications failures for federated users in Office 365.

  • Article

Here I’m assuming that we are using ADFS, for SSO to O365 services:

Below I have tried to list, a flow for Troubleshooting, authentication issues for a federated user in Azure AD / O365

1. Access https://login.microsoftonline.com/ and in the Login Form, enter the federated user’s login name like someone@example.com, once you hit tab to focus out of the login textbox, check if the statue of the page changes to redirecting and it redirect you to your STS / ADFS for sign-in.

 

    1. If no redirection happens and you get the option to enter password on the same page, then it means that Azure AD does not recognize the user or the domain of the user to be Federated.
      1. This is when you check if there is a federation trust between Azure AD / O365 and your STS/ADFS.

Run ‘Get-msoldomain’ cmdlet from Azure AD powershell, to find out if the domain is managed or federated. 

b.   If you see Redirection happening but it does NOT take you to your STS / ADFS for sign-in, then check if the STS / ADFS service name is resolving to the correct IP and if it can connect to that IP on TCP port 443.

If it shows federated, then get information about the federation trust by running the below commands.

Get-MsolFederationProperty -DomainName <domain>

Get-MsolDomainFederati``onSettings -DomainName <string>

**check the URI, URL and Certificate of the federation partner configured with AzureAD.

 

2. After you get redirected to ADFS, the browser may throws a certificate trust related error, and for some client/devices it may not let you establish a SSL session with ADFS.

- Esnure that ADFS service communication certificate presented to the client is the same and one configured on ADFS

- Ensure that ADFS service communication certificate is trusted by the client.

- If Non-SNI capable client are trying to establish a SSL session with ADFS/WAP 2-12 R2, it may fail. Please consider adding a Fallback entry on the ADFS/WAP servers to support non-SNI clients.

How to support non-SNI capable Clients with Web Application Proxy and AD FS 2012 R2
https://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx 

 

 3. “Unknown Auth method” or Errors stating AuthnCOntext not supported Errors at ADFS / STS level when you are redirected from Office 365.

This is most common when Office 365 and Azure AD redirects to the ADFS/STS with parameter enforcing a authentication method.

WSFED - uses WAUTH query string to force an preferred authentication method.

SAML2.0 - uses the following

<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>

**When the enforced Authentication method is sent with a wrong value or that authentication method is not supported on ADFS/ STS, it will give you an error before authenticating you.

4. After you get to your STS / ADFS and enter you credential but you are NOT able to authenticate, check the following:

a. 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.

 

b. 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:
https://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

 

c. 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 -F’ to check for duplicate SPN.

 

d. 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.

 

e. In a scenario, where you are using your email as the login ID on O365 and entering the same Email address when being redirected to ADFS for authenticate. The authentication may fail with NO_SUCH_USER error in Audit logs. For you to enable ADFS to find a user for authentication using an Attribute other than UPN or SAMaccountname, like Email, you need to configure it to support Alternate Logon ID.

Configuring Alternate Login ID

https://technet.microsoft.com/en-us/library/dn659436.aspx

 

f. 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

g. “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
https://technet.microsoft.com/en-us/library/hh852537.aspx

AD FS 2.0: Continuously Prompted for Credentials While Using Fiddler Web Debugger
https://social.technet.microsoft.com/wiki/contents/articles/1426.ad-fs-2-0-continuously-prompted-for-credentials-while-using-fiddler-web-debugger.aspx

 

h. 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
https://technet.microsoft.com/en-us/library/hh526961(v=ws.10).aspx -- for ADFS 2.0

https://technet.microsoft.com/en-in/library/dn592182.aspx -- for ADFS 2012 r2/WAP

 

Understanding Claim Rule Language in AD FS 2.0
https://social.technet.microsoft.com/wiki/contents/articles/4792.understanding-claim-rule-language-in-ad-fs-2-0.aspx

5. If you, are able to authenticate from Intranet when talking to the ADFS server directly but FAIL when accessing ADFS via ADFS proxy, check the following:

a. 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.

 

b. Check if the ADFS proxy Trust with the ADFS service is working fine. Re-running the proxy configuration may be a good option if you doubt that the proxy trust is broken.

 

 6. After your STS / ADFS issues a Token, Azure AD / O365 throws an error.

a. The Claims Issued by ADFS / STS in Token, should match the respective Attributes of the user in Azure AD.

In the Token for Azure AD / O365, we need the following Claims:

 

WSFED:

UPN = the value of this claim should match the userprincipalname of the users in Azure AD.

ImmutableID = the value of this claim should match the sourceAnchor or ImmutableID of the user in Azure AD.

To get User attribute value in Azure AD, run Get-MsolUser –UserPrincipalName <UPN>

 

SAML 2.0:

IDPEmail = the value of this claim should match the userprincipalname of the users in Azure AD.

NAMEID = the value of this claim should match the sourceAnchor or ImmutableID of the user in Azure AD.

 

Use a SAML 2.0 identity provider to implement single sign-on

https://technet.microsoft.com/en-us/library/dn641269.aspx

 

Examples:

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]”

 

It might also be that you are using AADsync to sync ‘MAIL as UPN’ and ‘EMPID as SourceAnchor’, but the Relying Party claim rules at ADFS level have not been updated to send ‘MAIL as UPN’ and ‘EMPID as ImmutableID’

 

b. Token signing certificate mismatch between ADFS and Office 365.

This is one of the most common 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 may 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
https://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc

Verify and manage single sign-on with AD FS
https://technet.microsoft.com/en-us/library/jj151809.aspx

 

c.      “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
https://blogs.technet.com/b/abizerh/archive/2013/02/06/supportmultipledomain-switch-when-managing-sso-to-office-365.aspx

 

d. Ensure Token Encryption is NOT being used by ADFS or STS when issuing a Token to AzureAD or O365.

 

7. 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.

 

8. Ensure that Secure Hash Algorithm configured on the Relying Party Trust for O365 is set to SHA1

When the trust between the STS/ADFS and AzureAD/O365 is using SAML 2.0 protocol, the Secure Hash Algorithm configured for digital signature should be SHA1.

6. 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"
https://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
https://support.microsoft.com/kb/2461628/EN-US

 

ADFS 2.0 troubleshooter

 

 

Regard

Abizer

Comments

  • Anonymous
    January 01, 2003
    This is awesome !!! Extensive list of steps and in a sequential order. Goes into my top of bookmarks. Thanks a ton for putting them altogether :)

  • Anonymous
    April 16, 2015
    This is really very helpful steps. Thanks a lot!

  • Anonymous
    June 02, 2015
    Thanks

  • Anonymous
    June 11, 2015
    The comment has been removed

  • Anonymous
    November 30, 2015
    Interesting Question: With ADFS redirections, has it ever happen by chance that a user is misdirected and accesses a completely different mailbox within the organization? For example: A visits o365 portal and is redirected to adfs, validates with adfs with A's credential, but instead is redirected to B's mailbox/portal?