DNS, Domain Controller ve IP Çakışması Nasıl Tespit Edilir?

Windows Server Domain Giriş Sorunu: DNS, Domain Controller ve IP Çakışması Nasıl Tespit Edilir?

Active Directory kullanılan Windows Server ortamlarında bazı sorunlar ilk bakışta kullanıcı adı veya parola problemi gibi görünebilir.

Örneğin:

• Domain kullanıcısı doğru parolayı girdiği halde oturum açamaz.
• \\DC yazıldığında Windows tekrar kullanıcı adı ve parola ister.
• Daha önce erişilebilen ağ paylaşımlarına ulaşılamaz.
• gpupdate /force başarısız olur.
• SYSVOL veya NETLOGON paylaşımlarına erişilemez.
• nltest komutları 1355 veya 1311 hataları verir.
• DNS sorguları zaman aşımına uğrar.

Bu belirtiler görüldüğünde ilk akla gelenler genellikle Windows Update, Group Policy, NTLM, Kerberos veya kullanıcı parolasıdır.

Oysa sorun çok daha temel bir noktada “Domain Controller’a erişimde veya ağ yapılandırmasında”  olabilir.

Bu yazıda, Windows Server 2016 ve üzeri sürümlerde, Active Directory ortamında yaşanabilecek bu tür bir problemi adım adım nasıl teşhis edebileceğimizi inceleyeceğiz.

Önemli: Aşağıdaki domain ve bilgisayar adları tamamen örnektir. Gerçek sistem bilgileri kullanılmamıştır.

Örnek Active Directory Yapısı

Amaç, gerçek bir ortama ait bilgileri paylaşmadan aynı sorunları yaşayan sistem yöneticilerinin teşhis adımlarını uygulayabilmesini sağlamaktır.

Not: Bu rehberde geçen tüm komutlar, aksi belirtilmedikçe istemci üzerinde ve yönetici yetkisiyle çalıştırılmalıdır.

1. Sorunun Gerçek Yüzü: Parola Değil, İletişim Zinciri

Kullanıcı doğru parolayı girdiğini söylüyor ancak Windows oturum açmıyorsa,

doğrudan parolayı değiştirmek veya Group Policy üzerinde değişiklik yapmak doğru ilk adım değildir.

Öncelikle bilgisayarın Domain Controller’a ulaşabildiğini kontrol etmek gerekir.

Çünkü Windows’un domain hesabını doğrulayabilmesi için temel olarak şu iletişim zincirinin çalışması gerekir:

İstemci / Sunucu

       │

       ▼

     DNS

       │

       ▼

Domain Controller

       │

       ├── LDAP

       ├── Kerberos

       ├── Netlogon

       ├── SYSVOL

       └── NETLOGON

       │

       ▼

Authentication / Group Policy

Zincirin başındaki DNS veya ağ iletişimi bozuksa, kullanıcı bunu yalnızca “şifrem çalışmıyor” şeklinde görebilir.

Bu nedenle bu rehberde izlenecek yol, katman katman daraltmaktır:

Kullanıcı / Oturum

        ↓

Domain Controller keşfi

        ↓

     DNS

        ↓

  Ağ bağlantısı

        ↓

Secure Channel / Netlogon

        ↓

Kerberos / LDAP / SMB

        ↓

SYSVOL / NETLOGON

        ↓

  Group Policy

2. İstemci Tarafı Teşhis Adımları

2.1 Önce “Ben Kimim, Hangi Domain’deyim?”

Teşhise başlamadan önce istemcinin hangi kullanıcıyla, hangi domain altında ve hangi logon server üzerinden oturum açtığını kontrol etmek gerekir.

cmd üzerinde 

whoami

echo %logonserver%

echo %userdnsdomain%

whoami çıktısı:

• DOMAIN\kullaniciadi → kullanıcı domain hesabıyla oturum açmıştır.
• PC01\kullaniciadi → kullanıcı yerel bilgisayar hesabıyla oturum açmıştır. Bu durumda sonraki tüm domain testleri anlamsızdır; önce domain oturumu sorunu çözülmelidir.

%logonserver% çıktısı:

• \\DC gibi bir değer döner. Bu, oturum açma anında hangi logon server’ın kullanıldığını gösterir.

Önemli nüanslar:

• Bu değişken oturum açma anında bir kez hesaplanır; oturum sırasında DC değişse bile güncellenmez
• %logonserver% yalnızca domain oturumlarında dolu olur. Yerel hesapta boş döner.
• Kullanıcı oturumu sonlandırıp yeniden açtığında güncellenir.
• Bazı durumlarda (örneğin VPN bağlantısı sonradan kurulduğunda) yanlış DC gösterebilir.

Güncel DC için nltest /dsgetdc kullanılmalıdır.

%userdnsdomain% çıktısı:

DC: \\DC.DOMAIN.LOCAL
Address: \\192.168.10.10
Dom Name: DOMAIN.LOCAL
Forest Name: DOMAIN.LOCAL
Dc Site Name: Default-First-Site-Name
Our Site Name: Default-First-Site-Name
Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST
The command completed successfully

• DOMAIN.LOCAL dönmelidir. Boş veya beklenmeyen bir domain ise domain üyeliği ve oturum açma durumu ayrıca kontrol edilmelidir.

2.2 Domain Controller Bulunabiliyor mu?

İlk önemli testlerden biri nltest komutudur:

cmd üzerinde

nltest /dsgetdc:DOMAIN.LOCAL

Sorun yaşanan durumda şu tip bir hata görülebilir:

Getting DC name failed:

Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

Bu hata, bilgisayarın ilgili domain için kullanılabilir bir Domain Controller keşfedemediğini gösterir. Bu çıktı tek başına kullanıcı parolasının yanlış olduğunu göstermez. Tam tersine, öncelikle DC keşfi, DNS ve ağ bağlantısı araştırılmalıdır.

Başarılı bir sonuçta buna benzer bilgiler görülür:

DC: \\DC.DOMAIN.LOCAL

Address: \\192.168.10.10

Dom Name: DOMAIN.LOCAL

Forest Name: DOMAIN.LOCAL

Dc Site Name: Default-First-Site-Name

Our Site Name: Default-First-Site-Name

Flags: PDC GC DS LDAP KDC TIMESERV WRITABLE DNS_DC DNS_DOMAIN DNS_FOREST

The command completed successfully

Özellikle Dc Site Name: ve Our Site Name: satırları, istemci ile DC aynı AD site’ta mı sorusunun cevabıdır. Farklıysa site/link maliyeti yanlış yapılandırılmış olabilir.

Gerçek çıktıda Dom Guid: xxxxxxxx-xxxx-... satırı da vardır (DC ve Domain GUID’i). Bu satır iki DC’nin farklı GUID döndürmesi durumunda replikasyon sorununa işaret edebilir. 

2.3 Domain Secure Channel Durumunu Kontrol Edin

Domain’e üye bilgisayar ile Active Directory arasındaki bilgisayar hesabı ilişkisi bozulduğunda Secure Channel (güven kanalı) problemi ortaya çıkabilir. İki komut vardır ve ikisi farklı şeyler yapar:

cmd üzerinde

nltest /sc_query:DOMAIN.LOCAL

nltest /sc_verify:DOMAIN.LOCAL

• nltest /sc_query → mevcut güven kanalının durumunu sorgular (hafif test).
• nltest /sc_verify → güven kanalını aktif olarak doğrular (daha güçlü test, DC ile gerçek iletişim kurar).

Sorun yaşanan bir ortamda şu tip bir hata görülebilir:

Trusted DC Connection Status

Status = 1311 0x51f ERROR_NO_LOGON_SERVERS

ERROR_NO_LOGON_SERVERS, bilgisayarın domain üzerinde kullanılabilecek bir logon sunucusuna ulaşamadığını gösterir. Diğer tipik hata kodları:

• ERROR_ACCESS_DENIED (5) → bilgisayar hesabı parolası eşleşmiyor

• ERROR_NO_TRUST_LSA_SECRET → LSA secret bozulmuş

• ERROR_NO_TRUST_SAM_ACCOUNT → SAM hesabı bulunamıyor

Başarılı bir sonuç:

Trust Verification Status = 0 0x0 NERR_Success

Gerekirse PowerShell üzerinden kontrol ve onarım:

Test-ComputerSecureChannel -Verbose

Test-ComputerSecureChannel -Repair -Credential DOMAIN\administrator

Önemli notlar:

• Bu komut istemci üzerinde çalıştırılır, DC üzerinde değil.
• -Repair parametresi yerel makinenin bilgisayar hesabı parolasını sıfırlar.
• -Credential olarak verilen hesabın Domain Admin yetkisi olmalıdır.
• Repair sonrası genellikle gpupdate /force ile Group Policy tekrar test edilebilir. Gerekirse bilgisayar yeniden başlatılabilir.

Özellikle şu durumlarda Secure Channel problemi görülebilir: VM snapshot geri dönüşleri, bilgisayar hesabının AD üzerinde değiştirilmesi, uzun süre domain bağlantısı olmaması, restore işlemleri veya bilgisayar hesabı parolasının eşleşmemesi.

2.4 DNS Kontrolü Yapın

Active Directory ortamlarında DNS, Domain Controller keşfi ve Active Directory servislerine erişim açısından kritik bir bileşendir. Bu nedenle DNS kontrolünde yalnızca Domain Controller’ın adının çözülüp çözülmediğine değil, domain ve Active Directory’ye ait DNS kayıtlarının doğru çalışıp çalışmadığına da bakılmalıdır.

Öncelikle Domain Controller’ın tam adı (FQDN) doğru IP adresine çözülüyor mu kontrol edilir:

cmd üzerinde

nslookup DC.DOMAIN.LOCAL

Örneğin:

Name: DC.DOMAIN.LOCAL
Address: 192.168.10.10

Burada özellikle Address satırına dikkat edilir. Domain Controller için beklenen IP adresi görülmelidir.

Daha sonra domain adının kendisi sorgulanabilir:

cmd üzerinde

nslookup DOMAIN.LOCAL

Bu test, domain adının DNS üzerinden çözümlenip çözümlenmediğini kontrol etmek için kullanılabilir.

Belirli bir DNS sunucusunu doğrudan test etmek istenirse nslookup içerisinden DNS sunucusu da belirtilebilir:

cmd üzerinde

nslookup

Ardından:

server 192.168.10.10

Sonra:

DC.DOMAIN.LOCAL

Test tamamlandıktan sonra:

exit

Bu yöntem özellikle birden fazla DNS sunucusunun bulunduğu veya istemcinin hangi DNS sunucusunu kullandığının şüpheli olduğu durumlarda faydalıdır.

Bunun yanında Active Directory’nin kullandığı SRV kayıtları da kontrol edilmelidir:

cmd üzerinde

nslookup -type=SRV _ldap._tcp.dc._msdcs.DOMAIN.LOCAL

SRV kayıtları önemlidir çünkü Active Directory ortamında Domain Controller keşfi yalnızca DC.DOMAIN.LOCAL gibi bir A kaydının çözülmesine bağlı değildir. İstemciler, Active Directory servislerini bulabilmek için DNS üzerindeki servis kayıtlarından da yararlanır.

Bu nedenle;

DC.DOMAIN.LOCAL çözümleniyor

sonucunu görmek tek başına:

“Active Directory DNS tamamen sağlıklı.”

anlamına gelmez.

Örneğin Domain Controller’ın adı doğru IP adresine çözülüyor ancak gerekli SRV kayıtları bulunamıyorsa, istemci yine Domain Controller keşfi veya Active Directory servislerine erişim konusunda sorun yaşayabilir.

Bir diğer önemli nokta da nslookup çıktısındaki Server: UnKnown ifadesidir. Örneğin:

Server: UnKnown
Address: 192.168.10.10

Name: DC.DOMAIN.LOCAL
Address: 192.168.10.10

Buradaki Server: UnKnown satırı tek başına DNS’in çalışmadığını göstermez. Burada asıl önemli olan, sorgulanan DC.DOMAIN.LOCAL adının beklenen IP adresine (192.168.10.10) çözümlenip çözümlenmediğidir.

Ancak DNS sunucusunun adının UnKnown görünmesi istenmeyen bir durumsa, DNS sunucusunun kendi PTR/reverse DNS kaydı da ayrıca kontrol edilebilir. Bu nedenle bu satırı doğrudan “DNS bozuk” şeklinde yorumlamak doğru değildir.

2.5 Domain Controller’a Ağ Erişimini Kontrol Edin

cmd üzerinde

ping DC.DOMAIN.LOCAL

Örneğin:

Pinging DC.DOMAIN.LOCAL [192.168.10.10]

görülmesi beklenir. Yanlış bir IP adresi, beklenmeyen IPv6 adresi veya çözümlenemeyen bir isim görülüyorsa DNS ve ağ yapılandırması tekrar incelenmelidir.

ping DC ile ping DC.DOMAIN.LOCAL arasındaki fark: Kısa isim çalışmıyor ancak FQDN çalışıyorsa DNS suffix yapılandırması incelenmelidir.

Bu durumda doğrudan “DC çalışmıyor” sonucuna varmak doğru değildir.

Ping başarılı olması Active Directory’nin sağlıklı olduğunu tek başına kanıtlamaz. Ping yalnızca temel ağ erişimi hakkında fikir verir.

2.6 SYSVOL ve NETLOGON Erişimini Kontrol Edin

Group Policy’nin çalışabilmesi için SYSVOL erişimi önemlidir. Aşağıdaki kontroller yapılabilir:

cmd üzerinde

dir \\DOMAIN.LOCAL\SYSVOL

dir \\DOMAIN.LOCAL\NETLOGON

dir \\DC.DOMAIN.LOCAL\SYSVOL

dir \\DC.DOMAIN.LOCAL\NETLOGON

Bu paylaşımlara erişilemiyorsa Group Policy üzerinde değişiklik yapmadan önce Domain Controller, DNS, Netlogon ve SYSVOL tarafı araştırılmalıdır.

2.7 Group Policy Hatasının Gerçek Nedenini Araştırın

cmd üzerinde

gpupdate /force

Örneğin aşağıdaki gibi bir hata alınabilir:

The processing of Group Policy failed.

 Windows attempted to read the file

\\DOMAIN.LOCAL\sysvol\DOMAIN.LOCAL\Policies\{GUID}\gpt.ini

from a domain controller and was not successful.

Bu durumda ilk bakışta sorun Group Policy gibi görünür. Ancak gpt.ini dosyasına ulaşılabilmesi için bilgisayarın önce Domain Controller ve SYSVOL’a erişebilmesi gerekir. Dolayısıyla hata zinciri şöyle olabilir:

DNS / Ağ

   ↓

Domain Controller erişimi

   ↓

SYSVOL / NETLOGON

   ↓

Group Policy

Bu nedenle Group Policy hatası her zaman Group Policy’nin bozuk olduğu anlamına gelmez.

Uygulanan Group Policy’leri görmek için:

cmd üzerinde

gpresult /r

Bu çıktıda özellikle şu bilgiler incelenir: domain bilgisi, bilgisayar bilgisi, uygulanan GPO’lar ve Group Policy’nin hangi Domain Controller üzerinden alındığı.

Örneğin:

Group Policy was applied from: DC.DOMAIN.LOCAL

gibi bir sonuç, bilgisayarın Group Policy işlemi sırasında DC’ye ulaşabildiğini gösteren önemli bir bulgudur.

Önemli nüans:

gpresult /r, çalıştırıldığı kullanıcı ve yetki bağlamına göre kullanıcı ve bilgisayar tarafındaki RSoP bilgilerini gösterebilir. 

• Yönetici CMD’de çalıştırılırsa → bilgisayar politikaları önce gelir

• Normal CMD’de çalıştırılırsa → kullanıcı politikaları önce gelir

• İki tarafı da görmek için ya yönetici CMD’de çalıştır ya da /scope:computer ve /scope:user ile iki kez çalıştır

2.8 Saat ve Kerberos Durumunu Kontrol Edin

Active Directory ortamlarında zaman senkronizasyonu Kerberos açısından kritiktir. İstemci ile DC arasındaki saat farkı 5 dakikayı aşarsa kimlik doğrulama başarısız olabilir ve hata “parola yanlış” gibi görünebilir.

cmd üzerinde

w32tm /query /status

w32tm /query /source

w32tm /query /configuration

w32tm /query /status

çıktısında neye bakılır:

• Source: → hangi zaman kaynağı kullanılıyor
• Phase Offset: → zaman kaynağı ile istemci arasındaki ölçülen zaman farkını gösterir. Değerin sürekli yüksek olması veya zaman senkronizasyonunun başarısız olması ayrıca araştırılmalıdır.
• Last Successful Sync Time: → son başarılı senkronizasyon
• Poll Interval: → yoklama aralığı

w32tm /query /configuration çıktısında neye bakılır: Domain ortamında istemciler için beklenen değer:

Type: NT5DS

NTP veya NoSync görünüyorsa yapılandırma hatalıdır.

Örneğin:

Leap Indicator: 3

Stratum: 0

Source: Local CMOS Clock

gibi bir çıktı ayrıca araştırılması gereken bir durumdur.

Domain’deki tüm DC’leri karşılaştırmak için:

cmd üzerinde

w32tm /monitor /domain:DOMAIN.LOCAL

Tek bir hedefe karşı sürekli ölçüm için:

cmd üzerinde

w32tm /stripchart /computer:DC.DOMAIN.LOCAL /samples:5

Bu komut Ctrl+C ile durdurulur.

Önemli ayrım: Bir testte anormal sonuç görülmesi, o sonucun mutlaka kök neden olduğu anlamına gelmez. İncelediğimiz örnekte zaman senkronizasyonu ayrıca kontrol edilmesi gereken bir bulgu olsa da, problemin temelinde ağ tarafındaki IP çakışması olduğu daha sonraki kontrollerle ortaya çıkmıştır.

3. Ağ Katmanı: IP Çakışması ve Nasıl Araştırılır?

Bazen bütün belirtilerin altında çok daha basit bir problem bulunabilir: Domain Controller’ın IP adresini başka bir cihaz da kullanıyor olabilir.

Örneğin DC’nin adresi 192.168.10.10 olduğu halde ağ üzerinde başka bir cihaz da aynı IP’yi kullanıyorsa, istemcilerin DC’ye gönderdiği trafik tutarsız hale gelir. Bu durumda:

• Domain Controller keşfi başarısız olabilir.
• DNS sorguları zaman aşımına uğrayabilir.
• Netlogon bağlantıları başarısız olabilir.
• Secure Channel kontrolleri hata verebilir.
• Kerberos doğrulaması başarısız olabilir.
• SMB bağlantıları tekrar kullanıcı adı ve parola isteyebilir.
• SYSVOL’a erişilemeyebilir.
• Group Policy uygulanamayabilir.

Kullanıcı ise bütün bu sorunları tek bir mesajla ifade eder: “Domain şifrem çalışmıyor.”

3.1 IP Çakışması Nasıl Araştırılır?

1. ARP tablosunu kontrol edin:

cmd üzerinde

arp -a

arp -a | findstr 192.168.10.10

Önemli nüans: Tek bir arp -a çıktısında aynı IP için iki farklı MAC görünmesi nadirdir.

Bu nedenle yalnızca tek bir arp -a çıktısına bakarak IP çakışması kesin olarak doğrulanmamalıdır. Şüpheli durumda farklı zamanlarda tekrar kontrol edilmeli ve mümkünse switch MAC tablosu veya DHCP kayıtlarıyla doğrulanmalıdır.

Çakışma genellikle zaman içinde ARP tablosunun değişmesiyle ortaya çıkar. Bu nedenle arp -a komutunu birkaç kez, birkaç dakika arayla çalıştırın.

2. DC’nin kendi MAC adresini doğrulayın:

DC üzerinde:

cmd üzerinde

getmac /v

3. Event Viewer’da TCP/IP çakışma kaydını arayın:

DC üzerinde Olay Görüntüleyicisi → Windows Logs → System altında Event ID 4198 veya 4199 (TCP/IP çakışması) kayıtlarını kontrol edin. Bu kayıtlar, IP adresi çakışması şüphesini güçlü şekilde destekleyen önemli göstergelerdir.

4. Switch üzerindeki MAC address table’ı inceleyin:

Çakışan cihazın hangi switch portuna bağlı olduğunu bulmak için switch’in MAC adres tablosunu kontrol edin:

show mac address-table | include <MAC_adresi>

Bu, çakışmanın kaynağını fiziksel olarak bulmanın en hızlı yoludur.

3.2 DHCP ve Statik IP Planı

DC gibi kritik sunucuların IP adresleri DHCP havuzuyla çakışmamalıdır. Örneğin:

DHCP Pool:

192.168.10.100 – 192.168.10.200

 Domain Controller:

192.168.10.10

gibi bir yapı daha sağlıklıdır. Burada önemli olan yalnızca IP’nin sabit olması değil, ağdaki başka hiçbir cihazın aynı IP’yi kullanmamasıdır.

4. Düzeltme Sonrası Doğrulama

Sorunun ağ tarafında olduğu düşünülüyorsa yalnızca IP adresini değiştirmekle yetinmemek gerekir. Aynı testleri tekrar çalıştırmak, problemin gerçekten ortadan kalkıp kalkmadığını gösterir.

arp -d * komutu tüm ARP tablosunu temizler. Bu, ağ üzerindeki diğer cihazlarla olan bağlantıyı kısa süreliğine kesintiye uğratabilir ve bazı ortamlarda (özellikle üretim sunucularında) istenmeyen sonuçlar doğurabilir. 

4.1 DC Keşfi ve Secure Channel

cmd üzerinde

nltest /dsgetdc:DOMAIN.LOCAL

nltest /sc_verify:DOMAIN.LOCAL

Başarılı sonuçlar:

DC: \\DC.DOMAIN.LOCAL

Address: \\192.168.10.10

Dom Name: DOMAIN.LOCAL

Forest Name: DOMAIN.LOCAL

Trust Verification Status = 0 0x0 NERR_Success

Bu sonuçlar, DC’nin yeniden keşfedilebildiğini ve bilgisayar ile domain arasındaki güven ilişkisinin doğrulanabildiğini gösterir.

4.2 DNS ve Ping Testleri

cmd üzerinde

ipconfig /flushdns

arp -d *

nslookup DC.DOMAIN.LOCAL

ping DC.DOMAIN.LOCAL

DNS sorgusu ve ping aynı IP adresini göstermelidir:

Pinging DC.DOMAIN.LOCAL [192.168.10.10]

4.3 Group Policy Testi

cmd üzerinde

gpupdate /force

gpresult /r

Eğer daha önce alınan SYSVOL veya gpt.ini hatası ortadan kalkmış ve Group Policy başarıyla uygulanmaya başlamışsa, başlangıçta görülen Group Policy probleminin aslında altyapıdaki bağlantı probleminden kaynaklandığı anlaşılabilir.

5. Domain Controller Tarafında Sağlık Kontrolleri

Sorun istemci tarafında çözülemiyorsa veya birden fazla bilgisayar aynı problemi yaşıyorsa Domain Controller üzerinde de kontroller yapılmalıdır.

Önemli: Bu komutlar DC üzerinde ve yönetici yetkisiyle çalıştırılmalıdır. dcdiag tek başına çalıştırıldığında çok uzun sürebilir ve bazı testler başarısız görünse bile ortam sağlıklı olabilir. Bu nedenle önce kısmi testlerle başlamak daha verimlidir.

Kısmi testler:

cmd üzerinde

dcdiag /test:dns

dcdiag /test:advertising

dcdiag /test:netlogons

Bu testler, Domain Controller’ın temel Active Directory servisleri açısından incelenmesine yardımcı olur.

dcdiag /test:dns
…
TEST: Delegations (Del)
…
……………………. DC passed test DNS

her testin sonunda passed veya failed satırı görünür

Replikasyon kontrolü (birden fazla DC olan ortamlarda):

cmd üzerinde

repadmin /replsummary

repadmin /showrepl

• repadmin /replsummary → tüm DC’ler arası replikasyonun özetini verir.
• repadmin /showrepl → belirli bir DC’nin replikasyon detaylarını verir.

Tek Domain Controller bulunan bir ortamda repadmin kontrollerinin anlamı sınırlıdır; bu komutlar özellikle birden fazla DC bulunan yapılarda önem kazanır. Çoklu DC ortamlarında replikasyon sorunları, AD verilerinin ve SYSVOL/Group Policy yapısının tutarsız hale gelmesine neden olabileceğinden ayrıca kontrol edilmelidir.

6. Hızlı Referans: Komutlar ve Doğrulama Sırası

6.1 İstemci / Üye Sunucu Üzerinde

cmd üzerinde

whoami

echo %logonserver%

echo %userdnsdomain%

 nltest /dsgetdc:DOMAIN.LOCAL

nltest /sc_query:DOMAIN.LOCAL

nltest /sc_verify:DOMAIN.LOCAL

 nslookup DC.DOMAIN.LOCAL

nslookup -type=SRV _ldap._tcp.dc._msdcs.DOMAIN.LOCAL

 ping DC.DOMAIN.LOCAL

 ipconfig /all

arp -a

 dir \\DOMAIN.LOCAL\SYSVOL

dir \\DOMAIN.LOCAL\NETLOGON

 gpupdate /force

gpresult /r

 w32tm /query /status

w32tm /query /source

w32tm /query /configuration

6.2 Domain Controller Üzerinde

cmd üzerinde

dcdiag /test:dns

dcdiag /test:advertising

dcdiag /test:netlogons

Birden fazla DC varsa:

cmd üzerinde

repadmin /replsummary

repadmin /showrepl

6.3 Komutların Ne Söylediğini Bilmek Önemlidir

6.4 Hata Kodları ve İlk Bakılacak Alan

Bu tablo bir “hata kodu → kesin neden” tablosu değildir. Her hata, ilgili katmanın daha ayrıntılı incelenmesi gerektiğini gösteren teşhis işaretidir.

7. Kısa Bir Vaka Örneği

Bir müşteride sabah saatlerinde birden fazla kullanıcı “şifrem çalışmıyor” diye ticket açtı. İlk kontrollerde:

• whoami → domain hesabı doğru
• echo %logonserver% → \\DC beklenen sunucu
• nltest /dsgetdc:DOMAIN.LOCAL → başarılı
• nltest /sc_verify:DOMAIN.LOCAL → başarısız (ERROR_ACCESS_DENIED)

Secure Channel onarımı yapıldı ancak sorun birkaç saat sonra tekrar etti. Bu kez arp -a birkaç kez çalıştırıldı ve DC’nin IP’sinin bazen farklı bir MAC adresine gittiği görüldü. DC üzerinde Event ID 4198 kaydı vardı.

Kök neden: Yeni kurulan bir cihaz, DHCP yapılandırmasındaki hatalı adres dağıtımı nedeniyle DC tarafından kullanılan IP adresini kullanmaya başlamıştı. DHCP kapsamından bu IP çıkarıldı, yazıcı yeniden başlatıldı ve istemcilerde ipconfig /flushdns + arp -d * çalıştırıldı. Sorun kalıcı olarak çözüldü.

Çıkarım: Secure Channel onarımı semptomu geçici olarak düzeltmişti; asıl neden IP çakışmasıydı ve düzeltilmeden semptom tekrar ediyordu.

8. IP Çakışmasını Önlemek İçin

Domain Controller’ın IP adresi Active Directory altyapısının kritik parçalarından biridir. Bu nedenle:

• Domain Controller için uygun şekilde yapılandırılmış statik IP kullanılmalı.
• DC’nin IP adresi DHCP havuzundan ayrılmalı.
• Aynı IP başka bir cihazda kullanılmamalı.
• DNS kayıtları düzenli kontrol edilmeli.
• DHCP ve DNS yapılandırmaları birlikte değerlendirilmeli.
• Ağ üzerinde IP/MAC eşleşmeleri gerektiğinde switch ve DHCP kayıtlarından doğrulanmalı.

Özellikle bir DC’nin IP adresinin başka bir cihaz tarafından kullanılması, yalnızca basit bir ağ problemi olarak değerlendirilmemelidir. Active Directory’nin DNS, Kerberos, LDAP, Netlogon, SMB, SYSVOL ve Group Policy gibi birçok bileşeni bu iletişime bağlıdır.

9. Sonuç

Active Directory ortamında “kullanıcı adı ve parola kabul edilmiyor” şikâyeti her zaman parola problemi anlamına gelmez. Özellikle aynı anda;

• \\DC tekrar kullanıcı adı ve parola istiyorsa,
• Domain kullanıcıları oturum açamıyorsa,
• nltest 1355 veya 1311 hataları veriyorsa,
• gpupdate /force SYSVOL veya gpt.ini hatası veriyorsa,
• DNS sorguları başarısız oluyor veya zaman aşımına uğruyorsa,

öncelikle Domain Controller erişimi, DNS, ağ yapılandırması ve IP çakışması kontrol edilmelidir.

Bu tür bir sorunda en doğru yaklaşım, doğrudan NTLM, Kerberos veya Group Policy ayarlarını değiştirmek değil; problemi katman katman daraltmaktır:

Kullanıcı / Oturum

        ↓

Domain Controller keşfi

        ↓

     DNS

        ↓

  Ağ bağlantısı

        ↓

Secure Channel / Netlogon

        ↓

Kerberos / LDAP / SMB

        ↓

SYSVOL / NETLOGON

        ↓

  Group Policy

İncelenen örnekte kullanıcı tarafında görünen sorun “domain şifresi kabul edilmiyor” şeklindeydi. Ancak yapılan kontroller — özellikle arp -a çıktısı ve Event ID 4198 kaydı — problemin kullanıcı parolasından ziyade Domain Controller’ın IP adresiyle ilgili bir ağ çakışmasından kaynaklandığını ortaya çıkardı.

Bu nedenle Active Directory sorunlarında en önemli yaklaşım şudur:

Görünen hataya değil, hatanın oluşmasına neden olan iletişim zincirine bakın. Bazen kullanıcıya “şifre yanlış” gibi görünen problem, aslında çok daha aşağıda, DNS veya ağ katmanında başlamış olabilir.