Pekala, LDAP sorunlarını giderme hakkında konuşalım. Baştan başlayacak olursak sorun gidermeniz gerekebilecek noktalardan biri doğrulama hatalarıdır.
İşte bu noktada sertifikanız doğru değilse, grubunuz Active Directory veya OpenLDAP sunucusunda doğru şekilde kurulmamışsa, kullanıcı adınız doğru formatta girilmemişse tüm bu sorunları görebilirsiniz.
Bu nedenle, sorgu kullanıcısı için parola yanlışsa, "LDAP yapılandırma ayrıntıları doğrulanamadı" yazdığını göreceksiniz ve "Gönder" düğmesine basamayacaksınız.
Vurgulamak istediğim bir şey var, sertifikayı buraya yüklediğinizde burada gördüğünüz "AD-cert.cer", "Validate" düğmesine tıkladığınızda temel olarak sertifikayı "User local data protection" çubuğunda bulunan "Certificates Directory", config manager server_data certificates içinde saklar.
Artık, sertifika burada depolandıktan sonra ACM bu sertifikayı ".cer" biçiminden ".pem" biçimine dönüştürür. Şimdi, başarılı bir doğrulamanın nasıl görüneceğini gösteren başka bir video hazırladım.
Doğrulamanız başarısız olursa sorun gidermek için günlükte nelere dikkat edebileceğinizden de bahsettim. Öyleyse buradan devam edelim.
Bu nedenle, bunu tekrar yapmak için "Logs Directory"ye gelin, Escape, shift G ve ardından Escape, bir cihazda bu yapılandırılmış LDAP'yi arayın.
Bu komutu aradığınızda sizi "testLDAPconnection" işlemini yapmaya çalıştığı mesaja ulaştırır. Biraz daha aşağı kaydırırsanız ping testi yapar ve ardından kullanıcının kimliğinin başarıyla doğrulanıp doğrulanmadığını ve grubun üyesi olup olmadığını doğrular.
LDAP bağlantısı başarıyla test edildi' şeklinde bir mesaj görürsünüz. Şimdi, LDAP doğrulama hatası için günlükleri inceleyelim. Şimdi de başarısız olana bakalım.
Buraya ayrıntıları giriyorum ve bilerek yanlış alanlardan birini yanlış değer olarak girmeye çalışacağım. Ne olacak, göreceğiz. Bu güvenli, o yüzden bu kutuyu işaretleyeceğiz.
Sertifikayı yükleyeceğiz ve ardından doğrulamaya çalışacağız. Görünüşe göre doğrulama başarısız oldu. İmleci bu kırmızı ünlemin üzerine getirebilirsiniz. "Failed to validate LDAP configuration details" yazıyor.
Tekrar "ACM logs directory"ye gelin, "server.log"ı görüntüleyin, günlüğün sonuna gitmek için G shift kullanın, ? ve ardından şunu arayın, LDAP Util: testConnection, "C" büyük harfle, tek kelime.
Bunun gibi bir mesaj göreceksiniz. Buradan sorunun kullanıcı adı veya parolayla ilgili olduğunu anlayabiliyoruz. Bu örnekte sorun parolayla ilgiliydi. Test bağlantısının başarısız olduğunu görüyoruz.
Bununla birlikte, bu ayrıntıları girerken bilmeniz gereken bazı noktaları gözden geçirelim. "Server Hostname" veya "LDAP Hostname" sorulduğunda kullanıcılar tam nitelikli etki alanı adını (FQDN) sağlamalıdır. IP adresleri geçerli değildir.
Kullanıcı adını sorgulayın, kullanıcıların kullanıcı adını "User Principal" ad biçiminde sağlamaları gerekir. Örnek olarak "Abc@domain.com" olabilir. Bu her zaman işe yarar.
Yönetici grubu ayarları'nı tıklayın. Bu, Active Directory veya OpenLDAP düzeyinde ayarlanan yönetici grubudur. Müşteriniz grubu oluştururken grubun kapsamını "Global", türünü de "Security" olarak belirlemelidir.
"Query username", LDAP yönetici grubunun bir üyesi olmalıdır. En iyi uygulama genellikle tüm değerler için küçük harf kullanmaktır. Değerleri büyük harfle kullanırken bazı sorunlara neden olan bir kod hatamız da var, bu yüzden bunun farkında olun.
Güvenli LDAP yapılandırmaları için kullanıcıların kök CA sertifikasını ".cer" biçiminde sağlamaları gerekir. Son olarak, iç içe gruba izin verilmez. Yani kullanıcılar LDAP yönetici grubunun doğrudan üyesi olmalıdır.
Burada bahsettiğimiz kullanıcı, LDAP sorgu kullanıcısıdır. Örneğin, bir LDAP sorgu kullanıcısını bir grubun parçası yapıp daha sonra bu grubu yönetici grubunun üyesi yapamazsınız. Bu işe yaramaz.
Ele almak istediğimiz bir gereklilik daha var. LDAP entegrasyonunun Protection Storage veya Data Domain'de başarılı bir şekilde çalışması için LDAP sorgu kullanıcısının bilgisayar nesnesi için "Oluşturma/Kaldırma" Tam Denetim izinlerine sahip olması gerekir çünkü entegrasyon sırasında bir bilgisayar nesnesi oluşturur.
Peki bunu nasıl yapabiliriz? Active Directory'de, LDAP sorgu kullanıcısını bulun ve o kullanıcının bulunduğu "Kuruluş Birimi"ne (OU) gidin. Sağ tıklayın ve "Delegate Control" öğesine tıklayın. Bunu yaptığınızda bunun gibi bir sihirbazla karşılaşırsınız. "Next" öğesine tıklayıp sorgu kullanıcınızı ekleyebilirsiniz.
Ardından "Create a custom task to delegate" seçeneğini belirleyin. Ve bunu yaptığınızda, temel olarak burada Bilgisayar nesnelerini seçebilir ve Bu klasörde seçili nesneleri oluştur veya "Sil" i seçtiğinizden emin olabilirsiniz. Bunu yaptıktan sonra "Next" düğmesine tıklayın. "Full Control" ayrıcalıkları verdiğinizden emin olun. "Next" ve "Finish".
Bunu yaptıktan sonra, Protection Storage veya Data Domain tarafında da sorunsuz bir yapılandırmaya sahip olursunuz. Şimdi, LDAP türü sorunları gidermek söz konusu olduğunda, sistematik bir sırayla gitmek çok önemlidir. Her zaman bir ping testi ile başlamanızı tavsiye ederim.
Ping komutuyla bağlantı durumunu kontrol edin. Ping için her zaman ana bilgisayar adını veya FQDN'yi kullanın. IP adresini de kullanmanızı öneririm. Bunun bir nedeni var. Böylece "ping -c" gönderebilirsiniz. Dört paket yayınlayın, bu nedenle "4 FQDN" değerini girin ve temel olarak ping i test edip başarılı olduğunu onaylayabilirsiniz.
Ping'i hem IP hem de ana bilgisayar adı için test edin dememin nedeni şu, bazen IP'ye ping göndermek işe yarar. Ancak bu işlev, ACM'den veya IDPA içindeki bir ya da daha fazla bileşenden ana bilgisayar adı için çalışmaz. Bunun nedeni, "/etc/resolv.conf" dosyasında DNS arama etki alanının eksik olması olabilir. Bu da LDAP sunucusu ana bilgisayar adı için ping hatalarına neden olabilir.
Doğrusu, bu en sık karşılaşılan sorundur. Bu nedenle, IP adresine ping gönderebilseniz de ana bilgisayar adına ping gönderemiyorsanız şunu deneyin: Her bir IDPA bileşeninde "/etc/resolv.conf" dosyasını kontrol edin. Çözümün işe yaradığından emin olmak için bu arama etki alanının Active Directory veya ortam için eklendiğinden emin olun.
Ardından, bazı bağlantı noktası kontrolleri yapmanızı öneririm. Peki, LDAP entegrasyonu için bağlantı noktası gereksinimleri nelerdir? Temel olarak IDPA bileşenleri ile Active Directory veya "OPENLDAP" sunucusu arasındaki iletişim için açık olması gereken 389 ve 636 numaralı TCP bağlantı noktalarına ihtiyacımız var. Artık "Avamar"ınız olan koruma yazılımı, veri etki alanınız olan koruma depolama alanı ve Active Directory veya "OPENLDAP" sunucusu arasında Kerberos kimlik doğrulaması için TCP bağlantı noktaları 88 ve 464'ün açık olması gerekir.
Bağlantı noktası bağlantısı nasıl test edilebilir? Bunu "curl" komutuyla yapabilirsiniz. Bunu demoda görmüştük. Yani şu komutu kullanabilirsiniz: "curl -kv :". Unutmayın, 389 "Non-secure", 636 ise "Secure" seçenekleri içindir. Komutu çalıştırınca şu mesajı görmelisiniz: "Connected to dc.x400.sh" ve "port 636". "ldapsearch" komutuyla sorun gidermenin çok önemli bir araç olduğunu düşünüyorum.
Doğrulamanız başarısız oluyorsa, yapılandırmanız başarısız oluyorsa bu kullanılabilir. Yaptığı şey, temel olarak sahip olduğunuz LDAP ayrıntılarını kullandığı bir "doğrulamaya" benzer olduğundan, bir test bağlantısı gerçekleştirecek ve bağlanıp bağlanamayacağımızı onaylayacaktır. Temel olarak "ldapsearch", bir LDAP sunucusuna bağlantı açan, ona bağlanan ve bir filtre kullanarak arama yapan bir komut satırı aracıdır.
Sonuçlar daha sonra "LDIF" biçiminde yani LDAP Interchange biçiminde görüntülenir. ldapsearch aracı, LDAP sunucusuyla bağlantıyı test etmek ve ayarları doğrulamak için ACM, DPC Search, Avamar vb. IDPA bileşenlerinde kullanılabilir. Söz dizimi, güvenli olmayan ve güvenli LDAP için farklıdır.
Güvenli olmayanlar için "ldapsearch -h" komutunu çalıştırabilirsiniz. LDAP sunucusunun FQDN'sini girin. Bu OpenLDAP veya Active Directory olabilir. Devamına "-p" getirin. Bağlantı noktası numarasını oraya "-D" koyun, kullanıcı kimlik bilgilerini girin LDAP_Query örneğin "x400.sh" veya bu biçimde bir şey ekleyin, -b, "Base_DN" Etki alanı bileşeninin gittiği yer burasıdır. Yani "dc=x400, dc=2.sh" gibi bir şey. Ardından "-w" ekleyip sorgu parolasını girin.
Benzer şekilde, Güvenli LDAP için de bunu yapabilirsiniz. ldapsearch -h, ldaps://, URL'yi oraya koyun. "LDAP_server_FQDN: port" numarasını giriyorsunuz. Güvenli LDAP türünü yapılandırırken "openssl" veya sertifikaları doğrulama işlemini gerçekleştirin. Bunu "openssl" komutunu girerek yapabilirsiniz. "openssl s_client -connect" komutunu çalıştırın. : biçiminde girin. Burada bağlantı noktası numaramız 636.
"Connected" ifadesinin görüntülendiğini fark edeceksiniz. Bu, ACM'nin bu sertifikayla 636 numaralı bağlantı noktasını doğrulayabildiği ve bağlanabildiği anlamına gelir. Bu komutu çalıştırınca değişikliğin doğrulanamadığını belirten bir ifade görüntülendiğini fark edebilirsiniz. Bu bir sorun değildir çünkü burada yalnızca bağlanıyorsunuz. Active Directory sunucusunun zinciri doğrulaması için bir sertifika iletmiyorsunuz. Bunda sorun yok. Yukarıdaki çıktı da kısaltılmıştır, buna da dikkat edin.
Sorgu kullanıcısı ve Yönetici grubu ayrıntılarını doğrulama. Diyelim ki bazı şeylerin doğru olmadığını, belki grubun doğru olmadığını, sorgu kullanıcısının ayrıntılarının doğru olmadığını öğrendiniz ve bir sonraki sorun giderme adımınıza burada geçiyorsunuz. Peki ne yapıyoruz? Active Directory sunucusunda, kullanıcı ve grup nesnelerini Ayırt Edici Ad (DN) biçiminde getirmek için sorgulayabileceğimiz PowerShell'i kullanıyoruz.
Belirli bir kullanıcı nesnesini alan veya birden çok kullanıcı nesnesi almak için arama yapan "Get-ADUser" cmdlet'iniz var. Bir de, bir grup almak veya bir Active Directory'den birden çok grup almak üzere arama gerçekleştirmek için kullanılabilen "Get-ADGroup" cmdlet'iniz var. Sol taraftaki ekran görüntüsünde kullanıcı komutunun çıktısı mevcut. Sağdakinde ise grup komutunun çıktısını görebilirsiniz. Alacağınız çıktı türü bu şekildedir.
"Distinguished Name" burada. Bir "ldap.query". "Users" OU'sunda. Etki alanı bileşeni "x400.sh". Sadece buna bakarak "User Principal Name"i doğrulayabilirim. "LDAP'yi yapılandır" açılır penceresine veya iletişim kutusuna girmem gereken şey bu.
Tüm bu ayrıntıları buradan doğrulayabilirsiniz. Grupla ilgili de yine DN biçimine ve grubun konumuna sahibiz. Yine "Users" OU'sunda. Etki alanı bileşeni "x400" ve "sh". Grup kategorisi "Security". Size grup kategorilerinin "Güvenlik" ve grup kapsamının "Genel" olması gerektiğini söylediğimi hatırlayın. Bunu da buradan doğrulayabiliriz.
Ayrıca bize "SamAccountName" ve "dp_admin" grup adını da gösteriyor. Dolayısıyla bu, müşterilerin Active Directory düzeyinde de doğrulama yapmanız için iyi bir yöntemdir. Önceki slaytlarda söylediğim gibi IDPA da LDAP yapılandırıldıktan sonra ACM, LDAP yapılandırmasının ayrıntılarını ldapconfig.xml dosyasında saklar. Ayrıca, bu sorgu kullanıcısının parolasını "Component Credentials.ReadXml" adlı bir dosyada saklar.
ACM'nin bileşenleri izlerken temel işlevi, birkaç dakikada bir bu kimlik bilgilerini ve ayrıntıları kullanarak her bir bileşende LDAP oturumu açma testi yapar. Bunu neden yapıyor? LDAP yapılandırmasının çalıştığından ve bu kullanıcı ve diğer bileşenler için ACM'de depolanan LDAP sorgu parolasının gerçekten senkronize olup olmadığından emin olmak ister. Değişiklik yok ve bunu doğruladı.
Artık, bir müşterinin sorgu kullanıcı parolasını değiştirdiği kullanım durumlarında LDAP kimlik doğrulamanız tüm bileşenlerde çalışmayı durduracak ve ACM kullanıcı arayüzünde "LDAP password of sync" yazan bir hata mesajı göreceksiniz. Yani durum buysa, temel olarak ACM GUI ya gelip aynı "Configure external LDAP" açılır penceresine tıklayabilir ve Update external LDAP password yazan onay kutusuna tıklayabilirsiniz.
Bunu yaptığınızda, diğer tüm ayrıntılar grileşir ve sadece parolayı güncelleştirebilirsiniz. Bunu yaptığınızda, kendi içindeki parolayı veya kimlik bilgilerinin saklandığı ACM "Component Credentials.ReadXml" dosyasındaki parolayı güncelleştirilir. Ayrıca kimlik doğrulamanın hala çalıştığından emin olmak için yapılandırma parolasını, IDPA ilgili ürünlerinin veya bileşenlerinin her birinde güncelleştirir. Yani, bu gerçekten dikkat edilmesi gereken bir şey.
Şimdi, yapılandırmanın başarısız olmasının veya kullanıcıların bir tür kimlik doğrulama sorunu yaşamasının en yaygın nedenlerinden biri, saatin senkronize olmaması olabilir. Zaman çok hassastır. LDAP söz konusu olduğunda zaman, IDPA bileşenleri ile Active Directory veya OpenLDAP sunucusu arasında senkronize olmalıdır. Zaman senkronize değilse kullanıcılar yapılandırma hataları ve hatta kimlik doğrulama oturum açma hatalarıyla karşılaşabilir.
Şimdi, burası çok önemli. Bunları her gün kullanıyoruz. Günlük konumları ve günlük dosyalarının kendileri. Bunlar nedir? Dolayısıyla, LDAP sorunlarını giderirken kullanıcıların ACM de aşağıdaki oturumlarda yapılandırma, entegrasyon, doğrulama, izleme türü hataları olup olmadığını kontrol etmeleri gerekir; bunlar sizin "server.log"ınızdır.
Bunu demoda da görmüştük. Şimdi, bir veya daha fazla bileşende yapılandırma hatası olduğunu varsayalım o zaman LDAP yapılandırmasının başarısız olduğu bileşendeki günlüklerin yanı sıra ACM'den gelen "server.log"yi analiz etmemiz gerekir. Günlük konumları da burada. ACM'de "server.log"umuz var. Data Protection Central'da "elg.log"umuz var.
Burada yolun tamamı sağlanmış. Search burada. Search'de "cis.log" mevcut. Protection Software için "userauthentication.log". Ayrıca bazı durumlarda aynı yerde bulunan "mcserver.log.0" üzerinde de bazı detayları bulabilirsiniz.
Protection Storage veya Data Domain için "messages.engineering" günlüğünü inceleyebilirsiniz. Bunun için Bash erişimine ihtiyacınız olacaktır. Bu yüzden bunu göz önünde bulundurun. Son olarak, DPA. Bir opt/emc/dpa/services/logs dizini olan "server.log"yi görebilirsiniz.
