cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2634
Views
0
Helpful
17
Replies

Local user for editing access-lists

idealo.de
Level 1
Level 1

Good Morning,

 

not sure if this is the right commnunity....anyway....

 

We are looking for a possibility to allow our User Helpdesk to modify access-lists on our Cisco ASA based client VPN. I'm wondering if it is possible to add a local user to the ASA who is allowed to enter configuration mode but can only execute commands like 'access-list ...'.

 

I already managed to set the privilege level so that the user can enter configuration mode and only see the access-list command but unfortunately he is not allowed to execute the command.

Any hint is appreciated.

 

Thank you.

------

asa-tst-rts# sh access-list
access-list Default; 10 elements; name hash: 0x2b24c7de
access-list Default line 1 remark ???
access-list Default line 2 standard permit host ???? (hitcnt=0) 0xe63fe3f9
access-list Default line 3 remark ???
access-list Default line 4 standard permit host ??? (hitcnt=0) 0x2f379ee1
[...]

asa-tst-rts# conf t

asa-tst-rts(config)# ?

  access-list  Configure an access control element
  clear        Clear
  configure    Configure using various methods
  end          Exit from configure mode
  exit         Exit from config mode
  logout       Logoff from config mode
  no           Negate a command or set its defaults
  quit         Exit from config mode
asa-tst-rts(config)# access-list ?

configure mode commands/options:
  WORD < 241 char  Access list identifier
asa-tst-rts(config)# access-list Default ?
ERROR: % Unrecognized command
asa-tst-rts(config)# access-list Default
ERROR: % Incomplete command
asa-tst-rts(config)#

 

17 Replies 17

Adeolu Owokade
Level 1
Level 1

Hi,

You can enable command authorization (aaa authorization command LOCAL) and then move the "access-list" command down to privilege 5 (privilege level 5 command access-list).

Note: To get to the access-list command, you need to use "configure terminal" so you also need to move the "configure" command down to level 5.

Command authorization can be very risky so be sure to test it out before deploying (so that you don't lock yourself out).

That's exactly what i did:

 

asa-tst-rts(config)# aaa authorization command LOCAL
asa-tst-rts(config)# username helpdesk password ??? privilege 5
asa-tst-rts(config)# privilege level 5 command access-list
asa-tst-rts(config)# privilege level 5 command configure
asa-tst-rts(config)#

 

asa-tst-rts# sh run | incl privil
username helpdesk password ??? privilege 5
privilege cmd level 5 mode exec command configure
privilege show level 5 mode exec command access-list
privilege show level 5 mode configure command access-list
privilege clear level 5 mode exec command access-list
privilege cmd level 5 mode configure command configure
privilege cmd level 5 mode configure command access-list
privilege clear level 5 mode configure command access-list
privilege clear level 5 mode configure command configure

 

asa-tst-rts# sh access-list Helpdesk
access-list Helpdesk; 18 elements; name hash: 0x70c5e23f
access-list Helpdesk line 1 remark ???
access-list Helpdesk line 2 standard permit host ???
access-list Helpdesk line 3 remark ???
access-list Helpdesk line 4 standard permit host ???
[...]

 

asa-tst-rts# conf t
asa-tst-rts(config)# ?

  access-list  Configure an access control element
  clear        Clear
  configure    Configure using various methods
  end          Exit from configure mode
  exit         Exit from config mode
  logout       Logoff from config mode
  no           Negate a command or set its defaults
  quit         Exit from config mode
asa-tst-rts(config)# access-lis
asa-tst-rts(config)# access-list Helpdesk ?
ERROR: % Unrecognized command
asa-tst-rts(config)# access-list Helpdesk
ERROR: % Incomplete command
asa-tst-rts(config)#

 

User helpdesk can enter configuration mode and will see the access-list command but cannot execute it. Don't know why.

 

Thank you.

 

When the user "helpdesk" logs into the ASA and is placed at the "asa-tst-rts>" prompt, do you use "login" to access the EXEC or "enable"? If "login" is used, then the user will enter the username and password again and will be placed at the appropriate priv level. If "enable" is used, then you have to do enable authentication (aaa authentication enable console LOCAL). 

Which are you using?

Although i'm using login it doesn't work.


 

Hmm...

If you are using an ASA on which logging can be safely turned on, perhaps you should connect via console and turn on logging and then SSH/Telnet from another terminal with that username and try to execute the access-list command and see if any logs come up.

I replicated it in a lab and I got it working successfully.

Currently i don#t have console access. Just did 'debug aaa authorization' / 'term mon' and logged in with user helpdesk on a different vty:

 

asa-tst-rts# AAA API: In aaa_open
AAA session opened: handle = 55
AAA API: In aaa_process_async
aaa_process_async: sending AAA_MSG_PROCESS
AAA task: aaa_process_msg(0x00007fff25830730) received message type 0
AAA FSM: In AAA_StartAAATransaction
AAA FSM: In AAA_InitTransaction

Initiating authentication to primary server (Svr Grp: LOCAL)
------------------------------------------------
AAA FSM: In AAA_BindServer
AAA_BindServer: Using server: <Internal Server>
AAA FSM: In AAA_SendMsg
User: helpdesk
Resp:
In localauth_ioctl
Local authentication of user helpdesk
callback_aaa_task: status = 1, msg =
AAA FSM: In aaa_backend_callback
aaa_backend_callback: Handle = 55, pAcb = 0x00007fff30a8d5d0
aaa_backend_callback: Error:
AAA task: aaa_process_msg(0x00007fff25830730) received message type 1
AAA FSM: In AAA_ProcSvrResp

Back End response:
------------------
Authentication Status: 1 (ACCEPT)

AAA FSM: In AAA_NextFunction
AAA_NextFunction: i_fsm_state = IFSM_PRIM_AUTHENTICATE, auth_status = ACCEPT
AAA_NextFunction: authen svr = LOCAL, author svr = <none>, user pol = , tunn pol =
AAA_NextFunction: New i_fsm_state = IFSM_DONE,
AAA FSM: In AAA_ProcessFinal
AAA FSM: In AAA_Callback
user attributes:

  1     User-Name(1)      8    "helpdesk"
  2     User-Password(2)      7    (hidden)
  3     Service-Type(6)      4    6
  4     Privilege Level(4316)      4    5

user policy attributes:
None

tunnel policy attributes:
None


Auth Status = ACCEPT
aaai_internal_cb: handle is 55, pAcb is 0x00007fff30a8d5d0, pAcb->tq.tqh_first is 0x00007fff24fa41e0
AAA API: In aaa_close
Admin user 'helpdesk' got privilege-level=5, service-type=ACCESS_LEVEL_PRIVILEGED.  Final-Access=ACCESS_LEVEL_PRIVILEGED.
AAA task: aaa_process_msg(0x00007fff25830730) received message type 3
In aaai_close_session (55)

 

Does that help? If a console connection is required i need to check that again next week when i'm in the office.

 

Oh no, the console is not necessary. Like you have done, I just wanted another terminal so that you could view logs on one and configure on the other.

Authorization is definitely successful and user is placed as privilege level 5 from the logs. So when you issue the access-list command that fails, do you get any logs on the ASA?

Perhaps just turn on level 7 logging (logging monitor 7) on the ASA so that we catch all logs.

asa-tst-rts(config)# logging monitor 7
Jun 19 2015 09:12:56 asa-tst-rts : %ASA-5-111008: User 'admin' executed the 'logging monitor 7' command.
Jun 19 2015 09:12:56 asa-tst-rts : %ASA-5-111010: User 'admin', running 'CLI' from IP ???, executed 'logging monitor 7'

 

 

Jun 19 2015 09:13:01 asa-tst-rts : %ASA-6-302013: Built inbound TCP connection 311 for management:???/49795 (???/49795) to identity:???/22 (???/22)
Jun 19 2015 09:13:04 asa-tst-rts : %ASA-6-113012: AAA user authentication Successful : local database : user = helpdesk
Jun 19 2015 09:13:04 asa-tst-rts : %ASA-6-113008: AAA transaction status ACCEPT : user = helpdesk
Jun 19 2015 09:13:04 asa-tst-rts : %ASA-6-611101: User authentication succeeded: Uname: helpdesk
Jun 19 2015 09:13:04 asa-tst-rts : %ASA-6-611101: User authentication succeeded: Uname: helpdesk
Jun 19 2015 09:13:04 asa-tst-rts : %ASA-6-605005: Login permitted from 172.30.160.192/49795 to management:172.29.252.10/ssh for user "helpdesk"
AAA API: In aaa_open
AAA session opened: handle = 56
AAA API: In aaa_process_async
aaa_process_async: sending AAA_MSG_PROCESS
AAA task: aaa_process_msg(0x00007fff25830730) received message type 0
AAA FSM: In AAA_StartAAATransaction
AAA FSM: In AAA_InitTransaction

Initiating authentication to primary server (Svr Grp: LOCAL)
------------------------------------------------
AAA FSM: In AAA_BindServer
AAA_BindServer: Using server: <Internal Server>
AAA FSM: In AAA_SendMsg
User: helpdesk

Resp:
In localauth_ioctl
Local authentication of user helpdesk
callback_aaa_task: status = 1, msg =
AAA FSM: In aaa_backend_callback
aaa_backend_callback: Handle = 56, pAcb = 0x00007fff30a8d5d0
aaa_backend_callback: Error:
AAA task: aaa_process_msg(0x00007fff25830730) received message type 1
AAA FSM: In AAA_ProcSvrResp

Back End response:
------------------
Authentication Status: 1 (ACCEPT)

AAA FSM: In AAA_NextFunction
AAA_NextFunction: i_fsm_state = IFSM_PRIM_AUTHENTICATE, auth_status = ACCEPT
AAA_NextFunction: authen svr = LOCAL, author svr = <none>, user pol = , tunn pol =
AAA_NextFunction: New i_fsm_state = IFSM_DONE,
AAA FSM: In AAA_ProcessFinal
AAA FSM: In AAA_Callback
user attributes:
  1     User-Name(1)      8    "helpdesk"
  2     User-Password(2)      7    (hidden)
  3     Service-Type(6)      4    6
  4     Privilege Level(4316)      4    5

user policy attributes:
None

tunnel policy attributes:
None


Auth Status = ACCEPT
aaai_internal_cb: handle is 56, pAcb is 0x00007fff30a8d5d0, pAcb->tq.tqh_first is 0x00007fff24fa3730
AAA API: In aaa_close
Admin user 'helpdesk' got privilege-level=5, service-type=ACCESS_LEVEL_PRIVILEGED.  Final-Access=ACCESS_LEVEL_PRIVILEGED.
AAA task: aaa_process_msg(0x00007fff25830730) received message type 3
In aaai_close_session (56)
Jun 19 2015 09:13:10 asa-tst-rts : %ASA-6-611101: User authentication succeeded: Uname: helpdesk
Jun 19 2015 09:13:10 asa-tst-rts : %ASA-5-111008: User 'helpdesk' executed the 'login' command.
Jun 19 2015 09:13:13 asa-tst-rts : %ASA-5-111007: Begin configuration: 172.30.160.192 reading from terminal
Jun 19 2015 09:13:13 asa-tst-rts : %ASA-5-111008: User 'helpdesk' executed the 'configure terminal' command.
Jun 19 2015 09:13:13 asa-tst-rts : %ASA-5-111010: User 'helpdesk', running 'CLI' from IP 172.30.160.192, executed 'configure terminal'

 

No logs regarding the access-list command in config modus because the user is not able to execute the command.

 

asa-tst-rts> login
Username: helpdesk
Password: *******
asa-tst-rts# conf t
asa-tst-rts(config)# access-l
asa-tst-rts(config)# access-list Default ?
ERROR: % Unrecognized command
asa-tst-rts(config)# access-list Default
ERROR: % Incomplete command
asa-tst-rts(config)#                    

 

I wonder what could be wrong.

Perhaps attach your entire (sanitized) configuration. Maybe I could pick something else out from there. Otherwise, maybe others will have something to contribute.

Nothing really exciting in the config. It's just a test box. I omitted all the vpn stuff. Please find the config attached.

 

Any clue why this is not working as expected?

 

Thanks you.

 

Unfortunately, I haven't been able to replicate the issue you are having. I used your configs (in a lab environment) and it worked for me.

 

What software version are you using?

Oh wow, you are quite right. I used version 8.4(2) and it worked on that. However, I just tried on version 9.4 and I am getting what you were getting. The context sensitive help just shows "Unrecognized command". 

However, if you know the syntax of the command (e.g. access-list Helpdesk permit ip any any), the ASA will accept it and it will show up in the show access-list output.

So even though it works, it doesn't work well - no help provided.

Review Cisco Networking for a $25 gift card