ASA-gruppealias mot gruppe-URL: hvordan profilen blir valgt

En tilkoblingsprofil styrer en sesjon først etter at ASA har valgt den. Den setningen er hele feilsøkingsmodellen for en gammel klientløs portal. En ubrukt profil kan ha perfekte tilgangsregler og likevel ikke gjelde for noen. Følg påloggingens inngangspunkt før du redigerer noen policy.

Forskjellene nedenfor følger 9.16-dokumentasjonen; klientløs SSL VPN ble fjernet i 9.17(1) og senere.

Aliaset er en listepost, ikke en URL

group-alias gir en etikett som brukeren velger fra gruppelisten på påloggingssiden. Å vise den listen er en egen innstilling, tunnel-group-list enable. Aliaset er et valgnavn og ikke noe mer. Å konfigurere et alias kalt staff oppretter ikke en /staff-URL som velger profilen.

Folk forventer at aliaset gjør dobbelt arbeid, fordi listen og URL-en fra nettleseren ser ut som det samme valget.

Hva group-url faktisk matcher

group-url binder en innkommende URL til en tilkoblingsprofil. Når den aktiverte URL-en matcher, velger ASA profilen uten å be brukeren velge fra listen. URL-en må være den komplette tiltenkte, i syntaksen versjonen din støtter. DNS-oppføringen og sertifikatet må stemme med det brukerne skriver, ellers får matchingen aldri skje.

Et kopiert URL-suffiks beviser ingenting om konfigurasjonen. Kontroller profilen, ikke adresselinjen.

Følg valget inn i policyen som kjøres

Når en tunnelgruppe er valgt, løser enheten opp autentiseringsmetoden og standardgruppepolicyen som er knyttet til den. Deretter kan brukerspesifikke attributter, verdier autentiseringen returnerer og dynamisk autorisasjon overstyre deler av dette grunnlaget. Undersøk hva sesjonen faktisk mottok. Å lese den navngitte policyen alene gir deg grunnlaget, ikke resultatet.

Gapet mellom de to er opphavet til de fleste rapportene om «regelen er riktig, men tilgangen er feil».

Arv er ikke isolasjon

Attributter du lar være uspesifiserte, kan arves fra standardgruppepolicyen. En ny navngitt policy er derfor ikke lukket fra delte standardverdier, og redigering av dem når hver profil som arver dem. Sammenlign faktisk ressurstilgang, DNS-innstillinger og sesjonsbegrensninger per profil. Gjør det før du endrer noe delt.

Hold også håndhevingen av tilgang atskilt fra valget.

For en klientløs sesjon er det aktuelle filteret webtype-ACL-en. Et VPN-filter for tunnelklienter er ikke en erstatning bare fordi begge ligger nær samme policyblokk i konfigurasjonen.

Avgjør tilfellet uten match, og test deretter hver vei

Bestem hva som skal skje på portalens generiske URL og ved andre inngangspunkter uten match. Se på den reelle standardprofilveien og autorisasjonen dens i stedet for å redigere en delt standard slik at én testkonto slipper gjennom. Åpne deretter tre ferske sesjoner: den eksplisitte URL-en, den aktiverte listeposten og det generiske inngangspunktet. Noter den valgte profilen og den effektive policyen for hver av dem.

Gjenbruk av en nettleserfane fra en tidligere pålogging ødelegger sammenligningen, fordi den sesjonen allerede er bundet til en profil.

Den registreringen gjør «portalen åpnes» om til en tilordning fra pålogging til policy som du kan revidere senere, og det er det eneste varige svaret når en profil ser riktig ut og ikke styrer noen.