Active Directory Bağlantı Sorunlarını Giderme

Tarafındankomut
0 Comments

Active Directory ortamında bağlantı sorunları yaşamak, özellikle production ortamında can sıkıcı bir durum. Sabahın 7’sinde telefon çalıyor, kullanıcılar domain’e giriş yapamıyor, servisler ayağa kalkmıyor. Bu tür senaryolarla karşılaştığımda yıllar içinde edindiğim deneyimleri bu yazıda paylaşacağım. Adım adım, sistematik bir yaklaşımla AD bağlantı sorunlarını nasıl çözeceğinizi ele alacağız.

Temel Tanı: Nerede Duruyoruz?

Soruna atlamadan önce durumu netleştirmek gerekiyor. AD bağlantı sorunları genellikle üç kategoriye giriyor:

  • Domain Controller erişim sorunları: İstemci DC’ye ulaşamıyor
  • Authentication sorunları: DC’ye ulaşılıyor ama kimlik doğrulama başarısız
  • DNS sorunları: AD tamamen DNS’e bağımlı, DNS bozulunca her şey bozuluyor
  • Replication sorunları: DC’ler arasında veri tutarsızlığı
  • Time sync sorunları: Kerberos zaman toleransı aşılıyor

İlk adım olarak event log’larına bakıyorum. Ama önce temel komutlarla durumu değerlendiriyorum.

# Powershell ile DC bağlantısını test et
Test-ComputerSecureChannel -Verbose

# Domain controller listesini getir
nltest /dclist:yourdomain.com

# Mevcut DC bağlantısını kontrol et
nltest /dsgetdc:yourdomain.com

Bu üç komut bana hemen bir fikir veriyor. Test-ComputerSecureChannel false dönüyorsa, bilgisayar hesabının secure channel’ı bozulmuştur. nltest /dclist boş dönüyorsa DNS veya network sorunu var demektir.

DNS Sorunlarını Tespit Etmek

AD’nin DNS olmadan çalışmadığını söylemek abartı olmaz. DNS yanlış yapılandırılmışsa kullanıcılar domain’e bağlanamaz, Group Policy uygulanamaz, Kerberos ticket alınamaz. Yıllar önce bir müşteride yeni bir network cihazının DNS ayarlarını otomatik değiştirmesi nedeniyle sabah mesai başlangıcında 300 kişi birden sisteme giremedi. Çözüm 10 dakika sürdü ama tespit etmek 40 dakika aldı.

# SRV kayıtlarını sorgula - bu kayıtlar olmazsa AD çalışmaz
nslookup -type=SRV _ldap._tcp.yourdomain.com
nslookup -type=SRV _kerberos._tcp.yourdomain.com
nslookup -type=SRV _gc._tcp.yourdomain.com

# DC'nin A kaydını kontrol et
nslookup dc01.yourdomain.com

SRV kayıtları dönmüyorsa sorun kesinlikle DNS. Bu durumda kontrol edilecekler:

  • İstemcinin DNS sunucu ayarı yanlış IP’ye bakıyor olabilir
  • DC üzerindeki DNS servisi durmuş olabilir
  • AD integrated DNS zone’larda replication sorunu olabilir
# DC'nin DNS kayıtlarını yeniden kaydet
ipconfig /registerdns

# DNS önbelleğini temizle
ipconfig /flushdns

# DNS servisini yeniden başlat (DC üzerinde)
Restart-Service -Name DNS -Force

# AD DNS zone'larını kontrol et
Get-DnsServerZone -ComputerName dc01.yourdomain.com

DNS servisini yeniden başlatmak çoğu zaman işe yarıyor. Ama zone transfer sorunları varsa daha derin inceleme gerekiyor.

Secure Channel Sorunları

“The trust relationship between this workstation and the primary domain failed” hatası görüyorsanız, bilgisayar hesabının secure channel’ı bozulmuştur. Bu genellikle şu durumlarda olur: bilgisayar hesabı yanlışlıkla sıfırlandığında, bilgisayar uzun süre domain’den kopuk kaldığında veya hesap parolası senkronizasyonu bozulduğunda.

Klasik çözüm bilgisayarı domain’den çıkarıp tekrar eklemek ama bu production ortamında her zaman mümkün değil. Daha pratik yaklaşım:

# Secure channel'ı test et
Test-ComputerSecureChannel -Verbose

# Secure channel'ı onar - domain admin kredansiyeli gerekiyor
$credential = Get-Credential -Message "Domain Admin bilgileri giriniz"
Test-ComputerSecureChannel -Repair -Credential $credential

# Alternatif olarak netdom kullan
netdom resetpwd /server:dc01.yourdomain.com /userd:DOMAINAdministrator /passwordd:*

Test-ComputerSecureChannel -Repair komutu çoğu durumda işe yarıyor ve bilgisayarı yeniden başlatmadan sorunu çözüyor. Ama bazen reset yeterli olmuyor, bu durumda bilgisayar hesabını AD’de sıfırlamak gerekiyor:

# AD'de bilgisayar hesabını sıfırla (DC üzerinde veya RSAT ile)
Reset-ComputerMachinePassword -Server dc01.yourdomain.com -Credential (Get-Credential)

# Veya AD modülü ile
Import-Module ActiveDirectory
Set-ADComputer -Identity "BILGISAYAR_ADI" -Reset

Kerberos Authentication Sorunları

Kerberos sorunları genellikle şu hataları üretiyor: “KDC_ERR_PREAUTH_FAILED”, “The Kerberos client received a KRB_AP_ERR_MODIFIED” veya event ID 4771. En yaygın nedeni zaman senkronizasyon sorunudur. Kerberos varsayılan olarak 5 dakikalık zaman toleransına sahip. İstemci ile DC arasındaki zaman farkı 5 dakikayı geçerse authentication tamamen başarısız olur.

# Mevcut zamanı kontrol et
w32tm /query /status

# Domain hiyerarşisindeki NTP kaynağını görüntüle
w32tm /query /source

# Zaman senkronizasyonunu zorla
w32tm /resync /force

# DC ile zaman farkını test et
w32tm /stripchart /computer:dc01.yourdomain.com /dataonly /samples:5

Bir şirkette VM snapshot’larından geri dönülen bir ortamda tüm sunucularda Kerberos hataları almıştık. Snapshot öncesi ve sonrası zaman farkı 2 saatten fazlaydı. w32tm /resync /force komutu kısa sürede sorunu çözdü.

Zaman sorunu değilse, SPN (Service Principal Name) kayıtlarına bakıyorum:

# Duplicate SPN kayıtlarını bul - bu ciddi bir sorun
setspn -X -F

# Belirli bir hesabın SPN kayıtlarını listele
setspn -L DOMAINServiceAccount

# Yanlış SPN'i sil
setspn -D MSSQLSvc/sunucu.domain.com:1433 DOMAINEskiHesap

# Doğru SPN'i ekle
setspn -A MSSQLSvc/sunucu.domain.com:1433 DOMAINYeniHesap

Duplicate SPN ciddi bir sorun. Kerberos hangi hesaba ticket vereceğini bilemez ve authentication başarısız olur. setspn -X -F komutu forest genelinde duplicate SPN’leri bulur, mutlaka çalıştırın.

LDAP Bağlantı Sorunları

Bazı uygulamalar AD’ye LDAP ile bağlanıyor. Bu bağlantılarda sorun yaşanıyorsa hem uygulama hem de DC tarafını incelemek gerekiyor.

# LDAP bağlantısını test et
$LDAP = "LDAP://dc01.yourdomain.com:389"
$Auth = [System.DirectoryServices.AuthenticationTypes]::Secure
$Entry = New-Object System.DirectoryServices.DirectoryEntry($LDAP, "DOMAINtestuser", "password", $Auth)
$Entry.Name

# Alternatif - ldp.exe ile test (GUI araç, ama scriptten de çağırılabilir)
# ldp.exe'yi açıp Connection > Connect ile test edin

# Portları test et
Test-NetConnection -ComputerName dc01.yourdomain.com -Port 389
Test-NetConnection -ComputerName dc01.yourdomain.com -Port 636  # LDAPS
Test-NetConnection -ComputerName dc01.yourdomain.com -Port 3268 # Global Catalog
Test-NetConnection -ComputerName dc01.yourdomain.com -Port 3269 # GC SSL

Port 389 açık ama uygulama bağlanamıyorsa, LDAP signing veya channel binding politikaları devreye girmiş olabilir. Windows Server 2019 ve sonrasında varsayılan güvenlik ayarları daha katı. Uygulama eski LDAP signing desteklemiyorsa event log’da şu hatayı görürsünüz: Event ID 2886, 2887, 2888, 2889.

Replication Sorunlarını Tespit Etmek

Multi-site veya multi-DC ortamlarda replication sorunları kullanıcıların bir DC’de yaptığı değişikliğin diğer DC’ye yansımamasına neden olur. Kullanıcı şifresini değiştiriyor, bir DC’de giriş yapabiliyor ama diğerinde yapamıyor gibi şikayetler alıyorsanız replication’a bakın.

# Replication durumunu kontrol et
repadmin /replsummary

# Detaylı replication hatalarını göster
repadmin /showrepl

# Tüm DC'lerin replication durumu
repadmin /replsum * /bysrc /bydest /errorsonly

# Replication'ı zorla
repadmin /syncall /AdeP

# Domain genelinde replication sağlığını kontrol et
dcdiag /test:replications /v

repadmin /replsummary çıktısında “Fail” sayısı sıfır olmalı. Hata görüyorsanız repadmin /showrepl ile hangi DC’ler arasında sorun olduğunu tespit edin.

Sık karşılaştığım bir senaryo: Site link’lerin yanlış yapılandırılması nedeniyle iki site arasında replication tamamen duruyor. Bir şirkette farklı şehirdeki DC 45 gün replication yapamamıştı. Bu durumda “tombstone lifetime” sorunuyla karşılaşabilirsiniz, silinmiş nesneler kalıcı hale geliyor ve DC’yi domain’den çıkarıp yeniden eklemeniz gerekebilir.

# Tombstone lifetime değerini kontrol et (varsayılan 180 gün)
(Get-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=yourdomain,DC=com" -Properties tombstoneLifetime).tombstoneLifetime

# SYSVOL replication durumu
dfsrdiag SyncStatus /Member:dc01.yourdomain.com

DCDiag ile Kapsamlı Sağlık Kontrolü

DCDiag en değerli araçlardan biri. Tek komutla onlarca testi çalıştırıp DC’nin genel sağlığını değerlendiriyor.

# Tüm testleri çalıştır ve dosyaya kaydet
dcdiag /test:all /v /f:C:dcdiag_raporu.txt

# Sadece kritik testler
dcdiag /test:connectivity /test:netlogons /test:services /test:fsmocheck

# Uzak DC'yi test et
dcdiag /s:dc02.yourdomain.com /test:all

# DNS testleri
dcdiag /test:dns /DnsAll /v

DCDiag çıktısında “PASSED” veya “FAILED” görürsünüz. FAILED olanları tek tek inceleyin. En sık FAILED gördüğüm testler:

  • Connectivity: DC’ye temel ağ bağlantısı yok
  • Netlogons: Netlogon servisi çalışmıyor veya sorunlu
  • FsmoCheck: FSMO rol sahipleri ulaşılamaz durumda
  • Advertising: DC kendini düzgün duyurmuyur
  • KccEvent: Knowledge Consistency Checker hataları var

Netlogon Servisi ve Güvenli Kanal

Netlogon servisi AD’nin omurgasından biri. Bu servis durunca kullanıcılar authentication yapamaz, Group Policy uygulanamaz. Özellikle güncellemeler sonrasında veya disk dolu durumlarda Netlogon bazen takılı kalabiliyor.

# Netlogon servis durumunu kontrol et
Get-Service Netlogon

# Servisi yeniden başlat
Restart-Service Netlogon -Force

# Netlogon log'larını etkinleştir (çok detaylı debugging için)
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesNetlogonParameters" -Name "DBFlag" -Value 0x2080FFFF

# Log dosyasının konumu
# C:Windowsdebugnetlogon.log

# Logging'i kapat (performans için önemli)
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesNetlogonParameters" -Name "DBFlag" -Value 0x0

Netlogon debug log’u açıldığında C:Windowsdebugnetlogon.log dosyasına detaylı bilgi yazılır. Authentication başarısızlıklarında hangi kullanıcının, hangi makineden, hangi nedenden dolayı başarısız olduğunu görebilirsiniz. Ama bu log çok büyüyebilir, işiniz bitince kapatmayı unutmayın.

Group Policy Uygulanma Sorunları

Kullanıcılar sisteme girebiliyor ama GPO uygulanmıyor ya da yanlış GPO uygulanıyorsa:

# GPO uygulamalarını zorla ve detay gör
gpupdate /force /sync

# GPO sonuç raporunu oluştur
gpresult /H C:gpo_raporu.html

# Komut satırında GPO sonucu
gpresult /R

# Belirli bir kullanıcı için
gpresult /user DOMAINkullanici /R

# SYSVOL erişimini test et
Test-Path "\yourdomain.comSYSVOLyourdomain.comPolicies"

SYSVOL erişimi yoksa GPO’lar hiç uygulanamaz. SYSVOL bir DFS namespace üzerinden paylaşılıyor ve replication’a bağımlı. SYSVOL sorunlarında:

# DFSR servis durumunu kontrol et
Get-Service DFSR

# DFSR replication grubunu kontrol et
dfsrdiag ReplicationState

# SYSVOL'u yeniden senkronize et (dikkatli kullanın)
dfsrdiag PollAD /Member:dc01.yourdomain.com

Event Log’lardan Faydalanmak

Sistematik debugging’de event log’lar vazgeçilmez. AD sorunlarında şu event ID’lere özellikle dikkat edin:

  • 4740: Hesap kilitlendi
  • 4771: Kerberos pre-authentication başarısız
  • 4776: NTLM authentication başarısız
  • 1006/1030: Group Policy uygulama hatası
  • 5722/5723: Secure channel sorunu
  • 1083/1084: AD replication hatası
# Son 1 saatteki authentication hatalarını bul
$StartTime = (Get-Date).AddHours(-1)
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = @(4771, 4776, 4740)
    StartTime = $StartTime
} | Select-Object TimeCreated, Id, Message | Format-List

# Replication hatalarını bul
Get-WinEvent -FilterHashtable @{
    LogName = 'Directory Service'
    Level = 2  # Error
} -MaxEvents 20 | Select-Object TimeCreated, Message

# Netlogon hatalarını bul
Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    ProviderName = 'NETLOGON'
    Level = @(1,2)  # Critical ve Error
} -MaxEvents 10 | Format-List

Event log’larını PowerShell ile filtrelemek, GUI’den bakmaktan çok daha hızlı. Özellikle 1 saatte yüzlerce event geliyorsa Get-WinEvent hayat kurtarıyor.

Firewall ve Ağ Katmanı

AD’nin çalışması için onlarca portun açık olması gerekiyor. Bir firewall kuralı değişikliği her şeyi bozabilir. Kontrol edilmesi gereken temel portlar:

  • 88: Kerberos
  • 135: RPC Endpoint Mapper
  • 389: LDAP
  • 445: SMB (SYSVOL ve NETLOGON paylaşımları için)
  • 464: Kerberos password change
  • 636: LDAPS
  • 3268: Global Catalog LDAP
  • 49152-65535: RPC dynamic ports (çok kritik)
# DC'ye temel portları test et
$DC = "dc01.yourdomain.com"
$Ports = @(88, 135, 389, 445, 464, 636, 3268)

foreach ($Port in $Ports) {
    $Result = Test-NetConnection -ComputerName $DC -Port $Port -WarningAction SilentlyContinue
    Write-Host "Port $Port : $($Result.TcpTestSucceeded)" -ForegroundColor $(if ($Result.TcpTestSucceeded) {"Green"} else {"Red"})
}

# RPC bağlantısını test et
portqry -n dc01.yourdomain.com -e 135

RPC dynamic port aralığı (49152-65535) çok geniş. Firewall bu portları kapatmışsa replication ve birçok AD servisi çalışmaz. Bu port aralığını açmak yerine firewall’da DC’ler arasına özel kural yazmak daha güvenli bir yaklaşım.

Gerçek Dünya Senaryosu: Sabah Mesai Kargaşası

Bir gün sabah 8’de çağrı aldım: “500 kişi sisteme giremiyor.” DC çalışıyor, network var, ama authentication başarısız. Event log’da yüzlerce 4771 hatası. w32tm /query /status çalıştırdım, DC zamanı 6 saat geride. Gece yapılan bir VMware maintenance’ı sırasında host’un zamanı değişmiş, VM’ler NTP’den sync almak yerine host’tan sync almış. w32tm /resync /force ve 5 dakika içinde herkes sisteme girdi. Ama bu 5 dakika kaosa yetti.

Bu deneyimden sonra tüm DC’lere şunu ekledim:

# DC'nin NTP kaynağını kalıcı olarak ayarla
# PDC Emulator'da harici NTP kaynağı kullan
w32tm /config /manualpeerlist:"0.tr.pool.ntp.org 1.tr.pool.ntp.org" /syncfromflags:manual /reliable:yes /update
Restart-Service w32tm

# Diğer DC'lerde domain hiyerarşisinden al
w32tm /config /syncfromflags:domhier /update
Restart-Service w32tm

FSMO Rolleri ve Sorunları

Flexible Single Master Operations rolleri yanlış dağıtılmışsa veya rol sahibi DC çökmüşse ciddi sorunlar çıkabilir.

# Mevcut FSMO rol sahiplerini göster
netdom query fsmo

# PowerShell ile
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster

# PDC Emulator'a ulaşılabilirliği test et
$PDC = (Get-ADDomain).PDCEmulator
Test-NetConnection -ComputerName $PDC -Port 389

PDC Emulator çok kritik: password değişikliklerini, hesap kilitlenmelerini ve zaman senkronizasyonunu yönetiyor. Bu DC çöktüğünde authentication sorunları hızla artıyor. Rol transferi gerekiyorsa:

# FSMO rollerini başka DC'ye transfer et (mevcut DC çalışıyorken)
Move-ADDirectoryServerOperationMasterRole -Identity "dc02" -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster

# Zorla ele geç (seize) - eski DC artık kullanılamıyorsa
# ntdsutil ile yapılır, dikkatli olun
ntdsutil
# activate instance ntds
# roles
# connections
# connect to server dc02.yourdomain.com
# quit
# seize PDC

FSMO seize işlemini geri almanın yolu yok. Eski DC’yi asla tekrar network’e bağlamayın.

Monitoring ve Proaktif Yaklaşım

Sorunlar çıkmadan önce tespit etmek, çıktıktan sonra çözmekten çok daha iyi. Temel bir monitoring scripti:

# AD sağlık kontrol scripti - scheduled task olarak çalıştırın
$Report = @()
$DCs = Get-ADDomainController -Filter *

foreach ($DC in $DCs) {
    $Status = [PSCustomObject]@{
        DCName = $DC.Name
        Site = $DC.Site
        Reachable = (Test-NetConnection -ComputerName $DC.HostName -Port 389 -WarningAction SilentlyContinue).TcpTestSucceeded
        NetlogonStatus = (Get-Service -ComputerName $DC.Name -Name Netlogon -ErrorAction SilentlyContinue).Status
        ADWSStatus = (Get-Service -ComputerName $DC.Name -Name ADWS -ErrorAction SilentlyContinue).Status
    }
    $Report += $Status
}

$Report | Format-Table -AutoSize

# Sorun varsa mail at
$Problems = $Report | Where-Object { -not $_.Reachable -or $_.NetlogonStatus -ne "Running" }
if ($Problems) {
    Send-MailMessage -To "[email protected]" -From "[email protected]" -Subject "AD SORUN ALGILANDI" -Body ($Problems | Out-String) -SmtpServer "mail.firma.com"
}

Sonuç

Active Directory sorunlarını gidermek sistematik bir yaklaşım gerektiriyor. Panikleyip rastgele şeyler denemek zaman kaybettirir ve bazen durumu daha da kötüleştirir. Her zaman şu sıralamayla gidiyorum: önce DNS, sonra network/firewall, sonra zaman senkronizasyonu, sonra servisler, sonra replication, en son da daha karmaşık sorunlar.

En önemli tavsiyem: düzenli sağlık kontrolleri yapın. dcdiag /test:all, repadmin /replsummary ve temel port testlerini haftalık çalıştırın. Sorun çıkmadan fark etmek, gece 2’de alarm almaktan çok daha az stresli. Ayrıca değişiklik yapmadan önce mutlaka snapshot veya yedek alın; AD’de yanlış bir hamle geri alınması saatler süren bir felakete dönüşebilir.

Bu yazıdaki komutları test ortamınızda mutlaka deneyin. Production’da ilk kez çalıştırdığınız bir komutu çalıştırmak, özellikle FSMO seize gibi geri dönüşü olmayan işlemler için, risk almak demektir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir