05-06-2013 08:59 AM - edited 03-10-2019 08:23 PM
In the process of migrating from ACS 4.1 to ACS 5.3. Authentication works fine, but having issues with authorization on the Juniper WXC-3400 devices. In ACS 4.1 we were passing TACACS+Shell (exec) Custom attributes Privilege level=15, which allowed a user to login with read/write privileges. In ACS 5.3 tried setting the Shell Profiles common task to 15 for both Default and Maximum (one at a time, and together), as well as setting the Custom Attributes for priv-lvl=15 (with and without Common Tasks set).
A capture shows Auth Status: 0x11 (ERROR).
Any ideas?
Thanks in advance!
Solved! Go to Solution.
05-07-2013 08:46 AM
I see...
if you look at Authorization Query...it's only sending Arg[0] value: service=shell and didn't send "cmd=" arg. As per T+ draft if service is shell, "cmd" attribute must be sent in Q.
http://tools.ietf.org/html/draft-grant-tacacs-02
cmd
a shell (exec) command. This indicates the command name for a shell
command that is to be run. This attribute MUST be specified if ser-
vice equals "shell". A NULL value indicates that the shell itself is
being referred to.
Now you must be thinking why it's working with ACS 4.x and just not with ACS 5.x
ACS 4.x doesn't check the presence of cmd and treat cmd= and no cmd as same, ACS 5.x is more strict
I've seen this happening with variety of 3rd party devices like bluecoat, zone ranger and now Juniper.
You need to involve Juniper support or development team to get a patch so that the authorization Q should contain cmd=
hope it helps.
Jatin Katyal
- Do rate helpful posts -
05-06-2013 09:16 AM
you need to push couple more attributes in the same shell profile to make this work.
under shell profiles > custom attributes > add the following attributes
attribute Requirement value
vsys mandatory root
privilege maddatory read-write
try this please and let me know.
Jatin Katyal
- Do rate helpful posts -
05-06-2013 09:21 AM
I've tried adding both of those custom attributes with and without Default/Maximum Privilege being set to 15.
No luck, still Read only access.
Thanks-
Shawn
05-06-2013 09:45 AM
what do you see in tacacs authorization?
Also can you upload the pcap file?
Jatin Katyal
- Do rate helpful posts -
05-06-2013 10:04 AM
... never see anything in the tacacs authorization.
Can't upload a capture, as it's within our non-public infrastructure.
Are you just wanting to look at the query and response or complete conversation?
Shawn
05-06-2013 01:06 PM
Yup. I want to see Tacacs+ authorization Query and Response.
Even the ACS/Tacacs authorization result should show us what exactly it is sending it out to Juniper.
Jatin Katyal
- Do rate helpful posts -
05-06-2013 01:08 PM
Here is what I found for you:
https://supportforums.cisco.com/message/3417297
This may give you quick review of your config.
Jatin Katyal
- Do rate helpful posts -
05-06-2013 02:01 PM
No. Time Source Destination VLAN Protocol Info
18 09:14:00.268166580 WX_Juniper ACS_5_3 TACACS+ Q: Authorization
Frame 18: 107 bytes on wire (856 bits), 107 bytes captured (856 bits)
Ethernet II, Src: Cisco_cd:46:af (00:07:7d:cd:46:af), Dst: Ibm_fe:9a:63 (5c:f3:fc:fe:9a:63)
Internet Protocol, Src: WX_Juniper (WX_Juniper), Dst: ACS_5_3 (ACS_5_3)
Transmission Control Protocol, Src Port: l2c-control (4371), Dst Port: tacacs (49), Seq: 1, Ack: 1, Len: 49
TACACS+
Major version: TACACS+
Minor version: 0
Type: Authorization (2)
Sequence number: 1
Flags: 0x04 (Encrypted payload, Single connection)
Session ID: 1491582254
Packet length: 37
Encrypted Request
Decrypted Request
Auth Method: TACACSPLUS
Privilege Level: 1
Authentication type: ASCII
Service: Login
User len: 8
User: stmartin
Port len: 7
Port: console
Remaddr len: 0
Arg count: 1
Arg[0] length: 13
Arg[0] value: service=shell
No. Time Source Destination VLAN Protocol Info
20 09:14:00.271608140 ACS_5_3 WX_Juniper TACACS+ R: Authorization
Frame 20: 76 bytes on wire (608 bits), 76 bytes captured (608 bits)
Ethernet II, Src: Ibm_fe:9a:63 (5c:f3:fc:fe:9a:63), Dst: Cisco_cd:46:af (00:07:7d:cd:46:af)
Internet Protocol, Src: ACS_5_3 (ACS_5_3), Dst: WX_Juniper (WX_Juniper)
Transmission Control Protocol, Src Port: tacacs (49), Dst Port: l2c-control (4371), Seq: 1, Ack: 50, Len: 18
TACACS+
Major version: TACACS+
Minor version: 0
Type: Authorization (2)
Sequence number: 2
Flags: 0x00 (Encrypted payload, Multiple Connections)
Session ID: 1491582254
Packet length: 6
Encrypted Reply
Decrypted Reply
Auth Status: 0x11 (ERROR)
Server Msg length: 0
Data length: 0
Arg count: 0
05-06-2013 02:02 PM
I've been though that last link a dozen times .... argh
Thanks-
Shawn
05-06-2013 02:17 PM
Hey Shawn,
Looks like the logs you mentioned, doesnt show if they are passing the read-write attributes:
- Can you check if its hitting the right rule?, if possible could you please take the snap shot of Tacacs authorization from ACS 5 and send it.
Regards
Minakshi
05-07-2013 08:02 AM
I'm not ever seeing anything in the tacacs authorization, looked at AAA Diagnostics this morning and I'm seeing:
May 7,13 2:59:27.073 PM | May 7,13 2:59:27.050 PM | p-msfc-acs2/151373657/554798 | WARN | Invalid TACACS+ authorization request | CSCOacs_TACACS_Diagnostics | 13000 | Device IP Address=192.xxx.xxx.xxx.xxx Device Port=4712 MajorVersion=Default MinorVersion=Default Type=Authorization Sequence-Number=1 Header-Flags=Encrypted SessionId=950056336 Privilege-Level=1 Authen-Type=ASCII Service=Login User=stmartin Port=console Authen-Method=TacacsPlus Service-Argument=shell EnableSingleConnect=false CiscoIOS=true UseSingleConnect=false AcsSessionID=p-msfc-acs2/151373657/554798 SelectedAccessService=CNOC Network Ops WOA Sequence-Number=2 SessionId=950056336 Response={AuthenticationResult=Passed; MajorVersion=Default; MinorVersion=Default; Type=Authorization; Header-Flags=Encrypted; SessionId=950056336; Author-Reply-Status=Error; } |
05-07-2013 08:46 AM
I see...
if you look at Authorization Query...it's only sending Arg[0] value: service=shell and didn't send "cmd=" arg. As per T+ draft if service is shell, "cmd" attribute must be sent in Q.
http://tools.ietf.org/html/draft-grant-tacacs-02
cmd
a shell (exec) command. This indicates the command name for a shell
command that is to be run. This attribute MUST be specified if ser-
vice equals "shell". A NULL value indicates that the shell itself is
being referred to.
Now you must be thinking why it's working with ACS 4.x and just not with ACS 5.x
ACS 4.x doesn't check the presence of cmd and treat cmd= and no cmd as same, ACS 5.x is more strict
I've seen this happening with variety of 3rd party devices like bluecoat, zone ranger and now Juniper.
You need to involve Juniper support or development team to get a patch so that the authorization Q should contain cmd=
hope it helps.
Jatin Katyal
- Do rate helpful posts -
05-08-2013 08:27 AM
Let me know if you still have any doubt.
Jatin Katyal
- Do rate helpful posts -
05-06-2013 02:44 PM
Hi Shawn,
As per the error message, the ACS is rejecting the request, What do you get on the ACS for this?
Also, the Junper device is not asking for any extra attributes, just the shell, as usually third party devices show the attributes that they need in the Author Request.
Request:
Arg[0] length: 13
Arg[0] value: service=shell
Response:
Decrypted Reply
Auth Status: 0x11 (ERROR)
Rate if useful
05-15-2013 12:05 PM
Thank you for your help. This has been resolved in new WX OS (5.7.7).
Thanks again
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide