Troubleshoot AD FS issues in Azure Active Directory and Office

365
This article discusses workflow troubleshooting for authentication issues for
federated users in Azure Active Directory or Office 365.

Symptoms

Federated users cannot log on to Office 365 or Microsoft Azure even

though managed cloud-only users who have a domainxx.onmicrosoft.com UPN
suffix can log on without a problem.

Redirection to Active Directory Federation Services (AD FS) or STS does

not occur for a federated user. Or, a Page cannot be displayed error is
triggered.

You receive a certificate-related warning on a browser when you try to

authenticate with AD FS. This states that certificate validation fails or that the
certificate is not trusted.

"Unknown Auth method error or errors stating that AuthnContext is

not supported. Also, errors at the AD FS or STS level when you are redirected
from Office 365.

AD FS throws an Access is Denied error.

AD FS throws an error stating that there's a problem accessing the site;

this includes a reference ID number.

The user is repeatedly prompted for credentials at the AD FS level.

Federated users cannot authenticate from an external network or when

they use an application that takes the external network route (Outlook, for
example).

Federated users cannot log on after a token-signing certificate is

changed on AD FS.

A "Sorry, but we're having trouble signing you in" error is triggered
when a federated user signs in to Office 365 in Microsoft Azure. This error
includes error codes such as 8004786C, 80041034, 80041317, 80043431,
80048163, 80045C06, 8004789A, or BAD request.

Troubleshooting workflow

1. Access https://login.microsoftonline.com, and then enter the federated

users login name (someone@example.com). After you press Tab to remove
the focus from the login box, check whether the status of the page changes to
 "Redirecting" and then you're redirected to your Active Directory Federation
Service (AD FS) for sign-in.

When redirection occurs, you see the following page:

a. If no redirection occurs and you are prompted to enter a

password on the same page, this means that Azure Active Directory (AD) or
Office 365 does not recognize the user or the domain of the user to be
federated. To check whether there's a federation trust between Azure AD or
Office 365 and your AD FS server, run the Get-msoldomain cmdlet from Azure
AD PowerShell. If a domain is federated, its authentication property will be
displayed as Federated, as in the following screen shot:

b. If redirection occurs but you are not redirected to your AD FS

server for sign-in, check whether the AD FS service name resolves to the correct
IP and whether it can connect to that IP on TCP port 443.

If the domain is displayed as "Federated," obtain information about the

federation trust by running the following commands:

Get-MsolFederationProperty -DomainName <domain>

Get-MsolDomainFederationSettings -DomainName <domain>

Check the URI, URL, and certificate of the federation partner that's configured
by Office 365 or Azure AD.
2. After you are redirected to AD FS, the browser may throws a certificate
trust-related error, and for some clients and devices it may not let you establish
an SSL session with AD FS. To resolve this issue, follow these steps:

a. Make sure that the AD FS service communication certificate

that's presented to the client is the same one that's configured on AD FS.

Ideally, the AD FS service communication certificate should be the same as the

SSL certificate that's presented to the client when it tries to establish an SSL
tunnel with the AD FS service.

In AD FS 2.0:

Bind the certificate to IIS->default first site.

Use the AD FS snap-in to add the same certificate as the

service communication certificate.

In AD FS 2012 R2:

Use the AD FS snap-in or the Add-

adfscertificate command to add a service communication certificate.

Use the Set-adfssslcertificate command to set the same

certificate for SSL binding.

b. Make sure that AD FS service communication certificate is

trusted by the client.
c. If non-SNIcapable clients are trying to establish an SSL session
with AD FS or WAP 2-12 R2, the attempt may fail. In this case, consider adding a
Fallback entry on the AD FS or WAP servers to support non-SNI clients. For more
information, see the following blog post:

How to support non-SNI capable clients with Web Application Proxy and AD FS
2012 R2

3. You may encounter an "Unknown Auth method error or errors stating

that AuthnContext is not supported at the AD FS or STS level when you are
redirected from Office 365. This is most common when Office 365 and Azure AD
redirects to the AD FS or STS by using a parameter that enforces an
authentication method. To enforce an authentication method, use one of the
following methods:

a. For WS-Federation, use a WAUTH query string to force a

preferred authentication method.

b. For SAML2.0, use the following:

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

4. When the enforced authentication method is sent with an incorrect

value, or if that authentication method is not supported on AD FS or STS, you
receive an error message before you are authenticated.

The following table shows the authentication type URIs that are recognized by
AD FS for WS-Federation passive authentication.

Method of authentication wanted wauth URI

User name and password authentication urn:oasis:names:tc:SAML:1.0:am:password

SSL client authentication urn:ietf:rfc:2246

Windows integrated authentication urn:federation:authentication:windows

5.
Supported SAML authentication context classes

Authentication method Authentication context class URI

 User name and password urn:oasis:names:tc:SAML:2.0:ac:classes:Password

Password protected transport urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtecte

Transport Layer Security (TLS) client urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient

X.509 certificate urn:oasis:names:tc:SAML:2.0:ac:classes:X509

Integrated Windows authentication urn:federation:authentication:windows

Kerberos urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos

6.
To make sure that the authentication method is supported at AD FS level, check
the following.

AD FS 2.0

Under /adfs/ls/web.config, make sure that the entry for the authentication
type is present.

<microsoft.identityServer.web>
<localAuthenticationTypes>
<add name="Forms" page="FormsSignIn.aspx" />
<add name="Integrated" page="auth/integrated/" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>

AD FS 2.0: How to change the local authentication type

AD FS 2012 R2

Under AD FS Management, click Authentication Policies in the AD FS snap-

in.

In the Primary Authentication section, click Edit next to Global Settings.

You can also right-click Authentication Policies and then select Edit Global
Primary Authentication. Or, in the Actions pane, select Edit Global Primary
Authentication.

In the Edit Global Authentication Policy window, on the Primary tab, you
can configure settings as part of the global authentication policy. For example,
for primary authentication, you can select available authentication methods
under Extranet and Intranet.

**Make sure that the required authentication method check box is selected.
 If you get to your AD FS and enter you credentials but you
cannot be authenticated, check for the following issues.

a. Active Directory replication issue

If AD replication is broken, changes made to the user or group may not be

synced across domain controllers. Between domain controllers, there may be a
password, UPN, GroupMembership, or Proxyaddress mismatch that affects
the AD FS response (authentication and claims). You should start looking at the
domain controllers on the same site as AD FS. Running a repadmin
/showreps or a DCdiag /v command should reveal whether there's a problem
on the domain controllers that AD FS is most likely to contact.

You can also collect an AD replication summary to make sure that AD changes
are being replicated correctly across all domain controllers. The repadmin
/showrepl * /csv > showrepl.csv output is helpful for checking the replication
status. For more information, see Troubleshooting Active Directory replication
problems.

b. Account locked out or disabled in Active Directory

When an end-user is authenticated through AD FS, he or she will not receive an

error message stating that the account is locked or disabled. From AD FS and
Logon auditing, you should be able to determine whether authentication failed
because of an incorrect password, whether the account is disabled or locked,
and so forth.

To enable AD FS and Logon auditing on the AD FS servers, follow these steps:

Use local or domain policy to enable success and failure for

the following policies:

Audit logon event, located in Computer

configuration\Windows Settings\Security setting\Local Policy\Audit Policy"

Audit Object Access, located in Computer

configuration\Windows Settings\Security setting\Local Policy\Audit Policy"
 Disable the following policy:

Audit: Force audit policy subcategory settings (Windows Vista or

later) to override audit policy category settings

This policy is located in Computer configuration\Windows Settings\Security

setting\Local Policy\Security Option.

If you want to configure this by using advanced auditing, click here.

Configure AD FS for auditing:

Open the AD FS 2.0 Management snap-in.

In the Actions pane, click Edit Federation Service

Properties.

In the Federation Service Properties dialog box,

click the Events tab.

Select the Success audits and Failure

audits check boxes.
 Run GPupdate /force on the server.

2. Service Principal Name (SPN) is registered incorrectly

There may be duplicate SPNs or an SPN that's registered under an account other
than the AD FS service account. For an AD FS Farm setup, make sure that SPN
HOST/AD FSservicename is added under the service account that's running
the AD FS service. For an AD FS stand-alone setup, where the service is running
under Network Service, the SPN must be under the server computer account
that's hosting AD FS.
 Make sure that there are not duplicate SPNs for the AD FS service, as this may
cause intermittent authentication failures with AD FS. To list the SPNs,
run SETSPN L <ServiceAccount>.

Run SETSPN A HOST/AD FSservicename ServiceAccount to add the SPN.

Run SETSPN X -F to check for duplicate SPNs.

3. Duplicate UPNs in Active Directory

A user may be able to authenticate through AD FS when they're

using SAMAccountName but be unable to authenticate when using UPN. In this
scenario, Active Directory may contain two users who have the same UPN. Its
possible to end up with two users who have the same UPN when users are added
and modified through scripting (ADSIedit, for example).

When UPN is used for authentication in this scenario, the user is authenticated
against the duplicate user. Therefore, the credentials that are provided are not
validated.
 You can use queries like the following to check whether there are multiple
objects in AD that have the same values for an attribute:

Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN

Make sure that the UPN on the duplicate user is renamed, so that the
authentication request with the UPN is validated against the correct objects.

4. In a scenario, where you are using your email address as the login ID in Office
365, and you enter the same email address when you are redirected to AD FS for
authentication, authentication may fail with a "NO_SUCH_USER" error in the
Audit logs. To enable AD FS to find a user for authentication by using an attribute
other than UPN or SAMaccountname, you must configure AD FS to support an
alternate login ID. For more information, see Configuring alternate login ID.

On AD FS 2012 R2

a. Install Update 2919355.

b. Update the AD FS configuration by running the following PowerShell cmdlet

on any of the federation servers in your farm (if you have a WID farm, you
must run this command on the primary AD FS server in your farm):

Set-AdfsClaimsProviderTrust -TargetIdentifier "AD AUTHORITY"

-AlternateLoginID <attribute> -LookupForests <forest domain>

NoteAlternateLoginID is the LDAP name of the attribute that you want to

use for login. And LookupForests is the list of forests DNS entries that your
users belong to.

To enable the alternate login ID feature, you must configure both

the AlternateLoginID and LookupForests parameters with a non-null,
valid value.

5. The AD FS service account does not have read access to on the AD FS token
that's signing the certificates private key. To add this permission, follow these
steps:

a. When you add a new Token-Signing certificate, you receive the following
warning: "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, click Run, type mmc.exe, and then press Enter.
 c. Click File, and then click Add/Remove Snap-in.

d. Double-click Certificates.

e. Select the computer account in question, and then click Next.

f. Select Local computer, and click Finish.

g. Expand Certificates (Local Computer), expand Personal, and then

select Certificates.

h. Right-click your new token-signing certificate, select All Tasks, and then
select Manage Private Keys.

i. Add Read access for your AD FS 2.0 service account, and then click OK.

j. Close the Certificates MMC.

6. The Extended Protection option for Windows Authentication is enabled for

the AD FS or LS virtual directory. This may cause issues with specific browsers.
Sometimes you may see AD FS repeatedly prompting for credentials, and this
might be related to the Extended protection setting that's enabled for
Windows Authentication for the AD FS or LS application in IIS.
 When Extended Protection for authentication is enabled, authentication
requests are bound to both the Service Principal Names (SPNs) of the server to
which the client tries to connect and to the outer Transport Layer Security (TLS)
channel over which Integrated Windows Authentication occurs. Extended
protection enhances the existing Windows Authentication functionality to
mitigate authentication relays or "man in the middle" attacks. However, certain
browsers do not work with the Extended protection setting; instead they
repeatedly prompt for credentials and then deny access. Disabling Extended
protection helps is this scenario.

For more information, see AD FS 2.0: Continuously prompted for credentials

while using Fiddler web debugger.

For AD FS 2012 R2

Run the following cmdlet to disable Extendedprotection:

Set-ADFSProperties ExtendedProtectionTokenCheck None

7. Issuance Authorization rules in the Relying Party (RP) trust may deny access
to users. On the AD FS Relying Party trust, you can configure the Issuance
Authorization rules that control whether an authenticated user should be issued
a token for a Relying Party. Administrators can use the claims that are issued to
decide whether to deny access to a user who's a member of a group that's
pulled up as a claim.

If certain federated users cannot authenticate through AD FS, you may want to
check the Issuance Authorization rules for the Office 365 RP and see whether
the Permit Access to All Users rule is configured.
 If this rule is not configure, peruse the custom authorization rules to check
whether the condition in that rule evaluates "true" for the affected user. For
more information, see the following resources:

Understanding claim rule language in AD FS 2.0

Configuring client access policies

Limiting access to Office 365 services based on the location of the client

If you can authenticate from an intranet when you access the AD FS server
directly, but you cannot authenticate when you access AD FS through an AD
FS proxy, check for the following issues:

a. Time sync issue on AD FS server and AD FS proxy

Make sure that the time on the AD FS server and the time on the proxy are in
sync. When the time on the AD FS server is off by more than five minutes from
the time on the domain controllers, authentication failures occur. When the time
on AD FS proxy is not synced with AD FS, the proxy trust is affected and broken.
Therefore, a request that comes through the AD FS proxy fails.
b. Check whether the AD FS proxy Trust with the AD FS service is working
correctly. Rerun the proxy configuration if you suspect that the proxy trust is
broken.

b. After your AD FS issues a token, Azure AD or Office 365 throws

an error. In this situation, check for the following issues:

The claims that are issued by AD FS in token should match

the respective attributes of the user in Azure AD. In the token for Azure AD or
Office 365, the following claims are required.

WSFED:
UPN: The value of this claim should match the UPN 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 the User attribute value in Azure AD, run the following command
line: Get-MsolUser UserPrincipalName <UPN>

SAML 2.0:
IDPEmail: The value of this claim should match the user principal name of the
users in Azure AD.
NAMEID: The value of this claim should match the sourceAnchor or ImmutableID
of the user in Azure AD.

For more information, see Use a SAML 2.0 identity provider to implement single
sign-on.

Examples:
This issue can occur when the UPN of a synced user is changed in AD but
without updating the online directory. In this scenario, you can either correct the
users UPN in AD (to match the related users logon name) or run the following
cmdlet to change the logon name of the related user in the Online directory:

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 the AD FS level have not
been updated to send MAIL as UPN and EMPID as ImmutableID.

There's a token-signing certificate mismatch between AD

FS and Office 365.

This is one of the most common issues. AD FS uses the token-signing certificate
to sign the token that's sent to the user or application. The trust between the AD
FS and Office 365 is a federated trust that's based on this token-signing
certificate (for example, Office 365 verifies that the token received is signed by
using a token-signing certificate of the claim provider [the AD FS service] that it
trusts).
 However, if the token-signing certificate on the AD FS is changed because of
Auto Certificate Rollover or by an admin's intervention (after or before certificate
expiry), the details of the new certificate must be updated on the Office 365
tenant for the federated domain. This may not happen automatically; it may
require an admin's intervention. When the Primary token-signing certificate on
the AD FS is different from what Office 365 knows about, the token that's issued
by AD FS is not trusted by Office 365. Therefore, the federated user is not
allowed to log on.

Office 365 or Azure AD will try to reach out to the AD FS service, assuming the
service is reachable over the public network. We try to poll the AD FS federation
metadata at regular intervals, to pull any configuration changes on AD FS,
mainly the token-signing certificate info. If this process is not working, the global
admin should receive a warning on the Office 365 portal about the token-signing
certificate expiry and about the actions that are required to update it.

You can use Get-MsolFederationProperty -DomainName <domain> to

dump the federation property on AD FS and Office 365. Here you can compare
the TokenSigningCertificate thumbprint, to check whether the Office 365 tenant
configuration for your federated domain is in sync with AD FS. If you find a
mismatch in the token-signing certificate configuration, run the following
command to update it:

Update-MsolFederatedDomain -DomainName <domain>

-SupportMultipleDomain

You can also run the following tool to schedule a task on the AD FS server
that will monitor for the Auto-certificate rollover of the token-signing
certificate and update the Office 365 tenant automatically.

Microsoft Office 365 Federation Metadata Update Automation Installation Tool

Verify and manage single sign-on with AD FS

Issuance Transform claim rules for the Office 365 RP are

not configured correctly.

In a scenario where you have multiple TLDs (top level domains), you might have
logon issues if the Supportmultipledomain switch was not used when the RP
trust was created and updated. For more information, click here.

Make sure that token encryption is not being used by AD

FS or STS when a token is issued to Azure AD or to Office 365.

There are stale cached credentials in Windows Credential

Manager.

Sometimes during login in from a workstation to the portal (or when using
Outlook), when the user is prompted for credentials, the credentials may be
 saved for the target (Office 365 or AD FS service) in the Windows Credentials
Manager (Control Panel\User Accounts\Credential Manager). This helps prevent a
credentials prompt for some time, but it may cause a problem after the user
password has changed and the credentials manager is not updated. In that
scenario, stale credentials are sent to the AD FS service, and therefore
authentication fails. Removing or updating the cached credentials, in Windows
Credential Manager may help.

Make sure that Secure Hash Algorithm that's configured on the

Relying Party Trust for Office 365 is set to SHA1.

When the trust between the STS/AD FS and Azure AD/Office 365 is using SAML
2.0 protocol, the Secure Hash Algorithm configured for digital signature should
be SHA1.

If none of the preceding causes apply to your situation, create a

support case with Microsoft and ask them to check whether the User account
appears consistently under the Office 365 tenant. For more information, see the
following resources:

Error message from AD FS 2.0 when a federated user signs in to Office 365:
"There was a problem accessing the site"

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

Depending on which cloud service (integrated with Azure AD)

you are accessing, the authentication request that's sent to AD FS may vary. For
example: certain requests may include additional parameters such
as Wauth or Wfresh, and these parameters may cause different behavior at the
AD FS level.

We recommend that AD FS binaries always be kept updated to include the fixes

for known issues. For more information about the latest updates, see the
following table.