Can's Windows Server Blog

Site = Lokasyon

AD oluşturulduğunda siteda oluşturur. İlk adı “default” dur.

Ama domainimiz birden çok site a bölünmüşse replikasyonda gerekecektir.

Site içinde network bağlantısı var demektir. Site içinde service lokalizasyonuda mevcuttur. Yani bir client boot yapınca DC onun ihtiyaç duyabileceği kaynakları öncelikle bulunduğu sitedan tahsis etmeye çalışacaktır.

Bir site a GPO’da link edilebilir ancak önerilmez çünkü o GPO’yu bulmak için o site’ın kurulduğu domaine gitmek gerekecektir ve bu domain remote bir yerde olabilir.

Site oluşturma “AD Sites and Services” ile yapılıyor.

Sites a sağ tıklayıp –> new Site ve bu yeni pencere geliyor.

Daha sonra bir isim verip DEFAULTIPSITELINK’i mutlaka seçiyorum.

Ok dedikten sonra site oluştu. Şimdi o site a bir subnet eklememiz gerekiyor. Oluştuacağımız yeni subnetler yeni lokasyonda ki gerçek fiziksel subnetleri temsil edecek ve onları gösteriyor olmak zorunda.

Subnet oluşturmak için “AD Sites and Services” de Sites–>Subnets e sağ tıklayıp ‘New Subnet’ diyoruz.

Eğer daha çok subnetimiz varsa onlarıda eklemeliyiz. Böylece replikasyonda kim ne kadar hızlı sistem tespit edebilecek.

Sitelar arası replikasyonlar normalde 5 dakikada bir yapılır ancak bağlantı hızlarına göre daha yavaş ve/veya hızlı olabilir. Bu schedule’ı biz tanımlayabiliriz. Acil yapılmasını sağlayabiliriz.

Link costlarına göre istersek replikasyonun hangi link ile yapılacağına da biz karar verebiliriz.

• SID Filter
• Slective Authentication
• Name Suffix Routing

Maalesef bunu göstermek için bir trust oluşturmam gerekli ancak bende şu anda bu mümkün değil.

Ama AD Domains and Trusts –> Domain’e sağ tık –> properties –> trusts–> kurulu trustu bulup onu seçiyoruz. Properties tıklayınca yeni pencere geliyor ve orada Authentication kısmı mevcut. 2 seçenek var.

Domain Wide Authentication : Default olan budur ve domain e login olan herkese izin verir.
Selective Authentication : Bunu yapmak için öncelikle AD Users and Computers in advanced View’i açık olmak zorundadır. Sonra

Burada en önemli şey Locations ı seçip orada Trustı seçmektir.

SID Filtering : SID Filtering default olarak tüm dışarı yöndeki trustlara enable edilmiştir.

Bunu kullanarak kötü kullanıcıların domain/enterprise admin seviyesinde yükseltilmiş haklarla trust üzerinden iş yapması engellenir.

Kullanıcılar oluşturulurken domain SID’side dahildir ve bu SID ile kullanıcının domain içinde hangi kaynaklara erişebileceği belirlenir. SID filtering ile trusted domaine ait olmayan tüm SID’lerin kullanılması engellenir.

Name Suffix Routing : Bunun için önce bir trust oluşturmak sonra bu oluşturulan trustın “AD Domains and Trusts”‘dan özelliklerine bakmak gerekiyor.

Screenshotta görüldüğü gibi kısıtlanabilir.

Trust –>Türkçesi güven. Domainlerin birbirine güvenmesi anlamında.

Eğer bir domain altında child domain oluşturuyorsak AD iki domain arasında Parent-Child trustını otomatik olarak oluşturur.

Transitive Trust : Örneğin domain A domain B ye güveniyor ve domain B de domani C’ye güveniyor. O zaman transitive var ise domain A domain C’ye de güvenir oluyor. tabii domain C’de domain A’ya.

Forest Root Trust : forestlar arası trustdır. Karşılıklı kaz-ynakların kullanımına izin verir.

External Trust: biz harici bir domain e de trust edebiliriz.

Shortcut trust : bir forest içinde trust path ini kısaltmak için kullanılır.

Ok ların yönü önemli. Standard olarak şöyle ; ok A domaininden çıkıp B domainini gösteriyorsa. B domaininde ki kişi A domaininde ki kaynakları kullanabilir. Yani A B’ye güvenir.

Trust oluşturmak için AD Domains and Trusts’ı açarız.

Domain’e sağ tıkla –> properties –>Trusts –> New Trust

wızardı takip edip kurulur. Wizardı dikkatle okumak gerekir.

Trust oluşturma iyi bir planlama ile olmalıdır.

Bunu yapmak için ADMT (Ad Migration tool) adında microsoft un sayfasında indirilebilecek bir tool mevcuttur.

A forestindan B forestına migrate ederken :
* Kullanıcı hesapları
* Managed Service Accounts
* Computer Accounts
* Gruplar
migrate edilir.

Ayrıca SID-History de istersek kullanıcılar ile bir forestdan diğerine gönderilir.
SID history özellikle B forestina göçerken A da kullandıkları şeyleri kullanmaya devam etmelerini sağlar bu nedenle önemlidir.

Migration dan önce yapılması gereken işlemler

• Vista SP1 den veya Windows Server 2008 R2 den önceki sistemlerde Registry yi ayarlayıp cryptography’i Windows NT 4.0 ile uyumlu hale getirmek gerekmektedir.
• Firewall dosya ve printer paylaşımına açılmalıdır.
• Kaynak ve hedef AD DS ayarlanacak böylece users, groups ve kullanıcı profilleri çalışabilecek.
• Rollback planı olmalı.
• Trust bağlantısı kurulmalı.
• Kaynak ve hedef AD DS’ler SID-History migration için enable edilmeli.
• Göç edeccek servis hesapları belirlenmeli
• Mutlaka test migration yapılmalı ve tespit edilen sorunlar çözülmeli.

Migration uzun bir süreçtir. Microsoftun web sayfasında bu konu ile ilgili 250 sayfalık doküman mevcuttur.

Güzel bir video bu konuda : https://www.youtube.com/watch?v=wXsLjzpb9ZA

Adım 1 : Yeni yapılanma planı oluşturun

• Account migration planı oluşturun
• Mevcut objectlerin yeni yerlerlerini planlayın (mapping)
• Test planı geliştirin.
• Rollback planı oluşturun.
• İletişim planı oluşturun. personeli bilgilendirin işlemler yapılırken.

Adım 2:

• 128-bit encryption kullanılacak.
• en az tek yönlü trust gerekiyor.
• Göç edecek hesapların kaynak ve hedef tarafında permissionları olmalı.
• ADMT SID-Historyi otomatik yapacak.
• Hedefte ki OU yapısını kontrol edin
• ADMT yi hedef domainde kurun.
• Password migration’ı enable edin.
• Test migration’ı yapın (küçük bir test olarak da icra edilebilir)

Adım 3 : Hesapları Migrate edin

• Service hesaplarını aktarın
• Global grupları aktarın
• Hesapları aktarın

Adım 4: Kaynakları (resources) migrate edin

• Workstatin ve üye serverları aktarın.
• Domain local grupları aktarın
• DC’leri aktarın

Adım 5: Migration i tamamlayın

• Yönetim processlerini hedef domaine aktarın.
• En az 2 faal DC olduğundan emin olun.
• Kaynak domain’i decomission yapın.

SID-History aktarımı çok önemli. Eski SIDlerin aktarıldığı yeni domainde kullanıcıların 2 SIDsi olacak ama böylece kullanıcılar eski resourceları kullanmaya devam edebilecekler. Herşey bittikten sonra eski domain kapandıktan sonra eski SID’ler artık silinebilir.

Domainler ve subdomainler bölge ve/veya departman ve/veya çeşitli sebeplerle bölünebilirler.

Örneğin sirket.com domain’i satıs.sirket.com , uretim.sirket.com, sonrada lokasyonlar ile ankara.uretim.sirket.com, hatay.uretim.sirket.com gibi bölünebilirler.

bu durumda child domain oluşturmuş oluruz. Contigous namespace

Ama bazen domain isimlerinde devamlılık olmaz. O zaman tree domain olur.

sirket.com ve musteri.com gibi tamamen bağımsız bir domain adı da kullanabiliriz. Buna da discontigous domain namespace denir.

Powershell de ise

Install-addsdomain -domaintype TreeDomain -parentdomainname sirket.com -newdomainname msuteri.com -credential domain\administrator

Forest functionla levelları Windows 2000’den başlar. Forest Functional Level 2006 olsun dediğimiz anda bilmemiz gereken o forest içinde artık tüm DC’ler minimum 2016 olmak zorundadır.

Aynı şey domain functional level içinde geçerlidir.

Eğer functional leveli yükseltirsek ve hala eski versiyon DC’ler mevcutsa bu durum onları disable yapacaktır.

AD Users and Computers da Domain e sağ tıklayıp aşağıda ki gibi level i yükseltebiliriz.

Forest functional level için ise AD Domains and Trusts a gitmemiz gerekiyor.

Sis DC oluştururken bazı konuları değerlendirmemiz gerekir. Örneğin forest mı olacak tek domain mi? Replication Lan mı Wan mı? Wan ne kadar hızlı yeterli mi?

Kimler yönetecek? Tek merkezden mi, çok merkezden mi?

GPO uygulaması. GPO Domain seviyesinde uygulanıyor. Güvenlik için herkesin uyması gereken GPO’larım olabilir?

Auditing domain seviyesinde trouble shooting ve resource planning de daha kolay olur mu?

Çok forest olunca güvenlik sıkıntı olur mu? Trusts ?

Schema replication tüm forestlar da geçerli olacak mı?

Global catalog replication?

bir domain içinde replikasyon muhtemelen her 5 dakikada bir olacaktır. bu nedenle uzak yerler seçerken bağlantım yeterince hızlımı onu değerlendirmeliyim.

birden çok domain namespace kullanıyor olabirim. (bizim şirket gibi)

Lokasyonlar çok parçalı ise yönetimi kim yapacak?

Empty domain root : bu yapılırsa hiç bir domain diğerine üstün olmaz. O zaman enterprise admin olmayacağı için tek bir yönetici tüm domainleri etkileyemez.

En önemli konulardan biri … en basiti en iyisidir.

Çoklu forestlarda

güvenlik izolasyonu sağlanabilir.

Bir lokasyondan veri çıkmasını engellemek mümkün olabilir.

Farklı schema lar kullanılabilir.

Firma birleşmeleri olmuş olabilir.

Herhangi bir restore için önce backup almak gerekir. Backup almanın bir yoluda Windows Server ile gelen Windows Backupdır. Bunu feature olarak yükleyip backup alıyoruz.

Maalesef detayları eğitimde hiç yoktu. Ancak NTDSUTIL ile yapılıyordu. Sadece bir screenshot mevcuttu.

ntdsutil: activate instance ntds
ntdsutil: authoritative restore
authoritative restore: restore object “cn=Can B, OU=Audit, OU=Satis,DC=can DC=com”
Opening DIT Database….Done
The Current Time is 08.10.2019 05:23
Most recent database update occured at 07.10.2019 11:34.03
Increasing attribute version numbers by 100000.

Counting records that need updating….
Records found: 0000000001
Done.

Found 1 records to update.

Updating records…..
Records remaining: 0000000000000
Done.
Authoritative Restore completed successfully

Koyu renkliler sistem tarafından yazılanlar.

Özellikle önemli olan version numarasının yükseltilmesi. Yani DC’miz networkte ki diğer DC’lere diyorki bunu silmedim update ettim artık bu bilgiyi kullanın.

DC’de silinen verileri kurtarmanın bir yolu Authoritative Restore ancak bunu yapmak icin DC yi offline yapmak gerekiyor.

Diğer bir yöntem ise AD Recycle Bin. Bu yöntemi kullanmak için önce Recycle Bin özelliğinin aktif edilmesi gerekmektedir. Aktif edildikten sonra de-aktif edilemez.

Herhangi bir obje silindiğinde AD den silinir ancak recycle bin e gider.

Aktif etmek için AD Administrative Center’da

Denemek için bir obje oluşturup sildim.

AD Administrative center’da dedomain altında “deleted objects” diye bir bölüm belirmişti oraya bakıyorum.

Evet bir VM’de ki 6 aylık periyot sona eriyor bu nedenle yeni DC ye ihtiyacım var. İlk DC’yi kapatacağım için FSMO’ları diğerine aktarmam lazım ki domain çalışmaya devam etsin.

DC2 yi daha önce yaratıp DNS ile kurdum ve domain e ekledim. Dolayısıyla zaten replikasyon tamamlanmıştı. Tüm masterları tek bir komutla direk (ve hatta şap diye) aktardım

PS C:> Move-ADDirectoryServerOperationMasterRole -Identity C1-DC2 -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster, SchemaMaster, DomainNamingMaster

Sonra da kontrol ettim çünkü çok hızlı oldu 🙂 gerçi içinde neredeyse 3-5 obje olan dandikr bir domain bu ya neyse 🙂

Sonra gelen ekranda 3 tane Rolü görüyoruz. Powershell ile değilde GUI üzerinden bu 3 rolü buradan da aktarabilirdik.

Diğer ikisini tekrar zaman olunca incelemek lazım.

Şimdi C1-DC1 i domainden adam gibi çıkartma kısmı kaldı.

Önce replikasyon doğru olmuşmu kontrol ediyoruz.

sonra sırada bekleyen bitmemiş replikasyon var mı ona bakıyoruz.

bir daha bakıyoruz son replikasyon ne zaman yapılmış

mesela uzun zamandır olmamışsa bir daha başlatıyoruz

artık ilk DC’yi silebiliriz.

ama olmuyor.

DCpromo yapmamız gerekiyor.

Hemen ilk server a tekrar bağlanıyoruz. Server manager dan remove role yapıyoruz.

Demote this domain controller.

Yine olmadı çünkü FSMO dışında Global Katalog ve DNS hala DC1 de kalmış şimdi onları aktaracağız.

DC2’de Server manager AD Sites and Servicesi açtım.

GC olmasını istediğim serveri Default-First-Site-Name’de buldum ve NTDS Özelliklerini açıyorum. DC2’de Global Catalog un seçili olduğunu DC1’de ise seçili olmadığı durumu sağlıyorum. Hangisinde değişiklik yaptıysam o Serverı restart etmem gerekiyor.