In the previous XMPP post, I was using local users in the XMPP ejabberd server. There was command authorisation in the form of a setting on the XMPP configuration of each Arista switch. The default is 1, however this will not permit show run, or configuration commands and others.
This post will explain how to use Cisco ISE to integrate TACACS command sets. The XMPP server will send the command to the client switch. The switch will then lookup the command the user that has sent it to determine if it is permitted. This overrides the XMPP privilege command. The domain is stripped from the username leaving only spine1, spine2 or admin in my examples.
AAA Configuration
This is a basic AAA configuration to get the Arista switch talking to the ISE server. Authentication and authorisation commands are required along with the IP of the ISE server.
|
0 1 2 3 4 5 6 7 8 9 10 11 |
tacacs-server key Stefan2020 tacacs-server host 172.17.5.101 key Stefan2020 aaa group server tacacs+ ISE server 172.17.5.101 aaa group server tacacs+ ISE server 172.17.5.101 aaa authentication login default group ISE local aaa authorization exec default group ISE aaa authorization commands all default group ISE local |
ISE Configuration
ISE has multiple steps to integrate Arista switches.
– Add device
– Create TACACS Profile
– Create TACACS command set
– Add users to AD, created a new group
– Create Device admin policy set
Add the device to ISE as a network resource. This is where TACACS, RADIUS plus more can be enabled for the device in ISE.
Creating the TACACS profile is in an awkward place in ISE 2.7. I cannot remember if it is a new place in ISE 3, but there is a search function in ISE 3 that allows searching of configuration items.
The TACACS profile is for assigning various attributes, I have used it to assign the privilege levels only. Specifcally level, 1, 7 and 15.
Next is the TACACS command set. This is not required, as you can just rely on the privilege levels set by the profiles. I have created three command sets; PermitAll, Priv1 and show_shut.
Priv1 contains commands that you would expect to find, show all but running-config. The commands work in a top-down manner. If a deny is above a permit then it impacts the permit line below if they conflict. There is a catch, which is the DENY_ALWAYS commands. Anything here doesn’t matter of the order (although I like to keep them at the top), they will always be denied. The full list is evaluated and then the DENY_ALWAYS commands matched are denied, even if there is a permit above them.
If any commands are not explicitly in the command set they are denied. Whcih is why I have needed to add the expected commands, configure terminal and exit
Now that all the policy elements have been created, the TACACS policy set can be created. This works in the same way as the policy set for 802.1x.
In the policy, I have configured the following;
– Device is Spine1 only
– AD group Domain Admins group gets Priv1 commands, and privilege1 profile
– AD group switches gets Priv1 commands and a privilege15 profile
– Any other users connecting will get the default, resulting in a deny all commands
A little bit of background, I added the XMPP users spine1 and spine2 to AD and created a new AD group to put them in named switches. This is a way I can differentiate the switches when sending XMPP commands from each other.
The other user I have added is the admin ejabberd user. These users will always hit the second rule named XMPP in the ISE policy set.
The last thing I did was to add this new group to ISE. ISE needs to be aware of the groups, otherwise it cannot use them in policies. To add a new group/search for groups in AD that ISE is connected to, click add.
Testing
This will show that the XMPP users are configured in the Arista switches with the ability to run privilege 15 commands. However, they will be limited to the Priv1 command set enforced by ISE.
|
0 1 2 3 4 5 6 7 |
spine1#show xmpp status XMPP Server: 172.17.3.253 port 5222 Client username: spine1@securitydemo.lab Default domain: securitydemo.lab Default privilege level for received commands: 15 Connection status: connected |
When running commands from another switch, such as running command on spine1 from spine2. The spine2 user must be in ISE. If not ISE displays this as an “UNKNOWN” user.
|
0 1 2 3 4 5 6 |
spine2#xmpp send spine1@securitydemo.lab command show hostname message from user: spine1@securitydemo.lab -------------------------------------------------- Hostname: spine1 FQDN: spine1 |
In the screenshot above, the first TACACS message is the bottom one. This is the authorisation of the user spine2 to get the shell for access to spine1. As the user spine2 is permitted, it receives the Privilege15Profile
The top TACACS message is for the command authorisation of the user spine2 running show hostname on spine1.
As the privilege level that XMPP has set is 15, running show running-config would be permitted if not for ISE. Now that ISE is checking commands, this will now be denied. I have run these from the Gajim client as the admin user
