Jak skonfigurować zewnętrzne uwierzytelnianie LDAP dla Zimbry

Jakie zmiany w zewnętrznym uwierzytelnianiu LDAP w Zimbra

Zewnętrzne uwierzytelnianie LDAP pozwala Zimbrze zweryfikować hasło użytkownika w innym katalogu, a nie w wewnętrznym katalogu LDAP Zimbry. Aktualny podręcznik administratora Zimbra Daffodil (v10) stwierdza, że ​​zewnętrzne uwierzytelnianie LDAP jest konfigurowane dla każdej domeny, a metoda zewnętrzna próbuje powiązać się z określonym katalogiem przy użyciu podanych danych logowania użytkownika. Jeśli powiązanie się powiedzie, hasło jest uznawane za prawidłowe.

Nie powoduje to automatycznego przekształcenia zewnętrznego katalogu LDAP w bazę danych kont Zimbra. Zimbra nadal przechowuje dane kont specyficzne dla Zimbra we własnym katalogu. W podręczniku do wersji 10 wyraźnie zaznaczono, że użytkownicy zazwyczaj muszą istnieć zarówno w Zimbra, jak i w katalogu zewnętrznym, chyba że osobno skonfigurujesz automatyczne udostępnianie.

Aktualną dokumentację produktu można znaleźć w podręczniku administratora Zimbra Daffodil v10 i podręczniku konfiguracji Zimbra v10 .

Szybka lista kontrolna planowania

• Potwierdź domenę Zimbra, którą chcesz zmienić, na przykład example.com.
• Sprawdź, czy ci sami użytkownicy już istnieją w systemie Zimbra lub zaplanuj automatyczne przydzielanie kont osobno.
• Poznaj zewnętrzną nazwę hosta LDAP, port, metodę TLS i łańcuch certyfikatu.
• Dowiedz się, w jaki sposób nazwa logowania Zimbra jest mapowana na nazwę wyróżniającą użytkownika w protokole LDAP.
• Jeśli nie można utworzyć nazwy wyróżniającej bezpośrednio na podstawie nazwy logowania, przygotuj bazę wyszukiwania, filtr wyszukiwania oraz konto wyszukiwania z najmniejszymi uprawnieniami.
• Podczas testowania utrzymuj otwartą sesję administratora Zimbra, aby móc szybko przywrócić poprzednie ustawienia.

Najpierw wybierz odpowiednią metodę mapowania

Aktualny przewodnik konfiguracji v10 nadal definiuje atrybuty „search-base”, „search-bind”, „search-filter” i „per-account external-DN”. Starsze oficjalne materiały Zimbra Tech Center wyjaśniają, jak te mapowania są wykorzystywane w praktyce. Ponieważ materiały te są starsze niż Daffodil, należy traktować je jako tło operacyjne i zweryfikować szczegóły z zainstalowaną wersją przed przeprowadzeniem dużej migracji. Zobacz oficjalne notatki Zimbra Tech Center dotyczące zewnętrznego LDAP .

Krok 1: Zapisz bieżące ustawienia uwierzytelniania domeny

Uruchom polecenia administracyjne jako zimbraużytkownik systemu operacyjnego. Przed wprowadzeniem jakichkolwiek zmian, przechwyć istniejące wartości domeny:

su - zimbra

zmprov gd example.com \
  zimbraAuthMech \
  zimbraAuthLdapURL \
  zimbraAuthLdapBindDn \
  zimbraAuthLdapSearchBase \
  zimbraAuthLdapSearchFilter \
  zimbraAuthFallbackToLocal

Zapisz dane wyjściowe w rekordzie zmian. Przewodnik konfiguracji v10 zawiera listę prawidłowych wartości dla zimbraAuthMech, w tym zimbra, ldap, adoraz Kerberos lub mechanizmów niestandardowych. W tym przewodniku mechanizmem docelowym jest ldap.

Krok 2: Sprawdź dostępność sieci i protokół TLS przed zmianą Zimbra

Nie rozwiązuj problemów z mapowaniem uwierzytelniania, dopóki nie będzie pewności, że podstawowa łączność działa. Na serwerze Zimbra sprawdź rozpoznawanie nazw DNS i czy punkt końcowy LDAP jest osiągalny. W przypadku protokołu LDAPS możesz sprawdzić łańcuch certyfikatów za pomocą OpenSSL:

openssl s_client -connect ldap.example.net:636 \
  -servername ldap.example.net -showcerts

W przypadku katalogu korzystającego ze standardowego protokołu LDAP i StartTLS, przetestuj punkt końcowy obsługujący StartTLS za pomocą klienta LDAP odpowiedniego dla Twojego systemu operacyjnego. Jeśli ldapsearchjest zainstalowany, sprawdzenie konta wyszukiwania może wyglądać następująco:

ldapsearch -x -H ldap://ldap.example.net:389 -ZZ \
  -D "cn=zimbra-search,ou=svc,dc=example,dc=net" -W \
  -b "ou=people,dc=example,dc=net" \
  "(uid=alice)" dn

W Podręczniku administratora Zimbra v10 stwierdzono, że ldaps:punkt końcowy wymaga certyfikatu serwera LDAP, aby był zaufany przez Zimbra. Nie należy pomijać weryfikacji certyfikatu tylko po to, aby test zakończył się pomyślnie. Zainstaluj odpowiedni urząd certyfikacji lub łańcuch certyfikatów zgodnie z procedurą magazynu zaufanych certyfikatów dla konkretnej kompilacji Zimbra.

Krok 3: Skonfiguruj szablon bezpośredniego powiązania nazwy wyróżniającej, gdy nazwy wyróżniające użytkowników są przewidywalne

To najprostszy schemat. Załóżmy, że katalog zewnętrzny przechowuje użytkowników jako , uid=alice,ou=people,dc=example,dc=neta login Zimbra to alice@example.com. Skonfiguruj domenę w następujący sposób:

zmprov md example.com zimbraAuthMech ldap

zmprov md example.com \
  zimbraAuthLdapURL "ldaps://ldap.example.net:636"

zmprov md example.com \
  zimbraAuthLdapBindDn "uid=%u,ou=people,dc=example,dc=net"

W Podręczniku administratora opisano zimbraAuthLdapBindDnciąg formatujący używany do określenia nazwy wyróżniającej (DN) używanej do zewnętrznego powiązania. Oficjalna dokumentacja Centrum Technicznego Zimbra opisuje typowe wartości zastępcze, takie jak %udla lokalnej części nazwy logowania i %ndla pełnej nazwy logowania.

Użyj szablonu DN tylko wtedy, gdy deterministycznie identyfikuje on właściwy obiekt katalogu. Jeśli użytkownicy znajdują się w różnych jednostkach organizacyjnych lub ich DN nie jest generowany na podstawie nazwy logowania, użyj zamiast tego wzorca filtra wyszukiwania.

Krok 4: Użyj mapowania filtrów wyszukiwania, jeśli nazwy wyróżniającej nie można utworzyć bezpośrednio

Mapowanie filtrów wyszukiwania pozwala Zimbrze najpierw zlokalizować wpis użytkownika, a następnie uwierzytelnić się na podstawie zwróconej nazwy wyróżniającej (DN). Podręcznik konfiguracji v10 definiuje wymagane atrybuty domeny związane z wyszukiwaniem.

Typowa konfiguracja w stylu OpenLDAP wygląda następująco:

zmprov md example.com \
  zimbraAuthLdapSearchBase "ou=people,dc=example,dc=net"

zmprov md example.com \
  zimbraAuthLdapSearchFilter "(uid=%u)"

zmprov md example.com \
  zimbraAuthLdapSearchBindDn \
  "cn=zimbra-search,ou=svc,dc=example,dc=net"

Aby uniknąć umieszczania hasła katalogu bezpośrednio w historii powłoki, najpierw wczytaj je do tymczasowej zmiennej powłoki:

read -s LDAP_BIND_PASSWORD
zmprov md example.com \
  zimbraAuthLdapSearchBindPassword "$LDAP_BIND_PASSWORD"
unset LDAP_BIND_PASSWORD

Konto wyszukiwania powinno mieć jedynie dostęp do odczytu niezbędny do wyszukiwania użytkowników w skonfigurowanej bazie. Nie wymaga szerokich uprawnień administratora katalogów.

W przypadku Active Directory filtr może używać sAMAccountNamelub userPrincipalName, w zależności od konwencji logowania. Zimbra oferuje również zewnętrzny mechanizm uwierzytelniania Active Directory, więc używaj mechanizmu specyficznego dla Active Directory, gdy lepiej pasuje do Twojego wdrożenia, zamiast wymuszać na każdym środowisku Active Directory korzystanie z ogólnych ustawień LDAP.

Krok 5: Sprawdź, co faktycznie zapisała Zimbra

Odczytaj atrybuty domeny po zmianie:

zmprov gd example.com \
  zimbraAuthMech \
  zimbraAuthLdapURL \
  zimbraAuthLdapBindDn \
  zimbraAuthLdapSearchBase \
  zimbraAuthLdapSearchFilter \
  zimbraAuthLdapSearchBindDn \
  zimbraAuthFallbackToLocal

Sprawdź, czy nie ma błędów w cytowaniu, nieprawidłowej nazwy bazy, nieoczekiwanej nazwy hosta lub starego mapowania pozostawionego z poprzedniej próby. Nie zapisuj hasła powiązania wyszukiwania w dokumentacji, zrzutach ekranu, zgłoszeniach ani transkryptach powłoki.

Krok 6: Przeprowadź test na jednym kontrolowanym użytkowniku przed szerokim wdrożeniem

Wybierz konto testowe inne niż administrator, które istnieje zarówno w Zimbrze, jak i w katalogu zewnętrznym. Przetestuj te przypadki celowo:

• Prawidłowe zewnętrzne hasło LDAP umożliwia zalogowanie się do Zimbra.
• Nieprawidłowe zewnętrzne hasło LDAP zostało odrzucone.
• Wyłączone lub zablokowane konto katalogowe zachowuje się zgodnie z polityką katalogową.
• Użytkownik konta Zimbra, które nie istnieje, nie będzie mógł się zalogować, jeśli nie skonfigurowano automatycznego udostępniania.
• Awaria serwera LDAP lub sieci powoduje oczekiwane zachowanie systemu.

Ostatni test ma znaczenie, ponieważ zimbraAuthFallbackToLocaljest to opcja oddzielnej domeny. W dokumentacji v10 podano, że domyślną opcją jest FALSE. Włączenie trybu zapasowego może być przydatne w przypadku starannie zaplanowanej migracji, ale może również przeczyć oczekiwaniom, że wyłączenie lub zmiana hasła w katalogu zewnętrznym natychmiast blokuje dostęp, jeśli stare lokalne hasło Zimbra pozostaje ważne. Tryb zapasowy należy traktować jako decyzję podjętą w ramach polityki bezpieczeństwa, a nie jako ogólną zmianę w rozwiązywaniu problemów.

Krok 7: Zdecyduj, czy potrzebujesz również automatycznego udostępniania

Uwierzytelnianie zewnętrzne i konfiguracja kont to różne funkcje. Jeśli nowi użytkownicy katalogu mają automatycznie otrzymywać konta Zimbra, należy osobno skonfigurować automatyczną konfigurację Zimbra. Aktualny Podręcznik administratora w wersji 10 opisuje tryby EAGER, LAZY i MANUAL oraz ich własne zimbraAutoProv*atrybuty.

Nie używaj ponownie ustawień uwierzytelniania bezmyślnie do automatycznego udostępniania. Automatyczne udostępnianie ma oddzielne opcje adresu URL, powiązania, bazy wyszukiwania, filtrowania, mapowania nazw kont i mapowania atrybutów. Najpierw zadbaj o to, aby uwierzytelnianie zewnętrzne było niezawodne dla istniejącego użytkownika, a następnie zaprojektuj udostępnianie jako drugą zmianę.

Typowe wzorce awarii i co należy sprawdzić

Plan wycofania

Jeżeli konfiguracja zewnętrznego katalogu uniemożliwia normalne uwierzytelnianie użytkownika, należy przełączyć domenę z powrotem na wewnętrzne uwierzytelnianie Zimbra, korzystając z otwartej już sesji administratora:

zmprov md example.com zimbraAuthMech zimbra

Następnie sprawdź wartość:

zmprov gd example.com zimbraAuthMech

Nie usuwaj zewnętrznych atrybutów LDAP podczas awaryjnego przywracania, chyba że masz ku temu powód. Zachowanie ich na miejscu ułatwia sprawdzenie, co się nie powiodło, i ponowienie próby po rozwiązaniu problemu z mapowaniem lub TLS.

Podsumowanie praktycznych wskazówek

• zimbraAuthMech: wybiera mechanizm uwierzytelniania dla domeny.
• zimbraAuthLdapURL: zewnętrzny punkt końcowy LDAP; używany ldaps:do LDAP przez SSL.
• zimbraAuthLdapBindDn: format używany do konstruowania nazwy wyróżniającej użytkownika na potrzeby bezpośredniego wiązania.
• zimbraAuthLdapSearchBase: poddrzewo, w którym Zimbra wyszukuje użytkownika zewnętrznego.
• zimbraAuthLdapSearchFilter:Filtr LDAP służący do lokalizacji użytkownika.
• zimbraAuthLdapSearchBindDnoraz zimbraAuthLdapSearchBindPassword: dane uwierzytelniające używane do wyszukiwania, gdy wyszukiwanie anonimowe nie jest odpowiednie.
• zimbraAuthLdapExternalDn: jawne zewnętrzne mapowanie DN dla pojedynczego konta Zimbra.
• zimbraAuthFallbackToLocal: kontroluje, czy Zimbra powróci do uwierzytelniania lokalnego, jeśli uwierzytelnianie zewnętrzne się nie powiedzie.

Ostateczna lista kontrolna walidacji

• Zewnętrzny punkt końcowy LDAP jest dostępny z serwera pocztowego Zimbra.
• Walidacja certyfikatu TLS przebiega pomyślnie, bez niebezpiecznych obejść.
• Wybrany szablon bind-DN ​​lub filtr wyszukiwania mapuje jedno logowanie na dokładnie jeden wpis w katalogu.
• Użytkownik testowy istnieje w systemie Zimbra lub celowo skonfigurowano automatyczne udostępnianie.
• Testy poprawności i niepoprawności hasła działają zgodnie z oczekiwaniami.
• Zachowanie awaryjne jest zgodne z polityką bezpieczeństwa.
• Oryginalne ustawienia domeny i polecenie wycofania są udokumentowane.

W przypadku zmian produkcyjnych lepiej jest wdrażać etapami, z jedną domeną testową lub niewielką grupą użytkowników. Zewnętrzne uwierzytelnianie LDAP jest proste, gdy mapowanie tożsamości jest przewidywalne; najpoważniejsze błędy wynikają z mapowania nazw domen (DN), zaufania certyfikatów lub mylenia uwierzytelniania z konfiguracją kont.