Kimlik ve dizin entegrasyonu: Entra ID, LDAP ve SSO nerede başlar nerede biter

Bir intranetin en sessiz başarısızlığı kullanıcı listesindedir. Kurulumda İK'dan alınan Excel içeri aktarılır, ilk ay herkes memnundur; altı ay sonra listede işten ayrılmış üç kişi durur, yeni gelen beş kişi yoktur ve kimse organizasyon şemasına güvenmez. Bu, içerik sorunu değil veri kaynağı sorunudur: kadronun gerçeği başka bir sistemde yaşıyordur.

Kurumsal dizine bağlanmak bunu çözer. Ama "dizin entegrasyonu" tek bir şey değil, sık karıştırılan iki ayrı iştir.

SSO doğrular, dizin sağlar

Bu ayrımı baştan yapmak, sonraki bütün kararları kolaylaştırır.

SSO (SAML ya da OIDC) bir kimlik doğrulama işidir. Kişi şirket hesabıyla giriş yapar, ayrı bir intranet şifresi tutmaz, şirket hesabı kapandığında giriş de kapanır. SSO'nun cevapladığı soru şudur: "Bu kişi gerçekten o kişi mi?"

Dizin eşleştirme bir veri sağlama işidir. Kimin çalıştığını, hangi departmanda olduğunu, unvanının ne olduğunu dizinden okur ve intranetteki profillere yazar. Cevapladığı soru farklıdır: "Kadro bugün kimlerden oluşuyor?"

İkisi birbirinin yerine geçmez. Yalnızca SSO kurarsanız girişler düzelir ama rehber eskimeye devam eder — çünkü hiç giriş yapmamış bir çalışan hiç görünmez. Yalnızca dizin eşleştirirseniz rehber güncel kalır ama herkes hâlâ ayrı bir şifre taşır. Olgun kurulumlarda ikisi birlikte çalışır.

Entra ID tarafı

Microsoft Entra ID (eski adıyla Azure AD) tarafında kurulum, bir uygulama kaydı açmakla başlar. İntranet bu kayıt üzerinden dizine kendi kimliğiyle bağlanır; kimsenin kişisel hesabı kullanılmaz.

Üç değer gerekir: dizin (tenant) kimliği, uygulama (client) kimliği ve bir istemci gizli anahtarı. Bir de izin: kadroyu okuyabilmek için uygulamaya User.Read.All yetkisi verilir ve bu yetki yönetici onayından geçer. Onay adımı unutulduğunda bağlantı testi jeton alır ama kullanıcı listesi boş döner — bu yüzden sağlıklı bir bağlantı testi jeton almakla yetinmemeli, kullanıcı ucunu da gerçekten yoklamalıdır.

Gizli anahtarın bir son kullanma tarihi olduğunu da not edin. Süresi dolduğunda entegrasyon sessizce durur; takvime bir hatırlatma koymak, altı ay sonra "senkron neden çalışmıyor" diye aramaktan ucuzdur.

LDAP / Active Directory tarafı

Şirket içinde klasik bir Active Directory varsa bağlantı LDAP üzerinden kurulur. Burada gereken şeyler farklıdır: sunucu adresi, bir okuma yetkili hesap (bind DN) ve aramanın nereden başlayacağı (base DN).

İki ayrıntı çoğu kurulumu belirler. Birincisi şifreli bağlantı: LDAPS ya da StartTLS olmadan kurumsal kimlik bilgileri ağda açık dolaşır. İkincisi pasif hesapların ayıklanması: Active Directory'de ayrılan çalışanların kaydı genellikle silinmez, devre dışı bırakılır. Bu bilgi userAccountControl alanında bir bit olarak durur; filtreye eklenmezse ayrılan herkes intranete "aktif çalışan" diye akar — yani çözmeye çalıştığınız sorunun aynısını, bu kez otomatik olarak üretirsiniz.

Önizle, sonra uygula

Dizin entegrasyonlarında en çok korkulan senaryo, bir yapılandırma hatasının kadroyu topluca bozmasıdır. Bunun karşılığı basit bir disiplindir: fark önce gösterilir, uygulama ayrı bir onayla olur.

Pratikte akış şudur: bağlantı testi geçer, sistem dizindeki kadroyla intranetteki profilleri karşılaştırır ve bir fark listesi çıkarır — kaç kişi eşleşti, kimin departmanı değişmiş, kim dizinde artık yok. Yönetici bu listeyi okur, sonra uygular.

Sınırları da baştan bilmek gerekir. Wepilot'ta dizin eşleştirmesi hesap açmaz ve departman yaratmaz; var olan profilleri günceller. Bunun sebebi ihtiyatlılık: bir filtre hatası yüzünden yüzlerce hesabın açılması, aynı hatanın profilleri güncellemesinden çok daha zor geri alınır. Tam otomatik hesap yaşam döngüsü (SCIM ile joiner-mover-leaver) ayrı bir konudur ve bu entegrasyonun kapsamında değildir.

Sırlar nerede durur?

Bu entegrasyonun taşıdığı şey sıradan bir ayar değil, dizine erişim yetkisidir. İstemci gizli anahtarı ve LDAP şifresi tarayıcıya hiç ulaşmamalıdır.

Doğru desen, bu kayıtları hiçbir okuma politikası olmayan bir tabloda tutmak ve yönetim ekranına yalnızca "anahtar tanımlı mı, değil mi" bilgisini döndürmektir. Yönetici alanı doldurabilir, ama daha önce yazdığı anahtarı geri okuyamaz. Bu, arayüzde alanı gizlemekten farklıdır: kısıt veritabanı seviyesindedir, tarayıcıdan gelen hiçbir istek bunu aşamaz. Aynı ilkenin uygulandığı diğer yerleri KVKK yazısında anlattık.

Nereden başlamalı?

Sıralama önerimiz nettir: önce dizin eşleştirmesini kurun, sonra SSO'ya geçin. Sebep pratiktir — rehberin doğru olması ilk günden herkesin gördüğü bir fayda üretir, SSO ise kimlik ekibiyle koordinasyon ve test penceresi ister.

Ölçmesi de kolaydır: eşleşmeyen kayıt sayısı, dizinde olup intranette olmayan kişi sayısı ve son başarılı senkronun üzerinden geçen süre. Üçü de sıfıra yaklaşmıyorsa entegrasyon kurulmuş ama işletilmiyor demektir. Bu tür süreç sahipliğini işletme yazısında ele alıyoruz.