Active Directory Trust Relationships – Bölüm 2 SID filtering Selective authentication ve Name suffix routing Kavramları
Makalemizin ilk bölümünde temel kavramlar ve trust’ ın çalışma modeli hakkında bilgi vermiştim. Bu bölümde ise aşağıdaki temel kavramları işleyeceğim
Makalemin ilk bölümü için aşağıdaki linki kullanabilirsiniz;
SID filtering
Selective authentication
Name suffix routing
SID Filtering
SID bildiğiniz gibi kullanıcıların kimlik numaraları olarak isimlendirdiğimiz benzersiz bir numaradır. Buna ek olarak bir kullanıcının üye olduğu group SID numarası da benzer şekilde büyük önem taşımaktadır. Örneğin Domain Users grup üyesi bir kullanıcı ile Domain Admins grup üyesi bir kullanıcı aynı haklara sahip değildir.
SID Filtering özelliği de tam burada devreye giriyor. Trusted Domain yani daha kolay hatırlamak için makalemin ilk bölümünde “Kullanıcılar” olarak isimlendirdiğimiz güvenilen domain içerisindeki yönetici hakların sahip ancak kötü niyetli kişilerin kendilerine veya yine trusted domain içerisindeki başka kişilere izin verilenden daha fazla yetki vermesini engellemektedir.
Authentication
Bir external trust veya forest trust yapmanız halinde kimlik doğrulama noktasındaki çerçeveyi belirleyebilirsiniz ( authentication scope ).
Burada temel iki kimlik doğrulama scope tanımı yapabiliyoruz
Selective Authentication
Domain-wide authentication ( external trust için ) veya forest-wide authentication ( forest trust için )
Yani trust yaparken bu iki kimlik doğrulama çerçevesinden birini seçmeliyiz.
Eğer domain-wide veya forest-wide authentication seçilir ise, bu durumda trusted domain içerisindeki tüm kullanıcı, group ve bilgisayar hesapları, Trusting domain içerisindeki kaynak ve servislerde kimlik doğrulayabilir. Bu durumda siz sistem yöneticisi olarak çok iyi bir güvenlik analizi yapıyor olmalısınız. Aslında trust oluşturmak tüm kaynakları açmak olarak algılansa da aslında öyle değildir. Örneğin A ve B domainleri forest trust ile iki forest’ ı birleştiren bir yapı kurmuş olsun. Bu durumda gerek A gerekse B domaini içerisindeki Sharepoint, exchange, file server vb pek çok yer için siz karşılıklı olarak ACL içerisinden izin vermediğiniz sürece herhangi bir erişim söz konusu değildir. Bu durumda bu trust ne işe yaradı derseniz? Trust sizin ACL üzerinden diğer domaini görmenizi ve izin vermenize yardımcı olur.
Ancak burada unutulmaması gereken çok önemli bir nokta var. Siz eğer bir trust authentication scope seçiminde domain veya forest-wide seçerseniz bu durumda aslında düşündüğünüz şey başınıza kısmı olarak gelmiş olur. Nasıl? Sonuç olarak yeni kurulmuş bir domain ve yine domain içerisine alınan her makinede “Authenticated Users” denilen bir group için Read hakkı vardır, bu da şu demek oluyor, siz trust yaptığınız ancak aslında diğer domaindeki herkes sizin bu kaynaklarınıza erişebilir. Dahası eğer siz bu konuda çok bilinçli bir izin politikası izlememiş ve ortak alanlar, file server ve benzeri yerlerde Authenticated Users kullanıcısına daha fazla yetki vermişseniz bu durumda ciddi sıkıntılar yaşayabilirsiniz.
Bu tür sorunları ortadan kaldırmak istiyorsanız “Selective Authentication” yöntemini tercih edebilirsiniz.
Bu yöntemde ise trusted domain içerisindeki tüm kullanıcılar güvenilirdir ancak bu kullanıcıların Trusting yani kaynakları barındıran domain içerisindeki erişebileceği bilgisayarları biz seçebiliyoruz. Örneğin bir partner firma ile external trust yaptınız. Ancak sizin isteğiniz partner olan firmanın sahip olduğunuz pek çok file server’ dan sadece birkaç tanesine veya sadece bir tanesine ulaşmak istiyorsanız o makine için izin verebilirsiniz.
Bunu aşağıdaki şekilde yapabilirsiniz
Burada Trusting domain wingtiptoys.com yani kaynakları paylaşan, örnek file server bu domain içerisinde. Trusted domain ise tailspintoys.com yani kullanıcılarına güvenilen domain de diyebiliriz. Yukarıdaki şekilde de gördüğünüz gibi birden çok fileserver olmasına karşın sadece fileserver1 makine hesabı üzerine gelerek Security sekmesinden ACL listesine trusted domain içerisinden sadece erişmesini istediğiniz kullanıcıları veya grubu seçebilirsiniz.
Bu tabiki çok daha güvenli bir trust yöntemi olmak ile beraber her kaynak için tek tek vermek gerektiğinden biraz zahmetlidir.
Gelelim 3 kavramımız olan Name Suffix Routing konusuna.
Temel olarak kimlik doğrulama isteklerini yönlendirme için kullanılan bir sistemdir. Bu sistemi daha iyi anlamak için örnekleme yapmak istiyorum.
Temelde aşağıdaki gibi 3 forest ve 4 domainden oluşan bir yapımız olsun.
Görüldüğü gibi Forest1 içerisinde “cozumpark.com” domaini, Forest2 içerisinde “sozluk.cozumpark.com” domaini, forest3 içerisinde ise “ik.cozumpark.com” domaini ve onun child domaini olan “kurumsal.ik.cozumpark.com” domaini yer almaktadır.
Bu yapıda Forest1 ile Forest2 arasında bir çift yönlü forest trust bulunmaktadır. Forest2 ile Forst3 içerisindeki child domain arasında ise bir tek yönlü bir external trust bulunmaktadır. Bu yapıda yine makalemizin önceki bölümlerinde okuduğunuz gibi Forest2 içerisindeki kullanıcılar Forest3 ve Forest1 içerisindeki kaynaklara rahatlıkla ( izinleri çerçevesinde ) ulaşabilmektedir. Bunun temel sebebi ise name suffix routing yani hedef domain yapısına ulaşmak için hangi yolu kullanacağımızı bize öğreten alt yapıdır. Malum makalemizin birinci bölümünü hatırlarsak eğer aşağıdaki gibi User1 kullanıcısı FileServer1 sunucusuna ulaşmak için izlediği yolu Global Catalog yardımı ile bulmuştu. İşte burada aslında bu bilginin temelinde yatan konuya da değinmiş oluyoruz.
Buraya kadar sorunsuz çalışan yapımızda aşağıdaki gibi bir değişiklik yapıyoruz.
Baktığınız zaman yaptığımız değişiklik; Forest1 ile Forest3 arasına yeni bir çift yönlü forest trust atmamız olmuştur. Ancak bu değişiklikten sonra bir takım kimlik doğrulama sorunlarını aşağıdaki gibi loğlardan tespit edebiliriz.
Event Type: Warning
Event Source: LSASRV
Event Category: SPNEGO (Negotiator)
Event ID: 40960
Bunun temel sebebi bir yeni bir trust oluşturduğumuz zaman otomatik olarak eklenen name suffix routing’ dir.
İlk durumdaki route’ larımız aşağıdaki gibidir.
Yani Forest2 içerisindeki bir kişi cozumpark.com’ a erişmek için Forest Trust’ ı kullanması gerektiğini biliyordu. İkinci trust’ ı ekleyince ise name suffix routing aşağıdaki gibi oluşmuştur.
Şekilde görüldüğü gibi ik.cozumpark.com domain yapısı, sozluk.cozumpark.com’ a erişmek için kimlik doğrulama sürecini cozumpark.com forest’ ına gönderir. Ancak dikkat ederseniz isim benzerliği olmasına karşın farklı forest’ lardan bahsediyoruz. Bu nedenle sozluk.cozumpark.com için gönderilen kimlik doğrulama süreci cozumpark.com domaininden başarısız olarak geri dönecektir.
Bunun çözmek için ise name suffix route yapımıza Exclusions eklemek olacaktır.
Forest2 içerisindeki trust özelliklerine gelecek *.cozumpark.com name suffix route için “ik.cozumpark.com” domain’ i harici tutuyoruz.
Benzer şekilde Forest3 içerisinde de yine *.cozumpark.com name suffix route üzerinde “sozluk.cozumpark.com” domain’ i hariç tutarak sorunu çözmüş oluyoruz.
Özetle bu ve benzeri kimlik doğrulama sorunları veya sorun olmasa bile iyileştirmelerini name suffix route ile yönetebiliyoruz.
Evet bu bölümde de önemli olan kavramların anlaşılması noktasında bilgilerimi paylaştım.
Makalemin 3 bölümünde ise sizler ile artık bu ana kadar paylaştığım teorik bilgilerin nasıl güncel hayat senaryolarında pratiğe dönüştüğünü anlatacağım.
Makalemin bir sonraki bölümü için aşağıdaki linki kullanabilirsiniz.
Umarım faydalı bir makale olmuştur.
Bir sonraki makalemde görüşmek üzere
Resimler için kullandığım kaynaklar
Microsoft Technet
