Active Directory Tiering Model Tasarımı Bölüm-5

Merhaba, bu bölümde servis hesapları ve yönetimi, GMSA hesapları, Authentication Policy ve Silo kavramları üzerinde duracağız.

İlk olarak servis hesapları ile başlıyalım, servis hesapları AD ortamındaki en belalı hesaplardan birisidir. Bunun nedenlerinin en başında parolalarının “never expire” olarak ayarlanması ve sonrasında unutularak yıllarca aynı parola ile bu hesapların kullanılması. Bunu bir kaç şekilde yönetebilirsiniz.

Birincisi: Ortamınızda iyi bir aduit tool’u veya düzgün yönetilen bir siem varsa bu hesaplara yapılan yetkisiz erişimleri kontrol edebilirsiniz.

İkincisi: Düzenli olarak parolalarının değiştirilmesi.

Üçüncüsü: GMSA hesap kullanımı.

GMSA Hesap nedir?

GMSA, Microsoft tarafından sunulan ve Active Directory üzerinde çalışan bir hizmet hesabıdır. Şifresi otomatik olarak Active Directory tarafından yönetilir ve belirli bilgisayarlar veya sunucular grubuna atanabilir.

GMSA Ne İşe Yarar?

1. Otomatik Şifre Yönetimi:
   Şifre karmaşık ve rastgele olur, Active Directory tarafından düzenli olarak otomatik değiştirilir. Yani manuel şifre yönetimine gerek kalmaz.
   
2. Yüksek Güvenlik:
   İnsan müdahalesi olmadığı için zayıf şifre, yanlış yapılandırma gibi riskler azalır.
   
3. Çoklu Sunucu Desteği:
   GMSA, aynı anda birden fazla sunucuda kullanılabilir. Bu da yük dengeleme, farm yapıları veya cluster senaryoları için idealdir.
   
4. Active Directory Entegrasyonu:
   Sadece belirli makinelerde kullanılabilir. Kısıtlıdır, kontrol altındadır.

Nerelerde Kullanılır?

• IIS Application Pool’larında
  
• Scheduled Task (Zamanlanmış Görev) çalıştırırken
  
• SQL Server, IIS, Exchange, AD FS, MDS gibi sunucularda servis hesabı olarak
  
• SCCM, SCOM, MIM, DFS vb. sistem servislerinde
  
• Windows Services altında Log On As hesabı olarak

Dikkat Edilmesi Gerekenler

• GMSA kullanabilmek için Windows Server 2012 veya üzeri gereklidir.
  
• Sunucuların bulunduğu ortamda Key Distribution Service (KDS) aktif olmalı.
  
• Active Directory schema uygun olmalı.
  
• GMSA, sadece hizmetler veya görevler için kullanılabilir; interaktif login (RDP) ile oturum açamazlar.

Nasıl Kullanılır?

Active Directory module for Windows PowerShell modülü, gMSA hesaplarının oluşturulması ve yönetilmesi için temel bir gerekliliktir.

1. Server Manager üzerinden Add Roles and Features Wizard sihirbazı başlatılır.
   
2. “Features” ekranında, Remote Server Administration Tools > Role Administration Tools > AD DS and AD LDS Tools yolunu izleyerek Active Directory module for Windows PowerShell seçeneği işaretlenir.
   
3. Ardından “Next” ve “Install” butonlarına tıklanarak kurulum tamamlanır.

roup Managed Service Account (gMSA) hesaplarının çalışabilmesi için, Active Directory ortamında Key Distribution Service (KDS) tarafından kullanılacak bir root key’in tanımlanması gerekmektedir. Bu anahtar, gMSA hesaplarının şifrelerinin arka planda otomatik olarak yönetilebilmesi için kullanılır.

Aşağıdaki komutu çalıştırıyoruz. Ancak bu bir süre olabilir. Bu süreyi beklemek istemiyorsanız aşağıdaki bir sonraki komutuda kullanabilirsiniz.

Add-KdsRootKey -EffectiveImmediately

Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

Aşağıdaki PowerShell komutu, bir gMSA hesabı oluşturmak için kullanılıyoruz. Bizim örğenimizde bir sql sunucu için gmsa hesabı oluştuyoruz.

New-ADServiceAccount -Name Sql-Service -DNSHostName Sql-Service.lab.local

Bu örnekte:

• -Name Sql-Service: gMSA hesabının adıdır.
  
• -DNSHostName Sql-Service.lab.local: Bu gMSA hesabını kullanacak olan bilgisayarın (veya servisin) DNS adıdır.

Bu komut başarıyla çalıştırıldığında, Active Directory ortamında Sql-Service adında bir gMSA nesnesi oluşturulur. Bu hesap henüz sistem tarafından kullanılmaya hazır hale gelmemiştir; bir sonraki adımda hedef bilgisayara yüklenmeli ve ilişkilendirilmelidir.

Veya bir sunucu grubun için yeni bir security group oluşturabilir ve bunu yetkilendirebiliriz.

Yukarıdaki ekran görüntüsünde, SQL1 adlı sunucunun SQL-Servers adında bir güvenlik grubunun üyesi olduğu görülmektedir. Bu grup, Sql-Service adlı gMSA hesabına erişim izni olan principal olarak tanımlanacaktır.

Bu yetkilendirme için kullanılan PowerShell komutu:

Set-ADServiceAccount -Identity Sql-Service -PrincipalsAllowedToRetrieveManagedPassword SQL-Servers

Bu komut ile:

• Sql-Service adlı gMSA hesabına,
  
• SQL-Servers güvenlik grubunun üyeleri tarafından erişim izni verilmiş olur.

AD tarafında işlemler bu kadar. Şimdi SQL sunucu tarafına login oluyoruz ve “Active Directory module for Windows PowerShell” modülü yüklüyoruz.

Yetkilendirme adımlarının ardından, gMSA hesabının hedef makineye kurulması gerekmektedir. Bu işlem, PowerShell üzerinden aşağıdaki komutla gerçekleştirilir:

Install-ADServiceAccount -Identity Sql-Service

Ancak bazı durumlarda bu işlem başarısız olabilir. Yukarıdaki ekran görüntüsünde görüldüğü gibi, Install-ADServiceAccount komutu çalıştırıldığında aşağıdaki hata alınabilir.

Bunu çözmek için aşağıdaki komutu giriyoruz ve tekrar deniyoruz.

Bu işlemler sonunda artık bu oluşturduğunuz hesapları yetkili sunucularda kullanmaya başlayabiliriz.

Active Directory Domain Service Authentication Policy & Silo Nedir?

Active Directory’de Authentication Policy ve Authentication Policy Silo, özellikle Kerberos tabanlı kimlik doğrulamada güvenliği artırmak amacıyla Windows Server 2012 R2 ve sonrasında tanıtılmış iki özelliktir. Bu yapı genellikle Tiered Administration modeli ve Privileged Access Management (PAM) kapsamında kullanılır.

Authentication Policy (Kimlik Doğrulama İlkesi) Nedir?

Authentication Policy, belirli kullanıcılar veya bilgisayarlar için kimlik doğrulama davranışlarını kısıtlamak ve kontrol etmek amacıyla kullanılan bir politikadır.

Ne işe yarar?

• Bir kullanıcının hangi bilgisayarlarda oturum açabileceğini tanımlayabilirsin.
• Kerberos biletlerinin süresini sınırlayabilirsin.
• Kimlik doğrulama taleplerine denetim (audit) uygulayabilirsin.

Örnek kullanım:

• “Domain Admin” kullanıcısı sadece belirli yönetim sunucularında oturum açabilsin.
• Belirli bir servis hesabı sadece belirli saat aralıklarında kullanılabilsin.

Örnek kullanım

İlk olarak “Default Domain Policy” ve “Default Domain Controllers Policy bazı düzenlemeler yapmamız gerekiyor.

İlk olarak “Default Domain Controllers Policy”de aşağıdaki ayarları yapıyoruz.

“Default Domain Policy” ise aşağıdaki ayarı yapıyoruz.

Politika Oluşturma Adımları

Aşağıdaki ekran görüntüsünde yeni bir Authentication Policy’nin nasıl oluşturulduğu gösterilmektedir:

1. Active Directory Administrative Center (ADAC) arayüzü açılır.
   
2. Sol menüden Authentication sekmesine tıklanır.
   
3. Sağ kısımda boş bir alana sağ tıklanarak New > Authentication Policy seçilir.
   
4. Açılan pencerede:
   • Display Name alanına politika adı girilir. Örneğimizde bu, T0 Admin Erisim olarak belirlenmiştir.
     
   • Enforce policy restrictions seçeneği işaretlenerek kısıtlamaların aktif olarak uygulanması sağlanır.
     

Ticket Granting Ticket (TGT) Süresini Sınırlama

Authentication Policy konfigürasyonunun bir parçası olarak, kullanıcı hesaplarına ait Kerberos Ticket Granting Ticket (TGT) süresi sınırlandırılabilir. Bu sayede belirli bir süreden sonra kullanıcıların yeniden kimlik doğrulaması yapmaları zorunlu hale getirilir.

Yukarıdaki ekran görüntüsünde, “User Sign On” sekmesi altındaki ilgili ayar yapılandırılmıştır:

• Specify a Ticket Granting Ticket lifetime for user accounts seçeneği işaretlenmiştir.
  
• Ticket-Granting-Ticket Lifetime değeri 120 dakika olarak belirlenmiştir.

Bu yapılandırma sayesinde, bu Authentication Policy’ye dahil olan kullanıcı hesapları için verilen TGT’lerin süresi maksimum 2 saat ile sınırlandırılmış olur. Böylece yetki süreleri daha kısa tutulur, saldırı yüzeyi daraltılır ve kimlik doğrulamanın periyodik olarak tekrarlanması sağlanır.

Authentication Policy Silo Oluşturulması

Authentication Policy Silo, belirli kullanıcı, bilgisayar ve servis hesaplarının sadece tanımlı kimlik doğrulama politikaları altında çalışmasını sağlayan bir güvenlik yapısıdır. Authentication Policy ile birlikte kullanıldığında, domain ortamındaki yüksek ayrıcalıklı hesapların erişimi üzerinde daha sıkı denetim sağlanabilir.

Yeni Authentication Policy Silo Oluşturma

Aşağıdaki ekran görüntüsünde, “T0 Admin Silo” adında yeni bir Authentication Policy Silo’nun oluşturulma süreci yer almaktadır.

Genel Bilgiler

• Display name: Silo’nun adı, örnekte T0 Admin Silo olarak tanımlanmıştır.
  
• Protect from accidental deletion: Silinmeye karşı koruma etkinleştirilmiştir.
  
• Policy Mode: Enforce silo policies seçilerek bu yapılandırmanın aktif şekilde uygulanması sağlanır.

Permitted Accounts (İzin Verilen Hesaplar)

Bu alanda, silo altında korunacak kullanıcı ve bilgisayar hesapları tanımlanır:

• DC: Bilgisayar hesabı (örneğin domain controller).
• t0.msyilmaz: Yüksek yetkili bir kullanıcı hesabı.

Authentication Policy Ataması

Silo içerisinde tanımlı hesaplara uygulanacak Authentication Policy aşağıdaki gibi belirlenmiştir:

• Use a single policy seçeneği ile tüm hesaplar için aynı Authentication Policy kullanılır.
• Bu örnekte, daha önce oluşturduğumuz T0 Admin Erisim politikası atanmıştır.

Alternatif olarak, her hesap türü (kullanıcı, bilgisayar, servis) için ayrı ayrı politika atamak da mümkündür. Bu esneklik sayesinde organizasyonlar ihtiyaçlarına göre özelleştirilmiş erişim kontrolü sağlayabilir.

Kullanıcı Hesabına Authentication Policy Silo Atama

Yukarıdaki ilk ekran görüntüsünde, t0.msyilmaz adlı yüksek yetkili kullanıcıya aşağıdaki atamalar yapılmıştır:

• Authentication Policy: T0 Admin Erisim
  (Doğrudan uygulanabilir ya da sadece silo üzerinden devreye alınabilir.)
  
• Authentication Policy Silo: T0 Admin Silo
  Bu kutu işaretlenerek ilgili silo, kullanıcı hesabına atanmış olur.

Bu sayede t0.msyilmaz kullanıcısı, sadece tanımlı cihazlarda ve tanımlı kurallar çerçevesinde oturum açabilecektir.

Bilgisayar Hesabına Authentication Policy Silo Atama

İkinci ekran görüntüsünde ise DC (Domain Controller) bilgisayar nesnesine T0 Admin Silo atanmıştır. Böylece silo kapsamındaki tüm kullanıcılar sadece bu bilgisayarda oturum açabilecektir. Güvenlik açısından bu oldukça kritik bir adımdır, çünkü yüksek yetkili hesapların sadece güvenilen makinelerde kullanılmasını sağlar.

Delegation Ayarlarına Dikkat!

Ayrıca, bilgisayarın “Delegation” sekmesinde yer alan yetki devri (delegasyon) ayarları da kontrol edilmelidir. Özellikle “Do not trust this computer for delegation” seçeneği aktif değilse, bu durum kimlik bilgilerinin başka sistemlere sızdırılma riskini doğurabilir. Authentication Silos ile birlikte delegation kısıtlaması da önerilir.

Protected Users Security Group Nedir?

Protected Users bir Security Group’tur ve bu gruba üye olan kullanıcılar için kimlik doğrulama ve kimlik bilgisi saklama politikaları çok daha sıkı hale gelir. Bu grubun amacı, hassas hesapların kimlik bilgilerinin çalınmasını, yanlış protokollerle kimlik doğrulaması yapılmasını ve zayıf güvenlik yapılandırmaları ile kullanılmasını engellemektir.

Gruba Üye Olan Hesaplara Uygulanan Kısıtlamalar

Bir kullanıcı Protected Users grubuna eklendiğinde, aşağıdaki sıkı kurallar devreye girer:

1. NTLM ile Kimlik Doğrulama Engellenir

• Üye kullanıcılar için NTLM authentication kullanılamaz.
• Bu, pass-the-hash gibi saldırılara karşı etkili bir korumadır.

2. DES ve RC4 Şifreleme Algoritmaları Devre Dışı Bırakılır

• Bu algoritmalar zayıf bulunduğundan Protected Users için Kerberos sadece daha güçlü algoritmaları kullanır (AES256, AES128).

3. TGT (Ticket Granting Ticket) Süresi 4 Saatle Sınırlandırılır

• Kullanıcının Kerberos bilet süresi maksimum 4 saat olur, sonrasında yeniden kimlik doğrulaması gerekir.

4. Hesap Kimlik Bilgileri Yerel Olarak Saklanmaz

• Kullanıcı adı/şifre gibi bilgilerin LSASS belleğinde saklanması engellenir.
• Credential theft (örneğin mimikatz) gibi saldırılara karşı güçlü koruma sağlar.

5. Delegation (Yetki Devri) Kapatılır

• Protected Users üyeleri Kerberos Delegation için uygun değildir.
• “Trust this computer for delegation” ayarları devre dışı kalır.

Bizim senaryomuzda domain admins hesaplar gibi sensitive hesapları bu gruba eklemiliyiz.

Protected Users Grubunda Yaşanabilecek Uyumluluk Sorunları

Örnek: Veeam ONE Giriş Problemi

Veeam ONE gibi bazı uygulamalar:

• NTLM ile oturum açmayı deneyebilir,
• Hizmet hesabının kimlik bilgisini LSASS belleğinde saklamaya çalışabilir,
• Ya da eski şifreleme algoritmalarını kullanıyor olabilir (RC4 gibi).

Bu durumda: Protected Users grubuna dahil edilen kullanıcı, Veeam ONE arabirimine login olmaya çalıştığında:

• Kimlik doğrulama başarısız olur.
• Oturum açma hataları veya “Authentication failed” uyarıları alınabilir.
• Event log’larda Kerberos/NTLM ile ilgili hatalar görülebilir (örneğin Event ID 4776, 4625).