- Cisco Employee,
Configuring WCS administration with ACS 5.x
- Configuring WCS administration with ACS 5.x
There are various options and possibilities when WCS users authenticate with ACS, not all combinations are explained in this document. However by reading one example, you should understand all the mechanisms to modify the example yourself to the precise configuration you want to achieve.
Example A:- Authenticating Lobby Ambassadors with TACACS+
Step1:- Adding the WCS in ACS AAA clients
- On ACS, go to “Network Resources” => “Network devices and AAA clients”.
- Create a new entry. Enter any name, the WCS ip address and enable TACACS with the shared secret you like (here we chose “Cisco”, which obviously is to be avoided for security reasons).
Step2:- Adding the ACS as tacacs server in WCS
- Login to WCS. Go to Administration-> AAA.
- There go to “TACACS+”. You can add a new server.
- Enter the ACS ip address, the same shared secret as above and leave the rest as default.
- On the left menu, click now on “AAA mode”.
- Set it to TACACS+.
- For safety reasons, it’s best to select “enable fallback to local on authentication failure or server no response”. This way we won't be locked out incase of problem. Once all is working you can always change this option later.
Step3:- Configuring the right shell profile on ACS
- We now need ACS to return the right attributes to determine the user privileges on WCS.
- WCS will actually tell you which attributes to configure.
- Go to “Groups” (still under Administration->AAA).
- You will see the list of user types. Since we are looking to authenticate Lobby Ambassadors, check the line of the “LobbyAmbassador” group. On the right you will see a link called “task list”. Click on it”.
It should give you this screen:-
- Basically, you will have to return the user role (here Lobby ambassador) and a list of task they can do (it relates to menus they can access).
- If you are return a recent release of WCS, you will also have to tell in which Virtual Domain the user will be.
- Go to “Administration”->Virtual domains.
- Click “Export. You will get a similar screen giving you the attributes to enter for each virtual domain:-
Let’s go and configure those attributes in ACS.
- Go to “Policy Elements” -> “Authorization and Permissions” -> “Device Administration” -> Shell Profiles.
- Create a new one. Give it a meaningful name (like “WCS” for example). And go to the “custom attributes” tab.
- Configure the attributes like they were shown on WCS. IT should give something like this :
The way to enter the attributes is usually a source of confusion. As an example, to enter those attributes, we had to:-
- type “role0” in the “Attribute” field
- type “LobbyAmbassador” in the Value field
- click the “add” button.
Etc… for the other attributes.
In ACS 4, it was possible to copy/paste the list of attributes from the WCS GUI to the ACS 4 GUI. They have to be entered one by one on ACS 5 and this can take some time. The future releases of ACS 5 will try to tackle this problem.
Step4: Configuring ACS to return the attributes
Having just a shell profile configured will not do the trick. We need more steps:-
- Configure a user. We configure Lobbyad as a user on ACS and for ease of configuration we put him in the group “WCS-users” (but this is not required).
2. In “Access policies”, under Default Device Admin->Authorization, we configured a rule to match WCS authentication :
If the username belongs to WCS-users group, then we will return the “wcs” shell profile (which contains all the attributes we configured).
3. In case you want to configure other types of users like administrators, you will need another shell profile returning different attributes. From there on, you need to group administrators in a different group in order to differentiate and know what shell profile to return.