IAS is a free network service available with Windows
Server 2003 that doesn't come installed by default. An IAS server does
not have to be a member of an AD domain, but if it is, it can be used in
more RADIUS deployment scenarios. If IAS is not a domain member, the
local user database is used for authenticating users. If IAS is a domain
member, AD is used.
In the following example, we
will install IAS on a domain member computer. After installation, the
server is registered in AD. If the server is not registered, it will not
be able to access user information in AD and, therefore, not be able to
authenticate users. As this is the reason that IAS is installed, the
registration process is essential to the operation of IAS. If you want
to use the IAS server to authenticate users from multiple domains, the
server must be given permission to access user information in each
domain. To do so, register IAS in each domain.
1. Installing IAS
To install and register an IAS
server, begin by opening the Add or Remove Programs applet in Control
Panel and click Add/Remove Windows Components. In the components list,
scroll down and select Networking Services. Click the Details button.
Select Internet Authentication Service, click OK, and click Finish. If
prompted, insert the Windows Server 2003 installation
CD-ROM, or browse to the location for installation files. When the
process is complete, click Finish and then close the Add/Remove applet.
Open the Internet
Authentication Service console from the Administrative Tools folder.
Right-click the Internet Authentication Service (see Figure 1) and then click Register Server in Active Directory.
Figure 1. The Internet Authentication Service console
In the Register Internet Authentication Server in Active Directory dialog box (Figure 2), click OK to indicate you want to authorize this computer to read the user's dial-in properties.
Figure 2. You must register IAS server in AD in order to use RADIUS authentication
In the Register Internet Authentication Server in Active Directory dialog box, click OK.
2. Configuring IAS for Remote Access
After you install
IAS, you must configure it before you can use it. This consists of
configuring a connection request policy, configuring access servers
(network access servers sometimes referred to as NAS, or as the RADIUS
clients), configuring logging, and configuring Remote Access policies.
Optional configuration options
An IAS server should
be registered in AD during IAS installation. If not, then it must be
registered after installation by one of the methods given below.
Moreover, if users from domains other than the one that IAS is installed
in will be using the IAS server, then it must be registered in those
domains as well. Several methods may be used to register IAS in AD. To
check to see which IAS servers are registered, open the Properties page
of the RAS and IAS Servers group and select the Member tab. To register
IAS you must be a member of the Domain Admins group in the domain within
which the IAS server is a member.
To register IAS using
the IAS console, right-click on the IAS server and select Register
Server in Active Directory. When the Register Internet Authentication
Service in Active Directory pop up appears, click OK.
You can also register IAS using the netsh command. Open a command prompt and type the following:
netsh RAS add registeredserver
You can also add a
registered server from another domain by extending the command and
adding the DNS domain name and IAS server name as follows:
netsh RAS add registeredserver DNSdomainNAME IASServerNAME
To register IAS using
the Active Directory Users and Computers console, select the Users
folder. In the details pane, right-click the RAS and IAS Servers group
and click Properties. Select the Member tab, and then add the IAS
An IAS member server can be registered in any domain in the forest.
include configuring different or additional RADIUS ports, and configuring account lockout.
Additional configuration may be necessary to support authentication
switches, VLANs, and wireless clients. The process is not complete until
the access servers (RADIUS clients) are configured and any additional
access client account or client software is configured. Access clients
are the end-user computers used to request connections to the remote
2.1. Configuring a connection request policy
Connection request policies
are rules that define whether authentication will take place locally or
remotely. Therefore, they help define whether the IAS server will
become a RADIUS server or a RADIUS proxy. They consist of conditions and a profile, and are similar to Remote Access policies.
Conditions are RADIUS
attributes that are compared to the RADIUS attributes of an incoming
connection request. If multiple conditions exist in the policy, the
attributes of the policy must be matched by all of the incoming
connection request attributes. The conditions and attributes for
connection request policies can also be set in Remote Access policies on
the RADIUS server. They may also be used when configuring RRAS servers
as RADIUS clients. Table 1 defines condition attributes that can be set in IAS.
Table 1. Attributes that can be defined in a connection request policy
|Called Station ID||Phone number of NAS.|
|Calling Station ID||Phone number of caller.|
|Client Friendly Name||Name of the RADIUS client computer requesting authentication. A friendly name
is a name assigned by an administrator during installation. The use of a
friendly name makes it easier to identify which RADIUS client is
attempting a connection and to trace activity in the RADIUS server logs.|
|Client IP address||IP address of the RADIUS client.|
|Client-Vendor||The NAS vendor.|
|Day and Time Restrictions||Day of week and time of day of connection request.|
|Framed Protocol||Type of frame for incoming packets (such as FTP, SLIP, Frame Relay).|
|NAS Identifier||Name of NAS.|
|NAS IP Address||IP address of NAS server.|
|NAS Port type||Media used such as asynch (phone), tunnels, virtual (VPN), Ethernet (switches), and wireless.|
|Remote RADIUS to Windows User Mapping||Authentication
can occur for users of a remote RADIUS server. In other words, partners
authenticate to their own RADIUS and can use one of your user accounts
to access LAN resources.|
|Service Type||Service requested such as framed (PPP) and login (Telnet).|
|Tunnel Type||Tunnel type such as PPTP and L2TP.|
|User Name||Username used by access client in RADIUS message Typically this is a realm (domain) name and user account name.|
are sets of properties that are applied to the incoming connection
request and used by IAS to determine if the client requesting access is
authorized to do so. They include information on Authentication,
Auditing, Attribute Manipulation, and some advanced processes as
explained in Table 10-3. Profile properties and processes are often collectively referred to as profile elements. Table 2
defines profile choices for IAS as a RADIUS server.
Table 2. RADIUS connection request profile elements
|Authentication||Authenticate Requests on this Server||Use the Local user database.|
|Authentication||Forward the request to another RADIUS server in a remote RADIUS server group||This IAS server is acting as a RADIUS proxy.|
|Authentication||Accept the connection attempt without performing authentication or authorization||Used
for some mandatory tunnels. Cannot be selected if MS-CHAP v2 or EAP/TLS
are used for authentication because these authentication protocols
implement mutual authentication. A choice to not require IAS to
authenticate should not prevent the client from requiring it. Therefore,
this option is not available when mutual authentication is required.|
|Accounting||Forward accounting information in a specific remote RADIUS server group||Pass
accounting information from this RADIUS proxy to a RADIUS server.
(Connection request records will always be logged to the RADIUS proxy
and replace this attribute before subjecting the request to
authentication and authorization. User-ID manipulation is changing the
realm (domain name) from the default.|
|Attribute Manipulation||Called Station ID||This
option applies to the Called Station ID, which identifies the RADIUS
side of the connection. Find and replace this attribute before
subjecting the request to authentication and authorization.|
|Attribute Manipulation||Calling Station ID||This
option applies to the Calling Station ID, which identifies the client
side of the connection. Find and replace this attribute before
subjecting the request to authentication and authorization.|
|Advanced||Various RADIUS attributes||Add
attribute value to the RADIUS response message of a RADIUS
authentication or accounting server, or a RADIUS authentication or
accounting proxy server. The value will replace any present in the
The default connection
request policy is set to configure IAS as a RADIUS server, but must be
completed with the specifics of the network on which it operates.
2.2. Configuring RADIUS clients for the IAS server
RADIUS clients are
the access servers to whom the access clients connect. A RADIUS client
can be a RRAS server, a wireless access point or an authenticating
switch. A maximum of 50 RADIUS clients and 2 remote RADIUS server groups
can be configured on an IAS server installed on Windows Server 2003
Standard Edition. If IAS is installed on Windows Server 2003 Enterprise
Edition or Windows Server 2003 Datacenter Edition, an unlimited number
of RADIUS clients and RADIUS server groups can be configured.
Refer to Table 1
for explanations of many of the required parameters when adding an RRAS
server as a RADIUS client. To add an RRAS server as a RADIUS client,
begin by opening the Start → Administrative Tools → Internet
Authentication Service console. Right-click the RADIUS client's node and
click New RADIUS Client. Enter a friendly name (a name that will help
an administrator identify the server) for the RRAS server in the
"Friendly name" box of the Name and Address page. Enter the clients IP
address or DNS name in the "Client address (IP or DNS)" field, as shown
in Figure 3.
Figure 3. Identify the RADIUS client by a friendly name
Click the Verify button
to verify that the server is present on the network. Click Next. If
necessary, use the Client-Vendor drop-down list to select the
manufacturer of the client. In this case, the default is fine because we
are using Windows RRAS servers as clients. Enter a shared secret and
then enter it again to confirm. The shared secret must match the one
entered in the configuration of the RRAS server. Check the box "Request
must contain the Message Authenticator attribute," as shown in Figure 4. Then click Finish.
Figure 4. Adding the use of the Message Authenticator improved the security offered by using a shared secret
2.3. Configuring RRAS servers as RADIUS clients
Before IAS server can be
used to authenticate remote access requests, RRAS servers (or other
access servers) must be configured to use RADIUS for authentication and
To configure a Windows
Server 2003 server to be a RADIUS client, begin by opening Routing and
Remote Access. Right-click the server and select Properties. Select the
Security tab. Change the "Authentication provider" to RADIUS
Authentication by using the drop-down list. Change the "Accounting
provider" to RADIUS Accounting by using the drop-down list, as shown in Figure 5.
Figure 5. Change the authentication and accounting provider to RADIUS
Click the Configure button
next to the "Authentication provider" drop-down list. Click the Add
button to add information on the RADIUS server. Enter the server name of
the RADIUS server and select the "Always use message authenticator," as
shown in Figure 10-8,
and then click OK. The Time-out (seconds) and Initial score entries
should be left to defaults until the operation of the server as a RADIUS
client is tested. If connections time out, then this value may be
Click the Configure button next to the "Accounting provider" field in the Security tab of the Properties window (see Figure 5).
Click the Add button to add information on the RADIUS server. Enter the
server name of the RADIUS server, then select the "Send RADIUS
Accounting On and Accounting Off messages," as shown in Figure 7. Click OK twice to return to the Properties page.
If you need to allow a
shared secret IPSec policy for communications between RADIUS and RRAS
servers, select "Allow custom IPSec Policy for L2TP connection" (see Figure 5). Click OK to exit the Properties page.
Figure 6. Add a RADIUS server
Figure 7. Configure the RADIUS server for accounting
servers are often implemented for redundancy. Rather than allowing a
single RADIUS server to become a single point of failure, two RADIUS
servers are provided, and each RRAS server is configured with
information on both of them. The initial score parameter of the Add
RADIUS Server configuration window identifies which RADIUS server is the
primary server. The RRAS server will attempt a connection with the
primary RADIUS server (the one configured with the lower "Initial
score"). If a connection attempt times out, the RADIUS server will
attempt a connection with the RADIUS server with the next-lowest
"Initial score." This is why the "Time-out (seconds)" parameter should
be carefully considered before it is changed. If set too low,
connections may needlessly time out, forcing the RRAS server to attempt
to connect to the secondary RADIUS server. If the time-out is set too
high and the RADIUS server becomes unavailable, unnecessary time is
wasted before the RRAS server attempts to connect to the secondary
2.4. Configuring auditing and logging
By default, minimal IAS data is logged in IAS log format to a log file at %windir%\System32\Log Files. Only authentication information is recorded, and a new log is started monthly (as shown in Figure 78).
As a best practice, you should put log files on a different drive than
the system drive. Log file data can also be forwarded to a remote server
by using a UNC format log file path.
Figure 8. The log files should be configured to reflect the needs of your organization
It is imperative that
logging be configured so that information on each connection attempt
(whether successful or denied) is recorded. The purpose of IAS is to
protect information assets by only allowing authenticated and authorized
access to the network. To ensure that it's doing its job, IAS must be
configured to log connection information. That information must be
reviewed on a regular basis. Reviewing the logs can uncover attacks
(both successful and unsuccessful). Finding this information may help to
thwart an in-progress attack, identify sources of attacks, and provide
evidence useful in closing security holes or in prosecuting attackers.
The frequency of log review will depend on the sensitivity of the
information IAS protects and the resources available for the reviewing.
The following list shows other reasons for collecting and analyzing IAS log information:
Both connection and session state information are logged.
When IAS is used
to manage customer access to the network, or where departmental use of
resources must be accounted for, IAS data provides the records necessary
to determine usage.
Knowing who has
connected and when they connected can be an important part of usage
reporting as well as key information in a security investigation.
2.4.1. Log format and creation
Log data is not
consistent. That is, the data recorded depends on the data collected by
the type of access server or NAS acting as the RADIUS client, rather
than some strict IAS-determined list of characteristics. Log data for
IAS is recorded in one of the following:
Logging to SQL Server is a new feature in Windows Server 2003.
Table 3 provides information on log file formats and their locations.
Table 3. IAS log location and file format
| ||IAS format||Database-compatible||SQL server logging||Event log|
|Location of file||Local||Local||SQL server computer||Local Application Event Log|
|File format||Text||Text||Records sent to SQL Server XML compliant database||Windows Event Log|
configuring SQL logging, the SQL Server database, stored procedures and
related applications must be installed and configured.
To configure local
text file logging for IAS, begin by opening the IAS console. Select the
Remote Access Logging node. In the details pane, right-click Local File
and then click Properties. Select the Log File tab, as shown in Figure 7. In the Directory box, enter the filename and path for storing the local log file.
To change the file
format from the IAS log default, select "Database-compatible" in the
Format box. In the "Create a new log file" section, schedule the opening
of new log files by clicking Daily, Weekly, or Monthly. To keep all
data in one log file, click "Never (unlimited file size)." To limit log
file size, click "When log file reaches this size" and then enter a file
size in the field next to the option. To delete old log files
automatically, click "When disk is full delete old log files." If the
file is the current file, it will not be deleted.
To provide adequate
log file storage and to prevent disk-full issues that might interfere
with system operation, place the log file on a separate disk. Select the
Settings tab, as shown in Figure 9. Table 4 provides information on these settings.
Figure 9. To log additional items, modify the Settings page
Table 4. RADIUS log file property settings
|Accounting requests||Accounting requests and responses|
|Authentication requests||Access-Accept and Access-Reject messages|
|Periodic status||Status updates such as interim accounting packets|
In addition to
IAS-specific log files, information is recorded in the Windows
Application Event log. To maximize the information recorded to the event
log, begin by opening the IAS console. Right-click on the service and
select Properties. Select the General tab, as shown in Figure 10.
Figure 10. Maximize event log information on authentication.
Enter a "Server
description" that will aid you in identifying the server in the log
entries. In this case, there is only one IAS server so we are simply
identifying it as IAS. If multiple IAS servers are active, then a more
descriptive entry should be used. Select "Rejected authentication
requests" and "Successful authentication requests." Click OK.
2.4.2. Log contents
The log files contain extensive data about connections. Table 10-6 identifies logged items.
Table 5. IAS log data
|Accounting-on request||Access server||The access server is online and ready to accept connections.|
|Accounting-off request||Access server||The access server is going offline.|
|Accounting-start request||Access server||An authenticated user session is starting.|
|Accounting-stop request||Access server||The user session has ended.|
|Accounting Interim requests||Some access servers||Sent
during a user session when the Acct-Interim Interval RADIUS attribute
is configured on the IAS server. If an access server supports this
feature, it will send data for logging; if not, no data is sent. |
|Authentication requests||Access server||Sent on behalf of the user attempting to connect to the network.|
|Authentication accepts (Access-Accept message)||IAS||The connection is accepted.|
|Authentication rejects (Access Reject)||IAS||The connection is denied.|
2.4.3. SQL server logging
Ordinary IAS text logs
can be used for analysis and reporting. Logging to SQL Server provides
the advantages of maintaining data on a non-IAS computer, using a
relational database, and the capability of providing customized
applications for log analysis. Logging to a modern relational database
provides the following:
Large amounts of data can be stored; terabytes of data can be efficiently managed and used.
Relationships between data tables enable flexible creation of dynamic data views.
backup can be written in parallel to multiple backup devices. You can
also use differential backups, which are backups that only record the
data changed after the last backup. Both features allow fast backup,
which is especially important for large databases.
IAS servers can log to the same database for centralized management and
reporting, as well as a more comprehensive view.
SQL Server logging can provide failover and redundancy.
SQL Server logging
can be configured to log to the Microsoft SQL Server Desktop Engine
(MSDE 2000) or to SQL Server 2000. Data is passed to the database in XML
format to a stored procedure (a collection of stored Transact SQL
statements compiled into a single executable program). The stored
procedure is developed by your SQL Server staff and must be called report_event.
To determine the
data fields that must be created in the database tables, you must
understand both the nature of the data collected by the different
devices that you use as RADIUS clients and also the minimum requirements
of IAS server logging. A Microsoft document, Deploying SQL Server Logging with Windows Server 2003 Internet Authentication Service (IAS), is available from http://www.microsoft.com/downloads/details.aspx?familyid=6e4357f7-4070-4902-95f1-3ad411d963b2&displaylang=en.
This is a good place to prepare for development efforts. Setting up the
SQL Server logging process requires configuration of IAS, development
of a SQL Server database, creation of the report_event
stored procedure, and creation of applications that can be used to
query the database and create reports, trouble tickets, and so forth.
Only an experienced SQL database programmer or administrator should
attempt setting up SQL Server logging for IAS.
2.5. Configuring Remote Access policies
Remote Access policies can be configured on RRAS servers
or IAS servers to control remote access authorization and communication
configuration. When an IAS server is used for centralization of
authentication, authorization, and accounting, any Remote Access
policies configured on the RRAS servers identified as the IAS server's
RADIUS clients will not be used. In addition, new remote access
conditions and profile options are available for configuration. These
elements, as well as those defined for both RRAS and RADIUS Remote
Access policies, are passed as RADIUS attributes in the RADIUS messages
between RADIUS servers and clients.
2.6. Configuring additional ports
By default, IAS uses ports
1812 and 1645 for authentication, and ports 1813 and 1646 for
accounting. To configure additional ports, begin by opening the IAS
console. Right-click on the service and select Properties. Select the
Ports tab, as shown in Figure 11. Add, and/or remove ports and then click OK.
Figure 11. Standard RADIUS ports are preconfigured, but can be changed
2.7. Configuring account lockout
You can lock a user account after a number of failed attempts by using account lockout
for IAS client connections. This is not the same as account lockout as
specified for user accounts in the domain GPO. Account lockout for
remote access connections must be configured in the registry of the IAS
server, (If RRAS is not configured as a RADIUS client, you configure
account lockout in the registry of the RRAS server.) Values are
configured under the following key:
By default, the MaxDenials value is set to 0, meaning account lockout is disabled. To enable account lockout, set the value to 1
(or greater) to indicate the maximum number of failed attempts before
an account is locked out. The "ResetTime (mins)" value should be set to
the number of minutes before the account will automatically be
If a user account is locked out, the account name will be added as a subkey to the AccountLockout key in the format domainname:username. If the account is automatically reset, the subkey will be deleted. To manually reset the user account, delete the subkey.
Now that you are
familiar with the RADIUS protocol, how to install IAS, and how to
configure IAS, let's take a look at how to configure IAS as a RADIUS