🔧 Troubleshooting Active Directory

Troubleshooting Active Directory: Slow Logins, Dead Domain Controllers, Expired Tickets and Kerberos Errors
nltest /dsgetdc:corp.example.com /force

This guide is a working method for finding out WHY Active Directory logins are slow or failing. It covers the classic causes: a domain controller (DC)
that is down or gone but still advertised in DNS, clients that pick a far-away DC, clock problems, expired or stale Kerberos tickets, broken machine
account trust, duplicate service names (SPNs), replication trouble and slow Group Policy. Commands are given for Windows (PowerShell and cmd) and for
Linux clients (SSSD and MIT Kerberos). Examples use the domain corp.example.com (realm CORP.EXAMPLE.COM) and DCs named dc01 and dc02: replace them.
Several fixes below change AD (DNS records, metadata cleanup, machine passwords). Read the warnings, take backups, and test in a lab when you can.
See the "Active Directory Login with SSSD" tutorial for Linux domain joins.

A login is a chain. If ANY link is slow or broken, the user waits or fails:
1. DNS          The client asks DNS for the domain's SRV records to find domain controllers. Bad DNS = "no domain" or a wrong DC
2. DC locator   The client picks a DC (ideally one in its own AD site) and pings it. A dead DC in the list = timeouts before it tries the next
3. Time         Kerberos refuses tickets when the clocks differ by more than 5 minutes
4. Kerberos     The client gets a TGT (Ticket-Granting Ticket) from the KDC on a DC, then service tickets. Wrong SPN, password or encryption = failure
5. Secure channel   Each computer has a machine account password. If it is out of sync the computer cannot authenticate to the domain
6. Group Policy and profiles   After authentication, policies, scripts, mapped drives and profiles load. These cause many "slow logon" complaints
7. The application   Sometimes the login is fine and one service (file server, web app) is the slow or failing part
Work through the chain in order. Fix DNS and time first: they explain more than half of all AD problems.

- WHO is affected: one user, one computer, one site, everyone? (One user = account or profile. One computer = trust, DNS, time. One site = local DC or network. Everyone = DC, replication, DNS or time)
- WHEN did it start, and what changed? (a DC added or removed, patching, a firewall change, a new GPO, a DNS change, a VM snapshot restore, daylight saving time)
- WHAT exactly is slow: the credentials prompt, "Welcome", the desktop, or one application? Time it with a stopwatch, and note the seconds
- IS it constant or intermittent? (Intermittent often means one bad DC among several: the client only hits it sometimes)
- WHERE: on the LAN, over VPN, in a branch office, Wi-Fi?
Write these answers down. They tell you which layer to check first.

Logins take a fixed long time (30, 60 or 90 seconds), every time     A dead or unreachable DC is tried first and times out. Stale DNS SRV records, wrong site or subnet. See "Slow logins and unavailable DCs"
Logins are slow only sometimes                                       One of several DCs is bad (slow, overloaded, out of replication) and clients randomly pick it
Slow only at a branch office or on VPN                               No subnet-to-site mapping, so clients use a far-away DC. Or slow WAN, or GPO/profile over the link
Slow only at "Applying computer settings" or "Group Policy Client"   Group Policy, SYSVOL/DFS access, or a slow client-side extension
"The trust relationship between this workstation and the primary domain failed"   Broken secure channel (machine password out of sync)
"There are currently no logon servers available to service the logon request"     Client cannot find or reach a DC: DNS, firewall, or all DCs down
SSO stopped, prompts for a password for shares or websites            Expired or missing Kerberos tickets, SPN problems, time, or the site is not in the Intranet zone
"Clock skew too great" / KRB_AP_ERR_SKEW                              Time is off by more than 5 minutes
"Preauthentication failed" / 0x18                                     Wrong password (or a cached old password, a lockout source)
Works after a reboot or logoff, then fails again later                Stale group membership or expired ticket, token bloat, or a bad DC being reused
Linux: SSH or su takes 30+ seconds                                    SSSD trying an unreachable DC, DNS/Kerberos lookups timing out, or GSSAPI delays. See the Linux section
Access denied to a share the user "should" reach                      Old token (log off and on), nested group not applied, NTFS/share permissions, or a Kerberos ticket problem

Windows (run PowerShell or cmd as administrator, on a client or a DC; DC tools need the RSAT/AD tools):
nltest /dsgetdc:corp.example.com /force        Which DC would I use, and in which site? (/force skips the cache)
nltest /dclist:corp.example.com                All DCs the client knows about        nltest /dsgetsite    My AD site         nltest /dsgetdc:corp.example.com /gc    A Global Catalog
nltest /sc_query:corp.example.com              State of the machine's secure channel     nltest /sc_verify:corp.example.com    Verify it      nltest /sc_reset:corp.example.com\dc01    Reset it to a specific DC
echo %LOGONSERVER%                             Which DC authenticated this logon
klist                                          Kerberos tickets of the current logon session     klist tgt    the TGT       klist purge    delete cached tickets      klist -li 0x3e7    computer (SYSTEM) tickets
setspn -L SERVER01                             SPNs on an account          setspn -Q HTTP/web.corp.example.com    who owns this SPN?         setspn -X    find duplicate SPNs in the forest
w32tm /query /status    /query /source    /monitor    /stripchart /computer:dc01 /samples:5 /dataonly       Time state, source and offset
w32tm /resync /force                           Sync now
dcdiag /v                                      Health tests for a DC (run ON the DC)       dcdiag /test:dns /v     dcdiag /test:replications     dcdiag /e /q    all DCs, errors only
repadmin /replsummary                          Replication overview for the whole forest        repadmin /showrepl    detail for this DC       repadmin /syncall /AdeP    force sync everywhere
gpresult /r    gpresult /h C:\gp.html /f       What Group Policy applied and how long each part took      gpupdate /force    reapply
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com       DC locator records        nslookup -type=SRV _kerberos._tcp.corp.example.com
Test-NetConnection dc01.corp.example.com -Port 389             TCP reachability (ports: 53, 88, 135, 389, 445, 464, 636, 3268, 3269)
Test-ComputerSecureChannel -Verbose            Is this computer's trust to the domain healthy?         Test-ComputerSecureChannel -Repair -Credential CORP\admin    Repair it
Get-ADUser jsmith -Properties LockedOut,PasswordExpired,PasswordLastSet,Enabled,"msDS-UserPasswordExpiryTimeComputed"
Linux (SSSD and MIT Kerberos):
realm list                       sudo sssctl domain-status corp.example.com      sudo sssctl user-checks jsmith@corp.example.com      sudo sss_cache -E
dig +short -t SRV _ldap._tcp.dc._msdcs.corp.example.com                          dig +short -t SRV _kerberos._tcp.corp.example.com
KRB5_TRACE=/dev/stderr kinit jsmith@CORP.EXAMPLE.COM                              Step-by-step Kerberos trace: the best Linux Kerberos tool     klist -e    show tickets and encryption types
sudo klist -k /etc/krb5.keytab                                                   Machine keytab          adcli testjoin     net ads testjoin
ldapsearch -H ldap://dc01.corp.example.com -Y GSSAPI -b "" -s base              LDAP with a Kerberos login (after kinit)        nc -zv dc01.corp.example.com 88
chronyc tracking     chronyc sources -v     timedatectl                          Time
sudo journalctl -u sssd -n 100           ls /var/log/sssd/           (raise debug_level to 6 in sssd.conf when needed)
Windows Event Viewer: Security log (4768 TGT request, 4769 service ticket, 4771 Kerberos pre-auth failure, 4776 NTLM validation, 4625 failed logon, 4740 account lockout),
System log (Kerberos, NETLOGON, Time-Service, DNS Client), and Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational.

The client asks DNS for _ldap._tcp.dc._msdcs.corp.example.com. DNS returns ALL DCs (each with a priority and weight), and a site-specific list
_ldap._tcp.SITENAME._sites.dc._msdcs.corp.example.com. Clients prefer DCs in their own site. The client sends a small LDAP ping (UDP 389) to candidates and
takes the first answer. If it tries a DC that is offline or unreachable, it waits for a timeout before trying the next. That delay lands in the user's face.
Windows also CACHES the choice, so problems can appear and disappear as the cache expires. nltest /dsgetdc /force bypasses the cache.
Common causes of a slow login from one bad DC:
- A DC was powered off, crashed or retired but its DNS records (SRV, A) still exist, so clients keep trying it
- A DC was removed the wrong way (deleted VM, no demotion), leaving metadata and DNS records behind
- The DC is up but unhealthy: DNS or Netlogon service stopped, not replicating, out of disk, very slow, or blocked by a firewall
- A firewall or routing change blocks a DC from some subnets
- The client has NO subnet in AD Sites and Services, so it lands in no site and gets a random DC (maybe across a slow WAN link)
- Clients have a wrong or extra DNS server (for example a public DNS like 8.8.8.8 as the secondary), so lookups sometimes fail or go elsewhere

On the affected computer:
nltest /dsgetdc:corp.example.com /force                  # note the DC name, and the site ("Client Site Name" and "DC Site Name")
nltest /dclist:corp.example.com
echo %LOGONSERVER%
Time the discovery itself:
Measure-Command { nltest /dsgetdc:corp.example.com /force }        # a few hundred ms is fine. Several seconds means timeouts happen
Repeat a few times, and from another site. If a run returns quickly with the WRONG or far-away site, or is slow, you have found the layer.
Check every DC that DNS advertises:
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com                        # list all DCs
foreach ($dc in "dc01","dc02","dc03") { $dc; Test-NetConnection "$dc.corp.example.com" -Port 389 -InformationLevel Quiet; Test-NetConnection "$dc.corp.example.com" -Port 88 -InformationLevel Quiet }
Any DC that does not answer on 389 and 88, but is in the SRV list, is your slow login.

dcdiag /e /q                                        # all DCs, errors only (empty output = good)
dcdiag /test:dns /v /s:dc01                          # DNS health of one DC
dcdiag /test:advertising /s:dc01                     # is it advertising itself as a DC? (Netlogon)
repadmin /replsummary                               # replication failures show up here
Get-ADDomainController -Filter * | Select Name,Site,IPv4Address,OperatingSystem,IsGlobalCatalog,Enabled
On the suspect DC: services running? (NTDS, DNS, Netlogon, Kerberos Key Distribution Center, W32Time, DFSR)  Get-Service NTDS,DNS,Netlogon,KDC,W32Time,DFSR
Disk space free on the drive holding the AD database and logs?  Event Viewer > Directory Service, DNS Server and System logs (errors, NETLOGON 5719/5781, DNS 4013).
Ports must be open from clients to DCs: DNS 53 (tcp/udp), Kerberos 88 (tcp/udp), RPC 135 and the dynamic range 49152-65535, LDAP 389 (tcp/udp), SMB 445, Kerberos password 464, LDAPS 636, GC 3268/3269, NTP 123/udp.

Step 1.3: Remove the dead DC's stale records (the most common permanent fix)
If a DC is gone for good, clean it out. If it is coming back soon, fix or start it instead. Order:
1. Make sure the DC is really gone (turned off, never returning), and note its name. NEVER do this to a DC that might be restored from a snapshot or backup later
2. Metadata cleanup (removes the DC object from AD). Modern method: in "Active Directory Users and Computers" delete the DC computer object from the Domain Controllers OU and choose
   "Delete this Domain Controller anyway" then let the wizard clean up (this also removes NTDS Settings). Or command-line:
       ntdsutil
       metadata cleanup
       connections
       connect to server dc02
       quit
       select operation target
       list domains ... list sites ... list servers in site ... select server <number> ... quit
       remove selected server
   (Follow Microsoft's documentation for your version. Be extremely careful to select the RIGHT server.)
3. Clean DNS: in DNS Manager remove the stale records:
   - The DC's A/AAAA record in the domain zone
   - _msdcs zone (_msdcs.corp.example.com): the DC's CNAME (a GUID name), NS record, and its entries under _ldap, _kerberos, _gc, _kpasswd, in domain, sites and dc subfolders
   - The DC's NS record in the domain zone and _msdcs zone (Name Servers tab)
   - Reverse lookup PTR records
4. Remove the DC from Active Directory Sites and Services if any object remains (Sites > site > Servers)
5. Check other things that point at it: DNS forwarders, DHCP scopes (DNS server option 6), GPOs or scripts that name the DC, time settings, ldap:// application settings, firewall rules
6. Verify from a client:  ipconfig /flushdns   nltest /dsgetdc:corp.example.com /force   nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com   (the dead DC must be gone)
7. Force replication so all DCs learn the change:  repadmin /syncall /AdeP
Prevent this next time: always DEMOTE a DC properly (Uninstall-ADDSDomainController, or Server Manager > Remove roles) before you shut it down or delete the VM.
Enable DNS scavenging so old dynamic records expire (carefully: set the no-refresh and refresh intervals thoughtfully).

Every IP subnet used by clients must be defined in Active Directory Sites and Services (Subnets), and linked to the right site. Otherwise clients are "not in a site" and may pick any DC.
Get-ADReplicationSubnet -Filter * | Select Name,Site                                 # defined subnets
nltest /dsgetsite                                                                    # the site a client believes it is in
Event NETLOGON 5807 on DCs (System log) lists client IP addresses that do not map to any site: add those subnets.
Have at least one DC (and preferably two) in each site with users. If a site has no DC, clients use "next closest site" costs from the site links. Check site link costs and the "Automatic site coverage" behavior.
Set the client site explicitly if needed (rare): HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SiteName (string).
Remote sites should have a local DC (or an RODC) and local DNS, so logins do not cross the WAN.

Domain-joined computers must use ONLY AD-integrated DNS servers (your DCs or servers that forward AD zones to them). A public DNS server as a "backup" breaks AD lookups intermittently.
Get-DnsClientServerAddress -AddressFamily IPv4                  # what the client uses
ipconfig /all                                                   # also the DNS suffix search list
Check DHCP scope option 006 (DNS servers) and 015 (domain name). Put the LOCAL-site DC first for branch offices.
Ensure the DNS zone allows secure dynamic updates and that clients register their A records (ipconfig /registerdns).
Reduce reliance on the primary DC: point the DC's own DNS setting at ITSELF as secondary and another DC as primary (or per Microsoft's current guidance), and never at 127.0.0.1 only when it is the first DC in a forest.
Test name resolution speed:  Measure-Command { Resolve-DnsName dc01.corp.example.com }     nslookup -debug dc01.corp.example.com

Test-NetConnection dc01.corp.example.com -Port 389 -InformationLevel Detailed
tracert dc01.corp.example.com                                   # and compare with a good client
ping -f -l 1472 dc01.corp.example.com                            # test for MTU/fragmentation trouble (Windows). VPN and tunnels often break large Kerberos packets
Kerberos over UDP fails with large tickets (big groups): clients fall back to TCP with a delay. Fix by allowing TCP 88, and reduce token bloat (see below).
A NIC set to half duplex, an inspecting firewall (with an "AD-unaware" ALG), or asymmetric routing can cause random slowness.
Capture when you cannot see the cause (see the Wireshark sheet): filter  kerberos || ldap || dns  and look for repeated packets (retransmissions) to one DC.

Step 1.7: Group Policy and profile slowness (often mistaken for "slow AD")
Watch where the time goes:
gpresult /h C:\gp.html /f                                       # open it: each Computer/User extension has a processing time. Look for the biggest numbers
Event Viewer > Applications and Services Logs > Microsoft > Windows > GroupPolicy > Operational
    1129   Processing failed because of lack of network connectivity to a domain controller (DNS or firewall trouble)
    1058   Cannot access the GPT file in SYSVOL (SYSVOL/DFS problem)
    Look also at the elapsed-time entries (the "Completed" events) to see how long each phase took.
gpupdate /force                                                 # then time it
Common slow-logon contributors:
- Logon scripts and mapped drives to servers that are slow, offline, or in another site (use DFS site-costing and asynchronous processing)
- Roaming profiles and folder redirection over slow links (move to caching, OneDrive Known Folder Move, or FSLogix)
- Many GPOs and WMI filters, item-level targeting that queries AD, or software installation policies
- "Always wait for the network at computer startup and logon" enabled where it is not needed
- SYSVOL replication issues: clients pull policies from a DC with an old or missing copy (check DFSR: dfsrdiag pollad, Get-DfsrState, DFSR event 4012/2213)
- Antivirus scanning the profile, or too large a profile
Trace a slow logon:  Windows Performance Recorder (WPR) with the "Logon" profile, or Windows Performance Toolkit boot/logon traces (xperf/xbootmgr), to see which phase (winlogon, GP, shell start) takes time.

1. The user logs in. The client sends an AS-REQ to a DC (the KDC). The DC checks the password and returns a TGT (usually valid 10 hours, renewable up to 7 days). This is event 4768 on the DC
2. To use a service (file share, website, SQL), the client shows the TGT to the DC and asks for a service ticket (TGS) for the service's SPN (like cifs/fs01.corp.example.com). Event 4769
3. The client presents the service ticket to the server. The server decrypts it with ITS key (from the service account or machine password). If the SPN, the key or the time is wrong, this step fails
4. The user's group memberships are copied into the ticket (PAC) at ticket time. That is why group changes need a new logon or a ticket refresh
Default policy (Default Domain Policy > Kerberos Policy): user ticket lifetime 10 hours, renewal 7 days, service ticket lifetime 600 minutes, clock skew tolerance 5 minutes.
Kerberos needs: correct time, working DNS (names, not IP addresses: connecting with \\10.0.0.5 forces NTLM, not Kerberos), and unique, correct SPNs.
NTLM is the fallback. Slow or "asked for credentials again" behavior usually means Kerberos failed and the client fell back to NTLM or gave up.

klist                                            # (Windows) list tickets: look at Server, Start Time, End Time, Renew Time, and KerbTicket Encryption Type
klist tgt                                        # your TGT, with Start and End Time. If End Time is in the past, the ticket is EXPIRED
klist get cifs/fs01.corp.example.com             # request a ticket for a service now. The error text is the clue (see the table below)
klist purge                                      # delete cached tickets, then reconnect to force new ones (fixes stale group membership and old tickets)
whoami /groups                                   # the groups in your CURRENT token. If a group is missing, log off and log on again (or purge tickets)
whoami /upn                                      # your UPN         whoami /fqdn    distinguished name
Linux:
klist                                            # ticket cache and expiry ("Expires" column)         klist -e    with encryption types
kinit jsmith@CORP.EXAMPLE.COM                    # get a new TGT (password prompt)                     kinit -R    renew a renewable ticket
kdestroy                                         # delete the cache                                     kvno cifs/fs01.corp.example.com     ask for a service ticket and print its key version
KRB5_TRACE=/dev/stderr kinit jsmith@CORP.EXAMPLE.COM        # every step of the exchange
echo $KRB5CCNAME                                 # where the ticket cache lives (FILE, KEYRING or KCM). Some tools cannot read all types

Expired TGT (after about 10 hours, or a laptop resumed from sleep)   SSO stops working; the user is asked for passwords. Locking and unlocking the screen, or logging off and on, gets a new TGT. On Linux: kinit, or SSSD renews it while online
Renewal limit (7 days) reached                                          The ticket can no longer be renewed. A full new logon is needed
User off the network (VPN not connected)                                Cached credentials log them in locally, but there is no TGT yet. Kerberos resources fail until they reconnect. Use "connect before logon" or Always On VPN
Stale group membership                                                  The token was built at logon. New group = log off and on again (or purge tickets and reconnect for services). For services using Kerberos, tickets refresh within their lifetime
Password expired                                                        Login prompts to change it (or fails remotely). Check PasswordExpired and msDS-UserPasswordExpiryTimeComputed. On VPN or with RDP NLA, expired passwords can cause confusing failures
Account locked out                                                      Repeated bad passwords (an old password stored in a phone, service, drive mapping or scheduled task). Find the source: event 4740 on the PDC emulator names the caller computer
Machine account password expired or out of sync                         "Trust relationship failed", Kerberos errors for the computer's own services. Machine passwords rotate every 30 days by default. See "Secure channel"
Very old cached credentials or restored VM snapshots                    A VM restored to an old snapshot has an old machine password: the domain rejects it. Rejoin or reset the secure channel
Expired computer certificate or smart card (if used)                    Certificate-based logons fail: check certificate validity and CA availability
Useful account checks:
Get-ADUser jsmith -Properties LockedOut,PasswordExpired,PasswordLastSet,Enabled,LastBadPasswordAttempt,BadLogonCount,AccountExpirationDate
Search-ADAccount -LockedOut | Select Name,SamAccountName        Unlock-ADAccount jsmith         Search-ADAccount -PasswordExpired
net user jsmith /domain                                          # shows "Password expires", "Account expires", group memberships
Find where a lockout came from (run on the PDC emulator; look for Security event 4740 with "Caller Computer Name"):
Get-WinEvent -FilterHashtable @{LogName='Security';Id=4740} -MaxEvents 20 | Select TimeCreated,@{n='User';e={$_.Properties[0].Value}},@{n='From';e={$_.Properties[1].Value}}

Time (Kerberos' strictest rule)
w32tm /query /status                             # Source, Stratum, Last Successful Sync Time, and Phase Offset
w32tm /query /source                             # a domain member should sync from a DC (not "Local CMOS Clock" or "Free-running")
w32tm /stripchart /computer:dc01.corp.example.com /samples:5 /dataonly       # the offset to a DC in seconds. Over 300 seconds breaks Kerberos
w32tm /resync /force                             # sync now       w32tm /config /syncfromflags:domhier /update     use the domain hierarchy
The PDC emulator of the forest root domain is the authoritative time source. Point it at reliable external NTP:
w32tm /config /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org" /syncfromflags:manual /reliable:yes /update ; Restart-Service w32time
Common time traps: virtual machines syncing time with the hypervisor AND with AD (conflict: disable one), a wrong time zone (the UTC time is fine but the local time is off: check both), a DC restored from a snapshot,
CMOS battery drift, a cloud VM not using the provider's time service, and daylight saving changes.
Linux:  chronyc tracking (System time offset)   chronyc sources -v   timedatectl   Sync from a DC or your NTP servers.

Windows Security event 4771 (Kerberos pre-authentication failed) and 4768/4769 carry a "Failure Code" or "Result Code" in hex:
0x6   KDC_ERR_C_PRINCIPAL_UNKNOWN    User does not exist (typo, wrong domain)
0x7   KDC_ERR_S_PRINCIPAL_UNKNOWN    Service (SPN) not found in the KDC: SPN missing, misspelled, or in a different forest
0xE   KDC_ERR_ETYPE_NOTSUPP          No common encryption type (RC4/AES mismatch). Check "msDS-SupportedEncryptionTypes" and the domain policy
0x12  KDC_ERR_CLIENT_REVOKED         Account disabled, expired or LOCKED OUT
0x17  KDC_ERR_KEY_EXPIRED            Password expired. User must change it
0x18  KDC_ERR_PREAUTH_FAILED         Wrong password
0x1F  KRB_AP_ERR_BAD_INTEGRITY       Integrity check failed: wrong key, a stale ticket, or a duplicate SPN
0x20  KRB_AP_ERR_TKT_EXPIRED         Ticket expired: get a new one (klist purge, then reconnect or kinit)
0x22  KRB_AP_ERR_REPEAT              Replay detected: a duplicate SPN or a load balancer issue
0x25  KRB_AP_ERR_SKEW                Clock skew too great: fix time
0x29  KRB_AP_ERR_MODIFIED            The ticket could not be decrypted by the service: SPN registered on the wrong account, or the service's password changed and the client used an old ticket
Common messages and what they mean:
"Clock skew too great" / KRB_AP_ERR_SKEW                              Time. See above
"Server not found in Kerberos database" / KDC_ERR_S_PRINCIPAL_UNKNOWN   The SPN does not exist or the name does not match. Use the exact FQDN, fix DNS (CNAME aliases need SPNs for the alias), setspn -Q, setspn -S
"Client not found in Kerberos database"                               The user name is wrong, or the user is in another realm
"Preauthentication failed"                                            Wrong password. On Linux with SSSD it can also mean cached credentials differ
"Cannot find KDC for realm" / "Cannot contact any KDC"                DNS SRV records missing, a firewall blocks port 88, or all DCs are unreachable
"Ticket expired" / "Credentials cache is expired"                     Renew or get new tickets
"KDC has no support for encryption type"                              Encryption mismatch (RC4 disabled on one side, or accounts with "Use only Kerberos DES"). Enable AES on accounts (msDS-SupportedEncryptionTypes) and on the service
"Access denied" with Kerberos to a service but NTLM works             SPN duplicates, delegation settings, or the service running under a different account than the SPN's owner
"The security database on the server does not have a computer account for this workstation trust relationship"   The computer object was deleted or is disabled, or the secure channel is broken
"The target principal name is incorrect" (0x80090322 / SEC_E_WRONG_PRINCIPAL)   The client used a name that does not match the server's SPN (alias, IP, wrong DNS)
"The specified target is unknown or unreachable" (0x80090303)         Kerberos could not find the server (DNS) or a DC
"No authority could be contacted for authentication" (0x80090311)     No DC reachable for Kerberos (DNS, network, or time)
Web sites prompt for a password every time                            The site is not in the browser's Local Intranet zone, or the SPN is missing/duplicated, or it uses a hostname alias without an SPN
IIS "HTTP 400 Bad Request: Request Header too long"                   Token bloat: the Kerberos ticket is huge. Reduce group membership (see below) or raise MaxFieldLength and MaxRequestBytes carefully
Turn on Windows Kerberos logging (temporarily) to see error details in the System log:
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v LogLevel /t REG_DWORD /d 1 /f        then reproduce; events appear as Kerberos-Key-Distribution-Center / Security-Kerberos in the System log (delete the value afterward)

An SPN (Service Principal Name) ties a service name to ONE account. Two accounts with the same SPN break Kerberos for that service, often as intermittent failures.
setspn -X                                        # find duplicate SPNs across the forest
setspn -Q HTTP/web.corp.example.com              # who owns it?
setspn -L SVC-WEB                                # list an account's SPNs
setspn -S HTTP/web.corp.example.com SVC-WEB      # add an SPN (with duplicate check)         setspn -D HTTP/web.corp.example.com OLDACCOUNT    remove it from the wrong account
For accounts running services: use Group Managed Service Accounts (gMSA) so passwords rotate automatically and SPNs stay tidy. Set the SPN on the account that actually runs the service.
Constrained delegation ("double hop") needs correct msDS-AllowedToDelegateTo or resource-based constrained delegation. Check with Get-ADComputer/Get-ADUser -Properties msDS-AllowedToDelegateTo.

Symptoms: "The trust relationship between this workstation and the primary domain failed", cannot log in with domain accounts (cached logins still work), Kerberos errors for the computer itself,
event NETLOGON 5719 (no logon servers) or 3210 (failed to authenticate with a DC), 5722/5723 (session setup failed).
Test-ComputerSecureChannel -Verbose                              # True = healthy
nltest /sc_verify:corp.example.com                               # or /sc_query
Repair (does not need to unjoin the computer). Log in with a LOCAL administrator account:
Test-ComputerSecureChannel -Repair -Credential (Get-Credential CORP\adminuser)
Reset-ComputerMachinePassword -Server dc01.corp.example.com -Credential CORP\adminuser        # an alternative
netdom resetpwd /server:dc01.corp.example.com /userd:CORP\adminuser /passwordd:*             # another alternative (RSAT)
If repair fails: check that the computer object exists and is enabled in AD (Get-ADComputer PC01 -Properties Enabled,PasswordLastSet), fix DNS and time, then as a last resort remove the computer from the domain and join it again (Rename or Remove-Computer, Add-Computer).
Warning: the classic cause is a snapshot restore, image clone, or long-offline machine. Machines must not be cloned without sysprep (duplicate SIDs and computer accounts).
Linux (SSSD):  sudo adcli testjoin     sudo net ads testjoin     sudo klist -k /etc/krb5.keytab     If the keytab is stale:  sudo net ads keytab create   or   sudo realm leave && sudo realm join -U adminuser corp.example.com
SSSD rotates the machine password automatically (ad_maximum_machine_account_password_age, default 30 days) while it is running and can reach a DC.

A user in hundreds of groups (or with many SID History entries) gets a very large Kerberos ticket. Symptoms: web servers reject requests (HTTP 400), logins fail for some users only, Kerberos over UDP fails and falls back to TCP,
slow logins, and services that limit token size fail.
whoami /groups | Measure-Object -Line                            # count the groups in the token (a rough check)
Estimate the token size: about 40 bytes per group SID, plus more for SID History and claims. Default MaxTokenSize is 48,000 bytes on modern Windows (12,000 on old versions).
Fix by trimming group membership (remove obsolete groups, avoid nested group explosions, use role-based groups), clearing SID History after migrations, and using domain-local groups sensibly.
Only raise MaxTokenSize (HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters, DWORD, maximum 65535) as a stop-gap, on every relevant machine and server.

Modern AD prefers AES. Old service accounts, trusts, and accounts with "DES only" or without AES keys cause 0xE (ETYPE_NOTSUPP) or downgrade to RC4.
- Reset the password of an old service account once so AES keys are generated (after raising the domain functional level)
- Set msDS-SupportedEncryptionTypes on accounts and computers (Get-ADUser/Set-ADUser), and check the GPO "Network security: Configure encryption types allowed for Kerberos"
- Plan to remove RC4: audit first (events 4768/4769 show the Ticket Encryption Type: 0x17 = RC4, 0x11/0x12 = AES128/256) with a report, then disable
- Security updates from Microsoft (for example those related to Kerberos PAC validation and RC4 enforcement) have changed behavior over time. Keep DCs patched, read the release notes, and test changes on one DC or a lab first
- Linux: klist -e shows the encryption type of your tickets; RHEL 8/9 crypto policies may disable RC4 (last resort: update-crypto-policies --set DEFAULT:AD-SUPPORT)

Replication (if DCs disagree, logins behave differently on different DCs)
repadmin /replsummary                              # failures, largest deltas
repadmin /showrepl * /csv | ConvertFrom-Csv | Where-Object { $_."Number of Failures" -gt 0 }          # any partner with failures
repadmin /syncall /AdeP                            # push replication across all DCs (A = all, d = identify by DN, e = enterprise, P = push)
repadmin /queue                                    # pending replication operations
Get-ADReplicationFailure -Target * -Scope Forest
Key errors: 1722 (RPC unavailable: network, firewall, DNS), 8524 (DSA operation unable to proceed: DNS lookup of the GUID name failed), 8606/8453 (insufficient rights),
1256 (DC unreachable), 2146893022 (target principal name incorrect: time or SPN), 1908 (could not find DC), 8614 (tombstone lifetime exceeded: lingering objects).
Rule: a DC that has not replicated for longer than the tombstone lifetime (180 days by default) must NOT be reconnected. Demote and metadata-clean it instead, or you re-introduce deleted objects.
USN rollback: restoring a DC from a snapshot without using the supported Virtualization-Safe (VM-GenerationID) features can corrupt the directory. Never revert a DC snapshot. Use system state backups.
SYSVOL: DFS Replication. dfsrdiag pollad, Get-DfsrState, and DFSR event log errors (2213, 4012, 4614) point to SYSVOL replication trouble that shows up as Group Policy inconsistencies.

dcdiag /test:dns /v /e                             # thorough DNS tests for all DCs
nslookup -type=SRV _ldap._tcp.dc._msdcs.corp.example.com dc01        # ask each DC's DNS the same question and compare answers
Get-DnsServerResourceRecord -ZoneName corp.example.com -RRType SRV        # (on a DNS server) look at the SRV records
ipconfig /registerdns  and  nltest /dsregdns       # re-register a DC's records after fixing DNS (run nltest /dsregdns on the DC)
Restart-Service Netlogon                           # a DC re-registers its SRV records when Netlogon restarts (the file %SystemRoot%\System32\config\netlogon.dns lists what it should register)
Watch for: missing SRV records after a DC restart, _msdcs zone not replicating (AD-integrated zone scope), stale records for retired DCs, scavenging settings that delete good records, and forwarders that are down.

netdom query fsmo                                  # who holds the 5 roles (PDC emulator, RID master, infrastructure master, schema master, domain naming master)
Get-ADDomain | Select PDCEmulator,RIDMaster,InfrastructureMaster ; Get-ADForest | Select SchemaMaster,DomainNamingMaster
If the PDC emulator is down: time sync, password change urgent replication, and lockout handling suffer, and clients get logon slowdowns. Fix or transfer the role (Move-ADDirectoryServerOperationMasterRole).
SEIZING a role is a last resort (only when the old holder will NEVER return). Prefer transfer. Read Microsoft's guidance first.
Global Catalog: at least one GC per site. In multi-domain forests, logins can fail or be slow when no GC is reachable (universal group membership lookup). Get-ADDomainController -Filter * | Select Name,IsGlobalCatalog.

Health-check script (Windows PowerShell): are all DCs reachable and answering?
Import-Module ActiveDirectory
$ports = 53,88,135,389,445,464,636,3268
Get-ADDomainController -Filter * | ForEach-Object {
    $dc = $_.HostName
    $row = [ordered]@{ DC = $dc; Site = $_.Site }
    foreach ($p in $ports) {
        $row["p$p"] = (Test-NetConnection $dc -Port $p -WarningAction SilentlyContinue -InformationLevel Quiet)
    }
    [pscustomobject]$row
} | Format-Table -AutoSize
Anything that says False in a column that should be open (or a DC that is missing entirely) is a lead.

Health-check script (Linux): can this host reach and use each DC?
domain=corp.example.com
for dc in $(dig +short -t SRV _ldap._tcp.dc._msdcs.$domain | awk '{print $4}' | sed 's/\.$//'); do
    printf '%-35s' "$dc"
    for p in 88 389 445; do nc -z -w2 "$dc" $p && printf ' %s:ok' "$p" || printf ' %s:FAIL' "$p"; done
    echo
done
time dig +short -t SRV _kerberos._tcp.$domain

Time the login and read the logs:
time su - jsmith@corp.example.com -c true                    # or time ssh jsmith@corp.example.com@server01 true
sudo journalctl -u sssd -f    ;    sudo tail -f /var/log/sssd/sssd_pam.log /var/log/sssd/sssd_corp.example.com.log
Set debug_level = 6 in [pam], [nss] and [domain/corp.example.com] in /etc/sssd/sssd.conf, restart sssd, reproduce, read the timestamps, then remove debug_level again.
Look for gaps of exactly 6, 10, 15 or 30 seconds: these are timeouts of one specific step (DNS, connect, LDAP, Kerberos).
Common causes and fixes:
SSSD tries an unreachable DC first                     Set  ad_server = dc01.corp.example.com, dc02.corp.example.com  (a preferred list) and  ad_backup_server = dc03.corp.example.com   or set  ad_site = YourSite  so DNS discovery favors local DCs
Long timeouts for dead servers                         Lower them in [domain/...]:  dns_resolver_timeout = 3    ldap_network_timeout = 3    ldap_opt_timeout = 3    krb5_auth_timeout = 10    (the defaults are longer)
DNS problems                                           /etc/resolv.conf should list AD DNS servers with options timeout:1 attempts:2 rotate   Check  dig SRV _ldap._tcp.dc._msdcs.corp.example.com  and reverse lookups
Kerberos cannot find a KDC                             dig SRV _kerberos._tcp.corp.example.com ; nc -zv dc01 88 ; in /etc/krb5.conf keep dns_lookup_kdc = true and dns_lookup_realm = false (or set explicit kdc = lines)
Reverse DNS or canonicalization delays                 In /etc/krb5.conf [libdefaults]  rdns = false  and  dns_canonicalize_hostname = false  (test carefully: needs matching SPNs)
sshd waits on GSSAPI or DNS                            In sshd_config: UseDNS no ; if you do not use Kerberos SSO set GSSAPIAuthentication no. On the SSH client: -o GSSAPIAuthentication=no shows whether it is the culprit
Large group lookups                                    Users in hundreds of groups make the initial lookup slow. Trim groups, use ldap_group_nesting_level, or turn off nested lookups if not needed. Caching helps after the first login
Cache problems / stale data                            sudo sss_cache -E ; sudo systemctl restart sssd ; last resort: sudo systemctl stop sssd ; sudo rm -f /var/lib/sss/db/* /var/lib/sss/mc/* ; sudo systemctl start sssd
Machine trust broken                                   sudo adcli testjoin ; sudo klist -k ; rejoin with  sudo realm leave && sudo realm join -U adminuser corp.example.com
SSSD is in "offline" mode                              sudo sssctl domain-status corp.example.com. When a DC is unreachable SSSD goes offline, uses cached credentials, and retries every so often (offline_timeout). Fix the network, then sudo sss_cache -E and check again
Kerberos ticket problems on Linux
kinit fails with "Cannot contact any KDC for realm"         DNS or port 88 (see above)          "Clock skew too great"           Fix chrony          "Preauthentication failed"    Wrong password, or the account is locked/expired
klist shows expired tickets, and SSH/NFS/web SSO stops      kinit again, or let SSSD renew (krb5_renew_interval = 3600). Check credential cache type: KEYRING or KCM caches can be invisible to some tools (echo $KRB5CCNAME)
NFS or SMB with Kerberos fails after long uptime            Machine ticket cache expired: run  sudo kinit -k -t /etc/krb5.keytab 'SERVER01$@CORP.EXAMPLE.COM'  and restart the service (rpc-gssd, sssd)
"Server not found in Kerberos database" with an alias name  Use the real FQDN, or register an SPN for the alias in AD (setspn -S) and ensure DNS matches
Keytab out of date after a password change                  Regenerate the keytab (net ads keytab create, or rejoin). Check the key version (kvno) against the keytab (klist -ke)

- At least TWO domain controllers per site with users (and a Global Catalog in each). Never a single DC
- Client DNS = AD DNS only (local DC first), and no public DNS servers on domain-joined machines
- Correct subnets in AD Sites and Services, and every subnet mapped to a site. Review after network changes
- Demote DCs properly, and clean DNS and metadata at once. Enable DNS scavenging with sensible intervals
- A reliable time hierarchy: PDC emulator syncs to external NTP, everything else follows the domain. Disable hypervisor time sync on DCs when it conflicts
- Monitor: DC services (NTDS, DNS, Netlogon, KDC, W32Time, DFSR), replication (repadmin /replsummary daily), disk space, event IDs (NETLOGON 5719/5805, Kerberos errors, DNS 4013), and time offset
- Monitor login speed: a synthetic test that times nltest /dsgetdc and an LDAP bind, from each site
- Back up System State of DCs regularly and test restores. Never restore a DC from a plain VM snapshot
- Use gMSAs for services, review SPNs (setspn -X monthly), keep service account passwords rotated
- Keep DCs patched, and test Microsoft's Kerberos hardening changes (RC4, PAC validation) in a lab first. Read the KB articles before installing
- Document your AD design: sites, subnets, DCs and their roles, DNS zones, time source, and the decommission procedure

- The exact error text, time (with time zone), user, computer, and site, and how long the delay is
- nltest /dsgetdc:corp.example.com /force, echo %LOGONSERVER%, ipconfig /all, klist, klist tgt, whoami /groups (from the affected client)
- dcdiag /v output and repadmin /showrepl (from the DC), plus relevant Security, System, GroupPolicy and Directory Service events
- Time state: w32tm /query /status on both client and DC
- For Linux: sssd.conf (redacted), sssd logs at debug_level 6, KRB5_TRACE output, klist -e, dig SRV results, and chronyc tracking
- A short packet capture of the login (see the Wireshark sheet): filter kerberos || ldap || dns
Redact passwords and sensitive data before you share logs or captures.

    Work through the chain in order: DNS, time, DC selection, Kerberos, secure channel, Group Policy. Do not guess.

    Fixed, repeatable delays (30, 60, 90 seconds) mean timeouts. Find the dead DC or stale DNS record that the client tries first.

    nltest /dsgetdc /force and klist show most of what you need in seconds. On Linux use KRB5_TRACE and sssctl.

    A stale or missing SRV record, a subnet not mapped to a site, or a public DNS server on a client causes a large share of slow logins.

    Clock skew, expired passwords, locked accounts and expired tickets all look like "login failed". Check them in that order, then read the event codes.

    Group changes need a new logon (or purged tickets) to show up in the token. Duplicate SPNs cause intermittent Kerberos failures.

    Never restore a DC from a snapshot, and never reconnect a DC that was offline longer than the tombstone lifetime.

    Change one thing at a time, and record the time and the effect. Take backups before metadata cleanup, DNS cleanup or role changes.

    Demote domain controllers properly, keep at least two per site, and monitor replication and time so problems are caught before users complain.

    Product behavior and security updates change how Kerberos and NTLM behave over time. Confirm details in Microsoft's and your Linux vendor's current documentation.