When a domain controller (DC) goes offline, Windows clients exhibit specific authentication behaviors:
- Cached Credentials: Users who have previously logged on can still authenticate using locally cached credentials (default cache duration: 30 days)
- New Users Blocked: First-time logins fail as there's no cached profile
- Time Synchronization Issues: Kerberos authentication may fail if client clocks drift significantly
# PowerShell to check cached logon info
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name "CachedLogonsCount"
Network operations are affected differently:
| Resource Type | Availability | Notes |
|---|---|---|
| DC-hosted shares | Unavailable | Complete failure |
| Member server shares | Available* | If previously connected with persistent credentials |
| Client-to-client shares | Available | Uses local accounts/workgroup auth |
# Command to map drive with explicit credentials
net use Z: \\fileserver\share /persistent:yes /user:domain\username password
Post-recovery behavior includes:
- Group Policy Updates: Will apply at next refresh cycle (90-120 min random interval)
- DNS Registration: Clients automatically reregister with DC when it's back online
- No Restart Required: Most services recover dynamically, though some applications may need restart
# Force group policy update
gpupdate /force
Typical issues reported during outages:
- "I can't log in" (new users)
- "My mapped drives disappeared"
- "I can't access [DC-hosted application]"
- "Password changes won't sync"
- "Certificate-based auth failures"
Proactive measures to minimize impact:
# PowerShell to check DC availability
Test-Connection -ComputerName "yourdc.domain.com" -Count 1 -Quiet
# Alternative authentication provider configuration
nltest /sc_reset:domain.com
Key architectural recommendations:
- Implement RODC for branch offices
- Configure DFS for critical shares
- Maintain proper time synchronization hierarchy
- Implement credential caching policies
When a domain controller (DC) becomes unavailable, Windows clients rely on cached credentials for authentication. Here's what happens:
- Existing logged-in users: Continue working normally with their current session
- New logins: Users who previously logged into the machine can authenticate using cached credentials
- First-time logins: Users who never logged into that specific machine before will be denied access
# Check cached credential policy (run on client)
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name "CachedLogonsCount"
File sharing behavior depends on the authentication method and share location:
| Share Type | Behavior During DC Outage |
|---|---|
| DC-hosted shares | Completely inaccessible |
| Member server shares | Accessible if using cached credentials |
| Client-to-client shares | Works if both clients have cached credentials |
When the DC comes back online:
- No reboot required - clients automatically reconnect
- Group Policy updates may be delayed until next refresh cycle
- Password changes made during the outage won't sync until next successful DC contact
# Force Group Policy update after DC recovery
gpupdate /force
# Check domain connectivity status
Test-ComputerSecureChannel -Repair
Expect these issues during a DC outage:
- "I can't log in to this computer I've never used before"
- "My mapped drives aren't working" (for DC-hosted shares)
- "I changed my password but it's not working on other computers"
- "Some applications give authentication errors" (especially those requiring Kerberos)
Consider implementing these measures:
# Configure client-side registry settings for better outage handling
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name "NegativeCachePeriod" -Value 300
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" -Name "BackgroundRetryInitialPeriod" -Value 60
For critical systems, implement a secondary DC or consider Azure AD hybrid join for cloud-based authentication fallback.