AD FS reports trouble in three places: the AD FS Admin log, the Security log (once auditing is on) and the error page the user sees, which carries an Activity ID. This quick reference lists the events and MSIS errors Microsoft documents for sign-in failures, extranet lockout, certificates and service start-up, with the usual cause and the first check, plus the commands that prove the fix. It applies to AD FS on Windows Server 2016 through 2025.
Codes in this quick reference
Event ID 364: Encountered error during federation passive request.AD FS/Admin logMSIS7065: There are no registered protocol handlers on path ... to process the incoming request.AD FS/Admin log (event 364)MSIS7042: The same client browser session has made '{0}' requests in the last '{1}' seconds.AD FS error page / Admin logEvent ID 342: credential or token validation failed (reason in the exception)AD FS/Admin logUnknown Auth method (requested authentication context isn't supported)AD FS error pageEvent ID 411: failed credential validation audit with the user and client IPSecurity log (AD FS auditing)Event ID 501: AD FS audit details with client IP headers (x-ms-client-ip)Security log (AD FS auditing)Event ID 1200: Application Token SuccessSecurity log (AD FS auditing)
+ 26 more codes in the tables below.
How to read these codes#
- Admin log: Event Viewer › Applications and Services Logs › AD FS › Admin, on by default. Errors such as 364 hold an exception; the MSIS code is inside it.
- Debug trace: View › Show Analytic and Debug Logs, then AD FS Tracing › Debug › Enable Log. It's verbose, so switch it off after the repro.
- Security log (411, 501, 1200-series, lockout events): needs the AD FS service account in the Generate security audits user right,
auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable, and Success audits and Failure audits ticked on the Events tab of Edit Federation Service Properties.Set-AdfsProperties -AuditLevelsetsBasic(default, up to five events per request) orVerbose. - Activity ID: every event for one request carries the same Activity ID on every server, including the proxy, and the user's error page shows it. Ask for it, then filter on it.
# Recent AD FS Admin errors
Get-WinEvent -FilterHashtable @{ LogName = 'AD FS/Admin'; Level = 2; StartTime = (Get-Date).AddHours(-2) } |
Select-Object TimeCreated, Id, ActivityId, Message | Format-List
# Everything for one request: paste the Activity ID from the user's error page
$id = [guid]'11111111-2222-3333-4444-555555555555'
Get-WinEvent -LogName 'AD FS/Admin' -MaxEvents 5000 | Where-Object ActivityId -eq $id
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 411, 501, 1201, 1203 } -MaxEvents 5000 |
Where-Object { $_.Message -match $id.ToString() }Sign-in and request errors#
| Event / code | Meaning | Usual cause | First check |
|---|---|---|---|
364: Encountered error during federation passive request. | A browser sign-in request failed. | Varies; the exception text names it, often with an MSIS code. | Exception details and the relying party in the event; the Activity ID. |
MSIS7065: There are no registered protocol handlers on path /adfs/ls/… to process the incoming request. | The URL isn't a working AD FS endpoint. | A typo in the path, or a page that's turned off, such as the IdP-initiated sign-on page. | Fix the URL (/adfs/ls/idpinitiatedsignon); enable that page only if you need it: Set-AdfsProperties -EnableIdpInitiatedSignonPage $true. |
MSIS7042: The same client browser session has made '{0}' requests in the last '{1}' seconds. Contact your administrator for details. | Loop detection stopped the browser: by default, five tokens in 20 seconds. | The relying party doesn't accept the token it was given and keeps sending the user back. | Fix the relying party (claims, endpoint, trusted certificate). Tune with -LoopDetectionMaximumTokensIssuedInterval and -LoopDetectionTimeIntervalInSeconds; never leave -EnableLoopDetection $false. |
| 342 | AD FS couldn't validate the presented credentials or token. | Bad or expired password, an account problem in AD, or a token AD FS doesn't accept; the exception names it. | The exception text; the account's LockedOut, Enabled and PasswordExpired values in AD. |
Unknown Auth method, or an error that the requested AuthnContext isn't supported | AD FS can't satisfy the requested authentication. | The app asks for a method or context that isn't enabled for the request. | Get-AdfsGlobalAuthenticationPolicy versus what the request asks for (wauth or RequestedAuthnContext). |
Federated Microsoft 365 users who reach AD FS and fail there show these events; failures before redirection are AADSTS codes, covered in the AADSTS quick reference.
Lockout and audit events#
| Event | Meaning | Usual cause | First check |
|---|---|---|---|
| 411 | Failed credential validation audit with the user and client IP. | Password spray, or a device or app still using an old password. | Group by user and IP; unknown external IPs point to an attack. |
| 501 | Audit details for the request, including client IP headers. | Read together with 411. | Web sign-ins: x-ms-client-ip. Exchange Online legacy authentication: the submitter is in x-ms-forwarded-client-ip. |
| 1200 / 1201 | Application Token Success / Application Token Failure. | 1201: token issuance failed (for WS-Federation and SAML-P, on the request that carried the SSO cookie). | The relying party and error in 1201. |
| 1202 / 1203 | Fresh Credential Validation Success / Error. | 1203 is written for each bad password; with extranet lockout it counts toward the threshold. | User and IP in 1203. |
| 1205 / 1207 | Password Change Request Error / Sign Out Failure. | Password change or sign-out request failed. | Details in the event. |
| 1210 | Extranet lockout: written each time a user is locked out. | Bad attempts passed ExtranetLockoutThreshold. | Get-AdfsAccountActivity. |
| 516 | The following user account has been locked out due to too many bad password attempts. | Same, with client IP and bad password count. | Client IP in the event. |
| 515 | The following user account was in a locked out state, and the correct password was provided. This account might be compromised. | The right password arrived during a lockout. | Treat as a possible compromise: reset the password, review sign-ins. |
| 512 | The account for the following user is locked out. A sign-in attempt is being allowed due to the system configuration. | The user is over the threshold, but the lockout settings let this attempt through. | Get-AdfsProperties: ExtranetLockoutMode and the thresholds. |
| 557 / 562 / 563 (AD FS 2019) | The node can't reach the account store on the primary node, or can't calculate lockout status. | WID farm: the primary node is offline. SQL farm: AD FS picks a new primary node. | (Get-AdfsFarmInformation).FarmRoles; the primary node's health. |
Get-AdfsAccountActivity user@contoso.com # bad password counts, lockout flags, familiar IPs
Reset-AdfsAccountLockout user@contoso.com -Location Unknown
# Extranet smart lockout: log-only first so AD FS learns familiar IPs, then enforce
Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 10 -ExtranetObservationWindow (New-TimeSpan -Minutes 30)
Set-AdfsProperties -ExtranetLockoutMode AdfsSmartLockoutLogOnly # later: AdfsSmartLockoutEnforce
Restart-Service adfssrv # on every node after a mode changeTip: Keep ExtranetLockoutThreshold below the AD lockout threshold (Microsoft's example: 10 against 20) so AD FS stops attackers before AD locks the account. Run log-only mode for 3-7 days first. Lockouts that still reach AD can be traced on the DCs with the logon failure and lockout reference, and Connect Health reports risky IPs.
Certificate events#
| Event | Meaning | Usual cause | First check |
|---|---|---|---|
| 249 | A certificate couldn't be found in the certificate store. | Certificate missing from the store, or no access to its private key; breaks signing or decryption after a rollover. | Certificate in LocalMachine\My; read access to the private key for the service account. |
| 315 / 316 / 317 / 374 | Chain build failed for a claims provider trust signing (315), relying party trust signing (316), relying party trust encryption (317) or claims provider trust encryption (374) certificate. | The partner's certificate is revoked, expired, not yet valid, or its chain can't be verified. | Certificate validity and reachability of its CRL. |
| 319 | Chain build failed for the client certificate. | Same reasons, for a user or device certificate. | Chain and CRL of the client certificate. |
| 360 | A certificate transport endpoint got a request without a client certificate. | The issuing root isn't trusted, or the certificate is expired or self-signed. | Root CA in the trusted root store; certificate expiry. |
| 381 | Chain build failed for a configuration certificate. | One of the farm's own certificates is expired or revoked. | Get-AdfsCertificate. |
| 385 | Certificates in the AD FS configuration database need to be updated manually. | A configured certificate is expired or close to expiry. | Replace it; with self-signed certificates and automatic rollover it resolves itself. |
| 387 | Certificates weren't accessible to the service account of the AD FS Windows service. | No read permission on a private key. | Grant the service account read access to every configured private key. |
| 389 | Trusts need their certificates updated manually because they're expired or expiring. | A partner rolled or let its certificate expire. | Manual trust: update it. Metadata-based trust: updates when the partner publishes. |
Get-AdfsCertificate | Select-Object CertificateType, IsPrimary, Thumbprint, @{ n = 'NotAfter'; e = { $_.Certificate.NotAfter } }
(Get-AdfsProperties).AutoCertificateRollover
Get-AdfsSslCertificate
# Microsoft Graph PowerShell: the signing certificate Entra ID holds for a federated domain
Get-MgDomainFederationConfiguration -DomainId contoso.com | Select-Object IssuerUri, SigningCertificateService start-up and proxy problems#
| Event | Meaning | Usual cause | First check |
|---|---|---|---|
| 102 | There was an error in enabling endpoints of the Federation Service. | A start-up configuration problem; the event details name it. | Microsoft's start-up checklist: start time-outs, the service account and its password, its database permissions and its rights on the certificate sharing container in AD. |
| 220 | The Federation Service configuration could not be loaded correctly from the AD FS configuration database. | The service can't read its configuration database. | WID or SQL Server reachability; permissions of the service account. |
| 352 | A SQL Server operation in the AD FS configuration database with connection string %1 failed. | SQL farm can't run a database operation. | Connectivity to SQL Server and the service account's rights. |
When the Web Application Proxy loses its trust with AD FS, check in this order: clock skew between all AD FS and proxy servers; that both sides use the same TLS certificate; that setspn -f -q host/fs.contoso.com resolves to the AD FS service account; and that secondary AD FS servers have synced. Then rebuild the trust with Install-WebApplicationProxy -FederationServiceName fs.contoso.com -CertificateThumbprint '<thumbprint>'.
How to verify a fix#
- Reproduce the sign-in and filter on its Activity ID: no new 364 in the Admin log, and 1202 followed by 1200 for the user in the Security log.
- Lockout:
Get-AdfsAccountActivityshows the lockout flags asFalse, and no new 1210 or 516 events appear for that user. - Certificates: restart
adfssrvon each node; 249, 381, 385 and 387 don't come back; Entra ID holds the current token-signing certificate for each federated domain. - Proxy:
Install-WebApplicationProxycompletes and an external sign-in reaches the AD FS sign-in page.
Note: Every fix here keeps AD FS running, but each farm is another set of certificates and servers to maintain. If you use AD FS mainly for Microsoft 365, read moving from AD FS to cloud authentication.

