ASA-groepsalias versus groeps-URL: hoe het profiel wordt gekozen

Een verbindingsprofiel beheert een sessie pas nadat de ASA het heeft gekozen. Die ene zin is het hele probleemoplossingsmodel voor een oud clientloos portaal. Een ongebruikt profiel kan perfecte toegangsregels hebben en toch voor niemand gelden. Volg het aanmeldpunt voordat u welk beleid dan ook wijzigt.

De onderstaande verschillen volgen de 9.16-documentatie; clientloze SSL VPN is verwijderd in 9.17(1) en later.

De alias is een lijstregel, geen URL

group-alias levert een label dat de gebruiker kiest uit de groepenlijst op de aanmeldpagina. Die lijst tonen is een aparte instelling, tunnel-group-list enable. De alias is een keuzenaam en niets meer. Een alias met de naam staff configureren maakt geen /staff-URL die het profiel kiest.

Mensen verwachten dat de alias dubbel werk doet, omdat de lijst en de URL vanuit de browser op dezelfde keuze lijken.

Wat group-url werkelijk vergelijkt

group-url koppelt een inkomende URL aan een verbindingsprofiel. Wanneer die geactiveerde URL overeenkomt, kiest de ASA het profiel zonder de gebruiker te vragen uit de lijst te kiezen. De URL moet de volledige bedoelde zijn, in de syntaxis die uw versie ondersteunt. Het DNS-record en het certificaat moeten overeenkomen met wat gebruikers invoeren, anders komt de overeenkomst nooit tot stand.

Een gekopieerd URL-achtervoegsel bewijst niets over de configuratie. Controleer het profiel, niet de adresbalk.

Volg de keuze tot in het beleid dat draait

Zodra een tunnelgroep is gekozen, bepaalt het apparaat de authenticatiemethode en het standaardgroepsbeleid dat eraan hangt. Daarna kunnen gebruikersspecifieke attributen, waarden die authenticatie teruggeeft en dynamische autorisatie delen van die basis overschrijven. Onderzoek wat de sessie werkelijk heeft ontvangen. Het genoemde beleid op zichzelf lezen geeft de basis, niet de uitkomst.

Het verschil tussen beide is de bron van de meeste meldingen «de regel klopt, maar de toegang niet».

Overerving is geen isolatie

Attributen die u ongespecificeerd laat, kunnen erven van het standaardgroepsbeleid. Een nieuw genoemd beleid is dus niet afgesloten van gedeelde standaardwaarden, en het wijzigen daarvan bereikt elk profiel dat ze erft. Vergelijk de effectieve resourcetoegang, DNS-instellingen en sessiebeperkingen per profiel. Doe dat voordat u iets gedeelds wijzigt.

Houd ook de handhaving van toegang gescheiden van de keuze.

Voor een clientloze sessie is het toepasselijke filter de webtype-ACL. Een VPN-filter voor tunnelclients is geen vervanging, alleen omdat beide in de configuratie bij hetzelfde beleidsblok staan.

Beslis het niet-overeenkomende geval en test daarna elk pad

Bepaal wat er moet gebeuren op de generieke URL van het portaal en op andere niet-overeenkomende toegangspunten. Kijk naar het echte standaardprofielpad en de autorisatie ervan in plaats van een gedeelde standaard te wijzigen zodat één testaccount erdoor komt. Open daarna drie nieuwe sessies: de expliciete URL, de geactiveerde lijstregel en het generieke toegangspunt. Noteer het gekozen profiel en het effectieve beleid voor elk daarvan.

Een browsertab van een eerdere aanmelding hergebruiken bederft de vergelijking, omdat die sessie al aan een profiel gebonden is.

Die registratie maakt van «het portaal opent» een toewijzing van aanmelding aan beleid die u later kunt auditen, en dat is het enige duurzame antwoord wanneer een profiel correct lijkt en niemand beheert.