ASA-gruppalias kontra grupp-URL: hur profilen väljs

En anslutningsprofil styr en session först efter att ASA har valt den. Den meningen är hela felsökningsmodellen för en gammal klientlös portal. En oanvänd profil kan ha perfekta åtkomstregler och ändå inte gälla för någon. Följ inloggningens ingångspunkt innan du redigerar någon policy.

Skillnaderna nedan följer dokumentationen för 9.16; klientlös SSL VPN togs bort i 9.17(1) och senare.

Aliaset är en listpost, inte en URL

group-alias ger en etikett som användaren väljer från grupplistan på inloggningssidan. Att visa listan är en separat inställning, tunnel-group-list enable. Aliaset är ett valnamn och inget mer. Att konfigurera ett alias som heter staff skapar ingen /staff-URL som väljer profilen.

Folk förväntar sig att aliaset ska göra dubbelt arbete, eftersom listan och URL:en inifrån en webbläsare ser ut som samma val.

Vad group-url faktiskt matchar

group-url binder en inkommande URL till en anslutningsprofil. När den aktiverade URL:en matchar väljer ASA profilen utan att be användaren välja från listan. URL:en måste vara den fullständiga avsedda, i den syntax din version stöder. Dess DNS-post och certifikat måste stämma med det användarna skriver, annars sker aldrig matchningen.

Ett kopierat URL-suffix bevisar ingenting om konfigurationen. Kontrollera profilen, inte adressfältet.

Följ valet in i policyn som körs

När en tunnelgrupp har valts löser enheten upp autentiseringsmetoden och den standardgruppolicy som är kopplad till den. Därefter kan användarspecifika attribut, värden som autentiseringen returnerar och dynamisk auktorisering åsidosätta delar av den basen. Granska vad sessionen faktiskt fick. Att läsa den namngivna policyn för sig ger basen, inte resultatet.

Gapet mellan de två är källan till de flesta rapporter om »regeln är rätt men åtkomsten är fel«.

Arv är inte isolering

Attribut som du lämnar ospecificerade kan ärvas från standardgruppolicyn. En ny namngiven policy är därför inte avskild från delade standardvärden, och redigering av dem når varje profil som ärver dem. Jämför den effektiva resursåtkomsten, DNS-inställningarna och sessionsbegränsningarna per profil. Gör det innan du ändrar något delat.

Håll också genomdrivandet av åtkomst åtskilt från valet.

För en klientlös session är det tillämpliga filtret webtype-ACL:en. Ett VPN-filter för tunnelklienter ersätter det inte bara för att båda ligger nära samma policyblock i konfigurationen.

Avgör fallet utan matchning och testa sedan varje väg

Bestäm vad som ska hända på portalens generiska URL och vid andra ingångspunkter utan matchning. Titta på den verkliga standardprofilvägen och dess auktorisering i stället för att redigera en delad standard så att ett enda testkonto kommer igenom. Öppna sedan tre nya sessioner: den explicita URL:en, den aktiverade listposten och den generiska ingångspunkten. Notera den valda profilen och den effektiva policyn för var och en.

Att återanvända en webbläsarflik från en tidigare inloggning förstör jämförelsen, eftersom den sessionen redan är bunden till en profil.

Den registreringen gör »portalen öppnas« till en mappning från inloggning till policy som du kan granska senare, och det är det enda hållbara svaret när en profil ser korrekt ut och inte styr någon.