Kerberos Desteklenen Şifreleme Türlerinin Seçimini Çözmek

Merhaba

Active Directory Sıkılaştırma serisinin Bölüm 4‘ünde Kerberos’ta AES’i zorunlu kılmayı, RC4’ü ortamdan çıkarmayı ele almıştık. Ancak pratikte pek çok yönetici şu soruyla karşılaşır: Her yeri AES’e ayarladım, ama olay kayıtlarında hala RC4 görüyorum. Neden? Bu yazı, tam olarak o kafa karışıklığını gidermek için Kerberos’un bir bilet üretirken şifreleme türünü nasıl seçtiğini adım adım açıklıyor.

Kerberos’ta şifreleme türü seçimi, tek bir ayara bakılan basit bir karar değil; birden fazla nesnenin ve politikanın kesişiminden çıkan bir sonuçtur. Bu mantığı anladığınızda, neden hala RC4 sorusuna da kendiniz cevap verebilir hale gelirsiniz.

Bir Kerberos Biletinde İki Ayrı Şifreleme Vardır

Birincisi biletin kendisidir. Bilet, hedef hesabın (bir servis hesabı ya da TGT (Ticket Granting Ticket) söz konusuysa krbtgt hesabı) uzun süreli anahtarıyla şifrelenir. Bu şifrelemeyi yalnızca o hedef hesap (veya onun anahtarını bilen KDC (Key Distribution Center)) çözebilir.

İkincisi session key’dir (oturum anahtarı). Bu, istemci ile servis arasında o oturum boyunca kullanılacak anahtardır ve biletin içine gömülüdür.

Bu ikisinin şifreleme türü birbirinden farklı olabilir. İşte her şeyi AES’e ayarladım ama RC4 görüyorum durumunun kökeni çoğu zaman buradadır: biletin kendisi bir etype ile, session key başka bir etype ile üretilebilir.

msDS-SupportedEncryptionTypes Özniteliği

Bir hesabın hangi şifreleme türlerini desteklediği, Active Directory’de msDS-SupportedEncryptionTypes özniteliğinde bir bit maskesi olarak tutulur. Bu öznitelik yalnızca kullanıcı hesaplarında değil; bilgisayar hesaplarında ve Kerberos’un kalbindeki krbtgt hesabında da bulunur.

Bit değerleri, Bölüm 4‘te de gördüğümüz gibi şöyledir:

AES-only hedefi için değer 24’tür (0x18 = AES128 + AES256).

Şifreleme Türü Nasıl Seçilir: Kesişim Mantığı

KDC (Key Distribution Center, yani anahtar dağıtım merkezi rolündeki Domain Controller), bir bilet üretirken şifreleme türünü tek bir kaynaktan değil, birden fazla girdinin kesişiminden belirler:

• İstemcinin desteklediği türler: İstemci, isteğinde hangi etype’ları desteklediğini bildirir.
• Hedef hesabın öznitelik değeri: Biletin şifreleneceği hesabın (servis hesabı ya da krbtgt) msDS-SupportedEncryptionTypes değeri.
• Domain / makine politikası: GPO ile dağıtılan Network security: Configure encryption types allowed for Kerberos ayarı ve karşılık gelen registry değeri.

KDC, bu kümelerin ortak (kesişen) en güçlü türünü seçer. Yani bir tarafta AES olsa bile, başka bir taraf yalnızca RC4 destekliyorsa, kesişim RC4’e düşebilir. Zayıf halka her zaman sonucu belirler.

Öznitelik Ayarlanmadığında Ne Olur

Microsoft, güncel yamalarla bu varsayılanı AES lehine sıkılaştırma yönünde adımlar attı. Ancak yine de en güvenli yaklaşım, varsayılana güvenmek değil; kritik hesaplarda (özellikle SPN’e sahip servis hesaplarında ve krbtgt’de) değeri açıkça AES’e ayarlamaktır. Ayarlanmamış bir öznitelik, güvenli anlamına gelmez.

Neden AES Hesapta Bile RC4 Session Key Görülür

En sık rastlanan kafa karışıklığı budur. Bir servis hesabını msDS-SupportedEncryptionTypes = 24 (AES-only) yaptınız, ama olay kayıtlarında hala RC4 geçiyor.

Olası nedenler şunlardır.

Öncelikle bilet etype ile session key etype’ı farklıdır; öznitelik ağırlıklı olarak biletin uzun süreli anahtar tarafını etkiler, session key ise istemci ve ilgili diğer nesnelerin desteğine göre pazarlık edilir. Bir diğer önemli aktör krbtgt hesabıdır: TGT, krbtgt’nin anahtarıyla şifrelenir ve krbtgt AES destekli değilse ya da parolası uygun biçimde döndürülmemişse, oradan RC4 sızabilir. Ayrıca istemcinin ya da aradaki başka bir hesabın hâlâ RC4’e ihtiyaç duyması da sonucu RC4’e çekebilir.

Kısacası tek bir hesabı AES yapmak yetmez; zincirin tamamının (istemci, servis hesabı, krbtgt ve domain politikası) AES’i desteklemesi gerekir. Bölüm 4‘te değindiğimiz krbtgt bakımının önemi tam da buradan gelir.

Olay Kayıtlarından Teşhis

Kerberos bilet isteklerini Domain Controller’lardaki şu olaylardan izleyebilirsiniz:

• Event 4768: Kerberos kimlik doğrulama bileti (TGT) isteği
• Event 4769: Kerberos servis bileti isteği

Bu olaylardaki Ticket Encryption Type alanı, o istekte kullanılan etype’ı gösterir. Sık karşılaşılan değerler:

0x17 gördüğünüz her kayıt, o bilet için RC4 kullanıldığını söyler. Teşhis ederken, biletin hangi hesap için (Service Name / Account Name alanları) üretildiğine bakın; sorunlu etype’ı üreten hesabı bu şekilde nokta atışı bulabilirsiniz. Ardından o hesabın msDS-SupportedEncryptionTypes değerini ve krbtgt’nin durumunu kontrol edin.

Genel Görünüm

Kerberos’ta şifreleme türü seçimi, tek bir kutuya tik atmakla bitmeyen, kesişime dayalı bir süreç. Biletin kendisi ile session key farklı etype’lar taşıyabilir; sonucu istemci desteği, hedef hesabın özniteliği, domain politikası ve krbtgt hesabının durumu birlikte belirler. Zincirdeki en zayıf halka her zaman kazanır.

Bu yüzden her şeyi AES yaptım ama RC4 görüyorum durumunda paniklemek yerine, zinciri baştan sona kontrol edin: ilgili servis hesabının özniteliği, istemcilerin desteği, domain GPO’su ve en önemlisi krbtgt hesabının AES desteği ve parola bakımı. Bu bütünsel bakış, Bölüm 4‘teki AES zorlamasını gerçek anlamda tamamlar.

Bu yazı, Active Directory Sıkılaştırma serisinin Bölüm 4 (Kerberos için AES Zorlaması) yazısının kavramsal tamamlayıcısıdır. Zorlamayı uygulamak için o bölümü, seçim mantığını anlamak için ise bu yazıyı birlikte değerlendirmenizi öneririm.

Başka bir yazımızda görüşmek dileğiyle…