Planning RADIUS Proxy Services

You can use RADIUS proxy to outsource the management of dial-in hardware to an Internet Service Provider (ISP) while you manage the users in your eDirectory tree. This benefit provides you with the flexibility to manage dial-in users without the investment in dial-in hardware or the burden of managing the hardware.

Using RADIUS proxy, a remote user (such as jane@acme.com) dials in to an ISP network. The user's access request (user ID and password) is forwarded to a RADIUS proxy server on the ISP network. The ISP RADIUS proxy server forwards the access request to your company's RADIUS server (such as acme.com). The RADIUS server then checks the information in the access request and either accepts or rejects the request. If the RADIUS server accepts the request, it returns configuration information specifying the type of connection service (such as PPP or Telnet) to deliver to the user.

Authentication Services can act as both a conventional RADIUS server and a RADIUS proxy server at the same time. To set up a RADIUS proxy, you must add a domain to the Dial Access System object's domain list. The domain name you assign is the target domain the user must use to be directed to that proxy for authentication. The RADIUS server supports usernames specified as either an eDirectory distinguished name or a common name. For access requests that have a username without a domain, you can configure search domains that can be checked to determine if valid authentication information is available. The search domains consist of configured domains that do not authenticate by eDirectory context. Domains are defined as one of the following types:

Refer to the NetWare Administrator online help for information about specific configuration procedures.

This section contains the following tasks:


Setting Up a RADIUS Authentication Proxy to Authenticate Remote Users by NDS or eDirectory Context to Any RADIUS Server

A user logs in as jane@acme.com. You want this user to authenticate using the local NDs or eDirectory tree and search for the user from the [Root] context of the NDS or eDirectory tree and any context below [Root]. You don't care which RADIUS server handles the authentication. If the user cannot be authenticated in the NDS or eDirectory tree, you want the server to send the authentication request to all the search domains for the Dial Access System object. Configure the Dial Access System object as follows:

Domain Name: acme.com
Domain Type: NDS or eDirectory Context---Any BMAS Server
eDirectory Context Name: [Root]
Look for user in any lookup context under this context: checked
Use search domains if user not found: checked


Setting Up a RADIUS Authentication Proxy to Authenticate Remote Users by NDS or eDirectory Context to a Specific RADIUS Server

A user logs in as jane@sales.acme.com. You want this user to authenticate using the local NDS or eDirectory tree, but you want to search for the user only in the sales.acme context. You also want a specific RADIUS server that is within the same partition of the NDS or eDirectory tree as the sales context to handle the authentication to reduce network latency for the login. The IP address for the RADIUS server is 1.2.3.4 and the secret is 12345678998765432100. You need the accounting to be logged locally on the RADIUS server. Configure the Dial Access System object as follows:

Domain Name: sales.acme.com
Domain Type: eDirectory Context---Specific BMAS Server
eDirectory Context Name: sales.acme
Look for user in this context only: checked
Primary Address: 1.2.3.4 Port: 1645
Secret: 12345678998765432100
Log at proxy server: checked


Setting Up a RADIUS Authentication Proxy as an ISP to Forward Requests to a Corporate RADIUS Server

You manage an ISP. Acme Corporation user joe dials in with the username joe@acme.com, and you need to forward the authentication request to the corporation's RADIUS server at IP address 1.2.3.4, port 1645, with a RADIUS secret of 12345678998765432100. You also need to forward accounting to the Acme corporation RADIUS accounting server at IP address 1.2.4.5, port 1646, with a RADIUS secret of 98765432112345678900 and a retry limit of 24 hours. Configure the Dial Access System object as follows:

Domain Name: acme.com
Domain Type: Generic Proxy
Primary Address: 1.2.4.5 Port: 1645
Secret: 12345678998765432100
Forward to domain: checked
Use alternate addresses/secret: checked
Primary Address: 1.2.4.5 Port: 1646
Secret: 98765432112345678900


Setting Up a RADIUS Authentication Proxy to Forward Requests to a Third-Party Authentication Server Supporting Token Authentication

Your corporation has a Security Dynamics ACE/Server external server that supports token authentication. Your sales force uses this token implementation extensively and you need to preserve your investment in this hardware. You want to use the token authentication capabilities of this server, but would like to manage the users in eDirectory with Novell BorderManager 3.7 Authentication Services. Salesperson Olivia Olsen logs in as Olivia.Sales.Acme. You want to remove the domain name on this login and create a domain, ace, to forward the request to the external authentication server at IP address 1.2.3.4, port 1645, with a RADIUS secret of 09876543211234567890. To implement this example, you must create an External Authentication Service object and an External Identity object.

Configure the External Authentication Service object as follows:

Domain Name: ace
Domain Type: External Authentication Server
Remove domain name: checked
Primary Address: 1.2.3.4
Port: 1645
Secret: 09876543211234567890
Accounting Log at proxy server: checked

Assign the User object to the External Identity Object as follows:

Login Name: Olivia.Sales.Acme
Given Name: Olivia
Last Name: Olsen


Setting Up a RADIUS Authentication Proxy to Forward Requests to Third-Party Authentication Server Supporting Token Authentication with Token Serial Numbers as Usernames

Your implementation is exactly the same as in the previous configuration; however, you want to eliminate the need to manage user accounts on the token server. Instead of using usernames on your external authentication server, you have assigned the serial number of the token as the login name. The serial number and login name for the token used by salesperson Olivia Olsen is 12345. You still want Olivia to log in as Olivia.Sales.Acme. However, you want eDirectory to substitute 12345 as Olivia's other name. To implement this configuration, you must configure the User object Olivia as follows:

Login Name: Olivia.Sales.Acme
Given Name: Olivia
Last Name: Olsen
Other name: 12345@ace

Configure the External Authentication Service object as follows:

Domain Name: ace
Primary Address: 1.2.3.4
Port: 1645
Secret: 09876543211234567890


Setting Up a RADIUS Authentication Proxy to Authenticate Usernames to a Search Domain

Acme Corporation has a legacy RADIUS server. You want to migrate your remote access to Novell BorderManager 3.7 Authentication Services; however, you want to do it gradually, moving one department a month from the legacy system to Novell BorderManager 3.7. You want your users to authenticate to the Novell BorderManager 3.7 RADIUS server and you want this server to search the legacy RADIUS server if the user does not exist in eDirectory.

To allow users to authenticate, you can set up a search domain on the Novell BorderManager 3.7 Authentication Services RADIUS server. The legacy RADIUS server, RAD1, is at IP address 1.2.3.4, port 1645, with a secret of 09876543211234567890. You also want accounting to be logged at the legacy proxy server. Configure the Dial Access System object on the Novell BorderManager 3.7 Authentication Services RADIUS server as follows:

Domain Name: RAD1
Domain Type: Search Domain Server
Primary Address: 1.2.3.4
Port: 1645
Secret: 09876543211234567890
Accounting Log at proxy server: checked



  Previous Page: Setting Up Authentication Policies  Next Page: Managing RADIUS Proxy Services