Zimbra LDAP Entegrasyonu ve Active Directory Senkronizasyonu
Kurumsal ortamlarda Zimbra kurarken en çok can yakan şey, kullanıcı yönetimini iki ayrı sistemde yapmak zorunda kalmak. Bir tarafta Active Directory, öbür tarafta Zimbra’nın kendi dizin yapısı. Kullanıcı oluşturulacak, her iki tarafta da yapılacak; şifre değişecek, yine iki taraf. Bu durumu yaşadıysanız ne demek istediğimi gayet iyi anlıyorsunuzdur. Bu yazıda Zimbra’yı Active Directory ile nasıl entegre edeceğinizi, senkronizasyonun nasıl çalıştığını ve gerçek ortamlarda karşılaştığım sorunları nasıl çözdüğümü aktaracağım.
Zimbra LDAP Mimarisi: Önce Bunu Anlamak Gerekiyor
Zimbra kendi içinde OpenLDAP tabanlı bir dizin servisi barındırır. Bu servis zimbra kullanıcısı altında çalışır ve Zimbra’ya özgü şema uzantıları içerir. Dolayısıyla “Zimbra’yı tamamen AD’ye bağlayayım, kendi LDAP’ını kapayayım” diye düşünüyorsanız, bu pek mümkün değil. Zimbra’nın kendi LDAP’ı her zaman çalışmak zorunda.
Peki entegrasyon nasıl çalışıyor? İki temel yöntem var:
- External LDAP Authentication: Kimlik doğrulama AD üzerinden yapılır, kullanıcı hesapları Zimbra’da manuel ya da otomatik oluşturulur.
- GAL (Global Address List) Senkronizasyonu: AD’deki kullanıcı listesi Zimbra’nın adres defterine aktarılır.
- Tam Senkronizasyon (ZimbraSync / zmgalsyncd): Hem kimlik doğrulama hem de kullanıcı bilgilerinin periyodik olarak AD’den çekilmesi.
Çoğu kurumsal ortamda üçü birden kullanılıyor. Ben de genellikle bu yaklaşımı tercih ediyorum.
Ortam Hazırlığı
Başlamadan önce şunların hazır olması gerekiyor:
- Windows Server üzerinde çalışan Active Directory Domain Services
- AD’ye okuma yetkisi olan bir servis hesabı (örnek:
[email protected]) - Zimbra sunucusundan AD domain controller’a 389 (LDAP) veya 636 (LDAPS) portunda erişim
- Zimbra 8.8.x veya 9.x kurulu ve çalışıyor olmalı
Önce bağlantıyı test edelim:
# Zimbra sunucusundan AD'ye LDAP bağlantı testi
ldapsearch -x -H ldap://dc01.sirket.local:389
-D "CN=svc-zimbra,OU=ServiceAccounts,DC=sirket,DC=local"
-w "ServisHesabiSifresi"
-b "DC=sirket,DC=local"
"(objectClass=user)" cn mail sAMAccountName | head -50
Bu komut çıktı veriyorsa bağlantı sağlam demektir. Hiçbir şey dönmüyorsa firewall kurallarını ve servis hesabı yetkilerini kontrol edin.
Zimbra’da External Authentication Yapılandırması
Kimlik doğrulamayı AD’ye devretmek için zmprov komutunu kullanıyoruz. Bu işlemi zimbra kullanıcısı olarak yapmanız gerekiyor:
su - zimbra
# Domain için external auth yapılandırması
zmprov md sirket.com.tr
zimbraAuthMech ldap
zimbraAuthLdapURL "ldap://dc01.sirket.local:389"
zimbraAuthLdapBindDn "CN=svc-zimbra,OU=ServiceAccounts,DC=sirket,DC=local"
zimbraAuthLdapBindPassword "ServisHesabiSifresi"
zimbraAuthLdapSearchBase "DC=sirket,DC=local"
zimbraAuthLdapSearchFilter "(sAMAccountName=%u)"
Buradaki %u değişkeni, kullanıcının giriş yaparken yazdığı kullanıcı adını temsil ediyor. Yani [email protected] ile giriş yapan biri için sAMAccountName=ahmet.yilmaz sorgusu AD’ye gönderilecek.
Yapılandırmayı doğrulamak için:
# Test kullanıcısı ile kimlik doğrulama testi
zmprov aau [email protected]
# ya da daha detaylı test için
ldap search debug modunda:
zmldappasswd -s
Aslında en sağlıklı test yöntemi şu:
# Belirli bir kullanıcı için auth testi
zmprov -v ga [email protected] zimbraAuthMech
GAL (Global Address List) Senkronizasyonu
GAL senkronizasyonu, AD’deki kullanıcıların Zimbra’nın adres defterinde görünmesini sağlar. Bu özellikle büyük organizasyonlarda kritik; 500 kişilik bir şirkette elle adres eklemek isteyebileceğiniz son şey.
# GAL için external data source oluşturma
zmprov md sirket.com.tr
zimbraGalMode ldap
zimbraGalLdapURL "ldap://dc01.sirket.local:389"
zimbraGalLdapBindDn "CN=svc-zimbra,OU=ServiceAccounts,DC=sirket,DC=local"
zimbraGalLdapBindPassword "ServisHesabiSifresi"
zimbraGalLdapSearchBase "OU=Kullanicilar,DC=sirket,DC=local"
zimbraGalLdapFilter "(|(objectClass=person)(objectClass=group))"
zimbraGalLdapAttrMap "cn=displayName,mail=mail,telephoneNumber=phone"
zimbraGalLdapAttrMap parametresi kritik. AD attribute adını Zimbra attribute adına eşliyorsunuz. Şirket içinde kullandığınız özel attribute’lar varsa bunları da buraya ekleyebilirsiniz.
GAL senkronizasyonunu tetiklemek için:
# Manuel GAL sync
zmprov sgds sirket.com.tr
# GAL sync durumunu kontrol et
zmprov ggs sirket.com.tr
Otomatik Hesap Oluşturma (Auto Provisioning)
Burada işler biraz daha ilginç hale geliyor. AD’de yeni bir kullanıcı oluşturulduğunda, o kullanıcının Zimbra’ya ilk girişinde otomatik olarak hesabının oluşturulmasını sağlayabilirsiniz. Buna lazy provisioning diyoruz.
# Auto provisioning ayarları
zmprov md sirket.com.tr
zimbraAutoProvMode LAZY
zimbraAutoProvLdapURL "ldap://dc01.sirket.local:389"
zimbraAutoProvLdapAdminBindDn "CN=svc-zimbra,OU=ServiceAccounts,DC=sirket,DC=local"
zimbraAutoProvLdapAdminBindPassword "ServisHesabiSifresi"
zimbraAutoProvLdapSearchBase "OU=Kullanicilar,DC=sirket,DC=local"
zimbraAutoProvLdapSearchFilter "(mail=%[email protected])"
zimbraAutoProvAttrMap "displayName=displayName,mail=mail,telephoneNumber=mobile"
zimbraAutoProvAccountNameMap "sAMAccountName"
Lazy mode’un dışında bir de EAGER mod var. Bu modda Zimbra periyodik olarak AD’yi tarar ve yeni kullanıcıları otomatik ekler, giriş beklenmez. Büyük organizasyonlarda eager mode daha tercih edilir çünkü IT’nin “neden hesabım yok?” şikayetlerini beklemesine gerek kalmaz.
# Eager provisioning için ek ayarlar
zmprov md sirket.com.tr
zimbraAutoProvMode EAGER
zimbraAutoProvPollingInterval 30m
zimbraAutoProvBatchSize 20
zimbraAutoProvPollingInterval: Her 30 dakikada bir AD taranır. zimbraAutoProvBatchSize: Her seferinde en fazla 20 kullanıcı işlenir; çok büyük koyarsanız ve binlerce kullanıcınız varsa performans sorunu çıkabilir.
LDAPS ile Güvenli Bağlantı
Üretim ortamında 389 portu üzerinden şifresiz LDAP kullanmak pek önerilen bir şey değil. Özellikle servis hesabı şifresi ağda açık gidiyor. LDAPS (636/tcp) veya StartTLS kullanmak daha sağlıklı.
Önce AD’nin sertifikasını Zimbra’nın trust store’una eklememiz gerekiyor:
# AD sertifikasını al
openssl s_client -connect dc01.sirket.local:636 -showcerts </dev/null 2>/dev/null
| openssl x509 -outform PEM > /tmp/ad-cert.pem
# Sertifikayı Zimbra'nın cacerts'ine ekle
su - zimbra
cd /opt/zimbra/common/lib/jvm/java/lib/security/
keytool -import -trustcacerts -alias "AD-DC01"
-file /tmp/ad-cert.pem
-keystore cacerts
-storepass changeit
# Zimbra'yı yeniden başlat
zmcontrol restart
Sonra yapılandırmada URL’yi güncelleyin:
zmprov md sirket.com.tr
zimbraAuthLdapURL "ldaps://dc01.sirket.local:636"
zimbraGalLdapURL "ldaps://dc01.sirket.local:636"
zimbraAutoProvLdapURL "ldaps://dc01.sirket.local:636"
Çoklu Domain Controller ile Yüksek Erişilebilirlik
Tek bir DC’ye bağımlı kalmak, o DC patladığında mail sunucunuzun da gitmesi demek. Birden fazla DC’yi şu şekilde tanımlayabilirsiniz:
# Birden fazla LDAP URL tanımı
zmprov md sirket.com.tr
zimbraAuthLdapURL "ldap://dc01.sirket.local:389 ldap://dc02.sirket.local:389"
Zimbra URL listesini soldan sağa dener; ilki cevap vermezse ikincisine geçer. Basit ama etkili bir failover mekanizması.
Gerçek Dünyadan Sorun Giderme
Şimdi gelelim benim en çok değer verdiğim kısma. Teorisi güzel, pratiği bazen başka türlü oluyor.
Sorun 1: Kullanıcılar AD şifresiyle giremedi
En yaygın senaryo. zimbraAuthLdapSearchFilter genellikle suçlu oluyor. Özellikle bazı kurumlar sAMAccountName yerine UPN (User Principal Name) ile giriş yapıyor. Şu filter’ı deneyin:
# UPN ile giriş için filter
zmprov md sirket.com.tr
zimbraAuthLdapSearchFilter "(|(sAMAccountName=%u)(userPrincipalName=%[email protected]))"
Sorun 2: Devre dışı AD hesapları Zimbra’ya girebiliyor
AD’de hesabı disable ettiğinizde Zimbra bunu otomatik algılamıyor. Filter’a şunu ekleyin:
# Sadece aktif hesapları getir
zmprov md sirket.com.tr
zimbraAuthLdapSearchFilter "(&(sAMAccountName=%u)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))"
userAccountControl:1.2.840.113556.1.4.803:=2 ifadesi AD’de disabled hesapları filtreleyen bitwise LDAP operatörü. Biraz karmaşık görünüyor ama çalışıyor.
Sorun 3: GAL’de Türkçe karakter problemi
AD’den gelen isimler “Mustafa” yerine bozuk karakterlerle görünüyorsa encoding sorunu var. Zimbra LDAP konfigürasyonuna şunu ekleyin:
# /opt/zimbra/conf/ldap/localconfig.xml içinde kontrol edin
zmlocalconfig -e ldap_common_loglevel=0
# Sonra logu inceleyin
tail -f /opt/zimbra/log/zimbra.log | grep -i ldap
Genellikle bu sorun, AD’nin UTF-8 dönüştürmesinde değil, Zimbra’nın veritabanına yazarken ortaya çıkıyor. zimbraGalLdapAttrMap içindeki attribute eşlemelerini kontrol edin.
Sorun 4: Auto provisioning çalışmıyor, log nerede?
# Auto provisioning loglarını izle
tail -f /opt/zimbra/log/zimbra.log | grep -i "autoprov|provision"
# Daha detaylı debug için
zmprov mcf zimbraAutoProvNotificationFromAddress [email protected]
zmprov md sirket.com.tr zimbraAutoProvMode EAGER
zmcontrol restart
Düzenli Senkronizasyon ve İzleme
AD’den Zimbra’ya değişikliklerin düzenli yansıması için bir cron job hazırlamak iyi bir pratik. Özellikle hesap silme durumlarında Zimbra otomatik davranmıyor; bunu kendiniz yönetmeniz gerekiyor.
#!/bin/bash
# /opt/zimbra/scripts/sync-disabled-accounts.sh
# AD'de disable edilen hesapları Zimbra'da da deaktive et
LDAP_HOST="ldap://dc01.sirket.local"
BIND_DN="CN=svc-zimbra,OU=ServiceAccounts,DC=sirket,DC=local"
BIND_PASS="ServisHesabiSifresi"
BASE_DN="OU=Kullanicilar,DC=sirket,DC=local"
DOMAIN="sirket.com.tr"
LOG="/var/log/zimbra-sync.log"
echo "$(date): Sync basliyor" >> $LOG
# AD'de disable edilmis hesaplari bul
DISABLED_USERS=$(ldapsearch -x -H $LDAP_HOST
-D "$BIND_DN"
-w "$BIND_PASS"
-b "$BASE_DN"
"(&(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2))"
mail | grep "^mail:" | awk '{print $2}')
for user in $DISABLED_USERS; do
# Zimbra'da kullanici var mi kontrol et
zimbra_status=$(su - zimbra -c "zmprov ga $user zimbraAccountStatus 2>/dev/null | grep zimbraAccountStatus")
if echo "$zimbra_status" | grep -q "active"; then
su - zimbra -c "zmprov ma $user zimbraAccountStatus maintenance"
echo "$(date): $user hesabi deaktive edildi" >> $LOG
fi
done
echo "$(date): Sync tamamlandi" >> $LOG
Bu scripti crontab’a ekleyin:
# root crontab
0 */2 * * * /opt/zimbra/scripts/sync-disabled-accounts.sh
Her 2 saatte bir çalışır; kalabalık ortamlarda yeterli. Daha acil ihtiyaçlarınız varsa 30 dakikaya indirebilirsiniz ama çok kalabalık bir AD’de performans etkisi yaratabilir.
Kullanıcı Attribute Eşlemeleri
AD ile Zimbra arasındaki attribute eşlemesi çoğu zaman belgelerde yetersiz anlatılıyor. Sık kullandığım eşlemeler:
- displayName: AD’deki görünen ad, Zimbra’da da displayName olarak gelir
- mail: AD’deki birincil mail adresi
- proxyAddresses: AD’deki SMTP:adres formatındaki adresleri Zimbra alias olarak eklemek için özel işlem gerekir
- telephoneNumber: İş telefonu, Zimbra’da mobile veya phone olarak eşlenebilir
- department: Departman bilgisi, Zimbra’da zimbraOrgUnit’e eşlenebilir
- manager: Yönetici bilgisi, bazı organizasyonlarda iş akışı için kullanılıyor
- thumbnailPhoto: AD’deki profil fotoğrafı, Zimbra bu attribute’ı destekler
proxyAddresses için özel bir senaryo: Bazı kullanıcıların AD’de birden fazla mail adresi var. Bunları Zimbra’ya alias olarak eklemek için otomatik mekanizma yok, ek scripting gerekiyor.
Güvenlik Notları
LDAP entegrasyonu yaparken güvenlik açısından dikkat edilmesi gerekenler:
- Servis hesabı için minimum yetki prensibini uygulayın. Sadece okuma yetkisi yeterli, Domain Admin’e gerek yok.
- Servis hesabının şifresini Zimbra’da düz metin olarak saklamamak mümkün değil ama
zmconfigdosyalarının izinlerini kontrol edin. - LDAPS veya StartTLS kullanmıyorsanız ağ trafiğinizi izleyin, şifreler açık gidecek.
- AD servis hesabının şifresini değiştirirseniz Zimbra’daki tüm bind DN konfigürasyonlarını güncellemeyi unutmayın. Bunu unutup pazar gecesi gelen “kimse mail alamıyor” aramasını yaşamak istemezsiniz.
# Servis hesabı sifresi degistiginde guncelleme
su - zimbra
zmprov md sirket.com.tr zimbraAuthLdapBindPassword "YeniSifre"
zmprov md sirket.com.tr zimbraGalLdapBindPassword "YeniSifre"
zmprov md sirket.com.tr zimbraAutoProvLdapAdminBindPassword "YeniSifre"
Sonuç
Zimbra ve Active Directory entegrasyonu, doğru yapılandırıldığında hem son kullanıcıların hem de sistem yöneticilerinin hayatını ciddi ölçüde kolaylaştırıyor. Tek kimlik bilgisiyle tüm sisteme erişim, IT helpdesk’e düşen “şifremi sıfırla” taleplerinin azalması ve merkezi kullanıcı yönetimi bunların başında geliyor.
Bununla birlikte, bu entegrasyonun “kur ve unut” türünden olmadığını da vurgulamak gerekiyor. AD’de yapılan her büyük değişiklik, Zimbra tarafında nasıl yansıdığını izlemenizi gerektiriyor. Özellikle organizasyon yapısı değişiklikleri, kullanıcı devre dışı bırakma işlemleri ve toplu hesap migrasyonları dikkat isteyen durumlar.
Birden fazla domain controller kullanımı, LDAPS ile şifreli bağlantı ve düzenli senkronizasyon scriptleri olmadan üretim ortamına almayın. Bu üç şeyi ihmal edilen kurulumları sonradan toparlayıp düzeltmek, baştan doğru yapmaktan çok daha maliyetli oluyor.
