NetExtender se přihlásí, ale přístup žádný: SonicWall lokální + LDAP

Přihlášení proběhne, tunel se zvedne a nic za firewallem neodpovídá. Tento vzorec na SonicWall SSL VPN obvykle znamená, že účet prošel autentizací a zastavil se u jednoho ze dvou pozdějších oprávnění: přijetí do služby SSL VPN, nebo povolení dosáhnout na prostředek. Smíšené lokální účty a účty LDAP to zhoršují, protože oba úložiště dosahují těchto oprávnění různými cestami. Pro klienta je příznak stejný, a proto je třeba vrstvy záměrně oddělit.

Příznak a tři oprávnění za ním

Mezi uživatelským jménem a dostupným serverem stojí tři nezávislá rozhodnutí. Metoda autentizace rozhoduje, zda budou přihlašovací údaje přijaty a kterým úložištěm. Členství ve službě SSL VPN rozhoduje, zda tato identita vůbec smí SSL VPN používat. Seznam VPN Access rozhoduje, kterých privátních cílů smí relace dosáhnout. Projít jedním nic neříká o dalších dvou.

Uživatel, který se autentizuje, ale není ve skupině služby SSL VPN, vidí spojení, které se naváže a pak nic nepřenáší, a log firewallu ukazuje přijaté přihlášení místo selhání. To je případ, který je vhodné rychle rozpoznat, protože řešením je členství ve skupině, nikoli reset hesla.

Uživatel, který je přijat, ale nemá žádné prostředky, vidí relaci, která se připojí a nikam užitečně nesměruje. Oba případy vypadají z pohledu helpdesku jako rozbitý tunel a oba jsou konfigurací, nikoli konektivitou.

Pole domény není adresář

NetExtender se ptá na doménu a toto pole není vyhledávací základna pro Active Directory. Ve výchozím uspořádání se pole musí rovnat doméně uživatele SSL VPN, kterou má firewall nakonfigurovanou, a dokumentovaná výchozí hodnota je LocalDomain. Porovnání rozlišuje velikost písmen, takže hodnota zadaná s jinou velikostí písmen selže, i když je účet správný.

Je-li nakonfigurováno dělení autentizace, vybírají externí kontext autentizace názvy oddílů a nakonfigurovaná výchozí hodnota si zachovává svou roli. V obou uspořádáních se doménový štítek na straně klienta nepředává do LDAP ani RADIUS jako součást uživatelského jména, takže nemůže řídit vyhledávání v adresáři.

Uchovávejte tři řetězce v poznámkách odděleně: suffix DNS společnosti, vyhledávací základnu LDAP a doménový štítek NetExtender. Vypadají podobně a žádný z nich nenahrazuje jiný. Zkopírujte hodnotu provozovatele pro tuto instalaci, nikoli hodnotu z příspěvku na fóru o jiné verzi firmwaru.

Přijetí a přístup k prostředkům jsou oddělená oprávnění

Lokální účty potřebují členství ve skupině služby SSL VPN, než je služba přijme. Účty z adresáře dosahují stejné skupiny podporovaným postupem mapování skupin, což znamená, že vztah skupiny LDAP je třeba nakonfigurovat a poté ověřit jako účinné členství, místo aby se předpokládal ze strany adresáře.

Přístup k prostředkům přichází dále, v části VPN Access u uživatele nebo skupiny. Přidělte konkrétní podsítě a služby, které role potřebuje, a odolejte zkratce přidělit celou LAN, protože je potřeba jedna aplikace. Trasy relace, pravidla přístupu a oprávnění cílové služby musí všechny odpovídat tomuto rozsahu.

Trasa na klientovi činí cíl volitelným a neautorizuje jej. Členství ve skupině SSL VPN z účtu také nedělá správce firewallu a nemělo by se považovat za obecné udělení privilegií.

Dvě identity, čtyři kontroly pro každou

Testujte s jedním lokálním účtem a jedním účtem z adresáře, oba úzce autorizované a oba dokumentované jako testovací účty. U každého zaznamenejte zdroj autentizace, který přihlášení přijal, efektivní skupiny, přidělený přístup k prostředkům a jednu povolenou operaci aplikace. Čtyři kontroly, dvě úložiště a písemný výsledek pro každou kombinaci.

Poté otestujte negativní případy: prostředek, na který účet nemá dosáhnout, a účet, který má být rovnou odmítnut. Návrh, který prokazuje jen pozitivní cestu, obvykle nechává otevřený druhý vchod, zvláště když stejné krátké uživatelské jméno existuje v obou úložištích. Zakažte účet z adresáře a ověřte, že lokální potichu nefunguje dál.

Duplicitní jména prověřte jako součást zavádění, ne až po incidentu. Stejná osoba ve dvou úložištích je zároveň podpůrná výhoda i problém pro audit a firewall ochotně autentizuje ten, který jste nakonfigurovali.

Udržte obnovovací cestu úzkou

Zachovejte zásady MFA pro každou třídu účtů, místo abyste z nich lokální účty vyjímali. Pokud lokální účty poskytují schválenou obnovovací cestu pro výpadek adresáře, je třeba ji omezit na jmenované administrátory a provozovat ji vědomě, protože lokální nouzový účet pro každého zaměstnance je druhý autentizační systém se slabším dohledem.

Zapište doménu klienta, zdroj autentizace a efektivní přístup do stejného záznamu. Další administrátor pak může zopakovat funkční návrh smíšených účtů, místo aby zkoušel řetězce domén, dokud se přihlášení nepovede.