Check User's Sign-In Activity Logs Log On AAD Portal Active Directory Activity Sing in

You might also like

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 3

Check user's sign-in activity logs

Log on AAD portal  active directory  activity  sing in

Sign-in error
code Sign-in failure reason Resolution
User's Kerberos ticket is
81001 too large. Reduce the user's group memberships and try again.
Unable to validate the
81002 user's Kerberos ticket. See the troubleshooting checklist.
Unable to validate the
81003 user's Kerberos ticket. See the troubleshooting checklist.
Kerberos authentication
81004 attempt failed. See the troubleshooting checklist.
Unable to validate the
81008 user's Kerberos ticket. See the troubleshooting checklist.
Unable to validate the
81009 user's Kerberos ticket. See the troubleshooting checklist.
Seamless SSO failed
because the user's
Kerberos ticket has The user needs to sign in from a domain-joined device
81010 expired or is invalid. inside your corporate network.
Unable to find the user
object based on the
information in the user's Use Azure AD Connect to synchronize the user's
81011 Kerberos ticket. information into Azure AD.
The user trying to sign in
to Azure AD is different
from the user that is
81012 signed in to the device. The user needs to sign in from a different device.
Unable to find the user
object based on the
information in the user's Use Azure AD Connect to synchronize the user's
81013 Kerberos ticket. information into Azure AD.
Domain controller logs

If you enable success auditing on your domain controller, then every time a user signs in through
Seamless SSO, a security entry is recorded in the event log. You can find these security events by
using the following query. (Look for event 4769 associated with the computer account
AzureADSSOAcc$.)

<QueryList>

<Query Id="0" Path="Security">

<Select Path="Security">*[EventData[Data[@Name='ServiceName'] and


(Data='AZUREADSSOACC$')]]</Select>

</Query>

</QueryList>

Query.txt

Known issues

1. In a few cases, enabling Seamless SSO can take up to 30 minutes.


2. If you disable and re-enable Seamless SSO on your tenant, users will not get the single sign-
on experience till their cached Kerberos tickets, typically valid for 10 hours, have expired.
3. If Seamless SSO succeeds, the user does not have the opportunity to select Keep me signed
in. Due to this behavior, SharePoint and OneDrive mapping scenarios don't work.
4. Office 365 Win32 clients (Outlook, Word, Excel, and others) with versions 16.0.8730.xxxx
and above are supported using a non-interactive flow. Other versions are not supported; on
those versions, users will enter their usernames, but not passwords, to sign-in. For OneDrive,
you will have to activate the OneDrive silent config feature for a silent sign-on experience.
5. Seamless SSO doesn't work in private browsing mode on Firefox.
6. Seamless SSO doesn't work in Internet Explorer when Enhanced Protected mode is turned
on.
7. Seamless SSO doesn't work on mobile browsers on iOS and Android.
8. If a user is part of too many groups in Active Directory, the user's Kerberos ticket will likely
be too large to process, and this will cause Seamless SSO to fail. Azure AD HTTPS requests
can have headers with a maximum size of 50 KB; Kerberos tickets need to be smaller than
that limit to accommodate other Azure AD artifacts (typically, 2 - 5 KB) such as cookies. Our
recommendation is to reduce user's group memberships and try again.
9. If you're synchronizing 30 or more Active Directory forests, you can't enable Seamless SSO
through Azure AD Connect. As a workaround, you can manually enable the feature on your
tenant.
10. Adding the Azure AD service URL (https://autologon.microsoftazuread-sso.com) to the
Trusted sites zone instead of the Local intranet zone blocks users from signing in.
11. Seamless SSO supports the AES256_HMAC_SHA1, AES128_HMAC_SHA1 and
RC4_HMAC_MD5 encryption types for Kerberos. It is recommended that the encryption type
for the AzureADSSOAcc$ account is set to AES256_HMAC_SHA1, or one of the AES types vs.
RC4 for added security. The encryption type is stored on the msDS-
SupportedEncryptionTypes attribute of the account in your Active Directory. If the
AzureADSSOAcc$ account encryption type is set to RC4_HMAC_MD5, and you want to
change it to one of the AES encryption types, please make sure that you first roll over the
Kerberos decryption key of the AzureADSSOAcc$ account as explained in the FAQ document
under the relevant question, otherwise Seamless SSO will not happen.

Troubleshooting checklist

1. Use the following checklist to troubleshoot Seamless SSO problems:


2. Ensure that the Seamless SSO feature is enabled in Azure AD Connect. If you can't enable the
feature (for example, due to a blocked port), ensure that you have all the prerequisites in
place.
3. If you have enabled both Azure AD Join and Seamless SSO on your tenant, ensure that the
issue is not with Azure AD Join. SSO from Azure AD Join takes precedence over Seamless SSO
if the device is both registered with Azure AD and domain-joined. With SSO from Azure AD
Join the user sees a sign-in tile that says "Connected to Windows".
4. Ensure that the Azure AD URL (https://autologon.microsoftazuread-sso.com) is part of the
user's Intranet zone settings.
5. Ensure that the corporate device is joined to the Active Directory domain. The device
doesn't need to be Azure AD Joined for Seamless SSO to work.
6. Ensure that the user is logged on to the device through an Active Directory domain account.
7. Ensure that the user's account is from an Active Directory forest where Seamless SSO has
been set up.
8. Ensure that the device is connected to the corporate network.
9. Ensure that the device's time is synchronized with the time in both Active Directory and the
domain controllers, and that they are within five minutes of each other.
10. Ensure that the AZUREADSSOACC computer account is present and enabled in each AD
forest that you want Seamless SSO enabled. If the computer account has been deleted or is
missing, you can use PowerShell cmdlets to re-create them.
11. List the existing Kerberos tickets on the device by using the klist command from a command
prompt. Ensure that the tickets issued for the AZUREADSSOACC computer account are
present. Users' Kerberos tickets are typically valid for 10 hours. You might have different
settings in Active Directory.
12. If you disabled and re-enabled Seamless SSO on your tenant, users will not get the single
sign-on experience till their cached Kerberos tickets have expired.
13. Purge existing Kerberos tickets from the device by using the klist purge command, and try
again.
14. To determine if there are JavaScript-related problems, review the console logs of the
browser (under Developer Tools).

You might also like