Following are the SRX pcap screenshot. Due to SRX did not received the local-user-name attribute, it uses the default "remote" account and applied with the class associated to user "remote". I need help on how to build the correct access policy for device admin authorization when ACS receive the "service=junos-exec" SRX sent, and reply with "local-user-name" according to the group.
After I did my lab test again from scratch. I believed I understand the whole process now and I can point out all problems that other people having when enabling TACACS+ account with Cisco ACS 5.2 servers.
Case 1: If Your ACS was not configured to response the TACACS+ authorization request with configured "local-user-name", depend on your SRX configuration, you may or may not ssh to the SRX and you defineatly cannot access J-Web. Why?
Scenario 1a: you have a local user "remote" defined on your SRX AND you configured "authentication-order tacplus". In this case, when you login as TACACS+ account "tac-user1", it will first authenticate with ACS as "tac-user1" and ACS will response authentication pass if correct password is provided,if SRX did not recvieve the "local-user-name" value from the TACACS+ authorization request, it uses the default "remote" user as "local-user-name" for authorization. In this case, you are able to access SSH and J-Web with TACACS+ account.
Scenario 1b: you don't have a local user "remote" defined on your SRX AND you configured "authentication-order tacplus". In this case, when you login as TACACS+ account "tac-user1", it will first authenticate with ACS as "tac-user1" and ACS will response authentication pass if correct password is provided, if SRX did not recvieve the "local-user-name" value from the TACACS+ authorization request, it uses the default "remote" user as "local-user-name" for authorization. (p.s. you can know this by SRX command "show cli authorization". refer to screenshot.) Due to there was NO "remote" user defined on SRX, the authorization was not granted. In this case, you are NOT able to access neither SSH nor J-Web with either TACACS+ or local account.
Scenario 1c: you don't have a local user "remote" defined on your SRX AND you configured "authentication-order [ tacplus password ]". in thise case, you are NOT able to access neither SSH nor J-Web with TACACS+ account. However, you are able to access SSH and J-Web with local account since the password is on the 2nd authentication-order.
Scenario 1d: you have a local user "remote" defined on your SRX AND you configured "authentication-order [ tacplus password ]". in thise case, both TACACS+ and local account are able to access SSH and J-Web.
Case 2: If Your ACS was configured to response the TACACS+ authorization request properly (returned with "local-remote-user" value). It doesn't match, however, with the SRX configured local user(s). In this case, the TACACS+ account with unknown "local-user-name" will NOT be able to access neither SSH nor J-Web even with authentication pass shown on ACS log.
After the explanation of what I found in my lab test. Following is how I configured the ACS 5.2 to get "TACACS+ authorization" work. I had experence on ACS 4.x but never configured ACS 5.2 in the past. Thanks to Cisco Jatin Katyal. He told me how to configure the Device Admin authorization on ACS 5.2.
1. Depends on you ACS authentication user database, you can configure the rule to authenticate the user with proper user database source such as local user, external Active Directory user, and so on. If you got the "authentication passed", that means your authentication policy was configured properly. In my case, I just use ACS local user database.
2. Since you may have users defined with certain groups for providing the "Role-Base Access Control (RBAC)" already. we will use those "Identity Group" for future policy condition. In my case, I created two groups, RW-Admin and RO-Admin under "All Groups".
Associate each user with the Identity Group. In my case, I created chenjro for RO-Admin group, chenjrw for RW-Admin group and chenj for default All Groups. So I can provide different authorization response for each user.
3. You may want to apply this authorization to only your SRX device. You can create a "Device Type" call "SRX" under "All Device Type". then associate your SRX devices (under "Network Device Groups" - "Network Devices and AAA Clients" with this SRX device type. After this is done, You are able to use this SRX device type as a condition when you configuring the authorization policy later to associate with selected Shell Profile.
4. This is the KEY. You need to defind the "Device Administration" - "Shell Profiles" under the "Policy Element" - "Authorizarion and Permission". Create your own Shell profile for each "local-user-name" group. "Remember to delete the default "space" in the value when you enter your own "local-user-name", select "Mandatory" on Requirement, the click "Add" to add the attribute. If you did not click "Add ^" before you click "Submit", the attribute will NOT be there. I learned that from my own mistake. If you need to change the attribute, click "Edit V" then modify your value. You MUST click the "Replace ^" to update the attribute before you click "Submit". Once you have done this "Shell Profile" for each of you "local-user-name" group. then we will configure the "Authorization policy" next.
5. Depends on your Access Services policy, configure the "Authorization" under your designated Service Policy, in our case, it is the "Default Device Admin" Access Services policy. Create your own policy condition according to your "Identity Group" setting and "Device Type" setting. Create one rule for each "Identity Group" and associate it with the selected "Shell Profile" that will return the proper "local-user-name" value via TACACS+ authorization request.
6. On you SRX configuration, it is very simple. You just need to define each "local-user-name" value as a user on SRX with the associate class. Following are the configuration. The "remote" user was added as a catch all for any user account that did not associate with any defined "local-user-name" with a RO-CLASS access permission. You may delete it if you want only TACACS+ users with designated groups have access to SRX.
====================
version 11.4R7.5;
system {
authentication-order [ tacplus password ];
tacplus-server {
192.168.14.49 {
port 49;
secret "xxxxxxxx"; ## SECRET-DATA
single-connection;
}
}
login {
class RO-CLASS {
permissions [ view view-configuration ];
}
class RW-CLASS {
permissions all;
}
user JUNOS-RO {
uid 2000;
class RO-CLASS;
}
user JUNOS-RW {
uid 2001;
class RW-CLASS;
}
user localadmin {
uid 2011;
class super-user;
authentication {
encrypted-password "XXXXXX"; ## SECRET-DATA
}
}
user remote {
uid 6001;
class RO-CLASS;
}
}
============================
Summary
I recommend you configure SRX with "authentication-order tacplus". This forces all authentication via TACACS+. The local shared account won't work unless the TACACS+ server is not reachable. Per Juniper KB24437, http://kb.juniper.net/InfoCenter/index?page=content&id=KB24437, it suggested you to add "password" in the authentication-order which is a work around from Juniper since most of SRX admins don't manage the ACS. You should provide this document to your ACS admin and ask them to configure ACS properly.
This link provide you extra help on other hardware, http://www.cisco.com/en/US/products/ps9911/products_configuration_example09186a0080bf5512.shtml,
