Active Directory Penetrasyon Testleri #3 — Forest Trust
Herkese merhaba. Bu yazıda Active Directory Trust kavramına ve içeriğine bir açıklık getirmek istedim çünkü ilerleyen dönemlerde bu trustların kötüye kullanımını konuşacağız.
Active Directory Trustları:
Aşağıdaki diyagram bize birkaç trust tipini göstermekte.
Active Directory ortamında trust, iki domainin kimlik doğrulama sistemlerini birbirine bağlayarak iki sistemdeki kullanıcılara, gruplara ve bilgisayarlara domainlerde bulunan kaynaklara erişim izni verir. Buna ek olarak da kimlik doğrulama trafiğinin bu iki domain arasında bir yönlendirme sistemi ile akmasına olanak sağlar. Bu durum iki aşamalı bir işlemdir. İlk adım trust oluşturmak, ikinci adım ise izinleri belirlemektir.
Trust Yönü: (Tek Yönlü veya Çift Yönlü)
Trustlar tek yönlü veya çift yönlü olabilirler. Çift yönlü trustlarda tahmin edebileceğiniz üzere her iki domain de birbirine erişim sağlayabilir. Tek yönlü trustlarda ise “Domain A trust domain B” kavramı söz konusudur. Buradaki A domaini “Trusting Domain”, B domaini ise “Trusted Domain” olarak adlandırılır. Belirli bir domaine sahip olan kullanıcının aralarında trust ilişkisi bulunan bir domaine erişim sağlayabilmesi için kullanıcıya ait domainin “Trusted Domain” olması gerekmektedir. Eğer kafanız karıştıysa bu kavramı daha iyi anlayabilmek için aşağıdaki şemayı inceleyebilirsiniz.
Hala aklınıza yatmadıysa bunu bir örnekle açıklamaya çalışayım. Örneğin Eşref, okuması için kitabını Murat’a verecekse Eşref ile Murat arasında bir trust oluşmuş oluyor. Burada trustın yönü Eşref Murat’a izin verdiği için Eşref’den Murat’a şeklinde oluyor. Erişim yönünde ise durum Murat Eşref’in kitabına erişim sağlayacağı için Murat’dan Eşref’e yönünde gerçekleşiyor. Murat ve Eşref’i domainlere entegre edecek olursak burada Murat trusted domain, Eşref trusting domain oluyor. Eğer domain isimlerine de takıldıysanız tam çeviri bakımından burada kitabına erişimin iznini verdiğinden dolayı güvenen kişi Eşref yani trusting, güvenilmiş kişi ise Murat yani trusted domain olarak örnekleniyor.
AD Trust Türleri:
Çeşitli Trust tipleri bulunmaktadır. Aşağıdaki tabloda bazı trust tipleri açıklanmıştır.
Forestlarda Transitive Trust:
Forestdaki diğer trusted domainlere uzanan bir trust tipidir. Örnek verecek olursak: “Eğer A domaini ile B domaini arasında bir trust varsa ve buna ek olarak B domaini ile de C domaini arasında bir trust varsa bunun sonuncunda A domaini ile C domaini arasında da bir trust vardır.” önermesini sunabiliriz.
Forestlarda Automatic Trust:
Varsayılan olarak iki yönlü ve geçişli trustlar, bir child domain eklendiğinde ya da bir domain tree eklendiğinde otomatik olarak oluşturulurlar. Varsayılan olarak gelen iki trust tipi Parent-Child trust ve Tree-Root trust tipleridir.
Parent-Child Domainler Arasındaki Trust Akışı:
Aşağıda Kerberos sürecini trust sınırları içerisinde görselleştirmek için bir görsel verilmiştir.
Burada TGT “Ticket Granting Ticket” anlamına gelir. TGT clientın Kerberos bölgesinde ek ticketlar edinmesini sağlayan özel bir tickettır. Client, Key Distribution Center’a(KDC) ticket için bir istek gönderdiğinde KDC client için bir TGT oluşturur. Bunu yaparken de clientın keyi ile TGT’yi şifreler. Sonrasında şifreli TGT’yi clienta yollar. Client aldığı şifreli TGT’yi kendi keyi ile çözer ve çözdüğü TGT’yi kendi bünyesinde barındırır. Bu TGT clientın kimliğini gösterir.
Şemadaki TGS ise “Ticket Granting Service” anlamına gelir. TGS, bir client Kerberos servisine bağlantı istediğinde servis ticketı veren bir KDC bileşenidir. Clientın bir TGS’ye sahip olabilmesi için öncelikle geçerli bir TGT’ye sahip olması gerekmektedir.
Inter-Realm TGT -> Forestlar arası trustlarda kimlik doğrulaması durumunda, Domain1'in krbtgt hesabı ile şifrelemek yerine, daha önce domainlerin değiş tokuş ettiği inter-realm trust keyi ile şifreleme işlemi gerçekleşir. Buna “Inter-realm ticket-granting-ticket/TGT” adı verilir. Sonrasında Domain2 başvuruda yer alan TGT’yi doğrular ve değiş tokuş edilen inter-realm key ile TGT’nin şifrelemesini çözer. Bu arada bir inter-realm TGT sahte olabilir. Bu durumu da gelecekteki yazılarda canlandıracağız.
Bir sonraki yazıda Kerberoasting’i gösterirken Kerberos sürecini ayrıntılı olarak açıklayacağım.
Her neyse, biz tekrar şemamıza dönelim ve şemamızı açıklayalım. Domain1'den bir istemci Domain2'de bulunan bir sunucuya erişmek istiyor. Bu süreçte şöyle gerçekleşiyor:
1)Domain1'den bir client DC1'den bir TGT istiyor.
2)DC1, TGT ile yanıt veriyor.(krbtgt hashi kullanılıyor)
3)Client elindeki TGT’yi göstererek Domain2'den sunucuya erişmek için bir TGS istiyor.
DC1, sunucuyu geçerli olan domainde bulamadığından ve sunucu Domain2'de bulunduğundan, TGS’nin DC2(Domain2) tarafından yayınlanması gerektiğini fark ediyor ve böylece clienta Inter-realm TGT dönüyor.
4)Client, Domain2'deki DC2'ye Inter-realm trust key ile şifrelenmiş TGT’yi göstererek TGS sunucuya erişim istiyor.
5)DC2, sunucunun hashi ile şifrelenen TGS ile geri dönüyor.
6)Client, erişim için sunucuya şifrelenmiş TGS’yi sunuyor.
Trust Oluşturulurken Kimlik Doğrulamanın Kapsamı:
Trust, oluşturulurken kapsamın ne kadar olacağını sorar. Biz bu ortamda “Selective Authentication”u kullanacağız ve ortamımız diğer forestlardaki sunuculara erişebilecek bir jump servera sahip olacak. Öncelikle kimlik doğrulama kapsamlarının iki çeşidini açıklayalım.
— Forest-wide Authentication — : Eğer biz Forest-wide Authentication kullanıyorsak, diğer forestlardaki kullanıcılar bizim baz aldığımız forestdaki kaynaklara sanki o forestın üyesiymiş gibi erişim sağlayabilirler.
— Selective Authentication — : Selective Authentication durumunda, domaindeki her bir bilgisayara ve diğer forestdaki kullanıcılara erişebilecekleri kaynaklar hakkında kendiniz, elle izin vermeniz gerekmektedir.
Bir kullanıcının Selective Authentication’da kimliğini doğrulamasına izin vermek için aşağıda gösterilen ACE’yi(Access Control Entry) düzenlemeniz gerekmektedir.
Uygulama
Şimdi iki domain arasında trust kuracağız. Diyelim ki bir “production.scriptdotsh.local” domainine ve diğer bir forestda “solar.local” domainine sahibiz.
Forestlar arasında trust oluşturmadan önce, her iki taraftaki domainde domain adminleri gibi yeterli yetkiye sahip olduğumuzdan emin olmamız gerekmektedir. DNS her iki tarafta da düzgün yapılandırılmalıdır ve her forest diğer forestlarda bulunan DNS adını ve SRV kayıtlarını DNS Zone( Stub zone gibi) ya da conditional forwarding kullanarak çözebilmelidir.
DNS Stub Zone’u Eklemek:
Öncelikle birincil domainimiz olan production.scriptdotsh.local ile başlayalım. DC’ye giriş yapıp DNS Manager Console’u açalım. Forward Lookup Zones klasörüne sağ tıklayıp “New Zone”u seçelim.
Zone Type sayfasında Stub zone’u seçip next diyelim.
Varsayılanları koruyup devam edelim.
Bu alana yazmamız gereken domain adının diğer forestdaki domain adıyla eşleşmesi gerekir. Bizim durumumuzda bu isim solar.local olacak.
Bu bölümde, söz konusu DNS sunucusunun IP adresini ya da diğer domain’ni DC’sini girin ve next diyin.
Zone’u oluşturmak için Finish diyin.
Solar.local domaininde, scriptdotsh stub zone’unu eklemek için DNS sunucusunda aynı işlemleri uygulayın. Ekledikten sonra, bağlantının çalışıyor olması gerekmekte.
Şimdi, DNS ayarlarıyla olan işimiz bitti, bir sonraki adım iki forest arası trust oluşturmak olacak.
Trust Oluşturmak:
AD’de trust oluşturmak için “administrative tools”dan Active Directory Domain and Trusts’ı açın.
Domain adına sağ tıklayın ve properties’i seçin.
Trust sekmesine gidin. Bu sekme, trust türleri ile tüm domainlerin bir listesini gösterir. Gördüğünüz üzere, burada gösterilen bir trusta sahibim. Scriptdotsh.local ve onun child domaini production.scriptdotsh.local arasından bir Parent-Child trust var. Bu trust, child domaini foresta eklediğimde otomatik olarak oluşturuldu.
Yeni bir trust oluşturmak için, trust sekmesi altındaki “New Trust”ı seçin ve karşılama ekranını atlamak için next diyin.
Burada trust oluşturmanız için gereken domain adını ya da forest adını yazmamız gerekiyor. Bu adın daha önce oluşturulmuş DNS stub zone adıyla eşleşmesi gerekiyor. Bu durumda bizim gireceğimiz değer solar.local’dir.
One-way outgoing seçeneğini seçin ve next diyin.
Şimdi, “both this domain and the specified domain” seçeneğini seçin.
Belirtilen domainde trust oluşturma hakkına sahip olan kullanıcının bilgilerini girin.(solar.local admini)
Next diyin, şimdi kimlik doğrulama tipini seçmemiz gerekiyor. Bunun için de “Selective Authentication”u seçin.
Bu yaptığımız ayar ile kullanıcılar otomatik olarak yetkilendirme sahibi olmayacak. Yetkilendirmeleri bizim elle yapmamız gerekmekte. Next diyin ve işlemi tamamlamak için trust’ı onaylayın.
SID filtrelemenin etkin olduğunu söyleyen iletişim kutusunu göreceksiniz. OK diyin.
Not: SID filtreleme, tüm forestlar arası trustlarda carsayılan olarak etkindir. Microsof, güvenlik sınırını domain olarak değil forest olarak kabul eder. SID geçmişi özelliğini child domaine root yetkisi vermek için kullanabiliriz.
Gördüğünüz üzere External bir Trust oluşturuldu.
Bu trustın properties sekmesine tıklayın ve trustı doğrulamak için validate seçeneğini seçin.
Umurım AD’de nasıl trust oluşturulacağını öğretebilmişimdir. Kendiniz de trust oluşturmayı deneyebilirsiniz.
Gelecek yazılar için takipte kalın, okuduğunuz için teşekkürler.
