Certyfikat VPN nie chroni odcinka LDAP

Logowanie VPN, które sprawdza poświadczenia w katalogu, obejmuje dwa osobne połączenia sieciowe. Połączenie użytkownika z bramą jest chronione przez własny certyfikat VPN i konfigurację protokołu. Połączenie bramy z katalogiem to inna sesja z własnymi ustawieniami TLS, własnym magazynem zaufania i własnymi trybami awarii. Nic w pierwszym nie gwarantuje niczego w drugim.

Ta asymetria jest mechanizmem stojącym za logowaniem, które wygląda na zaszyfrowane, a mimo to wysyła hasło bind jawnym tekstem.

Dwa połączenia, dwie decyzje o zaufaniu

Sesja zewnętrzna to, co widzi użytkownik: certyfikat powiązany z nazwą hosta VPN, zweryfikowany przez klienta, przenoszący wymianę uwierzytelniania. Sesja wewnętrzna należy do klienta katalogu wewnątrz bramy, który otwiera własne połączenie i albo negocjuje TLS, albo nie. Każda strona weryfikuje rozmówcę, z którym mówi, używając materiału z innego pliku konfiguracyjnego. Źle skonfigurowany odcinek wewnętrzny pozostaje niewidoczny od strony użytkownika, ponieważ odcinek zewnętrzny działa dokładnie tak, jak zamierzono.

Dlatego awaria jest cicha, a nie głośna. Brama, która nigdy nie sprawdza certyfikatu katalogu, nadal uwierzytelnia użytkowników poprawnie; po prostu uwierzytelnia ich kanałem, którego nie zweryfikowała.

StartTLS i LDAPS, wybrane świadomie

StartTLS otwiera się jako zwykły LDAP i jest podnoszony na miejscu, zwykle na porcie 389. LDAPS rozpoczyna TLS wraz z połączeniem, zwykle na 636. Oba są zgodne z prawem i adapter musi pasować do tego, co oferuje katalog. Wymaganie StartTLS to coś innego niż wypróbowanie go i kontynuowanie, gdy podniesienie się nie powiedzie, i właśnie w tej różnicy hasło bind może wyciec. Skonfiguruj tryb ścisły i nie zezwalaj na niechronioną ścieżkę zapasową dla bindu z hasłem.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

Opcja -ZZ to cała istota: zapytanie kończy się niepowodzeniem zamiast po cichu kontynuować bez podniesienia. Nazwy i konta w tym wierszu są przykładami. Dokumentacja TLS OpenLDAP opisuje stojące za tym ustawienia zaufania.

Który magazyn zaufania czyta klient LDAP?

Biblioteka klienta OpenLDAP czyta własną konfigurację zaufania, czy to z pliku systemowego, czy z ustawienia specyficznego dla wtyczki. Dyrektywa CA w VPN dotyczy partnerów VPN i nie jest dowodem, że biblioteka LDAP czyta ten sam plik. Użyj nazwy hosta katalogu, którą certyfikat faktycznie obejmuje, oraz łańcucha wydawcy, któremu biblioteka ufa. W usłudze Active Directory wdróż certyfikat usługi katalogowej z właściwym zastosowaniem do uwierzytelniania serwera, zamiast wnioskować z nazwy wyświetlanej.

Każdy cel przełączenia awaryjnego musi spełniać tę samą politykę tożsamości. Środowisko, w którym podstawowy jest weryfikowany, a zapasowy nie, jest gorsze od takiego bez przełączenia, ponieważ słabsza ścieżka ujawnia się dopiero podczas awarii.

Konto bind pozostaje osobnym problemem

Ochrona transportu nie zmniejsza tego, co może robić konto bind. Zakres wyszukiwania w katalogu, autoryzacja grupowa i uprawnienia konta usługi to odrębne decyzje, a szerokie konto bind pozostaje szerokie po włączeniu TLS. Użyj najwęższego konta usługi i bazy wyszukiwania, których potrzebuje integracja, i zapisz punkt końcowy, tryb TLS, właściciela zaufania i proces odnawiania razem z konfiguracją VPN.

Gdy pojawi się niezgodność certyfikatu, wdróż właściwy certyfikat lub łańcuch. Wyłączenie weryfikacji zamienia widoczną niezgodność w niewidoczną i pozostawia drugą relację zaufania bez testu.

Dwa połączenia, dwóch właścicieli, dwie daty odnowienia. Trzymanie ich osobno w dokumentacji jest tym, co utrzymuje logowanie uczciwym.