user accounts on cisco asa 5510

[donnie]

Hi all. I am using ASDM 5.0 GUI for configuring my cisco asa5510 firewall. I have created some user accounts for vpn access purpose only. However these users could login to my asdm and view the configuration though they could not modify as i have set privilege 0 on their accounts. What can i do such that they will not be able to access my asdm while retaining the vpn capability? Thanks in advance.

[JORGE RODRIGUEZ]

Look at ASA statement in CLI or in ASDM Administration section.

Ensure that only access to ASA is set in ASA per host IP or Subnet.

For example, if you want only one or two systems to access ASA via https or telnet you would have the following.

telnet 192.168.1.100 255.255.255.255 inside

telnet 192.168.1.101 255.255.255.255 inside

http 192.168.1.100 255.255.255.255 inside

http 192.168.1.101 255.255.255.255 inside

Only 192.168.1.100 and 101 will be able to access ASA for admin. the same goes for a subnet

e.g

any host within 192.168.1.0 will have access

telnet 192.168.1.0 255.255.255.0 inside

http 192.168.1.0 255.255.255.0 inside

or any subnet inside network will have access

telnet 0.0.0.0 0.0.0.0 inside

http 0.0.0.0 0.0.0.0 inside

Rate any helpful post

HTH

Jorge

[donnie]

Thanks george. But does it mean that all vpn accounts created are able to login to my ASDM?

[JORGE RODRIGUEZ]

Hi, it means that asa probably have http and telnet as 0.0.0.0 0.0.0.0 inside, when vpn users connect to asa-vpn server it is assign ip addresses by either DCHP services from ASA or whichever DHCP services you use for your vpn users, those IPs are consider to be inside your network perimeter.. if you post ASA config striping public IP info we can take a look.

Basically the administration access to ASA from inside our outside is determined by the statements http/telnet/ssh and the interface you allow it e.g inside, outside, DMZ etc..

vpn has nothing to do with admin access to ASA.

Pls rate any helpful post

Rgds

Jorge

[john.dowson]

I had a similar problem when using the local database for both SSH and Remote Access authentication. I had the following AAA config:

aaa authentication ssh console LOCAL

aaa authentication http console LOCAL

aaa authentication enable console LOCAL

I also had a Remote Access group set to use the local database for XAUTH. The users were set up like this:

username admin password admin privilege 15

username user password password privilege 0

The 'user' account was intended just for remote access, not SSH or ASDM. However, the ASA would still accept this for both. The only limitation was ASDM didn't show much config and SSH would only allow privilege 1 commands. A workaround was to configure local command authorization, as described in the following link:

http://www.cisco.com/en/US/docs/security/asa/asa72/configuration/guide/mgaccess.html#wp1042036

Although it still allows the user to authenticate for ASDM access, as soon as the GUI loads, an error is shown and no information can be viewed. SSH access does still work at the unprivileged level, however when trying to gain privileged access, the following message appears before rejecting the attempt:

[ user ] You do NOT have enable Admin Rights to the console

Not perfect but it does the job. I'd rather the remote access user be rejected the initial authentication for both SSH and ASDM.

Thanks,

John

[srue]

the better solution is to lock the user into a specific group:

if you have local user "bob"...

asa(config)# username bob attributes

asa(config-username)# ?

.....

[john.dowson]

Looks like there is a specific command within user attributes that will lock the user to just Remote Access:

asa(config)#username bob attributes

asa(config-username)# service-type remote-access

However, it only becomes effective when authenticating management access:

aaa authorization exec authentication-server

I'm using version 8.0(3) though, so not sure if this is available in 7.x.

http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/aaa.html#wp1062044

[bauer.juergen]

service-type remote-access seems not to be available on 7.2. :-(

another solution would be to add a vpn-filter to that user that prohibits access to the inside(?) interface.

not nice but maybe it works.