Bölüm 10: LDAP / Active Directory Entegrasyonu¶

LDAP Entegrasyonuna Genel Bakış¶

Kurumsal ortamlarda kullanıcı yönetimini yerel hesaplarla sınırlı tutmak genellikle yeterli olmaz. Bu nedenle Arceris, LDAP / Active Directory ile entegre çalışarak merkezi kimlik modeline uyum sağlayabilir.

Bu entegrasyonun amacı yalnızca kullanıcı doğrulamak değil; aynı zamanda kurumsal kimlik yapısını ürünün erişim ve yönetim modeline taşımaktır. İçe aktarılan LDAP grupları, Access Management'taki kuralların ve kurumsal PAC profillerinin hedeflerine, giriş kapısına girdi olur; dizin ayrıca Kerberos ile makine ve kullanıcı kaydının da dayanağıdır (aşağıda).

LDAP Bağlantı Ayarları¶

LDAP entegrasyonu, Identity sayfasındaki Active Directory / LDAP sekmesinden yapılandırılır. Sayfanın sağ üstündeki toggle ile LDAP entegrasyonu etkinleştirilir veya devre dışı bırakılır. Ayarlar dört bölümden oluşur:

Bağlantı:

Sunucu URL: LDAP sunucusunun adresini belirtir. İki protokol seçeneği vardır (ön ek arayüzden seçilir):
ldap:// — Port 389 üzerinden bağlanır. Bağlantı kurulduktan sonra STARTTLS yükseltmesi denenir.
ldaps:// — Port 636 üzerinden baştan TLS ile bağlanır.
Sunucu adresi dc.corp.com:389 biçiminde girilir.
DNS Sunucusu: Arceris konteynerinin LDAP sunucu adını çözümlemek için kullandığı DNS adresidir; host DNS ayarlarından bağımsızdır (örn. 192.168.9.100). Boş bırakılırsa sistem DNS'i kullanılır. Bu tercih edilen yöntemdir — URL'deki FQDN korunduğu için LDAPS sertifika doğrulaması bozulmaz.
Sunucu IP: DNS'e hiç erişilemiyorsa son çaredir: bağlantı doğrudan bu IP'ye kurulur, sertifika yine URL'deki isme göre doğrulanır — TLS hataları bu alandan kaynaklanmaz. Mümkünse DNS Sunucusu alanı tercih edilmelidir.
TLS Doğrulamasını Atla: TLS sertifika doğrulamasını atlar. Yalnızca geliştirme ve test ortamlarında kullanılmalıdır. Üretimde kapalı bırakılmalıdır; kurumsal kök CA yüklenerek bu seçeneğe gerek kalmaz (bkz. aşağı).

Servis Hesabı:

Bind DN: LDAP dizininde arama yapmak için kullanılan servis hesabının tam distinguished name (DN) değeridir. Örnek: cn=svc-arceris,ou=ServiceAccounts,dc=corp,dc=com. Bu hesap son kullanıcı hesabı değil; sınırlı, salt okunur erişimle tanımlanmış bir entegrasyon hesabı olmalıdır.
Bind Parolası: Servis hesabının parolasıdır. Daha önce kaydedilmişse alan *** olarak gösterilir; değiştirmek için yeni parola girilir. Göz simgesi girilen değeri geçici olarak görünümler.

Dizin:

Base DN: Kullanıcı aramalarının başlangıç noktasıdır. Örnek: ou=Users,dc=corp,dc=com. Tüm kullanıcı sorguları bu kök altında gerçekleştirilir. Grup aramaları da Grup Arama Base DN belirtilmedikçe bu DN'yi kullanır.
Kullanıcı Giriş Arama Filtresi: Kullanıcı girişi sırasında dizinde kullanıcıyı bulmak için kullanılan LDAP filtresidir. %s yer tutucusu girilen kullanıcı adı ile değiştirilir. Active Directory için tipik değer: (sAMAccountName=%s). Aynı filtre, Access Management'taki kullanıcı ön-hazırlama aramasında da kullanılır (aşağıda).
Grup Arama Base DN: Grup aramaları için ayrı bir arama kökü belirtir. Örnek: ou=Groups,dc=corp,dc=com. Boş bırakılırsa Base DN kullanılır.
Grup İçe Aktarma Arama Filtresi: Access Management içinde LDAP grubu aranırken kullanılan filtre. %s yer tutucusu yazılan sorgu ile değiştirilir. Tipik değer: (cn=%s).
İçe Aktarılan Grup Görünen Öznitelik: İçe aktarılan grupların arayüzde hangi LDAP niteliğiyle etiketleneceğini belirler. Varsayılan: cn. Saklanan kimlik her zaman grubun DN'idir; bu alan yalnızca görünen adı etkiler.
Kullanıcı Üyelik Özniteliği: Kullanıcının ait olduğu grup DN'lerini barındıran çok değerli (multi-value) niteliktir. Active Directory için varsayılan: memberOf. Giriş izin kontrolleri bu nitelikteki DN'leri içeri aktarılmış LDAP grup hedefleriyle karşılaştırır.

Rol Eşleme:

Grup → Rol Haritası (JSON): LDAP grup DN'lerini Arceris rollerine eşleyen JSON nesnesidir. Kullanılabilir roller: admin, developer, auditor, user. Eşleşme bulamayan kullanıcılar varsayılan olarak user rolünü alır. Örnek:
```
{
  "CN=AI-Admins,OU=Groups,DC=corp,DC=com": "admin",
  "CN=AI-Developers,OU=Groups,DC=corp,DC=com": "developer",
  "CN=AI-Viewers,OU=Groups,DC=corp,DC=com": "user"
}
```

Sekmenin altındaki Bağlantıyı Test Et düğmesi, Sunucu URL ve Bind DN girilmeden etkinleşmez; servis hesabıyla bağlanıp dizin sorgusunun sonucunu başarı ya da hata bandıyla gösterir. Kaydet & Uygula ile kaydedilen tüm değişiklikler Arceris'i yeniden başlatmaya gerek olmadan anında etkili olur.

Sekmenin üstünde iki bilgi kutusu bulunur: ilki bağlantı akışını özetler (Arceris bir servis hesabıyla bağlanır, kullanıcıyı arar ve parolayı doğrulamak için kullanıcı DN'iyle yeniden bağlanır); ikincisi, geçerli LDAP kimlik bilgilerinin tek başına giriş için yeterli olmadığını anımsatır (bkz. "LDAP Grup Bazlı Giriş Kısıtları").

LDAPS ve Kurumsal Kök Sertifikalar¶

ldaps:// bağlantıları, Settings → Trusted Root CAs altında yüklenen kurumsal kök/ara CA havuzunu kullanarak doğrulanır (Bölüm 6). İç PKI'nız tarafından verilen LDAPS sertifikaları için kurumsal kök sertifikayı bir kez yüklemek yeterlidir; havuz sistem köklerine ek olarak çalışır, yüklemeyi izleyen bağlantılara anında uygulanır ve "TLS Doğrulamasını Atla" seçeneğine gerek bırakmaz.

Servis Hesabı Doğrulaması¶

LDAP entegrasyonunda kullanılan servis hesabı, ürünün dizin içinde sorgu yapabilmesini sağlar. Bu hesap son kullanıcı hesabı değil; kontrollü, sınırlı amaçlı bir entegrasyon hesabı olarak düşünülmelidir.

Operasyon ekipleri bu hesabın izin kapsamını mümkün olduğunca dar ve güvenli tutmalıdır.

Kullanıcı Arama ve Grup Eşleme Mantığı¶

LDAP entegrasyonunun asıl değeri, kullanıcıyı yalnızca bulmak değil; aynı zamanda kurumsal grup ve rol bağlamını ürün tarafına taşıyabilmektir. Böylece kurumun mevcut dizin yapısı, Arceris içindeki yönetim ve erişim kararlarının temel girdilerinden biri haline gelir.

Kullanıcı adı ve parola girildiğinde akış şu şekilde işler:

Arceris, servis hesabıyla (Bind DN) dizine bağlanır.
Kullanıcı, Kullanıcı Giriş Arama Filtresi ile aranır ve DN'i bulunur.
Parola, bu DN ile dizine yeniden bağlanılarak doğrulanır; parola ürün tarafında saklanmaz.
Kullanıcı Üyelik Özniteliği'ndeki grup DN'leri okunur ve içeri aktarılmış LDAP grup hedefleriyle karşılaştırılır.
Rol, Grup → Rol Haritası'ndaki eşleşmeden belirlenir; eşleşme yoksa varsayılan user rolü atanır.

Bu yapı özellikle büyük kurumsal ortamlarda manuel kullanıcı yönetimi ihtiyacını ciddi ölçüde azaltır.

LDAP Kullanıcılarının İlk Oturum Davranışı¶

LDAP kullanıcısı ilk girişinde ürün tarafında görünür, yönetilebilir ve politika uygulanabilir bir kullanıcı kaydına dönüşür: rolü grup eşlemesinden, grupları dizinden gelir ve giriş kapısı koşulu uygulanır.

Kural atamak için ilk girişi beklemek gerekmez: Access Management'taki LDAP Kullanıcısı Ekle eylemi, dizinde arama yapıp kullanıcıyı önceden hazırlar; böylece kullanıcı henüz hiç giriş yapmamışken ona kullanıcı hedefli kurallar atanabilir (Bölüm 11). Arama, Kullanıcı Giriş Arama Filtresi ile yapılır.

LDAP Grup Import Süreci¶

Access Management içinde kullanılacak LDAP grup hedefleri, ürünün dizin yapısı ile hedef bazlı erişim modeli arasında köprü kurar. Bu nedenle grup import yaklaşımı, yalnızca dizin bilgisini göstermek değil; operasyonel hedef oluşturmak için kullanılır. Bu yapı, kullanıcılar sisteme giriş yapmadan önce bile grup bazlı politika hazırlığı yapılabilmesini sağlar.

İki davranış operasyonel olarak önemlidir:

Virgüllü DN'ler bölünmez. Kurumsal PAC profillerinde grup hedefi, LDAP DN'ini bütün olarak tek satırda taşır — virgül adın parçasıdır. Eski sürümlerde panel DN'i virgüllerinden böldüğü için profil "hiçbir cihaza uygulanmaz" sonucu alabiliyordu; bilinmeyen, bölünmüş ya da yazımı farklı grup değerleri artık doğru yazımı adlandıran bir uyarıyla gösterilir ve kaydetme reddedilmez. Grup hedefi alanı, içeri aktarılmış LDAP gruplarında arama yaparak doldurulabilir (Bölüm 6).
Grup eşleşmesi yazım farklarına duyarsızdır. Anahtar kasası (provider key) grup atamaları, kullanıcı gruplarını artık baştaki/sondaki boşluklardan arınmış ve BÜYÜK/küçük harf duyarsız biçimde eşler. Yükseltmeden önce yalnızca yazım farkıyla kimseye ulaşmayan atamalar uygulanmaya başlar; açılış günlüğü bu atamaları tek tek adlandırır.

LDAP Grup Bazlı Giriş Kısıtları¶

Bazı kurumlar için yalnızca başarılı LDAP doğrulaması yeterli değildir. Kullanıcının belirli kurumsal gruplara ait olması da erişim kararı için zorunlu olabilir.

Giriş için Access Management ataması zorunlu ayarı (Settings → Runtime; varsayılan AÇIK, Bölüm 6) açıkken geçerli LDAP kimlik bilgileri tek başına giriş yapmaz: kullanıcının bir Access Management ataması (kullanıcı, rol veya IP) ya da içeri aktarılmış bir LDAP grubuna üyeliği olması gerekir.

Yerel grup üyeliği yalnız belirli koşullardan geliyorsa girişe izin verir: üyelik kullanıcı veya LDAP grubu koşulundan geliyorsa geçerlidir; yalnızca IP koşuluyla üye olan kullanıcılar bu grup sayesinde LDAP girişi yapamaz (yerel grupların tanımı Bölüm 11'de).

İki sınıra dikkat:

Varsayılan rol user olduğundan, user rolüne yapılan herhangi bir atama fiilen tüm dizin kullanıcılarına giriş izni verir.
Yönetim (admin) düzlemi erişimi bu ayardan bağımsız olarak her zaman atama gerektirir; ayar kapalıyken de geçerlidir.

local: öneki rezervedir: LDAP (ve OIDC, FortiGate FSSO) gibi kimlik kaynaklarından local: ile gelen grup değerleri soyulur ve günlüğe yazılır; bu öneki taşıyan değeri saklamak isteyen yönetici formları reddedilir. Böylece dizinden gelen bir grup değeri, bir yerel grubun kurallarını kendisine claim edemez (Bölüm 11).

Grup ve Bölüm Hedefli Kuralların Kapsamı¶

LDAP grubuna veya bölüme (department) atanmış kurallar artık yerel LLM proxy'sinde (/local/) de uygulanır: Model Access izni ile PII, System Prompt ve konu sınıflandırıcı bağlamaları, Prompt Guard, DLP ve içerik moderasyonu kuralları grup veya bölüm hedefliyken eskiden yalnızca birleşik gateway'de çalışıyor, /local/ üzerinde sessizce hiç uygulanmıyordu.

Davranış değişikliği — aynı boşluk grup hedefli DENY kurallarını, gruba bağlı DLP / moderasyon / Prompt Guard kurallarını, daha sıkı grup PII bağlamalarını ve LDAP grubu hariç tutmalı yerel grupları da sessizce atlatıyordu. Yükseltmeden sonra bazı /local/ kullanıcıları daha önce reddedilmediği ya da taranmadığı yerde reddedilebilir veya taranabilir; kullanıcı ve rol hedefli kurallar değişmedi. Yükseltme sonrası grup hedefli atamalar (Bölüm 11) bu etki açısından gözden geçirilmelidir.

Kerberos ile Makine ve Kullanıcı Kaydı¶

Kimlik doğrulamanın Kerberos tarafı Bölüm 9'da, kayıt sonrası görünürlük ve yönetim Bölüm 13'te, kurulum adımları Bölüm 24'te anlatılır. Dizini ilgilendiren taraf burada özetlenir:

Makine kaydı. Domaine katılmış makineler, AD bilgisayar hesabının (HOST$) makineye özgü kimliğiyle, kullanıcı kimliğinden ayrı bir düzlemde kaydolur; kullanıcı token'ı asla makine kaydı için kullanılmaz. Bir bilgisayar hesabı sahibi olmadığı bir makineyi sahiplendiğinde, Makineler sayfasındaki satırdan Kimliği sıfırla ile makine kimliği temizlenir ve kimlik bilgileri iptal edilir; hostname, donanım ipucu ve makinedeki kullanıcı cihazları korunur. İptalden farklı olarak gerçek makine hemen yeniden kaydolabilir — önce sahte hesabın AD'de devre dışı bırakılması, sonra gerçek makineye kurulum token'ı verilmesi gerekir (Bölüm 13).
Sessiz kullanıcı kaydı. Oturum açmış domain kullanıcısı, elindeki Kerberos biletiyle pencere veya soru göstermeden kaydolur. Bu davranış Settings → Runtime altındaki sessiz kayıt anahtarıyla sunucu tarafından kapatılabilir (varsayılan AÇIK; elle çalıştırılan arceris-dev setup --kerberos bundan etkilenmez). Kayıt, makine + Arceris kullanıcısı başına tek OS hesabıyla sınırlıdır: aynı kullanıcının kaydını bu makinede başka bir OS hesabı tutuyorsa kayıt kararlı bir redd koduyla (os_user_conflict, 409) geri çevrilir ve Makineler sayfasında oturum bazında görünür (Bölüm 13).

Captive Portal ve LDAP Birlikte Çalışma¶

Transparent kullanım senaryolarında captive portal ile LDAP entegrasyonunun birlikte tutarlı çalışması önemlidir. Kullanıcının normal giriş akışı ile captive erişim akışı arasında farklı davranış görmesi operasyonel karmaşa yaratır.

Bu nedenle kurumlar captive portal kullandığında LDAP davranışını da aynı bütünlük içinde doğrulamalıdır.