Kurumsal ortamlarda güvenlik her şeyin önünde gelir. Özellikle Active Directory Certificate Services (AD CS) gibi kritik rol oynayan bileşenlerde yapılan güvenlik hardening çalışmaları hem kullanıcı kimlik doğrulamasını hem de kurum içi iletişimi güvence altına alır.
Ancak çoğu zaman gördüğümüz gibi, güvenliği artırmak için yapılan her değişiklik aynı zamanda yeni zorlukları da beraberinde getirebilir. Benim başıma gelen bu vaka tam da bu duruma güzel bir örnek oldu.
Microsoft’un KB5005413 bülteni ile önerdiği NTLM Relay saldırılarını engelleme adımlarını uyguladıktan sonra hiç beklemediğim bir sorunla karşılaştım.
Bu makalede bu sorunu gidermek için yapılması gerekenleri sizlerle paylaşıyorum.
Güncellemeleri uyguladıktan sonra kullanıcıların sertifika talebinde bulunduğu klasik /certsrv portalına (https://caserver.kadirkozan.local/certsrv) erişmeyi denedim.
- Kullanıcı adı ve parolam doğruydu.
- Kimlik doğrulama penceresi bilgileri kabul ediyor gibi görünüyordu.
- Fakat her denememde sistem beni reddediyordu.
İlk etapta akla gelen senaryo “yanlış şifre” ya da “domain hesabı sorunlu” gibi klasik problemlerdir. Ama işin aslı çok daha farklıydı.
Detaylı log incelemesi ve Kerberos/NTLM davranışlarını analiz ettiğimde asıl sebep ortaya çıktı
SPN (Service Principal Name) kaydı eksikti. Peki bu neden kritik?
- SPN bir servis hesabının belirli bir servisi temsil ettiğini Active Directory’ye bildirir.
- Eğer doğru SPN yoksa istemci Kerberos üzerinden kimlik doğrulaması yapamaz.
- Kerberos başarısız olunca sistem NTLM fallback dener.
- Ancak NTLM Relay mitigasyonu sonrası NTLM engellenmiş olduğundan, girişler başarısız kalır.
Kısacası sistemin doğru şekilde Kerberos kullanabilmesi için doğru SPN kayıtları zorunludur.
Bu sorunu çözmek için eksik olan SPN kayıtlarını doğru biçimde tanımlamak gerekiyordu. Bunun için setspn aracını kullandım:
setspn -S HTTP/cert.corp.local caserver
setspn -S HTTP/cert caserver
- İlk komut tam etki alanı adı (FQDN) üzerinden HTTP servisini CA sunucusuna bağladı.
- İkinci komut ise kısa hostname için gerekli SPN kaydını oluşturdu.
Bu değişikliklerden sonra certsrv portalına tekrar giriş yaptım ve sorun tamamen ortadan kalktı. Artık Kerberos üzerinden sorunsuz bir şekilde oturum açılabiliyordu.
AD CS Web Enrollment servisi HTTP tabanlı çalışır. Buradaki kritik nokta şudur:
- Eğer SPN kaydı yanlış ya da eksik olursa Kerberos kullanılamaz.
- Sistem NTLM’e düşer ama güvenlik hardening sonrası NTLM engellendiği için giriş hatası kaçınılmazdır.
- SPN doğru olduğunda ise Kerberos mekanizması devreye girer hem güvenli hem de hızlı bir kimlik doğrulama sağlanır.
Bu nedenle güvenlik yamalarını uygularken sadece politikaları değiştirmek değil aynı zamanda servislerin bağımlılıklarını da kontrol etmek gerekir.
Benim bu deneyimden çıkardığım birkaç önemli ders var:
- SPN Kayıtlarını Kontrol Edin
Güvenlik hardening sonrası özellikle HTTP tabanlı servisler için SPN kayıtlarının tam ve doğru olduğundan emin olun. - Kerberos & NTLM Davranışını Anlayın
Kerberos güvenlik hardening sonrasında her zaman birincil kimlik doğrulama mekanizmasıdır. NTLM’in fallback olarak devreye girmesini engellemek için yapılandırmalarınızı dikkatle planlayın. - Logları İyi Takip Edin
Başta sıradan bir kimlik doğrulama hatası gibi görünen sorunlar aslında çok daha temel bir yapılandırma eksikliğine dayanabilir. Event log’ları ve güvenlik loglarını yakından takip edin. - Değişiklik Sonrası Test Yapın
Her güvenlik güncellemesinden sonra kritik servislerin (ör. /certsrv portalı) erişimini farklı kullanıcı hesaplarıyla mutlaka test edin.
Güvenlik hardening sürecinde küçük bir eksiklik bile büyük problemlere yol açabiliyor. Benim yaşadığım bu örnek aslında birçok sistem yöneticisinin başına gelebilecek türden bir senaryo. Eğer siz de NTLM Relay mitigasyonu uyguladıktan sonra /certsrv portalına giriş hatası alırsanız vakit kaybetmeden SPN kayıtlarını kontrol edin. Ben bu deneyimi paylaşarak benzer bir durumda zaman kaybetmenizi önlemek istedim.