Hello! In this sixth installment of the series, we cover Troubleshooting - common problems and how to solve them.

In the previous installment (Part 5), we looked at how Integrated Windows Authentication behaves in the browser.

By understanding the concept of the intranet zone, it became clear why authentication behaves differently for the same server depending on how the URL is written (NetBIOS name, FQDN, or IP address). We also learned why integrated authentication is disabled by default in Chrome and Firefox, and how to configure it at scale with Group Policy.

In the real world, though, there always comes a moment when the configuration should be perfect and yet somehow it just does not work.

"Access to the file server has been slow lately." "It worked on Friday, but I can't log in on Monday morning." "Kerberos fails only for one particular service." These are the classic tickets that land on the help desk every day.

The causes range widely — Kerberos failures, clock skew, SPN misconfiguration, DNS issues — but with systematic troubleshooting they can always be resolved.

In this installment, we organize the problems that frequently occur in AD environments by pattern, and walk through a practical troubleshooting flow: from pinpointing causes with diagnostic commands to concrete resolution steps. Working through things calmly, one at a time, is the shortest path to a fix. Let's get started!

Series overview

• Chapter 1: Understanding the basics - Fundamentals of Active Directory and Kerberos/NTLM authentication
• Chapter 2: Building a domain environment - Setting up a lab environment
• Chapter 3: Joining clients and servers to the domain - Domain join in detail
• Chapter 4: Proxy servers and Integrated Windows Authentication
• Chapter 5: Browser configuration and authentication - Settings for each browser
• [★ This installment ★] Chapter 6: Troubleshooting - Common problems and solutions
• Chapter 7: Security and best practices - Considerations for production environments
• Chapter 8: Practical configuration examples - Integration with AI security tools

Chapter 6: Troubleshooting

6.1 Authentication problems

6.1.1 Why Kerberos fails and falls back to NTLM

Kerberos is the most secure authentication method, but it can fail for a variety of reasons and fall back to NTLM. This can also degrade performance.

[Typical symptom]
User: "Access to the file server has been slow lately."
IT admin: "Let's check the logs."

Event log:
Kerberos authentication failed.
Falling back to NTLM.

IT admin: "Kerberos is failing. Let's find out why."

Let's look at running the diagnostic commands.

[Kerberos diagnostics]
# Check current tickets
klist

Result (healthy):
Cached Tickets: 2
#0> Client: tanaka_t @ JP.QUALITEG.COM
    Server: krbtgt/JP.QUALITEG.COM @ JP.QUALITEG.COM
    Encryption type: AES-256-CTS-HMAC-SHA1-96
    Ticket expires: 2024/01/20 18:00:00

Result (problem):
Cached Tickets: 0
→ No ticket has been obtained

# Test ticket acquisition
kinit tanaka_t@JP.QUALITEG.COM

Common cause 1: DNS-related problems.

[When DNS is the cause]
Situation: works with the NetBIOS name, fails with the FQDN

Test:
# NetBIOS name
ping fileserver → success
Access: \\fileserver\share → success (NTLM)

# FQDN
ping fileserver.jp.qualiteg.com → success
Access: \\fileserver.jp.qualiteg.com\share → slow (Kerberos fails → NTLM)

Investigation:
nslookup fileserver.jp.qualiteg.com
→ forward lookup OK

nslookup 192.168.1.50
→ reverse lookup fails!

IT admin: "The reverse DNS record is missing."

Fix:
Add a PTR record to the reverse lookup zone in DNS Manager
50.1.168.192.in-addr.arpa. → fileserver.jp.qualiteg.com.

Common cause 2: SPN (Service Principal Name) problems.

[When the SPN is the cause]
Symptom: Kerberos fails only for a specific service

Check command:
setspn -L fileserver

Result (no problem):
Registered ServicePrincipalNames:
    HOST/fileserver
    HOST/fileserver.jp.qualiteg.com

Result (problem):
Registered ServicePrincipalNames:
    (empty)

Or a duplicate error:
setspn -X
Duplicate SPNs found:
    HTTP/intranet.jp.qualiteg.com
    → registered on both Server A and Server B

Fix:
# Add the SPN
setspn -A HOST/fileserver.jp.qualiteg.com FILESERVER$

# Remove the duplicate
setspn -D HTTP/intranet.jp.qualiteg.com ServerB

Let's also look at encryption type mismatches.

[Encryption incompatibility]
Windows Server 2019 admin: "Authentication got slower after we added a new DC."

Investigation:
# Check the supported encryption types
Group Policy:
Network security: Configure encryption types allowed for Kerberos

Old server: RC4-HMAC (deprecated)
New server: AES256-CTS-HMAC-SHA1-96

Problem:
Legacy app: "I can only speak RC4."
New DC: "RC4 is disabled."
Result: Kerberos failure

Fix:
1. Temporarily re-enable RC4 (a security risk)
2. Update the application (recommended)

6.1.2 Why time synchronization matters

In Kerberos authentication, time synchronization is critical. A skew of more than 5 minutes causes authentication to fail.

[Authentication failure caused by clock skew]
Monday morning:
Tanaka: "It worked on Friday, but now I can't log in!"
Error: "There are currently no logon servers available to service the logon request."

IT admin: "Let's check the clocks."

Client PC: 2024/01/20 09:00:00
DC: 2024/01/20 09:07:00
Difference: 7 minutes

IT admin: "That's more than 5 minutes of skew. This is the cause."

Let's understand how time synchronization works.

[The Windows time sync hierarchy]
Correct configuration:
Internet time server (time.windows.com)
    ↓
PDC emulator (DC01)
    ↓
Other DCs (DC02, DC03)
    ↓
Member servers and client PCs

Check commands:
# Check the time source
w32tm /query /source

Healthy: DC01.jp.qualiteg.com
Problem: Local CMOS Clock → not synchronizing

# Detailed status
w32tm /query /status

Here is how to fix time synchronization.

[Time sync configuration]
On the PDC emulator:
# Configure external time sources
w32tm /config /manualpeerlist:"time.windows.com,0x9 ntp.nict.jp,0x9" /syncfromflags:manual /reliable:yes /update

# Restart the service
net stop w32time && net start w32time

# Sync immediately
w32tm /resync /rediscover

On the other DCs:
# Sync from the PDC emulator
w32tm /config /syncfromflags:domhier /update

On client PCs:
# Usually automatic, but can be configured manually
w32tm /config /syncfromflags:domhier /update

Let's troubleshoot time synchronization.

[Common time sync problems]
Problem 1: NTP blocked by a firewall
Symptom:
w32tm /stripchart /computer:time.windows.com
Error: 0x800705B4 - timeout

Fix:
Open UDP port 123

Problem 2: VM time sync conflicts
Symptom:
VM: "I'll sync with the host."
DC: "No, sync with NTP."
Result: the clock never stabilizes

Fix:
VMware: disable time sync in VMware Tools
Hyper-V: disable time sync in Integration Services

Problem 3: Large clock skew
Symptom:
w32tm /resync
The resync command was sent to the computer, but an error
occurred because no time data was available.

Cause: the skew is too large for automatic correction (typically over 48 hours)

Fix:
# Manually set the clock close to the correct time, then sync
net time \\DC01 /set /y

6.1.3 Configuring SPNs (Service Principal Names)

An SPN is the name that uniquely identifies a service in Kerberos authentication. If it is not configured correctly, Kerberos authentication fails.

[What is an SPN?]
Newcomer: "What is an SPN?"
IT admin: "Think of it as a service's street address."

By analogy:
Tanaka's home = HOST/tanaka-pc.jp.qualiteg.com
  Location: tanaka-pc.jp.qualiteg.com
  Purpose: HOST (computer)

Company web server = HTTP/intranet.jp.qualiteg.com
  Location: intranet.jp.qualiteg.com  
  Purpose: HTTP (web service)

Kerberos: "Please give me a ticket for HTTP/intranet.jp.qualiteg.com."
KDC: "Searching for the SPN... found it! Issuing the ticket."

Let's check and register SPNs.

[Managing SPNs]
# Check the SPNs of a specific account
setspn -L IIS_Service

# Check the SPNs of a computer account  
setspn -L SERVER01$

Typical SPNs:
HOST/server01
HOST/server01.jp.qualiteg.com
TERMSRV/server01
TERMSRV/server01.jp.qualiteg.com
RestrictedKrbHost/server01
RestrictedKrbHost/server01.jp.qualiteg.com

# Example: registering SPNs for an IIS server
# when the application pool runs under a specific account
setspn -A HTTP/webapp.jp.qualiteg.com JP\webapp_svc
setspn -A HTTP/webapp JP\webapp_svc

Let's look at SPN-related trouble.

[The duplicate SPN problem]
Symptom: authentication error when accessing a website

Investigation:
setspn -X
Processing...
Duplicates found:
HTTP/intranet.jp.qualiteg.com is registered on:
  - SERVER01$
  - intranet_svc

IT admin: "The same SPN is on two accounts!"

How it happened:
1. The site initially ran under SERVER01's computer account
2. It was later switched to a service account (intranet_svc)
3. Nobody deleted the old SPN

Fix:
setspn -D HTTP/intranet.jp.qualiteg.com SERVER01$
→ delete the old one

Let's look at the relationship between application pools and SPNs.

[A real-world IIS example]
Scenario: building an internal portal site

Configuration:
- URL: http://portal.jp.qualiteg.com
- Application pool: PortalAppPool
- Run-as account: JP\portal_svc

Required steps:
1. Create the service account
New-ADUser -Name "portal_svc" -AccountPassword (ConvertTo-SecureString "P@ssw0rd" -AsPlainText -Force) -Enabled $true

2. Register the SPNs
setspn -A HTTP/portal.jp.qualiteg.com JP\portal_svc
setspn -A HTTP/portal JP\portal_svc

3. Configure IIS
- Application pool → Advanced Settings → Identity → portal_svc
- Authentication → Windows Authentication: enabled, Anonymous Authentication: disabled

4. Verify
setspn -L portal_svc
→ confirm the SPNs are listed

6.1.4 DNS-related problems

DNS misconfiguration accounts for the majority of trouble in AD environments. If DNS is wrong, name resolution fails before authentication even begins.

[A typical DNS problem]
User: "I can't reach the file server."
IT: "Try pinging it."
User: "ping fileserver"
Result: Ping request could not find host fileserver

IT: "Let's check the DNS suffix."
ipconfig /all
DNS suffix: (empty) ← the problem!

Let's look at DNS suffix configuration.

[Why the DNS suffix matters]
Correct configuration:
Primary DNS suffix: jp.qualiteg.com
DNS suffix search list: jp.qualiteg.com, tokyo.jp.qualiteg.com

Behavioral difference:
# Without a suffix
ping fileserver
→ looks up "fileserver" → fails

# With a suffix  
ping fileserver
→ looks up "fileserver.jp.qualiteg.com" → succeeds

How to configure:
1. Via DHCP (recommended)
   Option 015: jp.qualiteg.com

2. Manually
   Network adapter → Properties → Advanced → DNS
   "DNS suffix for this connection": jp.qualiteg.com

Let's look at forward and reverse DNS problems.

[Why reverse DNS matters]
Symptoms:
- Access by name: succeeds
- Access by IP: authentication takes a long time

Investigation:
# Forward lookup test
nslookup server01.jp.qualiteg.com
→ 192.168.1.20

# Reverse lookup test  
nslookup 192.168.1.20
→ *** dns1.jp.qualiteg.com can't find 192.168.1.20: Non-existent domain

Cause: no reverse lookup zone, or no record in it

Fix:
1. Create a reverse lookup zone in the DNS management tool
   - New Zone → Reverse Lookup Zone
   - Network ID: 192.168.1

2. Add a PTR record
   - 20 → server01.jp.qualiteg.com.

Let's look at DNS cache problems.

[Trouble caused by stale DNS data]
Situation: after changing a server's IP address

User: "I can't reach the new server."
IT: "Let's check DNS."

# Query the DNS server directly
nslookup server01.jp.qualiteg.com 192.168.1.10
→ 192.168.1.50 (new IP)

# But ping still goes to the old IP
ping server01.jp.qualiteg.com
→ pinging 192.168.1.20 (old IP)

Cause: the local DNS cache

Fix:
ipconfig /flushdns
→ clear the DNS cache

Verify:
ipconfig /displaydns
→ show the cache contents

Let's look at configuring conditional forwarders.

[DNS across multiple domains]
Scenario: integrating with another domain after an acquisition

Environment:
- Our company: jp.qualiteg.com (192.168.1.0/24)
- Acquired company: acquired.local (192.168.2.0/24)

Problem:
nslookup server.acquired.local
→ not found

Fix: a conditional forwarder
DNS Manager → Conditional Forwarders → New
- DNS domain: acquired.local
- IP address: 192.168.2.10 (the acquired company's DNS)

Result:
Queries for acquired.local are forwarded to 192.168.2.10

6.2 Domain join problems

6.2.1 The "domain not found" error

This is the most common error when joining a domain. The causes vary widely, but systematic troubleshooting will get you to a resolution.

[Typical error message]
Error:
"Could not connect to the domain "jp.qualiteg.com".
(The domain either does not exist or could not be contacted.)"

Junior IT: "But the domain name is correct..."
Senior: "Let's check things in order."

Step 1: check network connectivity.

[Basic connectivity checks]
# Check the IP address
ipconfig /all

What to look for:
- IP address: 169.254.x.x → not reaching the DHCP server
- IP address: 192.168.1.x → OK
- DNS server: 192.168.1.1 → pointing at the router (bad)
- DNS server: 192.168.1.10 → pointing at the DC (good)

# Check reachability to the DC
ping 192.168.1.10
→ confirm you get a response

Step 2: check DNS name resolution.

[DNS resolution tests]
# Resolve the domain name
nslookup jp.qualiteg.com

Healthy response:
Server:  dc01.jp.qualiteg.com
Address: 192.168.1.10

Name:    jp.qualiteg.com
Addresses: 192.168.1.10, 192.168.1.11

Problematic response:
*** dc01.jp.qualiteg.com can't find jp.qualiteg.com: Non-existent domain

# Check the SRV records (important)
nslookup -type=srv _ldap._tcp.jp.qualiteg.com

Healthy response:
_ldap._tcp.jp.qualiteg.com    SRV service location:
    priority       = 0
    weight         = 100  
    port          = 389
    svr hostname  = dc01.jp.qualiteg.com

Step 3: check the firewall.

[Checking the required ports]
# Check ports with PowerShell
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 389
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 445
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 88
Test-NetConnection -ComputerName dc01.jp.qualiteg.com -Port 135

Required ports:
- 88 (Kerberos)
- 135 (RPC Endpoint Mapper)
- 389 (LDAP)
- 445 (SMB)
- 636 (LDAPS)
- 3268 (Global Catalog)

Temporarily disabling Windows Firewall (for testing only):
netsh advfirewall set allprofiles state off
* Be sure to re-enable it after testing

6.2.2 Dealing with authentication errors

What to do when the domain is found but authentication fails.

[Types of authentication errors]
Error 1:
"Logon failure: unknown user name or bad password."

Error 2:
"The specified domain either does not exist or could not be contacted."

Error 3:
"There are currently no logon servers available to service the logon request."

Let's look at username format problems.

[Correct username formats]
Common mistakes:
× administrator (no domain specified)
× tanaka_t (a regular user)
× admin (a non-existent user)

Correct formats:
○ JP\Administrator
○ Administrator@jp.qualiteg.com
○ jp.qualiteg.com\Administrator

# Check the current domain admins
net group "Domain Admins" /domain

Let's check the account status.

[Administrator account problems]
# Run on the DC (check account status)
net user Administrator /domain

What to look for:
- Account active: Yes
- Account expires: Never
- Password expires: Never
- Account locked out: No

# If the account is disabled or locked out
net user Administrator /active:yes /domain

# Password reset (last resort)
net user Administrator NewP@ssw0rd /domain

Let's confirm which accounts can be used for the domain join.

[Checking permissions]
# Check the members of Domain Admins
net group "Domain Admins" /domain

# Other usable groups
- Domain Admins (full rights)
- Enterprise Admins (forest-wide)  
- Account Operators (limited rights)

# Check delegated permissions
dsacls "OU=Computers,DC=jp,DC=qualiteg,DC=com"
→ verify permission to create computer objects

6.2.3 Network settings to verify

Correct network settings are essential for a successful domain join.

[Checklist-style verification]
IT admin: "Check things in this order and you'll pinpoint the problem."

□ 1. Physical connection
  - LAN cable connected
  - Link lamp lit
  - Correct VLAN

□ 2. IP address settings
  - Static or DHCP
  - Same subnet
  - No duplicates

□ 3. DNS settings
  - Primary DNS = DC
  - Secondary DNS = another DC (if any)
  - DNS suffix configured

□ 4. Reachability
  - ping the DC
  - check ports
  - check name resolution

Let's look at what to watch for when crossing VLANs.

[Considerations in VLAN environments]
Example configuration:
- VLAN 10: server segment (192.168.10.0/24)
  - DC: 192.168.10.10
- VLAN 20: client segment (192.168.20.0/24)
  - Client: 192.168.20.100

Required settings:
1. Routing
   - inter-VLAN routing enabled
   - default gateway configured for each VLAN

2. Firewall
   - required ports allowed between VLANs
   - especially 135, 445, 389, etc.

3. DNS settings
   - client DNS: 192.168.10.10
   - DNS reachable across VLANs

Check command:
tracert 192.168.10.10
→ verify the route

Let's look at how proxy settings can interfere.

[When a proxy gets in the way]
Symptom: the browser works, but the domain join fails

Cause: system proxy settings

Check:
netsh winhttp show proxy

Current WinHTTP proxy settings:
    Proxy Server: proxy:8080
    Bypass List: (none)

Problem: traffic to the DC is also being routed through the proxy

Fix:
netsh winhttp set proxy proxy:8080 bypass-list="*.jp.qualiteg.com;192.168.*"

Or reset entirely:
netsh winhttp reset proxy

Let's look at the impact of IPv6.

[IPv6-related problems]
Symptom: name resolution is slow or unstable

Check:
ipconfig /all
IPv6 address: 2001:db8::1234 (enabled)
IPv4 address: 192.168.1.100

Problem: IPv6 is preferred, but the DC is IPv4-only

Fix 1: disable IPv6 (temporary)
Network adapter → Properties
□ Internet Protocol Version 6 (uncheck)

Fix 2: prefer IPv4 (recommended)
netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 46 4
→ a policy that prefers IPv4

Working through these check points in order will resolve the vast majority of domain join problems. The key is to stay calm and verify one thing at a time.

Coming up next

Next time: "Chapter 7: Security and Best Practices - Considerations for Production Environments."

As the title suggests, the next installment is about turning an environment that works into one that works securely.

A system running correctly and a system being operated securely are two different things. Precisely because you are deploying an authentication foundation into production, security considerations are indispensable. "Basic authentication passwords are actually visible in cleartext on the network." "There are 50 accounts in Domain Admins." "Former employees' accounts are still active." By the time you notice problems like these, it can already be too late.

Next time, we will cover the fundamental risks inherent in Basic authentication, best practices such as password management and minimizing administrative privileges, and concrete ways to implement monitoring, logging, and periodic audits — a complete picture of security with production operations in mind.

See you in Part 7!