Using RADIUS for AAA


The RADIUS protocol is the de facto standard for implementing centralized authentication, authorization, and accounting by multiple vendors. RADIUS is widely popular across the industry because it is a fully open protocol. A RADIUS server is distributed in source code format and can be modified to work with any security system that is currently on the market. Similar to the TACACS+-based AAA deployment covered in previous sections, the following sections discuss RADIUS deployment. Specifically, the discussion covers deploying a RADIUS Server and configuring RADIUS-based AAA on various Cisco devices.

Deploying a Linux-Based RADIUS Server

RADIUS, originally developed by Livingston, was later enhanced by various open source projects. Several of the open source RADIUS products were enterprise grade and are still used by Internet service providers (ISP) around the world. The following is a partial list of the most popular enterprise-grade RADIUS Server products that run in Linux (and other UNIX variants):

  • Cistron This is the most widely used RADIUS Server in the free-software community. Although it is no longer in active development, maintenance release 1.6.7 is still supported. The home page is http://www.radius.cistron.nl.

  • XtRADIUS This Cistron variant offers extensions that run external programs for accounting or authentication. It is included with Debian as the default RADIUS package. The home page is http://xtradius.sourceforge.net/.

  • OpenRADIUS This RADIUS flavor offers pluggable modules for all the functionalities, providing better control for the Netadmin. The home page is http://www.openradius.org.

  • GNU-RADIUS This revamped variant of Cistron has been rewritten with newer configuration files. The home page is http://www.gnu.org/software/radius/radius.html.

  • FreeRADIUS This forked variant of Cistron is currently under development, providing the latest enhancements. The home page is http://www.freeradius.org/.

Of all these RADIUS Servers, this discussion covers FreeRADIUS because it offers the following advantages:

  • Uses the stable and tested Cistron code

  • Is one of the most widely deployed RADIUS Servers

  • Is under active development

  • Supports newer features such as Cisco LEAP

You must have a Linux machine, with network connectivity, to install the FreeRADIUS server software. After installation, you must edit the configuration text files that control the FreeRADIUS server properties. Following configuration, you can start the server for use within the network.

Installing the FreeRADIUS Server

Download the FreeRADIUS installation files, in compressed tar file format, from the FreeRADIUS home page at http://www.freeradius.org. This discussion is based on the stable release file freeradius-1.0.0.tar.gz. The compressed tar file (represented by the tar.gz extension) contains the installation files for the FreeRADIUS server.

To uncompress and install the server, follow these steps:

Step 1.

Extract the installable files from the downloaded tar file as follows:

  [root@Linuxbox root]# ls  freeradius-1.0.0.tar.gz  [root@Linuxbox root]$ tar zxvf freeradius-1.0.0.tar.gz 

Step 2.

Change the directory to the extracted location using the following command:

  [root@Linuxbox root]# cd freeradius-1.0.0 

Step 3.

Run the configuration process by using the following commands:

  [root@Linuxbox freeradius-1.0.0]# ./configure  [root@Linuxbox freeradius-1.0.0]# make  [root@Linuxbox freeradius-1.0.0]# make install 

Note

Debian users can use the apt-get install freeradius command to quickly install the FreeRADIUS server.


Configuring the FreeRADIUS Server

The text files located in the default directory (/etc/raddb) control the properties of the FreeRADIUS server. These files are automatically created during the installation process and must be edited before starting the FreeRADIUS server. However, unless specified otherwise, do not delete or remove the default content of these files. Instead, add the newer configuration at the bottom of the existing file. Within each of these text files, every line starting with a hash sign (#) is treated as a comment. Table 3-12 provides a list of relevant files that must be tweaked before deploying the FreeRADIUS server in a Cisco network.

Table 3-12. FreeRADIUS Configuration Files

Filename

Purpose

/etc/raddb/clients.conf

Specifies the list of clients that will be accessing the FreeRADIUS server; the list includes the IP addresses and the secret key for each client.

/etc/raddb/users

Specifies the list of users; the list includes the authentication and authorization parameters for each user.

/etc/raddb/radiusd.conf

Specifies the global configuration for the FreeRADIUS server; exercise caution while editing this file.

/etc/raddb/dictionary

Specifies the list of dictionary files for each supported vendor; the server has separate dictionary files for each supported vendor that contain RADIUS attributes and values.

/etc/raddb/acct_users

Specifies the parameters for logging accounting messages.


Note

In Debian Linux, if the FreeRADIUS server is installed using the apt-get install freeradius command, the default directory of the text files is /etc/freeradius instead of /etc/raddb. However, there is no other impact on the properties of the FreeRADIUS server.


The following sections provide more information for each of the files listed in Table 3-12.

/etc/raddb/clients.conf File

The /etc/raddb/client.conf file contains a list of all the RADIUS clients that can query the FreeRADIUS server for AAA requests. The format for adding each RADIUS client is as follows:

   # CLIENT CONFIG BEGINS   client hostname-or-IP-address {           secret          = encryption-key           shortname       = hostname           nastype         = type-of-RADIUS-client   }   # CLIENT CONFIG ENDS 

You can specify the client either by host name or IP address. The encryption key for specifying the value of secret should be exactly similar to that specified for the RADIUS Client. The shortname parameter is used to specify an alias for the host, while the nastype is always cisco for Cisco devices. The default /etc/raddb/clients.conf file only contains one entry for the localhost. Each additional client should be appended to the default file. Optionally, you can also specify a network address (for example, 192.168.5.0/24) instead of a single client. The following sample snippet can be appended to the default /etc/raddb/ clients.conf file:

   # ADD A SINGLE CLIENT   client 192.168.0.10 {           secret          = testing123           shortname       = CiscoRouter           nastype         = cisco   }   # ADD A NETWORK SUBNET   client 192.168.5.0/24 {           secret          = testing123567           shortname       = Brach-office           nastype         = cisco   }   # CONFIG ENDS 

The first entry adds a single client with IP address 192.168.0.10, while the second entry adds all the clients in the 192.168.5.0/24 subnet.

/etc/raddb/users File

The /etc/raddb/users file contains a list of users and their credential information. The format for adding a user in the /etc/raddb/users file is as follows:

   user             Auth-Type := "local-or-system-authentication"                     Service-Type = Shell-User,                     Cisco-AVPair = " protocol:attribute sep value" 

Table 3-13 provides an explanation of each field used to define user credentials in the /etc/ raddb/users file.

Table 3-13. Fields in the /etc/raddb/users File

Field

Description

user

Specifies the username.

Auth-type

Specifies the type of authentication for the user. Possible values are System, for using the password defined on Linux machines, and Local, for using a clear-text password. Additionally, for Local authentication, specify the password in the same line using the syntax User-password == "password".

Service-Type

Defines the service type for the user; the value for authenticating the exec shell is Shell-User.

Cisco-AVPair = "protocol:attribute sep value"

Specifies a full set of TACACS+ authorization features to be used for an authenticated user by RADIUS. The keyword protocol is a value of the Cisco protocol attribute for a particular type of authorization. The pair, of keywords attribute and value, is an appropriate Attribute-Value (AV) pair defined in the Cisco TACACS+ specification. The keyword sep can be replaced by the equal sign (=) for mandatory attributes and asterisk (*) for optional attributes.


Based on the description in Table 3-13, the following code can be added to the /etc/raddb/ users file. This code snippet defines two users, with username spope and jkeith, respectively:

   spope         Auth-Type := System                  Service-Type = Shell-User,                  Cisco-AVPair = "shell:priv-lvl=15",                  Cisco-AVPair = "shell:cmd*"   jkeith         Auth-Type := Local, Password == "securepassword123"                  Service-Type = Shell-User,                  Cisco-AVPair = "shell:priv-lvl=1",                  Cisco-AVPair = "shell:cmd*" 

Note that user spope is configured to use the system password, while user jkeith is using the local password securepassword123. For authentication to succeed for the user spope, you must create a user spope using the Linux command adduser. User spope is assigned privilege level of 15, whereas user jkeith has a limited privilege level of 1. Additionally, the statement Cisco-AVPair = "shell:cmd*" exclusively authorizes the use of the command shell for each user.

Note

The default contents of the /etc/raddb/users file might conflict with the configurations for new users and can lead to unexpected results. In such cases, either insert the new configuration at the beginning of the default file, or better yet, create a fresh /etc/raddb/users file that contains the new configuration only. In the latter case, rename the original /etc/ raddb/users file before creating the new one.


/etc/raddb/radiusd.conf File

The /etc/raddb/radiusd.conf file defines the global configuration for the FreeRADIUS server. The /etc/raddb/radiusd.conf file is a large file, and most of the contents do not need tweaking. However, to use the FreeRADIUS server in a Cisco environment, you must tweak the parameters listed in Table 3-14.

Table 3-14. /etc/raddb/radiusd.conf File Parameters

Parameter

Description

log_auth_badpass

Controls the logging of failed authentication requests; possible values are yes on no. Useful in catching suspicious login activities.

log_auth_goodpass

Controls the logging of successful authentication requests; possible values are yes on no. Useful in catching suspicious login activities.

passwd

Specifies the location of user passwords on the Linux machine.

shadow

Specifies the location of user passwords on the Linux machine that are using shadow passwords.

group

Specifies the location of group files on the Linux machine.

with_cisco_vsa_hack

Enables the RADIUS Server to correctly interpret the response received from the Cisco devices; possible values are yes and no.


Referring to the parameters listed in Table 3-14, the contents of the /etc/raddb/radiusd.conf file should match the following output:

    #OUTPUT SUPPRESSED    log_auth_badpass = yes    log_auth_goodpass = yes    #OUTPUT SUPPRESSED    unix {                  #OUTPUT SUPPRESSED                  passwd = /etc/passwd                  shadow = /etc/shadow                  group = /etc/group                  #OUTPUT SUPPRESSED    }    #OUTPUT SUPPRESSED         preprocess {                   #OUTPUT SUPPRESSED                   with_cisco_vsa_hack = no                  #OUTPUT SUPPRESSED            } 

Caution

Exercise caution while editing the radiusd.conf file. You should make a backup copy of this file before making changes. Except for the parameters discussed in this section, do not make changes to this file. Also, do not change the order in which the commands appear within the file.


/etc/raddb/dictionary File

A dictionary file contains a list of RADIUS attributes and values for a particular vendor. The /etc/raddb/dictionary file is a master file that references other dictionary files by using the following statement:

    $INCLUDE /usr/share/freeradius/dictionary 

For the FreeRADIUS server to include Cisco-specific dictionary files, the /usr/share/ freeradius/dictionary file must contain the following three statements:

    $INCLUDE dictionary.cisco    $INCLUDE dictionary.cisco.vpn3000    $INCLUDE dictionary.cisco.vpn5000 

/etc/raddb/acct_users File

By default, the accounting feature on the FreeRADIUS server is turned off. To enable accounting, you must uncomment the two DEFAULT Acct-Status-Type statements in the / etc/raddb/acct_users file, as follows:

    # BEFORE ENABLING ACCOUNTING    # DEFAULT Acct-Status-Type == Start    # DEFAULT Acct-Status-Type == Stop    # AFTER ENABLING ACCOUNTING    DEFAULT Acct-Status-Type == Start    DEFAULT Acct-Status-Type == Stop    # END OF CONFIGURATION 

The RADIUS server records the accounting logs in the /var/log/radius/radacct directory.

Running the FreeRADIUS Server

So far, the discussion has covered the installation and configuration of the Linux-based RADIUS Server to implement access control over Cisco devices. This section prepares you to run and debug the FreeRADIUS server.

The command to run the FreeRADIUS server is radiusd. The radiusd command offers various CLI switches that can override the options specified in configuration files. A partial list of options is shown in Table 3-15.

Table 3-15. Options for the radiusd Command

Option

Description

-a accounting-directory

Specifies the directory for logging accounting messages.

-A

Logs the authentication detail.

-c

Verifies the syntax and contents of the configuration text files and the password/group/shadow files without loading into the server; useful for testing purposes without affecting the production environment.

-h

Prints this help message.

-l logging-directory

Specifies the directory for sending system logs; optionally uses the keyword syslog to send all messages to the system logger.

-p port

By default, the FreeRADIUS server listens on the ports specified for RADIUS authentication (radius) and RADIUS accounting (radacct) in the /etc/services file. To change the default behavior, specify the UDP port used by the FreeRADIUS server to listen to radius requests; the server uses port+1 to listen to radacct requests.

-v

Shows the server version information.

-X

Turns on complete debugging; this is the maximum debugging level.

-x

Turns on partial debugging; use the -xx option for more information.

-y

Logs authentication failures, including the password; the option is similar to the log_auth_badpass parameter within the radiusd.conf file.

-z

Logs authentication successes, including the password; similar to the log_auth_goodpass parameter within the radiusd.conf file. Use this option only for troubleshooting, because it logs all the passwords in clear text.


Before starting the FreeRADIUS server, always verify the configuration using the radiusd command with the -c option, as follows:

    [root@Linuxbox raddb]# radiusd -c    Sat Aug 28 11:44:21 2004 : Info: Starting - reading configuration files ... 

Follow the messages to rectify any errors.

To verify that the server is running, use the ps command, as follows:

    [root@Linuxbox raddb]# ps -ef | grep radius   root     20099     1 0 11:44 ?        00:00:00 radiusd -c   root     20106 19872 0 11:44 pts/0    00:00:00 grep radius 

The changes made to the configuration files do not take effect until the FreeRADIUS server is restarted. In such cases, to stop the service, use the kill pid command, where pid is the ID of the server process as identified using the ps -ef command. The command example is as follows:

    [root@Linuxbox raddb]# kill 20099 

After verifying the configuration files, restart the FreeRADIUS server in debug mode. Based on the options listed in Table 3-15, the command for running FreeRADIUS in debug mode is radiusd -xxyz. Using the radiusd -X command produces the same result as the radiusd -xxyz command. After starting in debug mode, test the server by sending authentication requests from a Cisco device. (The configuration of Cisco devices, specifically IOS devices, CatOS switches, and PIX Firewalls, as RADIUS Clients is discussed in later sections of this chapter.)

The server displays the transactions to and from the clients that request authentication. The debug messages are helpful in troubleshooting both server and client issues. The output of the radiusd -xxyz command is shown in Example 3-15.

Example 3-15. Output of the radiusd Command in Debug Mode
 [root@linuxbox root]# radiusd -xxyz Starting - reading configuration files ... Using deprecated naslist file. Support for this will go away soon. Module: Loaded exec rlm_exec: Wait=yes but no output defined. Did you mean output=none? Module: Instantiated exec (exec) Module: Loaded expr Module: Instantiated expr (expr) Module: Loaded PAP Module: Instantiated pap (pap) Module: Loaded CHAP Module: Instantiated chap (chap) Module: Loaded MS-CHAP Module: Instantiated mschap (mschap) Module: Loaded System Module: Instantiated unix (unix) Module: Loaded eap rlm_eap: Loaded and initialized type md5 rlm_eap: Loaded and initialized type leap rlm_eap: Loaded and initialized type gtc rlm_eap: Loaded and initialized type mschapv2 Module: Instantiated eap (eap) Module: Loaded preprocess Module: Instantiated preprocess (preprocess) Module: Loaded realm Module: Instantiated realm (suffix) Module: Loaded files Module: Instantiated files (files) Module: Loaded Acct-Unique-Session-Id Module: Instantiated acct_unique (acct_unique) Module: Loaded detail Module: Instantiated detail (detail) Module: Loaded radutmp Module: Instantiated radutmp (radutmp) Initializing the thread pool... Listening on authentication *:1812 Listening on accounting *:1813 Listening on proxy *:1814 Ready to process requests. rad_recv: Access-Request packet from host 192.168.0.10:1645, id=102, length=78 NAS-IP-Address = 192.168.0.10 NAS-Port = 1 NAS-Port-Type = Virtual User-Name = "spope" Calling-Station-Id = "192.168.0.100" User-Password = "something" rlm_unix: [spope]: invalid password rad_recv: Access-Request packet from host 192.168.0.10:1645, id=102, length=78 Sending Access-Reject of id 102 to 192.168.0.10:1645 Cisco-AVPair = "shell:priv-lvl=15" rad_recv: Access-Request packet from host 192.168.0.10:1645, id=103, length=78 NAS-IP-Address = 192.168.0.10 NAS-Port = 1 NAS-Port-Type = Virtual User-Name = "spope" Calling-Station-Id = "192.168.0.100" User-Password="password123" Sending Access-Accept of id 103 to 192.168.0.10:1645 Service-Type = Administrative-User Cisco-AVPair = "shell:priv-lvl=15" rad_recv: Accounting-Request packet from host 192.168.0.10:1646, id=104, length=94 NAS-IP-Address = 192.168.0.10 NAS-Port = 1 NAS-Port-Type = Virtual User-Name = "spope" Calling-Station-Id = "192.168.0.100" Acct-Status-Type = Start Acct-Authentic = RADIUS Service-Type = NAS-Prompt-User Acct-Session-Id = "0000006D" Acct-Delay-Time = 0 Sending Accounting-Response of id 104 to 192.168.0.10:1646 rad_recv: Accounting-Request packet from host 192.168.0.10:1646, id=105, length=106 NAS-IP-Address = 192.168.0.10 NAS-Port = 1 NAS-Port-Type = Virtual User-Name = "spope" Calling-Station-Id = "192.168.0.100" Acct-Status-Type = Stop Acct-Authentic = RADIUS Service-Type = NAS-Prompt-User Acct-Session-Id = "0000006D" Acct-Terminate-Cause = User-Request Acct-Session-Time = 32 Acct-Delay-Time = 0 Sending Accounting-Response of id 105 to 192.168.0.10:1646 

Tip

If you do not have a Cisco device configured as a RADIUS Client, you can use the radtest command to test authentication on the FreeRADIUS server. The syntax is as follows:

radtest user password radius-server[:port] nas-port-number secret

Output from the radtest command is as follows:

     root@linuxbox:~# radtest spope password123 127.0.0.1 10 testing123     Sending Access-Request of id 84 to 127.0.0.1:1812             User-Name = "spope"             User-Password = "password123"             NAS-IP-Address = linuxbox             NAS-Port = 10     rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=84, length=20 


After verifying the configuration and running the server in debug mode, start the FreeRADIUS server by using the radiusd command, as follows:

    [root@Linuxbox raddb]# radiusd    Sat Aug 28 12:25:21 2004 : Info: Starting - reading configuration files ... 

The server is now ready for deployment.

Configuring a Microsoft IAS Server as a RADIUS Server

Within the realm of access control using a RADIUS Server in a Cisco network, this discussion focuses on the use of a Windows-based Internet Authentication Service (IAS) server. IAS is a built-in RADIUS server within a Windows server.

Microsoft Windows 2000 IAS is the Microsoft implementation of a RADIUS Server. IAS is fully compliant with RFC 2138 and RFC 2139. To provide backward-compatibility, IAS uses UDP ports 1812 and 1645 for authentication and UDP ports 1813 and 1646 for accounting. Although an earlier version of IAS was included in the NT 4.0 option pack, a newer version is shipped as part of the Windows 2000 and 2003 servers. Windows 2000 IAS server for RADIUS provides the following advantages to the Netadmin:

  • Integration with Windows 2000 Active Directory services. This provides a single centralized authentication database across the enterprise for all clients, including nonLDAP devices.

  • No additional licensing or software requirements, because the product is part of Windows 2000 and 2003 servers and can be installed through the Add/Remove Programs icon.

  • Easy administration through the Microsoft Management Console (MMC).

  • Authorized users can access Cisco devices using their Windows username and password.

The first step in deploying an IAS server is installing it over a Windows server. Next, you must add RADIUS Clients and configure policies and accounting parameters in the IAS server.

Installing the Microsoft IAS-Based RADIUS Server

The IAS service can be added to any existing Microsoft Windows 2000 or 2003 server as long as enough resources are available to support the installed applications. Follow these steps to install a Microsoft IAS-based RADIUS Server:

Step 1.

Choose Start > Settings > Control Panel > Add/Remove Programs.

Step 2.

In the Add/Remove Programs window, click the Add/Remove Windows Components button to open the Windows components window.

Step 3.

In the Windows components window, select Networking Services and click the Details button.

Step 4.

In the Networking Services window, select the Internet Authentication Service check box (as shown in Figure 3-3) and click the OK button to return to the Windows components window.

Figure 3-3. Installing IAS


Step 5.

In the Windows components window, click the Next button to begin the installation, and then click the Finish button.

The IAS server is now added.

Note that after installing a new server, it is good practice to update the server with the latest security patches and service packs from the Microsoft website.

Configuring the Microsoft IAS-Based RADIUS Server

After IAS has been added to your Microsoft server, you must configure it. The IAS MMC, as shown in Figure 3-4, is the graphical user interface (GUI) for administration and configuration of IAS services. To open the IAS MMC, choose Start > Programs > Administrative Tools > Internet Authentication Service.

Figure 3-4. IAS MMC


The configuration of the IAS server can be best described by using the sample scenario shown in Figure 3-5. The Windows server (with host name DALLAS-RADIUS) is running the IAS service and is part of the Active Directory domain IASTEST. The network users and groups are already defined in the MS Active Directory with the group memberships shown in Table 3-16. DALLAS-RADIUS responds to RADIUS queries from the router and firewall. Note that the configuration of Cisco routers, switches, and PIX Firewalls as RADIUS clients is discussed in the following sections of this chapter.

Figure 3-5. Network with IAS Server


Table 3-16. User Group Membership

User

Username

Windows Group Membership

1

spope

Netadmin, Domain Admins

2

jkeith

Helpdesk, Domain Users


Note

Domain Admins and Domain Users are the default groups created within the MS Active Directory. The groups (Netadmin and Helpdesk) and users (spope and jkeith) were created using the Active Directory Users and Computers MMC snap-in. To open this snap-in in the MMC, choose Start > Programs > Active Directory Users and Computers.


The steps involved in configuring the IAS server are as follows:

  • Adding the clients

  • Configuring remote access policies

  • Configuring accounting parameters

Adding the Clients

The first task in configuring the IAS server is to add the RADIUS Clients to the IAS server using the IAS MMC. Based on the scenario shown in Figure 3-5, the Cisco network devices (Dallas-Router and Dallas-Firewall) are the clients that would be querying the IAS server for authentication. The steps for adding these RADIUS Clients are as follows:

Step 1.

From within the IAS MMC window, choose Clients > New > Client to open the Add Client window, as shown in Figure 3-6.

Figure 3-6. Adding Clients in IAS


Step 2.

In the Add Client window, specify dallas-router as the name of the client and click the Next button.

Step 3.

In the Add RADIUS Client window, as shown in Figure 3-7, specify the IP address used by dallas-router. In the Shared secret field, enter the same encryption key that is defined in the AAA configuration of dallas-router. For this example, the key is testing123.

Figure 3-7. Client Parameters in IAS


Step 4.

Repeat Steps 1 to 3 to add Firewall-Dallas to the IAS server.

Step 5.

Figure 3-8 shows the IAS MMC with two clients, dallas-router and dallas-firewall.

Figure 3-8. IAS MMC Clients


Configuring Remote-Access Policies

Remote-access policies determine the authentication and authorization permissions to be assigned to the authenticating users. Referring to the scenario shown in Figure 3-5, the two users, spope and jkeith, belong to the groups Netadmin and Helpdesk, respectively. The privilege levels assigned to the groups Netadmin and Helpdesk are 15 and 1, respectively. Consequently, when the members of the Helpdesk Active Directory group log in to the network devices, they would be authenticated using their Active Directory passwords and assigned a privilege level of 1. Similarly, the Netadmin group would be assigned privilege level 15. To implement such a scenario, you must create two remote-access policies, one each for Helpdesk and Netadmin. Follow these steps to create the policies:

Step 1.

In the IAS MMC, choose Remote Access Policy > New > Remote Access Policy. This action opens the Add Remote Access Policy window, as shown in Figure 3-9.

Figure 3-9. Add Remote Access Policy


Step 2.

In the Add Remote Access Policy window, enter the preferred name. The name entered in this example is Helpdesk to reflect the policy content; however, you can choose any arbitrary name. Then click the Next button to navigate to the Conditions field, as shown in Figure 3-10.

Figure 3-10. Add Remote Access Policy Conditions


Step 3.

In the Specify the conditions to match section, click the Add button to open the Select Attribute window, as shown in Figure 3-11.

Figure 3-11. Select Attribute


Step 4.

In the Select Attribute window, select Windows-Groups and click the Add button to open the Groups window, as shown in Figure 3-12.

Figure 3-12. Groups


Step 5.

Click the Add button in the Groups window to open the Select Groups window. This window lists all the Active Directory users and groups.

Step 6.

Scroll down to locate the Helpdesk Active Directory group, as shown in Figure 3-13, and click the Add button. Then click the OK button to return to the Groups window.

Figure 3-13. Active Directory Groups


Step 7.

In the Groups window, click the OK button to return to the Add Remote Access Policy window.

Step 8.

In the Add Remote Access Policy window, click the Next button and select the Grant remote access permission option in the Permissions section, as shown in Figure 3-14.

Figure 3-14. Permissions


Step 9.

Click the Next button again to enter the User Profile section, as shown in Figure 3-15.

Figure 3-15. User Profile


Step 10.

In the User Profile section, click the Edit Profile button to open the Edit Dial-in Profile window.

Step 11.

In the Edit Dial-in Profile window, select the Authentication tab and select the Unencrypted Authentication check box, as shown in Figure 3-16.

Figure 3-16. Edit Dial-In Profile


Step 12.

Click the Advanced tab and remove all the entries in the Parameters section, as shown in Figure 3-17. Then click the Add button to open the Add Attributes window, as shown in Figure 3-18.

Figure 3-17. Advanced Tab


Figure 3-18. Add Attributes


Step 13.

In the Add Attributes window, select the Vendor-Specific attribute and click the Add button to open the Multivalued Attribute Information window, as shown in Figure 3-19.

Figure 3-19. Multivalued Attribute Information


Step 14.

In the Multivalued Attribute Information window, click the Add button to open the Vendor-Specific Attribute Information window.

Note

The vendor-specific attributes, or VSAs, are RADIUS attributes defined by vendors to customize how RADIUS works on their servers.

Step 15.

In the Vendor-Specific Attribute Information window, select the options that are shown in Figure 3-20. Then click the Configure Attribute button to open the Configure VSA (RFC compliant) window.

Figure 3-20. Vendor-Specific Attribute


Step 16.

Change the fields in the Configure VSA (RFC compliant) window to match those shown in Figure 3-21. Note the string shell:priv-lvl=1. This string assigns the privilege level of 1 to the authenticated users.

Figure 3-21. Configure VSA (RFC Compliant)


Step 17.

Click the appropriate buttons to save and close all the open windows and return to the Advanced tab of the Edit Dial-in Profile window.

Step 18.

On the Advanced tab of the Edit Dial-in Profile window, click the Add button again to open the Add Attributes window.

Step 19.

In the Add Attributes window, select the Service-Type attribute, as shown in Figure 3-22. Then click the Add button to open the Enumerable Attribute Information window.

Figure 3-22. Add Attribute


Step 20.

In the Enumerable Attribute Information window, change the Attribute value field to Login, as shown in Figure 3-23.

Figure 3-23. Enumerable Attribute Information


Step 21.

Click the appropriate buttons to save and close the open windows and return to the Add Remote Access Policy window. Click the Finish button to return to the IAS MMC.

Step 22.

Repeat Steps 1 through 21 to create the Netadmin policy with a privilege level of 15.

Configuring Accounting Parameters

The accounting parameters are configured through the Remote Access Logging window. The default location of the logs is the %WINDOWS%/system32/Logfiles directory. To view or change the default accounting parameters through the IAS MMC, select the Remote Access Logging option and choose Local File > Properties to open the Local File Properties window, as shown in Figure 3-24.

Figure 3-24. Local File Properties


As shown in Figure 3-24, by default, the New log time period section is set to the Unlimited file size option. This results in a single log file that can grow considerably. For ease of administration, you should limit the log file either by size or by frequency. For example, choosing the Monthly option creates a new log file every month.

Always restart the IAS server after making any changes. To restart, choose Start > Run. Enter services.msc and click the OK button. Right-click the Internet Authentication Service option and choose Restart.

The Systems section of the Windows Event Viewer provides helpful information for troubleshooting an IAS server. For authentication issues related to a particular user, verify the user's membership.

Note

In the MS Active Directory, the Remote Access Permission option for a new user is, by default, set to Deny access. This setting prevents the user from logging in to a networking device. You must manually change this setting to Allow access. To make this change, right-click the user in the Active Directory User and Computers snap-in and choose Properties. In the Properties window, select the Dial-in tab and choose Allow access in the Remote Access Permission (Dial-in or VPN) section. Click the OK button to save the settings.


The Microsoft IAS RADIUS server is now ready to provide AAA services to Cisco clients.

Configuring a Cisco Router for RADIUS

The steps involved in configuring a Cisco IOS-based routers for RADIUS-based AAA are almost identical to those of TACACS+-based AAA. However, RADIUS-based AAA requires an additional step of defining the UDP ports numbers to be used by the IOS devices to communicate with the RADIUS Server. This step is required to avoid incompatibility issues arising because of differences in the versions of RADIUS. Some RADIUS vendors are using the old UDP ports of 1812 and 1813 for authentication and accounting, respectively, while others are using UDP 1645 and 1646.

The global-configuration-mode command for specifying a RADIUS Server, UDP ports, and the encryption key on an IOS device is as follows:

Router(config)# radius-server host {hostname | ip-address} [auth-port port-number] [acct-port port-number] [timeout seconds] [retransmit retries] [key string] [alias {hostname | ip address}]

Use the auth-port and acct-port options, respectively, to specify the UDP port for authentication and accounting.

Example 3-16 shows the configuration of an IOS device configured as a AAA Client using RADIUS. The RADIUS Server is configured with following parameters:

  • MS IAS RADIUS Server IP address 192.168.0.40

  • Linux FreeRADIUS Server IP address 192.168.0.30

  • Encryption key testing123

  • Authentication port UDP 1812

  • Accounting port UDP 1813

Example 3-16. IOS Device with RADIUS-Based AAA Configuration
 Dallas-Router# show running-config Building configuration... ! version 12.1 hostname Dallas-Router ! aaa new-model authentication login default group radius local enable authorization exec default group radius local none authorization commands 0 default group radius local none authorization commands 1 default group radius local none authorization commands 15 default group radius local none accounting exec default start-stop group radius accounting commands 0 default start-stop group radius accounting commands 1 default start-stop group radius accounting commands 15 default start-stop group radius enable password 7 03075218050070 ! username admin privilege 15 password 0 s3curepassword ! interface Ethernet0  ip address 192.168.0.10 255.255.255.0 ! interface Serial0  ip address 172.16.2.2 255.255.255.252 ! ip classless ip route 0.0.0.0 0.0.0.0 192.168.0.20 !This entry is for using Linux FreeRADIUS server radius-server host 192.168.0.30 auth-port 1812 acct-port 1813 key testing123 ! This entry is for using MS-IAS based RADIUS server radius-server host 192.168.0.40 auth-port 1812 acct-port 1813 key testing123 radius-server retransmit 3 ! line con 0 line vty 0 2  password 7 030752180500 line vty 3 4  password 7 13061E010803 ! end 

Configuring a Cisco Switch for RADIUS

The configuration steps involved in enabling RADIUS on CatOS-based switches are similar to those for TACACS+. However, RADIUS lacks authorization on CatOS. No command exists to enable RADIUS exec authorization. The workaround is to set the Service-Type (RADIUS attribute 6) to Administrative (a value of 6) in the RADIUS Server to place the user in enable mode. If the Service-type is set for anything other than Administrative (for example, 1-login, 7-shell, or 2-framed), the user arrives at the switch exec prompt, not the enable prompt.

Example 3-17 shows the configuration of the switch as a AAA Client using RADIUS.

Example 3-17. Cisco Switch Configuration for RADIUS-Based AAA
 set radius server 192.168.0.30 set radius key testing123 set authentication login radius enable set authentication enable radius enable set accounting exec enable start-stop radius 

Configuring Cisco PIX Firewalls for RADIUS

Just as in IOS and CatOS, the commands used to configure RADIUS-based AAA on PIX Firewalls are similar to those used for TACACS+. However, an additional step is involved, that is, to specify the port numbers used by RADIUS.

Table 3-17 lists the commands involved in configuring RADIUS-based authentication on PIX.

Table 3-17. Configuring RADIUS on PIX

Command

Purpose

aaa-server <tag> protocol tacacs+|radius

Creates a server group on the PIX to use the RADIUS protocol

aaa-server <tag> [<(if_name)>] host <ip_address> [<key>] [timeout <seconds>]

Specifies the IP address and encryption key for the RADIUS Server

aaa authentication serial | telnet | ssh | http | enable console <tag>

Specifies the authentication to be used for console access through serial, Telnet, or SSH

aaa-server radius-authport <auth_port>

Specifies the UDP port used by the RADIUS Server for exchanging authentication packets

aaa-server radius-acctport <acct_port>

Specifies the UDP port used by the RADIUS Server for exchanging accounting packets


Based on these commands, Example 3-18 shows the configuration of the PIX Firewall for authentication. The RADIUS Server details are grouped under the tag MYAAA and are then applied to authenticate access to the firewall console through Telnet and the serial interface.

Example 3-18. Configuring PIX for Authentication
 c:\windows\system32> telnet 192.168.0.20 User Access Verification Password: Type help or '?' for a list of available commands. Firewall-Dallas> enable Password: Dallas-Firewall# conf t Dallas-Firewall(config)# aaa-server MYAAA protocol radius Dallas-Firewall(config)# aaa-server MYAAA (inside) host 192.168.0.30 testing123 Dallas-Firewall(config)# aaa-server radius-authport 1812 Dallas-Firewall(config)# aaa-server radius-acctport 1813 Dallas-Firewall(config)# aaa authentication telnet console MYAAA Dallas-Firewall(config)# aaa authentication ssh console MYAAA Dallas-Firewall(config)# exit 

The PIX Firewall is now ready to be accessed using the username and password defined in the RADIUS Server.

Caution

Unlike the IOS AAA feature set, PIX does not offer local authentication as a fallback feature in the same aaa authentication statement. Hence, it is good administrative practice to configure the serial console of the PIX for local authentication. This avoids denial to the serial console because of problems with the AAA server or misconfigurations. The suggested configuration to enable local authentication on the PIX serial console is as follows:

      username admin password somepassword privilege 15      username helpdesk password someothepassword privilege 1      aaa-server LOCAL protocol local      aaa authentication serial console LOCAL 




Network Administrators Survival Guide
Network Administrators Survival Guide
ISBN: 1587052113
EAN: 2147483647
Year: 2006
Pages: 106

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net