即使我在我的实验室设备和家庭网络的唯一管理员，我想这将是很好有某种形式的对这些设备的集中认证，授权和计费。不过，我很快就意识到，使用专用设备，如思科ACS或ISE将意味着增加另一个总是VM我的实验室环境。我还没有准备好，开始我的实验室资源浪费的一个基本功能像AAA。因此，而不是使用专用设备在Ubuntu Linux服务器，我使用的DNS，DHCP，系统日志，和其他网络服务，在我的实验室，我决定实施FreeRADIUS的。
虽然，TACACS +，通常是思科AAA协议的首选，我的要求很简单，足够RADIUS将工作一样。 FreeRADIUS是包含在标准的Ubuntu软件库，这应该是很容易安装。
我的要求很简单。我想使用RADIUS服务器来验证用户，然后分配两个剖面之一：“管理员”配置文件里面有完整的管理权（相当于IOS的权限级别15或NX-OS网络管理员的角色）和“运算符“配置文件具有只读权限（相当于IOS的特权级别1或NX-OS网络操作员角色）。这些用户配置文件应指定通过RADIUS协议。当然，我也希望一些基本的会计。因为我不需要票友的功能，如命令授权，RADIUS应该足够了。
我部署一个新鲜的Ubuntu的虚拟机而不是搞乱我的服务器经常用于测试目的。然后，我使用的apt-get安装的freeradius的freeradius-utils的包：
tom@freeradius:~$ sudo apt-get install freeradius freeradius-utils
The freeradius-utils package is not strictly necessary, but nice to have when you need to troubleshoot the RADIUS implementation. Especially the radtest and radsniff commands are useful to verify the attributes that are exchanged between the client and the server.
Note: I had to do a fair amount of troubleshooting to find a set of attributes that works for the combination of IOS devices, NX-OS devices and ASAs. To keep this post clean, I will not list all the intermediate steps and stuff I tried that didn’t work, but simply present the eventual working configurations that I ended up with.
Next, I add an entry to the /etc/freeradius/clients.conf file to define the RADIUS key for a group of devices:
client 192.168.36.0/24 {
secret = Fr33-R@d1u$
shortname = lab-network
nastype = cisco
}
Rather than creating separate entries for every client device, I create a blanket statement that allows all devices in my lab IP range to use the same RADIUS key. Of course you can create individual entries for each client if you prefer.
Now it is time to define my “admin” and “ops” users. I add the following entries to the /etc/freeradius/users file:
admin Cleartext-Password := 1234QWer
Service-Type = Administrative-User,
Cisco-AVPair = "shell:roles=network-admin",
Cisco-AVPair += "shell:priv-lvl=15"
ops Cleartext-Password := 1234QWer
Service-Type = NAS-Prompt-User,
Cisco-AVPair = "shell:roles=network-operator",
Cisco-AVPair += "shell:priv-lvl=1"
tom Auth-Type := System
Service-Type = Administrative-User,
Cisco-AVPair = "shell:roles=network-admin",
Cisco-AVPair += "shell:priv-lvl=15"
And of course I restart the freeradius service to commit my changes:
tom@freeradius:~$ sudo service freeradius restart
* Stopping FreeRADIUS daemon freeradius
...done.
* Starting FreeRADIUS daemon freeradius
...done.
There are a couple of things that are worth noting about this configuration:
First of all, this post is not intended as a guide for setting up a production FreeRADIUS deployment. As such, the entries above do not represent best practices. My primary objective is to describe the attributes required for the various types of Cisco devices. For example, defining the passwords directly in the users file using the Cleartext-Password attribute is not good practice, but can be useful when you’re testing and experimenting. Also, defining the Auth-Type for a specific user is frowned upon. You may want to refer to the FreeRADIUS documentation if you intend to use FreeRADIUS in a production environment.
For the “admin” and “ops” users I defined the password directly in the users file using the Cleartext-Password attribute. On the other hand, the user “tom” is tied to the existing local system account on the Ubuntu server.
The “admin” and “tom” users are set up as Service-Type = Administrative-User, while the user “ops” is set up as Service-Type = NAS-Prompt-User. This distinction is primarily relevant for the ASA. For the ASA the Service-Type determines whether a user can use the enable command to go to privileged mode or not. This is documented in the ASA Management Access Configuration Guide. Some basic testing revealed that IOS also honors the Service-Type out of the box. It assigns privilege 1 to users of type NAS-Prompt-User, while it assigns privilege 15 to users of type Administrative-User. However, it is still possible to elevate NAS-Prompt-Users to privilege level 15 through use of the shell:priv-lvl Cisco AV pair. NX-OS does not honor the Service-Type by default, but requires the shell:roles Cisco AV pair to assign the network-admin or network-operator roles to the user. Therefore, I feel that it is better to always explicitly define the privilege level or role for IOS and NX-OS users.
Because this configuration is intended to be used for both IOS and NX-OS, it is necessary to define two Cisco-AVPair attributes. To pass both these attributes in the response instead of just the first one, it is necessary to use the “+=” operator on the second Cisco AV pair.
If you run into situations where the RADIUS client refuses the connection because it does not understand one of the two Cisco-AVPair attributes, you could replace the “=” in the AV pair with a “*” to make it an optional attribute (for example "shell:roles*network-admin" instead of "shell:roles=network-admin"). With the versions of NX-OS, IOS and ASA software that I used for testing this was not necessary.
And finally, I first tried to name my “ops” user “operator”, finding out the hard way that this is one of the reserved NX-OS usernames, causing the logins to fail. Other names that cannot be used are defined in the NX-OS documentation, for example the Nexus 1000v Security Configuration Guide. So be warned, these names really cannot be used!
Now that we have a our basic FreeRADIUS configuration in place, we can start adding AAA configuration to the various devices and start testing. First I configure my lab Nexus 1000v:
radius-server host 192.168.36.102 key Fr33-R@d1u$ authentication accounting
!
aaa group server radius FREERADIUS
server 192.168.36.102
use-vrf management
source-interface mgmt0
!
aaa authentication login default group FREERADIUS
aaa accounting default group FREERADIUS
Next I login as the user “tom” and verify my role:
tom@freeradius:~$ ssh [email protected]
Nexus 1000v Switch
Password:
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2013, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under
license. Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or the GNU
Lesser General Public License (LGPL) Version 2.1. A copy of each
such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://www.opensource.org/licenses/lgpl-2.1.php
n1kv# show user-account tom
user:tom
roles:network-admin
account created through REMOTE authentication
Credentials such as ssh server key will be cached temporarily only for this user account
Local login not possible
And of course I also want to verify my “ops” user and its assigned role:
tom@freeradius:~$ ssh [email protected]
Nexus 1000v Switch
Password:
Cisco Nexus Operating System (NX-OS) Software
TAC support: http://www.cisco.com/tac
Copyright (c) 2002-2013, Cisco Systems, Inc. All rights reserved.
The copyrights to certain works contained in this software are
owned by other third parties and used and distributed under
license. Certain components of this software are licensed under
the GNU General Public License (GPL) version 2.0 or the GNU
Lesser General Public License (LGPL) Version 2.1. A copy of each
such license is available at
http://www.opensource.org/licenses/gpl-2.0.php and
http://www.opensource.org/licenses/lgpl-2.1.php
n1kv# show user-account ops
userps
roles:network-operator
account created through REMOTE authentication
Credentials such as ssh server key will be cached temporarily only for this user account
Local login not possible
As can be seen, these users are properly authenticated and assigned their respective roles. Next, I configure AAA on a CSR 1000v instance to test the FreeRADIUS configuration on an IOS device:
aaa new-model
!
radius server FREERADIUS
address ipv4 192.168.36.102 auth-port 1812 acct-port 1813
key Fr33-R@d1u$
!
aaa group server radius LAB-RADIUS
server name FREERADIUS
ip vrf forwarding Mgmt-intf
ip radius source-interface GigabitEthernet0
!
aaa authentication login default group LAB-RADIUS local
aaa authorization exec default group LAB-RADIUS local
aaa accounting exec default start-stop group LAB-RADIUS
Again, I log in as user “tom” and verify my privilege level:
tom@freeradius:~$ ssh [email protected]
Password:
csr1kv#show privilege
Current privilege level is 15
And I also test the ops user account:
tom@freeradius:~$ ssh [email protected]
Password:
csr1kv>show privilege
Current privilege level is 1
Again, the output confirms that the users have been successfully authenticated and proper privilege levels have been assigned. Finally, I configure my ASA:
aaa-server FREERADIUS protocol radius
aaa-server FREERADIUS (inside) host 192.168.36.102
key Fr33-R@d1u$
authentication-port 1812
accounting-port 1813
aaa authentication http console FREERADIUS LOCAL
aaa authentication ssh console FREERADIUS LOCAL
aaa authentication enable console FREERADIUS LOCAL
aaa accounting ssh console FREERADIUS
aaa authorization exec authentication-server
And again, I login as user “tom”:
tom@skywalker:~$ ssh [email protected]
[email protected]'s password:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++ + +
+ + This is firewall r2d2 ++
++ Nothing to see here, so go away! + +
+ + ++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Type help or '?' for a list of available commands.
r2d2> show curpriv
Username : tom
Current privilege level : 1
Current Mode/s : P_UNPR
r2d2> enable
Password: ********
r2d2# show curpriv
Username : tom
Current privilege level : 15
Current Mode/s : P_PRIV
As you can see the ASA does not immediately drop the user in privileged mode. However, it does allow a user that has the Service-Type = Administrative-User attribute to issue the enable command and go to privileged mode using the user’s RADIUS password instead of the locally defined enable password. Now let’s see what happens when I log in as the user “ops”:
tom@skywalker:~$ ssh [email protected]
[email protected]'s password:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++ + +
+ + This is firewall r2d2 ++
++ Nothing to see here, so go away! + +
+ + ++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Type help or '?' for a list of available commands.
r2d2> show curpriv
Username : ops
Current privilege level : 1
Current Mode/s : P_UNPR
r2d2> enable
Password: ********
[ ops ] You do NOT have enable Admin Rights to the console
Password:
As can be seen, this time the ASA does not allow the user to use the enable command to go to privileged mode based on the Service-Type = NAS-Prompt-User attribute. So for CLI access everything now works as I had set down in my requirements. However, there is still a little catch here. When I login to ASDM, the “ops” user still gets full access. Apparently, just setting the Service-Type is not sufficient for ASDM, because it does not use the enable command and the ASA does not honor the Cisco shell:priv-lvl attribute. When I log in to ASDM as the “ops” user, it lists a privilege level of 15 in the bottom right corner next to the user name. So it looks like we need another RADIUS tweak.
To fix this we need to use another RADIUS attribute to set the privilege level for the ASA. This attribute originally comes from the Cisco/Altiga VPN 3000 concentrators. Unfortunately, the Cisco VPN dictionary is disabled by default in the FreeRADIUS dictionary file in /usr/share/freeradius/dictionary:
#
# The Cisco VPN300 dictionary is the same as the altiga one.
# You shouldn't use both at the same time.
#
#$INCLUDE dictionary.cisco.vpn3000
Despite the comment in the file, the Altiga dictionary is not enabled by default either, so I decide to simple uncomment the $INCLUDE dictionary.cisco.vpn3000 line to include the VPN 3000 dictionary. This enables the use of the CVPN3000-Privilege-Level attribute (vendor ID 3076 and attribute ID 220), which can be used to set the privilege level for the ASA.
Now that the Cisco VPN 3000 library has been enabled I add the appropriate privilege levels to the users in my user file:
admin Cleartext-Password := 1234QWer
Service-Type = Administrative-User,
Cisco-AVPair = "shell:roles=network-admin",
Cisco-AVPair += "shell:priv-lvl=15",
CVPN3000-Privilege-Level = 15
ops Cleartext-Password := 1234QWer
Service-Type = NAS-Prompt-User,
Cisco-AVPair = "shell:roles=network-operator",
Cisco-AVPair += "shell:priv-lvl=1",
CVPN3000-Privilege-Level = 3
tom Auth-Type := System
Service-Type = Administrative-User,
Cisco-AVPair = "shell:roles=network-admin",
Cisco-AVPair += "shell:priv-lvl=15",
CVPN3000-Privilege-Level = 15
And of course I need to restart the service again to commit my changes:
tom@freeradius:~$ sudo service freeradius restart
* Stopping FreeRADIUS daemon freeradius
...done.
* Starting FreeRADIUS daemon freeradius
...done.
You may wonder why I am setting the privilege level of the “ops” user to 3, instead of using level 1 like I did for IOS. The reason for this is that ASDM requires users to have a minimum privilege level of 2 to allow them to login. In addition, ASDM has a special button that makes it simple to setup the required command authorization for a monitor-only user like my “ops” user.
This is actually the next step in the procedure: I log in to ASDM as the admin user and then navigate to “Configuration > Device Management > Users/AAA > AAA Access > Authorization”. Next, I check the command authorization checkbox and set it to local. Then I click the “Set ASDM Defined User Roles” button to assign appropriate privilege levels to a predefined set of commands. Once these settings are applied, the following list of commands is added to the ASA:
aaa authorization command LOCAL
privilege cmd level 3 mode exec command perfmon
privilege cmd level 3 mode exec command ping
privilege cmd level 3 mode exec command who
privilege cmd level 3 mode exec command logging
privilege cmd level 3 mode exec command failover
privilege cmd level 3 mode exec command vpn-sessiondb
privilege cmd level 3 mode exec command packet-tracer
privilege show level 5 mode exec command import
privilege show level 5 mode exec command running-config
privilege show level 3 mode exec command reload
privilege show level 3 mode exec command mode
privilege show level 3 mode exec command firewall
privilege show level 3 mode exec command asp
privilege show level 3 mode exec command cpu
privilege show level 3 mode exec command interface
privilege show level 3 mode exec command clock
privilege show level 3 mode exec command dns-hosts
privilege show level 3 mode exec command access-list
privilege show level 3 mode exec command logging
privilege show level 3 mode exec command vlan
privilege show level 3 mode exec command ip
privilege show level 3 mode exec command ipv6
privilege show level 3 mode exec command failover
privilege show level 3 mode exec command asdm
privilege show level 3 mode exec command arp
privilege show level 3 mode exec command route
privilege show level 3 mode exec command ospf
privilege show level 3 mode exec command aaa-server
privilege show level 3 mode exec command aaa
privilege show level 3 mode exec command eigrp
privilege show level 3 mode exec command crypto
privilege show level 3 mode exec command ssh
privilege show level 3 mode exec command vpn-sessiondb
privilege show level 3 mode exec command vpnclient
privilege show level 3 mode exec command vpn
privilege show level 3 mode exec command dhcpd
privilege show level 3 mode exec command blocks
privilege show level 3 mode exec command wccp
privilege show level 3 mode exec command dynamic-filter
privilege show level 3 mode exec command webvpn
privilege show level 3 mode exec command service-policy
privilege show level 3 mode exec command module
privilege show level 3 mode exec command uauth
privilege show level 3 mode exec command compression
privilege show level 3 mode configure command interface
privilege show level 3 mode configure command clock
privilege show level 3 mode configure command access-list
privilege show level 3 mode configure command logging
privilege show level 3 mode configure command ip
privilege show level 3 mode configure command failover
privilege show level 5 mode configure command asdm
privilege show level 3 mode configure command arp
privilege show level 3 mode configure command route
privilege show level 3 mode configure command aaa-server
privilege show level 3 mode configure command aaa
privilege show level 3 mode configure command crypto
privilege show level 3 mode configure command ssh
privilege show level 3 mode configure command dhcpd
privilege show level 5 mode configure command privilege
privilege clear level 3 mode exec command dns-hosts
privilege clear level 3 mode exec command logging
privilege clear level 3 mode exec command arp
privilege clear level 3 mode exec command aaa-server
privilege clear level 3 mode exec command crypto
privilege clear level 3 mode exec command dynamic-filter
privilege cmd level 3 mode configure command failover
privilege clear level 3 mode configure command logging
privilege clear level 3 mode configure command arp
privilege clear level 3 mode configure command crypto
privilege clear level 3 mode configure command aaa-server
When I log in to ASDM as the “ops” user, I now properly get a privilege level of 3 assigned and I only see the monitor tab, not the configuration tab. I also retest the CLI access for the various devices to verify that these were not affected by the changes.
With this final tweak I now have FreeRADIUS properly set up to provide AAA services to all devices in my home and lab networks. Also, this post can serve as a “known-good” reference configuration for RADIUS implementations on different platforms.
No comments:
Post a Comment