Bir IT projesinin yaplımasında fiziksel şebeke yapısının planlanması (LAN ve WAN cihazlarının seçimi , kablolama yada kablosuz çözümler , Sunucular vs.) , arkasından Network servislerinin kurulması (DNS, DHCP, NAT vs. gibi) iletişim için yeterli olabilir. Ancak bu tür yapıları Active Directory gibi Domain yapıları ile tamamlamak önem taşıyor.
Çünkü Domain ortamının bize sağladığı kolaylıklar çok fazla. Yönetimin tek bir kişide toplanabiliyor. Yönetici sorumluluğunun bir kısmını diğer arkadaşına devredebiliyor. Kullanıcıların ve makinelerinin yetenekleri
Kısıtlanabiliyor. Dosyaların şebekede paylaştırılmasının ancak yönetici veya ona bağlı özel gruplar sayesinde oluyor. Şifrelerin nasıl olması gerektiğine yönetici karar veriyor. Güvenlik güncellemeleri tek merkezden herkeze dağıtılabiliyor. Kısaca Domain yapının kontrolünü tamamıyla yöneticiye bırakıyor.
Domain ortamını yaratmak bu yazının konusu değil. Microsoft?un her uygulamasında olduğu gibi ?next next? diyerek kolayca domain kurmak mümkün. Sıkıntılı olan bence tasarımını yapmak . Bu yazımda bir Active Directory tasarımı nasıl yapılır bundan bahsedeceğim.
İlk işimiz Active Directory Domain ismine karar vermek olmalı. Bugün her firmanın internete bakan bir yüzü olduğundan isim konusu özellikle önem taşıyor. Firmanın DNS?de temsil edilen ismi ile Active Directory domain adı arasında paralellikler vardır. Dns Domain adınız firma.com olduğunu varsayalım. Active Directory Domain adınızı 3 şekilde tercih edebilirsiniz.
Şekilde Active Directory Domain isimleri ile Dns üzerindeki domain kayıtları arasındaki benzerlik açık bir şekilde görülüyor.
Birincisi firma.com yapmak. Pek tavsiye edilmez. Kullanıcılar her iş için tek bir domain adını kullanırlar. Ancak Admin?in işini arttırır. Firewall konfigurasyonu daha sıkıntılı olabilir. İsim çözümlemesinde karışıklıklar olabilir. Dns Domain sekronizasyonu dış gerçek makinelere bağımlıdır.
İkinci yöntem ise adını örneğin baskaisim.com yapmak. Bu durumda dahili isimlerinizin dünyaya teşhir edilmesini önlemiş olursunuz ama Internet üzerinden dahili makinelerinize erişimi durdurmuş olursunuz. İki farklı isim kullanıcıların kafalarını karıştırabilir. Dns yapınız doğrudan sizin kontrolünüzde olduğu için istediğiniz gibi yönetimini sağlayabilirsiniz. Internetten iç kaynaklara erişimi kestiği için bunu aşmak amacıyla ikinci bir Dns Domain adı almak zorunda kalabilirsiniz.
Üçüncü yöntem ise Active Directory Domain adını örneğin Corp.firma1.com yapmak. Bu şekilde bütün Active Directory verilerini internette IP si görünen sunucularınızdan izole edebilirsiniz. Corp.firma1.com Domain?ini kendi yerel ağınızdaki DNS inize delege ettirerek hem Active Directory üye kullanıcı makinelerini ve Domain Controller SRV kayıtlarınızı saldırganlara karşı büyük ölçüde korumuş olursunuz.
Birden çok Domain kurmaya neden ihtiyaç duyarız? Active Directory Domain?leri biraraya gelerek Forest?ı meydana getirirler. Her Domain ayrı bir yönetim alanı oluşturduğu için Admin?lerin yetkisi ve sorumluluğunu net bir şekilde birbirinden ayırmak için farklı Domain?lere ihtiyaç duyarız. Bir Domain aynı zamanda bir güvenlik çemberi teşkil ettiği için aynı sınırlar içinde uygulayacağınız tedbirler (Şifrelerin enaz 8 karakter olması, network? te akan dataya IPSEc uygulanması gibi...) ülkeden ülkeye, bölgeden bölgeye farklılık gösterebilir. Bu durumda farklı Domain?ler yaratmak gerekecektir. Tek bir Domain?de farklı global güvenlik tedbiri uygulayamazsınız. Active Directory replikasyon amaçlı Domain? i ilgilendiren verilerinin tüm Domain içinde paylaşılmasını şart koşar. Eğer Domain Controller?lar arasında özellikle yerleşime bağlı olarak hattınızda bant genişliği azlığı (128 KB ve aşağısı) probleminiz varsa yada süreksiz (çevirmeli ağ bağlantısı) bir bağlantı durumu varsa farklı Domain kurmak replike edilecek veri miktarını çok büyük ölçüde (% 80-90) azaltacaktır.
Farklı Domain kurmanın diğer bir sebebi de şirket evlilikleridir. İki firma sonradan birleşecekse ve ortak Active Directory şema yapıları farklı ise (Örneğin farklı mail organizasyonları kullanıyorlarsa) yada firmalar geçici olarak bir araya gelmişlerse bu durumda tek Domain çatısı altında toplamak yerine harici Trust ilişkisi kurarak farklı Domain?leri birbirine bağlamak çözüm olacaktır.
Birden çok Domain Active Directory?nin işleme mantığı açısından her zaman tek Domain?e göre performansı daha düşüktür. Microsoft mümkünse tek Domain ile çalışmayı tavsiye ediyor. Ancak bu yukarıda bahsettiğim sebeplerden dolayı her zaman mümkün olmayabilir.
Tasarımda diğer önemli konu Site seçimleridir. Bilindiği gibi Site ile Active Directory replikasyonunun gerçek bant genişliği üzerinden olması sağlanıyor. Site nesnesi ile Active Directory?ye replikasyonu şu yerleşime şu yoldan giderek yapabilirsin diyebiliyoruz. Active Directory kurulu bir şebekede en uzak şubeye erişmenin onlarca ayrı yolu olabilir.
Şekildeki gibi farklı farklı siteler arası bağlantılar yapmak mümkün.
Bu durumda Active Directory bizim vereceğimiz (gerçek bant genişliğiyle ters orantılı olacak şekilde) Cost değerleri ile en iyi yolu kendisi seçebiliyor. Şube bağlantı hızları farklı ise ve özellikle 500 kbps ve aşağısı hızlar var ise bu durumda varsayılan 5 dakikada bir olan periodik replikasyon ayarını Active Directory bizim insiyatifimize bırakabiliyor. Böylece replikasyon sıklığını kontrol altına alabiliyoruz. Site kavramı ile ayrıca şubelerdeki kullanıcıların kendi sitelerindeki Domain Controller üzerinden Logon olmalarını sağlayarak hem Logon süresini kısaltıp hemde gereksiz WAN trafiği oluşmasını önleyebiliyoruz. Aksi taktirde örneğin Adana?daki kullanıcı belki de kendi sitesindeki Domain Controller dururken İstanbul?daki Domain Controller üzerinden logon olabilecekti. Bu da canımızı sıkacaktı.
Yarattığınız her sitede bir Domain Controller mutlaka olmalı. Aksi taktirde Site yaratmanın bir faydası olmaz.
Her sitede bir Global Catalog olması iyidir. Böylece özellikle kullanıcıların ait oldukları Universal Grup üyelikleri için merkezdeki Global Catalog?a sorulması da önlenmiş olacak. Bilindiği gibi logon sırasında kullanıcı kendi kimlik bilgilerini ifade eden SID numaralarını alır iken üyesi olduğu grupların da SID?lerine ihtiyaç duyar. Grup tipleri içinde Universal Grup adında özel bir tür vardır ki bu grubun kendisinin ve üyelerinin SID?leri sadece yaratıldığı Domain?de ve Global Catalog?da saklanır. Bilgisayarın kullanıcının Universal Grup üyelikleri var mıdır diye Global Catalog?a sorma zorunluluğu vardır. Çünkü varsa SID?lerini Global Catalog?dan alacaktır. Şimdi Windows 2003 server ile gelen ?Universal Group Membership Caching? özelliği de her siteye Global Catalog koymak yerine Domain Controller?ların Universal Gruplara ait SID?leri kendi Cache?lerinde saklamalarına imkan verdiği için alternatif bir çözüm olabilir.
Tek domain varsa bütün Domain Controller?ları Global Catalog yapmak tavsiye edilir.
Özellikle Exchange 2000/2003 Server varsa bu durumda her sitede bir Global Catalog olması şiddetle tavsiye edilir.
Çok fazla gezici kullanıcı varsa en çok logon oldukları siteye Global Catalog koymak performansı arttıracaktır.
Sitede 100 den daha az kullanıcı var ise Universal Group Membership Caching özelliği iyi bir çözüm olabilir.
Site içinde birden çok Domain Controller var ise bu durumda bir yerine en az iki Global Catalog kullanmak yedeklemeli kesintisiz çözüm sağlayacaktır.
Domain Controller?ların donanımının seçimi bir çok parametreye bağlıdır. Server kapasitesinin seçimi kullanıcı sayısına, ortamdaki mail organizasyonu olup olmadığına, bilgisayar sayısına, site sayısına, Domain Controller üzerinde ayrıca bir Global Catalog ve FSMO rolleri olmasına, kullanıcıların üye oldukları grupların çok olmasına gibi bir çok faktöre bağlıdır. Microsoft sitesinden indirebileceğiniz ?AdSizer? aracı size kapasite planlaması yapılmasında fikir verecektir. Çok kaba bir hesapla 500-1500 arası kullanıcının olduğu bir Domain ortamında en azından 2 işlemci (899 Mhz ve yukarısı) ve 512 MB Ram ve işletim sistemi ile birlikte 3.4 GB (1000 kullanıcı ve aşağısı için) disk alanının olması gerektiğini Microsoft söylüyor. Tabiki siz bu rakamları performanslı çalışmak için ikiye katlayın.
Operation Master rollerinin hangi Domain Controller?larda olacağı seçimi Active Directory?ye ince ayar yapmak için önemlidir. Bilindiği gibi Operation Master?lar PDC Emulator, RID Master, Infrastructure Master, Schema Master ve Domain Naming Master?lardır. PDC Emulator, ortamda varsa NT Backup Domain Controller?lara Primary Domain Controller?lık yapar. Group Policy nesnesi yaratılmasında onay verendir, Forest içinde diğer Domain?lerdeki PDC Master?lar ile koordineli çalışarak Active Directory zamanını senkronize ederek tüm Forest?da zamanın aynı olmasını garanti ederler. Şifre değişikliklerinde hesaplar kitlenmesin diye Domain Controller?lara yardımcı olurlar.
RID Master ise Active Directory?de yaratılan nesnelerin her birine ait eşi olmayan SID ve GUID numarası vererek yalnışlıkla aynı numaralarının bir başka Domain Controller tarafından bir başka nesneye tahsis edilmemesini garanti ederler. Böylece her nesnenin eşsizliği sağlanır. Olası çakışmalar daha doğmadan önlenir.
Infrastructure Master ise Domain?ler arasında kullanıcı ve bilgisayar transferi yapılması anında gerekli grup üyelikleri düzeltmesinin yapılmasını sağlar. Böylece örneğin X Global Grubuna ait İsmail?in başka Domain?e transferi sırasında eskiden üyesi olduğu X grubundan çıkartılması sağlanır.
Gerek PDC Emulator olsun, gerekse RID Master olsun, gerekse de Infrastructure Master olsun her Domain?de sadece bir tane olmak zorundadırlar. Bu durumda bütün roller kapasitesi en iyi ve çökmeyeceğinden emin olduğunuz Domain Controller üzerinde olmalıdır. Infrastructure Master?ın Global Catalog ile aynı makine üzerinde olmaması Microsoft tarafından şiddetle tavsiye ediliyor. Eğer Domain?de tek Domain Controller var ise bu durumda mecburen aynı Domain Controller üzerine olacaklar ancak bunun kesinlikle tek Domain olması durumunda sakıncası yok. Her üç rolu de en kalabalık Sitenin olduğu yerdeki Domain Controller üzerinde konuşlandırmakta fayda var. Birde yedekleme amaçlı bu rolleri transfer edebileceğiniz ikinci bir Domain Controller?ın da olması iyidir. İlki çökerse tabi ki Backup?tan da geriye dönebilirsiniz. Ancak zaman kaybınız bu durumda daha çok olabilir.
Domain Naming Master ise Forest?a ilave edilecek yada silinecek bir Domain olma durumunda izni alınan roldür.
Sık sık Domain eklenmesi gerçekleşmediği için bu rolun eksikliği pek hissedilmez. Forest bazında bir tane olmalıdır.
Schema Master ise Active Directory Şemasına örneğin Exchange 2000/2003 kurarken 1000?e yakın Class ve Attribute ilavesi yapılması anlamına geldiğinden bu değişiklkler için izni alınacak roldür. Eksikliği Şemada değişiklik yapılma isteği olmadıkça hissedilmez. Forest bazında bir tanedir.
Hem Domain Naming Master hem de Schema Master?ın üzerine Global Catalog olmayan bir başka Domain Controller?a birlikte transfer edilmesi tavsiye ediliyor. Aynı tavsiye Domain bazında iş yapan roller içinde sözkonusu.
İyi düşünülmüş Organizational Unit?ler oluşturulması hayatınızı çok kolaylaştırabilir. Bilindiği gibi OU (Organizational Unit) yapıları Active Directory?de yöneticinin üzerindeki bilgi işlem yükünün başkalarına delege edilmesi ve Group Policy uygulanması amacıyla kullanılıyor. Bu amaçla gerek kullanıcıları gerekse de bilgisayarları OU nesnesi altında grupluyoruz. Çünkü delegasyon ve poliçe uygulaması ancak OU üzerinden yapılabilir. OU oluşturulmasında fonksiyona göre olabilir. Yani personel bölümündekiler personel OU?su altında, muhasebedekiler muhasebe OU?su altında toplanabilirler. Diğer bir gruplama ise yerleşime göre olandır. Yani Ankara?dakiler Ankara OU?su altında , İstanbul?dakiler Istanbul OU? su altında toplanabilirler. Bunun kararını iyi vermek lazım. Yalnızca fonksiyona göre yaparsanız ve şifrelerin reset?lenmesi işini (delegasyon) Ankara?daki personelci Ali?ye verdiyseniz bu durumda Istanbul?daki personelci Ahmet şifresini unutunca Ankara?yı mı arayacak her seferinde? Belki hem yerleşimi hem de fonksiyonu içinde barındıran bir çözüm sizin için çözüm olabilir.Yani Ankara OU?su ve onun altına Ankarapersonel OU? su ve Istanbul OU su ve onun altında IstanbulPersonel OU?su gibi. Genel tavsiye önce yerleşime göre sonra fonksiyona göre OU tasarımı yapmak yönündedir.
Şekilde hibrit bir OU yapısı örneği görülüyor.
Gereksiz OU yaratmayın. OU içinde OU ve onun da içinde OU gibi çok fazla OU dikey yapılaşmayı tercih etmeyin. Bu durumda tepeye uygulanacak Group Policy?nin inherit durumu ve üzerindeki her bir OU ?dan gelen Group Policy?lerin hesaplanması bilgisayarınızın logon perfonmansını azaltacaktır.
OU tasarımı yapmak Group Policy?lerin rahat uygulanabilmesini sağlar. Poliçe uygularken çok fazla dikey yapılaşmış OU içinde OU varsa mümkünse sadece tepeye uygulayın. Her bir OU?ya ayrı ayrı Poliçe uygulamayın. Elinizde 5-10 tane şablon Group Policy olsun ve onları uygulayın. Çok fazla çeşit poliçeniz varsa bu durumda OU yapısını daha baştan oluştururken belki de dikey yerine yatay yapılaşma daha iyi olacaktır. Poliçe uygulamasında miras(inheritance), no override, blok koyma, filtreleme gibi özellikleri pek fazla kullanmamaya çalışın. Etkileyen toplam poliçelerin hesaplanması logon süresini uzatacaktır.
Hesapların açılmasında da dikkat edilecek konular var. Diğer bir konu ise hesapların yaratılmasıdır. Gerektiği kadar hesap açılmalı. Sık sirkülasyon olan bir firma ise yani sürekli eleman işten ayrılıyor ve yerine yenileri alınıyor ise isme göre hesap açıp silmektense ya pozisyona göre (pozisyonu kimse işten atmıyor) muhasebe1 şeklinde hesap açabilirsiniz bu yöntem pek sıcak gelmediyse eski kullanıcının ismini değiştirip şitresini de resetlemek mümkün. İten çıkan elemanı 6 ay hesabını silmeyin. Eğer silerseniz eleman tekrar işe alınırsa bu durumda yeni yaratacağınız aynı isimli kullanıcı kesinlikle sildiğiniz kullanıcının haklarına sahip olamayacaktır. Çünkü Yeni Ali eski Ali değildir. Farklı SID?li bir kişidir. Şifreler uygun güvenliği sağlayacak şekilde yeteri kadar uzun (en az 8 karakter) ve karışık harf ve rakamlardan oluşmalıdır. 3 kez şifresini yalnış girenin hesabının kitlenmesi deneme yanılma yoluyla logon olmaya çalışanları önleyecektir. İsim çakışması olmasın diye İsmail yerine İsmailH kullanılabilir.
Bu yazımda çok da ayrıntıya girmeden bir Active Directory tasarımının nasıl yapıldığından bahsetmeye çalıştım.
Bir sonraki yazımda görüşmek dileğiyle.
|