NetExtender se conectează, dar fără acces: SonicWall local + LDAP

Autentificarea reușește, tunelul se ridică și nimic din spatele firewallului nu răspunde. Acest model pe un SonicWall SSL VPN înseamnă de obicei că contul a trecut autentificarea și s-a oprit la una dintre cele două autorizări ulterioare: admiterea în serviciul SSL VPN sau permisiunea de a ajunge la o resursă. Conturile locale și LDAP amestecate înrăutățesc situația, pentru că cele două depozite ajung la aceste autorizări pe căi diferite. Simptomul este identic din partea clientului, motiv pentru care straturile trebuie separate în mod deliberat.

Simptomul și cele trei autorizări din spate

Trei decizii independente stau între un nume de utilizator și un server accesibil. Metoda de autentificare decide dacă acreditarea este acceptată și de ce depozit. Apartenența la serviciul SSL VPN decide dacă acea identitate poate folosi SSL VPN. Lista de acces VPN decide ce destinații private poate atinge sesiunea. Trecerea de una nu spune nimic despre următoarele două.

Un utilizator care se autentifică, dar nu este în grupul serviciului SSL VPN, vede o conexiune care se stabilește și apoi nu transportă nimic, iar jurnalul firewallului arată o autentificare acceptată în loc de o eroare. Este cazul care merită recunoscut repede, pentru că soluția este o apartenență la grup, nu o resetare a parolei.

Un utilizator admis, dar fără resurse, vede o sesiune care se conectează și nu rutează nicăieri util. Ambele arată ca un tunel defect din perspectiva helpdesk-ului, iar ambele sunt configurare, nu conectivitate.

Câmpul de domeniu nu este directorul

NetExtender cere un domeniu, iar acel câmp nu este o bază de căutare pentru Active Directory. În configurația implicită, câmpul trebuie să fie egal cu domeniul de utilizator SSL VPN configurat pe firewall, iar valoarea implicită documentată este LocalDomain. Comparația distinge majusculele de minuscule, așa că o valoare introdusă cu altă capitalizare eșuează chiar dacă contul este corect.

Cu partiționarea autentificării configurată, numele partițiilor selectează contextul de autentificare extern, iar valoarea implicită configurată își păstrează propriul rol. În ambele configurații, eticheta de domeniu din partea clientului nu este transmisă către LDAP sau RADIUS ca parte a numelui de utilizator, deci nu poate direcționa o căutare în director.

Țineți cele trei șiruri separate în note: sufixul DNS al companiei, baza de căutare LDAP și eticheta de domeniu NetExtender. Se aseamănă și niciuna nu o înlocuiește pe alta. Copiați valoarea operatorului pentru această instalare, nu o valoare dintr-un mesaj de forum despre altă versiune de firmware.

Admiterea și accesul la resurse sunt autorizări separate

Conturile locale au nevoie de apartenența la grupul serviciului SSL VPN înainte ca serviciul să le accepte. Conturile de director ajung în același grup prin fluxul de mapare a grupurilor acceptat, ceea ce înseamnă că relația de grup LDAP trebuie configurată și apoi verificată ca apartenență efectivă, nu presupusă din partea directorului.

Accesul la resurse vine apoi, sub Acces VPN la utilizator sau la grup. Acordați subrețelele și serviciile concrete de care are nevoie rolul și rezistați scurtăturii de a acorda întregul LAN pentru că este nevoie de o aplicație. Rutele sesiunii, regulile de acces și permisiunile serviciului de destinație trebuie toate să corespundă acestui domeniu.

O rută pe client face o destinație selectabilă și nu o autorizează. Apartenența la grupul SSL VPN nu face nici contul administrator de firewall și nu trebuie tratată ca o acordare generală de privilegii.

Două identități, câte patru verificări

Testați cu un cont local și un cont de director, ambele autorizate strict și ambele documentate ca conturi de test. Pentru fiecare, înregistrați sursa de autentificare care a acceptat conectarea, grupurile efective, accesul la resurse atribuit și o operațiune de aplicație permisă. Patru verificări, două depozite și un rezultat scris pentru fiecare combinație.

Apoi testați cazurile negative: o resursă la care contul nu trebuie să ajungă și un cont care trebuie respins direct. Un design care dovedește doar calea pozitivă tinde să lase o a doua intrare deschisă, mai ales când același nume scurt de utilizator există în ambele depozite. Dezactivați contul de director și confirmați că cel local nu continuă să funcționeze în tăcere.

Examinați numele duplicate ca parte a implementării, nu după un incident. Aceeași persoană în două depozite este simultan o comoditate pentru suport și o problemă de audit, iar firewallul va autentifica bucuros pe cel pe care l-ați configurat.

Păstrați îngustă calea de recuperare

Păstrați politica MFA pentru fiecare clasă de cont în loc să scutiți conturile locale de la ea. Dacă conturile locale oferă o cale de recuperare aprobată pentru o pană de director, limitați acea cale la administratori numiți și operați-o deliberat, pentru că un cont local de urgență pentru fiecare angajat este un al doilea sistem de autentificare cu supraveghere mai slabă.

Scrieți domeniul clientului, sursa de autentificare și accesul efectiv în aceeași înregistrare. Următorul administrator poate apoi reproduce un design funcțional de conturi mixte în loc să încerce șiruri de domenii până când reușește o conectare.