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.
A
