Lab Erişimi için: https://tryhackme.com/r/room/winadbasics

Microsoft’in Active Directory’si kurumsal dünyada temel bir yapı taşıdır. Cihazların ve kullanıcıların kurumsal bir ortamda yönetimini basitleştirir. Bu odada, Active Directory’nin temel bileşenlerine derinlemesine bir bakış yapacağız.

Oda Hedefleri

Bu odada, Active Directory’yi öğrenip aşağıdaki konular hakkında bilgi sahibi olacağız:

• Active Directory nedir
• Active Directory Domain nedir
• Bir Active Directory Domain’inin bileşenleri
• Forest ve Domain Trust
• Ve daha fazlası!

Oda Ön Koşulları

Windows ile genel bir aşinalık. Windows Temelleri modülüne göz atarak daha fazla bilgi edinebilirsiniz.

Küçük bir işletme ağını beş bilgisayar ve beş çalışanla yönettiğinizi hayal edin. Böyle küçük bir ağda, her bilgisayarı ayrı ayrı yapılandırmakta sorun yaşamazsınız. Her bilgisayara manuel olarak giriş yapar, her kullanıcı için hesaplar oluşturur ve her çalışanın hesapları için belirli yapılandırmalar yaparsınız. Bir kullanıcının bilgisayarı çalışmazsa, muhtemelen yerinde müdahale ederek bilgisayarı onarırsınız.

Bu durum kulağa oldukça rahat bir yaşam tarzı gibi gelse de, işiniz aniden büyüyüp dört farklı ofiste bulunan 157 bilgisayar ve 320 farklı kullanıcıya sahip olduğunda ne olur? Artık her bilgisayarı ayrı birim olarak yönetip, ağdaki her kullanıcı için politikaları manuel olarak yapılandırmak ve herkese yerinde destek sağlamak mümkün olmayabilir.

Bu sınırlamaları aşmak için Windows domain’ini kullanabiliriz. Basitçe söylemek gerekirse, bir Windows domain’i, belirli bir işletmenin yönetimi altındaki kullanıcılar ve bilgisayarlar grubudur. Bir domain’in ana fikri, bir Windows bilgisayar ağıyla ilgili ortak bileşenlerin yönetimini tek bir havuzda, Active Directory (AD) olarak bilinen bir yerde merkezileştirmektir. Active Directory hizmetlerini yürüten sunucuya Domain Controller (DC) denir.

Bir Windows domain’inin yapılandırılmasının ana avantajları şunlardır:

Merkezi kimlik yönetimi: Ağ üzerindeki tüm kullanıcılar, Active Directory üzerinden minimum çabayla yapılandırılabilir.

Güvenlik politikalarının yönetimi: Güvenlik politikalarını doğrudan Active Directory’den yapılandırabilir ve ağ üzerindeki kullanıcılar ve bilgisayarlar için gerektiği şekilde uygulayabilirsiniz.

Gerçek Dünya Örneği

Eğer bu biraz kafa karıştırıcı geldiyse, okulunuzda, üniversitenizde veya işinizde bir Windows domain’i ile muhtemelen daha önce etkileşimde bulunmuşsunuzdur.

Okul/üniversite ağlarında genellikle, kampüsteki herhangi bir bilgisayarda kullanabileceğiniz bir kullanıcı adı ve şifre sağlanır. Kimlik bilgileriniz tüm makineler için geçerlidir çünkü bu bilgileri bir makinede girdiğinizde, kimlik doğrulama süreci Active Directory’ye yönlendirilir ve kimlik bilgileriniz burada kontrol edilir. Active Directory sayesinde, kimlik bilgileriniz her makinede bulunmak zorunda değildir ve ağ boyunca erişilebilir durumdadır.

Active Directory ayrıca okulunuzun/üniversitenizin, kontrol paneline erişmenizi kısıtlamasına da olanak tanır. Politikalar genellikle ağ boyunca dağıtılır, böylece bu bilgisayarlar üzerinde yönetici ayrıcalıklarına sahip olmazsınız.

THM Inc.’e Hoş Geldiniz

Bu görevde, THM Inc.’de yeni IT yöneticisi rolünü üstleneceğiz. İlk görev olarak, mevcut “THM.local” domain’ini gözden geçirmemiz ve bazı ek yapılandırmalar yapmamız istendi. Görevleri yerine getirmek için önceden yapılandırılmış bir Domain Controller (DC) üzerinde yönetici yetkilerine sahip olacaksınız.

Tüm görevler için aynı makineyi kullanacağınızdan, şimdi Start Machine düğmesine tıklamayı unutmayın. Bu, tarayıcınızda bir makine açmalıdır. Eğer RDP üzerinden bağlanmayı tercih ederseniz, aşağıdaki kimlik bilgilerini kullanabilirsiniz:

Not: RDP üzerinden bağlanırken, THM etki alanındaki Administrator kullanıcısını kullanarak oturum açmak istediğinizi belirtmek için kullanıcı adı olarak THM\Administrator kullanın.

Herhangi bir Windows Domain’in temeli Active Directory Domain Services (AD DS) hizmetidir. Bu hizmet, ağınızdaki tüm “nesnelerin” bilgilerini tutan bir katalog olarak işlev görür. AD tarafından desteklenen birçok nesne türü arasında kullanıcılar, gruplar, makineler, yazıcılar, paylaşımlar ve daha fazlası bulunur. İşte bazılarına göz atalım:

Kullanıcılar

Kullanıcılar, Active Directory’deki en yaygın nesne türlerinden biridir. Kullanıcılar, güvenlik ilkelere sahip nesnelerden biridir, yani domain tarafından kimlik doğrulaması yapılabilir ve dosyalar veya yazıcılar gibi kaynaklar üzerinde ayrıcalıklar atanabilir. Bir güvenlik ilkesinin, ağdaki kaynaklar üzerinde işlem yapabilen bir nesne olduğunu söyleyebilirsiniz.

Kullanıcılar, iki tür varlığı temsil etmek için kullanılabilir:

• Kişiler: Kullanıcılar genellikle ağınıza erişmesi gereken organizasyonunuzdaki kişileri temsil eder, örneğin çalışanlar.
• Hizmetler: Ayrıca, IIS veya MSSQL gibi hizmetler tarafından kullanılan kullanıcıları tanımlayabilirsiniz. Her hizmetin çalışması için bir kullanıcıya ihtiyaç vardır, ancak hizmet kullanıcıları, belirli hizmetlerini çalıştırmak için gerekli olan ayrıcalıklara sahip olacaktır.

Makineler

Makineler, Active Directory içindeki diğer bir nesne türüdür; Active Directory domain’ine katılan her bilgisayar için bir makine nesnesi oluşturulur. Makineler de “güvenlik ilkeleri” olarak kabul edilir ve herhangi bir normal kullanıcı gibi bir hesap atanır. Bu hesap, domain içinde sınırlı haklara sahiptir.

Makine hesapları, atanan bilgisayarlarda yerel yöneticidir; genellikle bilgisayardan başka hiç kimse tarafından erişilmemesi gerekir, ancak diğer hesaplarda olduğu gibi şifreye sahipseniz, bu şifreyi kullanarak giriş yapabilirsiniz.

Not: Makine Hesap şifreleri otomatik olarak döndürülür ve genellikle 120 rastgele karakterden oluşur.

Makine hesaplarını tanımlamak nispeten kolaydır. Belirli bir adlandırma şemasını takip ederler. Makine hesap adı, bilgisayarın adının ardından bir dolar işareti ile gelir. Örneğin, DC01 adında bir makine, DC01$ adında bir makine hesabına sahip olacaktır.

Güvenlik Grupları

Windows ile ilgiliyseniz, dosyalara veya diğer kaynaklara erişim haklarını tüm gruplara atayabileceğinizi bilirsiniz, böylece tek tek kullanıcılar yerine gruplara erişim verebilirsiniz. Bu, yönetimi daha iyi hale getirir çünkü bir kullanıcıyı mevcut bir gruba eklediğinizde, grup üyeliğinin tüm ayrıcalıklarını otomatik olarak devralır. Güvenlik grupları da güvenlik ilkeleri olarak kabul edilir ve bu nedenle ağ üzerindeki kaynaklar üzerinde ayrıcalıklara sahip olabilirler.

Gruplar, kullanıcılar ve makineler dahil olabilir. Gerektiğinde, gruplar diğer grupları da içerebilir.

Bir domain içinde varsayılan olarak oluşturulan birkaç grup, kullanıcılara belirli ayrıcalıklar vermek için kullanılabilir. İşte bir domain’deki en önemli gruplardan bazıları:

Güvenlik Grubu	Açıklama
Domain Admins	Bu grubun kullanıcıları, tüm domain üzerinde yönetim ayrıcalıklarına sahiptir. Varsayılan olarak, domain’deki herhangi bir bilgisayarı, DC’leri dahil olmak üzere yönetebilirler.
Server Operators	Bu gruptaki kullanıcılar, Domain Controller’ları yönetebilirler. Yönetici grup üyeliklerini değiştiremezler.
Backup Operators	Bu gruptaki kullanıcılar, herhangi bir dosyayı erişebilir ve izinlerini görmezden gelebilirler. Bilgisayarlardaki verilerin yedeğini almak için kullanılırlar.
Account Operators	Bu gruptaki kullanıcılar, domain’de diğer hesapları oluşturabilir veya değiştirebilirler.
Domain Users	Domain’deki tüm mevcut kullanıcı hesaplarını içerir.
Domain Computers	Domain’deki tüm mevcut bilgisayarları içerir.
Domain Controllers	Domain’deki tüm mevcut DC’leri içerir.

Varsayılan güvenlik gruplarının tam listesini Microsoft belgelerinden ulaşabilirsiniz.

Active Directory Kullanıcıları ve Bilgisayarları

Active Directory’de kullanıcıları, grupları veya makineleri yapılandırmak için Domain Controller’a giriş yapmanız ve Başlat menüsünden “Active Directory Kullanıcıları ve Bilgisayarları”nı çalıştırmanız gerekir:

Bu, domain’de bulunan kullanıcıların, bilgisayarların ve grupların hiyerarşisini görebileceğiniz bir pencere açacaktır. Nesneler, kullanıcıları ve makineleri sınıflandırmanıza olanak tanıyan Organizational Unit’ler (OU’lar) içinde düzenlenir. OU’lar, benzer politika gereksinimlerine sahip kullanıcı kümelerini tanımlamak için kullanılır. Örneğin, organizasyonunuzdaki Satış departmanındaki kişilerin, BT’deki kişilere kıyasla farklı bir politika setine sahip olmaları muhtemeldir. Bir kullanıcının aynı anda sadece bir OU’nun parçası olabileceğini unutmayın.

Makinemizi kontrol ettiğimizde, zaten THM adında bir OU’nun ve IT, Yönetim, Pazarlama ve Satış departmanları için dört alt OU’nun bulunduğunu görebiliyoruz. OU’ların genellikle işyerinin yapısını yansıtması yaygındır, çünkü bu, tüm departmanlara uygulanan temel politikaları etkili bir şekilde dağıtmaya olanak tanır. Bu modelin çoğu zaman beklenen model olduğunu unutmayın, ancak OU’ları keyfi olarak tanımlayabilirsiniz. Eğlenceli olması için THM OU’suna sağ tıklayarak altında “Öğrenciler” adında yeni bir OU oluşturabilirsiniz.

Herhangi bir OU’yu açtığınızda, içerdiği kullanıcıları görebilir ve gerektiğinde kullanıcıları oluşturma, silme veya değiştirme gibi basit görevleri gerçekleştirebilirsiniz. Ayrıca, gerekirse parolaları sıfırlayabilirsiniz (bu, yardım masası için oldukça kullanışlıdır).

Muhtemelen THM OU’nun dışında başka varsayılan container’ların da olduğunu fark etmişsinizdir. Bu container’ların Windows tarafından otomatik olarak oluşturulur ve şunları içerir:

• Builtin: Her Windows hostu için mevcut olan varsayılan grupları içerir.
• Computers: Ağa katılan herhangi bir makine burada yer alır. Gerekirse bunları taşıyabilirsiniz.
• Domain Controllers: Ağınızdaki DC’leri içeren varsayılan OU’dur.
• Users: Alan genelinde geçerli olan varsayılan kullanıcılar ve grupları içerir.
• Managed Service Accounts: Windows alanınızdaki hizmetler tarafından kullanılan hesapları barındırır.

Güvenlik Grupları vs OUs

Neden hem gruplar hem de OUs olduğunu merak ediyor olabilirsiniz. Her ikisi de kullanıcıları ve bilgisayarları sınıflandırmak için kullanılsa da, amaçları tamamen farklıdır:

• OUs: Kullanıcılara ve bilgisayarlara politikalar uygulamak için kullanışlıdır. Bu politikalar, kullanıcıların kurumdaki özel rollerine bağlı olarak belirli yapılandırmaları içerir. Bir kullanıcı sadece bir OU’nun üyesi olabilir çünkü aynı kullanıcıya iki farklı politika seti uygulamak mantıklı olmaz.
• Güvenlik Grupları: Kaynaklar üzerinde izin vermek için kullanılır. Örneğin, bazı kullanıcıların paylaşılmış bir klasöre veya ağ yazıcısına erişim izni vermek istiyorsanız grupları kullanırsınız. Bir kullanıcı birçok grubun üyesi olabilir; bu da birden fazla kaynağa erişim izni verilmesi için gereklidir.

Soru 3: Bir etki alanındaki tüm bilgisayarları ve kaynakları normalde hangi grup yönetir?
Cevap 3: Domain Admins
Soru 4: TOM-PC adlı bir makineyle ilişkili makine hesabının adı ne olur?
Cevap 4: TOM-PC$
Soru 5: Şirketimizin Kalite Güvencesi için yeni bir departman oluşturduğunu varsayalım. Politikaların tutarlı bir şekilde uygulanabilmesi için tüm Kalite Güvence kullanıcılarını gruplandırmak için ne tür kapsayıcılar kullanmalıyız?
Cevap 5: Organizational Unit

Yeni domain admin olarak ilk göreviniz mevcut AD OUs ve kullanıcıları kontrol etmektir çünkü işte bazı son değişiklikler olmuştur. Size verilen organizasyon şemasına göre AD’de değişiklikler yapmanız beklenmektedir:

Ekstra OUs ve kullanıcıları silmek

İlk olarak, mevcut AD yapılandırmanızda şemada yer almayan ek bir bölüm OU’su olduğunu fark etmelisiniz. Bütçe kesintileri nedeniyle kapatıldığı ve alanından kaldırılması gerektiği belirtilmiştir. OU’yu sağ tıklayıp silmeye çalıştığınızda aşağıdaki hatayı alırsınız:

Default olarak, OU’lar yanlışlıkla silinmeye karşı korunur. OU’yu silmek için View menüsündeki Advanced Features etkinleştirmemiz gerekir:

Bu size bazı ek kapsayıcılar gösterecek ve yanlışlıkla silme korumasını devre dışı bırakmanızı sağlayacaktır. Bunu yapmak için, OU’ya sağ tıklayın ve Özellikler’e gidin. Korumayı devre dışı bırakmak için Nesne sekmesinde bir onay kutusu bulacaksınız:

Kutuyu işaretlemeyi unutmayın ve OU’yu yeniden silmeyi deneyin. OU’yu silmek istediğinizi onaylamanız istenecektir ve bunun sonucunda altındaki tüm kullanıcılar, gruplar veya OUs da silinecektir.

Ekstra OU’yu sildikten sonra, bazı bölümler için AD’deki kullanıcıların organizasyon şemasındaki kullanıcılarla eşleşmediğini fark etmelisiniz. Şemaya uyacak şekilde kullanıcıları oluşturun ve silin.

Delegation

AD’de yapabileceğiniz hoş şeylerden biri, belirli kullanıcılara bazı OUs üzerinde kontrol verme yetkisi tanımaktır. Bu süreç Delegation olarak bilinir ve kullanıcılara belirli görevleri, bir Domain Administrator’ün müdahalesi olmadan gerçekleştirebilmeleri için özel ayrıcalıklar verir.

Bu kullanım senaryolarından biri, IT support ekibine diğer düşük ayrıcalıklı kullanıcıların parolalarını sıfırlama yetkisi vermektir. Organizasyon şemamızda Phillip IT support’tan sorumlu olduğundan, Sales, Marketing ve Management OUs üzerinde parola sıfırlama yetkisini ona devretmek isteyebiliriz.

Bu örnekte, Sales OU üzerinde kontrolü Phillip’e devredeceğiz. Bir OU üzerinde yetki devretmek için, OU’ya sağ tıklayıp “Delegation” seçeneğini seçebilirsiniz:

Bu, ilk olarak delege etmek istediğiniz kullanıcıların sorulacağı yeni bir pencere açmalıdır: Not: Kullanıcının adını yanlış yazmaktan kaçınmak için “phillip” yazın ve Check Names düğmesine tıklayın. Windows kullanıcıyı sizin için otomatik olarak tamamlayacaktır.

Tamam’a tıklayın ve bir sonraki adımda aşağıdaki seçeneği seçin:

Birkaç kez next butonuna tıkladıktan sonra Phillip artık Sales departmanındaki herhangi bir kullanıcının parolasını sıfırlayabilmelidir. Pazarlama ve Yönetim departmanlarının parola sıfırlamalarını yetkilendirmek için muhtemelen bu adımları tekrarlamak isteyeceksiniz, ancak bu görev için burada bırakacağız. İsterseniz diğer OU’ları yapılandırmaya devam etmekte özgürsünüz. Şimdi Sophie’nin parolasını sıfırlamak için Phillip’in hesabını kullanalım. İşte RDP üzerinden oturum açmanız için Phillip’in kimlik bilgileri:

Username	phillip
Password	Claire2008

Not: RDP üzerinden bağlanırken, THM etki alanındaki phillip kullanıcısını kullanarak oturum açmak istediğinizi belirtmek için kullanıcı adı olarak THM\phillip kullanın.

Phillip’in yeni yetkilerini denemek ve test etmek için Active Directory Users and Computers’a gitmek isteyebilirsiniz, ancak bunu açmak için gerçekten ayrıcalıklara sahip değildir, bu nedenle parola sıfırlamaları yapmak için başka yöntemler kullanmanız gerekecektir. Bu durumda, bunu yapmak için Powershell kullanacağız:

WindowsPowerShell(As Phillip)

PS C:\Users\phillip> Set-ADAccountPassword sophie -Reset -NewPassword (Read-Host -AsSecureString -Prompt 'New Password') -Verbose

New Password: *********

VERBOSE: Performing the operation "Set-ADAccountPassword" on target "CN=Sophie,OU=Sales,OU=THM,DC=thm,DC=local".

Sophie’nin bildiğimiz bir parolayı kullanmaya devam etmesini istemediğimizden, aşağıdaki komutla bir sonraki oturum açmada parola sıfırlamaya da zorlayabiliriz:

Yeni parolanızla Sophie’nin hesabına giriş yapın ve Sophie’nin masaüstünden bir bayrak alın.

Not: RDP üzerinden bağlanırken, THM etki alanındaki sophie kullanıcısını kullanarak oturum açmak istediğinizi belirtmek için kullanıcı adı olarak THM\sophie kullanın.

Önce phillip’e bağlanmak için bir rdp atalım

şimdi phillip’de powershell ile sophie’nin parolasını atayabiliriz.

şimdi bu rdp’den çıkıp sophie’ için rdp atabiliriz.

parolayı philip’inki ile aynı olacak şekilde attım ve burada yazacağım şimdi

ve flag’imiz

Varsayılan olarak, bir domain’e katılan tüm makineler (DC’ler hariç) “Computers” adlı konteynıra yerleştirilir. DC’mizi kontrol edersek, bazı cihazların zaten burada olduğunu göreceğiz:

Ağımızdaki kullanıcıların her birine karşılık gelen bazı sunucuları, dizüstü bilgisayarları ve PC’leri görebiliyoruz. Tüm cihazlarımızın burada olması en iyi fikir değildir, çünkü genellikle sunucularınız ve günlük olarak kullanılan makineler için farklı politikalar uygulamak isteyebilirsiniz.

Cihazlarınızı düzenlemenin kesin bir kuralı olmasa da, iyi bir başlangıç noktası cihazları kullanımına göre ayırmaktır. Genel olarak, cihazların en az üç kategoride bölündüğünü görmeyi bekleyebilirsiniz:

1. İş İstasyonları (Workstations)

İş istasyonları, Active Directory domain içinde en yaygın cihazlardan biridir. Domain’deki her kullanıcı muhtemelen bir iş istasyonuna giriş yapacaktır. Bu, işlerini yapacakları veya normal tarayıcı etkinliklerini gerçekleştirecekleri cihazdır. Bu cihazlara asla ayrıcalıklı bir kullanıcı giriş yapmamalıdır.

2. Sunucular (Servers)

Sunucular, Active Directory domain içinde ikinci en yaygın cihaz türüdür. Sunucular genellikle kullanıcılara veya diğer sunuculara hizmet sunmak için kullanılır.

3. Domain Controller’lar (Domain Controllers)

Domain Controller’lar, Active Directory domain içinde üçüncü en yaygın cihaz türüdür. Domain Controller’lar, Active Directory Domain’i yönetmenizi sağlar. Bu cihazlar genellikle ağdaki en hassas cihazlar olarak kabul edilir, çünkü ortam içindeki tüm kullanıcı hesaplarının hashlenmiş şifrelerini içerirler.

AD’mizi düzenlerken, Workstations ve Servers için iki ayrı OU oluşturacağız (Domain Controllers zaten Windows tarafından oluşturulmuş bir OU’da bulunmaktadır). Bunları doğrudan thm.local domain konteynırı altında oluşturacağız. Sonunda aşağıdaki OU yapısına sahip olmalısınız:

Şimdi, kişisel bilgisayarları ve dizüstü bilgisayarları Bilgisayarlar konteynerinden İş İstasyonları OU’suna ve sunucuları da Sunucular OU’suna taşıyın. Bunu yapmak, daha sonra her bir OU için policies yapılandırmamıza olanak tanıyacaktır.

buradan servers ve workstation adında 2 tane ou oluşturdum.

Şimdi de gerekli taşımaları yapabiliriz.

Şu ana kadar, kullanıcıları ve bilgisayarları sadece düzenli bir şekilde OU’lara yerleştirdik, ancak asıl fikir, her OU için ayrı ayrı farklı politikalar uygulayabilmektir. Böylece, kullanıcıların departmanlarına bağlı olarak farklı yapılandırmalar ve güvenlik standartlarını zorlayabiliriz.

Windows bu tür politikaları Group Policy Objects (GPO) aracılığıyla yönetir. GPO’lar, OU’lara uygulanabilecek ayarların bir koleksiyonudur. GPO’lar, ya kullanıcılara ya da bilgisayarlara yönelik politikaları içerebilir ve belirli makinelerde ve kimliklerde bir temel oluşturmanıza olanak tanır.

GPO’ları yapılandırmak için, Başlangıç menüsünden erişilebilen Group Policy Objects aracını kullanabilirsiniz:

Açtığınızda göreceğiniz ilk şey, daha önce tanımlandığı gibi tüm OU hiyerarşinizdir. Grup İlkelerini yapılandırmak için, önce Grup İlkesi Nesneleri altında bir GPO oluşturursunuz ve ardından bunu ilkelerin uygulanmasını istediğiniz OU’ya bağlarsınız. Örnek olarak, makinenizde zaten var olan bazı GPO’lar olduğunu görebilirsiniz:

Yukarıdaki resimde, 3 GPO’nun oluşturulduğunu görebiliyoruz. Bunlardan Default Domain Policy ve RDP Policy, thm.local etki alanına tamamen bağlıdır ve Default Domain Controllers Policy yalnızca Domain Controllers OU’suna bağlıdır. Önemli bir nokta, herhangi bir GPO’nun bağlı olduğu OU ve alt OU’lara uygulanacağıdır. Örneğin, Sales OU’su hâlâ Default Domain Policy’den etkilenir.

Bir GPO’nun içeriğini incelemek için Default Domain Policy’yi gözden geçirelim. Bir GPO’yu seçtiğinizde göreceğiniz ilk sekme, GPO’nun AD’de hangi kapsamda olduğunu gösterir. Mevcut politika için, yalnızca thm.local etki alanına bağlı olduğunu görebiliyoruz:

Görüldüğü gibi, GPO’lara Güvenlik Filtreleme (Security Filtering) de uygulayabilirsiniz, böylece yalnızca belirli kullanıcılar/bilgisayarlar için geçerli olur. Varsayılan olarak, tüm kullanıcılar/PC’ler dahil olan Authenticated Users grubuna uygulanır.

Settings sekmesi, GPO’nun gerçek içeriğini içerir ve hangi özel yapılandırmaları uyguladığını gösterir. Daha önce belirtildiği gibi, her GPO’nun yalnızca bilgisayarlara ve yalnızca kullanıcılara uygulanan yapılandırmaları vardır. Bu durumda, Default Domain Policy yalnızca Bilgisayar Yapılandırmaları (Computer Configurations) içerir:

GPO’yu keşfetmekten çekinmeyin ve her yapılandırmanın sağındaki “show” bağlantılarını kullanarak mevcut öğeleri genişletin. Bu durumda, Default Domain Policy, çoğu domain için uygulanması gereken temel yapılandırmaları içerir, bunlar arasında şifre ve hesap kilitleme politikaları bulunur:

Bu GPO tüm etki alanı için geçerli olduğundan, yapılacak herhangi bir değişiklik tüm bilgisayarları etkileyecektir. Minimum parola uzunluğu ilkesini, kullanıcıların parolalarında en az 10 karakter olmasını gerektirecek şekilde değiştirelim. Bunu yapmak için GPO’ya sağ tıklayın ve Düzenle’yi seçin:

Bu, tüm mevcut yapılandırmaları gezip düzenleyebileceğimiz yeni bir pencere açacaktır. Minimum şifre uzunluğunu değiştirmek için şu adımları izleyin: Bilgisayar Yapılandırmaları -> Politika -> Windows Ayarları -> Güvenlik Ayarları -> Hesap Politikaları -> Şifre Politikası ve gerekli politika değerini değiştirin:

Görüldüğü gibi, bir GPO içinde pek çok politika oluşturulabilir. Her bir politikayı tek bir odada açıklamak imkânsız olsa da, bazı politikalar oldukça anlaşılır olduğu için biraz keşfetmekten çekinmeyin. Herhangi bir politika hakkında daha fazla bilgiye ihtiyacınız varsa, bunlara çift tıklayarak her birinin Açıklama (Explain) sekmesini okuyabilirsiniz.

GPO Dağıtımı

GPO’lar, DC’de depolanan SYSVOL adlı bir ağ paylaşımı aracılığıyla ağa dağıtılır. Bir domain içindeki tüm kullanıcılar genellikle bu paylaşımı ağa bağlı olarak GPO’larını periyodik olarak senkronize etmek için erişebilirler. SYSVOL paylaşımı, varsayılan olarak her DC’deki C:\Windows\SYSVOL\sysvol\ dizinine işaret eder.

Herhangi bir GPO’da değişiklik yapıldığında, bilgisayarların bu değişiklikleri yakalaması 2 saate kadar sürebilir. Belirli bir bilgisayarın GPO’larını hemen senkronize etmesini istiyorsanız, istenilen bilgisayarda aşağıdaki komutu çalıştırabilirsiniz:

Windows
PowerShell

PS C:\> gpupdate /force

THM Inc. için bazı GPO’lar oluşturma

Yeni işimizin bir parçası olarak, şu iki GPO’yu uygulamamız isteniyor:

1. Kontrol Paneline erişimi IT departmanıyla sınırlamak.
2. İş istasyonları ve sunucuların kullanıcı etkinsizliği nedeniyle ekranlarını 5 dakika sonra otomatik olarak kilitlemelerini sağlamak, böylece oturumların açık kalmasını önlemek.

Bu her bir konuyu ele alalım ve her GPO’da hangi politikaları etkinleştirmemiz gerektiğini ve hangi OUl’ye bağlantı yapmamız gerektiğini tanımlayalım.

Kontrol Paneli Erişimini Kısıtlama

Kontrol Paneli erişimini yalnızca IT departmanındaki kullanıcılara sınırlamak istiyoruz. Diğer departmanlardan gelen kullanıcıların sistem tercihlerinde değişiklik yapabilmelerini istemiyoruz.

Yeni bir GPO oluşturup adını “Kontrol Paneli Erişimini Kısıtla” koyacağız ve düzenlemek için açacağız. Bu GPO’nun belirli kullanıcılara uygulanmasını istediğimiz için, Kullanıcı Yapılandırması altında şu politikayı arayacağız:

Kontrol Paneli ve PC ayarlarına erişimi yasaklama politikasını etkinleştirdiğimize dikkat edin.

GPO yapılandırıldıktan sonra, bu GPO’yu Kontrol Paneline erişim izni olmayan kullanıcılarla ilgili olan tüm OUl’lara bağlamamız gerekecek. Bu durumda, GPO’yu Marketing, Management ve Sales OUl’larına sürükleyerek bağlayacağız.

Otomatik Ekran Kilidi GPO’su

İlk GPO, iş istasyonları ve sunucular için ekran kilitleme ile ilgili olarak, daha önce oluşturduğumuz Workstations, Servers ve Domain Controllers OUs’larına doğrudan uygulanabilir.

Bu çözüm işe yaramalıdır, ancak alternatif bir yöntem olarak GPO’yu doğrudan kök alan adına uygulayabiliriz, çünkü bu GPO’nun tüm bilgisayarlarımızı etkilemesini istiyoruz. Workstations, Servers ve Domain Controllers OUs’ları kök alanın çocuk OU’ları olduğundan, bu politikaları miras alacaklardır.

Not: GPO’nun kök alanına uygulanması durumunda, Sales veya Marketing gibi diğer OUl’lara da miras alınacağını fark edebilirsiniz. Bu OUl’lar sadece kullanıcıları içerdiğinden, GPO’daki herhangi bir Bilgisayar Konfigürasyonu bu OUl’lar tarafından görmezden gelinecektir.

Yeni bir GPO oluşturup, adını Auto Lock Screen koyun ve düzenleyin. İstediğimiz sonuca ulaşmak için gereken politika şu yolda bulunur:

Hareketsizlik sınırını 5 dakika olarak ayarlayacağız, böylece herhangi bir kullanıcı oturumunu açık bırakırsa bilgisayarlar otomatik olarak kilitlenecektir. GPO düzenleyicisini kapattıktan sonra, GPO’yu kök etki alanına sürükleyerek GPO’yu bağlayacağız:

GPO’lar doğru OU’lara uygulandıktan sonra, doğrulama için Pazarlama, Satış veya Yönetim’deki herhangi bir kullanıcı olarak oturum açabiliriz. Bu görev için Mark’ın kimlik bilgilerini kullanarak RDP üzerinden bağlanalım:

Username	Mark
Password	M4rk3t1ng.21

Not: RDP ile bağlanırken, THM domainindeki Mark kullanıcısıyla giriş yapmak istediğinizi belirtmek için kullanıcı adı olarak THM\Mark kullanın.

Kontrol Panelini açmayı denediğinizde, bu işlemin yöneticinin talimatıyla reddedildiğine dair bir mesaj almanız gerekir. Ayrıca, ekranın otomatik olarak kilitlenip kilitlenmediğini kontrol etmek isterseniz, 5 dakika bekleyebilirsiniz.

Kontrol paneli GPO’sunu IT OU’suna uygulamadığımız için, bu kullanıcıların herhangi biriyle makineye giriş yapıp kontrol paneline erişebilmeniz gerekir.

Not: GPO’ları oluşturup bağladıysanız ancak neden çalışmadığını görüyorsanız, GPO’ların güncellenmesini zorlamak için gpupdate /force komutunu çalıştırmayı unutmayın.

Soru 10: GPO’ları etki alanı makinelerine dağıtmak için kullanılan ağ paylaşımının adı nedir?
Cevap 10: sysvol
Soru 11: Bir GPO, ayarları kullanıcılara ve bilgisayarlara uygulamak için kullanılabilir mi?
(yay/nay) Ans 11: yay

---

Windows domain’lerde, tüm kimlik bilgileri Domain Controller’larda saklanır. Bir kullanıcı domain kimlik bilgilerini kullanarak bir hizmete kimlik doğrulaması yapmaya çalıştığında, hizmet bu kimlik bilgilerini doğrulamak için Domain Controller’a başvurur. Windows domain’lerde ağ kimlik doğrulaması için iki protokol kullanılabilir:

Kerberos: Herhangi bir güncel Windows sürümünde kullanılır. Bu, güncel alanlarda varsayılan protokoldür.

NetNTLM: Uygunluk amaçlı tutulmuş eski kimlik doğrulama protokolüdür.

NetNTLM’nin eski olarak kabul edilmesi gerekirken, çoğu ağda her iki protokol de etkin olabilir. Şimdi, her iki protokolün nasıl çalıştığını daha yakından inceleyelim.

Kerberos Kimlik Doğrulaması

---

Kerberos kimlik doğrulaması, güncel Windows sürümleri için varsayılan kimlik doğrulama protokolüdür. Kerberos kullanarak bir hizmette oturum açan kullanıcılara bilet atanır. Biletleri, önceden yapılmış bir kimlik doğrulamasının kanıtı olarak düşünün. Biletleri olan kullanıcılar, bu biletleri bir hizmete sunarak ağda daha önce kimlik doğrulaması yaptıklarını ve dolayısıyla hizmeti kullanma yetkisine sahip olduklarını gösterirler.

Kerberos kullanılarak kimlik doğrulaması yapıldığında şu işlem gerçekleşir:

1. Kullanıcı, kullanıcı adını ve parolasından türetilmiş bir anahtar kullanarak şifrelenmiş bir zaman damgasını Key Distribution Center (KDC) hizmetine gönderir. KDC, genellikle Domain Controller üzerinde bulunan ve ağdaki Kerberos biletlerini oluşturan hizmettir. KDC, kullanıcının belirli hizmetlere erişmek için ek bilet talep etmesine olanak tanıyan bir Ticket Granting Ticket (TGT) oluşturacak ve geri gönderecektir. TGT’nin bilet almak için bilet gerektirmesi biraz garip gelebilir, ancak bu durum kullanıcıların her hizmete bağlanmak istediklerinde kimlik bilgilerini iletmeden hizmet biletleri talep etmelerini sağlar. TGT ile birlikte bir Oturum Anahtarı (Session Key) da verilir; bu anahtar, kullanıcıların sonraki talepleri oluşturmak için gereklidir.

TGT’nin krbtgt hesabının parola hash’i ile şifrelenmiş olduğunu ve bu nedenle kullanıcının içeriğine erişemediğini unutmayın. Şifrelenmiş TGT’nin içeriğinin bir parçası olarak Oturum Anahtarının bir kopyasını içerdiğini ve KDC’nin gerektiğinde TGT’nin şifresini çözerek bir kopyasını kurtarabileceği için Oturum Anahtarını saklamasına gerek olmadığını bilmek önemlidir.

Bir kullanıcı ağdaki bir paylaşım, web sitesi veya veritabanı gibi bir hizmete bağlanmak istediğinde, KDC’den Ticket Granting Service (TGS) istemek için TGT’sini kullanacaktır. TGS, yalnızca oluşturuldukları belirli hizmete bağlantıya izin veren biletlerdir. Bir TGS talep etmek için kullanıcı, kullanıcı adını ve Oturum Anahtarı kullanılarak şifrelenmiş bir zaman damgasını, TGT ve erişmek istediğimiz hizmeti ve sunucu adını belirten bir Service Principal Name (SPN) ile birlikte gönderir. Sonuç olarak, KDC bize erişmek istediğimiz hizmete kimlik doğrulaması yapmak için ihtiyaç duyacağımız bir Service Session Key ile birlikte bir TGS gönderecektir. TGS, Service Owner Hash‘inden türetilen bir anahtar kullanılarak şifrelenir. Hizmet Sahibi, hizmetin altında çalıştığı kullanıcı veya makine hesabıdır. TGS, şifrelenmiş içeriğinde Service Session Key bir kopyasını içerir, böylece Hizmet Sahibi TGS’nin şifresini çözerek buna erişebilir.

TGS daha sonra kimlik doğrulaması yapmak ve bir bağlantı kurmak için istenen hizmete gönderilebilir. Hizmet, TGS’nin şifresini çözmek ve Service Session Key‘i doğrulamak için yapılandırılmış hesabının parola hash’ini kullanacaktır.

NetNTLM Kimlik Doğrulama

NetNTLM bir meydan challange-response mekanizması kullanarak çalışır.Tüm süreç aşağıdaki gibidir:

İstemci, erişmek istediği sunucuya bir kimlik doğrulama isteği gönderir.

Sunucu, rastgele bir sayı oluşturur ve bunu bir meydan okuma olarak istemciye gönderir.

İstemci, NTLM parolasının hash’ini meydan okuma (ve diğer bilinen veriler) ile birleştirerek bir yanıt oluşturur ve bunu sunucuya geri gönderir.

Sunucu, meydan okumayı ve yanıtı doğrulama için Domain Controller’a iletir.

Domain Controller, meydan okumayı kullanarak yanıtı yeniden hesaplar ve bunu istemciden gelen orijinal yanıt ile karşılaştırır. Eğer her ikisi de eşleşirse, istemci kimlik doğrulanır; aksi takdirde, erişim reddedilir. Kimlik doğrulama sonucu sunucuya gönderilir.

Sunucu, kimlik doğrulama sonucunu istemciye iletir.

Not: Kullanıcının parolası (veya hash’i) ağ üzerinden iletilmez; bu, güvenlik açısından önemlidir.

Not: Açıklanan süreç, bir alan hesabı kullanıldığında geçerlidir. Yerel bir hesap kullanıldığında, sunucu yanıtı doğrulamak için Domain Controller ile etkileşime ihtiyaç duymadan, SAM üzerinde saklanan parola hash’ini kullanarak yanıtı kendisi doğrulayabilir.

Soru 11. Windows’un güncel bir sürümü varsayılan olarak tercih edilen kimlik doğrulama protokolü olarak NetNTLM kullanacak mı? (evet/hayır)
Cevap 11: Nay
Soru 12. Kerberos’a atıfta bulunurken, TGS olarak bilinen daha fazla bilet talep etmemizi sağlayan bilet türü nedir?
Cevap 12: Ticket Granting Ticket

Soru 13: NetNTLM kullanırken, bir kullanıcının parolası herhangi bir noktada ağ üzerinden iletilir mi? (evet/hayır)
Cevap 13: Nay

Şimdiye kadar tek bir domain’in nasıl yönetileceğini,Domain Controller rolünü ve bilgisayarları, sunucuları ve kullanıcıları nasıl birleştirdiğini ele aldık.

Şirketler büyüdükçe, ağları da büyür. Şirket için tek bir domain başlamak için yeterli olabilir, ancak zamanla bazı ek ihtiyaçlar, birden fazla domain olmasını gerektirebilir.

Tree

Örneğin, şirketiniz aniden yeni bir ülkeye genişlediğini hayal edin. Yeni ülkenin farklı yasaları ve düzenlemeleri var ve bu, GPO’larınızı uyumlu hale getirmek için güncellemeniz gerektiği anlamına geliyor. Ayrıca, artık her iki ülkede de IT ekipleri var ve her IT ekibinin kendi ülkesine ait kaynakları yönetmesi gerekiyor. Her iki ekibin de diğerini etkilemeden kaynakları yönetebilmesi için karmaşık bir OU yapısı oluşturabilir ve delegation kullanabilirsiniz; ancak büyük bir AD yapısının yönetilmesi zor olabilir ve insan hatalarına açık olabilir.

Neyse ki, Active Directory, birden fazla domain’i entegre etmenizi destekler, böylece ağınızı bağımsız olarak yönetilebilecek birimlere bölebilirsiniz. Eğer iki domain aynı namespace’i (örneğin thm.local) paylaşıyorsa, bu domain’ler bir Ağaç (Tree) oluşturacak şekilde birleştirilebilir.

Eğer thm.local domain’imiz iki alt domaine (UK ve US şubeleri için) bölünürse, thm.local kök domain’ine sahip bir ağaç oluşturabilirsiniz ve bu iki alt domain, uk.thm.local ve us.thm.local olarak adlandırılabilir; her biri kendi AD’si, bilgisayarları ve kullanıcıları ile birlikte olur.

Bu bölümlenmiş yapı, domain’de neyin kim tarafından erişilebileceği üzerinde daha iyi kontrol sağlar. Birleşik Krallık’taki IT personeli, yalnızca Birleşik Krallık kaynaklarını yöneten kendi DC’lerine sahip olacaktır. Örneğin, Birleşik Krallık’taki bir kullanıcı, ABD kullanıcılarını yönetemez. Bu şekilde, her şubenin Domain Administrator’ları kendi DC’leri üzerinde tam kontrol sahibi olurken, diğer şubelerin DC’leri üzerinde herhangi bir kontrol sahibi olmazlar. Ayrıca, her domain’de bağımsız olarak politikalar da yapılandırılabilir.

Tree ve forest hakkında konuşurken yeni bir güvenlik grubunun tanıtılması gereklidir. Enterprise Admins grubu, bir kullanıcıya tüm bir işletmenin domain’leri üzerinde yönetimsel yetkiler verir. Her domain hala kendi Domain Admins grubuna sahip olacak ve bu gruplar sadece kendi domain’leri üzerinde yönetim yetkisine sahip olacaktır. Ancak Enterprise Admins grubu, tüm işletmedeki her şeyi kontrol edebilir.

Forest

Yönetilen domain’ler farklı namespace’ler içinde de yapılandırılabilir. Farz edelim ki şirketiniz büyümeye devam ediyor ve sonunda MHT Inc. adlı başka bir şirketi satın alıyor. Her iki şirket birleştiklerinde, muhtemelen her biri kendi IT departmanları tarafından yönetilen farklı domain ağaçlarına sahip olacaksınız. Farklı namespace’lere sahip birkaç ağacın aynı ağaç içinde birleşmesi forest olarak bilinir.

Güven İlişkileri

Tree ve forestlar içinde düzenlenmiş birden fazla domain’e sahip olmak, yönetim ve kaynaklar açısından güzel bir bölümlenmiş ağ sağlar. Ancak belirli bir noktada, THM UK’deki bir kullanıcının MHT ASIA sunucularından birinde paylaşılan bir dosyaya erişmesi gerekebilir. Bunun gerçekleşmesi için, tree ve forest içinde domain’ler arasında güven ilişkileri kurulur.

Basitçe ifade etmek gerekirse, domain’ler arasında bir güven ilişkisi kurmak, THM UK domain’indeki bir kullanıcının MHT EU domain’indeki kaynaklara erişimini sağlar.

Kurulabilecek en basit güven ilişkisi tek yönlü bir güven ilişkisidir. Tek yönlü bir güven ilişkisi durumunda, Domain AAA eğer Domain BBB’yi güvenilir olarak kabul ederse,

Tek yönlü güven ilişkisinin yönü erişim yönünün tersidir. Her iki etki alanının da diğerindeki kullanıcıları karşılıklı olarak yetkilendirmesine izin vermek için iki yönlü güven ilişkileri de oluşturulabilir. Varsayılan olarak, birkaç etki alanının bir ağaç veya orman altında birleştirilmesi iki yönlü bir güven ilişkisi oluşturacaktır. Etki alanları arasında bir güven ilişkisine sahip olmanın, diğer etki alanlarındaki tüm kaynaklara otomatik olarak erişim izni vermediğini unutmamak önemlidir. Bir güven ilişkisi kurulduktan sonra, farklı etki alanlarındaki kullanıcıları yetkilendirme şansına sahip olursunuz, ancak gerçekte neyin yetkilendirilip yetkilendirilmeyeceği size bağlıdır.