Bu makalemde yoğun olarak kimlik doğrulama servislerini kullanan şirket organizasyonlarında olası kimlik doğrulama sorunlarının kaynağının tespitinde kullanılan bir takım yöntemleri paylaşacağım.
Buradaki en önemli nokta aslında sorunun kaynağının tespit edilmesidir. Ancak çoğu kez bu sorunun oluştuğu zamanda açık olmayan loglar veya dump dosyaları nedeni ile tespit edilememektedir.
Varsayılan Windows olay günlükleri ile bu tür sorunları bir yere kadar inceleyebiliyor veya çözebiliyoruz ancak daha detay bir bilgi için mutlaka detaylı log gerekmektedir.
Örneğin bir sunucuda aşırı kaynak tüketimi nedeni ile ( memory leak ) DC’ niz birden kapanabilir, bu tarz bir duruma sebebiyet veren programı bulmak için o sunucunun dump dosyasına ihtiyacınız bulunmaktadır.
Nedir bu dump dosyası derseniz, sistem crash olduğu anda hafızadaki tüm veriyi c:\windows altında MEMORY.DMP olarak görebilirsiniz.
Bu konuda daha fazla bilgi için aşağıdaki makaleyi okumanızı öneriyorum
WinDbg ile Windows BSOD Crash Dump Dosyalarının Analiz Edilmesi – ÇözümPark (cozumpark.com)
Önemli olan sorun olduğu anda bu dosyalara erişebiliyor muyuz?
Yukarıda da bahsettiğim gibi bu tarz detay loglamaları açmak her zaman ek bir sistem kaynağı tüketmek olduğu için varsayılan olarak bu tür loglamaları biz açık tutmuyoruz. Bir sorun olduğunda bunun kök nedenini ( root cause ) araştırırken bu tür detay loğlara ihtiyacımız olmaktadır.
Peki, sorun bir daha tekrarlanmaz ise? Bu tür durumlarda zaten kök sebebi bilmemiz pek mümkün olmuyor.
Peki, sorun sık sık veya belirli aralıklar ile tekrarlanıyor ise neler yapabiliriz?
Öncelikle konumuz Active Directory kimlik doğrulama sorunları olduğu için bu konudaki logları açmamız gerekmektedir.
İlk işimiz Domain seviyesinde Domain Controller makineleri için aşağıdaki 3 başlığın açık olduğunu kontrol etmeliyiz.
Account Logon Events – Failure
Account Management – Success
Logon Events – Failure
Computer Configuration – Windows Settings – Security Settings – Local Policies altında Audit Policy bölümünden bu ayarlara ulaşabilirsiniz.
Yine bir diğer ön hazırlık ise, bu tarz yoğun loglama özelliklerini açtığımız zaman olay günlükleri hızlı bir şekilde dolacağı için sorunları incelemek zor olabilir. Bu nedenle güvenlik loglarını genişletmekte fayda var.
Log boyutunu yükseltin (benim tavsiyem 512MB çok yeterli olacaktır. Tabi ki bu şirket ortamına göre değişen bir yorumdur – ortalama 5000 kişilik bir şirket için).
Bunlar tüm DC lerde aktif olduktan sonra şimdi netlogon ve sonrasında kerberos detay loglamayı açabiliriz.
İlk olarak Netlogon ile başlıyoruz.
Netlogon Debug açma için aşağıdaki komutu sunucu üzerinde çalıştırabiliriz.
nltest /dbflag:0x2080ffff
loglar ise aşağıdaki dizinde olacaktır.
%windir%\debug\netlogon.log
http://support.microsoft.com/kb/109626
Bu konu hakkında daha fazla bilgi için yukarıdaki makaleyi inceleyebilirsiniz.
Peki, örnek birkaç log’ u izleyelim
03/09 04:35:27 [MISC] Logfile truncated because it was larger than 20000000 bytes
03/09 04:35:27 [LOGON] COZUMPARK: SamLogon: Transitive Network logon of COZUMPARK\hakanu from PC-21 (via HUBCAS) Returns 0x0
03/09 04:35:27 [LOGON] COZUMPARK: SamLogon: Transitive Network logon of COZUMPARK\serkanu from PC-22 (via HUBCAS) Entered
03/09 04:35:27 [LOGON] COZUMPARK: SamLogon: Transitive Network logon of COZUMPARK\serkanu from PC-22 (via HUBCAS) Returns 0x0
03/09 04:35:27 [LOGON] COZUMPARK: SamLogon: Transitive Network logon of COZUMPARK\serkanu from PC-22 (via HUBCAS) Entered
03/09 04:35:27 [LOGON] COZUMPARK: SamLogon: Transitive Network logon of COZUMPARK\serkanu from PC-22 (via HUBCAS) Returns 0x0
03/09 04:35:27 [LOGON] COZUMPARK: SamLogon: Transitive Network logon of COZUMPARK\mesuta from PC-03 (via HUBCAS) Entered
03/09 04:35:27 [LOGON] COZUMPARK: SamLogon: Transitive Network logon of COZUMPARK\mesuta from PC-03 (via HUBCAS) Returns 0x0
03/09 04:35:27 [LOGON] COZUMPARK: SamLogon: Transitive Network logon of COZUMPARK\mesuta from PC-03 (via HUBCAS) Entered
03/09 04:35:27 [LOGON] COZUMPARK: SamLogon: Transitive Network logon of COZUMPARK\mesuta from PC-03 (via HUBCAS) Returns 0x0
03/09 04:35:27 [LOGON] COZUMPARK: SamLogon: Transitive Network logon of COZUMPARK\mesuta from PC-03 (via HUBCAS) Entered
03/09 04:35:27 [LOGON] COZUMPARK: SamLogon: Transitive Network logon of COZUMPARK\mesuta from PC-03 (via HUBCAS) Returns 0x0
03/09 04:35:27 [LOGON] COZUMPARK: SamLogon: Transitive Network logon of COZUMPARK\mesuta from PC-03 (via HUBCAS) Entered
03/09 04:35:27 [LOGON] COZUMPARK: SamLogon: Transitive Network logon of COZUMPARK\mesuta from PC-03 (via HUBCAS) Returns 0x0
03/09 04:35:27 [LOGON] COZUMPARK: SamLogon: Generic logon of COZUMPARK.COM\(null) from (null) (via PC-2865) Package:Kerberos Entered
03/09 04:35:27 [LOGON] COZUMPARK: SamLogon: Generic logon of COZUMPARK.COM\(null) from (null) (via PC-2865) Package:Kerberos Returns 0x0
03/09 04:35:27 [MAILSLOT] Received ping from PC-007 COZUMPARK.com. (null) on UDP LDAP
03/09 04:35:27 [MISC] COZUMPARK: Pack NextClosestSiteName into message 0
Burada önemli olan konu hata alıp almıyor olmamız. Bunu ise “Return 0x0” den anlıyoruz. Bu “Success” yani başarılı login olduğunu anlayabiliyoruz.
Bu dönen kodlara göre aslında biz sorunu çok rahat bir şekilde çözebiliyoruz. Bunun için aşağıdaki tabloyu kullanma şansına sahipsiniz.
Net Logon Error Code
Tablonun orijinali için aşağıdaki linke ulaşabilirsiniz;
http://technet.microsoft.com/en-us/library/cc776964(v=WS.10).aspx
Örneğin buradaki en önemli kodlardan biri bana göre 9A ile biten koddur, bu DC nin yetersiz sistem kaynağına sahip olduğu için hizmet veremiyor durumda olduğunu gösterir.
Malum kimlik doğrulama denince aklımıza netlogon kadar Kerberos da gelmeli ve hali hazırda aktif olarak kullandığımız bir kimlik doğrulama yöntemidir.
Kerberos içinde detay logları açmamız gerekmektedir.
İstemci makinelerinde veya sunucularında aşağıdaki kayıt defteri yolunu izliyoruz
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Yeni bir REG_DWORD değeri oluşturuyoruz, ismi ise “LogLevel”
Değeri 0x1
Not; Eğer bu anahtar var ise oluşturmaya gerek yoktur, sadece değeri değiştirmeniz yeterli.
Ardından bilgisayarı yeniden başlatmamız gerekmektedir.
Bu loglamayı kapatmak için “Loglevel” anahtarını silmek yeterlidir.
2003 sistemlerde bu değişiklik restart gerektirirken 2008 ve üstü sistemlerde restart gerektirmemektedir.
Bu açtığımız detay loglarını sunucunu veya istemci olay günlüklerinden system günlüğünden takip edebilirsiniz.
Detayı
Burada aldığımız hata detayı ise aşağıdaki gibidir
0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN
Örneğin bu hata kodu için çözüm önerisi aşağıdaki linkte yer almaktadır.
http://technet.microsoft.com/en-us/library/cc772897(v=ws.10).aspx
Örneğin yukarıdaki sorunu incelemek gerekir ise, bu bir SPN problemidir.
Yani Kerberos ile kimlik doğrulamak istenen servis için AD üzerinde tanımlı bir SPN yok. Bu nedenle kerberos fail eder ve kimlik doğrulama NTLM’ e döner. (NTLM’ e failback yapması olarak da bilinir )
Öncelikle gerçekten bu SPN domain içerisinde var mı yok mu bir kontrol edelim.
ldifde -f SPN.txt -t 3268 -d “” -l serviceprincipalname -r “( serviceprincipalname= cifs/netapp.cozumpark.com*)” -p subtree
Yukarıdaki komut ile hata aldığımız SPN için bir sorgu çekiyoruz, eğer sonucunda herhangi bir kayıt yok ise bu SPN yok demektir.
Bunu ekleyerek kimlik doğrulamanın Kerberos ile gerçekleşmesini sağlayabiliriz.
Nasıl ekleyebiliriz?
Örnek komut seti aşağıdaki gibidir
setspn -A HTTP/MEDYA01 COZUMPARK\IISSmooth
setspn -A HTTP/MEDYA01.cozumpark.com COZUMPARK\IISSmooth
Set SPN komutu için daha fazla bilgiye aşağıdaki linkten ulaşabilirsiniz
http://technet.microsoft.com/en-us/library/cc731241(v=ws.10).aspx
Gördüğünüz gibi burada önemli olan konu sizdeki sorunu doğru tespit etmek. Yani loglama seviyeniz doğru ve detay alabiliyorsanız ya siz yâda bir Microsoft Mühendisi sorunun çözümü noktasında çok ciddi bir yol kat etmiş olacaktır.
Sorun çözümleme konuları tabiki çok detaylı konular olup başı sonu belli değildir. Bende temel seviyede netlogon ve kerberos loğlarının detaylandırılmasını anlatarak sizlere bir nebze olsa yardımcı olmak için bu makaleyi yazdım.
Umarım faydalı bir makale olmuştur.
Bir sonraki makalemde görüşmek üzere.