Cisco Nexus User Roles using TacPlus

I previously wrote a post about the Nexus Roles and how they integrate with a TACACS server.

Cisco Documentation shows the following format to issue multiple roles from a TACACS/RADIUS server.:

shell:roles="network-admin vdc-admin"

We are using Shrubbery TACPLUS, instead of the Cisco ACS software. Last week I noticed that only one role was assigned when multiples should be assigned. Multiple roles are required when using one TACACS server to issue roles for VDC and non-VDC Nexus switches since they need different default User-Roles.

This was tested on a Nexus 5000, a Nexus 7000 and VDC on the same Nexus 7000. Different codes were tried. This was not a NX-OS bug.

Upon further investigation it was obvious, that the syntax above as provided by Cisco was specific their TACACS software, being the ACS software. But I still required multiple Roles to be assigned for my single TACACS configuration to work across multiple Nexus devices. First attempt was the lazy method. Ask uncle Google for any such encounters with a solution. That yielded no practical results. I then contacting Shrubbery for the solution, after that it became clear that possibly nobody else have experienced this problem before.

So the hunt began to find out exactly what was so different in the AAA response from the Cisco ACS software to the TACPLUS software that it did not yield the required results.

All output below is from Nexus switch querying a TACPLUS or ACS server.

Starting with a low level debug it was obvious there was a difference between the two TACACS systems:

Debug output from querying TACPLUS on a Nexus switch, shows in line 12 that multiple roles were offered, yet, in line 17 only the first role was applied:

Nexus-N5K#debug tacacs+ aaa-request-lowlevel
...
tacacs: analyze_tac_resp_sent_aaa_resp_mts:received resp(before decrypt):
tacacs: analyze_tac_resp_sent_aaa_resp_mts: received resp(after decrypt):
tacacs: analyze_tac_resp_sent_aaa_resp_mts:TAC type and author status : 0x2, 0x2 for aaa session 0
tacacs: send_aaa_author_resp_mts: entering for aaa session 0
tacacs: tplus_decode_author_response: entering for aaa session: 0
tacacs: tplus_decode_author_response: Attributes count 5
tacacs: tplus_decode_author_response: attribute 0 service=shell
tacacs: tplus_decode_author_response: attribute 1 cmd=
tacacs: tplus_decode_author_response: attribute 2 shell:roles*vdc-admin network-admin
tacacs: tplus_process_vsa: got VSA attribute:shell:roles*vdc-admin network-admin
tacacs: tplus_process_vsa: got shell: home-dir: roles:vdc-admin uid:
tacacs: create_tacacs_user_profile: groups vdc-admin
tacacs: tplus_decode_author_response: privilege level is not specified, roles has been given priority
tacacs: AAA_RESP: status=2, av_count=3, ctx_len=294, server_msg_len=0, server_data_len=0
tacacs: AAA_RESP: 0 th attribute vdc-admin
tacacs: AAA_RESP: 1 th attribute shell:roles*vdc-admin network-admin
tacacs: AAA_RESP: 2 th attribute 10.1.5.82
tacacs: tplus_decode_author_response: exiting for aaa session: 0
tacacs: send_aaa_tplus_resp_mts: entering for aaa session 0
tacacs: send_aaa_tplus_resp_mts: exiting for aaa session 0
tacacs: update_tplus_state: entering for aaa session id: 0, current state: 6, next state 9
tacacs: close_tac_req_state_machine: entering for aaa session id: 0

The output locally on the N5K confirmed this:

LAB-N5K# sh user- | grep -A 1 test3
user:test3
        roles:network-admin

.

Debug output from querying an ACS with the desired behavior, illustrates that multiple roles were assigned correctly:

Nexus-N5K#debug tacacs+ aaa-request-lowlevel
...
tacacs: analyze_tac_resp_sent_aaa_resp_mts:received resp(before decrypt):
tacacs: analyze_tac_resp_sent_aaa_resp_mts: received resp(after decrypt):
tacacs: analyze_tac_resp_sent_aaa_resp_mts:TAC type and author status : 0x2, 0x2 for aaa session 0
tacacs: tplus_decode_author_response: attribute 0 service=shell
tacacs: tplus_process_vsa: got shell: home-dir: roles:network-admin vdc-admin uid:
tacacs: AAA_RESP: 0 th attribute network-admin vdc-admin
tacacs: send_aaa_tplus_resp_mts: entering for aaa session 0
tacacs: tplus_free_req_state_machine: entering for aaa session 0
tacacs: tplus_free_req_state_machine: exiting for aaa session 0
tacacs: close_tac_req_state_machine: exiting for aaa session id: 0
tacacs: update_tplus_state: exiting for aaa session id: 0, state: 6

.

I then resorted to comparing a low-level packet capture (which is available locally on Nexus Switches) between TACPLUS and ACS.

PACKET CAPTURE OUTPUT FROM TACPLUS:

TACACS+
    Major version: TACACS+
    Minor version: 0
    Type: Authorization (2)
    Sequence number: 2
    Flags: 0x00 (Encrypted payload, Multiple Connections)
        .... ...0 = Unencrypted: Not set
        .... .0.. = Single Connection: Not set
    Session ID: 958527057
    Packet length: 83
    Encrypted Reply
    Decrypted Reply
        Auth Status: 0x2 (PASS_REPL)
        Server Msg length: 0
        Data length: 0
        Arg count: 5
        Arg[0] length: 13
        Arg[0] value: service=shell
        Arg[1] length: 4
        Arg[1] value: cmd=
        Arg[2] length: 35
        Arg[2] value: shell:roles=network-admin vdc-admin
        Arg[3] length: 10
        Arg[3] value: idletime=3
        Arg[4] length: 10
        Arg[4] value: timeout=15

PACKET CAPTURE OUTPUT FROM ACS:

TACACS+
    Major version: TACACS+
    Minor version: 0
    Type: Authorization (2)
    Sequence number: 2
    Flags: 0x00 (Encrypted payload, Multiple Connections)
        .... ...0 = Unencrypted: Not set
        .... .0.. = Single Connection: Not set
    Session ID: 62527996
    Packet length: 84
    Encrypted Reply
    Decrypted Reply
        Auth Status: 0x2 (PASS_REPL)
        Server Msg length: 0
        Data length: 0
        Arg count: 4
        Arg[0] length: 13
        Arg[0] value: service=shell
        Arg[1] length: 4
        Arg[1] value: cmd=
        Arg[2] length: 47
        Arg[2] value: shell:roles="network-admin vdc-admin"
        Arg[3] length: 10
        Arg[3] value: timeout=15

.

At this point was obvious. Compare line 22 from each packet dump above. Nexus devices expects a *quoted string* for multiple word instead of relying on a newline as a terminator. ACS includes the extra inverted commas by default, but with TACPLUS this must be done manually. Wish I knew that before :)
To correct this for TACPLUS the Shell:Role string had to be updated in /usr/local/etc/tacacs/tacacs.conf to the following:

 shell:roles="\"network-admin vdc-admin\""

Once we found that the desired result was achieved using TACPLUS instead of using ACS.

LAB-N5K# sh user- | grep -A 1 test3
user:test3
        roles:network-admin vdc-admin
Advertisements

One thought on “Cisco Nexus User Roles using TacPlus

Please leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s