Local User on ASA for AnyConnect VPN Access

[Matthew Martin]

Hello All,

ASA version 9.4(1)

We are currently using AnyConnect along with the ASA and ISE for authentication and authorization into VPN. User's login requests are sent to the ISE server authentication and they get back the authorization policy from ISE.

But, I am planning on upgrading the ISE server this weekend which has an estimated time of about 10+ hours. So in case there are some issues that occur during the upgrade, and users cannot login to VPN via AnyConnect because ISE is down. We thought we could create a local user on the ASA which could authenticate through the ASA and bypass ISE for authentication. But, I'm having a little trouble figuring this out. The only time I've ever seen local user configurations on the ASA was for the user I use to login to the ASA on ASDM or CLI.

I just created a "local user" on the ASA. I gave it a username (*call him johndoe) and a password. Everything else is currently set to inherited.

Would someone be able to guide me to allowing this user the ability to login to VPN with the AnyConnect client?

Currenlty, when I attempt to login to VPN with my AnyConnect client, I get prompted with a pop-up that allows me to choose from the 2 Group Policies that we have (*Employee and Vendor) and then a username and password.

Any help would be greatly appreciated!

Thanks in Advance,

Matt

[Rahul Govindan · Accepted solution]

Unlike other vendors, Cisco ASA has just one local user database. Any username created on the ASA should be able to login both to the VPN and also the ASA itself (via ssh/https). The login process itself should remain the same for a user authenticating via ISE or local database.

If the ISE is assigning a group-policy based on AD groups (which then restricts what they can access etc.), you would have to manually assign the group-policy to the user created on the ASA local database to get the same access level.

[Matthew Martin]

Hey Rahul, thanks for the quick reply, much appreciated! And yes, you are correct in your assessment of how our VPN auths through ISE, with AD, etc...

Ok, so I created the user and password under local users. Since this user will be for contractors that will need to be working this weekend during the upgrade, I set the user to "No ASDM, SSH Telnet or Console access".

Under: Public Key Authentication
- Section is left blank.

Under: Public Key Using PKF
- Section is also blank.

Under: VPN Policy
- Group Policy = Vendor-GP
- Tunneling Protocols = SSL VPN Client
- Connection Profile (Tunnel Group) Lock = Vendor
- Simultaneous Logins = 10
*Everything else is inherited...

Under: VPN Policy > AnyConnect Client:
- All settings are set to inherited...
Under: VPN Policy > AnyConnect Client > Login Settings/Key Regeneration/Dead Peer Detection:
- All settings are set to inherited...

Since I'm in the office now. I connected my laptop to the Wi-Fi hotspot on my phone. Then I opened AnyConnect and clicked "Connect" on the VPN window of my AnyConnect client. I then get the Login window and I selected the "Vendor" Group from the Drop-down box, and I entered "johndoe" as the user and the password I created. However, it fails to login.

Is there something I could be missing?

Thanks Again,
Matt

[Rahul Govindan]

Have you changed the authentication to use local database under the tunnel-group? If it is still set to ISE as authentication server, local database never takes effect (even as fallback) unless the ISE servers are unreachable.
For testing, it would be almost easier to create a new test Tunnel-group and group-policy (mirroring the production ones) with Local DB as auth server. This will help in not messing up the existing settings :)

[Matthew Martin]

Something I just noticed under the "Vendor-GP".

In AnyConnect Connection Profiles > Vendor-GP > Basic > Authentication: It's currently set to "ISE" which is the AAA server group for our ISE nodes. I noticed the checkbox under that AAA Server Group that says "Use LOCAL if Server Group Fails" is NOT checked.

Would this be why its failing when I attempt to login?

-Matt

[Rahul Govindan]

Yup. It is probably sending the johndoe username/password to ISE and fails. Even checking the fallback option wont help in your case. If it is for quick testing, you can change the AAA server from from ISE to local DB. Once you test it, you can change it back to ISE.
I would also enable the Fallback option for your maintenance window period. If ISE is not reachable, it falls back to the local db. That way, you do not have to manually change the setting then.

[Matthew Martin]

Sorry, didn't see your last reply before I submited mine.

Ok I think I gotcha now. I'll create a new GP and Tunnel-Group as you suggested. And I'll set the local DB as the Auth server.

After I test and it works. Can I modify the Vendor-GP to, for example: Check local DB for authentication, if user fails, send authentication request to ISE?

Is something like that possible?

-Matt

[Rahul Govindan]

Nope. Only Local DB can act as fallback. So it would have to be ISE first and then Local as fallback if ISE is down.

[Matthew Martin]

Ok, gotcha. Thanks!

Alright. So I created new GP and Connection Profile (*is that the "Tunnel-Group" or is the GP the tunnel-group?). After I got that created and I attempted to connect to VPN I was given the choice of selecting the new Test Group, Employee and Vendor at login. So I selected the Test Group and used the Local user I created and I was successfully logged-in and had access to everything I needed access to, so far as I could tell.

So, now that I know that new LOCAL user works. I can now, in theory, set the Vendor Profile > Authentication > to "Use LOCAL if Server Group fails", and if ISE goes down during my upgrade this weekend the new LOCAL user should get authenticated through the local DB..?

Does that sound correct? Is there anything else that I need to set on the Vendor Profile or GP?

Thanks Again,
Matt

[Rahul Govindan]

Connection Profile (on ASDM) = Tunnel Group (on CLI).

I think you should be good going forward. Just remember that if you have ISE and local, the user would try the AD username/password first. If this fails (assuming that ISE is down), then they have to try the local username/password on the second attempt. Auth will be slower that usual because of the retries that it would require for ISE to marked as failed. If you have 2 nodes for the ISE server-group, then slightly longer.

[Matthew Martin]

Let's just say both ISE servers are down, and I try using the LOCAL user without even attempting my AD user first, are you saying this would fail, and that I would need to attempt my AD user first and then try the local user on subsequent attempts?

Wouldn't the ASA just re-attempt to send it to ISE first anyway on subsequent login attempts? Or does it get marked as "Dead" like it does on the Switch configuration?

-Matt

[Rahul Govindan]

No, I was talking more of a real world scenario when the user does not know when the ISE is down. If the user knows that ISE servers are down and then try the LOCAL credentials, the auth request will be sent to ISE first. When ISE does not respond, the ASA checks the credentials with the local DB. If they don't know that the ISE is down, they would first try the AD credentials, which would fail, and then try the local credentials on the next attempt. 

ASA will always attempt to send credentials to ISE first every time the username/password is entered. 

[Matthew Martin]

Ok I gotcha, that makes sense.

Thanks again for the help, very much appreciated!

-Matt