📜 ⬆️ ⬇️

Using Vendor-Specific Attributes in Cisco ACS 5 using the example of APC and Supermicro

In this article, I would like to share the experience of using Vendor-Specific Attributes (hereinafter VSA) in Cisco Secure ACS 5.5 (hereinafter referred to as ACS) on the example of setting up RADIUS authorization on APC Smart-UPS and Supermicro IPMI. ACS in turn will authorize users in LDAP. At the end of the article, as a bonus, I will show you how to take a package dump on ACS for troubleshooting using Wireshark.
Warning: for ease of understanding of the presented material, the article contains many screenshots.

First of all, it is necessary to configure the External Identity Stores, namely, to configure the connection to AD / LDAP and configure the mapping groups. On Habré there is already an article on this topic, so I’ll omit this point and proceed directly to preparing ACS for authorization of APC Smart-UPS users in it (at the end, showing the differences in the Supermicro IPMI setup).

First you need to create a RADIUS VSA in order to transfer an additional field to the client upon successful authorization. In this case, the level of rights of the logged in user is transferred. The required field names as well as their values ​​can be found in the manufacturer's documentation ( APC and Supermicro ). VSA creation is performed in the System Administration -> Configuration -> Dictionaries -> Protocols -> RADIUS -> RADIUS VSA menu section. First we create the Vendor Specific Dictionary (the Vendor ID can be found on the IANA website).


Then we add the attributes themselves.

')
Create a Device Type for UPS and IPMI. To do this, in Network Resources -> Network Device Groups -> Device Type create an APC-UPS group.


Next in Network Resources -> Network Devices and AAA Clients we describe the subnet in which our UPSs are located. You can describe each device separately, simply by specifying its IP, but with a large number it is more convenient to operate with groups of devices.


Now you need to create a Device Filter so that you can then send an authorization request to the required Access Service. This is done in the section Policy Elements -> Session Conditions -> Network Conditions -> Device Filters.


Create an Authorization Profile to send VSA to a client device in the Policy Elements -> Authorization and Permissions -> Network Access -> Authorization Profiles section.






Configure Access Service in the Access Policies -> Access Services section.




We specify for it Identity Source here Access Policies -> Access Services -> APC UPS Network Access -> Identity.


And we create Network Access Authorization Policy rules in Access Policies -> Access Services -> APC UPS Network Access -> Authorization.






The final step in ACS is creating the Access Services selection rule in Access Policies -> Access Services -> Service Selection Rules.






Finally, we configure UPS to authorize users through RADIUS.




Congratulations! Now you can log in to UPS by authorizing a user through RADIUS (which in turn authorizes users in LDAP / AD and also takes groups from it). If the RADIUS server is unavailable, authorization will take place through a local account, so do not forget to configure it and set a strong password for it.

Now consider the difference between APC Smart-UPS and Supermicro IPMI. It consists in another VSA dictionary and authorization profile.










The remaining settings are similar to the above settings for UPS from APC.

Configuring RADIUS in IPMI is rather trivial.


Unlike APC NMC, Supermicro IPMI does not indicate the priority of account sources. Both local and RADIUS users work simultaneously. Also, do not forget to change the default password of the ADMIN user.

I want to draw your attention to the bug / feature we found in the IPMI firmware versions used by us: A user password longer than 16 characters is truncated. I had 17 characters mnu - I had to “cut it down”. Perhaps in newer versions this was fixed - they did not check.

Promised bonus:


Often, during the authorization setup, it may be necessary to remove a packet dump between the end device and the authorization server represented by Cisco ACS. Prior to Cisco ACS 5.5, this was all bad ( CSCtd13775 ), but the request was heard and now ACS has a full tcpdump. You can call it using the command:
acs-01/admin# tech dumptcp --help tcpdump version 3.9.4 libpcap version 0.9.4 Usage: tcpdump [-aAdDeflLnNOpqRStuUvxX] [-c count] [ -C file_size ] [ -E algo:secret ] [ -F file ] [ -i interface ] [ -M secret ] [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] [ -W filecount ] [ -y datalinktype ] [ -Z user ] [ expression ] 

As can be seen from the output of the help - we are dealing with an ordinary tcpdump version 3.9.4, so that you can use all known / familiar methods of working with it. There is only one feature - the options passed by tcpdump must be enclosed in double quotes. For example, to intercept a radius session with an end device that has an IP of 192.168.1.1, you can run the following command:
 acs-01/admin# tech dumptcp "host 192.168.1.1 and port 1812 -vvv -s 0 -w radius.pcap" 

Next, copy it to the tftp server:
 acs-01/admin# copy disk:radius.pcap tftp://192.168.1.254/ 

And we can safely feed it to Wireshark for further analysis.

Useful links:


1) Configure Cisco ACS 5.3 in conjunction with Active Directory
2) IANA PRIVATE ENTERPRISE NUMBERS
3) IPMI User's Guide
4) How do I configure my RADIUS server to authenticate my APC Network Enabled device?

Source: https://habr.com/ru/post/237087/


All Articles