Trust kavramı çok merak edilen bir kavram olmak ile beraber ancak büyük şirket yapılarında ihtiyaç duyulduğu için çok yaygın bir içerik bulmak oldukça zordur. Yapmış olduğum projeleri düşününce hali hazırda zaten trust ile ilgili bir işlem yapıyorsanız muhtemel bunun devamında kullanıcı ve posta kutusu taşımak veya ortak çalıştırmak gibi ihtiyaçlar olacaktır. Durum böyle olunca da uzman bir personel ile bu geçişler yapılmaktadır.
Ancak günümüzde her ne kadar bu tür kritik işler danışmanlık ile yapılıyor olsa da aslında neler yapıldığını veya yapılacak bu işlemlerin sizin işinize yarayıp yaramadığını bilmek gerekli.
Bende bu amaç ile birkaç bölünden oluşan bir Active Directory Güven İlişkileri (Trust Relationships) makalesi yazmaya karar verdim. Bu makalemin ilk bölümü olup temel anlamda Güven İlişkileri (Trust Relationships) konusunun ne olduğunu değineceğim.
Öncelikle bunca zaman neden ben böyle bir kavram duymadım diyebilirsiniz, bu aslında böyle bir ihtiyacınızın olmadığının da bir kanıtı olabilir. Bunu anlamanın en iyi yolu ise neden ortamımızda trust ilişkisine ihtiyaç duyarız onu bir öğrenelim.
Sahip olduğunuz şirket organizasyonunuz büyüklüğü, karmaşıklığı veya yine bunların birleşimi sonucu ortaya çıkan güvenlik tehditleri nedeni ile ortamınızı birden çok domain ile yönetmeye ihtiyaç duyabilirsiniz. Veya hali hazırda birbirinden bağımsız çalışan domainlerin kaynaklarının ortak bir çalışma amacı ile kullanılması ki buna en çarpıcı örnek firma evlilikleri gösterilebilir. Özetle ortak çalışma ihtiyacınızın olması durumunda domainlerin bir birine güvenmesi gereklidir, bunun içinde domainlerin arasında güven ilişkisi oluşturuyoruz.
Güven ilişkisinin temelinde iki domain yer almaktadır. Burada domainlerden biri veya her ikisi karşı tarafa güvenir ve kaynaklarını açar. Bu temele dayalı bir çalışma prensibi vardır. Bu oluşuma iki farklı açıdan bakabiliriz.
Yönetici gözünden
Yönetici gözünden trust ilişkileri bir den çok domain yapısının merkezi olarak yönetilmesi nedeni ile iş kazancı sağlayan bir çözümdür.
Kullanıcı gözünden
Kullanıcılar ise trust ilişkisi sayesinde domain ortamındaki ve bu domain’ e güvenen tüm domainlerdeki kaynakları kullanabilmektedir.
Aslında uygulama olarak güven ilişkisi kurmak son derece kolaydır. Asıl zor olan trust için kavramları anlamak ve bilmektir. Çünkü makalemin ilerleyen bölümlerinde de sizlerle paylaşacağım gibi çok basit birkaç tıklama ile güven ilişkisi kuracağız.
Peki, artık teknik terimler ile ilerleyelim.
Trust konusunu anlamak için öncelikle temel kavramlara hakim olmak gerekmektedir.
Temel olarak 3 kavramdan bahsedeceğiz.
Trust type
Transitivity
Direction
Trust Type
Temelde 6 çeşit güven ilişkisi kurabiliyoruz. Bunlardan ilk ikisi domain kurulumu ile gelen varsayılan trust tipleridir
Parent and child
Tree-root
Bunlara ek olarak biz sistem yöneticilerinin elle eklediğimiz diğer trust tipleri ise aşağıdaki gibidir.
External
Realm
Forest
Shortcut
Trust tiplerinden ilerleyen bölümde detaylı bahsedeceğim.
Şimdi gelelim bir sonraki kavramımıza, yön mevzusu!
Güven ilişkisi iki domain arasında gerçekleşmekte olup one-way veya two-way yani tek yönlü ve çift yönlü olmak üzere ikiye ayrılmaktadır.
Tek yönlü güven ilişkilerinde bir domain diğer domain’ e güvenir ve kaynaklarını açar ancak diğer domain kaynaklarını açmaz. Bu genel olarak şirket evliliklerinde büyük firma küçük firma ilişkisinde görülür. Örneğin ÇözümPark firması HakanUzuner firmasını sayın alırsa, hakanuzuner.com domain yapısı cozumpark.com domain yapısına güvenir ve kaynaklarını açar, cozumpark.com domain’ i hakanuzuner.com domaininden kaynakları kendi domain ortamına taşır ve sonra bu domain’ i siler veya saklar veya sadece güven ilişkisini bozar.
Ancak bundan farklı olarak büyük – küçük firma değil de ortak bir çalışma olacak ise bu durumda çift yönlü bir güven ilişkisi kurulur ki bu durumda her iki domainde birbirine güvenmektedir.
Daha teknik olarak bu iki domain için Güvenen (Trusting) ve Güvenilen (Trusted) Domainler şeklinde isimlendirme kullanırız.
Güvenen – Trusting Domain; kaynaklarını açan domaini temsil eder – Kaynaklar
Güvenilen – Trusted Domain; Kaynaklara erişim için kullanıcılarına güvenilen domaini temsil eder – Kullanıcılar
Evet, şimdi sıra son kavramımıza geldi, geçişlilik!
Buradaki mantık çok basit, eğer A domaini ile B domain’ i çift yönlü bir trust yapmış ise ve benzer şekilde B domaini ile C domaini çift taraflı bir trust yapmış ise, başka bir ifade ile A, B’ ye güveniyor, B, C’ ye güveniyor ise otomatik olarak A’ da C’ ye güvenir yani bu duruma geçişli trust deriz (transitive )
Burada aslında yapılan işlem trust ilişkisini genişletmektir. Yukarıdaki şekilde görüldüğü gibi tüm domainler bir birine güvenmektedir, aslında baktığınız zaman trust iki domain arasında yapılmakta olsa bile geçiş özelliği sayesinde tüm domainler bir birine güvenmektedir.
Ancak yukarıdaki şeklin bir diğer özelliği ise bu trust yapısının varsayılan olarak kurulması. Yani bir Forest içerisine siz domain ekledikçe ki bu child veya tree olabilir her şekilde otomatik olarak bir üst otorite ile bir alt otorite arasında tree – root veya parent – child trust otomatik oluşur.
Nontransitive trust, aslen tek yönlü trust tipleridir. Ancak çift yönlü trust tipleri de nontransitive olabilir. Eğer iki tane ayrı ayrı tek yönlü trust yaparsanız bunlar geçişsiz olur ancak ikisi birlikte aslında iki yönlü bir trust ilişkisi kurmuş olacaktır.
Bu şartlar altında nontransitive trust’ ın oluşması için sadece aşağıdaki iki durum söz konusu olabilir
1 – Windows Server 2005 bir domain ile NT 4.0 bir domain arasındaki trust
2 – Bir Forest içerisindeki Windows server 2003 bir domain ile başka bir Forest içerisindeki başka bir domain arasındaki trust ( iki Forest arasında Forest trust yoksa )
Bu konu için aşağıdaki şekilde son derece açıklayıcıdır.
Bu bilgiler ışığında trust tipleri için aşağıdaki gibi bir tablo yapabiliriz
|
Trust Type |
Transitivity |
Direction |
|
Parent and child |
Transitive |
Two-way |
|
Tree-root |
Transitive |
Two-way |
|
External |
Nontransitive |
One-way or two-way |
|
Realm |
Transitive or nontransitive |
One-way or two-way |
|
Forest |
Transitive |
One-way or two-way |
|
Shortcut |
Transitive |
One-way or two-way |
Bu bilgiler ışığında trust konusunun geçmişini de inceleyebiliriz.
NT 4.0 ve daha önceki işletim sistemi sürümlerinde trust konusunda bazı limitler vardı. Bunların başında oluşturduğunuz trust’ ın one-way ve nontransitive olmasıydı.
Yukarıdaki örnek NT domain ortamı için çizilmiş olup gördüğünüz gibi tek taraflı bir güven ilişkisi söz konusudur.
Windows Server 2000 ve sonrası için ise artık çift yönlü ve geçişli trust’ lardan söz edebiliriz
Peki, trust için hangi protokolü kullanıyoruz? Trust protocols varsayılan olarak Kerberos veya NTLM’ dir. Yani trust ilişkisi kurduktan sonra farklı domainler üzerindeki kaynaklara ulaşmak isteyen kullanıcılar kimlik doğrulamak için Kerberos veya NTLM kullanmaktadırlar.
Gelelim trust tiplerine
Parent Child Trust
Varsayılan olarak aynı Forest içerisine eklenen domainlerin arasında oluşan trust tipidir. Aşağıdaki şekli kontrol ettiğimiz zaman root domain ile onun child domaini arasında kurulduğunu görebiliriz. Bu otomatik olarak oluşan bir trust tipidir. Örneğin root domain ismi cozumpark.com olsun, buna siz bir child ekliyorsunuz ve bunun ismi de sozluk.cozumpark.com olsun. Bu child kurulumundan sonra hemen trust menüsünü kontrol ederseniz bu trust’ ın kendiliğinden oluştuğunu göreceksiniz.
Tree-root
Aslında trust tipleri için isimler son derece açıklayıcı, bu da yine varsayılan olarak oluşan bir trust tipidir ve bir Forest içerisindeki bir root domain’ in yanına eklenen bir tree ile arasında oluşan trust tipidir. Bunu da örneklemek gerekir ise, yine yukarıdaki şekli kullanabiliriz, Forest root domain cozumpark.com iken aynı Forest içerisine hakanuzuner.com isminde bir tree root domain kurarsak otomatik olarak cozumpark ve hakanuzuner domainleri bir birine güvenecektir. Ancak burada aklınıza şu gelebilir, peki bu güvenmek ne demek? Tabiki siz kaynaklarınız için izin vermediğiniz sürece izinsiz bir erişim mümkün değil. Olayı şöyle basit düşünebiliriz, sizin bir klasörünüz var ve buna hakanuzuner.com domainindeki kişilerinde erişmesini istiyorsunuz. Ancak trust yoksa eğer aşağıdaki gibi ACL menüsünde diğer domain’ i göremezsiniz.
Burada tek bir domain görünür, ancak tree olarak eklendikten sonra ise otomatik olarak bu alana gelir ve bu domain içerisindeki herhangi bir kullanıcı veya gruba kendi domain ortamınızdaki kaynaklar için erişim yetkisi verebilirsiniz.
External Trust
Kendi içinde bulunduğunuz Forest dışındaki bir domain ile one way veya two-way ve nontransitive olmak üzere external trust oluşturabilirsiniz. Buradaki temel amaç Forest-trust ilişkisi olan iki Forest arasında olsa bile hızlı bir şekilde iletişim kurmak için child domainlerin bir birleri arasında external trust kurulabilir. Yani diğer domain içerisindeki bir child domain’ e erişmek için önce kendi forestınız içerisindeki root domain, ardından diğer forest’ ın root domaini derken hedefe uzun bir yoldan gitmek yerine direkt bir external trust ile bu işi hızlandırabilirsiniz.
Realm Trust
Trust yapmak istediğiniz sistem bir Microsoft işletim sistemi değil ancak buna rağmen Kerberos v5 destekliyor ise bu şekildeki bir sistem ile yaptığınız trust tipine Realm trust denir ( örnek UNIX ve MIT )
Forest Trust
En çok duyduğunuz trust tipi olsa gerek diye düşünüyorum, çünkü özellikle şirket evliliklerinde veya domain taşınması, birleşmesi operasyonlarında illaki başvurduğumuz bir trust tipidir. Adında da anlaşılacağı gibi tüm Forest içerisindeki domainlerin karşılıklı olarak birbirlerine güvenmesini saplayan bir trust tipidir. Uygulamalı olarak değineceğim için daha fazla detaya girmiyorum.
Shortcut Trust
Sistem yöneticileri eğer karmaşık bir Forest – trust yapısına sahip ise kimlik doğrulama sürecini (authentication process ) iyileştirmek için gerekli olan yerlerde kısa yol güven ilişkileri oluşturabilirler. Örneğin Tree – Root veya Forest trust örnekleri düşünüldüğü zaman child ve benzeri alt taraftaki bir domain’ in diğer tree veya Forest içerisindeki bir alt domain’ e erişmesi için tüm domainleri geçmesi gerekecektir. Bunu hızlandırmak için sadece bu iki alt domain arasında bir kısa yol güven ilişkisi kurulabilir.
Yukarıdaki şekil incelendiği zaman Domain B ile Domain D arasında ve Domain D ile Domain 2 arasında shortcut trust yapılmıştır.
Evet, şimdi gelelim bu trust nasıl çalışıyor bölümüne?
İlk olarak trust oluşturduğumuz zaman ne olduğuna bakalım.
Biz bir trust oluşturduğumuz zaman aslında bir Active Directory içerisinde bir “trusted domain objects TDO” oluşturmuş oluyoruz. Bu obje tüm trust tipleri için temel bilgiler içerir. Yani hangi tip trust yaparsanız yapın ( forest trust, external trust, realm trust vs ) bu obje active directory veri tabanı içerisinde oluşturulur ve gerektiğinde bilgiler bu obje içerisinden çekilir. Bu bilgiler trust tipleri, trust’ un geçişli olup olmadığı gibi temel bilgilerdir. Bu obje her domain’ in System OU’ su altında yer almaktadır.
Temel olarak bu objenin içerdiği bazı bilgiler ve açıklamaları aşağıdaki gibidir.
trustType: Oluşturduğunuz trust tipi hakkında bilgi içerir.
trustPartner – Active Directory domainleri ile yapılan trust için partner’ ın DNS isim bilgisini içerir. Eğer karşı taraf NT Domain seviyesinde ise bu karşı domain için domain’ in netbios bilgisini verir. Microsoft olmayan domainler ile yapılan güven ilişkisinde ise bu partner’ ın Kerberos realm ismidir.
flatName – Active Directory domainleri ile yapılan trust için partner domain’ in netbios name bilgisi. Windows olmayan domainler için ise partner domain ismi veya boş olur.
trustDirection: Aldığı değerlere göre trust yönü hakkında bilgi içerir.
0 = disabled, 1 = incoming (i.e., trusting domain), 2 = outgoing (i.e., trusted domain), 3 = both directions.
trustAttributes: Windows 2000 ve 2003 için ayrı değerler alır. Ben sadece 2003 değerlerini paylaşıyorum.
Eğer değer 1 ise bu trust nontransitive, 8 ise forest trust, 10 ise cross-organization trust yani selective authentication kullanılmış. 20 ise eğer forest içerisinde kurulmuş bir trust’ tır. vb.
Trust mimarisinin temelinde kimlik doğrulama yatmaktadır, ancak bunun nasıl gerçekleştiği aynı forest veya farklı forest içerisindeki kaynaklara ulaşırken bazı farklılıklar göstermektedir.
Aşağıda örnek bir senaryo yer almaktadır.
Gördüğünüz gibi tek bir forest içerisinde bir root domain ve altında iki child domain bulunmaktadır. Böyle bir mimaride bu ana kadar öğrendiğimiz bilgilerin ışığında elle bir trust oluşturmamıza gerek olmadığını biliyoruz. Çünkü hatırlarsanız aynı forest içerisinde domain ekledikçe tree – root veya parent – child trust objeleri kendiliğinden oluşuyordu.
Peki bizim trust yapımız hazır, child1 içerisindeki user1 isimli bir kullanıcı, child2 içerisindeki Fileserver1 isimli bir sunucu üzerindeki share klasörüne erişmek istiyor.
BU süreçten önce size tavsiyem Kerberos kimlik doğrulama protokolü nasıl çalışır bunu bir hatırlamakta fayda var. Aksi halde çok fazla terim kafa karıştırıcı olabilir
http://sozluk.cozumpark.com/goster.aspx?id=213&kelime=Kerberos
User1 kullanıcısı Workstation1 isimli makinede “child1.microsoft.com” domain bilgisi ile logon olur. Tabiki bu süreçte DC üzerinde çalışan KDC kullanıcıya bir ticket-granting ticket (TGT) verir. Bu bileti alan User1 FileServer1 üzerindeki bir paylaşıma erişmek istemektedir. Bu nedenle workstation1 makinesi child1 içerisindeki KDC ye giderek FileServer1 SPN’ i için bir service ticket talep eder. Ancak child1 kendi ad veri tabanında böyle bir SPN’ nin bulunmadığını görünce hemen Global Catalog’ a bir sorgu gönderir ve GC’ da ona geri dönüş yapar. BU dönüş içerisinde hedefe nasıl gideceğine dair bilgi yer almaktadır. Bu bilgiyi alan child1 dc bu bilgiyi workstation1 makinesine verir, bu bilgide ilk olarak root domain’ e erişmesi gerektiği bilgisi yer almaktaydı. Root domain’ e erişen workstation1 makinesi buradan da child2.microsoft.com domaini içerisindeki dc ye gitmesi gerektiğini öğrenir ( işte bu tür bir senaryo için external veya shortcut trust yapılır ki kimlik doğrulama süreçleri iyileşsin ). Son olarak child2.microsoft.com domaini içerisindeki DC ye giden workstation1 makinesi bu dc üzerinde çalışan KDC sayesinde artık kendisini doğrulayarak bir servis bileti alır ve bu bileti fileserver1 e vererek dosyaya erişir.
Süreç bu şekilde çalışmaktadır.
Evet artık sistemin nasıl çalıştığını da biliyoruz ancak hala kurulumlara geçmek için öğrenmemiz gereken birkaç terim daha bulunmaktadır.
Makalemin ikinci bölümünde aşağıdaki konulara değineceğim. Üçüncü bölümünde ise demo ortamındaki kurulumları yapacağım ki burada name suffix routing olayına detaylı gireceğim.
Bir sonraki makalemde görüşme dileği ile.
Resimler için kullandığım kaynaklar
Microsoft Technet
Makalemin bir sonraki bölümü için aşağıdaki linki kullanabilirsiniz;