İlk bölümde forest yapımızdaki DC lerimizi hazırlamıştık:
https://ortacdemirel.com/admt-araci-ile-kullanici-hesaplarinin-tasinmasi-bolum-1-forest-yapisinin-hazirlanmasi
Bu bölümde ise ADMT ve PES yazılımlarını kurarak kullanıcı hesabımızı ve parolaları taşıyacağız.
Aşağıdaki bağlantıdan yer alan ADMT 3.2 ve PES yazılımını ortacdemirel.com forestını yöneten DC üzerine kuruyoruz.
https://connect.microsoft.com/site1164
Öncelikle ADMT yazılımını kuruyoruz.
Active Directory Migration Tool (ADMT) yazılımı forest ınız içerisinde farklı domainler arasında ya da iki ayrı forest arasında nesnelerin (kullanıcı, bilgisayar, group vb.) taşınmasını sağlamaktadır.
Bu araç sayesinde mevcut forest ınız içerisinde yer alan kullanıcı nesnelerini rahatlıkla yeni kuracağınız bir domain e taşıyabilirsiniz.
ADMT ve genellikle onunla birlikte kullanılan “Password Export Server (PES)” yazılımlarının Windows Server 2012 işletim sistemine uygun sürümlerini aşağıdaki bağlantıdan indirebilirsiniz.
https://connect.microsoft.com/site1164
PES de parolaların taşınmasını sağlayan bir yazılımdır. Kurulu olan sunucuda bir hizmet çalıştırarak bu işlemi yapmaktadır.
ADMT ve PES yazılımları dışında birde MS SQL Server’a ihtiyacınız vardır. Express kullanabilirsiniz. Mevcut yapınızdaki bir MS SQL Server’ı da bu iş için kullanabilirsiniz.
ADMT ve PES uygulamamızda test ortamımız şu şekildedir:
Windows Server 2012 sunucu üzerinde ortacdemirel.com ismi ile bir domain çalışmaktadır. Bu domaine bağlı birde SQL server yer almaktadır.
Gene Windows Server 2012 sunucusu üzerinden abc.local ismi ile tamamıyla ayrı bir forest yapısı mevcuttur.
Ortacdemirel.com sunucusu üzerinde yer alan “ortac” ismindeki kullanıcı hesabını abc.local içerisine taşıyacağız.
Bu uygulama iki bölümden oluşmaktadır. İlk bölümde iki ayrı forest yapısında yer alan sunucuların birbiri arasında güven ilişkisi kurmasına değineceğiz, ikinci bölümde ise ADMT ve PES araçları ile kullanıcı taşıma işlemine değineceğiz.
Öncelikle iki forest içerisinde çalışan DC ler arasında güven ilişkisi hazırlamamız gerekiyor.
Ortacdemirel.com domainine hizmet adan DC makinesinde DNS konsolunu açıyoruz.
Makine ismine sağ tıklayıp özelliklere geliyoruz.
Windows Server 2012 işletim sistemi ile birlikte Active Directory Recycle Bin özelliği ile tanıştık. Bu özellik sayesinde active directory üzerinden silinen nesneleri geri getirebiliyoruz.
Aslında bu özellik Windows Server 2000 ve sonrasındaki tüm işletim sistemlerinde mevcuttu. 2008 R2 ile powershell üzerinden gerçekleştirilen bu eylem 2012 R2 ile birlikte artık grafiksel bir ara yüzden de yapılabilmektedir.
Active directory üzerinden silinen her nesne asında “tombstone” adı verilen bir kap içerisinde tutulmaktadır. Direk içerisini göremediğimiz bu kap içerisinde nesneler belirli bir süre daha muhafaza edilmekte ve sonrasında kalıcı olarak silinmektedir.
Tombstone kabı içerisinde tutulma süreleri ise işletim sisteminin sürümüne ve güncellemesine göre değişmektedir. Örneğin Windows server 2000’de 60 gün, Windows server 2003 Sp1’de 180 gün, 2003 R2’de gene 60 gün şeklinde devam etmektedir. En son çıkan Windows Server 2012 R2’de ise bu süre 180 gündür.
İstersek bu süreyi değiştirebiliriz. Bu süre powershell komutu, ldp.exe aracı ya da adsiedit konsolu üzerinden değiştirilebilir.
Powershell üzerinden yapmak için:
Öncelikle Active Directory Module for Windows PowerShell aracını yönetici modunda açmamız gerekmektedir.
Ardından aşağıdaki komutu çalıştırabiliriz:
Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ortacdemirel,DC=local” –Partition “CN=Configuration,DC=ortacdemirel,DC=local” –Replace:@{“tombstoneLifetime” = 365}
Yukardaki komutun sonunda yazan “365” sayısı silinen nesnenin tombstone kabında saklanma süresini belirlemektedir.
Domain bölümlerini kendi yapınıza göre değiştirmeniz gerekmektedir.
Adsiedit üzerinden yapmak ise bazı kullanıcılar için daha rahat olabilir:
Öncelikle adsiedit konsolunu server manager konsolundan açıyoruz.
“Configuration” bölümüne bağlanıyoruz.
CN=configuraiton,DC=ortacdemirel,DC=com altından CN=services > CN=WindowsNT ye geliyoruz ve CN=Directory Service i buluyoruz.
Üzerine sağ tıklayıp özelliklerini açıyoruz ve “tombstoneLifeTime” attribute unu buluyoruz. Burada yazan süreyi değiştirebiliriz.
Active Directory ortamlarında sıklıkla görülen durumlardan biride domaine alınan makinelerin bir süre sonra domain controller ile ilişkisinin bozulmasıdır. Bu tür durumlarda kullanıcılar makinelerini domainde açamazlar. Sadece yerel (local) ortamda açabilirler.
Bu sıkıntı meydana geldiğinde domain kullanıcıları makineleri açtıklarında oturum açma yerinde aşağıdaki hatayı görürler:
Trust relationship with primary domain and local computer failed
Ya da
bu iş istasyonu ile birinci etki alanı arasındaki güven ilişkisi başarısız
Bu tür durumda yapılması gereken işlemlerden biri bilgisayarları local admin yetkisi ile açarak workgroup a alıp tekrar domaine dahil etmektir.
İkinci bir seçenek ise bilgisayarların domaine ilişkisini tekrar kazandırmaktır.
Bu işlem için öncelikle domainde açılmayan makineleri local (yerel) de açıyoruz.
İlk olarak makinenin hangi domain kontrolcü ile haberleştiğini öğrenmek için aşağıdaki komutu yazabiliriz.
Nltest /dsgetdc:mke.local (Buradaki mke.local domain isminiz olmalıdır)
Microsoft’un en yeni işletim sistemi Windows Server 2012 R2 yakın zamanda son kullanıcıların hizmetine sunuldu. Birçok yeni özelliği barındıran R2 sürümü için belki de en çok merak edilen hususlardan biri hem kendi hem de içinde barındırdığı Hyper-V sanallaştırma çözümü için lisanslama çeşitleridir.
Windows Server 2012 R2 ürünün dört sürümü bulunmaktadır. Bu sürümler Datacenter, Standard, Essentials ve Foundation sürümleridir.
Her sürümün kendine ait bazı özellikleri ve lisanslama modeli vardır. Bu lisanslama modelleri Windows Server işletim sistemleri sahip oldukları özelliklere, kurulacak sunucu üzerindeki işlemci sayısına, sunucuya bağlanacak kullanıcı ya da aygıt sayısına ve sanallaştırma planına göre farklılık göstermektedir.
Lisanslama tablosu aşağıdaki gibidir.
Bu tabloda ilk dikkat etmemiz gereken kısım lisanslama modelinde işlemci ve CAL sayısının yer aldığı bölümdür.
Her bir Datacenter ya da Standard sürümler tek başlarına 2 işlemci lisanslı içerirler. Yani fiziksel sunucunuzda 2 adet işlemci var ise tek bir Standard ya da tek bir Datacenter kullanabilirsiniz. (Yukardaki fiyatlarda buna göre verilmiştir). Fakat sunucunuzda 2’den fazla işlemci var ise ek sunucu lisansına ihtiyacınız vardır. Örneğin 4 işlemcili sunucu için 2 adet Datacenter ya da 2 adet Standart gereklidir.
CAL ise sunucunuza bağlantı sağlayan kullanıcı ya da aygıt ile hesaplanır. Örneğin Active Directory yapısında 1000 kullanıcısı olan bir kurum 1000 adet CAL almak zorundadır.
Sunucu yazılımlarının sahip olduğu farklı özelliklerde lisanslama modeline etki etmektedir. Bu özellikler ayrıntılı olarak makalemizin sonunda yer alan bağlantıda yer almaktadır.
Gelelim sanallaştırmaya. Belki de en fazla karıştırılan bölüm burasıdır. Bildiğiniz üzere Windows Server 2008 sunucu yazılımından beri Hyper-V sanallaştırma çözümünü kullanmaktayız. Windows Server 2010 r2 üzerinde de yer alan bu çözüm Microsoft tarafından ücretsiz olarak sunulmaktadır. Fakat Hyper-V çözümünde bir lisanslaması vardır.
Windows Server 2012 R2’de Hyper-V Lisanslama
Bir ya da iki işlemcili tek bir sunucu üzerine iki adet sanal makine kurulacak ise;
Bu tür bir senaryoda host (fiziksel) makinenize Windows Server 2012 Standard sürümü yüklemeniz yeterlidir. Bu sürüm ile iki adet sanal makineye ücretsiz olarak işletim sistemi kurabilirsiniz. Windows Server 2012 iki işlemciye kadar ek lisans gerektirmez ve size iki adet sanal makine kurma hakkı verir.
Bir ya da iki işlemcili tek bir sunucu üzerine dört adet sanal makine kurulacak ise;
Bu senaryoda tek bir Windows Server 2012 Standard sürümü yetersiz kalacaktır çünkü sanal makine sayınız artmıştır. Bu durumda iki adet Standard sürüme ya da tek bir Datacenter sürümüne ihtiyacınız vardır. Datacenter sürümü ile sınırsız sayıda sanal makine kurabilirsiniz.
Dört işlemcili tek bir sunucu üzerine dört adet sanal makine kurulacak ise;
İşlemci sayısı dört e yükselince tek bir Standart sürüm ya da Datacenter sürüm yetersiz kalmaktadır. İki adet Datacenter ya da standart sürüm olmalıdır.
Aynı senaryo için dört işlemcili bir makinede yüz adet sanal makine çalıştırmak isteseydik eğer gene iki adet datacenter sürüme ihtiyacımız olurdu. Çünkü datacenter sürümü sınırsız sayıda sanal makineyi desteklemesine rağmen iki adet işlemci için lisanslanır. Dört işlemci için gene iki adet lisansa ihtiyacınız vardır.
İki ayrı fiziksel sunucu üzerinde dağınık olarak sanal makineleriniz yer alacak ise;
Örneğin bu resimde iki fiziksel host üzerinde toplamda on adet sanal makine vardır fakat sanal makineler ilk host üzerinde dört adet, ikinci host üzerinde altı adet yer almıştır. Bu tür durumlarda gene işlemci ve sanal makinenin toplam sayısı kadar lisansa ihtiyacınız vardır. Yukardaki örnekte her iki host üzerinde ikişer işlemci olduğunu varsayarsak ya iki adet datacenter sürümü ya da on adet sanal makine üzerinden hesaplayacak olursak beş adet standard sürüme ihtiyacınız vardır.
Görüldüğü üzere Hyper-V sanallaştırmasında esas sınır işlemcidir. İşlemci sayısına göre alacağınız lisansı hesaplamanız gerekmektedir.
Kaynak:
Distributed Files System (DFS) özelliği organizasyon içerisinde farklı makinler üzerinde açılan paylaşımların tek bir adres altında toplanmasına yardımcı olmaktadır. Bu özellik ile kullanıcılar tek bir UNC paylaşım adresi ile farklı sunucular üzerinde açılan paylaşımlara erişebilirler.
Access Based Enumeration ise DFS üzerinde etkinleştirilen bir özelliktir. Bilindiği üzere paylaşıma açılan dosyalar yetkisiz kullanıcılar tarafından da görülebilir. İçeriğine erişemezlerse bile bilgisayar üzerindeki paylaşılan dosyaları görebilirler. DFS içinde aynı kural geçerlidir. Fakat ABE özelliği sayesinde paylaşıma açılan dosyaya erişim hakkı bulunmayan kullanıcıların paylaşımları da görmesini engelleyebiliriz.
DFS rolü kurulu olan sunucuda kullanıcıların paylaşımlara erişebileceği ortak alan ismi (namespaces) oluşturarak işe başlıyoruz.
Active Directory yapısına geçiş işlemlerinde belki de en zor ve zahmetli işlem daha önce yerel hesaplar ile çalışan kullanıcıların dokümanlarını yeni domain hesaplarına taşımaktır.
Windows işletim sistemlerine yerel kullanıcı hesapları ile oturum açan kullanıcılar active directory ortamına geçişte bu kullanıcı hesaplarını kullanamazlar. Yeni domain hesapları ile oturum açmak zorundadırlar. Domain hesapları ile Windows işletim sistemlerine oturum açınca da yerel hesap ile kullandıkları ve kendilerine özgü dizinlerde bulunan dosyalara erişemezler. Bu dizinler; belgelerim, müziklerim, videolarım ve masa üstü gibi kişiye özel yerlerdir. Bu dizinler dışında C , D ya da farklı bir sürücü altında yer alan dosyalara erişimde sıkıntı olmayacaktır.
Kullanıcı profilinin taşınması için Windows ait user migration tool aracı bulunmaktadır. Bu araç dışında birçok üçüncü party yazılımda mevcuttur. Bu yazılımlardan biride fronsit firmasına ait profwiz aracıdır. Biz de yazımızda bu araca değineceğiz.
Yazılımı fronsit in web sayfasından ücretsiz olarak çekebilirsiniz.
User Profile Wizard
http://www.forensit.com/downloads.html
Makale içerisinde son sürüm olan User Profile Wizard 3.7 kullanılmıştır.
Bu aracı domaine aldığın tek tek tüm makinelere kurup çalıştırabilirsiniz. Fakat makinelere taşıma işlemi zahmetli olacağından bu işlem için group policy i kullanacağım.
Amacımız tüm domain e katılan makinelere otomatik olarak profwiz yazılımının kopyalanmasını sağlamak. Bu aşamadan sonra programı çalıştırarak kullanıcı profillerini taşıyabileceğiz.
Programın kopyalanması için öncelikle sunucumda bir paylaşım açıyorum ve içerisine profwiz programını yerleştiriyorum.
