Çoğu kurum kullanıcı kimliğini LDAP veya AD dizini üzerinde yönetir. Yeni bir uygulama devreye alındığında aynı soru tekrar ortaya çıkar: bu uygulama dizine nasıl bağlanacak, kullanıcıyı nasıl doğrulayacak, hangi grup bilgisini okuyacak ve erişim kararını nerede verecek? Eğer bu bağlantı her uygulamada ayrı ayrı yapılırsa, kimlik mimarisi hızla dağılır.
Uygulama başına LDAP entegrasyonu operasyonel borç üretir. Her uygulama kendi servis hesabını, bağlantı adresini, arama filtresini, timeout değerini ve sertifika doğrulama ayarını taşır. Dizin şeması değiştiğinde, OU yapısı taşındığında, servis hesabı parolası döndürüldüğünde veya domain migration yapıldığında bu değişiklik çok sayıda uygulamaya yayılır.
Güvenlik tarafında da risk büyür. Şifresiz LDAP kullanımı parolaların ağda korunmasız taşınmasına yol açabilir. Servis hesabı parolaları uygulama konfigürasyonlarında saklanır. Grup tabanlı yetkilendirme ise uygulamaların kendi koduna dağılır; kimlik doğrulama ve erişim politikası farklı sistemlerde farklı kurallarla uygulanır.
Denetim ve görünürlük de parçalanır. Hangi uygulama hangi servis hesabıyla dizine bağlandı, hangi kullanıcı doğrulandı, hangi grup sorgulandı, hangi erişim reddedildi bilgisi çoğu zaman uygulama loglarında gömülü kalır. SOC ve denetim ekipleri merkezi bir kimlik akışı yerine dağınık logları birleştirmek zorunda kalır.
TR7 LDAP / AD Bind bu problemi erişim platformunda çözer: direct-bind ve search-bind yöntemleri, LDAPS güvenli transport, grup üyeliği sorgusu, bind restriction filtresi, çoklu sunucu failover ve AAM koşullu erişim politikası tek mimaride birleşir.
TR7 AAM, LDAP/AD bağlantısını yalnızca parola doğrulama olarak değil; kullanıcı arama, grup sorgulama, güvenli transport ve erişim politikası üretme akışı olarak ele alır.
Direct-bind, kullanıcı adını UPN, NetBIOS, UID, CN veya özel desenle bind principal değerine dönüştürür. Search-bind ise servis hesabıyla kullanıcı DN bilgisini arar, ardından kullanıcının kendi parolasıyla bind doğrulaması yapar.
Search-bind modunda grup araması etkinleştirilebilir ve kullanıcının grup üyelikleri AAM oturumuna eklenir. Bu grup bilgisi, uygulama erişimi, MFA zorunluluğu veya kurum servisi bazlı yetki kararlarında kullanılabilir.
TR7, LDAPS üzerinden TLS korumalı bağlantı kurabilir. Sertifika doğrulama ve self-signed sertifika politikası yapılandırılarak dizin bağlantısının güvenlik seviyesi kurum standardına göre belirlenir.
Birden fazla LDAP/AD sunucusu tek konfigürasyon içinde tanımlanabilir. Roundrobin, weighted veya failover yöntemleriyle bağlantılar dağıtılır; birincil dizin sunucusu erişilemez olduğunda alternatif sunucu devreye alınabilir.
LDAP / AD Bind, kurumsal dizin doğrulamasını bind şablonları, arama filtreleri, grup üyeliği, güvenli transport ve çoklu sunucu yönetimiyle AAM akışına bağlar.
Direct-bind modunda kullanıcı adı UPN, NetBIOS, UID, CN veya custom şablonlardan biriyle bind principal değerine dönüştürülür. AD ortamlarında UPN ve NetBIOS formatları yaygındır; OpenLDAP veya POSIX dizinlerde UID ve CN desenleri daha uygun olabilir. Custom desen ile uid={{username}},ou=people,dc=company,dc=com gibi kuruma özel yapı kurulabilir. Bu esneklik, farklı dizin şemalarını tek AAM doğrulama akışına bağlamayı kolaylaştırır.
Search-bind modunda TR7 önce servis hesabıyla dizine bağlanır ve kullanıcı DN bilgisini arar. Kullanıcı bulunduğunda ikinci adımda kullanıcının kendi DN ve parolasıyla bind işlemi yapılır. Bu model kullanıcıların farklı OU'larda bulunduğu, DN bilgisinin kullanıcı adından doğrudan üretilemediği veya daha kontrollü arama filtresi gereken ortamlarda kullanışlıdır. Servis hesabı ve arama base DN bilgisi merkezi olarak yönetilir.
Search-bind filtresi otomatik modda userPrincipalName, sAMAccountName ve cn alanlarını birlikte değerlendirebilir. Custom modda operatör kendi LDAP filtresini tanımlar; örneğin (sAMAccountName={{username}}) gibi daha dar bir arama yapılabilir. Bu yaklaşım farklı dizin şemalarına ve kullanıcı adı formatlarına uyum sağlar. Yanlış kullanıcı eşleşmelerini azaltmak için filtre mümkün olduğunca net tanımlanmalıdır.
Kullanıcı parolası doğru olsa bile her dizin kullanıcısının her uygulamaya erişmesi istenmeyebilir. Bind restriction filter ile yalnızca belirli OU, grup veya attribute koşulunu karşılayan kullanıcıların doğrulama akışını geçmesi sağlanır. Örneğin yalnızca VPN Users grubundaki kullanıcılar belirli kurum servisine kabul edilebilir. Bu filtre, kimlik doğrulamayı erişim kapsamı ile birlikte değerlendirir.
ldapEnableGroupSearch aktif olduğunda TR7 kullanıcı DN değerini kullanarak grup üyeliklerini sorgulayabilir. ldapGroupSearchBase ve ldapGroupFilter ile hangi dizin bölgesinde ve hangi filtreyle grup aranacağı belirlenir. Dönen grup listesi AAM oturumuna eklenir. Koşullu erişim akışları bu grup bilgisine göre farklı uygulama, MFA, izin veya reddetme kararı verebilir.
LDAPS kullanıldığında LDAP bağlantısı TLS ile korunur ve tipik olarak 636 portu üzerinden çalışır. Sunucu sertifikası doğrulama davranışı sslValidateCertificate ve sslAllowSelfSigned gibi ayarlarla yapılandırılabilir. Üretim ortamında şifresiz LDAP tercih edilmemelidir. Dizin bağlantısının güvenliği, kullanıcı parolası ve servis hesabı gibi hassas verilerin korunması için temel gereksinimdir.
LDAP bağlantı ve işlem timeout değerleri yapılandırılabilir. Bağlantı kurulamazsa veya dizin sunucusu yavaş cevap verirse AAM akışı sonsuz beklemez. Yoğun saatlerde yavaş domain controller davranışı veya network segment gecikmesi bu değerlerle kontrol altına alınabilir. Timeout ayarları kullanıcı deneyimi ve failover davranışıyla birlikte planlanmalıdır.
TR7, belirli search base altında kullanıcıları çekerek mail ve telefon gibi attribute değerlerini AAM lokal kullanıcı profiline aktarabilir. queryMailField ve queryPhoneField gibi alanlar kurum şemasına göre ayarlanabilir. Bu özellik kullanıcı listesi ve iletişim bilgisi yönetiminde yardımcı olur. Cluster ortamında kullanıcı listesi çekimi yalnızca primary node üzerinde çalışacak şekilde sınırlandırılır.
hosts dizisinde birden fazla LDAP/AD sunucusu tanımlanabilir. lbMethod roundrobin, weighted veya failover olarak seçilebilir. Failover modunda birincil sunucu erişilemez olduğunda alternatif sunucuya geçiş yapılır. Bağlantı havuzu ve circuit breaker yaklaşımı sürekli başarısız olan sunucuların akışı bozmasını azaltır.
LDAP sunucusuna hangi network namespace üzerinden gidileceği yapılandırılabilir. Bu, ayrı segmentteki domain controller veya tenant'a özel dizin yapıları için önemlidir. Erişim yönetimi trafiği doğru route tablosu ve ağ izolasyonu üzerinden taşınır. Multi-tenant veya ayrıştırılmış veri merkezi mimarilerinde daha net ağ kontrolü sağlar.
LDAP / AD Bind; bağlantı yaşam döngüsü, filtre güvenliği, bağlantı temizliği, search-bind davranışı, cluster kısıtı ve attribute seçimiyle birlikte işletilir.
LDAP ayarları güncellendiğinde bağlantı bilgisi yeniden hazırlanır ve doğrulama akışı yeni ayarlarla çalışır. Bağlantı bilgisi protocol, host, port, TLS ve timeout parametrelerinden üretilir. Ayar değişikliklerinin merkezi yaşam döngüsü içinde uygulanması konfigürasyon tutarlılığı sağlar.
Kullanıcı girdileri LDAP filtresine yerleştirilmeden önce özel karakterler kaçırılır. Ters eğik çizgi, yıldız, parantez ve null karakter gibi değerler LDAP injection riskini azaltmak için escape edilir. Bu davranış özellikle custom filter kullanan yapılarda kritiktir.
LDAP bağlantısı kullanıldıktan sonra client temizlenir ve listener'lar kaldırılır. Bu yaklaşım zombie bağlantı ve gereksiz bellek kullanımını azaltır. Uzun süreli keep-alive davranışı yalnızca kullanıcı listesi çekimi gibi özel modlarda kullanılmalıdır.
Otomatik search-bind filtresi userPrincipalName, sAMAccountName ve cn alanlarını birlikte değerlendirebilir. Custom filtre modunda operatör kendi LDAP filtresini tanımlar. Custom filtre güçlüdür; ancak yanlış geniş filtreler beklenmeyen kullanıcı eşleşmelerine yol açabileceği için dikkatli tasarlanmalıdır.
Yeni nesil LDAP kurum servisi havuzu yapısı, LDAP istemci bağlantılarını havuz mantığıyla yönetebilir. LDAPS seçildiğinde TLS seçenekleri bağlantı kurulumuna eklenir. Özel DNS lookup süresi ve bağlantı timeout değerleri yavaş veya segmentli ağlarda önem kazanır.
Kullanıcı listesi çekimi cluster ortamında yalnızca primary node üzerinde çalışacak şekilde sınırlandırılır. Bu davranış aynı kullanıcı listesinin birden fazla düğüm tarafından eş zamanlı çekilmesini ve gereksiz yük üretmesini engeller. Authentication bind akışı ise tanımlı bağlantı modeline göre çalışmaya devam eder.
ldapAttributes dizisiyle dizinden hangi alanların döneceği belirlenir. Varsayılan alanlar dn, cn, userPrincipalName, displayName, mail ve telefon gibi değerleri kapsayabilir. department, employeeID veya özel attribute gibi ek alanlar kurum ihtiyacına göre listeye eklenebilir.
Büyük kurumda çalışanlar mevcut AD kullanıcı adı ve parolasıyla AAM üzerinden uygulamalara erişir. Grup üyelikleri AAM politikasına taşınır; finans, İK ve BT grupları farklı uygulama veya MFA akışlarına yönlendirilebilir. AD şifre politikası değiştiğinde uygulamalar tek tek güncellenmez.
İki veri merkezinde iki domain controller bulunan yapıda TR7 failover yöntemiyle bağlantı kurabilir. Birincil dizin sunucusu erişilemez olduğunda alternatif sunucuya geçilir. Kullanıcı doğrulama akışı tek DC arızasına bağlı kalmaz.
Belirli bir kurum servisi yalnızca VPN Users grubundaki kullanıcılara açılabilir. Bind başarılı olsa bile bindRestrictionFilter koşulunu geçmeyen kullanıcı reddedilir. Böylece parola doğrulama ile uygulama erişim yetkisi aynı şey kabul edilmez.
AD yerine OpenLDAP kullanan kurumlar UID veya CN bind şablonlarıyla kullanıcı doğrulaması yapabilir. posixAccount tabanlı dizinlerde mail, telefon ve özel attribute eşlemesi AAM profiline taşınabilir. LDAPS ile güvenli bağlantı kurularak klasik LDAP dizinleri modern erişim akışına dahil edilir.
LDAP/AD bağlantısı, grup tabanlı politika, LDAPS güvenli transport ve merkezi denetim tek platformda. Kendi ortamınızda canlı bir kurulumda gezdirelim.