Krbtgt Nedir ve Hesap Parolası Nasıl Sıfırlanır

27.03.2022
0

Kerberos, istemcilerin ağ üzerindeki sunucu kaynaklarına erişimi sırasında kimlik doğrulama işlemi için aracı olan servisler ile nasıl etkileşime girileceğini tanımlayan bir kimlik doğrulama protokolüdür. Bu protokol modelinde ağ üzerindeki sunucu kaynağına erişmek isteyen bir istemci, Kerberos V5 mimarisinin bileşenlerinden olan ve anahtar dağıtım merkezi olarak çalışan KDC’den (Key Distribution Center = AS+TGS) belirli bir işlem silsilesi sonucunda ticket olarak adlandırılan bir bilet alır ve parola bilgisi yerine doğrudan bu ticket’ı erişmek istediği sunucuya göndererek kimliğini doğrulayabilir. Kerberos V5 tasarımı aynı zamanda iletişim kurmak isteyen taraflara karşılıklı (mutual) kimlik doğrulama imkanı da tanır. Yani bir istemcinin erişmek istediği sunucuya kendini ticket ile tanıtması mümkünken, sunucunun da kendisini istemciye tanıtması ve taraflar arası güvenli ağ bağlantısının ancak bu karşılıklı kimlik doğrulama işlemini takiben kurulması da mümkündür. Kerberos ticket’lar, sistemleri parola olmaksızın ağ üzerindeki diğer sistemlere tanıtan birer kimlik kartı gibidir.

ⓘ Kerberos protokolü, username ve password bilgilerini karşı tarafla paylaşmadan kimlik doğrulama yapmayı mümkün kılan bir tasarıma sahiptir ve bu yönüyle password/hash bilgilerinin ağ üzerinde dolaşımını önemli oranda ortadan kaldırır.

Microsoft Active Directory etki alanı ortamlarında istemcilerin ağ üzerindeki kaynaklara erişimi sırasında varsayılan kimlik doğrulama protokolü olarak Kerberos V5 kullanılır ve mimaride görev alan KDC servisleri Domain Controller sunucuları üzerinde çalışır. Krbtgt hesabına geçmeden önce, AD etki alanı üyesi sistemler arasında Kerberos V5 kimlik doğrulama işleminin nasıl gerçekleştiğine bakalım.

kerberos-auth

Yukarıdaki diyagramda bir kullanıcı, oturum açmış olduğu Microsoft AD etki alanı üyesi bilgisayar/istemci üzerinden dosya paylaşımı, posta kutusu, web servis ya da bir belge yazdırma servisi gibi ağ üzerindeki bir sunucu kaynağına erişmek istiyor.

  1. İstemci erişmek istediği sunucuya doğrudan parola göndermek yerine önce bir TGT (ticket-granting ticket) almak için KDC’nin authentication service’ine (AS) istekte bulunur.
  2. KDC, istemciye şifrelenmiş bir TGT ve yine şifrelenmiş bir de session key verir. Yaşam süresi, yetkilendirme bilgileri gibi şeyler içeren TGT yalnızca KDC’nin çözebileceği bir anahtarla şifrelenmişken, diğer bölüm olan session key ise talepte bulunan kullanıcı hesabının AD veri tabanında kayıtlı parolasıyla şifrelenmiş durumdadır. Yani teknik olarak bir istemci ticket alma sürecinde aslında TGT içeriğini okuyamazken, session key’in şifresini çözecek bilgiye (kendi parolası) sahip olduğundan dolayı bu anahtarı çözüp okuyabilir.
  3. İstemci asıl ticket’ı almak için bu sefer KDC’nin ticket-granting service’ine (TGS) istekte bulunur. Bu sırada TGS’de kimlik doğrulamak için 2. adımda aldığı ancak içeriğini okuyamadığı ve zaten şifreli durumda olan TGT’yi gönderir.
  4. KDC istemciden gelen ve daha önce kendisi tarafından şifrelenmiş TGT’yi açar, doğrular ve istemciye sunucu kaynağına erişirken kullanmak üzere service ticket olarak da bilinen asıl ticket’ı verir. Bu ticket içerisinde istemciyi sunucuya tanıtan kimlik bilgileri, çözümlemesi sadece sunucunun kendi parolası ile yapılabilecek bir şifreleme için session key ve time stamp gibi bilgiler yer alır.
  5. İstemci 4. adımda aldığı ticket’ı yine aynı adımda aldığı ve yalnızca sunucu tarafından çözümlenebilen session key ile şifreler ve sunucuya göndererek erişim talebinde bulunur. Sunucu şifreli ticket’ı açar, doğrular ve access control sonrası uygun ise erişim gerçekleşir. Kerberos tasarımı gereği bu sırada sunucunun KDC ile iletişim kurması gerekmez.
  6. Opsiyonel olarak istemci de sunucudan kimlik doğrulama amaçlı kullanmak üzere kendi session key’i ile şifrelenmiş bir time stamp bilgisi talep edebilir. Bu da karşılıklı (mutual) kimlik doğrulama senaryosu olarak çalışır.

İşte bu Kerberos protokol modelinde KDC, istemciye verdiği TGT’yi şifrelerken ve çözerken AD veri tabanında yer alan krbtgt isimli bir hesap parolasını (aslında hash değerini) ana kriptografik anahtar yani master key olarak kullanır. Bu sebeple krbtgt hesap parolasının güvenliği kritik öneme sahiptir çünkü krbtgt hesap parolasının hash değerini ele geçirmeyi başaran bir saldırgan, AD domain ortamında geçerli Kerberos TGT’ler oluşturarak sistemlere erişim sağlayabilir ve parola doğru prosedür ile sıfırlanana kadar KDC bu TGT’lere güvenmeye devam eder.

Krbtgt hesabı Active Directory kurulumuyla birlikte gelen, bu sırada parolası random atanmış ve disabled pozisyonda çalışan yerleşik bir hesaptır. Bu hesap silinemez, ismi değiştirilemez ve enabled duruma getirilemez şekilde çalışmaktadır. Ancak parolası sıfırlanabilir ve hatta krbtgt hesabının parolasını aşağıdaki durumlarda mecburen sıfırlamanız da gerekebilir.

  • Güvenlik ihlali yaşanmış AD ortamlarında kurtarma planının bir parçası olarak.
  • Belirli bir güvenlik politikası dahilinde periyodik olarak.

Krbtgt Hesabının Parolası Nasıl Sıfırlanır?

Parola sıfırlama işlemi diğer AD hesaplarından farksızdır ve sıradan bir kullanıcı hesabı gibi sıfırlayabilirsiniz. Ancak farklı olarak, amacına ulaşan bir sıfırlama işlemi için krbtgt hesap parolasını belirli bir zaman aralığında art arda iki kez sıfırlamak ve bu sırada aşağıda bahsettiğim hususlarda dikkatli olmak gerekir.

ⓘ Krbtgt hesabı için parola belirlerken karakter sayısı açısından oldukça uzun, karmaşık ve random generated bir parola seçmeniz önerilir. Bu parolayı başka bir yere girmeniz ya da ilerleyen zamanda hatırlamanız gerekmez ve hatta ele geçirilme riskine karşı hiçbir yere kayıt etmemelisiniz.

KDC’nin TGT’leri şifrelerken krbtgt hesap parolasını master key olarak kullandığını söylemiştik. Kullanımda olan TGT’lerin maksimum yaşam süresi varsayılan olarak 10 saattir ve bu süre dolduğunda güvenlik sebebiyle yenilenmeleri gerekir. Gerektiğinde Domain Policy’de yer alan Kerberos Policy ayar grubu ile bu süreleri düzenlemeniz mümkün ancak mesai zaman aralığıyla da uyum açısından optimum sürenin 8-10 saat civarı olduğunu söyleyebiliriz.

kerberos-policy

Örneğin ortamda görev alan KDC’nin, krbtgt hesabının mevcut parolası ile TGT’ler şifreleyip dağıttığını ve bu TGT’lerle ilişkili ticket’ların da istemci ve sunucular tarafından kullanıldığını varsayalım. Krbtgt hesap parolası t1 anında 1. kez sıfırlandığında, 10 saate kadar yaşama hakkı olan eski parola ile oluşturulmuş TGT’lerin bu süre boyunca dolaşımda kalmaya devam edebilmesi için sistem bir önceki (yani eski) parolayı history’de saklamak üzere tasarlanmıştır ve hem eski hem de t1 anındaki yeni parolanın hash değerleri ile şifrelenmiş TGT’ler maksimum yaşam süreleri dolana kadar birlikte ortamda yaşamaya devam ederler. Yani Microsoft’un Kerberos uyarlamasında krbtgt hesabına ait son iki parolanın history’de saklanması gibi tasarımsal bir durum söz konusudur. Ancak buradaki problem eski parolanın history’de süresiz olarak saklanması. KDC’nin kendisi eski paroladan herhangi bir TGT üretmese bile, eski parolanın ele geçirildiği durumlarda bu parolayı kullanarak TGT oluşturmayı başaran birileri ortamda hala erişim sağlamaya devam edebilir. İşte bu yüzden parolayı belirli bir süre sonra 2. kez sıfırlayarak eski parolanın history’den tamamen çıkartılmasını sağlamak gerekiyor. 2. sıfırlama işleminden sonra 2 kapasiteli history’de sadece t1 ve t2 anında belirlenmiş yeni parolalar saklanacağı için eski parola vasıtasıyla oluşturulabilecek istenmeyen TGT’ler de geçerliliğini tamamen yitirmiş oluyor.

Krbtgt Parola Sıfırlama Prosedürü

  1. Sıfırlama işlemleri öncesinde AD domain içi DC’ler arası replikasyonun sağlıklı ve eksiksiz şekilde çalıştığından emin olun. DC’ler arası replikasyon durumlarını görmek için Repadmin /showrepl * tüm DC’ler arası replikasyonları tetiklemek için ise Repadmin /syncall /APeD komutlarını kullanabilirsiniz.
  2. Parolayı 1. kez sıfırlayın ve ardından Kerberos Policy ayarlarındaki süreleri de dikkate alarak en az 10 saat geçmesini bekleyin ve ayrıca sıfırlama sonrasında yine ortamdaki DC replikasyonlarının eksiksiz ve hatasız şekilde gerçekleştiğinden ve tüm DC’lerin krbtgt parola değişiminden haberdar olduğundan emin olun. Bu sebeple ve eğer bu işleme özel DC’ler arası manuel sync tetiklemiyorsanız şayet, 10 saat yerine 24 saat gibi daha uzun bir süre geçmesini beklemek ve DC’lerin aralarında konuşması için müsade etmek daha iyi bir fikir olabilir. Ancak her durumda DC replikasyonlarının tamamlandığından emin olmak çok önemlidir.
  3. Örneğin 24 saat geçtikten ve DC replikasyonlarının tamamlandığından emin olduktan sonra parolayı 2. kez sıfırlayın ve bir kez daha DC replikasyonlarının gerçekleştiğinden ve 2. parolanın da DC’ler arası yayıldığından emin olun.

Bu iki parola sıfırlama işlemini özellikle hemen arka arkaya yapmıyoruz çünkü sıfırlama öncesi yürürlükte olan ve kurtulmak istediğimiz eski parola ile oluşturulmuş TGT’ler hala ortamda kullanımda olacağı için o TGT’lerin yaşam sürelerinin dolmasını ve mimarideki standart prosedür ile TGT’lerini yenilenmesini beklemek iyi bir fikirdir. Acil değişikliklerde iki sıfırlama arasında bu süreleri beklemeyebilirsiniz ancak bu tip hızlı sıfırlama işlemlerinde hala kullanımda olan eski TGT’ler anında geçersiz kalacağı için ve ayrıca DC replikasyonlarını manuel tetikleseniz dahi yine de eşitlemede bir miktar gecikme söz konusu olacağı için yenilemeler gerçekleşene kadar ortamınızda kısa süreli bazı kimlik doğrulama sorunları yaşanabilir.

Parola Sıfırlama Sonrası Oluşabilecek Bazı Etkiler

Krbtgt hesabının parolasını sıfırlamadan önce aşağıdaki olası etkilerin bilinmesinde fayda var.

  • Eski parola ile şifrelenmiş TGT’lerin yaşam süreleri dolduğunda, bu TGT’leri kullanan AD bağımlı uygulamaların ve istemcilerin ticket’ları geçersiz kalır ve DC’lere gelip otomatik olarak yeniden üretilirler. Bu esnada yapının büyüklüğüne göre bir miktar trafik oluşabilir ancak kayda değer bir etkisi olmayacaktır çünkü TGT’lerin yaşam süresi sebebiyle bu gibi üretim ve yenileme işlemleri zaten her gün tekrar eden işlemlerdir.
  • Özellikle multi-site yapılarda örneğin replikasyon/iletişim sorunlarından ötürü hesap sıfırlama bilgisinin ulaşamadığı DC’ler olur ise, kimlik doğrulama süreçlerinde aksamalar yaşanabilir. Bu sebeple krbtgt parola sıfırlama işlemleri öncesinde ve sonrasında AD domain içindeki DC’ler arası replikasyonların eksiksiz şekilde gerçekleştiğinden emin olmalısınız.
    • DC’ler arası replikasyon durumlarını görmek için: Repadmin /showrepl *
    • DC’ler arası replikasyonları tetiklemek için: Repadmin /syncall /APeD
  • Elinizdeki geçmiş tarihli DC backup’ları içindeki krbtgt parolası eski kalmış olacak. Eğer bir gün bu eski backup’ları kullanmanız gerekir ise bu nokta aklınızda bulunsun.

Krbtgt hesap parolasının belirli zamanlarda sıfırlanmasıyla ilgili herhangi bir best practice olmamasına rağmen açıkça bir güvenlik ihlali yaşanmış ya da şüphe duyulan durumlarda veya belirli aralıklarla periyodik şekilde bu işlemi gerçekleştirebilirsiniz.

Yorum Ekle

* Gerekli

* Gerekli

* Tercihen