10.1 Typical Services

As you've learned from the chapters on FreeRADIUS, the users that connect through your RADIUS server must be either configured into the users file for the RADIUS server itself or known by a remote system with which the initial RADIUS server can communicate. Anything else falls into the default connection configuration, which is sometimes known as the "catchall." Most implementations have a generic configuration that is meant for most users and a few user-specific configurations sprinkled about. In the following sections, I will provide examples of both scenarios whenever appropriate.

10.1.1 System Shell Accounts

The shell account, a popular service 5 to 10 years ago but less so now, is a unique type of connection that allowed access to the command line of a remote server. Users would dial in to some NAS gear, which would open a channel to the remote "shell server," and it would then prompt the user for authentication information. Assuming he provided proper credentials, the user was authenticated, got a shell prompt on the remote machine, and the NAS acted as the pass through from the client to the server. That's an important distinction, since with shell accounts the user is not provided with a direct IP address for the remote network. Since he doesn't have his own IP, he must talk with a system that does in this scenario.

There are two common types of protocols used to connect to shell accounts on machines: Rlogin and Telnet. Rlogin was more popular, since it was the most configurable of the two, but Telnet is more secure. The RADIUS server, however, must be prepared to support both protocols. An example configuration stanza from the RADIUS users file for shell account access is listed in Example 10-1.

Example 10-1. RADIUS configuration for shell accounts

Jonathan
    Service-Type = Login,
    Login-Service = Telnet,
    Login-IP-Host = 172.16.1.37

Anna
    Service-Type = Login,
    Login-Service = Rlogin,
    Login-IP-Host = 172.16.1.38

Of course, you can default the configuration—meaning all users will use the same configuration, with Rlogin—by using the excerpt shown in Example 10-2.

Example 10-2. Default shell account configuration

DEFAULT
    Service-Type = Login
    Login-Service = Rlogin,
    Login-IP-Host = 172.16.1.38

10.1.2 Direct Connect Accounts

Today, you'll find most ISPs provide direct connect accounts using a framed remote access protocol such as SLIP or PPP. With these accounts, the connecting user is assigned an IP address (or, in the case of static IP addresses, allowed to use an address) on the remote network, so that she may function like an actual node on that network.

SLIP and PPP are both available for these kinds of connections, although usually PPP is used now, since it has many benefits: it is better supported, more robust, and has quite a few link negotiation features that SLIP just doesn't have. Example users file configurations are shown in Example 10-3.

Example 10-3. RADIUS configuration for direct connect accounts

Jonathan    Password = UNIX-PW
    Service-Type = Framed,
    Framed-Protocol = SLIP,
    Framed-IP-Address = 255.255.255.254,
    Framed-IP-Netmask = 255.255.255.0,
    Framed-Routing = None,
    Framed-MTU = 1500,
    Framed-Compression = Van-Jacobson-TCP-Header

Anna    Password = UNIX-PW
    Service-Type = Framed,
    Framed-Protocol = PPP,
    Framed-IP-Address = 255.255.255.254,
    Framed-IP-Netmask = 255.255.255.0,
    Framed-Routing = None,
    Framed-MTU = 1500,
    Framed-Compression = Van-Jacobson-TCP-Header

DEFAULT    Password = UNIX-PW
    Service-Type = Framed,
    Framed-Protocol = PPP,
    Framed-IP-Address = 255.255.255.254,
    Framed-IP-Netmask = 255.255.255.0,
    Framed-Routing = None,
    Framed-MTU = 1500,
    Framed-Compression = Van-Jacobson-TCP-Header

Note that both users are assigned dynamic IP addresses, presumably from a DHCP-compatible device. In fact, the PPP configuration stanza for user Anna and the default configuration specifically request the NAS to assign an IP address (this was covered in Framed-IP-Address attribute section in Chapter 3). But you, as an ISP, may provide a service for static IP usage. Or you, as a corporate IT administrator, may have deployed remote corporate applications that require a client to have a static IP address. In this case, the static IP address desired is simply specified in the Framed-IP-Address attribute in the appropriate section in the users file, as shown in Example 10-4.

Example 10-4. Assigning a static IP address to user Jonathan

Jonathan    Password = UNIX-PW
    Service-Type = Framed,
    Framed-Protocol = PPP,
    Framed-IP-Address = 66.26.224.45,
    Framed-IP-Netmask = 255.255.255.248,
    Framed-Routing = None,
    Framed-MTU = 1500,
    Framed-Compression = Van-Jacobson-TCP-Header

Alternatively, you may have a user who requires access from her corporate laptop with a static IP, but she may also want to dial in from a home computer to access the Internet. In this case, you can set up the appropriate configurations very easily. You simply add the Access-Request's protocol as an item to check in the different stanzas in the users file for the designated user, as shown in Example 10-5.

Example 10-5. Maintaining multiple connection configurations

Anna        Password = UNIX-PW, Framed-Protocol = SLIP
    Service-Type = Framed,
    Framed-IP-Netmask = 255.255.255.0,
    Framed-Routing = None,
    Framed-MTU = 1500,
    Framed-Compression = Van-Jacobson-TCP-Header

Anna        Password = UNIX-PW, Framed-Protocol = PPP
    Service-Type = Framed,
    Framed-IP-Address = 66.26.224.45,
    Framed-IP-Netmask = 255.255.255.248,
    Framed-Routing = None,
    Framed-MTU = 1500,
    Framed-Compression = Van-Jacobson-TCP-Header