ASA-gruppealias kontra gruppe-URL: hvordan profilen vælges

En forbindelsesprofil styrer først en session, når ASA har valgt den. Den sætning er hele fejlfindingsmodellen for en gammel klientløs portal. En ubrugt profil kan have perfekte adgangsregler og alligevel ikke gælde for nogen. Følg loginets indgangspunkt, før du redigerer nogen politik.

Forskellene nedenfor følger 9.16-dokumentationen; klientløs SSL VPN blev fjernet i 9.17(1) og senere.

Alias er en listepost, ikke en URL

group-alias leverer en etiket, som brugeren vælger fra gruppelisten på login-siden. Visning af listen er en separat indstilling, tunnel-group-list enable. Alias er et valgnavn og intet mere. Konfiguration af et alias ved navn staff opretter ikke en /staff-URL, der vælger profilen.

Folk forventer, at aliaset gør dobbeltarbejde, fordi listen og URL'en indefra en browser ser ud som det samme valg.

Hvad group-url faktisk matcher

group-url binder en indgående URL til en forbindelsesprofil. Når den aktiverede URL matcher, vælger ASA profilen uden at bede brugeren vælge fra listen. URL'en skal være den komplette tilsigtede, i den syntaks din version understøtter. Dens DNS-post og certifikat skal stemme med det, brugerne skriver, ellers får matchningen aldrig en chance.

Et kopieret URL-suffiks beviser intet om konfigurationen. Kontrollér profilen, ikke adresselinjen.

Følg valget ind i den politik, der kører

Når en tunnelgruppe er valgt, opløser enheden autentificeringsmetoden og den standardgruppepolitik, der er knyttet til den. Derefter kan brugerspecifikke attributter, værdier returneret af autentificering og dynamisk autorisation tilsidesætte dele af dette grundlag. Undersøg, hvad sessionen faktisk modtog. At læse den navngivne politik alene giver dig grundlaget, ikke resultatet.

Forskellen mellem de to er oprindelsen til de fleste rapporter om »reglen er rigtig, men adgangen er forkert«.

Nedarving er ikke isolering

Attributter, du lader være uspecificerede, kan nedarves fra standardgruppepolitikken. En ny navngivet politik er derfor ikke lukket af fra delte standarder, og redigering af disse standarder rammer hver profil, der nedarver dem. Sammenlign den effektive ressourceadgang, DNS-indstillinger og sessionsbegrænsninger pr. profil. Gør det, før du ændrer noget delt.

Hold også håndhævelse af adgang adskilt fra valget.

For en klientløs session er det relevante filter webtype-ACL'en. Et VPN-filter til tunnelklienter er ikke en erstatning, blot fordi begge ligger nær samme politikblok i konfigurationen.

Afgør tilfældet uden matchning, og test derefter hver vej

Bestem, hvad der skal ske på portalens generiske URL og ved andre indgangspunkter uden matchning. Se på den reelle standardprofil-vej og dens autorisation i stedet for at redigere en delt standard, så én testkonto kommer igennem. Åbn derefter tre friske sessioner: den eksplicitte URL, den aktiverede listepost og det generiske indgangspunkt. Notér den valgte profil og den effektive politik for hver af dem.

Genbrug af en browservane fra et tidligere login ødelægger sammenligningen, fordi den session allerede er bundet til en profil.

Den registrering gør »portalen åbner« til en login-til-politik-tilknytning, du kan revidere senere, og det er det eneste holdbare svar, når en profil ser korrekt ud og ikke styrer nogen.