Active Directory domain ortamlarında kimlik doğrulama ve isim çözümleme servisleri olarak Kerberos – NTLM ve DNS hizmetlerini kullanan istemci sunucuların üzerindeki servisler için ( SQL, Oracle, Exchange, Sharepoint, Biztalk vb ) Directory ve DNS hizmetlerindeki kesintiler ciddi sonuçlar doğurmaktadır.
DNS hali hazırda zaten directory de dâhil tüm alt yapı için vaz geçilmez bir servis olup genellikle iyi yönetildiği sürece kesintilere sebebiyet vermemektedir. Directory hizmeti ise daha karışık olduğu için sürekli takip ediliyor ve inceleniyor olması gerekmektedir.
Genellikle her ne kadar kararlı bir hizmet sunuyor olsanız da sizden hizmet alan istemcilerin size ulaşması noktasında da kararlı bir yapıya sahip olmanız gerekmektedir. Yani DC ler sağlıklı çalışıyor olsa bile istemcilerin veya diğer sunucuların DC lere sağlıklı bir şekilde ulaşması gerekmektedir.
Yaygın bir kullanım olmamak ile beraber Banka, Telekom veya veri güvenliğinin önemli olduğu kurumsal firmalarda segmentasyon dediğimiz istemci ve sunucu ürünlerinin arasına güvenlik cihazlarının konulması ile oluşturulan bölgeler bulunmaktadır.
Burada ilk olarak network uzun süre izlenerek gerekli olan izinler tespit edilir ve adım adım bunların dışında kalanlar kapatılır.
Bu yapının en önemli amacı güvenliği üst seviyeye çıkarmaktır. Örneğin siz yönetmekte olduğunuz bir sunucuya yönetim konsolu portundan veya https ile veya rdp ile gidebiliyor iken dosya seviyesinde ulaşamıyorsunuz. Bunun gibi örnekleri arttırmak mümkün.
Ancak bu tarz yapılarda arttırılan her güvenlik önlemi aslında sorun anında çözümü yavaşlatan birer sebeptir.
Yukarıdaki şekilde aslında işi özetliyor. Network segmentasyonu olarak bildiğimiz bu yapının en temel süreci istemciler ile sunucuları bir birinden güvenlik duvarı ile ayırmaktır. Ancak bunun ilerleyen durumlarında ise işler uygulama bazlı firewall kullanmaya kadar gitmektedir.
Örneğin yukarıdaki gibi veri tabanları için ayrıca firewall kullanma şansına sahipsiniz.
Bunlara ek olarak bu sistemlerin üzerinde log toplama ajanları da bulunmaktadır. Symantec SSIM, Karmasis Infraskope, Quest change Auditor veya Quest Intrust gibi. Tabiki bunlarda bu sistemler üzerinde ciddi yoğunluk teşkil etmektedir.
Birde tüm bunlara ek eğer network seviyesinde deduplication yapan cihazlar var ise işte bu senaryoda olası kimlik doğrulama veya diğer kesintilerinin kaynağını bulmak nerede ise imkânsızdır.
Yukarıdaki şekil, network seviyesinde ki deduplication işlemini özetlemektedir.
Gelelim bizim makale konusuna, eğer böyle karmaşık bir sisteminiz var ise bir takım kritik sunucular için bu tarz özellikle network ve güvenlik seviyesinden arınmış domain controller – dns hizmeti sunmak isteyebilirsiniz.
Bunun için öncelikle tabiki DC ile bu kritik sunucu sistemleri arasında firewall vb cihazlar olmaması gerekmektedir. Ancak normal şartlarda DC lerde diğer sunucu ve özellikle istemcilerden gelecek ataklara karşı korunması nedeni ile firewall arkasında bulunmaktadır.
Bizim amacımız bu yapıyı bozmadan yani mevcut DC lere ek özel olarak örneğin uygulama sunucularınız için veya veri tabanınız için özel dc konumlandırmak.
Özel DC aslında biraz karmaşık bir kavram. Exchange server gibi sistemlere şu DC yi kullan gibi statik bilgi verebiliyoruz ( Powershell komut seti ile ). Ancak bunu dışındaki pek çok sistem için DC bilgisi DNS üzerinden otomatik olarak çekilmektedir.
DNS kendisine yapılan bu sorguya karşılık DC listesini sunar, burada sunulacak olan DC listesinde site kavramı çok önemlidir. Çünkü cevap olarak verilecek DC listesi için öncelikle bu isteği yapan istemcinin site bilgisine karşılık gelen site içerisindeki DC lerin listesi verilmektedir. ( netmask ordering sadece A kayıtları için kullanılır bunu aklınızdan çıkarmayın lütfen )
Bu durumda bizde öncelikle ayrı bir vlan ile diğer sistemlerden isole edilmiş olan uygulama veya veri tabanı sunucularının bulunduğu network bilgisini AD üzerinde ayrı bir site olarak tanımlıyor olmamız gerekmektedir.
Öncelikle yeni bir site oluşturuyoruz
Daha sonra bu site için bir Subnet tanımlıyoruz.
Bu network artık AD için farklı bir site olarak nitelendirilmektedir ve yeni kuracağınız DC yi bu vlan içerisinde bu network ten bir ip de kurarsanız sistem otomatik olarak bu site içerisine yerleştirecektir.
Bundan sonra ise aslında özel bir şey yapmanıza gerek yoktur. Artık bu site içerisindeki yani bu network ( vlan ) içerisindeki sunucular bu DC veya DC ler ile iletişime geçecektir, tabiki bu DC lerdeki bir kesinti durumunda diğer DC ler hala bu sunuculara hizmet vermeye devam edecektir.
Ancak bu mimaride önemli bir noktada replikasyondur. Aslında fiziki olarak aynı bölge, aynı data center belkide aynı kabindeki makineleri siz AD mantıksal mimarisinde ayırdınız, yani istemciler ve diğer sunucular ile bu sunucular ve DC artık 15dk gecikmeli konuşacak. Çünkü AD mimarisi gereği iki site arasındaki replikasyonlar minimum 15dk gecikmeli olmaktadır.
Makalemizin bu noktasında replikasyon noktasında kısa hatırlatmalar yapmak istiyorum.
Replication ne zaman olur?
AD veri tabanında bir değişiklik oldu mu Replication başlar. Bu değişiklikler:
Obje ekleme, silme, değiştirme ve benzeri işlemlerdir.
Yukarıdaki eylemlerden herhangi biri herhangi bir DC üzerinde gerçekleşir ise eğer, o DC site içindeki tüm partnerlere olayı bildirir. Bu olaya “change notification” denir. Notification dan sonra partner DC’ ler kaynak DC’ den değişiklikleri almak isterler. Kaynak DC’ de update i yollar ya da request edenleri sıraya sokar.
Bu change notification sürecinde temel iki gecikme yaşanmaktadır.
Initial notification delay; Bir dc de olan değişiklikten sonra bu dc nin replikasyon partnerlarından ilki ile iletişime geçmeden önceki geçen bekleme süresidir. Bu süre varsayılan olarak 15 sn dir. Yani siz bir dc üzerinde bir değişiklik yaparsanız bu değişikliğin replike olması için 15 sn beklenir ( güvenlik ile ilgili olan değişikliklerin dışında , şifre değiştirilmesi , hesap lock olması vb ) .
Bu süre isterse değiştirilebilir.
msDS-Replication-Notify-First-DSA-Delay varsayılan olarak 15 sn dir
DC üzerinde bir kullanıcı için örneğin 3 ayrı attribute değiştirdiğiniz zaman bunların hepsi tek bir change notification olarak partner dc ye gönderilmektedir. Çünkü 15sn bekleme süresi vardır. Eğer bu olmasaydı her bir değişiklik tek tek gönderilecek ve inanılmaz bir trafik oluşturacaktı.
Subsequent notification delay; Bu değer ise ilk replikasyondan sonra bilgiyi alan dc ile bundan sonraki dc lerin replikasyonu için beklenen süredir ve bu 3 sn dir. Bunun sebebi ise ilk dc bütün partner lara aynı anda değişiklik bilgisi yollamaz ki cevap için servis kesintisi yaşanmasın yani yük dengeleme yapar.
msDS-Replication-Notify-Subsequent-DSA-Delay varsayılan değer 3 sn dir.
Bir replication sırasında, kaynak DC’ den 1. partner DC’ ye gönderilen “change notification” 3 sn sonra 2.ye gider ve 3 sn aralıklarla bu işlem bütün partnerlere gönderilecek şekilde devam eder. Böylece bir replication süreci tamamlanır. 2. replication da 15 sn sonra başlar. Bunlar default ayarlardır. Ayrıca network trafiği ve performansı için optimum ayarlardır.
Gördüğünüz gibi ortamda aslında küçükte olsa bir takım gecikmeler olabiliyor. Her DC için ilk replikasyondan önce beklenen bu 15sn ye biz “notification delay” olarak isimlendiriyoruz.
Aşağıdaki gibi bir senaryo olması halinde ise durum değişmektedir. Bu 15sn lik gecikme aynı site içerisindeki DC ler için geçerli olup farklı site içerisinde bulunan bu DC’ ler için ne yazık ki replikasyon noktasında geçerli olan süre site link üzerindeki süredir ve bu da yine makalemin içerisinde belirttiğim gibi minimum 15dk olarak ayarlanabilmektedir. Ancak böyle bir yapıda daha hızlı bir replikasyon ihtiyacımız var ise bu durumda “Inter-site change notification” olarak bildiğimiz ve aynı site içerisinde olduğu gibi site ların arasında da hızlı replikasyon ( aslında değişiklik bilgisinin iletilmesi ) imkanı sunar. Bu durumda yani inter site change notification açık ise aşağıdaki gibi bir yapıda DC1 üzerinde gerçekleştirilecek olan değişikliğin DC8 e ulaşması için geçen süre 105sn sürecektir.
Her ne kadar 105sn böyle bir yapı için kabul edilebilir bir süre olsa da bazı özel durumlarda yeterli olmaz.
Bu durumun üstüne iki farklı replikasyon modelinden bahsetmek istiyorum.
Urgent Replication ve Immediate Replication.
İlk olarak Urgent Replikasyon nedir onu görelim.
Urgent replikasyonunda 15sn olan bu delay notification beklenmez ve aşağıdaki durumlarda olur
Account lockout
Changing a Local Security Authority
Changing the password on a domain controller computer account.
Changing the relative identifier (known as a “RID”) master role owner
Changing the account lockout policy.
Changing the domain password policy.
Yani yukarıdaki durumlardan herhangi biri olur ise 15sn ve 3sn gibi gecikmeler yaşanmadan bu bilgiler anında partner DC lere gönderilir. Tek istisnası bu site içerisinde böyle çalışır. Çünkü urgent replikasyonun normal replikasyondan tek farkı notification delay olmaması. Ancak hala site ların arasında replikasyon için 15dk beklemek zorunda. Ancak site ların arasında change notification açılır ise bu durumda yukarıdaki güncellemeler site ların arasında da anında iletilir.
Immediate Replication
Site’ dan bağımsız olarak her hangi bir site içerisindeki herhangi bir DC de bir kullanıcı şifre değiştirir ise bu bilgi anında PDC ye iletilir. Daha sonra bu kullanıcı başka bir site içerisindeki henüz replikasyonu almayan dc de logon olmaya çalışır ve logon işlemi başarısız olur ise DC varsayılan olarak şifre değiştirme olasılığına karşın PDC ye giderek bir kez daha şifreyi ona sorar ve güncel şifre olduğunu öğrenerek logon sürecini tamamlar.
Peki, özetlemek gerekir ise
Eğer yukarıdaki gibi özel sistemler için ayrı bir site yaparsanız gerek lock bilgisi gerekse şifre bilgisi iletim noktasında herhangi bir sorun yaşamayacaksınız.
Şifre bilgisi için zaten özel bir ayara gerek yoktur, yani site ların arasındaki minimum 15dk ya çekebildiğimiz bu gecikmeyi engellemek için yapacağımız inter site change notification ayarı aslında password için gerekli değil, sonuçta şifre değişince PDC nin bundan haberi oluyor. Ardından farklı bir site içerisindeki makineye yeni şifre ile giriş yapılmaya çalışılınca bu DC hata alır ise bunu PDC ye soruyor ve yeni şifreyi doğrulayıp giriş izni veriyor.
Lock bilgisi için urgent replikasyon olduğunu söylemiş ancak site ların arasındaki gecikmeye takılacağını söyledim. Bunuda aşmak için site ların arasında change notification açarak bu sorunuda aşabiliyoruz.
Bir daha özetle dersek, çünkü gördüm ki yukarıdaki özetim de biraz uzun oldu, tek bir değişiklik ile özel sistemler için özel DC ler konumlandırılabilir.