Novell's BorderManager Authentication Service: Arm Your Network for Remote Users
Articles and Tips:
01 Dec 1998
If you were the network administrator at a small bicycle-accessory manufacturer in Yuma, Arizona, how would you solve the following challenge? The company's president has recently hired an inventor and a research and development firm. Now it's your job to provide both the inventor, who works out of his home in White Plains, New York, and the research and development firm, whose facility is located in Dallas, Texas, with remote access to your company's network.
Because the information exchanged between Yuma, White Plains, and Dallas will be confidential, the remote-access system you create must be secure. In addition, you must be able to expand the remote-access system rapidly and to virtually any size. After all, you do not know how fast the company will grow or how big the company will become once it begins to market new products.
The growing number of companies that have employees who telecommute--whether they work at home, on the road, or at a branch office--has left many network administrators facing this challenge. How do you address the security problems inherent in providing network services to remote users, not to mention the difficulties of managing an extended network? Novell's BorderManager Authentication Service integrates Remote Authentication Dial-In User Service (RADIUS) with Novell Directory Services (NDS) to offer security and other capabilities you need to set up and manage remote access to your company's network.
This article explains how BorderManager Authentication Service integrates RADIUS with NDS to offer an easily managed RADIUS solution that provides authentication, authorization, and accounting services for remote users. This article also explains several additional features of BorderManager Authentication Service--features that make it easy for you to enable remote access for any number of remote users and to manage their user accounts.
WHAT IS RADIUS?
RADIUS is the authentication, authorization, and accounting protocol that Livingston Enterprises Inc. (now Lucent Technologies) developed in collaboration with the Internet Engineering Task Force (IETF). RADIUS supports dial-in user authentication through Point-to-Point Protocol (PPP), Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), UNIX login, and other authentication protocols that implement a username and password.
RADIUS transports authentication, authorization, and configuration information between a network access server and an authentication server, both of which must be RADIUS compliant. A network access server accepts dial-in access from telephone lines via modems or from Integrated Services Digital Network (ISDN) lines via ISDN terminal adapters. (For a list of vendors that supply RADIUS-compliant network access servers, visit the NetWare Connection World-Wide Web site at http://www.nwconnection.com.)
An authentication server, on the other hand, stores a database of usernames, passwords, authorization information, and configuration information. In addition, the authentication server can be the same server that is running the RADIUS protocol--the server that is known as the RADIUS server. (See Figure 1.)
Figure 1: Dial-access network using the RADIUS protocol
When a network access server sends a request to a RADIUS server, the RADIUS server first checks the IP address of the network access server making the request. If this IP address does not belong to one of the network access servers with which the RADIUS server has been configured to communicate, the RADIUS server does not respond to the request.
According to the IETF's Request for Comments (RFC) 2138, if a RADIUS server receives a request from a network access server that is not on the RADIUS server's list of configured network access servers, the RADIUS server should log the access attempt and then silently discard the request. When silently discarding a request, the RADIUS server simply does not respond to the requesting network access server. (To read RFC 2138, go to ftp://ftp.livingston.com/pub/radius/rfc2138.txt.)
Since RFC 2138 recommends, but does not require, RADIUS applications to log unauthorized attempts to access your company's network, not all RADIUS applications perform this function. However, BorderManager Authentication Service does, providing you with information that allows you to identify repeated attempts to gain unauthorized network access.
SECRET, SECRET, WHO'S GOT THE SECRET?
Network access servers and RADIUS servers use a shared secret to protect each user's password and, at the same time, to validate one another's identity. A shared secret is a well-chosen string of alphanumeric characters that becomes the encryption key these servers use to keep a user's password secure as it travels between the servers.
Like a well-chosen password, a well-chosen shared secret should be one that cannot be easily guessed and that is at least eight characters long, depending on the RADIUS server you are using. For example, if you were using a server running BorderManager Authentication Service as your company's RADIUS server, the shared secret you create should be a meaningless string of 20 to 30 alphanumeric characters.
When a user dials in to a network protected by RADIUS, he or she is prompted for a username and password. After obtaining this information (either directly from the user or through this user's dial-in software, depending on the type of connection being established), the network access server creates an access request packet that includes the username and password. Using an encryption method based on MD5, the Rivest-Shamir-Adleman (RSA) message digest algorithm, the network access server then uses the encryption key obtained from the shared secret to encrypt the user's password before sending the access request packet to the RADIUS server. (See Figure 1.)
When the RADIUS server receives the access request packet, this server uses the encryption key generated from the shared secret to decrypt the user's password. The RADIUS server then uses the database stored on the authentication server to authenticate this user. For example, if you were using a server running BorderManager Authentication Service as your company's RADIUS server, this server would compare the username and password against the usernames and passwords stored in your company's NDS database.
If the requesting network access server did not encrypt the user's password using the correct shared secret, the RADIUS server could not use the decrypted password to authenticate the user. In this case, the RADIUS server would prepare an access reject packet and send it to the network access server. In other words, if the requesting network access server did not have the shared secret, the RADIUS server would deny any requests it receives from that network access server. The RADIUS server would also prepare an access reject packet if any of the specified user requirements were not met--for example, if the user mistyped his or her username.
If the user were successfully authenticated, the RADIUS server would send an access accept packet to the network access server. This packet would contain all of the information necessary to deliver the network services the user is authorized to receive.
In addition to protecting your company's network via a shared secret and encrypted passwords, a RADIUS server can be configured to instruct the network access server to "hang up" on a user and call the user back at a specified telephone number. This callback feature is useful if you want to require remote users to access your company's network only from specific locations.
IT'S BETTER WITH BORDERMANAGER AUTHENTICATION SERVICE
The IETF is in the process of establishing RADIUS as an official Internet standard. (See RFC 2138 and 2139. To read RFC 2139, go to ftp://ftp.livingston.com/pub/radius/rfc2139.txt.) However, vendors such as Novell have already made RADIUS the de facto industry standard. RADIUS performs even better when used in conjunction with BorderManager Authentication Service, which gives you flexibility to do the following:
Choose a platform
Choose dial-in software
Expand your company's remote-access system as the number of users grows
Update your company's remote-access system as technologies change
Platform of Choice: NetWare or Windows NT
You can install BorderManager Authentication Service on a server running NetWare 4.11 or above or on a server running Windows NT 4.0 or above. This cross-platform support means you can use NetWare or Windows NT servers running BorderManager Authentication Service together on the same network. You can also substitute a NetWare server for a Windows NT server, and vice versa.
Dial Me Up
BorderManager Authentication Service provides support for a variety of dial-in software. For example, BorderManager Authentication Service works with terminal emulation software, such as Hyper Terminal, and with software that supports PPP, such as the dial-in software included with Windows 95 and Windows NT 4.0. Since BorderManager Authentication Service doesn't require you to implement a particular type of dial-in software, the software you install on a user's workstation depends mainly on the type of RADIUS-compliant network access server that provides the user with remote access to your company's network.
For example, if BorderManager Authentication Service is running on a NetWare 4.11 server and remote users want to access NetWare services, both the network access server and the dial-in software you choose must support IPX. Also, like the network access server on your company's remote-access system, the dial-in software you choose must support authentication by username and password.
Room to Grow With NDS
In addition to allowing you to choose from a variety of dial-in software, BorderManager Authentication Service allows you to add a virtually unlimited number of users to your company's remote-access system. When you install BorderManager Authentication Service, the installation program copies RADIUS server files to one or more of your company's NetWare or Windows NT servers. These servers then become RADIUS servers. The installation program also extends the NDS schema to accommodate dial-in access to your company's network, thus enabling the RADIUS server (or servers) to authenticate remote users through the NDS database.
Since BorderManager Authentication Service is fully integrated with NDS and includes a snap-in module for Novell's NetWare Administrator (NWADMIN) utility, you can assign remote-access privileges--to individual users or to groups of users--through the same database you use to manage your company's network. You can also configure the NDS database to accommodate a virtually unlimited number of remote users.
After you have installed BorderManager Authentication Service, you must create at least one Dial Access System object in the NDS tree to provide dial-in access to your company's network. (You must also define a password for the Dial Access System object. To find out what this password does and how to keep it hidden from users who have access to the RADIUS server console, see "Where Did It Go?".) The Dial Access System object contains the configuration information that RADIUS servers on the network use to return connection information to requesting network access servers.
Whether you have one or more RADIUS servers, you can use the Dial Access System object to manage all of them. This capability allows you to add RADIUS servers to your company's remote-access system without significantly increasing the amount of time it takes to manage that system.
Keeping Up With Changing Technologies
BorderManager Authentication Service also allows you to incorporate new technologies as they become available. Along with the Dial Access System object, Novell recommends that you create a Dial Access Profile object, which allows you to configure a common set of attributes for all remote users, rather than configuring these attributes for each container object or for each User object. Attributes define specific authentication, authorization, and configuration options that are available to remote users.
For example, User-Password is an authentication attribute, Callback is an authorization attribute, and Framed Routing is a connection attribute. If you wanted users to receive PPP service, you would create a Dial Access Profile object and define the Framed value for the Service Type attribute and the PPP value for the Framed Protocol attribute. (For more information about defining attributes, see "Creating a Dial Access Profile Object")
BorderManager Authentication Service uses the attribute dictionary file to store information about a collection of attributes. The attribute dictionary file stores information about all of the generic and vendor-specific RADIUS attributes currently supported by BorderManager Authentication Service.
Generic RADIUS attributes consist of the attributes listed in RFC 2138, including User-Name, User-Password, CHAP-Password, Network Access Server (NAS) IP-Address, Framed Routing, and Framed-IPX-Network. Since many vendors have designed RADIUS-compliant network access servers to enable attributes outside the scope of RFC 2138, BorderManager Authentication Service's attribute dictionary file also stores information about many of these vendor-specific attributes.
BorderManager Authentication Service supports current technologies via the vendor-specific attributes in the attribute dictionary file. Novell plans to make emerging technologies available by extending the attribute dictionary file to include new attributes that vendors offer in future products, as well as attributes that the IETF might add as it extends the RADIUS standard. With BorderManager Authentication Service, you can incorporate emerging technologies by simply downloading the latest attribute dictionary file from Novell's web site and then adding the attributes you want to enable to the Dial Access Profile object. (For more information about how to add attributes to a Dial Access Profile object, see "Creating a Dial Access Profile Object".)
BUT THAT'S NOT ALL
In addition to the features already mentioned, BorderManager Authentication Service offers the following benefits:
The ability to outsource remote access
The ability to assign separate dial-in passwords
Group-based management
Dial access system caching
Accounting and audit logs
Your Place or Mine?
A RADIUS server can act as a proxy RADIUS server for other RADIUS servers. For example, a server running BorderManager Authentication service can act as a proxy RADIUS server or can communicate with other RADIUS servers that are acting as proxy RADIUS servers. As a result, you can outsource remote access by contracting with an Internet Service Provider (ISP) that provides RADIUS proxy services. (To view a list of some ISPs that provide RADIUS proxy services, visit the NetWare Connection web site at http://www.nwconnection.com.)
Outsourcing remote access through an ISP can save you time and money because you do not have to purchase, maintain, and manage costly hardware such as network access servers, modems, ISDN terminals, and routers. For example, suppose that you created a RADIUS server by installing BorderManager Authentication Service on a NetWare 5 server and that you contracted with an ISP to provide remote access to your company's network. In this case, remote users would dial in to a RADIUS-compliant network access server that would be owned and maintained by your ISP. (See Figure 2.)
Figure 2: Dial-access network that uses an ISP to provide RADIUS proxy services
The ISP's network access server would then route a user's request for access to a proxy RADIUS server, which would also be owned and maintained by your ISP. The ISP's proxy RADIUS server would use the encryption key derived from the shared secret to encrypt the user's password before sending the access request packet to your company's RADIUS server.
Upon receiving the access request packet, your company's RADIUS server would decrypt the user's password and authenticate the user through the NDS database. The RADIUS server would then send an access accept packet to the ISP's proxy RADIUS server, which would forward this packet to the ISP's network access server. The network access server, in turn, would establish the connections necessary to provide the user with any network services he or she was authorized to access.
In addition to running BorderManager Authentication Service, you could run other services on the NetWare 5 server, including NDS. In other words, the NetWare 5 server could do double-duty by acting as both a RADIUS server and an authentication server. (Alternately, BorderManager Authentication Service includes a two-user version of NetWare 4.11, so you could dedicate a server to RADIUS authentication without having to purchase additional software for that server.)
May I See a Second ID?
In addition to providing outsourcing capabilities, BorderManager Authentication Service allows you to assign remote users two passwords: one for accessing the network and the other--the NDS password--for accessing network resources. After a server running BorderManager Authentication Service sends an access accept packet to a network access server located on your company's network, the user is granted only the ability to connect to the network. If an ISP provides the network access server the user dials in to, the user can access only the ISP's network. In either case, the user must log in a second time to receive access to the network resources (such as NetWare file and print services) available to her or him through NDS.
When you create a Dial Access System object by using the snap-in module for the NWADMIN utility, you are prompted to choose one of the following password options:
Use Separate Dial-Access Passwords
Use Novell Directory Services Passwords
If you choose the Use Separate Dial-Access Passwords option, you can assign remote users separate, non-NDS passwords to access your company's network. Since all network access servers, RADIUS servers, and proxy RADIUS servers have access to users' clear text passwords, this option provides an extra level of security if an ISP owns the hardware that provides dial-in access to your company's network. In this case, the ISP's network access server and proxy RADIUS server would have clear text access only to non-NDS passwords. The NDS passwords that grant users access to network resources would not be available to these servers.
You should select the Separate Dial-in Passwords option if your company's network access server or your ISP's network access server sends access request packets via CHAP. CHAP servers require the RADIUS server to access the authenticating password in clear text, and NDS passwords are not available in clear text.
If you choose the Use Novell Directory Services Passwords option, remote users can use the same password (their NDS password) for both logins. This option is convenient for remote users because they have to remember only one password.
Join the Group
BorderManager Authentication Service's group-based management feature makes it easier for you to control remote users' access to network resources. With group-based management, you can control remote users' access to network resources such as network access servers, firewalls, and high-speed connections via Dial Access System objects and Group objects, rather than by controlling access on a user-by-user basis.
To use group-based management in BorderManager Authentication Service, you use the snap-in module for the NWADMIN utility to create a separate Dial Access System object for each resource to which you want to control access. You then configure separate RADIUS servers to access each Dial Access System object you created. (Each RADIUS server can access only one Dial Access System object. For more information, see "Where Did It Go?").
You also create a separate Group object for each Dial Access System object, and to each Group object, you assign rights to one of the Dial Access System objects. Finally, you add individual User objects to the Group objects.
For example, suppose you were the network administrator at the bicycle-accessory manufacturer mentioned earlier and you wanted to grant the inventor in White Plains and two of the researchers in Dallas access to a particular firewall. You would first use the NWADMIN utility to create a Dial Access System object (called, for example, FWALL1) for this firewall and to configure a RADIUS server to access that object.
Next, you would create a Group object (called, for example, FWALL1users) that granted access rights to the FWALL1 object. You would then add the inventor and the two researchers to the FWALL1users object.
Just as you can add any number of users to a Group object in general, you can add any number of remote users to a Group object that grants users rights to a Dial Access System object. Conversely, you can add an individual remote user to any number of Group objects that control users access to Dial Access System objects.
For example, suppose you wanted the entire staff of the research and development firm your company hired to have access to a particular set of network access servers on your company's network. You could create a Dial Access System object for that set of network access servers, configure a RADIUS server to access the Dial Access System object, and create a Group object (called, for example, RDSTAFF) with rights to the Dial Access System object. You could then add every member of the research and development staff to the RDSTAFF object, including the two researchers who were previously granted access to the firewall through the FWALL1users object. If the research and development staff grew, you could add the new employees to the RDSTAFF object as well.
Caching In on BorderManagerAuthentication Service
BorderManager Authentication Service's dial-access caching feature allows your company's RADIUS server to access authorization, authentication, and configuration information quickly and easily. The first time a user dials in to your company's network, BorderManager Authentication Service searches the Dial Access System object for the information necessary to authenticate the user and to provide the network services he or she is authorized to receive. BorderManager Authentication Service then stores this information in a dial-access cache.
With dial-access caching, users don't need to wait for BorderManager Authentication Service to search the Dial Access System object for authentication, authorization, and configuration information every time they request access to the network. Instead, BorderManager Authentication Service accesses and delivers this information from cache, which both speeds up remote access to and reduces traffic on your company's network.
In addition, BorderManager Authentication Service checks the Dial Access System object each minute. If this object has been modified, BorderManager Authentication Service updates the authentication, authorization, and configuration information stored in its dial-access cache to reflect the change. As a result, only currently authorized connections and access to network services are available to remote users.
Accounting and Auditing Made Easy
Dial-access caching may facilitate efficient dial-in connections to your company's network, but how do you get information about these connections? To provide you with the connection information you need, BorderManager Authentication Service generates accounting and auditing logs that record this information.
Upon installation, BorderManager Authentication Service automatically enables RADIUS accounting and auditing services. By default, these services are hosted on the same physical server as RADIUS authentication services.
BorderManager Authentication Service's accounting logs, like all RADIUS accounting logs, offer the following information:
Which users are using remote-access services
When users are using remote-access services
How long users are using remote-access services
You can use the information stored in BorderManager Authentication Service's accounting logs to help you troubleshoot problems, perform a statistical analysis, and provide your company's billing department with information about user accounts.
When a RADIUS session begins, the network access server sends an accounting request packet to the RADIUS server. (A session officially begins when the network access server first provides service to the user and officially ends when the service ends.) The accounting request packet contains information such as the user's username and password and the type of service the network access server is delivering to this user. The RADIUS server logs this information in an ASCII text file. The RADIUS server then returns a message to the network access server, acknowledging that the accounting request packet was received.
Similarly, when the session ends, the network access server sends another accounting request packet that contains the user's username and password, the type of service that was delivered to the user, and other information. The RADIUS server logs this information in an ASCII text file and once again sends the network access server a message, acknowledging receipt of the accounting request packet. (If you are running BorderManager Authentication Service on RADIUS proxy servers in your company's remote-access system, you should be aware that an accounting request packet is not forwarded but is recorded on the first RADIUS server that receives this packet.)
By default, RADIUS accounting log files are stored in the comma-delimited format. (To find out how you change the default parameters for RADIUS accounting and auditing services, see "Setting Accounting and Auditing Parameters".) The accounting log files are named YYYYMMDD.DAT.YYYY is the year,MM is the month, and DD is the day the accounting log rollover period begins.
For example, if you set the accounting log rollover period to Monthly, and tomorrow's date were January 1, 1999, the accounting log file that contained information about today's RADIUS sessions would be named 19981201.DAT. In this case, a new accounting log file named 19990101.DAT would be created at midnight, and information about the RADIUS sessions that occurred during the month of January would be recorded in this file. By default, accounting log files are set to roll over on a daily basis, but you can also set these files to roll over at the beginning of each week or at the beginning of each month. (See "Setting Accounting and Auditing Parameters".)
You can import the information stored in accounting log files into database and spreadsheet applications that support comma-delimited files, including Microsoft Excel. (By default, RADIUS accounting log files are located in the SYS:\ETC\RADIUS\ACCT directory if you are running BorderManager Authentication Service on a NetWare server. If you are running BorderManager Authentication Service on a Windows NT server, these files are located in the C:\Novell\BMAS\ACCT directory by default.)
RADIUS auditing log files provide a record of all login attempts, whether successful or unsuccessful. Although auditing log files are typically used for troubleshooting, these files are also a reliable means of identifying the attempts of unauthorized users to access your company's network. In addition, auditing log files provide information for use in accounting systems that are based on remote connection time.
RADIUS auditing log files are named YYYYMMDD.log.YYYY is the year,MM is the month, and DD is the day the auditing log rollover period begins. By default, these files are located in the SYS:\ETC\RADIUS\LOG directory on a NetWare server and in the C:\NOVELL\BMAS\LOG directory on a Windows NT server.
Unlike accounting log files, which you can set to begin at midnight on the first day of each week or each month, auditing log files always begin at midnight on each day. A RADIUS server stores these daily auditing log files for a specified interval and deletes auditing log files that exceed that interval. (Accounting log files are not deleted.)
For example, suppose today were December 17, 1998 and the auditing log interval were set to seven days (as it is by default). When the 19981217.LOG file was created at midnight this morning, the 19981210.LOG file would have been automatically deleted. You can set the rollover interval for RADIUS auditing log files to any number of days. (See "Setting Accounting and Auditing Parameters.")
CONCLUSION
Whether you are adding remote-access services to a multiplatform WAN or to a small LAN, such as the network belonging to our hypothetical bicycle-accessory manufacturer, BorderManager Authentication Service provides more than RADIUS security. Cross-platform capabilities, an extendable attribute dictionary file, group-based management, and dial-access system caching are only a few of the features that make BorderManager Authentication Service's RADIUS solution unique.
With BorderManager Authentication Service, you can manage your company's remote-access system just as you manage the rest of your company's network--through NDS and the NWADMIN utility. You can provide dial-in access to remote users via any network access server that is RADIUS compliant. And in many cases, these users can even access your company's network by using the dial-in software they are most comfortable with.
For more information about BorderManager Authentication Service, visit Novell's web site at http://www.novell.com/bordermanager/bmas. You can also participate in Novell's "Try Before You Buy" program. You can download a trial version of BorderManager Authentication Service from Novell's web site at http://www.novell.com/bordermanager/bmas/tbyb.html.
Cheryl Walton works for Niche Associates, an agency that specializes in writing and editing technical documents. Niche Associates is located in Sandy, Utah.
NetWare Connection, December 1998, pp. 21-30
Where Did It Go?
When you use the NetWare Administrator (NWADMIN) utility to create a Dial Access System object, you must give that object a password. BorderManager Authentication Service uses the password you create to protect the encryption keys that, in turn, protect both remote users' passwords and Remote Authentication Dial-In Service (RADIUS) shared secrets. In addition, RADIUS servers use the Dial Access System password to log in to the Dial Access System object, which allows RADIUS servers to access authentication and connection information through Novell Directory Services (NDS). Like the RADIUS shared secret, the Dial Access System password should be a random string of alphanumeric characters that is from 20 to 30 characters.
BorderManager Authentication Service's RADIUS service functions as a NetWare Loadable Module (NLM). As a result, RADIUS is on the NetWare server, but is not available and active until you load RADIUS. To load BorderManager Authentication Service's RADIUS services on a NetWare 4.11 or above server, type the following command at the server console:
LOAD RADIUS
After you enter this command, you will be prompted to enter the name and the password of the Dial Access System object that the RADIUS server will log in to.
When you install BorderManager Authentication Service, the installation program includes the LOAD RADIUS command in the AUTOEXEC.NCF file so that RADIUS will load automatically each time you reboot the server. Unless you edit the AUTOEXC.NCF file, however, you will be prompted to supply the Dial Access System object name and password each time RADIUS is loaded (as you are when you load the RADIUS services manually). You must add the following lines to the AUTOEXEC.NCF file:
"name=(Dial Access System object name)"" "password=(Dial Access System object password)"
You replace Dial Access System object name and Dial Access System object password with the actual name of your company's object and the actual password.
Although editing the AUTOEXEC.NCF file allows RADIUS to load unattended whenever the server is rebooted, this option also makes the Dial Access System object password available to anyone with access to your server's console. Fortunately, BorderManager Authentication Service allows you to hide the Dial Access System object password. You simply enter the following command at the server console after you load RADIUS the first time.
RADIUS Password SET
The RADIUS Password SET command stores the Dial Access System password in an encrypted form, preventing users who have access to the server console from accessing the Dial Access System password.
If you hide this password, only the name of the Dial Access System object must be specified if RADIUS is loaded. In other words, if the server went down while you were away, RADIUS could be loaded in your absence even if the person rebooting the server were not authorized to know the Dial Access System password.
If you change the Dial Access System password after hiding the previous Dial Access System password, you must either enter a SET command with the new password at the server console, or you must clear the previous password and enter the new password each time RADIUS is loaded. To clear a previously hidden password, type the following command at the server console:
RADIUS Password CLEAR
NetWare Connection, December 1998, p. 26
Creating a Dial Access Profile Object
To create a Dial Access Profile object for BorderManager Authentication Service, you use the NetWare Administrator (NWADMIN) utility to complete the following steps:
Select or create the Organizational Unit (OU) object in which you want the Dial Access Profile object to reside.
Select Create from the Object menu. The New Object dialog box appears.
Select Dial Access Profile, and then click the OK button.
Enter a name for the Dial Access Profile object, and then click the Create button.
Double-click the Dial Access Profile object you just created. The Dial Access Profile dialog box appears.
Select Attributes, and click the Add button.
Double-click either the Generic option or one of the vendors listed below the Vendor Specific option. If you select the Generic option, a list of attributes required by Request For Comments (RFC) 2138 appears. These attributes include User-Name, User-Password, Challenge Handshake Authentication Protocol (CHAP) Password, Network Access Server (NAS) IP-Address, Framed Routing, and Framed-IPX-Network. Click the attributes you want to implement.
To choose vendor-specific attributes, click the vendor that made your company's or your ISP's network access server. A list appears, containing the extended attributes that particular network access server supports. Click the attributes you want to implement. If your company uses more than one type of network access server, you can add other vendors' attributes as well. (You need to create only one Dial Access Profile object, even if your company has several network access servers.)
Select the attributes you want to add from the list, and click the OK button.
When you are finished adding attributes, uncheck the Add Another Attribute box, and click the OK button.
Click the OK button again.
If the vendor of your RADIUS-compliant network access server has extended attributes and that vendor does not appear in the list of extended attributes supported by BorderManager Authentication Service, you can request that Novell make the vendor's attribute extensions available: Simply send an e-mail message to Novell at BMASComments@Novell.com.
You can also use this e-mail address to request that Novell add attributes to the attribute dictionary file. (Note: The RADIUS server does not recognize attributes that your network access server does not support.) Novell plans to update the attribute dictionary file and make these updates available on the Novell Support Connection World-Wide Web site at http://support.novell.com/products/bmas. If you are a BorderManager Authentication Service customer, you may want to check this site periodically.
NetWare Connection, December 1998, p. 28
Setting Accounting and Auditing Parameters
BorderManager Authentication Service allows you to configure its accounting and auditing services. The following is a list of accounting and auditing parameters for BorderManager Authentication Service and the default settings for these parameters:
serverType = [accounting/authentication] (The default setting is both accounting and authentication.)
acctPath = <RADIUS accounting directory> (The default setting is SYS:\ETC\RADIUS\ACCT for NetWare and C:\NOVELL\BMAS\ACCT for Windows NT.)
acctPort = <UDP port for RADIUS accounting> (The default setting is 1646.)
fileFormat = [standard/comma] (The default setting is comma, meaning comma delimited.)
rollOver = [daily/weekly/monthly] (The default setting is daily.)
RADIUS SystemLog [On\Off] (The default setting is On.)
RADIUS SystemLog <file_location> (The default setting is SYS:\ETC\RADIUS\LOG for NetWare and C:\NOVELL\BMAS\LOG for Windows NT.)
RADIUS SystemLogInterval <number_of_days> (The default setting is 7.)
To change these auditing and accounting parameters when BorderManager Authentication Service is running on a NetWare 4.11 or above server, you enter the following commands at the server console:
UNLOAD RADIUS
LOAD RADIUS parameter
For example, if you wanted to set the accounting log file to rollover on a monthly basis, you would unload RADIUS services and enter the following command at the server console:
LOAD RADIUS rollOver = monthly
To change RADIUS accounting parameters for BorderManager Authentication Service on a Windows NT server, you would complete the following steps:
Select Settings from the Start menu on the Windows NT server console.
Select Control Panel, and then double-click Services.
Select BorderManager Authentication Service.
Click Stop, and then click Startup.
In the Log On As field, enter the username you use to authenticate to BorderManager Authentication Service.
Enter your password.
Select Automatic from the Startup Type list.
Enter parameter options in the Startup Parameters field.
After you enter the parameter options, click Start.
NetWare Connection, December 1998, p. 30
* Originally published in Novell Connection Magazine
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.