Active Directory Domain Services, Microsoft tabanlı kurumsal yapılarda kullanıcıların, bilgisayarların, grupların, güvenlik politikalarının, Organizational Unit’lerin, parolaların ve domain yapılandırmalarının merkezi olarak yönetilmesini sağlayan en önemli altyapı servislerinden biridir.

Bir Active Directory ortamında genellikle yalnızca tek bir Domain Controller bulunmaz. Kurumsal yapılarda yüksek erişilebilirlik sağlamak, kimlik doğrulama işlemlerinin devamlılığını korumak ve Active Directory verilerinin yedekli şekilde tutulmasını sağlamak amacıyla birden fazla Domain Controller kullanılır.

Her yazılabilir Domain Controller, Active Directory veritabanının bir kopyasını üzerinde bulundurur. Bir Domain Controller üzerinde yapılan değişiklikler replikasyon mekanizması aracılığıyla diğer Domain Controller’lara aktarılır.

Örneğin:

DC01 üzerinde yeni kullanıcı oluşturuldu
                │
                ▼
       Active Directory
          Replication
                │
        ┌───────┴───────┐
        ▼               ▼
      DC02             DC03

DC01 üzerinde oluşturulan kullanıcı bilgisi belirli bir süre içerisinde DC02 ve DC03 üzerine replike edilir.

Bu mimariye Multi-Master Replication adı verilir.

Multi-Master mimarinin en önemli avantajlarından biri, Active Directory üzerindeki günlük işlemlerin yalnızca tek bir Domain Controller’a bağımlı olmamasıdır.

Örneğin bir kullanıcı:

• DC01 üzerinde oluşturulabilir,
• DC02 üzerinde parolası değiştirilebilir,
• DC03 üzerinden kimlik doğrulaması gerçekleştirebilir.

Bu yapı Active Directory’nin erişilebilirliğini ve dayanıklılığını önemli ölçüde artırır.

Ancak burada önemli bir soru ortaya çıkar:

Eğer bütün Domain Controller’lar aynı işlemleri gerçekleştirebiliyorsa FSMO rollerine neden ihtiyaç vardır?

Bu sorunun cevabı Active Directory’nin çalışma mantığını anlamak açısından oldukça önemlidir.

FSMO Rollerine Neden İhtiyaç Duyulur?

Multi-Master Replication mimarisi günlük Active Directory işlemlerinin büyük kısmı için oldukça başarılıdır.

Ancak bazı kritik işlemlerin birden fazla Domain Controller tarafından aynı anda gerçekleştirilmesi ciddi tutarsızlıklara neden olabilir.

Örneğin iki farklı yöneticinin iki farklı Domain Controller üzerinden Active Directory’nin yapısını aynı anda değiştirdiğini düşünelim.

Ya da iki farklı Domain Controller’ın aynı anda benzersiz bir kimlik üretmeye çalıştığını varsayalım.

Böyle bir durumda çakışmalar meydana gelebilir.

Eklediğiniz dokümanda bu durum, iki yöneticinin aynı çalışan numarasını iki farklı kişiye vermeye çalışmasına benzetilmektedir. Bazı işlemlerde Active Directory’nin tek bir otoriteye ihtiyaç duymasının temel nedeni budur.

Microsoft bu problemi çözmek amacıyla bazı özel Active Directory görevlerini belirli Domain Controller’lara vermiştir.

Bu görevler: FSMO – Flexible Single Master Operations olarak adlandırılır. FSMO rolleri aynı zamanda: Operations Master Roles olarak da bilinir.

Buradaki Single Master ifadesi, belirli bir işlemin belirli bir zamanda yalnızca bir Domain Controller tarafından yönetildiğini ifade eder.

Ancak Flexible kelimesi de oldukça önemlidir.

Çünkü FSMO rolleri belirli bir Domain Controller’a kalıcı olarak bağlı değildir. Gerektiğinde başka bir Domain Controller’a taşınabilirler. Örneğin mevcut FSMO sahibi sunucu bakım nedeniyle kapatılacaksa rol başka bir Domain Controller’a transfer edilebilir.

Active Directory’de Kaç FSMO Rolü Bulunur?

Active Directory içerisinde toplam beş farklı FSMO rolü bulunmaktadır.

Bu roller iki gruba ayrılır:

Forest Bazlı FSMO Rolleri

Forest genelinde yalnızca birer tane bulunur:

1. Schema Master
2. Domain Naming Master

Domain Bazlı FSMO Rolleri

Her domain için ayrı ayrı bulunur:

1. PDC Emulator
2. RID Master
3. Infrastructure Master

Dokümanda da FSMO rollerinin iki forest-level ve üç domain-level olmak üzere toplam beş role ayrıldığı belirtilmektedir.

Yapıyı basit bir şekilde şu şekilde gösterebiliriz:

ACTIVE DIRECTORY FSMO ROLES
│
├── FOREST LEVEL
│   │
│   ├── Schema Master
│   └── Domain Naming Master
│
└── DOMAIN LEVEL
    │
    ├── PDC Emulator
    ├── RID Master
    └── Infrastructure Master

Buradaki önemli fark şudur:

Forest içerisinde kaç domain bulunursa bulunsun yalnızca:

• 1 Schema Master
• 1 Domain Naming Master

bulunur.

Ancak her domain kendi:

• PDC Emulator
• RID Master
• Infrastructure Master

rollerine sahiptir.

Yeni Kurulan Active Directory Ortamında FSMO Rolleri Nerede Bulunur?

Yeni bir Active Directory forest’ı oluşturulduğunda kurulan ilk Domain Controller başlangıçta beş FSMO rolünün tamamını üzerinde bulundurur.

Dokümanda da yeni bir forest içerisindeki ilk Domain Controller’ın otomatik olarak beş FSMO rolünün tamamını aldığı belirtilmektedir.

Örneğin ilk Domain Controller’ın adı:

DC01.contoso.local

olsun.

İlk kurulum sonrasında:

DC01
│
├── Schema Master
├── Domain Naming Master
├── PDC Emulator
├── RID Master
└── Infrastructure Master

şeklinde olacaktır.

Ancak bu durum rollerin her zaman DC01 üzerinde kalacağı anlamına gelmez.

İkinci bir Domain Controller kurulduktan sonra roller ihtiyaç doğrultusunda farklı Domain Controller’lara taşınabilir.

Örneğin:

DC01
│
├── Schema Master
├── Domain Naming Master
└── PDC Emulator


DC02
│
├── RID Master
└── Infrastructure Master

şeklinde bir yapı oluşturulabilir.

Küçük yapılarda ise beş FSMO rolünün tamamının güvenilir ve sağlıklı tek bir Domain Controller üzerinde tutulması mümkündür. Dokümanda küçük yapılarda tüm rollerin aynı, iyi yönetilen Domain Controller üzerinde bırakılmasının yaygın olduğu belirtilmektedir.

A. Forest Bazlı FSMO Rolleri

Forest seviyesinde çalışan iki FSMO rolü vardır:

• Schema Master
• Domain Naming Master

Bu roller tüm Active Directory forest yapısını ilgilendirdiği için forest içerisinde yalnızca birer tane bulunur.

1. Schema Master

Schema Master, Active Directory içerisindeki en temel yapılardan biri olan Active Directory Schema üzerinde gerçekleştirilecek değişiklikleri kontrol eden FSMO rolüdür.

Schema’yı Active Directory’nin veri modeli veya şablonu olarak düşünebiliriz.

Schema iki temel kavramı tanımlar:

• Object Classes
• Attributes

Başka bir ifadeyle Active Directory içerisinde:

“Hangi tür nesneler bulunabilir ve bu nesnelerin hangi özellikleri olabilir?”

sorusunun cevabı Schema içerisinde tutulur.

Object Class Nedir?

Active Directory içerisinde bulunan:

• User
• Computer
• Group
• Contact
• Organizational Unit

gibi nesne türleri birer object class olarak düşünülebilir.

Örneğin:

User
Computer
Group
Contact
Printer

gibi Active Directory nesnelerinin yapıları Schema tarafından tanımlanır.

Attribute Nedir?

Attribute ise bir Active Directory nesnesinin özelliklerini ifade eder.

Örneğin bir kullanıcı hesabının:

Name
Surname
Display Name
E-Mail
Telephone Number
Department
Employee ID
Manager

gibi bilgileri attribute olarak tutulabilir.

Dolayısıyla Active Directory Schema genel olarak:

Object
   │
   ├── Object Class
   │
   └── Attributes

mantığıyla düşünülebilir.

Schema Master’ın Görevi Nedir?

Schema Master’ın temel görevi Active Directory Schema üzerinde yapılacak değişikliklerin kontrolünü sağlamaktır.

Örneğin yeni bir yazılım Active Directory içerisine kendisine özel attribute veya object class eklemek istiyorsa Schema üzerinde değişiklik yapılması gerekebilir.

Dokümana göre Active Directory şemasının genişletilmesi gerektiğinde Schema Master’a erişilebilir olması gerekir ve bütün forest içerisinde yalnızca bir Schema Master bulunmaktadır.

Schema değişiklikleri günlük Active Directory operasyonları içerisinde sık gerçekleştirilen işlemler değildir.

Bu nedenle Schema Master rolü sürekli yoğun trafik alan bir FSMO rolü değildir.

Ancak Schema değişikliği yapılacağı zaman son derece kritik hale gelir.

Schema Master ile İlgili Önemli Noktalar

Schema Master:

• Forest bazında çalışır.
• Forest içerisinde yalnızca bir tane bulunur.
• Active Directory Schema değişikliklerini kontrol eder.
• Yeni bir forest kurulduğunda başlangıçta ilk Domain Controller üzerinde bulunur.
• Gerekli durumlarda başka uygun bir Domain Controller’a taşınabilir.

Ek teknik açıklama: Schema üzerinde değişiklik yapılması oldukça hassas bir işlemdir. Bu nedenle production ortamında Schema değişikliklerinden önce yedekleme, değişiklik planı ve gerekli testlerin yapılması iyi bir Active Directory yönetim yaklaşımıdır.

2. Domain Naming Master

İkinci forest bazlı FSMO rolü Domain Naming Master rolüdür.

Domain Naming Master’ın temel görevi Active Directory forest yapısına domain ekleme ve forest’tan domain çıkarma işlemlerinin kontrolünü sağlamaktır.

Dokümana göre bu rol forest içerisinde domain eklenmesi ve kaldırılması sırasında kullanılır ve domain isimlerinin forest içerisinde benzersiz kalmasına yardımcı olur.

Örneğin mevcut Active Directory yapımız şöyle olsun:

company.local

Şirket büyüdükten sonra farklı lokasyonlar için child domain oluşturulmak istendiğini düşünelim:

company.local
│
├── ankara.company.local
│
└── istanbul.company.local

Yeni domain’in forest yapısına dahil edilmesi sırasında Domain Naming Master rolüne ihtiyaç duyulur.

Domain Naming Master’ın Temel Görevleri

Bu rol genel olarak:

• Forest’a yeni domain eklenmesini,
• Mevcut domain’in forest’tan kaldırılmasını,
• Forest domain namespace’inin tutarlı tutulmasını

kontrol eder.

Forest yapısı günlük olarak sürekli değiştirilmediği için Domain Naming Master da Schema Master gibi günlük operasyonlarda yoğun kullanılan bir FSMO rolü değildir.

Ancak forest yapısında değişiklik yapılacağı zaman rolün erişilebilir olması gerekir.

Forest Seviyesindeki Roller İçin Genel Görünüm

FOREST
│
├── Schema Master
│       │
│       └── AD Schema değişiklikleri
│
└── Domain Naming Master
        │
        └── Domain ekleme / kaldırma

Her iki rol de tüm forest’ı ilgilendirdiği için forest içerisinde yalnızca birer tane bulunmaktadır.

B. Domain Bazlı FSMO Rolleri

Domain seviyesinde üç FSMO rolü bulunmaktadır:

1. PDC Emulator
2. RID Master
3. Infrastructure Master

Forest bazlı rollerden farklı olarak bu roller her domain için ayrı ayrı bulunur.

Örneğin:

company.local

ankara.company.local

istanbul.company.local

şeklinde üç domain varsa her domain’in kendi:

PDC Emulator
RID Master
Infrastructure Master

rolleri olacaktır.

Dolayısıyla üç domain bulunan bir forest içerisinde:

Forest Rolleri
2

+

Domain Rolleri
3 × 3 = 9

=

Toplam 11 FSMO Rolü

bulunur.

3. RID Master

RID Master’ın görevini anlayabilmek için öncelikle SID kavramını anlamak gerekir.

Active Directory içerisindeki güvenlik nesnelerinin benzersiz şekilde tanımlanması gerekir.

Örneğin:

• User
• Computer
• Security Group

gibi nesnelere birer Security Identifier – SID atanır.

Bir SID genel anlamda:

Domain SID + RID

mantığıyla oluşur.

RID ise:

Relative Identifier

ifadesinin kısaltmasıdır.

RID Master Nasıl Çalışır?

Domain içerisinde birden fazla Domain Controller bulunabilir.

Örneğin:

DC01
DC02
DC03

Her Domain Controller üzerinde yeni kullanıcı oluşturulabilir.

Ancak oluşturulan her güvenlik nesnesinin SID’sinin benzersiz olması gerekir.

Bu noktada RID Master devreye girer.

RID Master doğrudan her yeni kullanıcı için tek tek RID üretmez.

Bunun yerine Domain Controller’lara RID Pool, yani RID havuzları dağıtır.

Örneğin:

                 RID MASTER
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
        DC01       DC02       DC03
        RID        RID        RID
        Pool       Pool       Pool

DC01 üzerinde yeni kullanıcı oluşturulduğunda DC01 kendi RID havuzundan bir RID kullanır.

RID havuzu azalmaya başladığında Domain Controller, RID Master’dan yeni bir RID bloğu ister.

Dokümana göre Domain Controller’ın RID havuzu tükendiğinde ve RID Master uzun süre erişilemiyorsa yeni güvenlik nesnelerinin oluşturulamaması gibi problemler meydana gelebilir.

RID Master Arızalanırsa Ne Olur?

RID Master’ın kısa süreli olarak erişilemez olması Active Directory’nin tamamen duracağı anlamına gelmez.

Domain Controller’lar ellerindeki mevcut RID havuzlarını kullanmaya devam edebilir.

Ancak mevcut RID havuzları zamanla tükenirse:

• yeni kullanıcı,
• yeni bilgisayar,
• yeni güvenlik grubu

gibi SID gerektiren yeni nesnelerin oluşturulması sorun haline gelebilir.

Bu nedenle RID Master özellikle çok yoğun Active Directory nesnesi oluşturulan ortamlarda önemlidir.

4. PDC Emulator

PDC Emulator, beş FSMO rolü içerisinde günlük Active Directory operasyonlarında en fazla görev üstlenen rollerden biridir.

Eklediğiniz dokümanda da PDC Emulator’ın operasyonel açıdan FSMO rollerinin en önemlilerinden biri olduğu belirtilmektedir.

PDC Emulator’ın görevleri arasında:

• Saat senkronizasyonu,
• Parola değişiklikleri,
• Account lockout işlemleri,
• Group Policy güncellemeleri,
• Eski Windows sistemleriyle uyumluluk

bulunmaktadır.

Bu görevleri ayrı ayrı incelemek PDC Emulator rolünü anlamayı oldukça kolaylaştırır.

PDC Emulator ve Saat Senkronizasyonu

Active Directory ortamında doğru saat kullanımı son derece önemlidir.

Özellikle Kerberos tabanlı kimlik doğrulama işlemlerinin sağlıklı çalışabilmesi için domain ortamındaki sistemlerin saatlerinin birbiriyle uyumlu olması gerekir.

Active Directory içerisinde hiyerarşik bir zaman senkronizasyon yapısı bulunur.

Dokümana göre forest root domain içerisindeki PDC Emulator bütün forest için zaman hiyerarşisinin merkezinde önemli rol oynar.

Yapıyı basitleştirilmiş şekilde şöyle düşünebiliriz:

Güvenilir External NTP
          │
          ▼
Forest Root Domain
PDC Emulator
          │
          ▼
Diğer Domain Controller'lar
          │
          ▼
Member Server / Client

Ek teknik açıklama: Production ortamlarında forest root PDC Emulator’ın güvenilir bir dış NTP kaynağıyla doğru şekilde yapılandırılması Active Directory sağlık kontrollerinin önemli parçalarından biridir.

PDC Emulator ve Parola Değişiklikleri

PDC Emulator’ın en önemli görevlerinden biri parola değişikliklerinde devreye girmesidir.

Örneğin ortamda:

DC01
DC02
DC03

bulunduğunu düşünelim.

Kullanıcı parolasını DC02 üzerinde değiştirmiş olsun.

Yeni parola bilgisi replikasyon sayesinde diğer Domain Controller’lara aktarılacaktır.

Ancak replikasyon anlık olmak zorunda değildir.

Kullanıcı hemen ardından DC03 üzerinden oturum açmaya çalışırsa DC03 henüz yeni parola bilgisini almamış olabilir.

Bu durumda PDC Emulator özellikle son parola değişikliklerinin doğrulanmasında önemli rol oynar.

Dokümana göre kullanıcı parolasını değiştirdiğinde PDC Emulator güncellemenin hızlı şekilde bilinmesinde rol oynar; bir Domain Controller hatalı parola nedeniyle oturum açmayı reddetmeden önce yakın zamanda parola değişikliği ihtimaline karşı PDC Emulator ile kontrol gerçekleştirebilir.

PDC Emulator ve Account Lockout

PDC Emulator, hesap kilitleme işlemleri açısından da önemli bir role sahiptir.

Örneğin bir kullanıcı birçok kez yanlış parola girerse domain’in Account Lockout Policy ayarlarına bağlı olarak hesabı kilitlenebilir.

PDC Emulator bu işlemlerin doğru şekilde takip edilmesinde önemli rol oynar.

Bu nedenle:

• Sürekli hesabı kilitlenen kullanıcılar,
• Parola doğrulama problemleri,
• Replikasyon gecikmesine bağlı authentication sorunları

incelenirken PDC Emulator’ın sağlığı da kontrol edilmelidir.

PDC Emulator ve Group Policy

PDC Emulator’ın bir diğer önemli görevi Group Policy yönetimiyle ilgilidir.

Group Policy düzenlemelerinde PDC Emulator varsayılan olarak tercih edilen Domain Controller’dır. Dokümanda da Group Policy güncellemelerinin varsayılan olarak PDC Emulator üzerinde yazıldığı belirtilmektedir.

Burada sık yapılan bir yanlış anlaşılmayı ayırmak gerekir.

PDC Emulator:

GPO’ların OU’lara hangi sırayla uygulanacağını belirleyen FSMO rolü değildir.

GPO işleme davranışı:

• Local Policy,
• Site,
• Domain,
• OU,
• Inheritance,
• Enforced,
• Security Filtering

gibi Group Policy mekanizmaları tarafından belirlenir.

PDC Emulator’ın buradaki önemi Group Policy yönetim işlemlerinin tutarlı şekilde gerçekleştirilmesine yardımcı olmasıdır.

PDC Emulator ve Eski Windows Sistemleri

PDC Emulator ismindeki “PDC” ifadesi:

Primary Domain Controller

kavramından gelir.

Bu isim Windows NT dönemindeki domain mimarisiyle geriye dönük uyumluluk amacıyla korunmuştur.

Modern Active Directory ortamlarında eski Windows istemcileri yaygın kullanılmasa da rol hala PDC Emulator adıyla devam etmektedir.

PDC Emulator Neden Kritik Bir FSMO Rolüdür?

Çünkü diğer rollerin bir kısmı yalnızca belirli idari işlemler sırasında devreye girerken PDC Emulator günlük operasyonların içerisinde sürekli görev alabilir.

Özellikle:

Authentication
        │
Password
        │
Account Lockout
        │
Time Synchronization
        │
Group Policy Management

gibi servislerle ilişkili olması PDC Emulator’ı operasyonel açıdan önemli hale getirir.

Dokümanda da PDC Emulator’ın güçlü ve güvenilir bir Domain Controller üzerinde tutulmasının önemli olduğu vurgulanmaktadır.

5. Infrastructure Master

Infrastructure Master özellikle birden fazla domain bulunan forest yapılarında önemlidir.

Bu rolün temel görevi farklı domain’lerde bulunan Active Directory nesneleri arasındaki referansların güncel tutulmasına yardımcı olmaktır.

Örneğin forest yapımız şöyle olsun:

company.local
│
├── ankara.company.local
│
└── istanbul.company.local

Ankara domain’inde:

Ahmet Yılmaz

isimli bir kullanıcı bulunsun.

İstanbul domain’inde ise:

IT-Admins

isimli bir grup olsun.

Ahmet kullanıcısı IT-Admins grubuna üye olabilir.

Bu durumda İstanbul domain’indeki grup Ankara domain’indeki bir nesneye referans vermektedir.

Daha sonra Ahmet’in adı veya ilgili nesne bilgileri değiştirildiğinde bu referansın güncel tutulması gerekir.

Infrastructure Master’ın görevlerinden biri bu tip cross-domain object reference bilgilerinin güncel tutulmasına yardımcı olmaktır.

Dokümanda da başka bir domain’deki kullanıcının bir gruba üye olması ve kullanıcının adının değiştirilmesi örneğiyle Infrastructure Master’ın bu referansı güncellediği açıklanmaktadır.

Infrastructure Master ve Global Catalog İlişkisi

Infrastructure Master konusunda uzun yıllardır bilinen önemli bir tasarım önerisi vardır:

Infrastructure Master rolünün Global Catalog bulunan Domain Controller üzerinde tutulmaması önerilir.

Ancak bu ifade tek başına kullanıldığında eksik kalabilir.

Dokümana göre domain içerisindeki bütün Domain Controller’lar Global Catalog ise Infrastructure Master rolünün yapacağı cross-domain referans güncelleme işi oldukça azalır; çünkü bütün Domain Controller’lar forest nesneleri hakkında gerekli bilgilerin önemli kısmını zaten biliyor olacaktır.

Dolayısıyla daha doğru yaklaşım şu şekilde ifade edilebilir:

Eğer domain içerisindeki bütün Domain Controller’lar Global Catalog değilse Infrastructure Master rolünün GC olmayan bir Domain Controller üzerinde tutulması tercih edilir.

Ancak:

Domain içerisindeki bütün DC’ler Global Catalog ise Infrastructure Master’ın Global Catalog üzerinde olması pratik olarak problem oluşturmaz.

Dokümanın sayfa 4’ündeki öneriler bölümünde de Infrastructure Master’ın Global Catalog ile aynı DC üzerinde tutulmamasının, domain’deki tüm DC’lerin Global Catalog olması durumunda istisna olduğu belirtilmektedir.

FSMO Rollerinin Operasyonel Önem Sırası

FSMO rollerinin tamamı önemlidir ancak hepsi günlük operasyonlarda aynı yoğunlukta kullanılmaz.

Genel olarak şöyle düşünebiliriz:

FSMO Rolü	Günlük Operasyon Yoğunluğu	Kritik Olduğu Durum
PDC Emulator	Yüksek	Parola, lockout, zaman, GPO
RID Master	Orta	Yeni kullanıcı/grup/bilgisayar oluşturma
Infrastructure Master	Orta/Düşük	Cross-domain referansları
Domain Naming Master	Düşük	Domain ekleme veya kaldırma
Schema Master	Düşük	Schema değişiklikleri

Buradaki “düşük” ifadesi rolün önemsiz olduğunu göstermez.

Örneğin Schema Master günlük işlemlerde çok az kullanılır ancak Schema değişikliği yapılacağı anda son derece kritik hale gelir.

FSMO Rolleri Hangi Domain Controller Üzerinde Tutulmalıdır?

Dokümanda FSMO rol yerleşimi için birkaç önemli öneri bulunmaktadır.

Özellikle:

• PDC Emulator’ın güçlü ve güvenilir bir DC üzerinde tutulması,
• Forest rollerinin forest root domain’deki uygun DC’lerde bulunması,
• Her rol için uygun bir yedek/standby Domain Controller planlanması,
• Infrastructure Master ile Global Catalog ilişkisinin doğru tasarlanması

önerilmektedir.

Örneğin iki Domain Controller bulunan küçük bir ortamda:

DC01
Schema Master
Domain Naming Master
PDC Emulator

DC02
RID Master
Infrastructure Master

şeklinde bir dağılım tercih edilebilir.

Ancak bu mutlak bir zorunluluk değildir.

Küçük ve sağlıklı bir Active Directory ortamında beş rol de aynı Domain Controller üzerinde bulunabilir.

Asıl önemli olan:

• DNS’in sağlıklı olması,
• Active Directory replikasyonunun düzgün çalışması,
• Domain Controller’ların düzenli yedeklenmesi,
• Event Log’ların izlenmesi,
• FSMO sahiplerinin biliniyor olması,
• Disaster Recovery planının bulunmasıdır.

FSMO Rolleri Nasıl Görüntülenir?

FSMO rollerinin hangi Domain Controller üzerinde bulunduğunu kontrol etmek için en yaygın komutlardan biri:

netdom query fsmo

komutudur.

Dokümana göre bu komut mevcut beş FSMO rol sahibini görüntüler.

Örnek çıktı:

Schema master               DC01.contoso.local
Domain naming master        DC01.contoso.local
PDC                          DC01.contoso.local
RID pool manager             DC02.contoso.local
Infrastructure master        DC02.contoso.local

Bu çıktı sayesinde hangi FSMO rolünün hangi Domain Controller üzerinde bulunduğu hızlı şekilde kontrol edilebilir.

PowerShell ile FSMO Rollerini Kontrol Etme

Ek teknik kullanım: PowerShell üzerinden de FSMO rolleri görüntülenebilir.

Forest seviyesindeki rolleri görmek için:

Get-ADForest |
Select-Object SchemaMaster, DomainNamingMaster

Domain seviyesindeki rolleri görmek için:

Get-ADDomain |
Select-Object PDCEmulator, RIDMaster, InfrastructureMaster

kullanılabilir.

Bu yöntem özellikle otomasyon ve sağlık kontrolü scriptlerinde oldukça kullanışlıdır.

FSMO Role Transfer Nedir?

FSMO rolleri belirli bir sunucuya kalıcı olarak bağlı değildir.

Mevcut FSMO sahibi sağlıklı ve erişilebilir durumdaysa rol başka bir Domain Controller’a Transfer edilebilir.

Örneğin:

DC01
PDC Emulator

rolüne sahip olsun.

DC01 planlı bakım nedeniyle kapatılacaksa:

DC01
      │
      │ FSMO Transfer
      ▼
DC02

şeklinde PDC Emulator rolü DC02’ye taşınabilir.

Transfer işlemi genellikle şu durumlarda kullanılır:

• Planlı bakım,
• Domain Controller yenileme,
• Eski DC’nin devreden çıkarılması,
• FSMO rollerinin yeniden dağıtılması.

Dokümana göre FSMO sahibinin sağlıklı ve erişilebilir olduğu durumlarda önerilen yöntem Transfer işlemidir.

FSMO Role Seize Nedir?

FSMO rol sahibinin tamamen kaybedildiği ve artık tekrar çalıştırılmayacağı durumlarda rol başka bir Domain Controller tarafından zorla devralınabilir.

Bu işleme:

FSMO Role Seizure

adı verilir.

Örneğin:

DC01
PDC Emulator
     │
     X
Donanım tamamen arızalandı
ve sunucu geri dönmeyecek
     │
     ▼
DC02
FSMO Seizure

Seize işlemi normal rol taşıma yöntemi değildir.

Bu daha çok Disaster Recovery senaryolarında kullanılan bir işlemdir.

Dokümanda da Seize işleminin yalnızca mevcut rol sahibi kalıcı olarak kaybedildiğinde kullanılmasının gerektiği açıkça belirtilmektedir.

Transfer ve Seize Arasındaki Fark

İşlem	FSMO Sahibi	Kullanım Senaryosu
Transfer	Çalışıyor ve erişilebilir	Planlı bakım / taşıma
Seize	Kalıcı olarak kaybedilmiş	Disaster Recovery

Basit bir ifadeyle:

Sunucu çalışıyor
      │
      ▼
   TRANSFER


Sunucu kalıcı olarak kayıp
      │
      ▼
    SEIZE

Transfer normal yönetim işlemidir.

Seize ise olağanüstü durum işlemidir.

FSMO Sorunlarında Temel Troubleshooting Süreci

FSMO problemi olduğundan şüphelenildiğinde doğrudan rol taşımak yerine öncelikle Active Directory’nin genel sağlığını kontrol etmek gerekir.

Eklediğiniz dokümanda önerilen temel kontrol sırası şöyledir:

1. FSMO sahiplerini belirleyin

netdom query fsmo

2. FSMO sahibi Domain Controller’ın çalıştığını doğrulayın

Sunucunun:

• açık,
• network erişimine sahip,
• Domain Controller servislerinin çalışıyor

olduğunu kontrol edin.

3. DNS çözümlemesini kontrol edin

Active Directory’nin düzgün çalışabilmesi için DNS son derece kritik bir servistir.

FSMO sahibinin isminin doğru çözümlenip çözümlenmediğini kontrol edin.

4. Active Directory replikasyonunu kontrol edin

Dokümanda önerilen temel komut:

repadmin /replsummary

şeklindedir.

Bu komut Domain Controller’lar arasındaki replikasyon başarısızlıklarını hızlı şekilde görmenizi sağlar.

5. Event Viewer kayıtlarını inceleyin

Özellikle:

Directory Service
System

logları incelenmelidir.

Ek teknik kullanım: DNS problemi şüphesi varsa DNS Server event loglarının da incelenmesi faydalıdır.

6. Sunucu planlı olarak devreden çıkarılacaksa Transfer kullanın

FSMO rol sahibi sağlıklıysa Transfer tercih edilmelidir.

7. FSMO sahibinin kesin olarak geri dönmeyeceği biliniyorsa Seize değerlendirin

Seize son seçenek olmalıdır.

FSMO Rolleri ile İlgili Önemli Notlar

Eklediğiniz dokümanda FSMO rolleri konusunda iki önemli hatırlatma daha bulunmaktadır.

İlk olarak Read Only Domain Controller – RODC sunucular FSMO rolü barındıramaz. Bunun nedeni FSMO rollerinin Active Directory veritabanına yazma yetkisi gerektiren roller olmasıdır.

İkinci önemli nokta ise FSMO rollerinin tek başına bir Active Directory Disaster Recovery stratejisi olmadığıdır.

FSMO rolleri:

• düzenli backup,
• replikasyon kontrolü,
• monitoring,
• DNS sağlığı,
• Disaster Recovery planı

gibi süreçlerin yerine geçmez.

FSMO Rollerini Akılda Tutmanın Kolay Yolu

Rolleri görevleriyle eşleştirdiğimizde öğrenmek oldukça kolaylaşır.

Schema Master

Active Directory’nin yapısını kim değiştirebilir?

→ Schema Master

Domain Naming Master

Forest’a kim domain ekler veya çıkarır?

→ Domain Naming Master

RID Master

Yeni AD nesnesinin benzersiz SID oluşturabilmesi için RID’leri kim dağıtır?

→ RID Master

PDC Emulator

Saat, parola, lockout ve GPO işlemlerinde merkezi rol kimde?

→ PDC Emulator

Infrastructure Master

Domain’ler arasındaki nesne referanslarını kim güncel tutar?

→ Infrastructure Master

Kısaca:

Schema Master
      ↓
AD yapısı


Domain Naming Master
      ↓
Forest domain yapısı


RID Master
      ↓
Benzersiz kimlikler


PDC Emulator
      ↓
Saat + Parola + Lockout + GPO


Infrastructure Master
      ↓
Domain'ler arası referanslar

Gerçek Bir Active Directory Ortamı Üzerinden Örnek

Örneğin aşağıdaki yapıyı ele alalım:

            contoso.local
                  │
        ┌─────────┴──────────┐
        │                    │
 ankara.contoso.local   istanbul.contoso.local

Forest içerisinde toplam üç domain bulunmaktadır.

Bu durumda forest bazında:

1 Schema Master
1 Domain Naming Master

bulunur.

Her domain için ise:

1 PDC Emulator
1 RID Master
1 Infrastructure Master

bulunacaktır.

Hesaplama:

Forest FSMO = 2

Domain FSMO =
3 Domain × 3 Rol = 9

Toplam FSMO Rolü = 11

Bu örnek forest ve domain bazlı roller arasındaki farkı anlamak için oldukça önemlidir.

Genel FSMO Mimarisi

Tüm konuyu tek bir şema üzerinde gösterirsek:

                    ACTIVE DIRECTORY
                           │
                           ▼
                         FOREST
                           │
             ┌─────────────┴─────────────┐
             │                           │
      Schema Master              Domain Naming Master
             │                           │
    Schema değişiklikleri          Domain ekleme/
                                    kaldırma
             │
             ▼
                         DOMAINS
                           │
             ┌─────────────┼─────────────┐
             │             │             │
             ▼             ▼             ▼
      PDC Emulator    RID Master   Infrastructure
                                        Master
             │             │             │
           Saat          RID Pool     Cross-domain
          Parola           SID        referansları
          Lockout
           GPO

FSMO rolleri Active Directory mimarisinin en önemli bileşenlerinden biridir.

Active Directory günlük işlemlerin büyük bölümünde Multi-Master Replication mimarisini kullanır. Bu sayede birden fazla Domain Controller aynı Active Directory veritabanının yazılabilir kopyasını barındırabilir ve yöneticiler birçok işlemi farklı Domain Controller’lar üzerinden gerçekleştirebilir.

Ancak Schema değişikliği, domain ekleme veya kaldırma, benzersiz RID dağıtımı, parola işlemleri, zaman senkronizasyonu ve domain’ler arası nesne referansları gibi bazı kritik görevlerin birden fazla Domain Controller tarafından aynı anda gerçekleştirilmesi tutarsızlıklara yol açabileceğinden bu işlemler FSMO rolleri aracılığıyla belirli Domain Controller’lara atanır.

Active Directory içerisinde toplam beş FSMO rolü vardır:

FOREST LEVEL
│
├── Schema Master
└── Domain Naming Master


DOMAIN LEVEL
│
├── PDC Emulator
├── RID Master
└── Infrastructure Master

Forest seviyesindeki roller bütün forest içerisinde yalnızca birer tane bulunurken domain seviyesindeki roller her domain için ayrı ayrı bulunur.

Yeni oluşturulan bir forest’ta ilk Domain Controller başlangıçta beş FSMO rolünün tamamını alır. Ancak FSMO’nun açılımındaki Flexible ifadesinin de belirttiği gibi roller daha sonra başka Domain Controller’lara transfer edilebilir.

Özellikle PDC Emulator, parola değişiklikleri, account lockout işlemleri, zaman senkronizasyonu ve Group Policy işlemleri nedeniyle günlük Active Directory operasyonlarında diğer FSMO rollerine kıyasla daha sık devreye girer. Bu nedenle PDC Emulator rolünün güvenilir ve sağlıklı bir Domain Controller üzerinde bulunması önemlidir.

Bununla birlikte sağlıklı bir Active Directory ortamı yalnızca FSMO rollerinin doğru dağıtılmasıyla oluşturulamaz. DNS, Active Directory Replication, Domain Controller sağlığı, düzenli yedekleme, monitoring ve Disaster Recovery planlaması birlikte değerlendirilmelidir. FSMO rolleri bu mimarinin kritik bir parçasıdır ancak tek başına yüksek erişilebilirlik veya felaket kurtarma çözümü değildir.

Bu nedenle bir sistem yöneticisinin yalnızca “Beş FSMO rolünün adı nedir?” sorusunu bilmesi yeterli değildir. Asıl önemli olan; her rolün neden var olduğunu, hangi işlemlerde devreye girdiğini, rol sahibinin erişilememesi durumunda hangi servislerin etkileneceğini ve Transfer ile Seize arasındaki farkı anlayabilmektir.