Skupinový alias versus skupinová URL v ASA: jak se profil vybírá
Skupinový alias je položka v přihlašovacím seznamu, nikoli mapování URL. Sledujte, jak ASA profil vybírá, a pak si přečtěte politiku, kterou relace skutečně dostane.
Profil připojení řídí relaci až poté, co ho ASA vybere. Tahle věta je celý model řešení potíží pro starý portál bez klienta. Nepoužívaný profil může mít bezvadná pravidla přístupu a přesto se na nikoho nevztahovat. Sledujte vstupní bod přihlášení, než upravíte jakoukoli politiku.
Níže uvedené rozdíly vycházejí z dokumentace k 9.16; SSL VPN bez klienta byla odstraněna v 9.17(1) a později.
Alias je položka seznamu, ne URL
group-alias poskytuje označení, které uživatel vybírá ze seznamu skupin na přihlašovací stránce. Zobrazení tohoto seznamu je samostatné nastavení, tunnel-group-list enable. Alias je jen název pro volbu a nic víc. Konfigurace aliasu s názvem staff nevytváří URL /staff, která by profil vybírala.
Lidé očekávají, že alias bude plnit dvojí roli, protože seznam i URL vypadají z prohlížeče jako stejná volba.
Čemu group-url skutečně odpovídá
group-url váže příchozí URL k profilu připojení. Když se tato povolená URL shoduje, ASA vybere profil, aniž by uživatele žádala o volbu ze seznamu. URL musí být úplná a přesně ta zamýšlená, v syntaxi, kterou vaše verze podporuje. Její záznam DNS a certifikát musí odpovídat tomu, co uživatelé zadávají, jinak se shoda nikdy neuskuteční.
Zkopírovaný suffix URL nic o konfiguraci nedokazuje. Kontrolujte profil, ne adresní řádek.
Sledujte volbu až do politiky, která se provádí
Po výběru tunelové skupiny zařízení vyhodnotí metodu ověřování a výchozí skupinovou politiku, která je k ní připojená. Potom atributy specifické pro uživatele, hodnoty vrácené ověřováním a dynamická autorizace mohou přepsat části tohoto základu. Prohlédněte si, co relace skutečně dostala. Čtení pojmenované politiky samo o sobě vám dá základ, ne výsledek.
Mezera mezi těmito dvěma je zdrojem většiny hlášení „pravidlo je správné, ale přístup je špatný“.
Dědičnost není izolace
Atributy, které necháte neurčené, mohou dědit z výchozí skupinové politiky. Nová pojmenovaná politika tedy není oddělena od sdílených výchozích hodnot a úprava těchto hodnot zasáhne každý profil, který je dědí. Porovnejte efektivní přístup ke zdrojům, nastavení DNS a omezení relace pro každý profil. Udělejte to dřív, než změníte cokoli sdíleného.
Vynucování přístupu držte také oddělené od volby.
Pro relaci bez klienta je použitelným filtrem ACL webtype. VPN filtr pro tunelového klienta ho nenahrazuje jen proto, že oba leží blízko stejného bloku politiky v konfiguraci.
Rozhodněte případ bez shody a pak otestujte každou cestu
Určete, co se má dít na obecné URL portálu a na dalších vstupních bodech bez shody. Podívejte se na skutečnou cestu výchozího profilu a jeho autorizaci, místo abyste upravovali sdílenou výchozí hodnotu, aby prošel jeden testovací účet. Pak otevřete tři nové relace: explicitní URL, povolenou položku seznamu a obecný vstupní bod. Zapište vybraný profil a efektivní politiku pro každou z nich.
Opětovné použití karty prohlížeče z dřívějšího přihlášení srovnání zničí, protože tato relace je už vázaná na profil.
Tento záznam promění „portál se otevře“ v mapování přihlášení na politiku, které můžete později auditovat, a to je jediná trvalá odpověď, když profil vypadá správně a nikomu nevládne.