We are unable to deny ASA admin functions to users who have connected via VPN.
In summary, any user that makes a remote VPN connection to our ASA is able to start up ASDM and/or the https java applet regardless of the privileges set. This, in our opinion, is bad.
1) Local authentication used.
2) Privilege set to 0 (zero) - have also tried 1 & 2.
3) User makes remote VPN connection.
4) User able to use ASDM/https to view any/all of the ASA configuration, but is not able to make changes.
Would appreciate advice on how admin functions can be denied, but still permit access to local LAN.
Curt, the access to the firewall is controled by two statements in the firewall.
for example, if you have in your asa this:
http 0.0.0.0 0.0.0.0 inside
this means any inside Ip address in any subnet will be able to load asdm and of course if you have AAA local server they will connect to ASA, now with priviledge set to 0 user can connect but don't think it can make any changes to firewall whatsoever.
You could be more granular in the way the firewall is accessed, you may do it in several ways.
You could allow only one, two or three IP address be able to connect to ASA ASDM as well as Telnet , or a combination of IP address hosts and subnets.
http 192.168.1.50 255.255.255.255 inside
telnet 192.168.1.50 255.255.255.255 inside
http 192.168.2.0 255.255.255.0 inside
telnet 126.96.36.199 255.255.255.0 inside
in above example only 192.168.1.50 will be able to connect to asa either through asdm or telnet, and any hosts from 192.168.2.0 subnet should be able to do the same for both asdm and telnet.
there is also another command , the management-access inside allows for access to the firewall from vpn connections, so if you want to avoid all above administrative hassle and just deny asa administration from vpn connections you could accomplish this through [no management-access inside] command in enable mode and leave http 0.0.0.0 0.0.0.0 inside statement , but if you want to access firewall from a vpn connection you will have to rdp to a machine inside you LAN that is permited in ASA for asdm and telnet access.
Jorge, thank you for the quick reply ... you are faster than TAC, which has yet to find a solution :-)
I had authorized http for the remote subnet (as well as the local LAN). I had assumed the privilege levels would constrain access. I'm a bit disappointed that they don't function as, in my opinion, they should.
Unfortunately (for us) the ASAs are scattered around the country and remote VPN is the defacto admin method. It looks like I'm going to have to create separate admin VPNs with separate ip pools (unless TAC finds some switch/parameter I have missed).
Thanks again for the help.
You are welcome , indeed, the idea of creating separate admin group for vpn seems a great idea.. I am quite positive TAC will definately provide you with good implementation options.
Just an FYI for the help you provided:
TAC did eventually get back to me. However, the answer was not wonderful. The "feature" to deny a user from https or ASDM will not be available until the NEXT v8.x release (the current 8.x early release has a bug in the implementation of this "feature".
The separate ip pools associated with separate policy groups worked fine ... only admin policy/pool permitted http/ASDM access.