Windows Server 2012 Ortamında ADMT ile Kullanıcı ve Grupların Farklı Forestlar Arasında SIDHistory ile Beraber Taşınması
Makalemizin bu bölümünde sizlere hali hazırda sahip olduğumuz bir trust yapısı üzerinden kullanıcı ve grup taşımayı anlatacağım.
Malum bundan önceki bölümlerde trust nedir, trust tipleri, teknik detaylar, forest trust ve external trust oluşturulması ve daha pek çok konuda bilgi paylaşımında bulunmuştum. Bu bölümlere aşağıdaki linklerden ulaşabilirsiniz.
Bu bölüm ise diğer bölümlerden tamamen bağımsız bir bölüm olup ADMT aracı ile iki forest arasında kullanıcı ve grup taşımayı anlatacağım.
Aslında bu konu Hakan hocam tarafından iki bölüm halinde çok detaylı incelenmiştir.
Tavsiyem mutlaka bu makaleleri okumanızdır.
Ben ise malum Server 2012’ nin piyasaya çıkması ile bu taraftaki gelen çok küçük değişikliklerden bahsedeceğim. Aslında değişiklikten öte henüz araçlar hazır olmadığı için şu anda ADMT kullanmak biraz sıkıntılı bir durum. Ancak hali hazırda bazı projelerimizde biz bu tecrübeyi yaşadığımız için bunu paylaşmak istedim.
Tabiki bu işlem için öncelikle Active Directory ortamının buna hazır olması gerekmektedir. Bunun için benim elimde hali hazırda bir birleri arasında çift yönlü forest trust oluşturmuş iki domain bulunmaktadır.
Bu yapının nasıl oluşturulduğuna dair bilgi yukarıdaki makale serisinde anlatılmaktadır.
Peki, temel olarak trust işlemlerini tamamladık ise buna ek olarak dns için küçük bir GPO uygulamamız gerekmektedir. Malum şu anda bizim istemci makineler “ping hakan” dersek bunu otomatik olarak domain suffix nedeni ile “ping hakan.cozumpark.local” olarak algılayacaklardır. Peki, ben fileserver1 isimli bir makineye ulaşmak istediğim zaman ve bu makine hakanuzuner.com domaininde yani diğer forest içerisinde ise bu durumda
Ping fileserver1 dersem bu = ping fileserver1.cozumpark.local olacak ve buna bir karşılık bulamayacağız. Oysaki
Ping fileserver1.hakanuzuner.com olsaydı karşılık bulacaktır. İşte böyle durumlardaki sorunları çözmek için istemci makinelerin “suffix search list” değerine ek yapmamız gerekmektedir.
Varsayılan değeri görmek için bir istemci makinede aşağıdaki gibi ipconfig çalıştırmanız yeterlidir
Yukarıdaki şekilde “HuPC” isimli makinenin cozumpark.local domaininde olduğunu anlıyorum. Ve search listesinde sadece kendi domaini var.
Bende GPO ile aşağıdaki gibi bir değişiklik yapıyorum
Computer Config – Policies -> Administrative templates -> Network -> DNS Client
Bunun altındaki iki değeri değiştiriyoruz
1 – Primary DNS Suffix
Mevcut domain ismini yazıyoruz
2 – DNS Suffix Search List
Burada ise sırası ile ilk olarak kendi domain ismimizi ve bir virgül ile trust oluşturduğumuz domain ismini yazıyoruz.
Evet, bu işlemi de tamamladığımıza göre artık ADMT aracının kurulumuna geçebiliriz.
İlk olarak ADMT için bir kullanıcı hesabı oluşturmamız gerekmektedir. Bu aslında mevcut bir hesap ile de olur ancak her iki domain’ in güveneceği bir hesap olacağından yeniden oluşturmakta fayda var. Burada tavsiye edilen bu hesabı hedef domain yani kullanıcıları alacak domainde açmaktır. Bende öyle yapıyorum.
Bizim kaynak domain ismi; cozumpark.local
Hedef domain ismi ise; hakanuzuner.com
Şimdi hakanuzuner.com üzerinde bir kullanıcı yapacağım ve bu kullanıcıyı her iki domain içinde “Domain Admins” grubu üyesi olarak atayacağım.
Benzer şekilde cozumpark.local yani kaynak domain içinde yetkilendirme yapıyorum, ancak burası için domain admins grubu yerine built-in administrators grubu yeterlidir.
Her iki domain içinde gerekli yetkileri vermiş bulunuyorum.
Şimdi sıra geldi ADMT kurulumuna. Bunun için hakanuzuner.com domaini içerisinde üye bir makineye ihtiyacımız var. Bir üye makine buluyoruz ancak bu üye makine server 2012 olamıyor. Çünkü bu makaleyi yazdığım kasım ayı itibari ile en son sürüm olan admt 3.2 ve PES 3.1 ne yazık ki server 2012 desteklemiyor. Bu nedenle tavsiyem 2008 r2 bir Member makine bulmanızdır. Ek olarak DLF ve FFL da 2008 R2 olmalıdır. Eğer Server 2012 FFL ve DFL’ a sahipseniz aşağıdaki komut seti ile bunu düşürebilirsiniz.
Set-AdForestMode -identity cozumpark.com -forestmode Windows2008R2Forest
Set-AdDomainMode -identity cozumpark.com -domainmode Windows2008R2Domain
Not; Eper şifre taşıma işlemini de yapmak istiyorsanız bu durumda kaynak domain ortamında da bir 2008 R2 DC bulunmalı. Çünkü PES 3.1 de Server 2012 de çalışmıyor. Ancak eminim ki çok kısa bir süre içerisinde bu her iki programında yeni sürümü çıkacak ve sizler benim gibi takla atmak zorunda kalmayacaksınız J
Buna ek olarak “admt” hesabı ile kurulumları yapıyoruz. Kurulumlar için SQL gereksinimi olduğunu unutmayalım lütfen.
ADMT 3.2
http://www.microsoft.com/en-us/download/details.aspx?id=8377
SQL Server 2008 Express için ise aşağıdaki linki kullanabilirsiniz
http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=25052
Temel yüklemelerden biri olan .net ve benzeri gereksinimlerin tamam olduğunu düşünüyorum. SQL için her ne kadar kurulum adımlarını bildiğinizi düşünüyor olsam da hatırlatmakta fayda var J
Sadece Database Engine servisi bize yeterlidir
Instance olarak makine ismi yerine “SQLEXPRESS” seçiyorum ki bunu hatırlıyor olmanız gerekli, birazdan admt kurulumunda bizden sql server bilgisi istenirken instance bilgisi de istenecektir.
SQL için hesap olarak admt için açtığım hesabı kullanıyorum
Windows kimlik doğrulama yöntemi yeterli çünkü sadece admt için kurulum yapıyorum.
Evet, SQL kurulumundan sonra sıra geldi admt kurulumuna
ADMT için kurulum adımları aşağıdaki gibidir
Veri tabanı bilgisini giriyoruz.
Herhangi bir datamız yok 3.1 versiyonundan alınacak.
Kurulum tamamlandı.
Taşıma işlemi sırasında bir kullanıcı şifrelerini de alacağımız için ek bir araca daha ihtiyacımız bulunmaktadır.
Password Export Server version 3.1 x86
http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=10370
Password Export Server version 3.1 x64
http://www.microsoft.com/en-us/download/details.aspx?id=1838
Bu programı şifreleri alacağımız kaynak DC ye yüklüyoruz. Yani cozumpark.local içerisindeki herhangi bir DC ye. Ek olarak ADMT yüklü makine ile aralarında güvenli bir iletişim olması için bir şifreleme anahtarı oluşturmamız gerekmektedir. Bunu admt yüklü makinede aşağıdaki komutu çalıştırarak üretiyoruz
admt key /option:create /sourcedomain:cozumpark.local /keyfile:”c:\PESKey\PES.pes” /keypassword:Abcd1234
Şimdi bu key dosyasını PES kurulacak olan DC ye kopyalıyoruz ve kurulumu yapıyoruz. Bu işlemleri cozumpark domain admin grubu üyesi bir kullanıcı ile yapın.
PES anahtarının yolunu gösteriyoruz.
Anahtar şifresiniz giriyoruz, komut setindeki şifre yani Abcd1234
PES servis hesabının hangi active directory kullanıcı bilgisi ile çalışacağını belirliyoruz. Tavsiye edilen hedef domain kullanıcısıdır ki biz bunun için hali hazırda bir user tanımlamıştık.
Buraya kadar kullanıcı işlemleri için gerekli olan alt yapıyı sağlamış olduk, ancak sunucu ve istemci makinelerde agent yüklenmesi için ADMT kullanıcı hesabının local admin olması gerekmektedir. Bunu pek çok yöntemi olmak ile beraber ben GPO üzerinden yapmayı tercih ediyorum ve istemci makinemde hakanuzuner içerisindeki admt kullanıcısını önce cozumpark domain içerisindeki bir gruba ekliyorum ve daha sonra restricted group yardımı ile bu grubu bu gpo yu alan makinelerde local admin yapıyorum.
Grup işi tamam. Şimdi makineleri etkileyecek GPO oluşturuyorum
Şimdide restricted group uyguluyorum
Sonuç
Peki, bu aşamayı da atlatmış olduk. Makineler ile ilgili olan bir diğer gereksinim ise Windows Firewall. Aslında bu kapalıdır diye düşünüyorum malum pek çok yönetim ve iletişim sorununa sebep oluyor ancak hala bazı şirketler iç network de dahi makinelerde Windows firewall’ u açık bırakıyorlar. Malum port bazlı çalışmaya çalışıyorlar ancak günümüz gerçeği bu pek mümkün değil. Bundan daha çok segmentasyon dediğimiz istemci makine parkuru ile sunucu makine parkuru arasına fiziksel bir firewall koymak çok daha mantıklıdır. Neyse özetle eğer firewall açık ise gpo ile bunu kapatmanız gerekli.
Peki, temel taşıma işlemlerine başlamadan önce son hazırlığımız ise SID Filter ile ilgili olacak.
SID History ve SID Filter
Active Directory ortamında trust ilişkisi kurduğunuz iki domain arasında kullanıcı taşımak isteyebilirsiniz. Bunun temel sebebi eski ve yeni domainler arasında sadece kullanıcı değil başta kaynak olmak üzere grupları ve pek çok ortak kullanılan objeyi de taşıyacaksınızdır. Buradaki mantık eski bir domain’ den yeni bir domain’ e geçiş işlemini gerçekleştirmektir. Eğer böyle bir durum yok ise yani eski kaynakları taşımayacaksanız zaten yeni domainde kullanıcıları bir kez daha açabilirsiniz.
Ancak gerçek hayat senaryolarında mevcut bu kullanıcı bilgileri çok önemli olduğu için hatta 100 ve üzeri kullanıcınızın olduğunu düşünürseniz sadece onlara yeni şifre bilgilerini vermek bile ciddi bir iştir.
Bu nedenle böyle bir geçiş işleminde doğru olan mevcut kullanıcıyı şifresi ile taşımak olacaktır. Ancak taşınacak tek şey şifre değildir, SID’ de taşınabilmektedir. SID bildiğiniz gibi kullanıcılar için kimlik numaraları olup hangi kaynak üzerinde yetkileri olduğu hep bu SID ye bağlıdır. Yeni domain’ e taşınan bir kullanıcı yeni bir SID olacaktır. Bu çok doğal bir durumdur çünkü bildiğiniz gibi bir SID aşağıdaki gibi bir numaradır
S-1-5-21-1659004503-193565697-854245398-1002
ID numarasını farklı segmentlere bölebilirsiniz. Örneğin aşağıdaki gibi:
S-1-5-21-D1-D2-D3-RID
S-1-5 standart bir ön ektir. Burada 1 sürüm numarasıdır ve NT 3.1 versiyondan bu yana hiç değişmedi. 5 ise SID’ nin NT tarafından atandığını gösteren tanımlamadır. 21 yine bir NT ön ektir. D1,D2,D3 ise domain ’e özgü olan 32-bitlik tanımlayıcı numaradır. Bir domain kurulunca D1’den D3’e kadar olan numara otomatik oluşur ve aynı domain içerisindeki bütün objeler için bu D1,D2,D3 değerleri aynı olur. En sondaki RID, relative identifier‘ın kısaltmasıdır. Ve SID numarası içerisinde ait olduğu objeyi benzersiz kılan ve diğer objelerden ayıran numaradır. Her yeni hesap benzersiz bir RID numarasına sahiptir. Hatta eski kullanıcı ile aynı isim ve bilgiler kullanılsa bile RID her zaman farklıdır. Dolayısıyla, yeni açılan kullanıcının adı eski kullanıcı ile aynı olsa da RID numarası farklı olacağı için eski kullanıcının haklarını hiçbir şekilde kullanamayacaktır.
Durum böyle olunca SID çok önemli bir değer olup kullanıcı için eski kaynaklara erişimde hayati önem taşımaktadır. Bu nedenle böylesi kullanıcı taşıma işlemlerinde biz mutlaka objenin eski SID numarasını da yeni domaindeki objeye taşımak isteriz. Bunu yapmamız kullanıcı için yeni domainden gelen bir objectSID yanında eski domainden gelen bir SIDHistory değeri oluşur. Bunu aşağıdaki komut ile kontrol edebilirsiniz
dsquery * -filter “&(objectcategory=user)(samaccountname=hakan)” -attr objectsid
Yukarıdaki kullanıcı için SIDHistory yok, ancak makalenin ilerleyen bölümlerinde bunu görebileceğiz
Peki, SID taşımak için ne yapmak gerekli? Öncelikle SID Filter’ ı kapatmak gerekli.
External Trust için
Netdom trust TrustingDomainName /domain:TrustedDomainName /quarantine:No /usero:domainadministratorAcct /passwordo:domainadminpwd
TrustingDomain = Kaynakların Olduğu
TrustedDomain= Kullanıcıların Olduğu
Bu iki kavram için lütfen aşağıdaki makaleyi detaylıca okuyunuz, çünkü buradaki kullanıcıların olduğu manası kullanıcı taşınma işlemi noktasında yanlış bir anlamaya neden olabilir. Aslında kullanıcıları trusting yani kaynakları açan yerden ki kullanıcıda bir kaynaktır alacaksınız.
netdom trust DomainA /D:DomainB /UD:DomainB\Administrator /PD:* /UO:DomainA\Administrator /PO:* /Quarantine:No
2008 ve üstü için NO yerine N, YES yerine Y kullanıyoruz.
Forest Trust için ki benim yapımda forest trust olduğu için bu komutu çalıştıracağım.
Netdom trust trustingDomain /domain:trustedDomain /enableSIDhistory:yes /usero:domainadministratorAcct /passwordo:domainadminpwd
Benim komutum bu senaryoda aşağıdaki gibidir
Netdom trust cozumpark.local /domain:hakanuzuner.com /enableSIDhistory:yes /usero:administrator /passwordo:Password1
Komut başarılı bir şekilde çalıştı.
Evet buraya kadar tüm temel hazırlıkları tamamladık. Bundan sonra ise aslında grup, kullanıcı ve bilgisayar hesabı taşımam gerekli, ancak makalemin başında da dediğim gibi Hakan CAN hocamız bu bölümleri çok detaylı bir şekilde yazdığı için ben tekrar aynı işlemleri yapmayacağım.
Buraya kadar temelde 2008 R2 üzerinde anlatılan ADMT aracının 2012 domainlerinde de kullanılması için gerekli olan hazırlıklardan ve konu hakkındaki bir takım temel kavramlardan bahsettim.
Bundan sonrası için taşıma işlemlerinde hiçbir fark yok buna emin olabilirsiniz J Ben bizzat bu denemeleri gerçekleştirdim ve server 2012 ortamında da çalıştığınız gördüm.
Umarım faydalı bir makale olmuştur.
Bir sonraki makalemizde görüşmek üzere.
