Internet Authentication Service

Internet Authentication Service (IAS) in XOX; XOX; and XOX is the Microsoft implementation of a Remote Authentication Dial-in User Service (RADIUS) server and proxy. As a RADIUS server, IAS performs centralized connection authentication, authorization, and accounting for many types of network access including wireless, authenticating switch, and remote access dial-up and virtual private network (VPN) connections. As a RADIUS proxy, IAS forwards authentication and accounting messages to other RADIUS servers. RADIUS is an Internet Engineering Task Force (IETF) standard. For more detailed information, see Features of IAS.

  • Before installing an IAS server, see Checklists.
  • For tips about using IAS, see Best practices.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.

Notes

  • XOX
  • XOX


Checklists

  • Checklist: Configuring IAS for dial-up and VPN access
  • Checklist: Configuring IAS to outsource dial-up access
  • Checklist: Configuring IAS to forward requests
  • Checklists: Configuring IAS for wireless access
  • Checklists: Configuring IAS for authenticated switch access

Note

  • XOX


Checklist: Configuring IAS for dial-up and VPN access

Step | Reference
Review RADIUS and IAS concepts. | IAS overview; Understanding IAS
Review IAS implementation best practices. | Best practices
Review IAS security issues. | Security information for IAS
Install IAS on the servers to be used as IAS servers. (One server is configured first, and then the configuration is copied to the other server or servers.) | To install IAS
Configure the properties of one IAS server, including the ports used and event log settings. | Configure IAS properties
Add the access servers (the dial-up network access servers and VPN servers) as clients on the same IAS server. | Configure RADIUS clients
Set up the remote access policies that reflect your dial-up and VPN connection requirements on the same IAS server. | Introduction to remote access policies; Configure remote access policies
Configure logging methods for user authentication and accounting requests. Configure logging for user authentication and accounting
Copy the IAS configuration from the first IAS server to additional IAS servers. | To copy the IAS configuration to another server
Register the IAS servers in the appropriate Active Directory domains. | To enable the IAS server to read user accounts in Active Directory
Verify the configuration of RADIUS accounting and authentication on the access servers, ensuring that IAS is configured on all access servers as the authentication and accounting provider. IAS as a RADIUS server design considerations; To use RADIUS authentication; To use RADIUS accounting;
Remote access;
Manufacturer's documentation
Verify that the access servers are properly configured for dial-up and VPN connections. Routing and Remote Access;
Manufacturer's documentation

Notes

  • For more information about how to deploy IAS with Routing and Remote Access, see Dial-up and VPN remote access.
  • XOX


Checklist: Configuring IAS to outsource dial-up access

Step | Reference
Review RADIUS and IAS concepts. | IAS overview; Understanding IAS
Review IAS implementation best practices. | Best practices
Review IAS security issues. | Security information for IAS
Configure the firewall to support the IAS servers in the perimeter network. | IAS and firewalls
Install IAS on the servers to be used as primary and backup IAS servers. | To install IAS
Add the Internet service provider (ISP) RADIUS proxies and the VPN servers as clients on the primary IAS server. Configure RADIUS clients;
Contact the Internet service provider (ISP)
Configure the remote access policies that reflect your dial-up and VPN connection requirements on the primary IAS server. | Introduction to remote access policies; Configure remote access policies
Configure logging methods for user authentication and accounting requests. | Configure logging for user authentication and accounting
Copy the IAS configuration from the primary IAS server to the backup and remote IAS servers. | To copy the IAS configuration to another server
Register the primary and backup IAS servers in the appropriate Active Directory domains. | To enable the IAS server to read user accounts in Active Directory
Verify the configuration of RADIUS accounting and authentication on the VPN servers. Ensure that IAS is configured on all VPN servers as the authentication and accounting provider. IAS as a RADIUS server design considerations; To use RADIUS authentication; To use RADIUS accounting;
Remote access;
Manufacturer's documentation
Verify that the VPN servers are correctly configured for VPN connections. Virtual private networks;
Routing and Remote Access;
Manufacturer's documentation
Verify the configuration of the RADIUS proxies at the ISP. | Contact the ISP
Verify that Connection Manager service profiles have been configured to support access to the corporate network, and that they work correctly (with Connection Point Services support, as required). | Connection Manager Administration Kit

Notes

  • For information about how to deploy IAS with outsourced dial-up access, see Outsourced VPN remote access.
  • XOX


Checklist: Configuring IAS to forward requests

Step | Reference
Review RADIUS and IAS concepts. | IAS overview; Understanding IAS
Review IAS implementation best practices. | Best practices
Review IAS security issues. | Security information for IAS
Install IAS on the computer that will be used as the IAS proxy server. | To install IAS
Configure the properties of the IAS proxy server, including the ports used and event log settings. | Configure IAS properties
Add the RADIUS clients on the IAS proxy server. Configure the shared secret that is common to both the IAS proxy server and the RADIUS client (from which requests are received). | To add RADIUS clients
On the IAS proxy server, use the New Remote RADIUS Server Group Wizard to create a remote server group with one or more RADIUS servers to which RADIUS messages are forwarded. Configure RADIUS ports and shared secrets that are common to both the IAS proxy server and the RADIUS servers (to which requests are forwarded). | To add a remote RADIUS server group
On the IAS proxy server, use the New Connection Request Policy Wizard to create a connection request policy to forward connection requests and accounting information to the remote RADIUS server group. | To add a connection request policy
Configure logging methods for user authentication and accounting requests. Configure logging for user authentication and accounting
Optional. Copy the IAS proxy configuration from the IAS proxy server to additional IAS proxy servers. | To copy the IAS configuration to another server
Register the IAS proxy servers in the appropriate Active Directory domains. | To enable the IAS server to read user accounts in Active Directory
Verify the configuration of RADIUS accounting and authentication on the RADIUS clients. IAS as a RADIUS server design considerations; To use RADIUS authentication; To use RADIUS accounting;
Remote access;
Manufacturer's documentation
Configure the IAS servers as RADIUS clients on the RADIUS servers (to which requests are forwarded). To add RADIUS clients;
Manufacturer's documentation

Note

  • XOX


Checklists: Configuring IAS for wireless access

You can use the following checklists to configure both the IAS server and wireless access points, and to install user certificates on wireless clients.

  • Checklist: Configuring the IAS server and wireless access points for wireless access
  • Checklist: Installing a user certificate on a wireless client over a wireless connection
  • Checklist: Installing a user certificate on a wireless client over an unauthenticated Ethernet connection
  • Checklist: Installing a user certificate from floppy disk on a wireless client

Note

  • XOX


Checklist: Configuring the IAS server and wireless access points for wireless access

Step | Reference
Review RADIUS and IAS concepts. | IAS overview; Understanding IAS
Review IAS implementation best practices. | Best practices
Review IAS security issues. | Security information for IAS
If you are using certificates to authenticate wireless clients, install a computer certificate on the IAS server computers. | Computer certificates for certificate-based authentication
Install IAS on the servers to be used as primary and backup IAS servers. | To install IAS
Configure the properties of the primary IAS server, including the ports used and event log settings. | Configure IAS properties
Configure logging methods for user authentication and accounting requests. | Configure logging for user authentication and accounting
Add the wireless access points as RADIUS clients on the primary IAS server. | To add RADIUS clients
Use the New Remote Access Policy Wizard to create a common policy for wireless access. | To add a remote access policy
If you are using secure password authentication through Protected Extensible Authentication Protocol (PEAP), also called PEAP-EAP-MS-CHAP v2, configure authentication methods for the remote access policy. | To configure PEAP and EAP methods; PEAP
If you want client and server certificate authentication using Protected Extensible Authentication Protocol (PEAP), also called PEAP-EAP-TLS, configure authentication methods for the remote access policy. | To configure PEAP and EAP methods; PEAP
If you want client and server certificate authentication using PEAP-EAP-TLS, install a certificate on the wireless client from floppy disk, or deploy smart cards. | Checklist: Installing a user certificate from floppy disk on a wireless client; Checklist: Deploying smart cards for logging on to Windows; PEAP; Network access authentication and certificates
If you are using certificate authentication with EAP-TLS and initially installing a user certificate on your wireless clients over a wireless connection, enable guest authentication. | Guest authentication
If you are using certificate authentication with EAP-TLS and initially installing a user certificate on your wireless clients over a wireless connection, create a group named Guests and add the Guest account as a member. | To create a new group; To add a member to a group
If you are using certificate authentication with EAP-TLS and initially installing a user certificate on your wireless clients over a wireless connection, use the New Remote Access Policy Wizard to create a custom policy for new wireless clients (clients that do not have user certificates). Set the NAS-Port-Type condition to Wireless-IEEE 802.11 and Wireless-Other, and the Windows-Groups condition to Guests. On the Dial-in Constraints tab of the profile, restrict the maximum session time to 10 minutes. On the Advanced tab of the profile, add the Tunnel-Type attribute with the value of Virtual LANs (VLAN), and then add the Tunnel-Pvt-Group-ID attribute with the VLAN ID value that corresponds to guest wireless clients. | To add a remote access policy
Copy the IAS configuration from the primary IAS server to the backup IAS server. | To copy the IAS configuration to another server
Register the primary and backup IAS servers in the appropriate Active Directory domains. | To enable the IAS server to read user accounts in Active Directory
Verify the configuration of the wireless access points. Ensure that the RADIUS servers used for authentication and accounting for the wireless access point are the IAS server computers. | Manufacturer's documentation
Optional. Install a user certificate on wireless clients over a wireless connection. | Checklist: Installing a user certificate on a wireless client over a wireless connection
Optional. Install user certificates on wireless clients over an unauthenticated Ethernet connection. | Checklist: Installing a user certificate on a wireless client over an unauthenticated Ethernet connection
Optional. Install user certificates from floppy disk on wireless clients. | Checklist: Installing a user certificate from floppy disk on a wireless client

For more information, see Wireless access and Outsourced wireless access.

Note

  • XOX


Checklist: Installing a user certificate on a wireless client over a wireless connection

Step | Reference
Configure the IAS server and wireless access points for wireless access. | Checklist: Configuring the IAS server and wireless access points for wireless access
Configure the network connection that corresponds to your wireless network adapter for EAP-TLS authentication. | Right-click the network connection, and then click Properties. Click the Authentication tab. Select Smart Card or other Certificate as the Extensible Authentication Protocol (EAP) type. Click Properties, and then click Use a certificate on this computer. Click OK three times to save changes to the network connection.
Move your wireless client computer within range of the configured wireless access point. |
After your wireless client computer has guest access, join the domain. | To join a domain
Restart the computer when prompted and log on to the domain. You will still have a guest connection. |
Install a user certificate on the wireless client computer. | To request a certificate; To submit a user certificate request via the Web
After 10 minutes, your wireless client computer is disconnected because of the dial-in constraint in the new wireless client remote access policy that has been configured on the IAS server. When the wireless client computer reconnects, it will authenticate with the new user certificate and receive an authenticated connection to the wireless access point. |

Note

  • XOX


Checklist: Installing a user certificate on a wireless client over an unauthenticated Ethernet connection

Step | Reference
Configure the IAS server and wireless access points for wireless access. | Checklist: Configuring the IAS server and wireless access points for wireless access
Connect your wireless client computer to the organization network using an unauthenticated Ethernet connection. |
Join the domain. | To join a domain
Restart the computer when prompted and log on to the domain. |
Install a user certificate on the wireless client computer. | To request a certificate; To submit a user certificate request via the Web
Configure the network connection that corresponds to your wireless network adapter for EAP-TLS authentication. | Right-click the network connection, and then click Properties. Click the Authentication tab. Select Smart Card or other Certificate as the Extensible Authentication Protocol (EAP) type. Click Properties, and then click Use a certificate on this computer. Click OK three times to save changes to the network connection.
Move your wireless client computer within range of the configured wireless access point. |
When the wireless client computer connects, it will authenticate with the new user certificate and receive an authenticated connection to the wireless access point. |

Note

  • XOX


Checklist: Installing a user certificate from floppy disk on a wireless client

Step | Reference
Configure the IAS server and wireless access points for wireless access. | Checklist: Configuring the IAS server and wireless access points for wireless access
Submit a user certificate request using the CA Web enrollment tool and save the certificate to floppy disk. | To save a certificate to floppy disk, submit an advanced certificate request by using the CA Web enrollment tool. You can connect to the CA Web enrollment tool at http://ServerName/certsrv, where ServerName is the name of the Web server at which the certification authority you want to access is located. Click Advanced certificate request, and then click Create and submit a request to this CA. On the Advanced Certificate Request page, select Export keys to file, and then type a path statement (including file name) in Full path statement. In Additional Options, select the PKCS 10 format, and then click Submit. When prompted, type a password and password confirmation in Create Private Key Password, and then click OK. In Certificate Issued, select DER encoded and Download certificate chain. When prompted, save the file in a selected location. For more information, see To submit an advanced certificate request via the Web to a Windows Server 2003 CA.
Import the user certificate into the certificate store of the computer for which you want to use the certificate. | Insert the floppy disk that contains the user certificate into the floppy drive and run the Certificate Import Wizard. For more information, see To import a certificate.

Note

  • XOX


Checklists: Configuring IAS for authenticated switch access

You can use the following checklists to configure both the IAS server and Ethernet switch clients, and to install user certificates on Ethernet clients.

  • Checklist: Configuring the IAS server for authenticated switch access
  • Checklist: Configuring a first-time Ethernet switch client for authenticated access
  • Checklist: Installing a computer certificate on an Ethernet client over an unauthenticated Ethernet connection
  • Checklist: Installing a user certificate from floppy disk on an Ethernet client

Note

  • XOX


Checklist: Configuring the IAS server for authenticated switch access

Step | Reference
Review RADIUS and IAS concepts. | IAS overview; Understanding IAS
Review IAS implementation best practices. | Best practices
Review IAS security issues. | Security information for IAS
If you are using certificates for authentication, install a computer certificate on IAS server computers. | Computer certificates for certificate-based authentication
Install IAS on the servers to be used as primary and backup IAS servers. | To install IAS
Configure the properties of the primary IAS server, including the ports used and event log settings. | Configure IAS properties
Configure logging methods for user authentication and accounting requests. | Configure logging for user authentication and accounting
Add the Ethernet switches as RADIUS clients on the primary IAS server. | To add RADIUS clients
Use the New Remote Access Policy Wizard to create a common policy for Ethernet access. | To add a remote access policy
If you are using certificate authentication and initially installing computer certificates on your Ethernet clients over an authenticated Ethernet connection, enable guest authentication. | Guest authentication
If you are using certificate authentication and initially installing a computer certificate on your Ethernet clients over an authenticated Ethernet connection, create a group named Guests and add the Guest account as a member. | To create a new group; To add a member to a group
If you are using certificate authentication and initially installing computer certificates on your Ethernet clients over an authenticated Ethernet connection, use the New Remote Access Policy Wizard to create a custom policy for new Ethernet switch clients (clients that do not have computer certificates that are used in the authentication process). Set the NAS-Port-Type condition to Ethernet and the Windows-Groups condition to Guests. On the Dial-in Constraints tab of the profile, restrict the maximum session time to 10 minutes. On the Advanced tab of the profile, add the Tunnel-Type attribute with the value of Virtual LANs (VLAN), and then add the Tunnel-Pvt-Group-ID attribute with the VLAN ID value that corresponds to guest Ethernet clients. | To add a remote access policy
Copy the IAS configuration from the primary IAS server to the backup IAS server. | To copy the IAS configuration to another server
Register the primary and backup IAS servers in the appropriate Active Directory domains. | To enable the IAS server to read user accounts in Active Directory
Verify the configuration of the Ethernet switches. Ensure that the RADIUS servers used for the Ethernet switch authentication and accounting are the IAS server computers. | Manufacturer's documentation
Optional. Configure first-time Ethernet switch clients for authenticated access. | Checklist: Configuring a first-time Ethernet switch client for authenticated access
Optional. Install a computer certificate on Ethernet clients over an unauthenticated Ethernet connection. | Checklist: Installing a computer certificate on an Ethernet client over an unauthenticated Ethernet connection
Optional. Install user certificates from floppy disk on Ethernet clients. | Checklist: Installing a user certificate from floppy disk on an Ethernet client

Note

  • XOX


Checklist: Configuring a first-time Ethernet switch client for authenticated access

This checklist applies only to Ethernet client computers that use EAP-TLS authentication.

Step | Reference
Configure the IAS server for authenticated switch access. | Checklist: Configuring the IAS server for authenticated switch access
Configure the network connection that corresponds to your Ethernet network adapter for EAP-TLS authentication. | Right-click the network connection, and then click Properties. Click the Authentication tab, and then select Smart Card or other Certificate as the Extensible Authentication Protocol (EAP) type. Click Properties, and then click Use a certificate on this computer. Click OK three times to save changes to the network connection.
Connect your Ethernet client computer to the Ethernet switch. |
After your Ethernet client computer has unauthenticated access, join the domain. | To join a domain
Restart the computer when prompted and log on to the domain. Although you will still have a guest connection, the Ethernet client computer is issued a computer certificate during the startup and domain logon process. |
After 10 minutes, your Ethernet client computer is disconnected because of the dial-in constraint in the first-time Ethernet client remote access policy that has been configured on the IAS server. When the Ethernet client computer reconnects, it will authenticate with the new computer certificate and receive an authenticated connection to the Ethernet switch. |

Note

  • XOX


Checklist: Installing a computer certificate on an Ethernet client over an unauthenticated Ethernet connection

This checklist applies only to Ethernet client computers that use EAP-TLS authentication.

Step | Reference
Configure the IAS server for authenticated switch access. | Checklist: Configuring the IAS server for authenticated switch access
Connect your Ethernet client computer to the organization network with an unauthenticated Ethernet connection. |
Join the domain. | To join a domain
Restart the computer when prompted and log on to the domain. |
Install a user certificate on the Ethernet client computer. | To request a certificate; To submit a user certificate request via the Web
Configure the network connection that corresponds to your Ethernet network adapter for EAP-TLS authentication. | Right-click the network connection, and then click Properties. Click the Authentication tab. Select Smart Card or other Certificate as the Extensible Authentication Protocol (EAP) type. Click Properties, and then click Use a certificate on this computer. Click OK three times to save changes to the network connection.
Connect your Ethernet client computer to the organization network by using an authenticated Ethernet connection. |
When the Ethernet client computer connects, it will authenticate with the new user certificate and receive an authenticated connection to the network. |

Note

  • XOX


Checklist: Installing a user certificate from floppy disk on an Ethernet client

This checklist applies only to Ethernet client computers that use EAP-TLS authentication.

Step | Reference
Configure the IAS server for authenticated switch access. | Checklist: Configuring the IAS server for authenticated switch access
Submit a user certificate request using the CA Web enrollment tool and save the certificate to floppy disk. | To save a certificate to floppy disk, submit an advanced certificate request by using the CA Web enrollment tool. You can connect to the CA Web enrollment tool at http://ServerName/certsrv, where ServerName is the name of the Web server at which the certification authority you want to access is located. Click Advanced certificate request, and then click Create and submit a request to this CA. On the Advanced Certificate Request page, select Export keys to file, and then type a path statement (including file name) in Full path statement. In Additional Options, select the PKCS 10 format, and then click Submit. When prompted, type a password and password confirmation in Create Private Key Password, and then click OK. In Certificate Issued, select DER encoded and Download certificate chain. When prompted, choose to save the file, and then select a location for it. For more information, see To submit an advanced certificate request via the Web to a Windows Server 2003, Standard Edition CA.
Import the user certificate into the certificate store of the computer for which you want to use the certificate. | Insert the floppy disk that contains the user certificate into the floppy drive and run the Certificate Import Wizard. For more information, see To import a certificate.

Note

  • XOX


Best practices

This topic provides best practices for implementing and configuring IAS and is based on recommendations from Microsoft Product Support Services.

Installation suggestions

Before installing IAS, do the following:

  • Install and test each of your access servers using local authentication methods before making them RADIUS clients.
  • After you install and configure IAS, save the configuration by using the netsh aaaa show config > path\file.txt command. For more information, see Netsh commands for AAAA. Save the IAS configuration with the netsh aaaa show config > path\file.txt command each time a change is made.
  • Do not install XOX; XOX; or XOX on the same partition as Windows 2000. These operating systems use common files in the systemroot\Program Files folder to access the IAS database. If you decide to install XOX; XOX; or XOX on the same partition as Windows 2000, IAS in Windows 2000 can no longer access remote access policies or remote access logging.
  • Do not configure a server running IAS or Routing and Remote Access and Windows Server 2003 as a member of a Windows NT Server 4.0 domain if your user accounts database is stored on a Windows Server 2003 domain controller in another domain. Doing this will cause Lightweight Directory Access Protocol (LDAP) queries from the IAS server to the Windows Server 2003 domain controller to fail.

    Instead, configure your server running IAS or Routing and Remote Access and Windows Server 2003 as a member of a Windows Server 2003 domain. Alternately, you can configure a server running IAS and Windows Server 2003 as a proxy server that forwards authentication and accounting requests to another server running IAS and Windows Server 2003 that can access the user accounts database on the Windows Server 2003 domain controller. For more information, see Deploying IAS as a RADIUS proxy.

Security issues

When you are administering an IAS server remotely, do not send sensitive or confidential data (for example shared secrets or passwords) over the network in plaintext. There are two recommended methods for remote administration of IAS servers:

  • Use Terminal Services to access the IAS server.

    When you use Terminal Services, data is not sent between client and server. Only the user interface of the server (for example, the operating system desktop and IAS console image) is sent to the Terminal Services client, which is named Remote Desktop Connection in XOX. The client sends keyboard and mouse input, which is processed locally by the server that has Terminal Services enabled. When Terminal Services users log on, they can view only their individual client sessions, which are managed by the server and are independent of each other. In addition, Remote Desktop Connection provides 128-bit encryption between client and server. For more information, see Terminal Services.

  • Use IPSec to encrypt confidential data.

    You can use IPSec to encrypt communication between the IAS server and the remote client computer that is being used to administer it. In order to administer the server remotely, the Windows Server 2003 Administration Tools Pack must be installed on the client computer, and the IAS snap-in must be added to the Microsoft Management Console (MMC). For more information, see IPSec Policy Rules and To add a published snap-in to a new MMC console.

Your IAS server provides authentication, authorization, and accounting for connection attempts to your organization network. You can protect your IAS server and RADIUS messages from unwanted internal and external intrusion. For more information about how to secure your IAS server, see Securing IAS.

For additional information about securing RADIUS traffic when IAS is used as a RADIUS server, see IAS as a RADIUS server security considerations. For additional information about securing RADIUS traffic when IAS is used as a RADIUS proxy, see IAS as a RADIUS proxy security considerations.

Use the Runas command to administer local IAS servers

You can use the Runas command to perform administrative tasks when you are logged on as a member of a group that does not have the required administrative credentials (such as the Users group or the Power Users group). Logging onto your server without administrative credentials is recommended because it protects the computer from a variety of possible security attacks, such as the accidental installation of a computer virus.

For more information, see To run a program with administrative credentials, To create a shortcut using the runas command, and Runas.

Logging

There are two types of logging in IAS:

  1. Event logging for IAS

    2. You can use event logging to record IAS events in the system event log. This is used primarily for auditing and troubleshooting connection attempts.

  2. Logging user authentication and accounting requests

    3. You can log user authentication and accounting requests to log files in text format or database format, or you can log to a stored procedure in a SQL Server 2000 database. Request logging is used primarily for connection analysis and billing purposes, and is also useful as a security investigation tool, providing you with a method of tracking down the activity an attacker.

To make the most effective use of IAS logging:

  • Turn on logging (initially) for both authentication and accounting records. Modify these selections after you have determined what is appropriate for your environment.
  • Ensure that event logging is configured with a capacity that is sufficient to maintain your logs.
  • Back up all log files on a regular basis, since they cannot be recreated when they are damaged or deleted.
  • Use the RADIUS Class attribute to both track usage and simplify the identification of which department or user to charge for usage. Although the automatically generated Class attribute is unique for each request, duplicate records might exist in cases where the reply to the access server is lost and the request is resent. You might need to delete duplicate requests from your logs to accurately track usage.
  • To provide failover and redundancy with SQL Server logging, place two computers running SQL Server on different subnets. Use the SQL Server Create Publication Wizard to set up database replication between the two servers. For more information, see SQL Server 2000 documentation.

You can use the Iasparse.exe tool in the \Support\Tools folder on the XOX; XOX; or XOX compact disc to view IAS logs.

For more information, see Remote access logging.

Performance-tuning IAS

  • To optimize IAS authentication and authorization response times and minimize network traffic, install IAS on a domain controller.
  • When universal principal names (UPNs) or Windows Server 2003 domains are used, IAS uses the global catalog to authenticate users. To minimize the time it takes to do this, install IAS on either a global catalog server or a server that is on the same subnet. For more information, see The role of the global catalog. For more information about domain functionality, see Domain and forest functionality.
  • When you have remote RADIUS server groups configured and, in RADIUS proxy server Connection Request Policies, you clear the Record accounting information on the servers in the following remote RADIUS server group check box, these groups are still sent network access server (NAS) start and stop notification messages. This creates unnecessary network traffic. To eliminate this traffic, disable NAS notification forwarding for individual servers in each remote RADIUS server group by clearing the Forward network start and stop notifications to this server check box. For more information, see To configure the authentication and accounting settings of a group member and To configure accounting.

Using IAS in large organizations

  • If you are using remote access policies to restrict access for all but certain groups, create a universal group for all of the users for whom you want to allow access, and then create a remote access policy that grants access for this universal group. Do not put all of your users directly into the universal group, especially if you have a large number of them on your network. Instead, create separate groups that are members of the universal group, and add users to those groups. For more information about universal groups, see Group scope. For more information about restricting or granting access to a group, see Allow dial-up connection using group membership.
  • Use a user principal name to refer to users whenever possible. A user can have the same user principal name regardless of domain membership. This practice provides scalability that might be required in organizations with a large number of domains.
  • If the IAS server is on a computer other than a domain controller and it is receiving a very large number of authentication requests per second, you can improve performance by increasing the number of concurrent authentications between the IAS server and the domain controller.

    • To do this, edit the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters. Add a new value named MaxConcurrentApi and assign to it a value from 2 through 5. For more information about adding values to registry keys, see To add a value to a registry key entry.

    Caution

    • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Notes

  • If you assign a value to MaxConcurrentApi that is too high, your IAS server might place an excessive load on your domain controller.
  • To effectively balance the load of either a large number of authorizations or a large volume of RADIUS authentication traffic (such as a large wireless implementation using certificate-based authentication), install IAS as a RADIUS server on all of your domain controllers. Next, configure two or more IAS proxies to forward the authentication requests between the access servers and the RADIUS servers. Next, configure your access servers to use the IAS proxies as RADIUS servers. For more information, see Using IAS proxy for load balancing.
  • XOX


How to...

  • Install IAS
  • Manage a remote IAS server
  • Copy the IAS configuration to another server
  • Enable the IAS server to read user accounts in Active Directory
  • Start or stop IAS
  • Configure IAS properties
  • Configure RADIUS clients
  • Configure remote access policies
  • Configure connection request processing
  • Configure logging for user authentication and accounting

Note

  • XOX


Install IAS

Microsoft Windows graphic

To install IAS

  1. Open Add or Remove Programs in Control Panel.
  2. Click Add/Remove Windows Components.
  3. In the Windows Components Wizard dialog box, click Networking Services, and then click Details.
  4. In the Networking Services dialog box, select Internet Authentication Service, click OK, and then click Next.
  5. If prompted, insert your XOX; XOX; or XOX compact disc.
  6. After IAS is installed, click Finish, and then click Close.

Notes

  • You must be logged on as an administrator or a member of the Administrators group in order to complete this procedure. If your computer is connected to a network, network policy settings might prevent you from completing this procedure.
  • XOX
  • XOX

Related Topics


Manage a remote IAS server

Microsoft Windows Graphic

To manage a remote IAS server

  1. Click Start, click Run, type MMC, and then click OK.
  2. In the MMC console, click File, click Add/Remove Snap-in, and then click Add.
  3. Click Internet Authentication Service (IAS), and then click Add.
  4. Select the computer for which you want to manage IAS:
    5. To | Do this
Manage IAS on the computer on which this console is running | Click Local computer (the one this console is running on).
Manage IAS on a remote computer | Click Another computer, and then type the name or IP address of the remote IAS server.
  5. Click Finish, click Close, and then click OK.

Note

  • You must be logged on as an administrator or a member of the Administrators group in order to complete this procedure. If your computer is connected to a network, network policy settings might also prevent you from completing this procedure.

Related Topics


Copy the IAS configuration to another server

Microsoft Windows graphic

To copy the IAS configuration to another server

  1. Open Command Prompt.
  2. At the command prompt, type netsh aaaa show config > path\file.txt.

    3. This stores configuration settings (including registry settings) in a text file. The path can be relative or absolute, or it can be a UNC path.

  3. Copy the file you created to the destination computer.
  4. At a command prompt on the destination computer, type netsh exec path\file.txt.

    5. A message appears indicating whether the update was successful.

Notes

  • XOX
  • You do not need to stop IAS on the destination computer to run the netsh exec command. When the command is run, IAS is automatically refreshed with the updated configuration settings.
  • Because IAS configurations are not encrypted in the text file, sending it over a network might pose a security risk.
  • Do not use this procedure if the source IAS database is a higher version number than the version number of the destination IAS database. You can view the version number of the IAS database from the display of the netsh aaaa show config command.
  • This procedure replicates the entire IAS, remote access policy, connection request policy, registry, and logging configuration.
  • You can copy a remote access configuration from a server running Routing and Remote Access and Windows 2000 or Windows Server 2003 to an IAS server. Use the netsh aaaa dump command at the remote access server to create a file that contains the configuration, copy it to the IAS server, and then use the netsh exec command to import the configuration to the IAS server. Next, configure RADIUS clients on the IAS server.
  • XOX

Related Topics


Enable the IAS server to read user accounts in Active Directory

Microsoft Windows graphic

To enable the IAS server to read user accounts in Active Directory

  • To register the IAS server in the default domain using Internet Authentication Service:
    1. Log on to the IAS server with an account that has administrative credentials for the domain.
    2. Open Internet Authentication Service.
    3. Right-click Internet Authentication Service, and then click Register Server in Active Directory. When the Register Internet Authentication Service in Active Directory dialog box appears, click OK.
  • To register the IAS server in the default domain using the netsh command:
    1. Log on to the IAS server with an account that has administrative credentials for the domain.
    2. Open Command Prompt.
    3. At the command prompt, type:

      netsh ras add registeredserver

  • To register the IAS server in the default domain using Active Directory Users and Computers:
    1. Log on to the IAS server with an account that has administrative credentials for the domain.
    2. Open Active Directory Users and Computers.
    3. In the console tree, click the Users folder in the appropriate domain.
    4. In the details pane, right-click RAS and IAS Servers, and then click Properties.
    5. In the RAS and IAS Servers Properties dialog box, on the Members tab, add each of the IAS servers.
  • To register the IAS server in another domain using Active Directory Users and Computers:
    1. Log on to the IAS server with an account that has administrative credentials for the domain.
    2. Open Active Directory Users and Computers.
    3. In the console tree, click the Users folder in the appropriate domain.
    4. In the details pane, right-click RAS and IAS Servers, and then click Properties.
    5. In the RAS and IAS Servers Properties dialog box, on the Members tab, add each of the IAS servers.
  • To register the IAS server in another domain using the netsh command:
    1. Log on to the IAS server with an account that has administrative credentials for the domain.
    2. Open Command Prompt.
    3. At the command prompt, type:

      netsh ras add registeredserver Domain IASServer

      4. where Domain is the DNS domain name of the domain and IASServer is the name of the IAS server computer.

Notes

  • XOX
  • XOX
  • XOX
  • After you register the service in Active Directory, you can verify the security settings. For more information, see Related Topics.
  • You can add the IAS server to the RAS and IAS Servers group with the Dsmod tool. For more information, see Related Topics.
  • For more information about how to use IAS or Routing and Remote Access servers as stand-alone servers or member servers in Windows NT 4.0 domains, Windows 2000 mixed domains, Windows 2000 native domains, and Windows Server 2003 domains, see Related Topics.

Related Topics


Start or stop IAS

Microsoft Windows graphic

To start or stop IAS

  1. Open Internet Authentication Service.
  2. In the console tree, right-click Internet Authentication Service, and then click Start Service.

    Or, to stop the service, click Stop Service.

Note

  • XOX


Configure IAS properties

  • Configure IAS port information
  • Configure event logging for IAS


Configure IAS port information

Microsoft Windows graphic

To configure IAS port information

  1. Open Internet Authentication Service.
  2. Right-click Internet Authentication Service, and then click Properties.
  3. Click the Ports tab, and then examine the settings for ports. If your RADIUS authentication and RADIUS accounting UDP ports vary from the default values provided (1812 and 1645 for authentication, and 1813 and 1646 for accounting), type your port settings in Authentication and Accounting.

    To use multiple port settings for authentication or accounting requests, separate the port numbers with commas.

Notes

  • XOX
  • To configure a remote IAS server, you must have administrative credentials on the remote server.
  • The values of 1812 for authentication and 1813 for accounting are RADIUS standard ports defined in RFCs 2865 and 2866. However, many access servers use ports 1645 for authentication requests and 1646 for accounting requests by default. Whatever port numbers you decide to use, make sure that IAS and your access server are configured to use the same ones.
  • You can specify an IP address to which the RADIUS messages must be sent with the following syntax: IPAddress:UDPPort. For example, if you have multiple network adapters and you only want to receive RADIUS authentication messages sent to the IP address of 10.0.0.99 and UDP port 1812, you would type 10.0.0.99:1812 in Authentication.

Related Topics


Configure event logging for IAS

Microsoft Windows graphic

To configure event logging for IAS

  1. Open Internet Authentication Service.
  2. Right-click Internet Authentication Service (IAS), and then click Properties.
  3. On the General tab, select each required option, and then click OK.

Notes

  • XOX
  • Rejected, discarded, and successful authentication requests are logged by default.
  • Selecting Successful authentication requests can result in logging extremely large volumes of data. Before selecting this option, verify that the Event Viewer is configured with a maximum log size that will accommodate this type of event logging.

Related Topics


Configure RADIUS clients

  • Add RADIUS clients
  • Delete a RADIUS client
  • Edit RADIUS client configuration
  • Configure the Message Authenticator attribute and shared secret

Note

  • XOX


Add RADIUS clients

Microsoft Windows graphic

To add RADIUS clients

  1. Open Internet Authentication Service.
  2. Right-click RADIUS Clients, and then click New RADIUS Client.
  3. Use the New RADIUS Client Wizard to both add and configure a client.

Notes

  • XOX
  • If the client is a network access server (NAS) and you are planning to use NAS-specific remote access policies for configuration (for example, a remote access policy that contains vendor-specific attributes), in the New RADIUS Client Wizard, click Client Vendor, and then select the name of the manufacturer. If you do not know the name of the manufacturer or it is not in the list, click RADIUS Standard. If the RADIUS client is a computer running XOX; XOX; or XOX and the Routing and Remote Access service, click Microsoft.
  • When you have a number of RADIUS clients on the same subnet (such as, numerous wireless access points), you can simplify RADIUS client administration by specifying an address range while running the wizard, instead of specifying the IP address or DNS name of a single RADIUS client. All of the RADIUS clients in the range must use the same configuration and shared secret. The address range for RADIUS clients is expressed in the network prefix length notation w.x.y.z/p, where w.x.y.z is the dotted decimal notation of the address prefix and p is the prefix length (the number of high order bits that define the network prefix). This is also known as Classless Inter-Domain Routing (CIDR) notation. An example is 192.168.21.0/24. To convert from subnet mask notation to network prefix length notation, p is the number of high order bits set to one in the subnet mask.
  • If your access server supports use of the Message Authenticator attribute (also known as the signature attribute), in the New RADIUS Client Wizard, click Request must contain the Message Authenticator attribute. If the access server does not support the Message Authenticator attribute, do not select this option.
  • If IAS receives an access request from a RADIUS proxy, it cannot detect the manufacturer of the NAS that originated the request. This can cause problems if you plan to use remote access policy conditions that are based on the client vendor and have at least one client that is defined as a RADIUS proxy. Requests from the proxy might not match any of the remote access policies and be denied.
  • Shared secrets are case-sensitive. Verify that the client's shared secret and the shared secret you type in Shared secret are identical. For more information, see Related Topics.
  • If the client address cannot be resolved when you click Verify, make sure that the DNS name that you typed is correct.
  • You can use the friendly name that you provide for your RADIUS clients with the Client-Friendly-Name condition in remote access policies. For more information, see Related Topics.
  • Enabling the use of the Message Authenticator attribute provides additional security when PAP, CHAP, MS-CHAP, and MS-CHAP v2 are used for authentication. EAP uses the Message Authenticator attribute by default and does not require that you enable it. For more information, see Related Topics.
  • XOX

Related Topics


Delete a RADIUS client

Microsoft Windows graphic

To delete a RADIUS client

  1. Open Internet Authentication Service.
  2. In the console tree, click RADIUS Clients.
  3. In the details pane, right-click the client that you want to delete, and then click Delete.
  4. In the Delete Client dialog box, click Yes.

Note

  • XOX

Related Topics


Edit RADIUS client configuration

Microsoft Windows graphic

To edit RADIUS client configuration

  1. Open Internet Authentication Service.
  2. In the console tree, click RADIUS Clients.
  3. In the details pane, double-click the client for which you want to edit the configuration.
  4. Make changes to the RADIUS client configuration.
  5. Click OK to save your changes.

Notes

  • XOX
  • If IAS receives an access request from a RADIUS proxy server, IAS cannot detect the manufacturer of the NAS that originated the request. This can cause problems if you plan to use remote access policy conditions that are based on the client vendor and have at least one client that is defined as a RADIUS proxy server. Requests from the proxy might not match any of the remote access policies and be denied.
  • Shared secrets are case-sensitive. Verify that the client's shared secret and the shared secret that you type in Shared secret are identical. For more information, see Related Topics.
  • If the client address cannot be resolved when you click Verify, make sure the DNS name that you typed is correct.
  • You can use the friendly name that you provide for your RADIUS clients with the Client-Friendly-Name condition in remote access policies. For more information, see Related Topics.
  • Enabling the use of the Message Authenticator attribute provides additional security when PAP, CHAP, MS-CHAP, and MS-CHAP v2 are used for authentication. EAP uses the Message Authenticator attribute by default and does not require that you enable it. For more information, see Related Topics.
  • XOX

Related Topics


Configure the Message Authenticator attribute and shared secret

Microsoft Windows graphic

To configure the Message Authenticator attribute and shared secret

  1. Open Internet Authentication Service.
  2. In the console tree, click RADIUS Clients.
  3. In the details pane, double-click the client for which you want to edit the configuration.
  4. To enable or disable use of the Message Authenticator attribute, click Request must contain the Message Authenticator attribute.
  5. In Shared secret, type a shared secret. In Confirm shared secret, retype the shared secret.
  6. Click OK to save your changes.

Notes

  • XOX
  • When you enable the Message Authenticator attribute, the entire RADIUS message is encrypted and the shared secret is used as the key. Shared secrets are case-sensitive. Verify that the client's shared secret and the shared secret that you type in Shared secret are identical. For more information, see Related Topics.
  • Enabling the use of the Message Authenticator attribute provides additional security when PAP, CHAP, MS-CHAP, and MS-CHAP v2 are used for authentication. EAP uses the Message Authenticator attribute by default and does not require that you enable it. For more information, see Related Topics.
  • Shared secrets should be comprised of a 22-character or longer random sequence of letters, numbers, and punctuation and should be changed often to protect your IAS server and your RADIUS clients from online dictionary attacks. For more information, see Related Topics.

Related Topics


Configure remote access policies

  • Add a remote access policy
  • Configure a remote access policy to grant or deny access
  • Configure a condition of a remote access policy
  • Change the policy evaluation order
  • Rename a remote access policy
  • Delete a remote access policy
  • Recreate the default remote access policy
  • Configure a profile for a remote access policy


Add a remote access policy

Microsoft Windows graphic

To add a remote access policy

  1. Do one of the following:
    • Open Routing and Remote Access and, if necessary, double-click Routing and Remote Access and the server name.
    • Open Internet Authentication Service and, if necessary, double-click Internet Authentication Service.
  2. In the console tree, right-click Remote Access Policies, and then click New Remote Access Policy.
  3. Use the New Remote Access Policy Wizard to create a policy.

    4. For a common policy, you must choose the following:

    • An access method:
      • VPN access
      • Dial-up access
      • Wireless access
      • Ethernet
    • Whether to grant access permissions by user or by group.
    • Authentication methods.
    • Levels of allowed encryption (depending on the access method selected).

    For a custom policy, you must configure the following:

    • A set of policy conditions.
    • Whether remote access permission for the policy is granted or denied.
    • Remote access policy profile settings.

Notes

  • XOX
  • XOX
  • You cannot use this procedure to configure a remote access policy unless a remote access server is already installed on your network. After installing one or more remote access servers, use this procedure and the New Remote Access Policy Wizard to configure a new remote access policy.
  • When you use the New Remote Access Policy Wizard to create a common policy:
    • The access method is used to automatically configure the NAS Port Type condition.
    • If you choose to grant access by group, the Windows Groups condition is automatically set to the selected groups.
    • The authentication settings are used to set the profile settings on the Authentication tab.
    • The encryption levels are used to set the profile settings on the Encryption tab.
    • The remote access permission is always set to Grant remote access permission.

Related Topics


Configure a remote access policy to grant or deny access

Microsoft Windows graphic

To configure a remote access policy to grant or deny access

  1. Do one of the following:
    • Open Routing and Remote Access and, if necessary, double-click Routing and Remote Access and the server name.
    • Open Internet Authentication Service and, if necessary, double-click Internet Authentication Service.
  2. In the console tree, click Remote Access Policies.
  3. In the details pane, double-click the policy that you want to configure.
  4. Under If a connection request matches the specified conditions:
    • To grant dial-up permission for these users, click Grant remote access permission.
    • To deny dial-up permission for these users, click Deny remote access permission.

Notes

  • XOX
  • XOX
  • The Remote Access Permission setting on the dial-in properties of the user or computer account overrides this setting if it is set to either Allow access or Deny access.

Related Topics


Configure a condition of a remote access policy

Microsoft Windows graphic

To configure a condition of a remote access policy

  1. Do one of the following:
    • Open Routing and Remote Access, double-click Routing and Remote Access, and then double-click the server name to expand the console tree.
    • Open Internet Authentication Service and, if necessary, double-click Internet Authentication Service.
  2. In the console tree, click Remote Access Policies.
  3. In the details pane, double-click the policy that you want to configure.
  4. To configure a new condition, click Add, and then do the following:
    • In the Select Attribute dialog box, click the attribute to add, and then click Add.
    • In the attribute dialog box, configure the attribute, and then click OK.
  5. To change the configuration of an existing condition:
    • Click the condition, and then click Edit.
    • In the attribute dialog box, specify the required settings, and then click OK.

Notes

  • XOX
  • XOX

Related Topics


Change the policy evaluation order

Microsoft Windows graphic

To change the policy evaluation order

  1. Do one of the following:
    • Open Routing and Remote Access and, if necessary, double-click Routing and Remote Access and the server name.
    • Open Internet Authentication Service and, if necessary, double-click Internet Authentication Service.
  2. In the console tree, click Remote Access Policies.
  3. In the details pane, right-click the policy that you want to move, and then click either Move Up (to move the policy up one level) or Move Down (to move the policy down one level).

Notes

  • XOX
  • XOX

Related Topics


Rename a remote access policy

Microsoft Windows graphic

To rename a remote access policy

  1. Do one of the following:
    • Open Routing and Remote Access and, if necessary, expand Routing and Remote Access and the server name.
    • Open Internet Authentication Service and, if necessary, expand Internet Authentication Service.
  2. In the console tree, click Remote Access Policies.
  3. In the details pane, right-click the policy that you want to rename, and then click Rename.
  4. Type a new name for the policy, and then press ENTER.

Notes

  • XOX
  • XOX

Related Topics


Delete a remote access policy

Microsoft Windows graphic

To delete a remote access policy

  1. Do one of the following:
    • Open Routing and Remote Access and, if necessary, double-click Routing and Remote Access and the server name.
    • Open Internet Authentication Service and, if necessary, double-click Internet Authentication Service.
  2. In the console tree, click Remote Access Policies.
  3. In the details pane, right-click the policy that you want to delete, and then click Delete.

Notes

  • XOX
  • XOX

Related Topics


Recreate the default remote access policy

Microsoft Windows graphic

To recreate the default remote access policy

  1. Do one of the following:
    • Open Routing and Remote Access and, if necessary, double-click both Routing and Remote Access and the server name.
    • Open Internet Authentication Service and, if necessary, double-click Internet Authentication Service.
  2. Right-click Remote Access Policies, and then click New Remote Access Policy.
  3. In the Add Remote Access Policy Wizard, create a custom remote access policy with the following settings:
    • In Policy name, type a default name, and then click Next.
    • In Conditions, click Add, click Day-and-Time-Restrictions, click Add, and then configure the attribute to permit all times on all days.
    • Click OK, and then click Next.
    • In Permissions, click Deny remote access permission, and then click Next.
    • In Profile, click Next. Do not make any changes to the profile.
    • Click Finish.

Notes

  • XOX
  • XOX

Related Topics


Configure a profile for a remote access policy

  • Configure dial-in constraints
  • Configure IP options
  • Configure multilink options
  • Configure authentication
  • Configure PEAP and EAP methods
  • Configure encryption
  • Configure attributes for a profile


Configure dial-in constraints

Microsoft Windows graphic

To configure dial-in constraints

  1. Do one of the following:
    • Open Routing and Remote Access, double-click Routing and Remote Access, and then double-click the server name to expand the console tree.
    • Open Internet Authentication Service and, if necessary, double-click Internet Authentication Service.
  2. In the console tree, click Remote Access Policies.
  3. In the details pane, double-click the remote access policy that you want to configure.
  4. Click Edit Profile.
  5. On the Dial-in Constraints tab, specify any required settings.

Notes

  • XOX
  • XOX
  • Dial-in constraints should work with most network access servers, however, some network access servers might not support the RADIUS attributes that are required to enable dial-in constraints. For more information, see your NAS documentation.


Configure IP options

Microsoft Windows graphic

To configure IP options

  1. Do one of the following:
    • Open Routing and Remote Access and, if necessary, double-click Routing and Remote Access and the server name.
    • Open Internet Authentication Service and, if necessary, double-click Internet Authentication Service.
  2. In the console tree, click Remote Access Policies.
  3. In the details pane, double-click the remote access policy that you want to configure.
  4. Click Edit Profile.
  5. On the IP tab, specify any required settings.

Notes

  • XOX
  • XOX


Configure multilink options

Microsoft Windows graphic

To configure multilink options

  1. Do one of the following:
    • Open Routing and Remote Access and, if necessary, double-click Routing and Remote Access and the server name.
    • Open Internet Authentication Service and, if necessary, double-click Internet Authentication Service.
  2. In the console tree, click Remote Access Policies.
  3. In the details pane, double-click the remote access policy that you want to configure.
  4. Click Edit Profile.
  5. On the Multilink tab, specify any required settings.

Notes

  • XOX
  • XOX


Configure authentication

Microsoft Windows graphic

To configure authentication

  1. Do one of the following:
    • Open Routing and Remote Access and, if necessary, double-click Routing and Remote Access and the server name.
    • Open Internet Authentication Service and, if necessary, double-click Internet Authentication Service.
  2. In the console tree, click Remote Access Policies.
  3. In the details pane, double-click the policy that you want to configure.
  4. Click Edit Profile.
  5. On the Authentication tab, specify any required settings.

Notes

  • XOX
  • XOX
  • When using the EAP-TLS authentication method with certificates, TLS uses cached certificate properties instead of reading the certificate from the certificate store. If a certificate is either changed or deleted and replaced by a new certificate, TLS continues using outdated cached certificate information until the cache expires or is refreshed. If you change or replace a certificate, you can refresh the TLS cache by restarting the server computer.
  • For information about configuring specific authentication protocols, see Related Topics.

Related Topics


Configure PEAP and EAP methods

Microsoft Windows Graphic

To configure PEAP and EAP methods

  1. Open Internet Authentication Service and, if necessary, double-click Internet Authentication Service.
  2. In the console tree, click Remote Access Policies.
  3. In the details pane, double-click the policy that you want to configure.
  4. Click Edit Profile.
  5. On the Authentication tab, click EAP Methods.
  6. In Select EAP providers, click Add. Select the authentication methods that you want to use, and then click OK.
  7. In Select EAP providers, click the EAP type that you want to configure, and then click Edit. Depending on the EAP type selected, one of the following dialog boxes is displayed:
    • If Protected EAP (PEAP) is selected, the Protected EAP Properties dialog box opens. In Certificate Issued, select the certificate that the server uses to identify itself to client computers. To enable PEAP fast reconnect for 802.11 wireless client computers, click Enable Fast Reconnect. Secure password user authentication with EAP-MSCHAPv2 is the default in EAP Types. To configure EAP-MSCHAPv2 properties, click Edit. To configure certificate or smart card user authentication click Add. In Authentication methods, click Smart Card or other certificate, and then click OK.
    • If Smart Card or other Certificate Properties is selected, the Smart Card or other Certificate Properties dialog box opens. In Certificate issued to, select the certificate that the server uses to authenticate to client computers.
  8. In Select EAP providers, click Move Up or Move Down to specify the negotiation order of EAP methods. The server starts negotiation with the client according to the order specified in EAP types.

Notes

  • XOX
  • XOX
  • If the EAP types displayed in the Select EAP Providers dialog box are selected as (Server-Configured), then the configuration of the EAP type is common to the server and applies to all remote access policies that are configured on the server. Otherwise, the EAP type configuration is specific to the current remote access policy, in which case the EAP method must be configured for each policy to which you want it to apply.
  • PEAP is used as an authentication method for 802.11 wireless client computers, but is not supported for virtual private network (VPN) or other remote access clients. Because of this, you can only configure PEAP as the authentication method for a remote access policy when you are using IAS.
  • When using the PEAP-EAP-TLS and EAP-TLS authentication methods with certificates, TLS uses cached certificate properties instead of reading the certificate from the certificate store. If a certificate is either changed or deleted and replaced by a new certificate, TLS continues using outdated cached certificate information until the cache expires or is refreshed. If you change or replace a certificate, you can refresh the TLS cache by restarting the server computer.
  • EAP-TLS is not supported if the IAS or remote access server is not a member of the domain.
  • If you have issued a certificate to your IAS server that has a blank Subject, the certificate is not available to authenticate your IAS server. To change this, you can use Certificate Templates to create a new certificate for enrollment on your IAS server. In the certificate properties, on the Subject Name tab, in Subject name format, select a value other than None.
  • For information about configuring specific authentication protocols, see Related Topics.

Related Topics


Configure encryption

Microsoft Windows graphic

To configure encryption

  1. Do one of the following:
    • Open Routing and Remote Access and, if necessary, double-click Routing and Remote Access and the server name.
    • Open Internet Authentication Service and, if necessary, double-click Internet Authentication Service.
  2. In the console tree, click Remote Access Policies.
  3. In the details pane, double-click the remote access policy that you want to configure.
  4. Click Edit Profile.
  5. On the Encryption tab, specify any required settings.

Notes

  • XOX
  • XOX


Configure attributes for a profile

  • Add RADIUS attributes to a remote access policy
  • Configure vendor-specific attributes for a remote access policy


Add RADIUS attributes to a remote access policy

Microsoft Windows graphic

To add RADIUS attributes to a remote access policy

  1. Open Internet Authentication Service.
  2. In the console tree, click Remote Access Policies.
  3. Right-click the policy for which you want to configure a RADIUS attribute, and then click Properties.
  4. Click Edit Profile, click the Advanced tab, and then click Add.
  5. In the list of available RADIUS attributes, double-click the attribute that you want to add to the profile. If the Multivalued Attribute Information dialog box appears, click Add.
  6. In Attribute, supply a value from the following table, and then click Add. If you want to add another value to the attribute, click Add again, and then configure the attribute.
If the attribute format is | In Attribute value | Attributes in this format include
Integer | Type the value specified in your access server documentation. | Acct-Interim-Interval
Enumerator | Select the value from the list. | Framed-Protocol
InetAddr | Type the IP address to be specified in the attribute. | Framed-IP-Netmask
Octet String | Type the string or the hexadecimal value that you provide. | Tunnel-Password
String | Type the string that you provide. | Reply-Message
Boolean | Select either True or False. | Ignore-User-Dialin-Properties

Notes

  • XOX
  • You can only use the Generate-Session-Timeout attribute if your user account database is either a Security Accounts Manager (SAM) database or the user account database for an Active Directory domain. When the value of Generate-Session-Timeout is set to True, the ForceLogoff value for a SAM database should be set to 0 (zero). In Local Security Settings, ForceLogoff is set to 0 when Network security: Force logoff when logon hours expire is enabled. For more information, see To edit a security setting on a Group Policy object. For information about changing the ForceLogoff value for the SAM database at the command prompt, see Net accounts.
  • You can configure wireless connection policy so that wireless clients periodically reauthenticate. This ensures that the client Wired Equivalent Privacy (WEP) encryption keys are changed often enough to provide adequate security for the wireless connection. To configure reauthentication, set the session timeout in your remote access policy or connection request policy for wireless connections (using the Session-Timeout attribute) to the interval you prefer (for example, 10 minutes). Additionally, configure the Termination-Action attribute with Attribute value set to RADIUS-Request. If the Termination-Action attribute is not set to RADIUS-Request, wireless access points might end the connection during reauthentication. For more information, see your hardware documentation.

Related Topics


Configure vendor-specific attributes for a remote access policy

Microsoft Windows graphic

To configure vendor-specific attributes for a remote access policy

  1. Open Internet Authentication Service.
  2. In the console tree, click Remote Access Policies.
  3. Right-click the policy for which you want to configure a vendor-specific attribute (VSA), and then click Properties.
  4. Click Edit Profile, click the Advanced tab, and then click Add.
  5. Look at the list of available RADIUS attributes to determine whether your vendor-specific attribute is already in it. If it is, double-click it, and then configure it as specified in your NAS documentation. If the vendor-specific attribute is not in the list of available RADIUS attributes:
    1. Double-click Vendor-Specific, and then click Add.
    2. Specify the vendor for your network access server.

      To specify the NAS vendor by selecting the name from the list, click Select from list, and then select the vendor of the NAS for which you are configuring the VSA. If you are using Routing and Remote Access as your NAS, click Microsoft.

      If the vendor is not listed, you can specify the vendor by typing the vendor code. To do this, click Enter Vendor Code, and then type the vendor code in the space provided. If you do not know the vendor code for your NAS, see IETF RFC 1007 for a list of SMI Network Management Private Enterprise Codes.

    3. Specify whether the attribute conforms to the RADIUS RFC VSA specification. If you are not sure, see your NAS documentation.
      • If your attribute conforms, click Yes. It conforms, and then click Configure Attribute.
        1. In Vendor-assigned attribute number, type the number that is assigned to the attribute (the numbers available are 0 through 255).
        2. In Attribute format, specify the format for the attribute, and then in Attribute value, type the value that you are assigning to the attribute.
      • If the attribute does not conform, click No. It does not conform, and then click Configure Attribute. In Hexadecimal attribute value, type the value for the attribute.

Notes

  • XOX
  • To see configuration examples for vendor-specific attributes that both conform and do not conform to the RADIUS RFC, see Related Topics.

Related Topics


Configure connection request processing

  • Configure connection request policies
  • Configure remote RADIUS server groups


Configure connection request policies

  • Add a connection request policy
  • Configure a condition of a connection request policy
  • Change the policy evaluation order
  • Delete a connection request policy
  • Configure a profile for a connection request policy


Add a connection request policy

Microsoft Windows graphic

To add a connection request policy

  1. Open Internet Authentication Service.
  2. In the console tree, right-click Connection Request Policies, and then click New Connection Request Policy.

    3. Where?

    • Internet Authentication Service (Local)
    • Connection Request Processing
    • Connection Request Policies
  3. Use the New Connection Request Policy Wizard to configure your connection request policy.

Notes

  • XOX
  • You are not required to configure a remote RADIUS server group before you create a connection request policy that forwards authentication or accounting messages. You can create a remote RADIUS server group in the New Connection Request Policy Wizard.

Related Topics


Configure a condition of a connection request policy

Microsoft Windows graphic

To configure a condition of a connection request policy

  1. Open Internet Authentication Service.
  2. In the console tree, click Connection Request Policies.

    3. Where?

    • Internet Authentication Service (Local)
    • Connection Request Processing
    • Connection Request Policies
  3. In the details pane, double-click the policy that you want to configure.
  4. To configure a new condition, click Add, and then do the following:
    • In the Select Attribute dialog box, click the attribute to add, and then click Add.
    • In the attribute dialog box, configure the attribute, and then click OK.
  5. To change the configuration of an existing condition:
    • Click the condition, and then click Edit.
    • In the attribute dialog box, specify your required settings, and then click OK.

Note

  • XOX

Related Topics


Change the policy evaluation order

Microsoft Windows graphic

To change the policy evaluation order

  1. Open Internet Authentication Service.
  2. In the console tree, click Connection Request Policies.

    3. Where?

    • Internet Authentication Service (Local)
    • Connection Request Processing
    • Connection Request Policies
  3. In the details pane, right-click the policy that you want to move, and then click either Move Up (to move the policy up one level) or Move Down (to move the policy down one level).

Note

  • XOX

Related Topics


Delete a connection request policy

Microsoft Windows graphic

To delete a connection request policy

  1. Open Internet Authentication Service.
  2. In the console tree, click Connection Request Policies.

    3. Where?

    • Internet Authentication Service (Local)
    • Connection Request Processing
    • Connection Request Policies
  3. In the details pane, right-click the policy that you want to delete, and then click Delete.

Note

  • XOX

Related Topics


Configure a profile for a connection request policy

  • Configure authentication
  • Configure accounting
  • Configure attribute manipulation
  • Configure advanced attributes


Configure authentication

Microsoft Windows graphic

To configure authentication

  1. Open Internet Authentication Service.
  2. In the console tree, click Connection Request Policies.

    3. Where?

    • Internet Authentication Service (Local)
    • Connection Request Processing
    • Connection Request Policies
  3. In the details pane, right-click the policy that you want to configure, and then click Properties.
  4. Click Edit Profile.
  5. On the Authentication tab, specify authentication settings.

Note

  • XOX

Related Topics


Configure accounting

Microsoft Windows graphic

To configure accounting

  1. Open Internet Authentication Service.
  2. In the console tree, click Connection Request Policies.

    3. Where?

    • Internet Authentication Service (Local)
    • Connection Request Processing
    • Connection Request Policies
  3. In the details pane, right-click the policy that you want to configure, and then click Properties.
  4. Click Edit Profile.
  5. On the Accounting tab, specify accounting settings.

Notes

  • XOX
  • When you have remote RADIUS server groups configured and, in RADIUS proxy server Connection Request Policies, you clear the Record accounting information on the servers in the following remote RADIUS server group check box, these groups are still sent network access server (NAS) start and stop notification messages. This creates unnecessary network traffic. To eliminate this traffic, disable NAS notification forwarding for individual servers in each remote RADIUS server group by clearing the Forward network start and stop notifications to this server check box. For more information, see To configure the authentication and accounting settings of a group member and To configure accounting.

Related Topics


Configure attribute manipulation

Microsoft Windows graphic

To configure attribute manipulation

  1. Open Internet Authentication Service.
  2. In the console tree, click Connection Request Policies.

    3. Where?

    • Internet Authentication Service (Local)
    • Connection Request Processing
    • Connection Request Policies
  3. In the details pane, right-click the policy that you want to configure, and then click Properties.
  4. Click Edit Profile.
  5. On the Attribute tab, specify find and replace rules for RADIUS attributes.

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on your computer.

Notes

  • XOX
  • When the user name does not contain a domain name, IAS supplies one. By default, the domain name supplied is that of which the IAS server is a member. You can specify this domain name through the following registry setting:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RasMan\PPP\ControlProtocols\BuiltIn\DefaultDomain

  • Some third party network access servers delete or modify the domain name as specified by the user. As the result, the network access request is authenticated against the default domain, which might not be the domain for the user's account. To resolve this problem, configure your RADIUS servers to change the user name into the correct format with the accurate domain name.

Related Topics


Configure advanced attributes

Microsoft Windows graphic

To configure advanced attributes

  1. Open Internet Authentication Service.
  2. In the console tree, click Connection Request Policies.

    3. Where?

    • Internet Authentication Service (Local)
    • Connection Request Processing
    • Connection Request Policies
  3. In the details pane, right-click the policy that you want to configure, and then click Properties.
  4. Click Edit Profile.
  5. On the Advanced tab, specify connection attributes.

Note

  • XOX

Related Topics


Configure remote RADIUS server groups

  • Add a remote RADIUS server group
  • Delete a remote RADIUS server group
  • Configure the members of a remote RADIUS server group


Add a remote RADIUS server group

Microsoft Windows graphic

To add a remote RADIUS server group

  1. Open Internet Authentication Service.
  2. In the console tree, right-click Remote RADIUS Server Groups, and then click New Remote RADIUS Server Group.

    3. Where?

    • Internet Authentication Service (Local)
    • Connection Request Processing
    • Remote RADIUS Server Groups
  3. Use the New Remote RADIUS Server Group Wizard to configure your remote RADIUS server group.

Note

  • XOX

Related Topics


Delete a remote RADIUS server group

Microsoft Windows graphic

To delete a remote RADIUS server group

  1. Open Internet Authentication Service.
  2. In the console tree, click Remote RADIUS Server Groups.

    3. Where?

    • Internet Authentication Service (Local)
    • Connection Request Processing
    • Remote RADIUS Server Groups
  3. In the details pane, right-click the remote RADIUS server group that you want to delete, and then click Delete.

Note

  • XOX

Related Topics


Configure the members of a remote RADIUS server group

  • Add a member to a remote RADIUS server group
  • Remove a member from a remote RADIUS server group
  • Configure the name of a group member
  • Configure the authentication and accounting settings of a group member
  • Configure the load balancing properties of a group member

Note

  • XOX


Add a member to a remote RADIUS server group

Microsoft Windows graphic

To add a member to a remote RADIUS server group

  1. Open Internet Authentication Service.
  2. In the console tree, click Remote RADIUS Server Groups.

    3. Where?

    • Internet Authentication Service (Local)
    • Connection Request Processing
    • Remote RADIUS Server Groups
  3. In the details pane, right-click the remote RADIUS server group that you want to configure, and then click Properties.
  4. Click Add, and then configure address, authentication, accounting, and load balancing settings.

Notes

  • XOX
  • XOX

Related Topics


Remove a member from a remote RADIUS server group

Microsoft Windows graphic

To remove a member from a remote RADIUS server group

  1. Open Internet Authentication Service.
  2. In the console tree, click Remote RADIUS Server Groups.

    3. Where?

    • Internet Authentication Service (Local)
    • Connection Request Processing
    • Remote RADIUS Server Groups
  3. In the details pane, right-click the remote RADIUS server group that you want to configure, and then click Properties.
  4. Click the server to remove from the group and then click Remove.

Notes

  • XOX
  • XOX

Related Topics


Configure the name of a group member

Microsoft Windows graphic

To configure the name of a group member

  1. Open Internet Authentication Service.
  2. In the console tree, click Remote RADIUS Server Groups.

    3. Where?

    • Internet Authentication Service (Local)
    • Connection Request Processing
    • Remote RADIUS Server Groups
  3. In the details pane, right-click the remote RADIUS server group that you want to configure, and then click Properties.
  4. On the General tab, click the server that you want to configure, and then click Properties.
  5. On the Address tab, type the name or IP address of the server.

Notes

  • XOX
  • XOX

Related Topics


Configure the authentication and accounting settings of a group member

Microsoft Windows graphic

To configure the authentication and accounting settings of a group member

  1. Open Internet Authentication Service.
  2. In the console tree, click Remote RADIUS Server Groups.

    3. Where?

    • Internet Authentication Service (Local)
    • Connection Request Processing
    • Remote RADIUS Server Groups
  3. In the details pane, right-click the remote RADIUS server group that you want to configure, and then click Properties.
  4. On the General tab, click the server that you want to configure, and then click Properties.
  5. On the Authentication/Accounting tab, specify authentication and accounting settings.

Notes

  • XOX
  • When you have remote RADIUS server groups configured and, in RADIUS proxy server Connection Request Policies, you clear the Record accounting information on the servers in the following remote RADIUS server group check box, these groups are still sent network access server (NAS) start and stop notification messages. This creates unnecessary network traffic. To eliminate this traffic, disable NAS notification forwarding for individual servers in each remote RADIUS server group by clearing the Forward network start and stop notifications to this server check box. For more information, see To configure the authentication and accounting settings of a group member and To configure accounting.
  • XOX

Related Topics


Configure the load balancing properties of a group member

Microsoft Windows graphic

To configure the load balancing properties of a group member

  1. Open Internet Authentication Service.
  2. In the console tree, click Remote RADIUS Server Groups.

    3. Where?

    • Internet Authentication Service (Local)
    • Connection Request Processing
    • Remote RADIUS Server Groups
  3. In the details pane, right-click the remote RADIUS server group that you want to configure, and then click Properties.
  4. On the General tab, click the server that you want to configure, and then click Properties.
  5. On the Load balancing tab, specify load balancing settings.

Notes

  • XOX
  • XOX

Related Topics


Configure logging for user authentication and accounting

  • Select requests to be logged
  • Configure log file properties


Select requests to be logged

Microsoft Windows graphic

To select requests to be logged

  1. Open Internet Authentication Service.
  2. In the console tree, click Remote access logging.
  3. In the details pane, right-click Local File or SQL Server, and then click Properties.
  4. On the Settings tab, select one or more check boxes for recording authentication and accounting requests in the IAS log files:
    • To capture accounting requests and responses, select Accounting requests.
    • To capture authentication requests, Access-Accept messages, and Access-Reject messages, select Authentication requests.
    • To capture periodic status updates, such as interim accounting packets, select Periodic status.

Notes

  • XOX
  • It is recommended that you initially select Accounting requests and Authentication requests. You can change your selections as your requirements change.
  • To use SQL Server logging, you must have a computer running an XML-compliant version of SQL Server. For more information, see Related Topics.
  • The Authentication requests option alerts you to both problems with transaction volume and unauthorized attempts to access resources.
  • Interim accounting messages, recorded when you select Periodic status, are sent by the access server only when:
    1. You have added and configured the Acct-Interim-Interval RADIUS accounting attribute on the Advanced tab of the appropriate remote access policy. For more information, see Related Topics.
    2. The access server supports the Acct-Interim-Interval attribute and the sending of interim accounting messages.
  • Logging of client certificate validation failures is a secure channel (Schannel) event, and is not enabled on the IAS server by default. You can enable additional Schannel events (including logging of the client certificate validation failure) by changing the following registry key value from 1 (REG_DWORD type, data 0x00000001) to 3 (REG_DWORD type, data 0x00000003):

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging

    Caution

    • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Related Topics


Configure log file properties

Microsoft Windows graphic

To configure log file properties

  1. Open Internet Authentication Service.
  2. In the console tree, click Remote Access Logging.
  3. In the details pane, choose one of the following:

    4. Local File

    1. In the details pane, right-click Local File, and then click Properties.
    2. On the Log File tab, in Directory, type the location where log files are to be stored. The default location is the systemroot\System32\LogFiles folder.
    3. In Format, click Database-compatible.

      Or, to keep your log files in IAS format, click IAS.

    4. To open new log files at specific intervals, click the interval that you want to use:
      • For heavy transaction volume and logging activity, click Daily.
      • For lesser transaction volumes and logging activity, click Weekly or Monthly.
      • To store all transactions in one log file, click Never (unlimited file size).
      • To limit the size of each log file, click When log file reaches this size, and then type a file size—after which a new log is created. The default size is 10 MB.
    5. To automatically delete log files when the disk is full, click When disk is full delete older log files.

      Note

      • If the oldest log file is the current log file, it is not deleted. For more information, see Related Topics.

    SQL Server

    1. In the details pane, right-click SQL Server, and then click Properties.
    2. In Log the following information, select the information that you want to log:
      • To log all accounting requests, click Accounting requests.
      • To log authentication requests, click Authentication requests.
      • To log periodic status, such as interim accounting requests, click Periodic status.
    3. To configure the number of concurrent sessions allowed between the IAS server and the SQL Server database, type a number in Maximum number of concurrent sessions.
    4. To configure the SQL Server data source, click Configure, and then, on the Connection tab, specify the following:
      • To specify the name of the server on which the database is stored, type or select a name in Select or enter a server name.
      • To specify the authentication method with which to log on to the server, click Use Windows NT integrated security. Or, click Use a specific user name and password, and then type credentials in User name and Password.
      • To allow a blank password, click Blank password.
      • To store the password, click Allow saving password.
      • To specify which database to connect to on the computer running SQL Server, click Select the database on the server, and then select a database name from the list.
    5. To test the connection between the IAS server and the computer running SQL Server, click Test Connection.

Notes

  • XOX
  • To prevent the log files from filling the hard drive on which you are storing them, it is strongly recommended that you keep them on a partition that is separate from the system partition.
  • To send the log file data for collection by another process, you can configure IAS to write to a named pipe. To use named pipes, set the log file folder to \\.\pipe or \\ComputerName\pipe. The named pipe server program creates a named pipe named \\.\pipe\iaslog.log to accept the data. In the Local file properties dialog box, in Create a new log file, select Never (unlimited file size) when you use named pipes.
  • The log file directory can be created by using system environment variables (instead of user variables), such as %systemdrive%, %systemroot%, and %windir%. For example, the following path, using the environment variable %windir%, locates the log file at the system directory in the subfolder \System32\Logs (that is, %windir%\System32\Logs\). For more information, see Related Topics.
  • Switching log file formats does not cause a new log to be created. If you change log file formats, the file that is active at the time of the change will contain a mixture of the two formats (records at the start of the log will have the previous format, and records at the end of the log will have the new format).
  • If you are administering an IAS server remotely, you cannot browse the directory structure. If you need to log accounting information to a remote server, specify the log file name by typing a Universal Naming Convention (UNC) name, such as \\MyLogServer\LogShare.
  • If you do not supply a full path statement in Log File Directory, the default path is used. For example, if you type IASLogFile in Log File Directory, the file is located at systemroot\System32\IASLogFile.

Related Topics


Concepts

This section covers:

  • IAS overview
  • Understanding IAS
  • Deploying IAS
  • Resources


IAS overview

This section covers:

  • Security information for IAS
  • Introducing IAS
  • Features of IAS
  • RADIUS protocol
  • New features for IAS
  • Differences in IAS implementations
  • How IAS works


Security information for IAS

It is important to follow best practices for security when using IAS servers on your network. For more information, see Best practices for security.

Following is security information for IAS and related protocols:

  • Deployments of PEAP and EAP unprotected by PEAP should not use the same authentication type

    When you deploy both PEAP and EAP unprotected by PEAP, do not use the same EAP authentication type with and without PEAP. For example, if you deploy PEAP with EAP-TLS (PEAP-EAP-TLS), do not also deploy EAP-TLS without PEAP. Deploying authentication methods with the same type — one with and the other without the protection of PEAP — creates a security vulnerability.

  • The RADIUS User-Password hiding mechanism might not provide sufficient security for passwords.

    The RADIUS hiding mechanism uses the RADIUS shared secret, the Request Authenticator, and the use of the MD5 hashing algorithm to encrypt the User-Password and other attributes, such as Tunnel-Password and MS-CHAP-MPPE-Keys. RFC 2865 notes the potential need for evaluating the threat environment and determining whether additional security should be used.

    You can provide additional protection for hidden attributes by using Internet Protocol Security (IPSec) with Encapsulating Security Payload (ESP) and an encryption algorithm, such as Triple DES (3DES), to provide data confidentiality for the entire RADIUS message.

    Recommendations:

    • Use IPSec to provide additional security for RADIUS clients and servers. For more information, see Securing RADIUS traffic with IPSec.
    • If you are using IPSec with ESP and an encryption algorithm is not available, do the following:
      1. Require the use of the Message Authenticator attribute for all Access-Request messages. For more information, see Message Authenticator attribute and To configure the Message Authenticator attribute and shared secret.
      2. Use cryptographically strong Request Authenticators.
      3. Require the use of strong user passwords. For more information, see Strong passwords.
      4. Use authentication counting and account lockout to help prevent a dictionary attack against a user password.
      5. Use a long shared secret with a random sequence of letters, numbers, and punctuation. Change it often to help protect your IAS server and your RADIUS clients from dictionary attacks. For more information, see Shared secrets.
  • Many authentication methods are too weak to provide adequate security for most organizations.

    • Many organizations use authentication methods that expose their network to a variety of security attacks. The most secure method of authentication is Extensible Authentication Protocol-Transport Level Security (EAP-TLS) when used in conjunction with smart cards. However, EAP-TLS and smart cards require a public key infrastructure (PKI), which can be complicated to deploy.

    Recommendations:

    • When you use password-based authentication, enforce strong password policies on your network to make dictionary attacks more difficult. For more information, see Creating strong passwords.
    • Make sure that Password Authentication Protocol (PAP), Shiva Password Authentication Protocol (SPAP), and Challenge Handshake Authentication Protocol (CHAP) are disabled. PAP, SPAP, and CHAP are disabled by default on the profile of a remote access policy.
    • Disable Microsoft Challenge Handshake Authentication Protocol (MS-CHAP). MS-CHAP is enabled by default on the profile of a remote access policy. Before you disable MS-CHAP, ensure that all of the clients of your access server are capable of using MS-CHAP version 2 (MS-CHAP v2). If your server is not running Windows Server 2003, you will need the latest service packs and dial-up networking updates in order to support MS-CHAP v2.
    • If you do not disable MS-CHAP, disable Microsoft LAN Manager authentication for MS-CHAP. LAN Manager authentication for MS-CHAP is enabled by default on clients running earlier versions of Windows.

      To disable LAN Manager authentication, set the registry value Allow LM Authentication to 0 at the following registry key:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy

      Caution

      • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.
  • Remote access account lockout can cause authorized users to be denied network access.

    If a malicious user attempts a dictionary attack with an authorized user logon name when remote access account lockout is enabled, both the malicious user and the authorized user are locked out of the account until the configured Account lockout threshold is reached.

    Recommendations:

    • Be cautious when defining account lockout policy. For more information, see password Best practices.
    • When the lockout count for a user account is reset to zero, due to either a successful authentication or an automatic reset, the registry subkey for the user account is deleted. To manually unlock a user account (before the Account lockout threshold is automatically reset), you can delete the following registry subkey that corresponds to the user's account name:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout\DomainName:UserName

    Caution

    • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer. You can also use the Last Known Good Configuration startup option if problems are encountered after manual changes have been applied.

    Notes

    • Remote access account lockout is not related to the Account locked out setting on the Account tab in the properties of a user account.
    • With remote access account lockout, there is no distinction between malicious users who attempt to access your intranet and authentic users who attempt remote access but have forgotten or repeatedly mistyped their current passwords. Depending on the number of attempts and the MaxDenials setting in the registry, these users might have their accounts locked out.
  • Moving IAS log files from the default location results in unprotected log files.

    When IAS logging is enabled, log files are located by default in the systemroot\System32\LogFiles folder. By default, the access control list on the LogFiles folder provides the best security for the IAS log files. The access control list is a list of users and groups that can access the folder. In addition, each user or group is assigned specific permissions that determine what actions the user or group can take with the folder. For more information, see Access control.

    If you change the location of the IAS log files, however, the new folder location is not protected with the usual access control list by default. This creates a security risk.

    Recommendations:

    • If you move the IAS log files to another folder, create an access control list that contains only the Local System account and the Administrators group. In addition, ensure that the new log file folder does not inherit permissions from any other folder.
    • Do not store IAS log files in any personal folders, in My Documents, or in any subfolder of My Documents.
    • Store IAS log files on a computer that is physically secured and protected from unauthorized access.
    • Use file-level auditing for individual IAS log files to track the users and groups that access them. For more information, see To apply or modify auditing policy settings for a local file or folder.
    • Do not move or map the IAS log files to a remote storage device or an external drive for which no access control list can be created. Also do not move or copy IAS log files to an anonymous FTP site or any other unprotected location.
  • IAS server log data is sent in plaintext to remote computers running SQL server

    If your IAS server is configured to log user authentication and accounting requests to a remote computer running SQL Server, the log data is sent unencrypted over the network, posing a high security risk.

    Recommendations:

    • Establish an encrypted connection at the computer running SQL Server for communication with the IAS server. For more information, see the SQL Server documentation.

    For more information about logging IAS data to a SQL Server database, see SQL Server database logging and To configure log file properties.

For additional information about security considerations and best practices, consult the following resources:

  • Securing IAS
  • IAS as a RADIUS server security considerations
  • Best practices
  • IAS as a RADIUS proxy security considerations
  • Remote access logging
  • Event Viewer
  • Security information for VPN
  • Security information for remote access
  • Security information for routing

Note

  • XOX


Introducing IAS

Internet Authentication Service (IAS) in XOX; XOX; and XOX is the Microsoft implementation of a Remote Authentication Dial-In User Service (RADIUS) server and proxy. As a RADIUS server, IAS performs centralized connection authentication, authorization, and accounting for many types of network access, including wireless, authenticating switch, dial-up and virtual private network (VPN) remote access, and router-to-router connections. As a RADIUS proxy, IAS forwards authentication and accounting messages to other RADIUS servers. IAS supports the Internet Engineering Task Force (IETF) standards for RADIUS described in RFCs 2865 and 2866.

IAS enables the use of a heterogeneous set of wireless, switch, remote access, or VPN equipment. You can use IAS with the Routing and Remote Access service, which is available in Microsoft Windows 2000, XOX; XOX; and XOX.

When an IAS server is a member of an Active Directory® domain, IAS uses the directory service as its user account database and is part of a single sign-on solution. The same set of credentials is used for network access control (authenticating and authorizing access to a network) and to log on to an Active Directory domain.

Internet service providers (ISPs) and organizations that maintain network access have the increased challenge of managing all types of network access from a single point of administration, regardless of the type of network access equipment used. The RADIUS standard supports this functionality in both homogeneous and heterogeneous environments. RADIUS is a client-server protocol that enables network access equipment (used as RADIUS clients) to submit authentication and accounting requests to a RADIUS server.

A RADIUS server has access to user account information and can check network access authentication credentials. If the user's credentials are authentic and the connection attempt is authorized, the RADIUS server authorizes the user's access on the basis of specified conditions and logs the network access connection in an accounting log. The use of RADIUS allows the network access user authentication, authorization, and accounting data to be collected and maintained in a central location, rather than on each access server.

With IAS, organizations can also outsource remote access infrastructure to a service provider while retaining control over user authentication, authorization, and accounting.

Different IAS configurations can be created for the following solutions:

  • Wireless access
  • Organization dial-up or virtual private network (VPN) remote access
  • Outsourced dial-up or wireless access
  • Internet access
  • Authenticated access to extranet resources for business partners

Note

  • XOX


Features of IAS

IAS includes support for the following features:

  • A variety of authentication methods

    • IAS supports a number of authentication protocols and allows you to add custom methods that meet your authentication requirements. The supported authentication methods are:

    • Password-based Point-to-Point Protocol (PPP) authentication protocols

      • Password-based PPP authentication protocols, such as Password Authentication Protocol (PAP), Challenge Handshake Authentication Protocol (CHAP), Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), and MS-CHAP version 2 (MS-CHAP v2), are supported. For more information, see Authentication methods.

    • Extensible Authentication Protocol (EAP)

      • An Internet standards-based infrastructure that allows the addition of arbitrary authentication methods, such as smart cards, certificates, one-time passwords, and token cards. A specific authentication method that uses the EAP infrastructure is an EAP type. IAS includes support for EAP-Message Digest 5 (MD5) and EAP-Transport Level Security (EAP-TLS). For more information, see EAP.

  • A variety of authorization methods

    • IAS supports a number of authorization methods and allows you to add custom methods that meet your authorization requirements. The supported authorization methods are:

    • Dialed Number Identification Service (DNIS)

      • The authorization of a connection attempt that is based on the number called. DNIS supplies the number that was called to the call receiver and is provided by most standard telephone companies.

    • Automatic Number Identification/Calling Line Identification (ANI/CLI)

      • The authorization of a connection attempt that is based on the phone number of the caller. ANI/CLI service supplies the number of the caller to the call receiver and is provided by most standard telephone companies.

    • Guest authorization

      • The use of the Guest account as the identity of the user when the connection is made without user credentials (user name and password).

    For more information, see Unauthenticated access.

  • Heterogeneous access servers

    • IAS supports access servers that support RADIUS RFCs 2865 and 2866. In addition to dial-up access servers (also known as network access servers), IAS also supports the following:

    • Wireless access points

      • By using remote access policies and the Wireless-IEEE 802.11 port type condition, IAS can be used as a RADIUS server for wireless access points that use RADIUS for authentication and authorization of wireless nodes. For more information, see New features.

    • Authenticating switches

      • By using remote access policies and the Ethernet port type condition, IAS can be used as a RADIUS server for Ethernet network switches that use RADIUS for authentication and authorization of switch nodes. For more information, see New features.

    • Integration with the Routing and Remote Access service

      • Both IAS and the Routing and Remote Access service share remote access policies and log file capabilities. This integration provides a consistent implementation for both IAS and the Routing and Remote Access service. It enables you to deploy Routing and Remote Access in small sites without the requirement of a separate, centralized IAS server. It also provides the ability to scale to a centralized remote access management model, whenever you have multiple Routing and Remote Access servers in your organization. IAS, in conjunction with Routing and Remote Access servers, implements a single point of administration for remote access to your network for outsourced-dial, demand-dial, and VPN access. The policies within IAS at a central and large site can be exported to the independent Routing and Remote Access server in a small site.

  • RADIUS proxy

    • IAS allows an incoming RADIUS request to be forwarded to another RADIUS server for the processing of authentication and authorization, or accounting. As a RADIUS proxy, IAS can be used whenever the RADIUS request must be routed to another RADIUS server. IAS can forward requests based on user name, access server IP address, access server identifier, and other conditions. For more information, see New features.

  • Outsourced dial-up and wireless network access

    • Outsourced dialing (also known as wholesale dialing) provides a contract between an organization (the customer) and an Internet service provider (ISP). The ISP allows organization employees to connect to its network before the VPN tunnel to the organization’s private network is established. When an organization employee connects to the ISP's NAS, the authentication and usage records are forwarded to the IAS server at the organization. The IAS server enables the organization to control user authentication, track usage, and determine which employees are allowed to access the ISP's network.

    The advantage of outsourced dialing is the potential savings. By using an ISP's routers, network access servers, and wide area network (WAN) links instead of purchasing your own, you might save a great deal on hardware (infrastructure) costs. By dialing into the ISP with worldwide connections, you might significantly decrease your long-distance phone bill. And, by moving support requirements to the provider, you might eliminate administrative costs.

    You can also outsource wireless access. A vendor can provide wireless access in a remote location and use your user name to forward the connection request to a RADIUS server that is under your control for authentication and authorization. A good example is wireless Internet access in an airport.

  • Centralized user authentication and authorization

    • To authenticate a connection request, IAS validates the connection credentials against user accounts in the local Security Accounts Manager (SAM), a Microsoft® Windows NT® Server 4.0 domain, or an Active Directory® domain. For an Active Directory domain, IAS supports the use of Active Directory user principal names (UPNs) and universal groups.

    To authorize a connection request, IAS uses the dial-in properties of the user account that correspond to both the connection credentials and remote access policies. Although it is relatively easy to manage remote access permission for each user account, this approach does not scale well as an organization grows. Remote access policies provide a more powerful and flexible way to manage remote access permission. You can authorize network access based on various conditions, including:

    • User account membership in a group.
    • The time of day or day of the week.
    • The type of media through which the user is connecting (for example, wireless, Ethernet switch, modem, or VPN).
    • The phone number that the user calls.
    • The access server from which the request arrives.

    By configuring profile settings on remote access policies, you can control many connection parameters, including:

    • The use of specific authentication methods.
    • The idle timeout.
    • The maximum time of a single session.
    • The number of links in a multilink session.
    • The use of encryption and its strength.
    • The use of packet filters to control what the remote access user can access when connected to the network. For example, you can use filters to control which IP addresses, hosts, and ports the user is allowed to use in sending or receiving packets.
    • The creation of a compulsory tunnel that forces all packets from that connection to be securely tunneled through the Internet and terminated in a private network.
    • The virtual local area network identifier (VLAN ID) for wireless or Ethernet connections.
  • Centralized administration for all of your access servers

    • Support for the RADIUS standard allows IAS to control connection parameters for any access server that implements RADIUS. The RADIUS standard also allows individual remote access vendors to create proprietary extensions called vendor-specific attributes (VSAs). IAS has incorporated the extensions from a number of vendors in its dictionary. Additional VSAs can be added to the profile of individual remote access policies. For more information, see Vendor-specific attribute overview.

  • Centralized auditing and usage accounting

    • Support for the RADIUS standard allows IAS to collect, at a central location, the usage (accounting) records sent by all access servers. IAS stores audit information (for example, authentication accepts and rejects) and usage information (for example, connect and disconnect records) in log files. IAS supports a log file format that can be directly imported into a database. The data can then be analyzed with any standard data analysis application. For more information, see Logging user authentication and accounting requests.

  • Snap-in-based management tool

    • IAS provides an administration tool named the Internet Authentication Service snap-in. You can run Internet Authentication Service from Administrative Tools to administer IAS on a local computer. Or, you can add the Internet Authentication Service snap-in to the Microsoft Management Console (MMC) to administer IAS running on either a local computer or a remote computer.

  • Local or remote monitoring with tools provided in XOX; XOX; and XOX

    • You can monitor IAS locally or on a remote computer with tools provided in XOX; XOX; and XOX, including Event Viewer, System Monitor, and Simple Network Management Protocol (SNMP). You can also use Network Monitor to capture RADIUS messages for detailed traffic analysis and troubleshooting.

  • Scalability

    • You can use IAS in a variety of network configurations of varying size, from stand-alone servers for small networks to large organization and ISP networks.

  • Support for multiple IAS servers

    • The synchronization of the configuration of multiple IAS servers can be performed with the Netsh command-line tool. For more information see To copy the IAS configuration to another server.

  • Extensibility

    • The Windows Server 2003 Platform Software Development Kit (SDK) contains two smaller networking SDKs—the IAS SDK and the EAP SDK.

    You can use the IAS SDK to:

    • Return custom attributes to the access server in addition to those returned by IAS. For example, you can create a customized module to assign IP addresses.
    • Control the number of user network sessions.
    • Import usage and audit data directly into an Open Database Connectivity (ODBC)-compliant database.
    • Create customized authorization modules.
    • Create customized authentication modules (non-EAP).

    You can use the EAP SDK to create EAP types. For more information, see EAP.

Note

  • XOX


RADIUS protocol

Remote Authentication Dial-In User Service (RADIUS) is an industry standard protocol described in RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)," and RFC 2866, "RADIUS Accounting." RADIUS is used to provide authentication, authorization, and accounting services. A RADIUS client (typically a dial-up server, VPN server, or wireless access point) sends user credentials and connection parameter information in the form of a RADIUS message to a RADIUS server. The RADIUS server authenticates and authorizes the RADIUS client request, and sends back a RADIUS message response. RADIUS clients also send RADIUS accounting messages to RADIUS servers. Additionally, the RADIUS standards support the use of RADIUS proxies. A RADIUS proxy is a computer that forwards RADIUS messages between RADIUS-enabled computers.

RADIUS messages are sent as User Datagram Protocol (UDP) messages. UDP port 1812 is used for RADIUS authentication messages and UDP port 1813 is used for RADIUS accounting messages. Some network access servers might use UDP port 1645 for RADIUS authentication messages and UDP port 1646 for RADIUS accounting messages. By default, IAS supports receiving RADIUS messages destined to both sets of UDP ports. For information about changing the UDP ports that are used by IAS, see To configure IAS port information. Only one RADIUS message is included in the UDP payload of a RADIUS packet.

RFCs 2865 and 2866 define the following RADIUS message types:

  • Access-Request

    • Sent by a RADIUS client to request authentication and authorization for a connection attempt.

  • Access-Accept

    • Sent by a RADIUS server in response to an Access-Request message. This message informs the RADIUS client that the connection attempt is authenticated and authorized.

  • Access-Reject

    • Sent by a RADIUS server in response to an Access-Request message. This message informs the RADIUS client that the connection attempt is rejected. A RADIUS server sends this message if either the credentials are not authentic or the connection attempt is not authorized.

  • Access-Challenge

    • Sent by a RADIUS server in response to an Access-Request message. This message is a challenge to the RADIUS client that requires a response.

  • Accounting-Request

    • Sent by a RADIUS client to specify accounting information for a connection that was accepted.

  • Accounting-Response

    • Sent by the RADIUS server in response to the Accounting-Request message. This message acknowledges the successful receipt and processing of the Accounting-Request message.

A RADIUS message consists of a RADIUS header and zero or more RADIUS attributes. Each RADIUS attribute specifies a piece of information about the connection attempt. For example, there are RADIUS attributes for the user name, the user password, the type of service requested by the user, and the IP address of the access server. RADIUS attributes are used to convey information between RADIUS clients, RADIUS proxies, and RADIUS servers. For example, the list of attributes in the Access-Request message includes information about the user credentials and the parameters of the connection attempt. In contrast, the Access-Accept message includes information about the type of connection that can be made, connection constraints, and any vendor-specific attributes (VSAs).

Note

  • XOX


New features for IAS

The following are new features for IAS in XOX; XOX; and XOX:

  • Support for RADIUS proxy
  • Support for mapping network authentication and authorization for IAS proxy
  • Support for IEEE 802.1x wireless and authenticating switches
  • Support for Protected Extensible Authentication Protocol (PEAP) for 802.11 wireless clients
  • Enhanced EAP configuration for remote access policies
  • Support for IAS Network Access Quarantine Control
  • Support for logging to an XML-compliant SQL Server database
  • Ignoring the dial-in properties of user accounts
  • Support for configuring RADIUS clients by IP address range
  • Support for computer authentication
  • Support for checking user certificate purposes
  • Improved attribute manipulation
  • Support for the Authentication Type remote access policy condition
  • Improved support for the Class attribute

Note

  • XOX

Support for RADIUS proxy

XOX; XOX; and XOX include RADIUS proxy support in addition to RADIUS server support. With RADIUS proxy support, you can use IAS as a RADIUS message router or forwarder. Based on attributes in the incoming RADIUS message, the RADIUS proxy forwards the message to a specific RADIUS server or client.

IAS implements RADIUS proxy support through connection request processing and remote RADIUS server groups. Connection request processing is a set of rules that determine how an incoming connection request is processed: It is either authenticated and authorized by the IAS server (when the IAS server is being used as a RADIUS server), or it is forwarded to another RADIUS server for authentication and authorization (when the IAS server is being used as a RADIUS proxy). When IAS is being used as a proxy, it forwards the connection request to a member of a remote RADIUS server group.

By correctly configuring connection request processing rules and remote RADIUS server groups, an IAS server can be used as a RADIUS server for some requests and a RADIUS proxy for others. The IAS proxy also provides the ability to balance RADIUS requests across multiple RADIUS servers, to detect both which RADIUS servers are no longer available and when they become available again. For more information about how RADIUS proxies are used and when to use IAS as a RADIUS proxy, see IAS as a RADIUS proxy.

For more information about configuring IAS as a RADIUS proxy, see Deploying IAS as a RADIUS proxy and Checklist: Configuring IAS to forward requests.

Support for mapping network authentication and authorization for IAS proxy

The proxy component of IAS supports the ability to separate the authentication and authorization of connection requests from access servers. The IAS proxy can forward password-based user credentials to an external RADIUS server for authentication, and perform authorization against a user account in an Active Directory® domain and a locally configured remote access policy. Alternate user authentication databases can be used but connection authorization and restrictions are still determined through local administration.

For example, a visitor from a partner company can be authenticated by using the partner company RADIUS server and user database. Authorization to access your network is accomplished based on connection request policy settings on your IAS server and a Windows account user database in an Active Directory domain that is established for visitor accounts.

You can configure the proxy component with the Remote-RADIUS-to-Windows-User-Mapping attribute in the advanced properties of a connection request policy.

For more information, see Mapping network authentication and authorization and Connection request policies.

Support for IEEE 802.1x wireless and authenticating switches

IAS provides authentication, authorization, and accounting for connections that use the link-layer standard IEEE 802.1x for wireless and switch access.

Wireless access point support

Wireless networking technology has become more widely used since the adoption of wireless industry standards such as IEEE 802.11 and 802.11b. You can use wireless networking to roam within a building or area and connect automatically to a network when you are in the vicinity of a wireless access point.

While providing convenience, wireless networking technologies and wireless access points have the following security risks:

  • Anyone who has a compatible wireless network adapter can gain access to the network.
  • Wireless networking signals use radio waves to send and receive information. Anyone within an appropriate distance to a wireless access point can detect and receive all data sent to and from the wireless access point.

To counter the first security risk, wireless access points must require authentication and authorization of the wireless node before data can be sent to and received from the network that is attached to the wireless access point. To provide their own authentication and authorization, each wireless access point should require a user account database with each user's authentication credentials and a set of rules by which authorization is granted. Because this is difficult to manage, some wireless access points are RADIUS clients that use the industry standard RADIUS protocol to send connection request and accounting messages to a central RADIUS server. The RADIUS server has access to a user account database and a set of rules for granting authorization. The RADIUS server processes the wireless access point's connection request and either accepts or rejects the connection request.

To counter the second security risk, the data sent between the wireless nodes and the wireless access points must be encrypted. Because of this, the authentication method that is used by the wireless node must allow for the determination of encryption keys that are used to encrypt data.

IAS supports wireless access authentication through the following:

  • The use of Extensible Authentication Protocol-Transport Level Security (EAP-TLS) to provide certificate-based authentication and the management of encryption keys that are used to encrypt data sent between wireless access points and wireless nodes.
  • The use of the Wireless-IEEE 802.11 port types when configuring the NAS-Port-Type condition of remote access policies.

    • By using these port types, you can create a separate remote access policy that contains connection parameters and encryption settings that are specifically designed for wireless nodes.

  • By providing a means to grant guest access for a wireless client that does not have a certificate installed.

For more information about configuring IAS for wireless access authentication, see Checklist: Configuring the IAS server and wireless access points for wireless access and Wireless access.

For an example of a remote access policy for wireless clients, see Wireless access example.

Authenticating switch support

Network switches are a commonly used technology. A network switch provides selective filtering of the traffic received on each port of the switch and allows better traffic management by segmenting a network. A typical switch, however, sends and receives packets to any node that is connected to the switch. This can be a problem for switch ports in a conference room within an organization. A person from another organization can simply connect their network adapter to the switch port and gain instant access to the network.

To prevent physical layer access to the network, newer switches can be configured to require switch node authentication and authorization before data can be sent to and received from the network that is attached to the switch. To provide their own authentication and authorization, each switch is required to have a user account database with each user's authentication credentials and a set of rules by which authorization is granted. Because this is difficult to manage, newer switches can be RADIUS clients, using the industry standard RADIUS protocol to send connection request and accounting messages to a central RADIUS server. The RADIUS server has access to a user account database and a set of rules for granting authorization. The RADIUS server processes the switch's connection request and either grants the connection request or rejects it.

As the data sent to and from the switch node travels on the wire between the switch node and the switch, encryption of the sent data is neither required nor typically implemented.

IAS supports switch access authentication through the following:

  • EAP-TLS is used to provide computer or user certificate-based authentication.
  • The Ethernet port type is used when configuring the NAS-Port-Type condition of remote access policies. By using this port type, you can create a separate remote access policy containing connection parameters that are specifically designed for switch nodes.
  • Virtual local area network (VLAN) switching is used on the basis of whether or not the switch access client is authenticated.

For more information about configuring IAS for switch access authentication, see Checklist: Configuring the IAS server for authenticated switch access and Ethernet switch access.

Support for Protected Extensible Authentication Protocol (PEAP) for 802.11 wireless clients

Protected Extensible Authentication Protocol (PEAP) provides protection for clients and authenticators (IAS or RADIUS servers) that are using EAP. The next generation of EAP, PEAP uses Transport Level Security (TLS) to create end-to-end communication between client and authenticator after the identity of the authenticator is verified.

PEAP creates a session key that is used to derive keys for the encryption of data traffic between the wireless client and the wireless access point. It also provides smooth and efficient roaming between wireless access points that are configured as RADIUS clients on the same IAS server. You can use PEAP with two different authentication types: EAP-MS-CHAPv2 or EAP-TLS. PEAP with EAP-MS-CHAPv2 (also known as PEAP-EAP-MS-CHAPv2), provides secure password authentication for wireless and authenticated switch clients. PEAP-EAP-MS-CHAPv2 can be used to complement the security of MS-CHAPv2 and does not require deployment of user or computer certificates. You can also use PEAP with EAP-TLS (also known as PEAP-EAP-TLS), which provides strong security through a public key infrastructure (PKI) with certificates, which is used for server authentication, and either smart cards or certificates for client and user authentication. When you use PEAP-EAP-TLS, client certificate information is encrypted, providing improved security over the use of EAP-TLS without PEAP.

The following table shows the strengths of PEAP-EAP-MS-CHAPv2 and how it compares to MS-CHAPv2:

Feature/function | MS-CHAPv2 | PEAP-EAP-MS-CHAPv2
Provides client authentication using passwords | Yes | Yes
Ensures that the server has access to credentials | Yes | Yes
Authenticates the server | No | Yes
Prevents wireless access point spoofing | No | Yes
Prevents an unauthorized server from negotiating the least secure authentication method | No | Yes
Uses TLS keys generated with a public key | No | Yes
Provides end-to-end encryption | No | Yes
Prevents dictionary or brute force attacks | No | Yes
Prevents replay | No | Yes
Allows chaining of authentication methods | No | Yes
Requires client trust of certificates provided by the server | No | Yes

For more information, see PEAP.

Enhanced EAP configuration for remote access policies

In Microsoft Windows 2000 Server, you can select only a single EAP type for a remote access policy. All connections matching the conditions of the policy must use this single EAP type, which is selected in the policy profile settings. Additionally, the configuration of an EAP type is global for all of the remote access policies configured on the IAS server. This can cause problems when you want to either individually configure the properties for EAP types for each policy or select multiple EAP types by group or for a specific kind of network connection.

In XOX; XOX; and XOX; these limitations are removed for IAS. For example, you can select different computer certificates for VPN connections and EAP-TLS authentication for wireless connections, or you can select multiple EAP types for wireless connections in the circumstance where some of your wireless clients use EAP-TLS authentication and some of them use PEAP with EAP-MS-CHAPv2.

For more information, see To configure PEAP and EAP methods, PEAP, and EAP.

Support for IAS Network Access Quarantine Control

IAS Network Access Quarantine Control provides phased network access, which restricts the access of remote clients to quarantine mode until each client is either verified as meeting or configured according to organization network access policy. After the client computer configuration is verified as meeting organization network policy, the quarantine restrictions, which consist of Quarantine IP-Filters and Session Timers, are removed and standard remote access policy is applied to the connection.

For more information, see IAS Network Access Quarantine Control.

Support for logging to an XML-compliant SQL Server database

You can use an XML-compliant database, such as Microsoft SQL Server™ 2000, to log user authentication and accounting requests, which are received from one or more access servers, to a central data source. Log data is passed from IAS to a procedure stored in a database that supports both structured query language (SQL) and extensible markup language (XML).

For more information, see SQL Server database logging.

Ignoring the dial-in properties of user accounts

You can configure a RADIUS attribute on the profile properties of a remote access policy to ignore the dial-in properties of user accounts. The dial-in properties of the user account contain the following:

  • Remote access permission
  • Caller-ID
  • Callback options
  • Static IP address
  • Static routes

To support multiple types of connections for which IAS provides authentication and authorization, it might be necessary to disable the processing of user account dial-in properties. This can be done to support scenarios in which specific dial-in properties are not required.

For example, the caller-ID, callback, static IP address, and static routes properties are designed for a client that is dialing into a network access server (NAS), not for wireless access points. A wireless access point that receives these settings in a RADIUS message might not be able to process them, which could cause the wireless client to be disconnected. When IAS provides authentication and authorization for users who are both dialing in and accessing the organization network through wireless technology, the dial-in properties must be configured to support either dial-in connections (by setting dial-in properties) or wireless connections (by not setting dial-in properties).

You can use IAS to enable dial-in properties processing for the user account in some scenarios (such as dial-in) and to disable dial-in properties processing for user account dial-in properties in other scenarios (such as wireless and authenticating switch). This is accomplished by configuring the Ignore-User-Dialin-Properties attribute on the Advanced tab of the profile settings for a remote access policy. For more information, see To add RADIUS attributes to a remote access policy.

The Ignore-User-Dialin-Properties attribute is set to the following:

  • To enable user account dial-in properties processing, delete the Ignore-User-Dialin-Properties attribute or set it to False. For example, for a remote access policy that is designed for dial-in connections, no additional configuration is required.
  • To disable user account dial-in properties processing, set the Ignore-User-Dialin-Properties attribute to the value of True. For example, this is set for the remote access policy that is designed for wireless or authenticating switch connections. When the dial-in properties of the user account are ignored, remote access permission is determined by the remote access permission setting in the remote access policy.

You can also use this attribute to manage network access control through groups and the remote access permission on the remote access policy. By setting the Ignore-User-Dialin-Properties attribute to the value of True, the remote access permission on the user account is ignored. The disadvantage to using the Ignore-User-Dialin-Properties attribute in this way is that you cannot use the additional dial-in properties of caller-ID, callback, static IP address, and static routes.

For more information about setting advanced attributes, see To add RADIUS attributes to a remote access policy.

Note

  • The Ignore-User-Dialin-Properties attribute disables the use of all dial-in properties for the user account. Specific dial-in properties cannot be selectively disabled.

Support for configuring RADIUS clients by IP address range

For IAS in Windows 2000, you must specify a RADIUS client by IP address or by Domain Name System (DNS) name. In addition, you must configure each RADIUS client separately, even if you have a number of RADIUS clients on the same subnet. While this is not an issue for typical dial-in or VPN access server configurations, numerous wireless access points can be placed on the same subnet. To simplify administration of RADIUS clients for this type of network configuration, IAS in XOX and XOX allows you to specify a RADIUS client by using an address range. All of the RADIUS clients in the range must use the same configuration and shared secret.

The address range for RADIUS clients is expressed in the network prefix length notation w.x.y.z/p, where w.x.y.z is the dotted decimal notation of the address prefix and p is the prefix length (the number of high order bits that define the network prefix). This is also known as Classless Inter-Domain Routing (CIDR) notation. An example is 192.168.21.0/24. To convert from subnet mask notation to network prefix length notation, p is the number of high order bits set to one in the subnet mask.

For more information, see Configure RADIUS clients.

Support for computer authentication

Active Directory and IAS in XOX; XOX; and XOX support the authentication of computer accounts by using standard user authentication methods such as Point-to-Point Protocol (PPP). This allows a computer and its computer certificate to be authenticated for wireless or authenticating switch access clients.

Support for checking user certificate purposes

To enforce the use of specific types of user certificates for specific connection types, you can configure IAS to check the purposes (also known as object identifiers or OIDs) of certificates in their Enhanced Key Usage (EKU) extensions. When EAP-TLS is used, the access client can send a smart card certificate or a user certificate from the client computer certificate store during the authentication process. Because smart card certificates are more secure than certificates from the client computer certificate store, you might want to ensure that remote access VPN connections use a smart card certificate for user authentication instead of a locally-installed user certificate. In this case, you can configure a remote access policy to require that the user certificate EKU extensions contain the Smart Card Logon purpose (the object identifier is 1.3.6.1.4.1.311.20.2.2). When the VPN client offers the smart card certificate for user authentication, the IAS server checks the EKU extensions according to remote access policy. Because the Smart Card Logon purpose is present in the VPN client certificate, authentication succeeds. For more information, see Network access authentication and certificates.

You can configure a list of object identifiers that are required to be present in the user certificate (which is offered by the access client). To do this, use the Allow certificates with these OIDs attribute on the Advanced tab in the properties of a remote access policy profile. No required object identifiers are specified by default. For more information, see To add RADIUS attributes to a remote access policy.

Improved attribute manipulation

In Windows 2000, you can use IAS to manipulate the contents of the User-Name RADIUS attribute. Using connection request policies in IAS for XOX; XOX; and XOX; you can manipulate the User-Name, Called-Station-ID, and Calling-Station-ID RADIUS attributes. For more information, see Connection request policies.

Support for the Authentication Type remote access policy condition

In IAS for XOX; XOX; and XOX; you can create remote access policies by using the Authentication Type condition. You can use it to specify connection constraints that are based on the authentication protocol or method that is used by the access client. For more information, see Elements of a remote access policy.

Improved support for the Class attribute

In Windows 2000, IAS automatically generates a value for the Class attribute and appends it to the existing value of the Class attribute received in the RADIUS request message. The result is the Class attribute in the RADIUS response message. In XOX; XOX; and XOX:

  1. You can disable the automatic generation of a value for the Class attribute by using Generate-Class-Attribute on the Advanced tab in the properties of a remote access policy profile. Automatic generation of a value for the Class attribute is disabled by default. For more information, see To add RADIUS attributes to a remote access policy.
  2. Instead of appending the generated value of the Class attribute to the existing Class attribute, IAS creates a separate Class attribute. The RADIUS response message contains both the original Class attribute and the second Class attribute that is generated by IAS.


Differences in IAS implementations

A previous version of IAS was released with the Microsoft® Windows NT® 4.0 Option Pack. The following table describes the differences between this version and the one available in XOX; XOX; and XOX.

Windows NT 4.0 IAS | XOX; XOX; or XOX IAS
If a domain name is not specified during authentication, the IAS server authenticates the user against only the local SAM database. IAS resolves a user name without a specified domain name by using the following sequence:
  1. IAS determines a default domain from the registry, if one is specified.
  2. If the IAS server is a member of a domain, IAS authenticates the user against that domain.
  3. If the IAS server is not a member of a domain, IAS authenticates the user against the local SAM database.
IAS does not use callback permissions for all user objects. | IAS uses callback permissions for all user objects.
IAS log files are written in ASCII. | IAS log files are multilanguage and are written in UTF-8.

Note

  • XOX


How IAS works

This section covers:

  • IAS as a RADIUS server
  • IAS as a RADIUS proxy

Note

  • XOX


IAS as a RADIUS server

Internet Authentication Service (IAS) can be used as a RADIUS server to perform authentication, authorization, and accounting for RADIUS clients. A RADIUS client can be either an access server or a RADIUS proxy. When Internet Authentication Service (IAS) is used as a RADIUS server, it provides the following:

  • A central authentication and authorization service for all access requests that are sent by RADIUS clients.

    • IAS uses either a Microsoft® Windows NT® Server 4.0 domain, an Active Directory® domain, or the local Security Accounts Manager (SAM) to authenticate user credentials for a connection attempt. IAS uses the dial-in properties of the user account and remote access policies to authorize a connection.

  • A central accounting recording service for all accounting requests that are sent by RADIUS clients.

    • Accounting requests are stored in a local log file for analysis.

The following illustration shows IAS as a RADIUS server for a variety of access clients and a RADIUS proxy. IAS uses an Active Directory domain for user credential authentication of incoming RADIUS Access-Request messages.

IAS as a RADIUS server

When IAS is used as a RADIUS server, RADIUS messages provide authentication, authorization, and accounting for network access connections in the following way:

  1. Access servers, such as dial-up network access servers, VPN servers, and wireless access points, receive connection requests from access clients.
  2. The access server, configured to use RADIUS as the authentication, authorization, and accounting protocol, creates an Access-Request message and sends it to the IAS server.
  3. The IAS server evaluates the Access-Request message.
  4. If required, the IAS server sends an Access-Challenge message to the access server. The access server processes the challenge and sends an updated Access-Request to the IAS server.
  5. The user credentials are checked and the dial-in properties of the user account are obtained by using a secure connection to a domain controller.
  6. The connection attempt is authorized with both the dial-in properties of the user account and remote access policies.
  7. If the connection attempt is both authenticated and authorized, the IAS server sends an Access-Accept message to the access server.

    8. If the connection attempt is either not authenticated or not authorized, the IAS server sends an Access-Reject message to the access server.

  8. The access server completes the connection process with the access client and sends an Accounting-Request message to the IAS server, where the message is logged.
  9. The IAS server sends an Accounting-Response to the access server.

Notes

  • The access server also sends Accounting-Request messages for the following:
    • During the time in which the connection is established.
    • When the access client connection is closed.
    • When the access server is started and stopped.

You can use IAS as a RADIUS server when:

  • You are using a Windows NT Server 4.0 domain, an Active Directory domain, or the local Security Accounts Manager (SAM) as your user account database for access clients.
  • You are using the XOX; XOX; XOX; or Windows 2000 Routing and Remote Access service on multiple dial-up servers, VPN servers, or demand-dial routers and you want to centralize both the configuration of remote access policies and connection logging for accounting.
  • You are outsourcing your dial-in, VPN, or wireless access to a service provider. The access servers use RADIUS to authenticate and authorize connections that are made by members of your organization.
  • You want to centralize authentication, authorization, and accounting for a heterogeneous set of access servers.

For more information, see Deploying IAS as a RADIUS server.

Note

  • XOX


IAS as a RADIUS proxy

Internet Authentication Service (IAS) can be used as a RADIUS proxy to provide the routing of RADIUS messages between RADIUS clients (access servers) and RADIUS servers that perform user authentication, authorization, and accounting for the connection attempt. When used as a RADIUS proxy, IAS is a central switching or routing point through which RADIUS access and accounting messages flow. IAS records information in an accounting log about the messages that are forwarded.

The following illustration shows IAS as a RADIUS proxy between RADIUS clients (access servers) and either RADIUS servers or another RADIUS proxy.

IAS as a RADIUS proxy

When IAS is used as a RADIUS proxy between a RADIUS client and a RADIUS server, RADIUS messages for network access connection attempts are forwarded in the following way:

  1. Access servers, such as dial-up network access servers, VPN servers, and wireless access points, receive connection requests from access clients.
  2. The access server, configured to use RADIUS as the authentication, authorization, and accounting protocol, creates an Access-Request message and sends it to the IAS server that is being used as the IAS RADIUS proxy.
  3. The IAS RADIUS proxy receives the Access-Request message and, based on the locally configured connection request policies, determines where to forward the Access-Request message.
  4. The IAS RADIUS proxy forwards the Access-Request message to the appropriate RADIUS server.
  5. The RADIUS server evaluates the Access-Request message.
  6. If required, the RADIUS server sends an Access-Challenge message to the IAS RADIUS proxy, where it is forwarded to the access server. The access server processes the challenge with the access client and sends an updated Access-Request to the IAS RADIUS proxy, where it is forwarded to the RADIUS server.
  7. The RADIUS server authenticates and authorizes the connection attempt.
  8. If the connection attempt is both authenticated and authorized, the RADIUS server sends an Access-Accept message to the IAS RADIUS proxy, where it is forwarded to the access server.

    9. If the connection attempt is either not authenticated or not authorized, the RADIUS server sends an Access-Reject message to the IAS RADIUS proxy, where it is forwarded to the access server.

  9. The access server completes the connection process with the access client and sends an Accounting-Request message to the IAS RADIUS proxy. The IAS RADIUS proxy logs the accounting data and forwards the message to the RADIUS server.
  10. The RADIUS server sends an Accounting-Response to the IAS RADIUS proxy, where it is forwarded to the access server.

You can use IAS as a RADIUS proxy when:

  • You are a service provider that offers outsourced dial, virtual private network (VPN), or wireless network access services to multiple customers. Your network access servers send connection requests to the IAS RADIUS proxy. Based on the realm portion of the user name in the connection request, the IAS RADIUS proxy forwards the connection request to a RADIUS server that is maintained by the customer and can authenticate and authorize the connection attempt. For more information, see Realm names.
  • You want to provide authentication and authorization for user accounts that are not members of either the domain in which the IAS server is a member or another domain that has a two-way trust with the domain in which the IAS server is a member. This includes accounts in untrusted domains, one-way trusted domains, and other forests. Instead of configuring your access servers to send their connection requests to an IAS RADIUS server, you can configure them to send their connection requests to an IAS RADIUS proxy. The IAS RADIUS proxy uses the realm name portion of the user name and forwards the request to an IAS server in the correct domain or forest. Connection attempts for user accounts in one domain or forest can be authenticated for network access servers in another domain or forest.

    • IAS supports authentication across forests without a RADIUS proxy when the two forests contain only domains that consist of domain controllers running XOX; XOX; and XOX. The forest functional level must be Windows Server 2003, and there must be a two-way trust relationship between forests. If you use EAP-TLS with certificates as your authentication method, however, you must use a RADIUS proxy for authentication across forests that consist of Windows Server 2003 domains.

  • You want to perform authentication and authorization by using a database that is not a Windows account database. In this case, connection requests that match a specified realm name are forwarded to a RADIUS server, which has access to a different database of user accounts and authorization data. Examples of other user databases include Novell Directory Services (NDS) and Structured Query Language (SQL) databases.
  • You want to process a large number of connection requests. In this case, instead of configuring your RADIUS clients to attempt to balance their connection and accounting requests across multiple RADIUS servers, you can configure them to send their connection and accounting requests to an IAS RADIUS proxy. The IAS RADIUS proxy dynamically balances the load of connection and accounting requests across multiple RADIUS servers and increases the processing of large numbers of RADIUS clients and authentications per second.
  • You want to provide RADIUS authentication and authorization for outsourced service providers and minimize intranet firewall configuration. An intranet firewall is between your perimeter network (the network between your intranet and the Internet) and intranet. By placing an IAS server on your perimeter network, the firewall between your perimeter network and intranet must allow traffic to flow between the IAS server and multiple domain controllers. When replacing the IAS server with an IAS proxy, the firewall must allow only RADIUS traffic to flow between the IAS proxy and one or multiple IAS servers within your intranet.

For more information, see Deploying IAS as a RADIUS proxy.

Note

  • XOX


Understanding IAS

This section covers:

  • Components of a RADIUS infrastructure
  • Realm names
  • IAS and tunnels
  • Managing multiple IAS servers
  • Network access authentication and certificates
  • Securing IAS
  • Vendor-specific attributes
  • Authentication methods
  • Remote access policies
  • Connection request processing
  • Remote access logging

Note

  • XOX


Components of a RADIUS infrastructure

A RADIUS authentication, authorization, and accounting infrastructure consists of the following components:

  • Access clients
  • Access servers (RADIUS clients)
  • RADIUS proxies
  • RADIUS servers
  • User account databases

These components are shown in the following illustration.

Components of a RADIUS infrastructure

Access clients

An access client is a device that requires some level of access to a larger network. Examples of access clients are dial-up or virtual private network (VPN) clients, wireless clients, or LAN clients connected to a switch.

Access servers (RADIUS clients)

An access server is a device that provides some level of access to a larger network. An access server using a RADIUS infrastructure is also a RADIUS client, sending connection requests and accounting messages to a RADIUS server. Examples of access servers are:

  • Network access servers (NASs) that provide remote access connectivity to an organization network or the Internet. An example is a Windows 2000 computer running the Routing and Remote Access service and providing either traditional dial-up or virtual private network (VPN) remote access services to an organization's intranet.
  • Wireless access points that provide physical layer access to an organization's network, using wireless-based transmission and reception technologies.
  • Switches that provide physical layer access to an organization's network, using traditional LAN technologies such as Ethernet.

RADIUS proxies

A RADIUS proxy is a device that forwards or routes RADIUS connection requests and accounting messages between RADIUS clients (and RADIUS proxies) and RADIUS servers (or RADIUS proxies). The RADIUS proxy uses information within the RADIUS message, such as the User-Name or Called-Station-ID RADIUS attributes, to route the RADIUS message to the appropriate RADIUS server.

A RADIUS proxy can be used as a forwarding point for RADIUS messages when the authentication, authorization, and accounting must occur at multiple RADIUS servers in different organizations.

RADIUS servers

A RADIUS server is a device that receives and processes connection requests or accounting messages sent by RADIUS clients or RADIUS proxies. In the case of connection requests, the RADIUS server processes the list of RADIUS attributes in the connection request. Based on a set of rules and the information in the user account database, the RADIUS server either authenticates and authorizes the connection and sends back an Access-Accept message or sends back an Access-Reject message. The Access-Accept message can contain connection restrictions that are implemented by the access server for the duration of the connection.

User account databases

The user account database is the list of user accounts and their properties that can be checked by a RADIUS server to verify authentication credentials and user account properties containing authorization and connection parameter information.

The user account databases that IAS can use are the local Security Accounts Manager (SAM), a Microsoft Windows NT 4.0 domain, or the Active Directory directory service. For Active Directory, IAS can provide authentication and authorization for user or computer accounts in the domain in which the IAS server is a member, two-way trusted domains, and trusted forests with domain controllers running XOX; XOX; and XOX.

If the user accounts for authentication reside in a different type of database, IAS can be configured as a RADIUS proxy to forward the authentication request to a RADIUS server that does have access to the user account database. Different databases for Active Directory include untrusted forests, untrusted domains, or one-way trusted domains.

Note

  • XOX


Realm names

When an access client sends user credentials, a user name is often included. Within the user name are two elements:

  1. Identification of the user account name
  2. Identification of the user account location

For example, for the user name user1@microsoft.com, user1 is the user account name and microsoft.com is the location of the user account. The identification of the location of the user account is known as a realm. There are different forms of realm names:

  • The realm name can be a prefix.

    • For example, Microsoft\user1, where Microsoft is the name of a Windows NT 4.0 domain.

  • The realm name can be a suffix.

    • For example, user1@microsoft.com, where microsoft.com is either a DNS domain name or the name of an Active Directory domain.

You can require users to specify the realm name by using the correct syntax when they connect. For example, you can require that the user type the user name (including the user account name and the realm) in User name in the Connect dialog box when making a dial-up or VPN connection in Network Connections. You can also add the realm name automatically to the user account name. For example, you can specify a realm name and syntax when you create a custom dialing package with the Connection Manager Administration Kit, so that the user has to specify only the user account name. For more information, see Connection Manager Administration Kit.

The user name is passed from the access client to the access server during the authentication phase of the connection attempt. This user name becomes the User-Name RADIUS attribute in the Access-Request message that is sent by the access server to its RADIUS server.

If the RADIUS server is an IAS server, the Access-Request message is evaluated against the set of configured connection request policies. Conditions on the connection request policy can include the specification of the contents of User-Name attribute. You can configure a set of connection request policies that are specific to the realm name within the User-Name attribute of incoming messages. This allows to you create routing rules that forward RADIUS messages with a specific realm name to a specific set of RADIUS servers when IAS is used as a RADIUS proxy.

Before the RADIUS message is either processed locally (when IAS is being used as a RADIUS server) or forwarded to another RADIUS server (when IAS is being used as a RADIUS proxy), the User-Name attribute in the message might be modified by attribute manipulation rules that are configured on the profile of the first matching connection request policy. Attribute manipulation rules for the User-Name attribute might change the following:

  • Remove the realm name from the user name (also known as realm stripping).

    • For example, the user name user1@microsoft.com is changed to user1.

  • Change the realm name but not its syntax.

    • For example, the user name user1@microsoft.com is changed to user1@wcoast.microsoft.com.

  • Change the syntax of the realm name.

    • For example, the user name microsoft\user1 is changed to user1@microsoft.com.

Attribute manipulation rules are configured in the Attribute tab on the profile of a connection request policy. For more information, see To configure attribute manipulation. IAS attribute manipulation rules use regular expression syntax. For more information about this syntax and examples, see Pattern matching syntax.

After the User-Name attribute is modified according to attribute manipulation rules, additional settings on the profile of the first matching connection request policy are used to determine whether:

  • The IAS server processes the Access-Request message locally (when IAS is being used as a RADIUS server).
  • The IAS server forwards the message to another RADIUS server (when IAS is being used as a RADIUS proxy).

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Notes

  • When the user name does not contain a domain name, IAS supplies one. By default, the IAS-supplied domain name is the domain of which the IAS server is a member. You can specify the IAS-supplied domain name through the following registry setting:

    HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RasMan\PPP\ControlProtocols\BuiltIn\DefaultDomain

  • Some third party network access servers delete or modify the domain name as specified by the user. As the result, the network access request is authenticated against the default domain, which might not be the domain for the user's account. To resolve this problem, configure your RADIUS servers to change the user name into the correct format with the accurate domain name.


IAS and tunnels

Tunneling, also known as encapsulation, is a method of using an internetwork infrastructure of one protocol to transfer a payload. Sometimes, the payload consists of the frames (or packets) of another protocol. Instead of being sent as the originating host produces it, the frame is encapsulated with an additional header. The additional header provides routing information so that the encapsulated payload can traverse an intermediate internetwork (also known as a transit internetwork). The encapsulated packets are then routed between tunnel endpoints over the transit internetwork. After the encapsulated payload packets reach their destination on the transit internetwork, the frame is de-encapsulated and forwarded to its final destination.

The entire process of the encapsulation, transmission, and de-encapsulation of packets is called tunneling. The logical path in the transit internetwork through which the encapsulated packets travel is called a tunnel.

With remote access virtual private network (VPN) connections, there are two types of tunneling:

  1. Voluntary tunneling
  2. Compulsory tunneling

Voluntary tunneling

A user or client computer can issue a VPN request to configure and create a voluntary tunnel. In this case, the user's computer is a tunnel endpoint that acts as the tunnel client. Voluntary tunneling occurs when a workstation or router uses tunneling client software to create a VPN connection to the target tunnel server. In order to accomplish this, the appropriate tunneling protocol must be installed on the client computer. In a dial-up situation, which is the most common use, the client must establish a dial-up connection to the internetwork before the client can set up a tunnel. A good example of this is the dial-up Internet user, who must dial an ISP and obtain an Internet connection before a tunnel over the Internet is created.

Voluntary tunneling is not different from other types of network access, and IAS can be used for authentication, authorization, and accounting.

Compulsory tunneling

Compulsory tunneling is the creation of a secure tunnel by another computer or network device on the client computer's behalf. Compulsory tunnels are configured and created automatically for users without their knowledge or intervention. With a compulsory tunnel, the user's computer is not a tunnel endpoint. Another device between the user's computer and the tunnel server is the tunnel endpoint, which acts as the tunnel client.

Some vendors that sell dial-up access servers provide for the creation of a tunnel on behalf of a dial-up client. The computer or network device that provides the tunnel for the client computer is known as a front-end processor (FEP) in PPTP, an L2TP access concentrator (LAC) in L2TP, or an IP Security gateway in IPSec. The term FEP is used to describe tunnel creation functionality, regardless of the protocol used. To perform its function, the FEP must have the appropriate tunneling protocol installed and must be capable of establishing the tunnel when the client computer attempts a connection. The XOX; XOX; XOX; and Windows 2000 Routing and Remote Access service cannot be used as a FEP.

An organization can contract with an ISP to deploy a nationwide set of FEPs. These FEPs can establish tunnels across the Internet to a VPN server that is connected to the organization private network, thereby consolidating calls from geographically diverse locations into a single Internet connection at the organization network.

There are two types of compulsory tunneling. In the first type, the tunnel is created before the access client is authenticated. Based on the realm name or the caller ID of the access client, the FEP sends an Access-Request to an IAS server. The IAS server sends back an immediate Access-Accept with RADIUS attributes for the tunnel creation without performing authentication and authorization. After the tunnel is created, the access client authenticates against the tunnel server.

In the second type of compulsory tunneling, the tunnel is created after the access client is authenticated by the FEP. In this case, the FEP sends the Access-Request message with the client credentials to an IAS server. The IAS server authenticates and authorizes the connection attempt and returns RADIUS attributes in the Access-Accept message, which specify to the NAS how to initiate a tunnel to a VPN server. The tunnel-endpoint (the VPN server at which the tunnel is terminated), can be changed on the basis of conditions in a remote access policy. For example, the tunnel-endpoint can be changed on the basis of the user name or the user account group membership. Controlling compulsory tunnels with remote access policies provides more flexibility than static tunneling (which requires a dedicated network access server) or realm-based tunneling (which requires that all users in a given realm use the same tunnel settings).

RADIUS attributes used with compulsory tunneling

The following is a list of RADIUS attributes that are used to carry compulsory tunneling information from the IAS server to the FEP. The same set of attributes is used regardless of the type of compulsory tunnel.

  • Attributes used only for authorization:
    • Tunnel-Preference
    • Tunnel-Password

      • This attribute should not be used with RADIUS proxies.

  • Attributes used in authorization and accounting:
    • Tunnel-Type (for example, PPTP and L2TP)
    • Tunnel-Medium-Type (for example, X.25, ATM, Frame Relay, and IP)
    • Tunnel-Client-Endpoint
    • Tunnel-Server-Endpoint
    • Tunnel-Private-Group-ID
    • Tunnel-Assignment-ID
    • Tunnel-Client-Auth-ID
    • Tunnel-Server-Auth-ID
  • Attributes used only for accounting:
    • Acct-Tunnel-Connection-ID

Compulsory tunneling example

The following table lists the set of compulsory tunneling RADIUS attributes that specify a compulsory tunnel. This tunnel uses the Layer Two Tunneling Protocol (L2TP) with a VPN server at the IP address of 131.107.9.41, and a tunnel password of og*37y#cW@95?4xT.

Attribute | Value
Framed-Protocol | PPP
Service-Type | Outbound-User
Tunnel-Medium-Type | IP (IP version 4)
Tunnel-Password | og*37y#cW@95?4xT
Tunnel-Server-Endpt | 131.107.9.41
Tunnel-Type | Layer Two Tunneling Protocol (L2TP)

To configure IAS, add your versions of all of these attributes and their appropriate values on the Advanced tab in the profile properties of the applicable remote access policy. For more information, see To add RADIUS attributes to a remote access policy.

Notes

  • You can use a RADIUS Access-Accept packet to send tunnel attributes that describe multiple tunnels. However, IAS only returns information for a single tunnel.
  • IAS only supports one compulsory tunnel for each connection request and remote access policy.


Managing multiple IAS servers

To prevent a single IAS server from becoming a single point of failure for authentication, authorization, and accounting, IAS servers are often deployed either in pairs (a primary and a backup) to provide fault tolerance, or in multiples to balance the load of large numbers of authentication and accounting requests.

When you deploy more than one IAS server computer to provide the same authentication, authorization, and accounting service to RADIUS clients and proxies, you must synchronize the configuration of the IAS server computers. You can do this through the following:

  • Internet Authentication Service snap-in

    • You can use the Internet Authentication Service snap-in to manage both local and remote IAS server computers. If you make a configuration change to one IAS server, you must make the same configuration change to all of the IAS servers that provide the same service. For information about managing a remote IAS server computer, see To manage a remote IAS server. This method might be acceptable for a small number of servers and minor configuration changes.

  • Copying the configuration of one IAS server computer to another

    • With this method, you can use the netsh aaaa show config to export the configuration of one IAS server to a Netsh script file. Next, you can use the netsh exec command to import the IAS server configuration on another IAS server. For more information, see To copy the IAS configuration to another server. This method is recommended for a large number of configuration changes or a larger number of servers. You can use this method to centrally manage RADIUS and remote access policy configuration in a large enterprise network.

When you type netsh aaaa show config, it creates a Netsh script file that is designed to be used with the netsh exec command. The contents of the display of the netsh aaaa show config command includes:

  • IAS settings
  • RADIUS clients
  • Remote access policies
  • Connection request policies
  • Remote access logging settings

For more information, see Netsh commands for AAAA.

The Routing and Remote Access service uses the same database as IAS. There are no settings, however, for IAS, RADIUS clients, or connection request policies. If settings are present, they are ignored by the Routing and Remote Access service. Because of this, it is possible to copy the configuration of an IAS server computer to a Routing and Remote Access server. For example, you can update the remote access policies of a branch office demand-dial router computer.

Notes

  • The netsh aaaa show config and netsh exec commands can be run without stopping the Internet Authentication Service or the Routing and Remote Access service.
  • The version number of the IAS database from which the configuration was exported, should be less than or equal to the version of the IAS database to which the configuration is being imported. To view the version of the IAS database from which the configuration was exported, view the Netsh command script file, which is created with the netsh aaaa show config command. To view the version of the IAS database on the IAS server computer on which the Netsh script is being run, use the netsh aaaa show version command.
  • The netsh aaaa show config and netsh exec commands are used to export and import the entire database. You cannot specify which elements of the IAS database to export or import.
  • Do not copy the configuration from a Routing and Remote Access server to an IAS server. By default, the Routing and Remote Access service version of the IAS database does not contain all of the configuration items contained in the full IAS database.
  • XOX


Securing IAS

This section covers:

  • IAS and firewalls
  • Shared secrets
  • Message Authenticator attribute
  • Remote access account lockout
  • IAS Network Access Quarantine Control
  • Securing RADIUS traffic with IPSec


IAS and firewalls

In the most common configuration, the firewall is connected to the Internet and the IAS server is another intranet resource that is connected to the perimeter network.

To reach the domain controller within the intranet, the IAS server might have:

  • An interface on the perimeter network and an interface on the intranet (IP routing is not enabled).
  • A single interface on the perimeter network. In this configuration, IAS communicates with intranet domain controllers through another firewall that connects the perimeter network to the intranet. This configuration is shown in the following drawing.
IAS in a perimeter network

Configuring the Internet firewall

The firewall that is connected to the Internet must be configured with input and output filters on its Internet interface (and, optionally, its network perimeter interface), to allow the forwarding of RADIUS messages between the IAS server and RADIUS clients or proxies on the Internet. Additional filters can be used to allow the passing of traffic to Web servers, VPN servers, and other types of servers on the perimeter network.

Separate input and output packet filters can be configured on the Internet interface and the perimeter network interface.

Filters on the Internet interface

Configure the following input packet filters on the Internet interface of the firewall to allow the following types of traffic:

  • Destination IP address of the IAS server's perimeter network interface and UDP destination port of 1812 (0x714).

    • This filter allows RADIUS authentication traffic from Internet-based RADIUS clients to the IAS server. This is the default UDP port that is used by IAS, as defined in RFC 2865. If you are using a different port, substitute that port number for 1812, which is used in this example.

  • Destination IP address of the IAS server's perimeter network interface and UDP destination port of 1813 (0x715).

    • This filter allows RADIUS accounting traffic from Internet-based RADIUS clients to the IAS server. This is the default UDP port that is used by IAS, as defined in RFC 2866. If you are using a different port, substitute that port number for 1813, which is used in this example.

  • (Optional) Destination IP address of the IAS server's perimeter network interface and UDP destination port of 1645 (0x66D).

    • This filter allows RADIUS authentication traffic from Internet-based RADIUS clients to the IAS server. This is the UDP port that is used by older RADIUS clients.

  • (Optional) Destination IP address of the IAS server's perimeter network interface and UDP destination port of 1646 (0x66E).

    • This filter allows RADIUS accounting traffic from Internet-based RADIUS clients to the IAS server. This is the UDP port that is used by older RADIUS clients.

Configure the following output filters on the Internet interface of the firewall to allow the following types of traffic:

  • Source IP address of the IAS server's perimeter network interface and UDP source port of 1812 (0x714).

    • This filter allows RADIUS authentication traffic from the IAS server to Internet-based RADIUS clients. This is the default UDP port that is used by IAS, as defined in RFC 2865. If you are using a different port, substitute that port number for 1812, which is used in this example.

  • Source IP address of the IAS server's perimeter network interface and UDP source port of 1813 (0x715).

    • This filter allows RADIUS accounting traffic from the IAS server to Internet-based RADIUS clients. This is the default UDP port that is used by IAS, as defined in RFC 2866. If you are using a different port, substitute that port number for 1813, which is used in this example.

  • (Optional) Source IP address of the IAS server's perimeter network interface and UDP source port of 1645 (0x66D).

    • This filter allows RADIUS authentication traffic from the IAS server to Internet-based RADIUS clients. This is the UDP port that is used by older RADIUS clients.

  • (Optional) Source IP address of the IAS server's perimeter network interface and UDP source port of 1646 (0x66E).

    • This filter allows RADIUS accounting traffic from the IAS server to Internet-based RADIUS clients. This is the UDP port that is used by older RADIUS clients.

Filters on the perimeter network interface

Configure the following input filters on the perimeter network interface of the firewall to allow the following types of traffic:

  • Source IP address of the IAS server's perimeter network interface and UDP source port of 1812 (0x714).

    • This filter allows RADIUS authentication traffic from the IAS server to Internet-based RADIUS clients. This is the default UDP port that is used by IAS, as defined in RFC 2865. If you are using a different port, substitute that port number for 1812, which is used in this example.

  • Source IP address of the IAS server's perimeter network interface and UDP source port of 1813 (0x715).

    • This filter allows RADIUS accounting traffic from the IAS server to Internet-based RADIUS clients. This is the default UDP port that is used by IAS, as defined in RFC 2866. If you are using a different port, substitute that port number for 1813, which is used in this example.

  • (Optional) Source IP address of the IAS server's perimeter network interface and UDP source port of 1645 (0x66D).

    • This filter allows RADIUS authentication traffic from the IAS server to Internet-based RADIUS clients. This is the UDP port that is used by older RADIUS clients.

  • (Optional) Source IP address of the IAS server's perimeter network interface and UDP source port of 1646 (0x66E).

    • This filter allows RADIUS accounting traffic from the IAS server to Internet-based RADIUS clients. This is the UDP port that is used by older RADIUS clients.

Configure the following output packet filters on the perimeter network interface of the firewall to allow the following types of traffic:

  • Destination IP address of the IAS server's perimeter network interface and UDP destination port of 1812 (0x714).

    • This filter allows RADIUS authentication traffic from Internet-based RADIUS clients to the IAS server. This is the default UDP port that is used by IAS, as defined in RFC 2865. If you are using a different port, substitute that port number for 1812, which is used in this example.

  • Destination IP address of the IAS server's perimeter network interface and UDP destination port of 1813 (0x715).

    • This filter allows RADIUS accounting traffic from Internet-based RADIUS clients to the IAS server. This is the default UDP port that is used by IAS, as defined in RFC 2866. If you are using a different port, substitute that port number for 1813, which is used in this example.

  • (Optional) Destination IP address of the IAS server's perimeter network interface and UDP destination port of 1645 (0x66D).

    • This filter allows RADIUS authentication traffic from Internet-based RADIUS clients to the IAS server. This is the UDP port that is used by older RADIUS clients.

  • (Optional) Destination IP address of the IAS server's perimeter network interface and UDP destination port of 1646 (0x66E).

    • This filter allows RADIUS accounting traffic from Internet-based RADIUS clients to the IAS server. This is the UDP port that is used by older RADIUS clients.

For added security, you can use the IP addresses of each RADIUS client that sends the packets through the firewall to define specific filters for traffic between the client and the IP address of the IAS server on the perimeter network.

Configuring the intranet firewall

The firewall that is connected to the intranet must be configured with input and output filters on its perimeter network interface (and, optionally, its intranet interface), to allow the forwarding of RADIUS messages between the IAS server on the perimeter network and domain controllers in the intranet. Additional filters can allow the passing of traffic to Web, VPN, and other types of servers on the perimeter network.

Separate input and output packet filters can be configured on the perimeter network interface and the intranet interface.

Filters on the perimeter network interface

Configure the following input packet filters on the perimeter network interface of the intranet firewall to allow the following types of traffic:

  • Source IP address of the IAS server's perimeter network interface.

    • This filter allows traffic from the IAS server on the perimeter network.

Configure the following output filters on the perimeter network interface of the intranet firewall to allow the following types of traffic:

  • Destination IP address of the IAS server's perimeter network interface.

    • This filter allows traffic to the IAS server on the perimeter network.

Filters on the intranet interface

Configure the following input filters on the intranet interface of the firewall to allow the following types of traffic:

  • Destination IP address of the IAS server's perimeter network interface.

    • This filter allows traffic to the IAS server on the perimeter network.

Configure the following output packet filters on the intranet interface of the firewall to allow the following types of traffic:

  • Source IP address of the IAS server's perimeter network interface.

    • This filter allows traffic from the IAS server on the perimeter network.


Shared secrets

A shared secret is a text string that serves as a password between:

  • A RADIUS client and RADIUS server.
  • A RADIUS client and a RADIUS proxy.
  • A RADIUS proxy and a RADIUS server.

For a configuration that uses a RADIUS client, a RADIUS proxy, and a RADIUS server, the shared secret that is used between the RADIUS client and the RADIUS proxy can be different than the shared secret used between the RADIUS proxy and the RADIUS server.

Shared secrets are used to verify that RADIUS messages, with the exception of the Access-Request message, are sent by a RADIUS-enabled device that is configured with the same shared secret. Shared secrets also verify that the RADIUS message has not been modified in transit (message integrity). The shared secret is also used to encrypt some RADIUS attributes, such as User-Password and Tunnel-Password. To provide verification for Access-Request messages, you can enable use of the RADIUS Message Authenticator attribute for both the RADIUS client configured on the IAS server and the access server. For more information, see Message Authenticator attribute and To configure the Message Authenticator attribute and shared secret.

When creating and using a shared secret:

  • You must use the same case-sensitive shared secret on both RADIUS devices.
  • Use a different shared secret for each RADIUS server-RADIUS client pair.
  • To ensure a random shared secret, generate a random sequence at least 22 characters long.
  • You can use any standard alphanumeric and special characters.
  • You can use a shared secret of up to 128 characters in length. To protect your IAS server and your RADIUS clients from brute force attacks, use long shared secrets (more than 22 characters).
  • Make the shared secret a random sequence of letters, numbers, and punctuation and change it often to protect your IAS server and your RADIUS clients from dictionary attacks. Shared secrets should contain characters from each of the following three groups:
Group | Examples
Letters (uppercase and lowercase) | A, B, C and a, b, c
Numerals | 0, 1, 2, 3
Symbols (all characters not defined as letters or numerals) | Exclamation point (!), asterisk (*), colon (:)

The stronger your shared secret, the more secure are the attributes (for example, those used for passwords and encryption keys) that are encrypted with it. An example of a strong shared secret is 8d#>9fq4bV)H7%a3-zE13sW.

Notes

  • When the Password Authentication Protocol (PAP) is used between an access client and an access server (a RADIUS client), the access server encrypts the PAP password by using the shared secret and sends it in an Access-Request packet. If the access server sends the Access-Request message to a RADIUS proxy, the RADIUS proxy must first decrypt the PAP password with the shared secret that was used between the RADIUS proxy and the access server. Next, it encrypts the PAP password with the shared secret that was used between the RADIUS proxy and the RADIUS server before forwarding the Access-Request message. Because a malicious user or process at a RADIUS proxy can record user names and passwords for PAP connections after they are decrypted but before they are encrypted, the use of PAP is highly discouraged.
  • If you specify RADIUS clients by using an IP address range, all RADIUS clients within the address range must use the same shared secret.
  • If you are using a password-based authentication method, it is strongly recommended that you use MS-CHAP v2, MS-CHAP, or CHAP with strong passwords to provide password protection from dictionary attacks.
  • XOX


Message Authenticator attribute

When you configure IAS for a RADIUS client, you configure the IP address of the client. If an incoming RADIUS Access-Request message does not originate from at least one of the IP addresses of configured clients, IAS automatically discards the message, providing protection for an IAS server. However, source IP addresses can be spoofed (substituted with other IP addresses).

To provide protection from spoofed Access-Request messages and RADIUS message tampering, each RADIUS message can be additionally protected with the RADIUS Message Authenticator attribute, which is described in RFC 2869, "RADIUS Extensions."

The RADIUS Message Authenticator attribute is a Message Digest 5 (MD5) hash of the entire RADIUS message. The shared secret is used as the key. If the RADIUS Message Authenticator attribute is present, it is verified. If it fails verification, the RADIUS message is discarded. If the client settings require the Message Authenticator attribute and it is not present, the RADIUS message is discarded.

For information about how to configure the use of the Message Authenticator attribute for RADIUS clients of an IAS server, see To configure the Message Authenticator attribute and shared secret. For information about how to configure the use of the Message Authenticator attribute for the Routing and Remote Access service, see To use RADIUS authentication.


IAS Network Access Quarantine Control

IAS Network Access Quarantine Control provides phased network access for remote client computers by restricting them to a quarantine mode. After the client computer configuration is either brought into or determined to be in accordance with your organization’s network policy, quarantine restrictions, which consist of Quarantine IP-Filters and Session Timers, are removed and standard remote access policy is applied to the connection.

Network Access Quarantine Control provides protection when users in your organization accidentally reconfigure key settings and do not restore them before connecting to your network. For example, a user might disable antivirus software that is required while connected to your network. Although Network Access Quarantine Control does not protect against attackers, computer configurations for authorized users can be verified and, if necessary, corrected before they can access the network. A timer setting is also available, which you can use to specify an interval at which the connection is dropped if the client fails to meet configuration requirements.

You can use the Routing and Remote Access service to process the specific RADIUS options sent by IAS, complete any required client configuration work, and remove the quarantine condition (or drop the connection) based on success or failure.

Quarantine mode

Quarantine mode is a set of network restrictions that are configured in IAS and implemented by the remote access server for each connection. You can use a Quarantine IP Filter to restrict access to a specific set of servers (for example, servers on a specified virtual Local Area Network) and a Quarantine Session Timer to restrict the amount of time the client can remain connected in quarantine mode. You can set these filters in the IAS console.

Configuring Network Access Quarantine Control

You can implement Network Access Quarantine Control with one or more servers running Windows Server 2003 and remote access, one or more servers running Windows Server 2003 and IAS, a Connection Manager (CM) profile created with Connection Manager Administration Kit (CMAK), an administrator-provided script, and two additional components: the notifier component and the listener component.

The notifier component is included in the CM profile and installed on the client computer. The notifier component sends notification to the remote access server when the administrator-provided script has run successfully on the client.

The listener component is installed on the remote access server, and receives notification from the notifier component that the script on the client has successfully performed all configuration checks. After the listener component receives notification, it removes the client from quarantine mode, and the remote access server applies standard remote access policy to the client.

You can create your own notifier and listener components, or you can use Rqs.exe (a listener component) and Rqc.exe (a notifier component), which are planned to be available in the Windows Deployment and Resource Kits. For more information, see Windows Resource Kit Tools Help. The Remote Access Quarantine Agent service is included when Rqs.exe is installed on a remote access server. When you create the CM profile, you can include the administrator-provided script and Rqc.exe, which are distributed to and installed on remote access client computers. This profile can be installed on the following client operating systems:

  • XOX
  • XOX
  • Windows 2000 Professional
  • Windows Millennium Edition
  • Windows 98 Second Edition

For more information about CMAK, see Connection Manager Administration Kit.

Caution

  • Placing all remote access clients in quarantine mode without a way to remove quarantine policy and apply full access policy might prevent all remote access clients from establishing network connections.

Before you implement a remote access policy with Quarantine IP-Filters and Session Timers on your network, you must complete the following steps:

  1. Create a client-side script that validates client configuration information.
  2. Create a notification component that provides verification to the remote access server that the script has successfully run. If you do not want to create a notification component, you can use Rqc.exe.
  3. Create a listener component to install on remote access servers (that can receive information from the notification component), and then remove the client from quarantine mode, applying the full access policy. If you do not want to create a listener component, you can use Rqs.exe.
  4. Create a CM profile with CMAK. Include the client-side script and the notification component in the profile.
  5. Distribute the CM profile for installation on remote access client computers.

Configure two remote access policies on remote access or IAS servers

On your remote access servers or IAS servers, use the New Remote Access Policy Wizard to create these remote access policies:

  • A full access policy
  • A quarantine policy

The notification and listener components of Network Access Quarantine Control use port 7250 by default. When you create the quarantine policy, you must configure Inbound Filters (also called Input Filters) to allow network traffic on port 7250, or the notification component (Rqc.exe), which runs on client computers, cannot notify the remote access server listener component (Rqs.exe) that the script has run successfully. You can specify another port, but you must also configure the listener and notification components to use this new port.

When you use the New Remote Access Policy Wizard to create quarantine policy, do the following to add quarantine IP filters and session timers:

  1. On the Profile page, click Edit Profile.
  2. In Edit Dial-In Profile, click the Advanced tab, and then click Add.

To add a quarantine IP filter

  1. In Attribute, select MS-Quarantine-IPFilter, and then click Add.
  2. In IP Filter Attribute Information, click Input Filters.
  3. In Inbound Filters, click New.
  4. In Add IP Filter, click Destination network, and then type values in IP address and Subnet mask that match your network configuration.
  5. In Protocol, select TCP.
  6. In Source port, type 7250.
  7. In Destination port, type 7250, and then click OK.
  8. In Inbound Filters, for Filter action, click Permit only the packets listed below, and then click OK.

To add a quarantine session timer

  • In Attribute, select MS-Quarantine-Session-Timeout, and then click Add.
  • In Attribute value, type the number of seconds that represents the maximum amount of time (in seconds) that you want client computers to remain connected in quarantine mode, and then click OK.

After you have configured both the full access and quarantine policies, make sure that the quarantine policy is first in the list of remote access policies.

For more information about the New Remote Access Policy Wizard, see To add a remote access policy.

Notes

  • IAS Network Access Quarantine Control must be used in combination with remote access policy (user-based authentication and access control) to provide security for your network. The quarantine filters and timers can be defined in a remote access policy on either the remote access server or the IAS server. When the connection is made, the access server implements the restrictions (Quarantine IP Filters and Quarantine Session Timers) that are returned by IAS.
  • Notification by the client (to the server) that the administrator-provided script has successfully run is not secure and can be spoofed by a malicious user or attacker. Network Access Quarantine Control is only intended to help verify a managed client computer configuration.
  • XOX


Securing RADIUS traffic with IPSec

Internet Protocol security (IPSec) provides you with the ability to secure RADIUS servers against unwanted traffic by filtering on specific network adapters (allowing or blocking specific protocols) and enabling you to choose source IP addresses from which traffic is allowed. For organizational units, you can create IPSec policies, which are stored in Active Directory. Or, you can create local policies on RADIUS servers, and apply these policies to specific computers. If you create IPSec policies for an organizational unit, the policy is applied through Group Policy.

For more information about organizational units and Group Policy, see Organizational units, Group Policy integration, and To create a new organizational unit.

Before you create IPSec filters, determine the type of traffic that you want to allow for each RADIUS server. Filters that are too strict might block acceptable network traffic. For example, if IAS is installed on a domain controller and all IP traffic, except RADIUS traffic, is blocked on all ports, user queries for Active Directory objects (such as printers) on default global catalog port 3268 will fail. Conversely, IP filters that are too general expose the RADIUS server to unwanted traffic. For more information, see Special IPSec considerations and Filter list.

RADIUS messages are sent with the User Datagram Protocol (UDP). UDP port 1812 is used for RADIUS authentication messages and UDP port 1813 is used for RADIUS accounting messages. When you create inbound and outbound filters with IPSec, UDP traffic must be allowed on these ports. However, some network access servers might use UDP port 1645 for RADIUS authentication messages and UDP port 1646 for RADIUS accounting messages. By default, IAS supports both sets of ports. If your network access servers use UDP ports 1645 and 1646, you can create IPSec filters that allow traffic on these ports. For information about changing the UDP ports that IAS uses, see To configure IAS port information. For more information about defining IP filter lists, see Internet Protocol security (IPSec) and Define IP filter lists

You can use the IP Security Policies snap-in and Group Policy to configure IPSec policy for organizational units. For more information, see To start the IP Security Policies snap-in and Group Policy.

You can use the Local Security Policy console to configure IPSec policy for individual RADIUS servers. For more information, see Local security policy.

For information about how to create IP filters for remote access clients, see IAS Network Access Quarantine Control.

Note

  • XOX


Vendor-specific attributes

This section covers:

  • Vendor-specific attribute overview
  • Sample VSA for a Cisco NAS
  • Sample VSA for a US Robotics NAS


Vendor-specific attribute overview

IAS provides the ability to specify RADIUS attributes that are returned with a RADIUS response message. These RADIUS attributes can be specified for each remote access policy and are configured on the Advanced tab in the properties of a profile for a remote access policy. For more information, see Configure attributes for a profile.

In addition to the standard RADIUS attributes, which are described in RFCs 2865 and 2866, you might also need to configure vendor-specific attributes (VSAs). VSAs allow vendors to support their own proprietary RADIUS attributes that are not included in RFCs 2865 and 2866. IAS includes VSAs from a number of vendors in its dictionary; however, the VSAs provided with IAS in XOX; XOX; and XOX do not include VSAs for all vendors. There is no process for centrally updating and distributing new versions of the IAS dictionary. Instead, you can manually create new VSAs for each remote access policy profile.

Some network access server (NAS) manufacturers use vendor-specific attributes (VSAs) to provide functionality that is not supported in standard attributes. IAS enables you to create or edit VSAs to take advantage of proprietary functionality supported by some NAS vendors. For more information about vendor-specific functionality and the VSAs that you can configure, see your access server documentation.

Before adding a VSA, check the list of attributes in the IAS dictionary. If the required VSA is present, use it. If not, you must add a VSA to the profile. VSAs are added by specifying the Vendor-Specific attribute on the Advanced tab in the properties of a profile for a remote access policy. For more information, see To configure vendor-specific attributes for a remote access policy.

If you want to add VSAs to the remote access policy profile to support proprietary functionality for your access point, you must determine whether the VSA conforms to the format recommended in RFC 2865.

  • If it does, you must specify:
    • A network access vendor by either name or vendor code.
    • A vendor-assigned attribute number.
    • The attribute format (that is, the type of data, such as string or hexadecimal).
    • The attribute value.
  • If it does not, you must specify:
    • A network access vendor by either name or vendor code.
    • A hexadecimal attribute value that represents the attribute data.

Ordering of multiple VSAs

If you need to configure more than one VSA, you should arrange them in the appropriate order in the Multivalued Attribute Information dialog box. For example, if you are using a filtering VSA that automatically disconnects users who do not meet specific criteria, you should ensure that the attribute appears at the top of the list. Use the Move Up and Move Down buttons in the Multivalued Attribute Information dialog box to arrange the attributes in the correct order.


Sample VSA for a Cisco NAS

This sample Cisco vendor-specific attribute conforms to the format for vendor-specific attributes (type 26) that is specified in RFC 2865.

The following table lists the information used to configure a Cisco VSA to specify a primary DNS server with an IP address of 10.10.10.10.

Information | Description
Vendor ID | This is the unique ID for Cisco. When you select Cisco as the network access server vendor, this ID (9) is automatically supplied.
Cisco-assigned attribute number | This is the vendor-type number (1) for vendor-specific attributes that take the attribute-value pair form, specified in Cisco documentation as cisco-avpair.
Syntax | If the attribute is mandatory, the syntax is Protocol:Attribute = Value. If the attribute is optional, the attribute-value pair is separated by an asterisk (*) instead of an equal sign (=). In this example, Protocol is a value of the Cisco protocol attribute for a specific type of authorization. Attribute and Value represent an appropriate attribute/value (AV) pair defined in the Cisco TACACS+ specification. This allows the full set of features available for TACACS+ authorization to be used for RADIUS. The Cisco format, used to specify a primary DNS server, is ip:dns-servers=10.10.10.10.

To specify the primary DNS server of 10.10.10.10:

  • Configure an RFC-compliant VSA.

    • For more information, see To configure vendor-specific attributes for a remote access policy.

    • Select Cisco as the network access server vendor.
    • In the Configure VSA (RFC-compliant) dialog box:
      • Type 1 for the Vendor-assigned attribute number.
      • Select String for the Attribute format.
      • Type ip:dns-servers=10.10.10.10 for the Attribute value.

For more information about Cisco VSAs, see your Cisco documentation.


Sample VSA for a US Robotics NAS

This sample US Robotics vendor-specific attribute does not conform to the format for vendor-specific attributes (VSAs) that is specified in RFC 2865. Therefore, this US Robotics VSA must be entered in hexadecimal format.

The following table lists the information that is used to configure a US Robotics VSA to specify a primary DNS/NBNS server with an IP address of 10.10.10.10.

Information | Description
Vendor ID | This is the unique ID for US Robotics. When you select US Robotics as the network access server vendor, this ID (429) is automatically supplied.
US Robotics VSA Indicator | The VSA indicator for the primary DNS/NBNS server is 0x900F.
String | The hexadecimal encoding of the string 10.10.10.10. (the IP address of a primary DNS/NBNS server) is 0x31302E31302E31302E31302E.

To specify an IP address of 10.10.10.10 for a primary DNS/NBNS server:

  • Configure a non-RFC-compliant VSA.

    • For more information, see To configure vendor-specific attributes for a remote access policy.

    • Select US Robotics as the network access server vendor.
    • In Hexadecimal attribute value, in the Configure VSA (non-RFC-compliant) dialog box, type 0x900f31302E31302E31302E31302E.

For more information about US Robotics VSAs, see your US Robotics documentation.


Authentication methods

The authentication of access clients is an important security concern. Authentication methods typically use an authentication protocol that is negotiated during the connection establishment process. IAS also supports unauthenticated connections.

For information about using authentication methods, see the following:

  • PEAP
  • EAP
  • MS-CHAP
  • MS-CHAP version 2
  • CHAP
  • PAP
  • Unauthenticated access

Each authentication method has advantages and disadvantages in terms of security, usability, and breadth of support. The authentication method used is determined by the configuration of both the access server and client. Consult your access server documentation to determine which authentication methods are supported.

You can configure IAS to accept multiple authentication methods. You can also configure your access servers to attempt to negotiate a connection by using the most secure protocol first, and then the next most secure, and so on down to the least secure. For example, the Routing and Remote Access service tries to negotiate a connection using EAP first, then MS-CHAP v2, then MS-CHAP, then CHAP, then SPAP, and then PAP. When EAP is chosen as the authentication method, the negotiation of the EAP type occurs between the access client and the IAS server.

In addition, you can use remote access policies for various authentication methods, depending on the type of client being authenticated. For example, you can create two remote access policies, one for virtual private network (VPN) clients and one for wireless clients—each of which uses a different authentication method. The remote access policy for VPN clients can be configured to use EAP-TLS with smart cards or certificates as the authentication method and authentication type, while the remote access policy for wireless clients can be configured to use PEAP-EAP-MS-CHAP v2, which provides secure password authentication.

Certificate deployments and Active Directory replication

Some authentication methods, such as PEAP and EAP, can use certificates for authentication of computers and users. Latency in Active Directory replication might temporarily affect the ability of a client or server to obtain a certificate from a certification authority (CA). If a computer configured to use certificates for authentication cannot enroll a certificate, authentication fails.

For example, if a new computer running IAS is joined to the domain by a local domain controller, the IAS server is rebooted and Group Policy is applied. After Group Policy is applied and certificate autoenrollment is configured, the IAS server attempts to enroll a certificate with a CA. The CA queries Active Directory to determine whether the IAS server has the security permissions required to enroll a certificate. If the domain controller that joined the IAS server to the domain has replicated IAS server domain membership information across the domain, the CA can verify that the IAS server should receive a certificate. The CA then enrolls a certificate to the IAS server. You can manually refresh Group Policy by logging onto the domain or by running the gpupdate command.

When information about the IAS server domain membership has not replicated to other domain controllers and the CA queries a domain controller that does not yet have information about the IAS server, the CA cannot verify that the IAS server is running on a computer that is a domain member. Because the CA cannot verify that the IAS server has the security permissions to enroll a certificate, the CA does not enroll a certificate for the IAS server. As the result, authentication fails and the server cannot log on to the network.

For more information, see Network access authentication and certificates and Remote access policies.

Notes

  • IEEE 802.1x authentications for wireless and switch clients use only the PEAP and EAP authentication methods.
  • IAS also supports authentication for computer accounts.
  • When using the EAP-TLS authentication method with certificates, TLS uses cached certificate properties instead of reading the certificate from the certificate store. If a certificate is either changed or deleted and replaced by a new certificate, TLS continues using outdated cached certificate information until the cache expires or is refreshed. If you change or replace a certificate, you can refresh the TLS cache by restarting the server computer.


PEAP

Protected Extensible Authentication Protocol (PEAP) is a new member of the family of Extensible Authentication Protocol (EAP) protocols. PEAP uses Transport Level Security (TLS) to create an encrypted channel between an authenticating PEAP client, such as a wireless computer, and a PEAP authenticator, such as an Internet Authentication Service (IAS) or Remote Authentication Dial-In User Service (RADIUS) server. PEAP does not specify an authentication method, but provides additional security for other EAP authentication protocols, such as EAP-MSCHAPv2, that can operate through the TLS encrypted channel provided by PEAP. PEAP is used as an authentication method for 802.11 wireless client computers, but is not supported for virtual private network (VPN) or other remote access clients.

To enhance both the EAP protocols and network security, PEAP provides:

  • Protection for the EAP method negotiation that occurs between client and server through a TLS channel. This helps prevent an attacker from injecting packets between the client and the network access server (NAS) to cause the negotiation of a less secure EAP method. The encrypted TLS channel also helps prevent denial of service attacks against the IAS server.
  • Support for the fragmentation and reassembly of messages, allowing the use of EAP types that do not provide this.
  • Wireless clients with the ability to authenticate the IAS or RADIUS server. Because the server also authenticates the client, mutual authentication occurs.
  • Protection against the deployment of an unauthorized wireless access point (WAP) when the EAP client authenticates the certificate provided by the IAS server. In addition, the TLS master secret created by the PEAP authenticator and client is not shared with the access point. Because of this, the access point cannot decrypt the messages protected by PEAP.
  • PEAP fast reconnect, which reduces the delay in time between an authentication request by a client and the response by the IAS or RADIUS server, and allows wireless clients to move between access points without repeated requests for authentication. This reduces resource requirements for both client and server.

PEAP authentication process

There are two stages in the PEAP authentication process between PEAP client and authenticator. The first stage sets up a secure channel between the PEAP client and the authenticating server. The second stage provides EAP authentication between the EAP client and authenticator.

TLS encrypted channel

The wireless client associates with a wireless access point. An IEEE 802.11-based association provides an Open System or Shared Key Authentication before a secure association is created between the client and access point. After the IEEE 802.11-based association is successfully established between the client and access point, the TLS session is negotiated with the access point. After authentication is successfully completed between the wireless client and the server (for example, an IAS server), the TLS session is negotiated between them. The key that is derived during this negotiation is used to encrypt all subsequent communication.

EAP-authenticated communication

Complete EAP communication, including EAP negotiation, occurs through the TLS channel. The IAS server authenticates the user and client computer with the method that is determined by the EAP type and selected for use within PEAP (either EAP-TLS or EAP-MS-CHAPv2). The access point only forwards messages between wireless client and RADIUS server—the access point (or a person monitoring it) cannot decrypt these messages because it is not the TLS end point.

802.11 wireless deployments using PEAP

You can choose between two EAP types for use with PEAP: EAP-MS-CHAPv2 or EAP-TLS. EAP-MS-CHAPv2 uses credentials (user name and password) for user authentication, and a certificate in the server computer certificate store for server authentication. EAP-TLS uses either certificates installed in the client computer certificate store or a smart card for user and client computer authentication, and a certificate in the server computer certificate store for server authentication.

PEAP with EAP-MS-CHAPv2

PEAP with EAP-MS-CHAPv2 (PEAP-EAP-MS-CHAPv2) is easier to deploy than EAP-TLS because user authentication is accomplished with password-based credentials (user name and password) instead of certificates or smart cards—only the IAS or RADIUS server is required to have a certificate. Additionally, the server certificate can be issued by a public certification authority (CA) that is trusted by the client computer (that is, the public CA certificate already exists in the Trusted Root Certification Authority folder on the client computer certificate store). In this case, the server certificate is not downloaded and added to the client trusted root certificate store, and the user is not prompted to make a decision about whether to trust the server.

PEAP-EAP-MS-CHAPv2 provides improved security over MS-CHAPv2 by using mutual authentication, preventing an unauthorized server from negotiating the least secure authentication method, and providing key generation with TLS. PEAP-EAP-MS-CHAPv2 requires that the client trust certificates provided by the server.

For server and client computer certificate requirements, see Network access authentication and certificates. For an example wireless access policy using PEAP-EAP-MS-CHAPv2, see Wireless access with secure password authentication.

PEAP with EAP-TLS

Public Key certificates provide a much stronger authentication method than those that use password-based credentials. PEAP with EAP-TLS (PEAP-EAP-TLS) uses certificates for server authentication and either certificates or smart cards for user and client computer authentication. To use PEAP-EAP-TLS, you must deploy a public key infrastructure (PKI).

For more information, see Network access authentication and certificates.

PEAP fast reconnect

PEAP fast reconnect enables wireless clients to move between wireless access points on the same network without being reauthenticated each time they associate with a new access point.

Wireless access points are configured as RADIUS clients to RADIUS servers. If a wireless client roams between access points that are configured as clients to the same RADIUS server, the client is not required to be authenticated with each new association. When a client moves to an access point that is configured as a RADIUS client to a different RADIUS server, although the client is reauthenticated, this process occurs much more efficiently.

PEAP fast reconnect reduces the response time for authentication between client and authenticator because the authentication request is forwarded from the new server to the original server. Because both the PEAP client and authenticator use previously cached TLS connection properties (the collection of which is named the TLS handle), the authenticator can quickly determine that the client connection is a reconnect.

If the original PEAP authenticator is unavailable, full authentication must occur between the client and the new authenticator. The new PEAP authenticator's TLS handle is cached by the client. The client can cache TLS handles for multiple PEAP authenticators. For smart carts or PEAP-EAP-MSCHAPv2 authentication, the user is asked to supply the PIN or credentials, respectively.

With PEAP-EAP-MS-CHAPv2 authentication:

When the new access point is a client to the same RADIUS server | When the new access point is a client to a new RADIUS server
The user is not prompted for credentials each time the client computer associates with a new access point. | The user is prompted for credentials on this initial association. The next time the client computer associates with an access point that is a client to this server, user credentials are not required.
The RADIUS server is not required to provide a certificate. | The RADIUS server provides a certificate on this initial association so that the wireless client can authenticate to the RADIUS server. The next time the client computer associates with an access point that is a client to this server, the server is not required to be reauthenticated.

With PEAP-EAP-TLS authentication:

When the new access point is a client to the same RADIUS server | When the new access point is a client to a new RADIUS server
The client and server are not required to exchange certificates. | The client and server exchange certificates on this initial association. The next time the client computer associates with an access point that is a client to this server, certificates are not exchanged.
The user is not prompted for a smart card personal identification number (PIN) each time the client computer associates with a new access point. | The user is prompted for a smart card PIN on this initial association. The next time the client computer associates with an access point that is a client to this server, the user is not prompted for the PIN.

For more information about RADIUS clients, see Components of a RADIUS infrastructure.

For more information about RADIUS proxy servers, see IAS as a RADIUS proxy.

To enable PEAP fast reconnect:

  • Both the PEAP client (802.11 wireless client) and PEAP authenticator (RADIUS server) must have fast reconnect enabled.
  • All access points to which the PEAP client roams must be configured as RADIUS clients to a RADIUS server (the PEAP authenticator) for which PEAP is configured as the authentication method for wireless connections.
  • All access points to which the PEAP client associates must be configured to prefer the same RADIUS server (PEAP authenticator) in order to avoid being prompted for credentials from every RADIUS server. If the access point cannot be configured to prefer a RADIUS server, you can configure an IAS RADIUS proxy with a preferred RADIUS server.

For more information, see To configure PEAP and EAP methods.

Notes

  • When using the PEAP-EAP-TLS and EAP-TLS authentication methods with certificates, TLS uses cached certificate properties instead of reading the certificate from the certificate store. If a certificate is either changed or deleted and replaced by a new one, TLS continues using outdated cached certificate information until the cache expires or is refreshed. If you change or replace a certificate, you can refresh the TLS cache by restarting the server computer.
  • PEAP does not support guest authentication, which has a blank user name and password.
  • When you deploy both PEAP and EAP unprotected by PEAP, do not use the same EAP authentication type with and without PEAP. For example, if you deploy PEAP with EAP-TLS (PEAP-EAP-TLS), do not also deploy EAP-TLS without PEAP. Deploying authentication methods with the same type — one with and the other without the protection of PEAP — creates a security vulnerability.
  • XOX


Remote access policies

This section covers:

  • Introduction to remote access policies
  • Dial-in properties of a user account
  • Elements of a remote access policy
  • Accepting a connection attempt
  • Remote access policies examples


Introduction to remote access policies

In Windows NT versions 3.5, 3.51, and 4.0, authorization was based on a Grant dial-in permission to user option in either User Manager or the Remote Access Admin utility. An individual user configured callback options. For the Routing and Remote Access service and Internet Authentication Service (IAS) in XOX; XOX; XOX; and Windows 2000, network access authorization is granted on the basis of user account dial-in properties and remote access policies.

Remote access policies are an ordered set of rules that define how connections are either authorized or rejected. For each rule, there are one or more conditions, a set of profile settings, and a remote access permission setting.

If a connection is authorized, the remote access policy profile specifies a set of connection restrictions. The dial-in properties of the user account also provide a set of restrictions. Where applicable, user account connection restrictions override the remote access policy profile connection restrictions.

For information about connection restrictions that can be configured on a user account, see Dial-in properties of a user account. For information about connection restrictions that can be configured through a remote access policy profile, see Elements of a remote access policy.

Remote access policies validate a number of connection settings before authorizing the connection, including the following:

  • Remote access permission
  • Group membership
  • Type of connection
  • Time of day
  • Authentication methods
  • Advanced conditions:
    • Access server identity
    • Access client phone number or MAC address
    • Whether user account dial-in properties are ignored
    • Whether unauthenticated access is allowed

After the connection is authorized, remote access policies can also be used to specify connection restrictions, including the following:

  • Idle timeout time
  • Maximum session time
  • Encryption strength
  • IP packet filters
  • Advanced restrictions:
    • IP address for PPP connections
    • Static routes

Additionally, you can vary connection restrictions based on the following settings:

  • Group membership
  • Type of connection
  • Time of day
  • Authentication methods
  • Identity of the access server
  • Access client phone number or MAC address
  • Whether unauthenticated access is allowed

For example, you can have policies that specify different maximum session times for different types of connections or groups. Additionally, you can specify restricted access for business partners or unauthenticated connections.

Authorizing access

There are two ways to use remote access policies to grant authorization:

  1. By user
  2. By group

Authorization by user

If you are managing authorization by user, set the remote access permission on the user or computer account to either Grant access or Deny access and, optionally, create different remote access policies based on different types of connections. For example, you might want to have one remote access policy that is used for dial-up connections and a different remote access policy that is used for wireless connections. Managing authorization by user is recommended only when you have a small number of user or computer accounts to manage.

If you are managing authorization by user, the basic process for authorizing a connection attempt occurs as follows:

  • If the connection attempt matches all policy conditions, check the remote access permission setting of the account.
    • If the remote access permission is set to Grant access, apply the connection settings of the policy profile and user account.
    • If the remote access permission is set to Deny access, reject the connection attempt.
  • If the connection attempt does not match all policy conditions, process the next remote access policy.

If the connection attempt does not match all conditions of any remote access policy, reject the connection attempt.

Authorization by group

If you are managing authorization by group, set the remote access permission on the user account to Control access through Remote Access Policy and create remote access policies that are based on different types of connections and group membership. For example, you might want to have one remote access policy for dial-up connections for employees (members of the Employees group) and a different remote access policy for dial-up connections for contractors (members of the Contractors group).

If you are managing authorization by group, the basic process for authorizing a connection attempt occurs as follows:

  • If the connection attempt matches all policy conditions, check the remote access permission of the remote access policy.
    • If the remote access permission is set to Grant remote access permission, apply the connection settings of the policy profile and user account.
    • If the remote access permission is set to Deny remote access permission, reject the connection attempt.
  • If the connection attempt does not match all policy conditions, process the next remote access policy.

If the connection attempt does not match all conditions of any remote access policy, reject the connection attempt.

Notes

  • Setting the remote access permission on user accounts to Control access through Remote Access Policy and not using groups to manage network access is not recommended.
  • For more information about how connection attempts are processed, see Remote access policies examples.

Remote access policies and the Routing and Remote Access service

For servers running the Routing and Remote Access service that are configured for the Windows authentication provider, remote access policies are administered from Routing and Remote Access and apply only to the connections of the Routing and Remote Access service server. For servers running the Routing and Remote Access service that are configured for the RADIUS authentication provider, you can no longer configure remote access policies using Routing and Remote Access. If the RADIUS server is an IAS server, remote access policies are administered from Internet Authentication Service.

To centrally manage a single set of remote access policies for multiple remote access or VPN servers using an IAS server, you must do the following:

  1. Install the Internet Authentication Service (IAS) as a Remote Authentication Dial-In User Service (RADIUS) server. For more information, see Checklist: Configuring IAS for dial-up and VPN access.
  2. Configure IAS with RADIUS clients that correspond to each of the XOX; XOX; or XOX remote access or VPN servers. For more information, see To add RADIUS clients.
  3. On the IAS server, create the central set of policies that will be used by all servers running the Routing and Remote Access service. For more information, see To add a remote access policy.
  4. Configure each of the servers running the Routing and Remote Access service as RADIUS clients to the IAS server. For more information, see To use RADIUS authentication.

For more information about deploying IAS for centralized remote access policy management, see Using RADIUS for multiple remote access servers.

Centralized management of remote access policies is also used when you have remote access servers that are running Windows NT 4.0 and the Routing and Remote Access Service (RRAS). You can configure this server as a RADIUS client to an IAS server. However, a remote access server running Windows NT 4.0 without RRAS cannot be configured to use centralized remote access policies.


Dial-in properties of a user account

In XOX; XOX; and XOX; the user account for a stand-alone server or server running Active Directory contains a set of dial-in properties that are used when allowing or denying a connection attempt made by a user. On a stand-alone server, you can set the dial-in properties on the Dial-in tab in the user account in Local Users and Groups. On a server running Active Directory, you can set the dial-in properties on the Dial-in tab in the user account in Active Directory Users and Computers. On these servers, you cannot use the Windows NT 4.0 User Manager for Domains administrative tool.

The dial-in properties for a user account are:

  • Remote Access Permission (Dial-in or VPN)

    You can use this property to set remote access permission to be explicitly allowed, denied, or determined through remote access policies. In all cases, remote access policies are used to authorize the connection attempt. If access is explicitly allowed, remote access policy conditions, user account properties, or profile properties can still deny the connection attempt. The Control access through Remote Access Policy option is only available on user accounts in a Windows 2000 native domain, a Windows Server 2003 domain, or for local accounts on stand-alone servers running Windows 2000, XOX; XOX; or XOX.

    By default, the Administrator and Guest accounts on a stand-alone server or in a Windows 2000 native domain are set to Control access through Remote Access Policy. In a Windows 2000 mixed domain, they are set to Deny access. New accounts that are created on a stand-alone server or in a Windows 2000 native domain are set to Control access through Remote Access Policy. New accounts that are created in a Windows 2000 mixed domain are set to Deny access.

    For more information, see Domain and forest functionality.

  • Verify Caller ID

    If this property is enabled, the server verifies the caller's phone number. If the caller's phone number does not match the configured phone number, the connection attempt is denied.

    Caller ID must be supported by the caller, the phone system between the caller and the remote access server, and the remote access server. On a computer running the Routing and Remote Access service, caller ID support consists of call answering equipment that provides caller ID information and the appropriate XOX; XOX; or XOX driver to pass the information to the Routing and Remote Access service.

    If you configure a caller ID phone number for a user, and you do not have support for the passing of caller ID information from the caller to the Routing and Remote Access service, the connection attempt is denied.

  • Callback Options

    If this property is enabled, the server calls the caller back during the connection process. The phone number that is used by the server is set by either the caller or the network administrator.

  • Assign a Static IP Address

    You can use this property to assign a specific IP address to a user when a connection is made.

  • Apply Static Routes

    You can use this property to define a series of static IP routes that are added to the routing table of the server running the Routing and Remote Access service when a connection is made. This setting is designed for user accounts that a router running XOX; XOX; or XOX uses for demand-dial routing. For more information, see One-way initiated demand-dial connections.

For information about configuring dial-in properties for a user account, see Configure dial-in user properties.

Support for ignoring the dial-in properties of user accounts

In XOX; XOX; or XOX; you can configure a RADIUS attribute to ignore the dial-in properties of user and computer accounts in the profile properties of a remote access policy. To support multiple types of connections for which IAS provides authentication and authorization, it might be necessary to disable the processing of user account dial-in properties. This can be done to support scenarios in which specific dial-in properties are not required.

For example, the caller-ID, callback, static IP address, and static routes properties are designed for a client that is dialing into a network access server (NAS). These settings are not designed for wireless access points. A wireless access point that receives these settings in the RADIUS message from the IAS server might be unable to process them, which could cause the wireless client to become disconnected. When IAS provides authentication and authorization for users who are both dialing in and accessing the organization network through wireless technology, the dial-in properties must be configured to support either dial-in connections (by setting dial-in properties) or wireless connections (by not setting dial-in properties).

You can use IAS to enable the processing of dial-in properties for user and computer accounts in some scenarios (such as dial-in), and to disable the processing of dial-in properties for user and computer accounts in other scenarios (such as wireless and authenticating switch). This is done by configuring the Ignore-User-Dialin-Properties attribute on the Advanced tab of the profile settings for a remote access policy. For more information, see To add RADIUS attributes to a remote access policy.

The Ignore-User-Dialin-Properties attribute is set to the following:

  • To enable the processing of dial-in properties for a user account, delete the Ignore-User-Dialin-Properties attribute or set it to False. For example, for a remote access policy that is designed for dial-in connections, no additional configuration is required.
  • To disable the processing of dial-in properties for a user account, set the Ignore-User-Dialin-Properties attribute to the value of True. For example, this is set for the remote access policy that is used for wireless or authenticating switch connections. When the dial-in properties of the user account are ignored, remote access permission is determined by the setting in the remote access policy.

Notes

  • For a user account in a Windows NT 4.0 domain or a Windows 2000 mixed domain:
    • Only the dial-in properties named Remote Access Permission (Dial-in or VPN) (Allow access and Deny access options) and Callback Options are available.
    • You can use the Windows NT 4.0 User Manager for Domains administrative tool to grant or deny dial-in access and set callback options.
  • If a user account is in a Windows 2000 native domain, the callback number can be up to 128 characters in length. If a user account is on a stand-alone remote access server, in a Windows NT 4.0 domain, or in a Windows 2000 mixed domain, the callback number can contain 24 through 48 characters. This is due to the compressed format for storing callback numbers.
  • When a remote access server running Windows NT 4.0 uses a Windows 2000 native domain to obtain the dial-in properties of a user account, the Control access through Remote Access Policy remote access permission setting is retrieved as Deny access. Callback settings are retrieved correctly.

    For more information, see Domain and forest functionality.

  • A remote access server running Windows NT 4.0 cannot use remote access policies. If you upgrade this remote access server with the Routing and Remote Access Service (RRAS) and configure it for RADIUS authentication, you can use the remote access policies of an IAS server. Alternately, you can upgrade this remote access server with a member of the Windows 2000 Server family; XOX; XOX; or XOX.
  • User accounts upgraded to XOX; XOX; or XOX that were configured with dial-in permission enabled are set to Allow access. Those that were configured with dial-in permission disabled are set to Deny access.
  • It is possible to ignore all of the user or computer account properties. For more information, see Ignoring the dial-in properties of user accounts.
  • In XOX; XOX; and XOX; computer accounts also have dial-in properties and are similar to user accounts. This new feature allows computers to be authenticated as if they were users, and is used when an IEEE 802.1x Ethernet client uses EAP-TLS and an installed computer certificate to authenticate itself to an Ethernet switch.
  • The Ignore-User-Dialin-Properties attribute disables the use of all dial-in properties for the user account. Specific dial-in properties cannot be selectively disabled.


Elements of a remote access policy

A remote access policy is a named rule that consists of the following elements:

  • Conditions
  • Remote access permission
  • Profile

Conditions

Remote access policy conditions are one or more attributes that are compared to the settings of the connection attempt. If there are multiple conditions, then all of the conditions must match the settings of the connection attempt in order for it to match the policy.

The following table shows the condition attributes that you can set for a remote access policy.

Attribute name | Description
Authentication Type | The type of authentication that is being used by the access client. Authentication types include CHAP, EAP, MS-CHAP, and MS-CHAP v2.
Called Station ID | The phone number of the network access server (NAS). This attribute is a character string. You can use pattern matching syntax to specify area codes. For more information, see Pattern matching syntax. In order to receive called station ID information during a call, the phone line, the hardware, and the XOX; XOX; or XOX driver for the hardware must support passing the called ID. Otherwise, the called station ID is manually set for each port. To manually set phone numbers on ports, see To set the phone number on a port.
Calling Station ID | The phone number used by the caller. This attribute is a character string. You can use pattern matching syntax to specify area codes. For more information, see Pattern matching syntax. For more information about obtaining the calling station ID, see Caller ID and callback.
Client Friendly Name | The name of the RADIUS client that is requesting authentication. This name is configured in Friendly name on the Settings tab in the properties of a RADIUS client in Internet Authentication Service. This attribute is a character string. You can use pattern matching syntax to specify client names. For more information, see Pattern matching syntax. This attribute is used by the IAS server.
Client IP Address | The IP address of the RADIUS client. This can be the IP address of either the originating RADIUS client or an intermediate RADIUS proxy. This attribute is a character string. You can use pattern matching syntax to specify IP networks. For more information, see Pattern matching syntax. This attribute is used by the IAS server.
Client Vendor | The vendor of the network access server (NAS) that is requesting authentication. The Routing and Remote Access service is the Microsoft NAS manufacturer. You can use this attribute to configure separate policies for different NAS manufacturers who are RADIUS clients to an IAS server. This attribute is used by the IAS server. Ensure that you configure the NAS as a RADIUS client on the IAS server. For more information, see To add RADIUS clients.
Day and Time Restrictions | The day of the week and the time of day of the connection attempt. The day and time is relative to the day and time of the server providing the authorization.
Framed Protocol | The type of framing for incoming packets. Examples are PPP, SLIP, Frame Relay, and X.25. This attribute is used by the IAS server.
NAS Identifier | The name of the network access server (NAS). This attribute is a character string. You can use pattern matching syntax to specify multiple NASs. For more information, see Pattern matching syntax. This attribute is used by the IAS server.
NAS IP Address | The IP address of the NAS (the RADIUS client) that sent the message. This attribute is a character string. You can use pattern matching syntax to specify IP networks. For more information, see Pattern matching syntax. This attribute is used by the IAS server.
NAS Port Type | The type of media that is used by the access client. Examples include analog phone lines (known as async), ISDN, tunnels or virtual private networks (known as virtual), IEEE 802.11 wireless, and Ethernet switches.
Service Type | The type of service that is being requested. Examples include framed (such as PPP connections) and login (such as Telnet connections). For more information about RADIUS service types, see RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)." This attribute is used by the IAS server.
Tunnel Type | The type of tunnel that is being created by the requesting client. Tunnel types include the Point-to-Point Tunneling Protocol (PPTP) and the Layer Two Tunneling Protocol (L2TP), which are used by XOX; XOX; XOX; XOX; and Windows 2000, remote access clients and demand-dial routers. You can use this condition to specify profile settings, such as authentication methods or encryption strengths for a specific type of tunneling technology.
Windows Groups | The names of the groups to which the user or computer account that is attempting the connection belongs. There is no condition attribute for a specific user or computer name. It is not necessary to have a separate remote access policy for each group. Instead, you can use multiple groups or nested groups to consolidate and delegate the administration of group membership. For a remote access or IAS server in a Windows 2000 native domain, you can use universal groups. For more information, see Domain and forest functionality.

Notes

  • If conditions that use an IAS server attribute are evaluated against a Routing and Remote Access service server that is configured for Windows authentication, they do not match and the policy is not applied.
  • Not all access servers send all of the IAS server-specific attributes.
  • You cannot use the built-in local or domain groups for the Windows Groups attribute.

Remote access permission

If all conditions of a remote access policy are met, remote access permission is either granted or denied. You can use either the Grant remote access permission option or the Deny remote access permission option to set remote access permission for a policy.

Remote access permission is also granted or denied for each user account. The user remote access permission overrides the policy remote access permission. When remote access permission on a user account is set to the Control access through Remote Access Policy option, the policy remote access permission determines whether the user is granted access.

Granting access through either the user account permission setting or the policy permission setting is only the first step in accepting a connection. The connection attempt is subject to the settings of both the user account dial-in properties and policy profile properties. If the connection attempt does not match the settings of the user account or policy profile properties, the connection attempt is rejected.

Profile

A remote access policy profile is a set of properties that are applied to a connection when it is authorized—either through the user account or policy permission settings. A profile consists of the following groups of properties:

  • Dial-in constraints
  • IP
  • Multilink
  • Authentication
  • Encryption
  • Advanced

Dial-in constraints

You can set the following dial-in constraints:

  • Minutes server can remain idle before it is disconnected

    • The time after which a connection is disconnected when there is no activity. By default, this property is not set. Additionally, the Routing and Remote Access service does not disconnect an idle connection.

  • Minutes client can be connected

    • The maximum amount of time that a connection is connected. The connection is disconnected by the access server after the maximum session length. By default, this property is not set and there is no maximum session limit.

  • Allow access only on these days and at these times

    • The days of the week and hours of each day that a connection is allowed. If the day and time of the connection attempt do not match the configured day and time limits, the connection attempt is rejected. By default, this property is not set and there are no day or time limits. The Routing and Remote Access service does not disconnect active connections that were previously connected at a time when connection attempts were allowed.

  • Allow access to this number only

    • The specific phone number that a caller must call in order for a connection to be allowed. If the dial-in number of the connection attempt does not match the configured dial-in number, the connection attempt is rejected. By default, this property is not set and all dial-in numbers are allowed.

  • Allow access only through these media

    • The specific types of media, such as modem (also known as async), ISDN, virtual private network (known as virtual), or 802.11 wireless that a caller must use in order for a connection to be allowed. If the dial-in medium of the connection attempt does not match the configured dial-in media, the connection attempt is rejected. By default, this property is not set and all media types are allowed.

For information about setting dial-in constraints on a profile, see To configure dial-in constraints.

IP

You can set IP properties that specify IP address assignment behavior. You have the following options:

  • The access server must supply an IP address.
  • The access client can request an IP address.
  • IP address assignment is determined by the access server (this is the default setting).
  • A static IP address is assigned. A static IP address assigned to the user account overrides this setting. The IP address assigned is typically used to accommodate vendor-specific attributes for IP addresses.

You can also use the IP tab to define IP packet filters that apply to remote access connection traffic. This is intended for use with the Routing and Remote Access service. You can configure IP traffic that is allowed to remote access clients (output filters) or from remote access clients (input filters) on an exception basis. Either all traffic is allowed, except traffic specified by filters; or all traffic is blocked, except traffic specified by filters . Remote access policy profile filtering applies to all remote access connections that match the remote access policy.

Filters configured on the IP tab are applied to client connections on a Windows Server 2003 remote access server, but are not applied to dial-on-demand connections.

For information about setting IP options on a profile, see To configure IP options.

Multilink

You can set Multilink properties that both enable Multilink and determine the maximum number of ports that a Multilink connection can use. Additionally, you can set Bandwidth Allocation Protocol (BAP) policies that both determine BAP usage and specify when extra BAP lines are dropped. The Multilink and BAP properties are specific to the Routing and Remote Access service. By default, Multilink and BAP are disabled.

The Routing and Remote Access service must have Multilink and BAP enabled in order for the Multilink properties of the profile to be enforced. For more information about enabling Multilink and BAP for the Routing and Remote Access service, see To enable Multilink and To enable BAP and BACP.

For information about setting Multilink options on a profile, see To configure Multilink options.

Authentication

You can set authentication properties to both enable the authentication types that are allowed for a connection and specify the EAP type that must be used. Additionally, you can configure the EAP type. By default, Microsoft Encrypted Authentication (MS-CHAP) and Microsoft Encrypted Authentication version 2 (MS-CHAP v2) are enabled. With XOX; XOX; and XOX; you can specify whether users can change their expired passwords using MS-CHAP and MS-CHAP v2 (enabled by default). For more information, see Authentication methods.

The Routing and Remote Access service must have the corresponding authentication types enabled in order for the authentication properties of the profile to be enforced. For more information about enabling authentication methods for the Routing and Remote Access service, see To enable authentication protocols.

For information about setting authentication options on a profile, see To configure authentication.

Encryption

You can set encryption properties for the following encryption strengths:

  • No Encryption

    This option allows a nonencrypted connection. To require encryption, clear this option.

  • Basic

    For dial-up and PPTP-based VPN connections, Microsoft Point-to-Point Encryption (MPPE) is used with a 40-bit key. For L2TP/IPSec VPN connections, 56-bit Data Encryption Standard (DES) encryption is used.

  • Strong

    For dial-up and PPTP VPN connections, MPPE is used with a 56-bit key. For L2TP/IPSec VPN connections, 56-bit DES encryption is used.

  • Strongest

    For dial-up and PPTP VPN connections, MPPE is used with a 128-bit key. For L2TP/IPSec VPN connections, triple DES (3DES) encryption is used.

These settings are intended to be used with Routing and Remote Access. When other access servers are used, select No Encryption and clear all encryption strengths.

For information about setting encryption options on a profile, see To configure encryption.

Advanced

You can set advanced properties to specify the series of RADIUS attributes that are sent back by the IAS server to be evaluated by the RADIUS client. RADIUS attributes are specific to performing RADIUS authentication, and are ignored by a server that is running the Routing and Remote Access service and is configured for Windows authentication. By default, Framed-Protocol is set to PPP and Service-Type is set to Framed.

The only advanced attributes that are used by the Routing and Remote Access service are Account-Interim-Interval, Framed-Protocol, Framed-MTU, Reply-Message, and Service-Type.

For information about setting advanced options on a profile, see To add RADIUS attributes to a remote access policy.

Notes

  • Some elements of a remote access policy correspond to RADIUS attributes that are used during RADIUS-based authentication. For remote access policies on an Internet Authentication Service (IAS) server, verify that the access servers used are sending RADIUS attributes that correspond to the configured remote access policy conditions and profile settings. If a NAS does not send a RADIUS attribute that corresponds to a remote access policy condition or profile setting, then all RADIUS authentications from that NAS are denied.
  • You can only use the Generate-Session-Timeout attribute if your user account database is a Security Accounts Manager (SAM) database or is the user account database for an Active Directory domain. When the value of Generate-Session-Timeout is set to True, the ForceLogoff value for a SAM database should be set to 0. In the Local Security Settings console, ForceLogoff is changed to zero when Network security: Force logoff when logon hours expire is enabled. For information about how to change this setting, see To edit a security setting on a Group Policy object. For information about how to change the ForceLogoff value for the SAM database at the command prompt, see Net accounts.
  • You can configure wireless connection policy so that wireless clients periodically reauthenticate. This ensures that the client Wired Equivalent Privacy (WEP) encryption keys are changed often enough to provide adequate security for the wireless connection. To configure reauthentication, set the session timeout in your remote access policy or connection request policy for wireless connections (using the Session-Timeout attribute) to the required interval (for example, 10 minutes). Additionally, configure the Termination-Action attribute with the Attribute value set to RADIUS-Request. If the Termination-Action attribute is not set to RADIUS-Request, wireless access points might end the connection during reauthentication. For more information, see your hardware documentation.
  • XOX


Accepting a connection attempt

When a user attempts a connection, the connection attempt is accepted or rejected, based on the following logic:

  1. The first policy in the ordered list of remote access policies is checked. If there are no policies, reject the connection attempt.
  2. If all conditions of the policy do not match the connection attempt, go to the next policy. If there are no more policies, reject the connection attempt.
  3. If all conditions of the policy match the connection attempt, check the value of the Ignore-User-Dialin-Properties attribute.
  4. If the Ignore-User-Dialin-Properties attribute is set to False, check the remote access permission setting for the user attempting the connection.
    • If Deny access is selected, reject the connection attempt.
    • If Allow access is selected, apply the user account and profile properties.
      • If the connection attempt does not match the settings of the user account and profile properties, reject the connection attempt.
      • If the connection attempt matches the settings of the user account and profile properties, accept the connection attempt.
    • If the remote access permission is not set to Allow access or Deny access, the remote access permission must be set to Control access through Remote Access Policy. Check the remote access permission setting of the policy.
      • If Deny remote access permission is selected, reject the connection attempt.
      • If Grant remote access permission is selected, apply the user account and profile properties.
        • If the connection attempt does not match the settings of the user account and profile properties, reject the connection attempt.
        • If the connection attempt matches the settings of the user account properties and profile, accept the connection attempt.
  5. If the Ignore-User-Dialin-Properties attribute is set to True, check the remote access permission setting of the policy.
    • If Deny remote access permission is selected, reject the connection attempt.
    • If Grant remote access permission is selected, apply the profile properties.
      • If the connection attempt does not match the settings of the profile properties, reject the connection attempt.
      • If the connection attempt matches the settings of the profile properties, accept the connection attempt.

The following illustration shows the logic of remote access policies.

Remote access policy logic

Notes

  • The profile and user account settings for the first matching policy are applied to the connection. If a connection does not match the profile or user account settings of the remote access policy, the additional remote access policies are not tried.
  • A connection attempt might not match any of the remote access policies. If this is the case, the connection attempt is rejected regardless of the remote access permission setting on the user account.
  • The remote access polices are tried in order. The more specific remote access policies are typically placed in order ahead of the more general remote access policies.
  • The Ignore-User-Dialin-Properties attribute is a new feature for XOX; XOX; and XOX that allows you to ignore all of the dial-in properties of a user account. For more information, see New features.
  • XOX

For examples of how different connection attempts are processed, see Remote access policies examples.


Remote access policies examples

Remote access policies provide a tremendous amount of flexibility in accepting connections based on policy evaluation order, policy conditions, user and policy dial-in permissions, and both policy profile and user account properties.

This section describes some examples in which remote access policies are used:

  • Grant remote access per user
  • Allow dial-up connection using group membership
  • Restrict connections to a maximum session time
  • Wireless access example
  • Wireless access with secure password authentication
  • Ethernet switch access example
  • Force VPN clients to use strongest encryption
  • Apply packet filters for business partner extranet
  • Send NAS-specific RADIUS attributes to a RADIUS client


Grant remote access per user

In this example, the network administrator wants to maintain the same administrative model as used in Windows NT 4.0. Dial-in access is granted on a per-user basis by modifying the remote access permission setting of the user account dial-in properties. The remote access permission is set to either Allow access or Deny access. This is the default behavior for remote access policies.

You can create a policy named Allow access if dial-in permission is enabled. The settings on this policy are configured as follows:

  • A single condition that consists of the Day-And-Time-Restrictions attribute is set for all times on all days.
  • The Deny remote access permission option is selected.
  • The profile is set to the default settings.

When a user attempts a remote access connection, the following logic is used to accept or reject the attempt (assuming that the default settings are set for all the other user account dial-in properties ):

  1. The policy Allow access if dial-in permission is enabled is evaluated.
  2. The settings of the connection attempt match the conditions of the policy (the connection attempt occurs on any day or at any time).
  3. On the user account, the setting in Remote Access Permission (Dial-in or VPN) is evaluated.
    • If Allow access is selected, the connection is accepted, subject to the settings of the user account dial-in and profile properties.
    • If Deny access is selected, the connection is rejected.


Allow dial-up connection using group membership

In this example, the network administrator is managing authorization by using groups. All user accounts have the Remote Access Permission (Dial-in or VPN) option set to Control access through Remote Access Policy.

The network administrator wants to allow dial-up connections for only those user accounts that belong to a specific set of groups. After remote access permission is set for all user accounts, the administrator completes the following steps:

  1. Use the New Remote Access Policy Wizard to create a common dial-up policy with the following settings:
    • Policy name: Dial-up access for allowed groups
    • Access Method: Dial-up access
    • User or Group: Select Group, and then specify the set of groups for which dial-up access is allowed.
    • Authentication methods: Select Microsoft Encrypted Authentication version 2 (MS-CHAP v2) and Microsoft Encrypted Authentication.
    • Policy Encryption Level: Select all check boxes.

    For more information, see To add a remote access policy.

  2. Delete the default policies.

    3. For more information, see To delete a remote access policy.

Notes

  • It is not necessary to have a separate remote access policy for each group. You can specify multiple groups or you can use nested groups to both delegate administration of and consolidate group membership. For a remote access or IAS server in a Windows 2000 native domain or a Windows Server 2003 domain, you can use universal groups. For more information, see Domain and forest functionality.
  • You cannot use built-in local or domain groups when specifying group names.


Restrict connections to a maximum session time

In this example, the network administrator is managing authorization by using groups. All user accounts have the Remote Access Permission (Dial-in or VPN) option set to Control access through Remote Access Policy.

To conserve limited remote access server connection resources, the network administrator wants to limit the maximum session time for all dial-up users (members of the DialUpUsers group) to 20 minutes.

To implement this restriction through a remote access policy, the administrator completes the following steps:

  1. Use the New Remote Access Policy Wizard to create a custom policy with the following settings:
    • Policy name: Maximum session time of 20 minutes
    • Conditions:
      • NAS-Port-Type matches Async (Modem)
      • Windows-Groups matches DialUpUsers
    • Permission: Grant remote access permission
    • Profile settings, Dial-in Constraints tab:
      • Select the Minutes client can be connected check box, and then type 20.

    For more information, see To add a remote access policy.

  2. Delete the default policies.

    3. For more information, see To delete a remote access policy.


Wireless access example

In this example, the network administrator is managing authorization by using groups. All user accounts have the Remote Access Permission (Dial-in or VPN) option set to Control access through Remote Access Policy.

The network administrator requires that all IEEE 802.11 wireless clients (members of the WirelessClients group) use certificate-based authentication through the EAP-TLS authentication protocol and 128-bit encryption. Wireless clients that do not have a user certificate installed are placed on a specific virtual local area network (VLAN) from which they can obtain a user certificate. This unauthenticated connection lasts for 10 minutes.

In this case, two policies are needed:

  1. A policy that requires wireless connections to use EAP-TLS.
  2. A policy that accepts unauthenticated wireless connections and configures the wireless access point for a VLAN with an ID of 3. VLAN 3 contains a certificate server from which the wireless client can obtain a user certificate.

After remote access permission is set for all user accounts, the administrator completes the following steps:

  1. Use the New Remote Access Policy Wizard to create a common wireless policy with the following settings:
    • Policy name: Wireless access
    • Access Method: Wireless access
    • User or Group: Select Group, and then specify the WirelessClients group (example).
    • Authentication methods: Select Smart Card or other Certificate.
    • Policy Encryption Level: Check the Strongest encryption (MPPE 128-bit) check box, and then clear all other check boxes.
  2. Use the New Remote Access Policy Wizard to create a custom wireless policy with the following settings:
    • Policy name: First-time wireless access
    • Conditions:
      • NAS-Port-Type matches Wireless-Other or Wireless-IEEE 802.11
      • Windows-Groups matches WirelessUsers
      • Authentication-Type matches Unauthenticated
    • Permission: Grant remote access permission
    • Profile settings, Dial-in Constraints tab:
      • Select the Minutes client can be connected check box, and then type 10.
    • Profile settings, Advanced tab:
      • Add the Tunnel-Type attribute with the value of Virtual LANs (VLAN).
      • Add the Tunnel-Pvt-Group-ID attribute with the value of 3.
  3. Delete the default policies.

    4. For more information, see To delete a remote access policy.

Notes

  • For this example, a public key infrastructure (PKI) that has allocated the required computer certificate to the IAS server is being used. Additionally, the wireless access point is configured to use both an IAS server as its RADIUS server and EAP. For more information about wireless access deployment, see Checklist: Configuring the IAS server and wireless access points for wireless access.
  • You can configure wireless connection policy so that wireless clients periodically reauthenticate. This ensures that the client Wired Equivalent Privacy (WEP) encryption keys are changed often enough to provide adequate security for the wireless connection. To configure reauthentication, set the session timeout in your remote access policy or connection request policy for wireless connections (using the Session-Timeout attribute) to the required interval (for example, 10 minutes). Additionally, configure the Termination-Action attribute with the Attribute value set to RADIUS-Request. If the Termination-Action attribute is not set to RADIUS-Request, wireless access points might end the connection during reauthentication. For more information, see your hardware documentation.


Wireless access with secure password authentication

In this example, the network administrator is managing authorization by using groups. All user accounts have the Remote Access Permission (Dial-in or VPN) option set to Control access through Remote Access Policy.

The network administrator requires that all IEEE 802.11 wireless clients (members of the WirelessClientsGroupName) use Protected Extensible Authentication Protocol, or PEAP, for secure password authentication on the network. PEAP uses Transport Level Security (TLS) to create an end-to-end (EAP client to EAP authenticator) encrypted connection after verifying the identity of the authenticator (typically, an IAS server). The IAS server authenticates itself to the client with a certificate that includes the Server Authentication purpose in Enhanced Key Usage (EKU) extensions.

Because PEAP is used with EAP-MS-CHAPv2 as the authentication type, user authentication is accomplished with password-based credentials that are typed by the user. PEAP with EAP-MS-CHAPv2, also called PEAP-EAP-MS-CHAPv2, eliminates the need to deploy certificates to wireless clients for the purpose of client computer and user authentication.

For more information, see Network access authentication and certificates.

Note

  • You can also use PEAP with EAP-TLS (also known as PEAP-EAP-TLS), which provides strong security. PEAP-EAP-TLS uses a public key infrastructure with certificates, which are used for server authentication, and either smart cards or certificates for client computer and user authentication. When you use PEAP-EAP-TLS, client certificate information is encrypted, providing improved security over EAP-TLS without PEAP.

After remote access permission is set for all user accounts, the administrator completes the following steps:

  1. Use the New Remote Access Policy Wizard to create a common wireless policy with the following settings:
    • Policy name: Wireless access
    • Access Method: Wireless access
    • User or Group: Select Group, and then specify the WirelessClients group (example).
    • Authentication methods: Select Protected Extensible Authentication Protocol (PEAP).
    • Policy Encryption Level: Check the Strongest encryption (MPPE 128-bit) check box, and then clear all other check boxes.
  2. Delete the default policies.

    3. For more information, see To delete a remote access policy.

When you select PEAP as the authentication method, the default authentication type is EAP-MS-CHAPv2. The following defaults are used:

  • Number of authentication retries: 0
  • Allow client to change password (not selected)

To change these settings, complete the steps in To configure PEAP and EAP methods.

Notes

  • Although the deployment of certificates for user and client computer authentication is more difficult than using PEAP with EAP-MS-CHAPv2, certificates are more secure and PEAP with EAP-TLS with smart cards or certificates is the recommended authentication method for wireless clients.
  • You can configure wireless connection policy so that wireless clients periodically reauthenticate. This ensures that the client Wired Equivalent Privacy (WEP) encryption keys are changed often enough to provide adequate security for the wireless connection. To configure reauthentication, set the session timeout in your remote access policy or connection request policy for wireless connections (using the Session-Timeout attribute) to the required interval (for example, 10 minutes). Additionally, configure the Termination-Action attribute with the Attribute value set to RADIUS-Request. If the Termination-Action attribute is not set to RADIUS-Request, wireless access points might end the connection during reauthentication. For more information, see your hardware documentation.


Ethernet switch access example

In this example, the network administrator is managing authorization by using groups. All computer accounts have the Remote Access Permission (Dial-in or VPN) option set to Control access through Remote Access Policy.

The network administrator wants all Ethernet switch clients (members of the SwitchClients group) to use password-based authentication through the Extensible Authentication Protocol (EAP) and the Message Digest 5 (MD5) Challenge EAP type. After remote access permission is set for all computer accounts, the administrator completes the following steps:

  1. Use the New Remote Access Policy Wizard to create a common dial-up policy with the following settings:
    • Policy name: Ethernet access for switch clients
    • Access Method: Ethernet
    • User or Group: Select Group, and then specify the SwitchClients group (example).
    • Authentication methods: Select the MD5-Challenge EAP type.

    For more information, see To add a remote access policy.

  2. Delete the default policies.

    3. For more information, see To delete a remote access policy.

Note

  • This example assumes that the Ethernet switch has been configured to use both EAP and an IAS server as its RADIUS server. For more information about Ethernet switch deployment, see Ethernet switch access.


Force VPN clients to use strongest encryption

In this example, the network administrator is managing authorization by using groups. All user accounts have the Remote Access Permission (Dial-in or VPN) option set to Control access through Remote Access Policy.

The network administrator wants all virtual private network (VPN) clients (members of the group VPNClients) to use strong encryption. For PPTP connections, 128-bit Microsoft Point-to-Point Encryption (MPPE) must be used. For L2TP over IPSec connections, Triple DES (3DES) must be used. After remote access permission is set for all user accounts, the administrator completes the following steps:

  1. Use the New Remote Access Policy Wizard to create a common VPN policy with the following settings:
    • Policy name: VPN access with strongest encryption
    • Access Method: VPN access
    • User or Group: Select Group, and then specify the VPNClients group (example).
    • Authentication methods: Select Microsoft Encrypted Authentication version 2 (MS-CHAP v2) and Microsoft Encrypted Authentication.
    • Policy Encryption Level: Select the Strongest encryption (IPSec triple DES or MPPE 128-bit) check box, and then clear all other check boxes.

    For more information, see To add a remote access policy.

  2. Delete the default policies.

    3. For more information, see To delete a remote access policy.


Apply packet filters for business partner extranet

In this example, the network administrator is managing authorization by using groups. All user accounts have the Remote Access Permission (Dial-in or VPN) option set to Control access through Remote Access Policy.

The network administrator wants to restrict access for all business partner virtual private network (VPN) connections to the resources of an extranet—a specific network segment that contains Web and file servers. In this example, the extranet is the subnet of 192.168.47.0/24. All business partner user accounts are members of the Partners group.

After remote access permission is set for all user accounts, the administrator completes the following steps:

  1. Use the New Remote Access Policy Wizard to create a custom policy with the following settings:
    • Policy name: Business partner connections to extranet
    • Conditions:
      • Windows-Groups matches Partners
    • Permission: Grant remote access permission
    • Profile settings, Dial-in Constraints tab:
      • Select Allow access only through these media and the Virtual (VPN) media type.
    • Profile settings, IP tab:
      • Input packet filter:
        • Deny all traffic except those listed below
        • Destination network, IP address: 192.168.47.0
        • Destination network, Subnet mask: 255.255.255.0
        • Protocol: Any
      • Output packet filter:
        • Deny all traffic except those listed below
        • Source network, IP address: 192.168.47.0
        • Source network, Subnet mask: 255.255.255.0
        • Protocol: Any
    • Profile settings, Authentication tab:
      • Select both Microsoft Encrypted Authentication version 2 (MS-CHAP v2) and Microsoft Encrypted Authentication. For both of these authentication types, select User can change password after it has expired.
      • Clear all other check boxes.
    • Profile settings, Encryption tab:
      • Select the Strongest encryption check box, and then clear all other check boxes.

    For more information, see To add a remote access policy.

  2. Delete the default policies.

    3. For more information, see To delete a remote access policy.


Send NAS-specific RADIUS attributes to a RADIUS client

In this example, the network administrator is managing authorization by using groups. All user accounts have the Remote Access Permission (Dial-in or VPN) option set to Control access through Remote Access Policy.

The network administrator wants to allow dial-up connections for only those user accounts in the DialUpUsers group and send a series of network access server (NAS) attributes that are specific to the Ascend NAS. After remote access permission is set for all user accounts, the administrator completes the following steps:

  1. When the NAS is added as a RADIUS client, configure its manufacturer.

    2. For more information about configuring a RADIUS client for an IAS server, see To add RADIUS clients.

  2. Use the New Remote Access Policy Wizard to create a custom policy with the following settings:
    • Policy name: Allow dial-up connections and send attributes to Ascend NAS
    • Conditions:
      • Client-Vendor matches Ascend Communications, Inc.
      • NAS-Port-Type matches Async (Modem)
      • Windows-Groups matches DialUpUsers
    • Permission: Grant remote access permission
    • Profile settings, Advanced tab:
      • Add the appropriate Ascend RADIUS attributes with their correct values.

    For more information, see To add a remote access policy.

  3. Delete the default policies.

    4. For more information, see To delete a remote access policy.


Connection request processing

This section covers:

  • Introduction to connection request processing
  • Processing a connection request
  • Elements of connection request processing
  • Connection request processing examples


Introduction to connection request processing

In Windows 2000, Internet Authentication Service (IAS) can only be used as a RADIUS server. In XOX; XOX; and XOX, IAS can be used as either a RADIUS server or a RADIUS proxy.

When IAS is used as a RADIUS server:

  • Access-Request messages are authenticated through Active Directory or a Windows NT Server 4.0 domain, or through the Security Account Manager (SAM) in XOX; XOX; or XOX. They are authorized with the user or computer account dial-in properties and remote access policies. Additionally, IAS can return an Access-Accept message without authenticating and authorizing the Access-Request message.
  • Accounting-Request messages are logged in a local log file based on remote access logging settings.

Note

  • IAS can be configured for separate use as an authentication RADIUS server or an accounting RADIUS server.

When IAS is used as a RADIUS proxy:

  • Access-Request messages are forwarded to another RADIUS server for authentication and authorization.
  • Accounting-Request messages are logged in a local log file (based on remote access logging settings) and forwarded to another RADIUS server for accounting.

Note

  • IAS can be configured for separate use as an authentication RADIUS proxy or an accounting RADIUS proxy.

To determine whether a specific connection attempt request or an accounting message received from a RADIUS client should be processed locally or forwarded to another RADIUS server, the IAS server uses connection request processing. Connection request processing is a combination of:

  • Connection request policies

    • Connection request policies determine, for any incoming RADIUS request message, whether the message is processed locally or forwarded to another RADIUS server. For more information, see Connection request policies.

  • Remote RADIUS server groups

    • Remote RADIUS server groups specify multiple RADIUS servers when an incoming RADIUS request message is forwarded. For more information, see Remote RADIUS server groups.

Note

  • XOX


Processing a connection request

When an IAS server receives a valid RADIUS request message from a RADIUS client, it is processed as follows:

  1. The first policy in the ordered list of connection request policies is checked. If there are no policies and the RADIUS message is an Access-Request message, an Access-Reject message is immediately sent. If there are no policies and the RADIUS message is an Accounting-Request message, the message is discarded.
  2. If all conditions of the policy do not match the RADIUS request message, then go to the next policy. If there are no additional policies and the RADIUS message is an Access-Request message, an Access-Reject message is immediately sent. If there are no additional policies and the RADIUS message is an Accounting-Request message, the message is discarded.
  3. If all conditions of the policy match the RADIUS request message, then apply the attribute manipulation rules that are configured in the policy.
  4. If the RADIUS message is an Access-Request message, check the authentication settings on the profile of the matching policy.
    • If the authentication setting requires using this server for authentication, use a Windows NT 4.0 domain or the Active Directory directory service, or the local Security Account Manager (SAM) on XOX; XOX; or XOX; for authentication. Use the matching remote access policy and user or computer account dial-in properties for authorization. For more information, see Accepting a connection attempt.
    • If the authentication setting requires forwarding the Access-Request message to a remote RADIUS server group, forward the Access-Request message to a member of the remote RADIUS server on the basis of priority and weight settings.
    • If the authentication setting requires accepting the connection attempt without performing authentication or authorization, an Access-Accept message is immediately sent.
  5. If the RADIUS message is an Accounting-Request message, check the accounting settings on the profile of the matching policy.
    • If the accounting settings specify that accounting information is to be sent to a member of a remote RADIUS server group, forward the accounting message to the appropriate RADIUS server in the group on the basis of priority and weight settings.
    • Based on the settings for remote access logging, record the information in the local accounting log file.

The following illustration shows the logic of connection request policies.

Connection request policy logic

For examples of how different connection requests are processed, see Connection request processing examples.

Note

  • XOX


Elements of connection request processing

This section covers:

  • Connection request policies
  • Remote RADIUS server groups


Connection request policies

Connection request policies are sets of conditions and profile settings that give network administrators flexibility in configuring how incoming authentication and accounting request messages are handled by the IAS server. With connection request policies, you can create a series of policies so that some RADIUS request messages sent from RADIUS clients are processed locally (IAS is being used as a RADIUS server) and other types of messages are forwarded to another RADIUS server (IAS is being used as a RADIUS proxy). This capability allows IAS to be deployed in many new RADIUS scenarios.

With connection request policies, you can use IAS as a RADIUS server or as a RADIUS proxy, based on the time of day and day of the week, by the realm name in the request, by the type of connection being requested, by the IP address of the RADIUS client, and so on.

It is important to remember that with connection request policies, a RADIUS request message is processed only if the settings of the incoming RADIUS request message match at least one of the connection request policies. For example, if the settings of an incoming RADIUS Access-Request message do not match at least one of the connection request policies, an Access-Reject message is sent.

For more information about how incoming RADIUS request messages from RADIUS clients are processed, see Processing a connection request.

To create a connection request policy, see Configure connection request policies.

A connection request policy is a named rule that consists of the following elements:

  • Conditions
  • Profile

Connection request policies, like remote access policies, operate on the following principle:

  • Based on the RADIUS request message matching all of the conditions of a connection request policy, the profile settings of the policy are applied to determine the processing of the message.

Conditions

Connection request policy conditions are one or more RADIUS attributes that are compared to the attributes of the incoming RADIUS request message. If there are multiple conditions, then all of the conditions must match the attributes of the incoming RADIUS message in order for the RADIUS request message to match the policy.

The following table shows the condition attributes that you can set for a connection request policy.

Attribute name | Description
Called Station ID | The phone number of the network access server (NAS). This attribute is a character string. You can use pattern matching syntax to specify area codes. For more information, see Pattern matching syntax.
Calling Station ID | The phone number used by the caller (the access client). This attribute is a character string. You can use pattern matching syntax to specify area codes. For more information, see Pattern matching syntax.
Client Friendly Name | The name of the RADIUS client computer that is requesting authentication. This attribute is a character string. You can use pattern matching syntax to specify client names. For more information, see Pattern matching syntax.
Client IP Address | The IP address of the network access server (the RADIUS client). This attribute is a character string. You can use pattern matching syntax to specify IP networks. For more information, see Pattern matching syntax.
Client Vendor | The vendor of the network access server (NAS) that is requesting authentication. A computer running the Routing and Remote Access service is the Microsoft NAS manufacturer. You can use this attribute to configure separate policies for different NAS manufacturers. This attribute is a character string. You can use pattern matching syntax. For more information, see Pattern matching syntax.
Day and Time Restrictions | The day of the week and the time of day of the connection attempt. The day and time is relative to the day and time of the IAS server.
Framed Protocol | The type of framing for incoming packets. Examples are PPP, SLIP, Frame Relay, and X.25.
NAS Identifier | The name of the network access server (NAS). This attribute is a character string. You can use pattern matching syntax to specify NAS identifiers. For more information, see Pattern matching syntax.
NAS IP Address | The IP address of the network access server (the RADIUS client). This attribute is a character string. You can use pattern matching syntax to specify IP networks. For more information, see Pattern matching syntax.
NAS Port Type | The type of media used by the access client. Examples are analog phone lines (known as async), ISDN, tunnels or virtual private networks (known as virtual), IEEE 802.11 wireless, and Ethernet switches.
Remote RADIUS to Windows User Mapping | Specifies that Windows authorization occurs for users authenticated by a remote RADIUS server. For example, visitors to your network from partner organizations can be authenticated by their organization's RADIUS server, and can use a Windows user account at your organization to access a guest local area network (LAN) on your network. For more information, see Mapping network authentication and authorization
Service Type | The type of service being requested. Examples include framed (for example, PPP connections) and login (for example, Telnet connections). For more information about RADIUS service types, see RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)."
Tunnel Type | The type of tunnel that is being created by the requesting client. Tunnel types include the Point-to-Point Tunneling Protocol (PPTP) and the Layer Two Tunneling Protocol (L2TP), used by XOX; XOX; XOX; XOX; and Windows 2000 remote access clients and demand-dial routers.
User Name | The user name that is used by the access client in the RADIUS message. This attribute is a character string that typically contains a realm name and a user account name. For more information about realm names, see Realm names. You can use pattern matching syntax to specify user names. For more information, see Pattern matching syntax.

Profile

A connection request policy profile is a set of properties that are applied to an incoming RADIUS message. A connection request policy profile consists of the following groups of properties:

  • Authentication
  • Accounting
  • Attribute manipulation
  • Advanced

Authentication

You can set the following authentication options that are used for RADIUS Access-Request messages:

  • Authenticate requests on this server.

    • Use a Windows NT 4.0 domain or the Active Directory directory service, or the local Security Account Manager (SAM) on XOX; XOX; or XOX; for both authentication and the matching remote access policy and user account dial-in properties for authorization. In this case, the IAS server is being used as a RADIUS server.

  • Forward requests to another RADIUS server in a remote RADIUS server group.

    • Forward the Access-Request message to another RADIUS server in a specified remote RADIUS server group. If the IAS server receives a valid Access-Accept message that corresponds to the Access-Request message, the connection attempt is considered authenticated and authorized. In this case, the IAS server is being used as a RADIUS proxy.

  • Accept the connection attempt without performing authentication or authorization.

    • Do not check authentication of the user credentials and authorization of the connection attempt. An Access-Accept message is immediately sent to the RADIUS client. This setting is used for some types of compulsory tunneling where the access client is tunneled before the user's credentials are authenticated. For more information, see IAS and tunnels.

    This authentication option cannot be used when the access client’s authentication protocol is MS-CHAP v2 or EAP-TLS, both of which provide mutual authentication. In mutual authentication, the access client proves that it is a valid access client to the authenticating server (the IAS server), and the authenticating server proves that it is a valid authenticating server to the access client. When this authentication option is used, the Access-Accept message is returned. However, the authenticating server does not provide validation to the access client and mutual authentication fails.

For information about configuring authentication settings on a connection request profile, see To configure authentication.

Accounting

You can set the following accounting options that are used for RADIUS Accounting-Request messages:

  • Forward accounting information in a specific remote RADIUS server group.

    • Pass the accounting request to another RADIUS server in a specified remote RADIUS server group. In this case, the IAS server is acting as a RADIUS proxy.

Note

  • IAS always records the accounting information for Accounting-Request messages in local log files on the basis of remote access logging settings. For more information, see To select requests to be logged.

For information about setting accounting settings on a connection request profile, see To configure accounting.

Attribute manipulation

You can configure a set of find and replace rules that manipulate the text strings of one of the following attributes:

  • User Name
  • Called Station ID
  • Calling Station ID

Find and replace rule processing occurs for one of the above attributes before the RADIUS message is subject to authentication and accounting settings.

Configuring attribute manipulation for the User Name attribute is equivalent to configuring realm replacement rules for IAS in Windows 2000.

If you are using the MS-CHAP v2 authentication protocol, you cannot manipulate the User Name attribute if the connection request policy is used to forward the RADIUS message. The only exception occurs when a backslash (\) character is used and the manipulation only affects the information to the left of it. A backslash character is typically used to indicate a domain name (the information to the left of the backslash character) and a user account name within the domain (the information to the right of the backslash character). In this case, only attribute manipulation rules that modify or replace the domain name are allowed.

For information about configuring attribute manipulation settings on a connection request profile, see To configure attribute manipulation. For information about the syntax of find and replace rules, see Pattern matching syntax.

Notes

  • Find and replace rules apply only to a single attribute. You cannot configure find and replace rules for each attribute.
  • You cannot add to the list of attributes available for manipulation.

Advanced

You can set advanced properties to specify the series of RADIUS attributes that are:

  • Added to the RADIUS response message when the IAS server is being used as a RADIUS authentication or accounting server.

    • When there are attributes specified on both a remote access policy and the connection request policy, the attributes that are sent in the RADIUS response message are the combination of the two sets of attributes.

  • Added to the RADIUS message when the IAS server is being used as a RADIUS authentication or accounting proxy. If the attribute already exists in the message that is forwarded, it is replaced with the value of the attribute specified in the connection request policy.

For information about setting advanced options on a profile, see To configure advanced attributes.

The default connection request policy

A default connection request policy named Use Windows authentication for all users is created when you install IAS. This policy has the following configuration:

  • The Day-and-Time-Restrictions condition is set to all times and all days.
  • Authentication is set to authenticate requests on this server.
  • Accounting is not set to forward accounting information to a remote RADIUS server group.
  • Attribute manipulation rules are not configured.
  • Advanced attributes are not configured.

The default connection request policy uses IAS as a RADIUS server. To configure an IAS server to act as a RADIUS proxy, you must also configure a remote RADIUS server group. You can create a new remote RADIUS server group while you are creating a new connection request policy with the New Connection Request Policy Wizard. You can either delete the default connection request policy or verify that the default connection request policy is the last policy processed. For an example of a connection request policy that uses IAS as a RADIUS proxy, see Remote RADIUS server.

Note

  • If IAS and the Routing and Remote Access service are installed on the same computer, and the Routing and Remote Access service is configured for Windows authentication and accounting, it is possible for Routing and Remote Access service authentication and accounting requests to be forwarded to a RADIUS server. This can occur when Routing and Remote Access service authentication and accounting requests match a connection request policy that is configured to forward them to a remote RADIUS server group.


Remote RADIUS server groups

A remote RADIUS server group is a named group that contains one or more RADIUS servers. When IAS is being used as a RADIUS proxy for RADIUS request messages, a remote RADIUS server group must be specified. This group is used to facilitate the common configuration of both a primary and at least one backup RADIUS server. You can specify various settings to either determine the order in which the servers are used or distribute the RADIUS messages across all servers in the group.

Each server in the group has the following settings:

  • Name or address

    • Each group member must have a unique name within the group. The name can be an IP address or a name that can be resolved to its IP address. For more information, see To configure the name of a group member.

  • Authentication and accounting

    • When IAS is used as a RADIUS proxy, it is acting as a RADIUS client to another RADIUS server. Therefore, each group member must be configured to send RADIUS messages to the correct User Datagram Protocol (UDP) port that is used by the RADIUS server for RADIUS traffic. Additionally, each group member must be configured for the correct shared secret. The default authentication port is 1812. The default accounting port is 1813. For more information, see To configure the authentication and accounting settings of a group member.

  • Load balancing

    • A priority setting is used to indicate which member of the group is the primary server (the priority is set to 1). For group members that have the same priority, a weight setting is used to calculate how often RADIUS messages are sent to each of them. You can use additional settings to configure the way in which the IAS server detects when a group member first becomes unavailable and when it becomes available after it has been determined to be unavailable. For more information, see To configure the load balancing properties of a group member.

After a remote RADIUS server group is configured, it can be specified in the authentication and accounting settings of a connection request policy. Because of this, you can configure a remote RADIUS server group first. Next, you can configure the connection request policy to use the newly configured remote RADIUS server group. Alternately, you can use the New Connection Request Policy Wizard to create a new remote RADIUS server group while you are creating the connection request policy.

For information about creating a remote RADIUS server group, see To add a remote RADIUS server group.

Note

  • Remote RADIUS server groups are separate from Windows groups.


Connection request processing examples

This section covers:

  • Remote RADIUS server
  • Disabling caller-set callback
  • Compulsory tunnels


Remote RADIUS server

To provide RADIUS authentication, authorization, and accounting for an outsourced dial-up and Internet vendor, an IAS server computer that is used as a RADIUS proxy is placed in the organization's perimeter network. To forward RADIUS request messages, where the User-Name attribute contains the realm name example.microsoft.com, to a remote RADIUS server group that corresponds to primary and backup IAS servers inside an organization intranet, the following connection request policy is configured:

  1. Use the New Remote RADIUS Server Group Wizard to create a new remote RADIUS server group named Intranet IAS servers. Configure the group with primary and backup servers that correspond to the two IAS server computers in the organization intranet.

    2. For more information, see To add a remote RADIUS server group.

  2. Use the New Connection Request Policy Wizard to create a new connection request policy named Forward to intranet IAS servers. Configure the policy to forward RADIUS requests, configure the realm name of example.microsoft.com (but do not remove the realm name before authentication), and select the remote RADIUS server group named Intranet IAS servers.

    3. For more information, see To add a connection request policy.

Based on this connection request policy, all RADIUS request messages that contain the realm name example.microsoft.com in the User-Name attribute are forwarded to an IAS server in the organization intranet.

  • Delete the default policy named Use Windows authentication for all users.

For more information, see To delete a connection request policy.


Disabling caller-set callback

In this example, a network administrator wants to disable the use of callback when callback settings are determined by the dial-up access client (also known as caller-set callback). If caller-set callback is not being used, do not disable or modify the use of callback.

To implement this connection request policy example, complete the following steps:

  1. Use the New Connection Request Policy Wizard to create a new common connection request policy named Forward to intranet IAS servers. Configure the policy to forward RADIUS requests, configure the realm name of example.microsoft.com, and select the remote RADIUS server group named Intranet IAS servers. Do not remove the realm name before authentication.

    2. For more information, see To add a connection request policy.

  2. Use the New Remote RADIUS Server Wizard to create a new remote RADIUS server group named Intranet IAS servers. Configure the group with primary and backup servers that correspond to the two IAS server computers in the organization intranet.

    3. For more information, see To add a remote RADIUS server group.

  3. Create a new custom connection request policy with the following settings:
    • Policy name: Forward to intranet IAS servers but remove caller-set callback
    • Conditions:
      • User-Name matches example.microsoft.com
      • Service-Type matches Callback Login
    • Profile settings, Authentication tab:
      • Select Forward requests to the following remote RADIUS server group for authentication, and then select the Intranet IAS servers group.
    • Profile settings, Accounting tab:
      • Select Record accounting information on the servers in the following remote RADIUS server group, and then select the Intranet IAS servers group.
    • Profile settings, Attribute tab:
      • Select the User-Name attribute and add a find and replace rule that finds example.microsoft.com and replaces it with nothing.
    • Profile settings, Advanced tab:
      • Add the Service-Type attribute with the value Framed.

    For more information, see To add a connection request policy.

  4. Delete the default policy named Use Windows authentication for all users.

    5. For more information, see To delete a connection request policy.

Based on this connection request policy, all RADIUS request messages that contain the realm name example.microsoft.com in the User-Name attribute are forwarded to an IAS server in the organization intranet. When the Access-Accept message is sent to the IAS server computer in the perimeter network, the Callback-ID and Callback-Number RADIUS attributes in the message are set to blank values—effectively disabling callback.


Compulsory tunnels

In this example, a network administrator wants to enable the use of compulsory tunnels for organization employees when they dial an outsourced Internet vendor.

To provide RADIUS authentication, authorization, and accounting for the outsourced dial-up and Internet vendor, an IAS server computer, used as a RADIUS proxy, is placed on the organization's perimeter network. A connection request policy is configured on the IAS server computer to forward RADIUS request messages, where the User-Name attribute contains the realm name example.microsoft.com, to a remote RADIUS server group that corresponds to primary and backup IAS servers inside an organization intranet. The policy is also configured to add the set of attributes required in creating a compulsory tunnel to a VPN server with the Layer Two Tunneling Protocol (L2TP). The VPN server has the IP address of 131.107.9.41 and uses the example tunnel password of og*37y#cW@95?4xT.

To implement this connection request policy example, complete the following steps:

  1. Use the New Remote RADIUS Server Wizard to create a new remote RADIUS server group named Intranet IAS servers. Configure the group with primary and backup servers that correspond to the two IAS server computers in the organization intranet.

    2. For more information, see To add a remote RADIUS server group.

  2. Use the New Connection Request Policy Wizard to create a new connection request policy named Forward to intranet IAS servers. Configure the policy to forward RADIUS requests and the realm name of example.microsoft.com, and then select the remote RADIUS server group named Intranet IAS servers. Do not remove the realm name before authentication.

    3. For more information, see To add a connection request policy.

  3. Configure the advanced properties for the profile of the connection request policy named Forward to intranet IAS servers with the following:
    • Add the Framed-Protocol attribute with the value set to PPP.
    • Add the Service-Type attribute with the value set to Outbound-User.
    • Add the Tunnel-Medium-Type attribute with the value set to IP.
    • Add the Tunnel-Password attribute with the value set to og*37y#cW@95?4xT.
    • Add the Tunnel-Server-Endpt attribute with the value set to 131.107.9.41.
    • Add the Tunnel-Type attribute with the value set to Layer Two Tunneling Protocol (L2TP).

    For more information, see To configure advanced attributes.

  4. Delete the default policy named Use Windows authentication for all users.

    5. For more information, see To delete a connection request policy.

Based on this connection request policy, all RADIUS request messages that contain the realm name example.microsoft.com in the User-Name attribute are forwarded to an IAS server in the organization intranet. When the Access-Accept message is sent back to the IAS server computer in the perimeter network, the set of attributes that are used to create a compulsory tunnel are added to the message before they are returned to the outsourced vendor's Front End Processor (FEP).

For more information about compulsory tunneling, see IAS and tunnels.


Remote access logging

This section contains information about remote access logging in IAS. There are three types of logging:

  1. Event logging for IAS

    2. Event logging is the recording of IAS events in the system event log. It is used primarily for auditing and troubleshooting connection attempts.

  2. Logging user authentication and accounting requests

    3. Recording user authentication and accounting requests in log files is used primarily for connection analysis and billing purposes, and is also useful as a security investigation tool, providing you with a method of tracking down the activity of a malicious user after an attack.

  3. SQL Server database logging

    4. Recording user authentication and accounting requests in a SQL Server XML-compliant database enables multiple IAS servers to share one data source, and provides the advantages of using a relational database.

Note

  • XOX


Event logging for IAS

IAS errors are automatically recorded in the XOX;XOX; and XOX system event logs. IAS authentication events are recorded in the system event log on the basis of event logging settings. You can individually enable the logging of:

  • Rejected or discarded authentication events

    • These events are useful for understanding why a particular request was rejected or ignored. Requests can be rejected or ignored for many reasons, including the following:

    • The RADIUS message is not formatted according to RFCs 2865 or 2866.
    • The RADIUS client is unknown.
    • The RADIUS client has multiple IP addresses and sent the request on an address other than the one defined in IAS.
    • The shared secret is invalid.
    • The message authenticator (also known as a digital signature) sent by the client is invalid.
    • IAS was unable to locate the user name's domain.
    • IAS was unable to connect to the user name's domain.
    • IAS was unable to access the user account in the domain.

    If the request was rejected, the information in the event text includes the user name, access server identifiers, the authentication type, the name of the first matching remote access policy, the reason for the rejection, and other information.

    The logging of rejected or discarded authentication events is enabled by default.

    Secure channel (Schannel) is a security support provider (SSP) that supports a set of Internet security protocols, such as Secure Sockets Layer (SSL) and Transport Level Security (TLS). These protocols provide identity authentication and secure, private communication through encryption.

    Logging of client certificate validation failures is a secure channel event, and is not enabled on the IAS server by default. You can enable additional secure channel events by changing the following registry key value from 1 (REG_DWORD type, data 0x00000001) to 3 (REG_DWORD type, data 0x00000003):

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\EventLogging

    Caution

    • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

    For more information, see The registry.

  • Successful authentication requests

    • If the request was accepted, the information in the event text includes the user name, access server identifiers, the authentication type, and the name of the first matching remote access policy.

    The logging of successful authentication events is enabled by default.

For information about configuring event logging options for IAS, see To configure event logging for IAS.

For information about how to view event logs in XOX; XOX; and XOX; see Event Viewer.

For more information about troubleshooting IAS, see Troubleshooting.


Logging user authentication and accounting requests

You can use IAS to create log files based on the authentication and accounting requests received from access servers, and collect this information in a central location. By setting up and using log files to track authentication information, such as each connection accept and connection reject, you can simplify administration of your service. You can set up and use logs to track accounting information (such as logon and logoff records) to maintain records for billing purposes.

When you set up logging, you can specify:

  • Which requests are logged.
  • The log-file format.
  • How often new logs are started.
  • Automatic deletion of the oldest log file when the disk is full.
  • Where log files are recorded.
  • What the log file records contain.

You can use the IAS console to specify which requests are logged. For more information, see To select requests to be logged.

You can use the IAS console to specify the log-file format, how often new logs are started, and where log files are recorded. For more information, see To configure log file properties.

Which requests are logged

You can select the following types of requests to log:

  • Accounting requests, including the following:
    • Accounting-on requests, which are sent by the access server to indicate that it is online and ready to accept connections.
    • Accounting-off requests, which are sent by the access server to indicate that it is going offline.
    • Accounting-start requests are sent by the access server (after the user is accepted by the IAS server) to indicate the start of a user session.
    • Accounting-stop requests are sent by the access server to indicate the end of a user session.
  • Authentication requests, including the following:
    • Authentication requests are sent by the access server on behalf of the connecting user. These entries in the log contain only incoming attributes.
    • Authentication accepts and rejects, which are sent by IAS to the access server, indicating whether the user should be accepted or rejected. These entries contain only outgoing attributes.
  • Periodic status, which is used to obtain interim accounting requests sent by some access servers during sessions.

    • Accounting-interim requests, which are sent periodically by the access server during a user session. This type of request can be used when the Acct-Interim-Interval RADIUS attribute is configured to support periodic requests in the remote access profile on the IAS server.

Notes

  • All types of request logging are disabled by default.
  • Initially, it is recommended that you enable the logging of accounting and authentication requests. You can refine your logging methods after you determine which data best matches your needs.
  • You can also log accounting, authentication, and periodic status to a SQL Server database. For more information, see SQL Server database logging.

The log-file format

You can configure your IAS servers to log data with either the IAS format or the database-import log format.

  • If you select the IAS format, attributes are logged in the form of attribute-value pairs. This format has the following characteristics:
    • The sequence of the attributes is dependent on the access server that is sending a request.
    • The logged attributes include RADIUS standard, IAS-specific, and vendor-specific.
    • All attributes that contain unprintable characters or any delimiters are printed in hexadecimal format (for example, 0x026).
  • If you select the database-import log format, attributes are logged in a format that supports importing the log into databases. This format has the following characteristics:
    • The attributes of all records are recorded in the same sequence (predefined by IAS), regardless of which access server sent the request.
    • If the attribute is not present in the request or reply (for example, if an attribute is not received from the access server), then the field in the log is empty.
    • The specific set of attributes that are logged is in a sequence that is predefined in IAS. Although the attributes included in this set are limited in number, they are those that are generally most useful in request tracking and analysis.

Notes

  • IAS format is enabled by default.
  • Switching log file formats does not cause a new log to be created. If you change log file formats, the file that is active at the time of the change will contain a mixture of the two formats (that is, records at the start of the log have the previous format and records at the end of the log have the new format).

How often new logs are started

When you configure your servers, you can specify whether new logs are started daily, weekly, monthly, or after the log reaches a specific size. You can also specify that a single log is maintained continually (regardless of file size), but this is not recommended. The file naming convention for logs is determined by the amount of time that each log is used, which you specify by setting the change frequency. If the log file change frequency is Daily, the log file name format is in yymmdd (where y is year, m is month, and d is day).log. If the log file change frequency is Weekly, the log file name format is in yymmww.log (where w is week). If the log file change frequency is Monthly, the log file name format is in yymm.log. Following are some example log file names:

Log file name | Change frequency | File creation date
in020528.log | Daily | May 28, 2002
in020304.log | Weekly | The fourth week of March, 2002
in0304.log | Monthly | April, 2003

Notes

  • By default, the new log file change frequency is set to Monthly.
  • When the log file change frequency is Never (unlimited file size), the IAS log file is named iaslog.log.
  • When the log file change frequency is When log file reaches this size, the file name is iaslog n.log, where n represents the maximum size of the file.

Automatic deletion of the oldest log file when the disk is full

You can specify whether IAS deletes the oldest log file when the disk is full. IAS determines which file is oldest by checking the file name rather than the time stamp. The currently configured log file change frequency (where new files are created at either a specified time or when the current file reaches a specified size) determines which log file IAS deletes.

IAS only deletes the oldest file from the same change frequency—it does not delete a file with a different file name format. For example, if the currently configured log file change frequency is set to Monthly (which has a log file name format of in yymm.log), IAS will not delete a log file named in021231.log even if it is the oldest log file, because the log file name and name format indicate that it was created with the change frequency set to Daily. The only time that IAS might delete a file from another change frequency occurs when the two change frequency settings are Daily and Weekly, and the file name can be interpreted both as one of the first four days of the month and as one of the four weeks of the month, as demonstrated in the following examples:

The file name | Is interpreted as both
in020501.log | A Daily file created on May 1, 2002 or a Weekly file created in the first week of May, 2002.
in020502.log | A Daily file created on May 2, 2002 or a Weekly file created in the second week of May, 2002.
in020503.log | A Daily file created on May 3, 2002 or a Weekly file created in the third week of May, 2002.
in020504.log | A Daily file created on May 4, 2002 or a Weekly file created in the fourth week of May, 2002.

Notes

  • If the oldest log file is the log file that is currently in use, the log file is not deleted.
  • Because changing the log file change frequency might result in the overwriting of existing logs, you should copy logs to a separate file before making the change.
  • For more information about how to effectively configure and use log files, see Best practices and To configure log file properties.

Where log files are recorded

By default, log files are located in the systemroot\System32\LogFiles folder. You can specify a different location.

The log file directory can be created by using system environment variables (instead of user variables) such as, %systemdrive%, %systemroot%, and %windir%. For example, the following path, using the environment variable %windir%, locates the log file at the system directory in the subfolder \System32\Logs (that is, %windir%\System32\Logs\).

For information about how to set up the authentication and accounting logging service on an IAS server, see To configure logging for user authentication and accounting.

For information about how to import a log file into a database, see Importing IAS log files into a database.

Log capture for other processes

To send log data directly to another process, you can configure IAS to write to a named pipe, instead of a file. To use named pipes, set the log file folder to \\.\pipe or \\ComputerName\pipe. The named pipe server program should create a named pipe called \\.\pipe\iaslog.log to accept the data.

What the log file records contain

Attributes are recorded in UTF-8 encoding in a comma-delimited format. The format of the records in a log file depends on the file format.

In IAS-formatted log files, each record starts with a fixed-format header, which consists of the access server IP address, user name, record date, record time, service name, and computer name, followed by attribute-value pairs.

For more information about the attributes and other data logged in the IAS format, see IAS-formatted log files.

In database-import log files, each record contains attribute values in a consistent sequence, including the computer name, service name, record date, and record time. An access server might not use all of the attributes specified in the database-import log format, but the comma-delimited location for each of these pre-defined attributes is maintained, even for attributes that have no value specified in a record.

For more information about the attributes and other data logged in the database-import log format, see Database-import log files.

Note

  • This documentation contains logging information that is specific to IAS. The types of data that your access server sends might vary, depending upon the manufacturer. For information about the specific data that your access server sends and how to configure accounting packets, see your access server documentation.


SQL Server database logging

You can use SQL Server database logging to log user authentication and accounting requests, which are received from one or more network access servers, to a centralized data source. Log data is passed from IAS to a stored procedure in a database that supports both structured query language (SQL) and extensible markup language (XML), such as one created with Microsoft SQL Server 2000. A stored procedure is a custom program, created by a SQL Server database programmer, that runs within the SQL Server database environment.

Logging to a relational database instead of a standard text file (that is, either IAS format or database-compatible format) has the advantage that relationships between data tables enable the flexible creation of dynamic data views by using queries and reports.

Which requests are logged

By default, no data is logged. When you configure logging, all required attributes, accounting, and authentication data that is normally logged in either IAS or database-compatible format is logged to the SQL Server database. You can log the following information in a SQL Server database:

  • Accounting requests, including the following:
    • Accounting-on requests, which are sent by the access server to indicate that it is online and ready to accept connections.
    • Accounting-off requests, which are sent by the access server to indicate that it is going offline.
    • Accounting-start requests, which are sent by the access server (after the user is accepted by the IAS server) to indicate the start of a user session.
    • Accounting-stop requests, which are sent by the access server to indicate the end of a user session.
  • Authentication requests, including the following:
    • Authentication requests, which are sent by the access server on behalf of the connecting user. These entries in the log contain only incoming attributes.
    • Authentication accepts and rejects, which are sent by IAS to the access server, indicating whether the user should be accepted or rejected. These entries contain only outgoing attributes.
  • Periodic status, which is used to obtain interim accounting requests sent by some access servers during sessions.

Accounting-interim requests, which are sent periodically by the access server during a user session, can also be logged to a SQL Server database. This type of request can be used when the Acct-Interim-Interval RADIUS attribute is configured to support periodic requests in the remote access profile on the IAS server.

Attributes that are recorded by SQL Server

Unlike database-import log files, which use a fixed sequence of attributes, the sequence of the attributes in a SQL Server log file depends upon the sequence used by the access server. For more information about the sequence of these records, see the documentation for the access server. The table in Interpreting IAS-formatted log files lists, in numerical order, RADIUS attributes that can be found in a SQL Server database and configured for IAS logging. This table does not cover vendor-specific attributes (VSAs). For information about VSAs, see Interpreting IAS IDs for vendor-specific attributes. For more information about VSAs that are supported by your access server, see your access server documentation.

Attributes that are not recorded by SQL Server

Although most of the attributes that are sent by an access server and supported in XOX; XOX; and XOX are logged when you specify the use of SQL Server logging, some attributes are not logged because they contain sensitive information (for example, passwords) that should not be included. The table in Interpreting IAS-formatted log files lists some of the attributes that are not logged.

You can use the IAS console to specify which requests are logged. For more information, see To select requests to be logged.

You can use the IAS console to specify additional SQL Server logging properties. For more information, see To configure log file properties.

Notes

  • All types of request logging are disabled by default.
  • Initially, it is recommended that you enable the logging of accounting and authentication requests. You can refine your logging methods after you determine your required data.
  • You can also log accounting, authentication, and periodic status in IAS or database-compatible format. For more information, see Logging user authentication and accounting requests.

How IAS and SQL Server logging works

When IAS is configured to log to a SQL Server database, the following occurs:

  1. The IAS server receives or produces the data that it is configured to log to a SQL Server database. For example, a network access server configured as a RADIUS client to the IAS server sends the IAS server incoming attributes for an authentication request by a user or computer.
  2. The IAS server packages the data as an XML document.
  3. The IAS server initiates a connection with the server running SQL Server. If the IAS server is unable to establish a connection with SQL Server, the IAS server stops processing authentication requests and users cannot log on to the network.

    IAS connects to SQL Server using password-based credentials that you can configure on the Connection tab in the Data Link Properties dialog box.

    If you select Use Windows NT integrated security, the IAS server attempts to authenticate the connection with the local computer account. If you select Use a specific name and password, you must specify the user name and password for a valid user account that you have already configured on your SQL Server.

    For more information about configuring SQL Server data link properties, see To configure log file properties.

  4. If a connection with the computer running SQL Server is successful, the IAS server signals SQL Server to run a stored procedure named report_event. IAS then sends the accounting data (an XML document) to the computer running SQL Server. The stored procedure that is called by IAS must be named report_event, or logging will fail.

    The report_event stored procedure uses only one parameter. This parameter is a Unicode string of type ntext. The Unicode string contains an XML document which in turn contains the accounting data to be logged.

  5. The report_event stored procedure in the SQL Server database processes the XML document and stores the processed data in SQL Server database tables.
  6. SQL Server notifies the IAS server that the transaction is successful.
  7. The IAS server is free to process additional data, repeating this process as required.

For more information about stored procedures and SQL Server logging, see article Q323723 in the Microsoft Knowledge Base. (http://www.microsoft.com/)

How IAS creates an XML document from accounting and authentication data

If you select the SQL Server log format, attribute-value pairs are converted to XML format.

When IAS creates an XML document from attributes, accounting and authentication data, the XML document includes the attribute ID or name, the attribute value, and the data type of the attribute value. With SQL Server logging, there are five date types for attribute values: Non-negative integers, strings (text), hexadecimal numbers, IPv4 addresses, and date and time. The following example XML document, which is created by IAS, includes the attribute name (User-Name), the attribute value (DOMAIN\username), and the data type of (1), indicating a value data type of string:

<Event>
<User-Name data_type="1">DOMAIN\username</User-Name>
</Event>

The next example XML document includes the attribute name (NAS-IP-Address), the attribute value (192.168.0.1), and the data type (3), indicating a value data type of IP address:

<Event>
<NAS-IP-Address data_type="3">192.168.0.1</NAS-IP-Address>
</Event>

The next example XML document includes the attribute name (Provider-Type), the attribute value (1), and the data type of (0), indicating a value data type of non-negative integers:

<Event>
<Provider-Type data_type="0">1</Provider-Type>
</Event>

The last example XML document, which is created by IAS, includes the three previous examples combined into one typical XML document:

<Event>
<User-Name data_type="1">DOMAIN\username</User-Name>
<NAS-IP-Address data_type="3">192.168.0.1</NAS-IP-Address>
<Provider-Type data_type="0">1</Provider-Type>
</Event>

Configuring SQL Server database logging

To log information to a SQL Server database, you must configure the SQL Server data link in Remote Access Logging in the IAS console. For more information, see To configure log file properties.

To provide centralized logging, failover, and redundancy with SQL Server logging, you can place two SQL Server databases on different subnets. Use the SQL Server Create Publication Wizard to set up database replication between the two servers.

For larger IAS deployments, you should use more than two computers running SQL Server and you should not configure all IAS servers to log to the same one. When you have a primary and backup IAS server configuration, the primary IAS server should log to a computer running SQL Server that is other than the one to which the backup IAS server logs. With this configuration, if the primary computer running SQL Server fails, preventing the primary IAS server from servicing clients, the backup IAS server, which is configured to log to a different computer running SQL Server, can service clients until the primary server is back on line.

If the computer running SQL Server runs out of disk space and can no longer perform IAS logging, IAS discards all accounting and authentication requests, preventing client authentication through the IAS server. Make sure you maintain adequate hard disk space on your computer running SQL Server.

The performance of the SQL Server database (throughput and latency) affects the response time of the IAS server. During an authentication attempt, IAS does not respond to the RADIUS client (network access server) until after SQL Server notifies the IAS server that the last data write operation is successful. Because of this, you should ensure that the computer running SQL Server is designed to handle the IAS logging load and is able to respond with minimum delay.

In addition, some RADIUS clients might retry authentication attempts if a response is not received from the IAS server within a specific time period (for example, one second). This could add to the load on the computers running IAS and SQL Server during periods of slow response due to network conditions. You should configure the network access servers with an appropriate retry interval to prevent overloading the computers running IAS and SQL Server with retry attempts.

For more information about SQL Server configuration and best practices, see the SQL Server 2000 documentation.

Requirements

Logging to a SQL Server database requires the use of one or more servers running Windows Server 2003 and IAS and an SQLXML-compliant database, such as Microsoft SQL Server 2000. Because this feature requires SQLXML, Microsoft Data Engine (MSDE) cannot be used instead of SQL Server. For more information, see SQL Server and XML. (http://www.microsoft.com/)


Deploying IAS

This section covers:

  • Deploying IAS as a RADIUS server
  • Deploying IAS as a RADIUS proxy
  • Setting up IAS in a test lab

Note

  • XOX


Deploying IAS as a RADIUS server

This section covers:

  • Planning for IAS as a RADIUS server
  • IAS as a RADIUS server

Note

  • XOX


Planning for IAS as a RADIUS server

This section covers:

  • IAS as a RADIUS server design considerations
  • IAS as a RADIUS server security considerations
  • Computer certificates for certificate-based authentication

Note

  • XOX


IAS as a RADIUS server design considerations

Consider the following design issues when deploying IAS as a RADIUS server:

  • The common uses of IAS as a RADIUS server

    • For more information about common ways to use IAS as a RADIUS server, see IAS as a RADIUS server.

  • IAS server domain membership

    • You must decide in which domain the IAS server computer is a member. For multiple domain environments, an IAS server can authenticate credentials for user accounts in the domain of which it is a member and all domains that trust this domain. To read the dial-in properties for user accounts, however, you must add the computer account of the IAS server to the RAS and IAS Servers group for each domain. For more information, see To enable the IAS server to read user accounts in Active Directory. XOX; XOX; and XOX also provide authentication across forests. For more information, see Accessing resources across forests.

  • RADIUS ports

    • You can configure the IAS server to receive RADIUS messages that are sent to UDP ports other than the default ports of 1812 and 1645 (for RADIUS authentication) and ports 1813 and 1646 (for RADIUS accounting). For more information, see To configure IAS port information.

  • RADIUS clients

    • A RADIUS client can be an access server (for example, a dial-up or VPN server, a wireless access point, or an Ethernet switch) or a RADIUS proxy. IAS supports all access servers and RADIUS proxies that comply with RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)."

    Configure each access server or RADIUS proxy that sends RADIUS request messages to the IAS server as a RADIUS client on the IAS server. For each RADIUS client, you can configure a friendly name, an IP address or DNS name, the client vendor, the shared secret, and whether to use the RADIUS Message Authenticator attribute. For more information, see Configure RADIUS clients.

    You can specify IP addresses or DNS names for RADIUS clients. In most cases, it is better to specify RADIUS clients with IP addresses. When you use IP addresses, IAS is not required to resolve host names at startup and will start much more quickly as the result. This is especially beneficial if your network contains a large number of RADIUS clients. You can use DNS names to specify RADIUS clients when you require something other than administrative flexibility (for example, the ability to map multiple RADIUS client IP addresses to a single DNS name).

    IAS in XOX and XOX allows you to specify a RADIUS client by using an address range. The address range for RADIUS clients is expressed in the network prefix length notation w.x.y.z/p, where w.x.y.z is the dotted decimal notation of the address prefix and p is the prefix length (the number of high order bits that define the network prefix). This is also known as Classless Inter-Domain Routing (CIDR) notation. An example is 192.168.21.0/24. To convert from subnet mask notation to network prefix length notation, p is the number of high order bits in the subnet mask that are set to 1.

  • Third-party access points

    • To determine whether a third-party access point is interoperable with IAS as a RADIUS server, refer to the third-party access point documentation for its use of RADIUS attributes and vendor-specific attributes.

    To test basic interoperability for PPP connections, configure the access point and the access client to use Password Authentication Protocol (PAP). Use additional PPP authentication protocols until you have tested the ones that you are using for network access.

  • Connection request policy configuration

    • The default connection request policy named Use Windows authentication for all users is configured for IAS when it is used as a RADIUS server. For more information about the settings of the default connection request policy, see Connection request policies. Additional connection request policies can be used to define more specific conditions, manipulate attributes, and specify advanced attributes. Use the New Connection Request Policy Wizard to create either common or custom connection request policies. For more information about connection request policies and how to configure them when IAS is being used as a RADIUS server, see Introduction to connection request processing.

  • Realm replacement

    • To correctly replace or convert realm names within the user name of a connection request, you must configure attribute manipulation rules for the User-Name attribute on the appropriate connection request policy. For more information, see Connection request policies and To configure attribute manipulation.

  • Remote access policy configuration

    • Remote access policies can be used to define specific conditions, set dial-in constraints, set allowed authentication protocols and encryption strength, and specify advanced attributes. Use the New Remote Access Policy Wizard to create either common or custom policies. For more information, see Introduction to remote access policies.

  • Remote access policies and authorization by user or group

    • In small organizations, you can manage authorization by setting the remote access permission on each user account. For a large organization, set the remote access permission on each user account to be controlled through remote access policy. Next, configure remote access policies to grant access by using group membership. For more information, see Introduction to remote access policies.

  • The use of additional RADIUS attributes and vendor-specific attributes

    • If you plan to return additional RADIUS attributes or vendor-specific attributes (VSAs) with the responses to RADIUS requests, you must add the RADIUS attributes or VSAs to the appropriate remote access policy. For more information, see Vendor-specific attribute overview and Configure attributes for a profile.

  • The use of logging

    • You can enable event logging for authentication events to assist with troubleshooting and debugging connection attempts. For more information, see Event logging for IAS. For information about logging user authentication and accounting requests for analysis and connection billing, see Logging user authentication and accounting requests.

  • Interim accounting

    • To use interim accounting, first verify that your access server supports sending interim accounting messages. Next, add the Acct-Interim-Interval RADIUS attribute from the Advanced tab on the profile settings of the appropriate remote access policy. Configure the Acct-Interim-Interval attribute with the interval (in minutes) to send periodic interim accounting messages. For more information, see To add RADIUS attributes to a remote access policy. Next, enable logging of periodic status. For more information, see To select requests to be logged.

    The Routing and Remote Access service supports sending interim accounting messages and is enabled from the properties of a RADIUS server when configuring the RADIUS accounting provider. For more information, see To use RADIUS accounting.

  • Performance and capacity planning

    • For information about tuning performance and using IAS in large organizations, see Best practices.

  • Multiple IAS servers

    • To provide fault tolerance for RADIUS-based authentication and accounting, you should always use at least two IAS servers. One IAS server is used as the primary RADIUS server and the other is used as a backup. Access servers are configured for both IAS servers. They switch to using the backup IAS server when the primary IAS server becomes unavailable. For information about how to synchronize the configuration of multiple IAS servers, see Managing multiple IAS servers.

Note

  • XOX


IAS as a RADIUS server security considerations

Consider the following security issues when deploying IAS as a RADIUS server:

  • Shared secrets

    • Configure strong shared secrets and change them frequently to prevent dictionary attacks. Strong shared secrets are a long (more than 22 characters) sequence of random letters, numbers, and punctuation. For more information, see Shared secrets.

  • Message Authenticator attribute

    • To ensure that an incoming RADIUS Access-Request message, for connection requests that use the PAP, CHAP, MS-CHAP, and MS-CHAP v2 authentication protocols, was sent from a RADIUS client configured with the correct shared secret, you can use the RADIUS Message Authenticator attribute (also known as a digital signature or the signature attribute). You must enable the use of the Message Authenticator attribute on both the IAS server (as part of the configuration of the RADIUS client in Internet Authentication Service) and the RADIUS client (the access server or RADIUS proxy). Ensure that the RADIUS client supports the Message Authenticator attribute before enabling it. The Message Authenticator attribute is always used with EAP without having to enable it on the IAS server and access server. For more information, see To edit RADIUS client configuration.

    For information about enabling the RADIUS Message Authenticator attribute for your access server, see the appropriate access server documentation. For the Routing and Remote Access service, the use of the RADIUS Message Authenticator attribute is enabled from the properties of a RADIUS server when you configure the RADIUS authentication provider. For more information, see To use RADIUS authentication.

  • Firewall configuration

    • If your IAS server is on a perimeter network (also known as a demilitarized zone or DMZ), configure your Internet firewall (between your perimeter network and the Internet) to allow RADIUS messages to pass between your IAS server and RADIUS clients on the Internet. You might need to configure an additional firewall that is placed between your perimeter network and your intranet, to allow traffic to flow between the IAS server on the perimeter network and domain controllers on the intranet. For more information, see IAS and firewalls.

  • Authentication protocols

    • IAS supports several different authentication protocols. The order of authentication protocols, from the most secure to the least secure, is: PEAP-EAP-TLS (for wireless clients and authenticated switch clients only), EAP-TLS, PEAP-EAP-MS-CHAPv2 (for wireless clients and authenticated switch clients only), MS-CHAP v2, MS-CHAP, EAP-MD5, CHAP, and PAP. Microsoft recommends using only the strongest authentication protocols required for your configuration. For password-based authentication protocols, strong password policies must be enforced to protect from dictionary attacks. The use of PAP is not recommended unless it is required. For more information, see Authentication methods.

  • Remote access account lockout

    • To provide protection for online dictionary attacks launched against access servers by using known user names, you can enable remote access account lockout. Remote access account lockout disables remote access for user accounts after a configured number of failed connection attempts has been reached. For more information, see Remote access account lockout.

    Remote access account lockout can also be used to prevent a malicious user from intentionally locking out a domain account by attempting multiple dial-up or VPN connections with the wrong password. You can set the number of failed attempts for remote access account lockout to a number that is lower than the logon retries for domain account lockout. By doing this, remote access account lockout occurs before domain account lockout, which prevents the domain account from being intentionally locked out.

  • Certificate-based authentication

    • When you use the EAP-TLS authentication protocol, you must install a computer certificate on the IAS server. For client and user authentication, you can either install a certificate on the client computer or use smart cards. Before certificate enrollment occurs, the certificate must be designed with the correct requirements and purposes. For more information, see Network access authentication and certificates and Computer certificates for certificate-based authentication.

  • Authentication of wireless clients using Protected Extensible Authentication Protocol (PEAP)

    You can use PEAP with EAP-TLS (also known as PEAP-EAP-TLS) to deploy a certificates with PEAP. PEAP with EAP-MS-CHAPv2 (also known as PEAP-EAP-MS-CHAPv2) provides secure password authentication. PEAP-EAP-TLS uses a public key infrastructure (PKI) with certificates for server authentication and either smart cards or certificates for client and user authentication. When you use PEAP-EAP-TLS, client certificate information is encrypted.

    Although using PEAP-EAP-TLS with smart cards for certificate deployment is the most secure authentication method, the complexity and cost of deploying certificates to wireless and authenticated switch clients might not be practical for your organization. PEAP-EAP-MS-CHAPv2 balances security with deployment cost and complexity. Unlike MS-CHAPv2, PEAP-EAP-MS-CHAPv2 is a mutual authentication method that uses Transport Level Security (TLS) to create an end-to-end encrypted connection between client and authenticator. The client authenticates the server by using the server's certificate and the server authenticates the client with password-based credentials. For an example of a remote access policy using PEAP, see Wireless access with secure password authentication.

  • Registration of the IAS server in Active Directory

    • Before the IAS server can access Active Directory domains to authenticate user credentials and user access account properties, the IAS server must be registered in those domains. For more information, see To enable the IAS server to read user accounts in Active Directory.

  • Using IPSec filters to lock down IAS servers

    • You can configure IPSec filters on a granular level to allow specific traffic in and out of network interfaces on RADIUS servers. These filters can be applied to organizational units and stored in Active Directory, or they can be created and applied to individual servers. For more information, see Securing RADIUS traffic with IPSec.

Note

  • XOX


Computer certificates for certificate-based authentication

Before using Extensible Authentication Protocol-Transport Level Security (EAP-TLS), you must install a computer certificate (also known as a machine certificate) on the Internet Authentication Service (IAS) server computer. The installed computer certificate must be issued from a certification authority (CA) that can follow a certificate chain to a root CA that is trusted by the access clients. Additionally, in order for the IAS server to validate the user or computer certificate of the access client, the IAS server must install the certificate of the root CA that issued the user or computer certificate to the access clients.

For more information, see Network access authentication and certificates.

To install a computer certificate, a CA must be available to issue certificates. After the CA is configured, you can install a computer certificate on the IAS server:

  • By configuring the automatic allocation of computer certificates to computers in an Active Directory domain.
  • By using Certificate Manager to obtain a computer certificate.
  • By using Microsoft Internet Explorer and Web-based enrollment.

To configure a CA and install the computer certificate, complete the following steps:

  1. Install the Certificate Services component as an enterprise root CA. For more information, see To install an enterprise root certification authority. This step is only required if you do not already have an enterprise root CA.

    2. If necessary, configure the computer that is the CA to be a domain controller.

  2. To install the computer certificates through auto-enrollment, configure Group Policy on the Active Directory domain for automatic allocation of computer certificates. For more information, see To configure automatic certificate allocation from an enterprise CA.

    3. To create a computer certificate for the IAS server that is a member of the domain for which auto-enrollment is configured (and other computers that are members of the domain), restart the computer or type gpupdate /target:computer from a Command Prompt.

  3. To manually enroll computer certificates, use Certificate Manager to install both the CA root certificate of the access client and the computer certificate for the IAS server. For more information, see To manage certificates for a computer and To request a certificate.
  4. To manually enroll computer certificates with Internet Explorer, see To submit an advanced certificate request via the Web.

Notes

  • While XOX; XOX; and XOX allow you to install multiple computer certificates, only a single certificate can be selected for all remote access policies that specify authentication through EAP-TLS.
  • An IAS server does not use a new certificate revocation list (CRL), which is published by the certification authority (CA), until the old CRL has expired. If a certificate has expired and the IAS server is checking against an old but unexpired CRL, the IAS server will allow clients with revoked certificates to connect to the network. To prevent this from happening, you can publish CRLs with short expiration times (one hour or longer).
  • XOX


IAS as a RADIUS server

This section covers:

  • Wireless access
  • Dial-up and VPN remote access
  • Extranet access
  • Internet access
  • Outsourced VPN remote access
  • Outsourced wireless access
  • Ethernet switch access

Note

  • XOX


Wireless access

This topic describes how IAS can be used to support authentication, authorization, and accounting for wireless connections to an organization. This topic describes a typical configuration for an organization that uses:

  • Two IAS servers.

    • Two IAS servers (one primary and one secondary) are used to provide fault tolerance for RADIUS-based authentication. If only one RADIUS server is configured and it becomes unavailable, wireless access clients cannot connect. By using two IAS servers and configuring all wireless access points (RADIUS clients) for both the primary and secondary IAS servers, the RADIUS clients can detect when the primary RADIUS server is unavailable and automatically fail over to the secondary IAS server.

  • Active Directory domains.

    • Active Directory domains contain the user accounts, passwords, and dial-in properties that each IAS server requires to authenticate user credentials and evaluate both authorization and connection constraints. To both optimize IAS authentication and authorization response times and minimize network traffic, IAS is installed on domain controllers.

  • A certificate infrastructure.

    • The Extensible Authentication Protocol-Transport Level Security (EAP-TLS) authentication protocol is used with locally installed user certificates to authenticate wireless clients.

  • Wireless remote access policies.

    • Remote access policies are configured for wireless connections so that authenticated wireless users obtain unrestricted access to the organization intranet and guest wireless users obtain restricted access to a virtual LAN (VLAN) that contains a certificate server.

  • Multiple wireless access points.

    • Multiple third-party wireless access points provide wireless access in different buildings of an organization.

  • A certificate server on a separate VLAN for new wireless clients

    • To accommodate new wireless clients, a certificate server is placed on a separate virtual local area network (VLAN). The certificate server is used by a new wireless client to obtain a user certificate for subsequent wireless access. After 10 minutes of receiving a guest connection, the wireless client is disconnected. When the wireless client computer reconnects, it authenticates by using the newly installed user certificate and obtains authenticated wireless access to the network.

The following illustration shows a wireless configuration.

Wireless access

When you configure IAS so that wireless clients can access the certificate server on the VLAN, it is important to note that the term guest refers to user identity and the term unauthenticated refers to user credentials. The following rules illustrate the differences between the Guest account and remote access policy unauthenticated access:

User identity rules

Condition | IAS action
If the wireless client has a UserID | IAS maps to the corresponding Windows account.
If the wireless client does not have a UserID or uses a null UserID | IAS attempts to default to the Guest account (in the domain in which the IAS server is a member).

Credential rules

Condition | IAS action
If the wireless client provides credentials | The authentication method in use specifies whether to accept the connection attempt. EAP-MD5 guest authentication is standard user authentication with a UserID and password (which can be null). However, secure channel (Schannel) does not support authentication to a Windows account that is based on a NULL certificate.
If the wireless client does not provide credentials | IAS checks the remote access policy to determine whether unauthenticated access is allowed. EAP-TLS supports one-way authorization, such as unauthenticated access where the wireless client does not send credentials. However, EAP-MD5 does not support one-way authorization.

Notes

  • This topic only describes how to configure IAS. It does not describe the configuration of Active Directory domains, the certificate infrastructure, or the wireless access points. For more information about how to deploy these components, see the appropriate Help topics.
  • This topic describes the bootstrapping of wireless clients by using a VLAN that contains a certificate server. You can also bootstrap wireless clients by using an unauthenticated Ethernet connection or a certificate that has been extracted to a floppy disk.

To configure IAS for this example, complete the following steps:

  • Configure Active Directory for user accounts and groups.
  • Configure the primary IAS server on a domain controller.
  • Configure the secondary IAS server on a different domain controller.
  • Configure RADIUS accounting and authentication on wireless access points.

Configuring user accounts and groups

To configure user accounts and groups, do the following:

  1. Ensure that all users that are making wireless connections have a corresponding user account.
  2. Manage your wireless access by user by setting the remote access permission on user accounts to Allow access or Deny access. To manage your wireless access by group, set the remote access permission on user accounts to Control access through Remote Access Policy. For more information, see To configure remote access permission for a user.
  3. Organize your wireless access users into the appropriate universal and nested groups in order to take advantage of group-based remote access policies. For example, create a universal group named WirelessUsers that contains global groups of wireless user accounts. For more information, see Group scope.
  4. Configure the Guest account to allow guest access for new wireless clients. For more information, see Guest authentication. Enable reversibly encrypted password storage on the Guest account. For more information, see User and computer accounts.
  5. Create a group named Guests, and add the Guest account as a member. For more information, see To create a new group.
  6. Configure the domain in which the IAS server computers will be members for auto-enrollment of computer certificates. For more information, see To configure automatic certificate allocation from an enterprise CA.

Configuring the primary IAS server on a domain controller

To configure the primary IAS server on a domain controller, do the following:

  1. On the domain controller, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the IAS server computer (the domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the IAS server computer is a member. Next, configure the IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.

    4. If the IAS server authenticates connection attempts for user accounts in other domains, and those domains do not have a two-way trust with the domain in which the IAS server computer is a member, see Authentication across forests.

  4. Enable file logging for accounting and authentication events. For more information, see To configure log file properties.
  5. If needed, configure additional UDP ports for authentication and accounting messages that are sent by RADIUS clients. For more information, see To configure IAS port information. By default, IAS uses UDP ports 1812 and 1645 for authentication and ports 1813 and 1646 for accounting.
  6. Add the wireless access points as RADIUS clients of the IAS server. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets. Enable the use of the Message Authenticator attribute only when it is supported by the wireless access point.
  7. Use the New Remote Access Policy Wizard to create a common wireless policy with the following settings:
    • Policy name: Wireless access
    • Access Method: Wireless access
    • User or Group: Select Group, and then specify the WirelessUsers group (example).
    • Authentication methods: Select Smart Card or other Certificate. If you have multiple computer certificates, click Configure, and then select the appropriate computer certificate.
    • Policy Encryption Level: Select the Strongest encryption check box, and then clear all other check boxes.
  8. Use the New Remote Access Policy Wizard to create a custom wireless policy with the following settings:
    • Policy name: New wireless access
    • Conditions:
      • NAS-Port-Type matches Wireless-Other or Wireless-IEEE 802.11
      • Windows-Groups matches Guests
    • Permission: Grant remote access permission
    • Profile settings, Dial-in Constraints tab:
      • Select the Minutes client can be connected check box, and then type 10.
    • Profile settings, Advanced tab:
      • Add the Tunnel-Type attribute with the value of Virtual LANs (VLAN).
      • Add the Tunnel-Pvt-Group-ID attribute with the value of the VLAN ID of the VLAN that contains the certificate server for new wireless clients.

    For additional examples of remote access policies, see Remote access policies examples.

  9. Delete the default remote access policies. For more information, see To delete a remote access policy.

Configuring the secondary IAS server on a different domain controller

To configure the secondary IAS server on a different domain controller, do the following:

  1. On the other domain controller, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the secondary IAS server computer (the other domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the secondary IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the secondary IAS server computer is a member. Next, configure the secondary IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.

    4. If the secondary IAS server authenticates connection attempts for user accounts in other domains, and those domains do not have a two-way trust with the domain in which the secondary IAS server computer is a member, see Authentication across forests.

  4. Copy the configuration of the primary IAS server to the secondary IAS server. For more information, see To copy the IAS configuration to another server.

Configuring RADIUS authentication and accounting on wireless access points

Configure your third-party wireless access point as a RADIUS client with two RADIUS servers (the primary and secondary IAS servers). For more information, see the documentation for the wireless access point.


Dial-up and VPN remote access

This topic describes how IAS is used to support authentication, authorization, and accounting for dial-up and virtual private network (VPN) connections to an organization. This topic describes a typical configuration for an organization that uses:

  • Two IAS servers.

    • Two IAS servers (one primary and one secondary) are used to provide fault tolerance for RADIUS-based authentication. If only one RADIUS server is configured and it becomes unavailable, dial-up and VPN access clients cannot connect. By using two IAS servers and configuring all dial-up and VPN servers (RADIUS clients) for both the primary and secondary IAS servers, RADIUS clients can detect when the primary RADIUS server is unavailable and automatically fail over to the secondary IAS server.

  • Active Directory domains.

    • Active Directory domains contain the user accounts, passwords, and dial-up properties that each IAS server requires to authenticate user credentials and evaluate both authorization and connection constraints. To optimize IAS authentication and authorization response times and minimize network traffic, IAS is installed on domain controllers.

  • A smart card certificate infrastructure.

    • The Extensible Authentication Protocol-Transport Level Security (EAP-TLS) authentication protocol is used with smart cards to authenticate employee connections and provide the highest level of security for authentication.

  • Custom remote access policies.

    • Remote access policies are configured to specify, based on group membership, the different requirements for various types of connections and users.

  • Multiple dial-up and VPN servers.

    • Dial-up and VPN servers consist of computers running different versions of Windows and the Routing and Remote Access service, and third-party network access server (NAS) devices.

The following illustration shows the common dial-up and VPN remote access configuration.

Dial-up and VPN remote access

Note

  • This topic only describes how to configure IAS. It does not describe the configuration of Active Directory, the smart card certificate infrastructure, or the dial-up and VPN servers. For more information about how to deploy these components, see the appropriate Help topics.

To configure IAS for this example, complete the following steps:

  • Configure Active Directory for user accounts and groups.
  • Configure the primary IAS server on a domain controller.
  • Configure the secondary IAS server on a different domain controller.
  • Configure RADIUS accounting and authentication on dial-up and VPN servers.

Configuring user accounts and groups

To configure user accounts and groups, do the following:

  1. Ensure that all users that are making remote access connections have a corresponding user account. This includes employees, contractors, vendors, and business partners.
  2. Set the remote access permission on user accounts to Allow access or Deny access to manage network access by user. Or, to manage network access by group, set the remote access permission on user accounts to Control access through Remote Access Policy. For more information, see To configure remote access permission for a user.
  3. Organize remote access users into the appropriate universal and nested groups in order to take advantage of group-based remote access policies. For more information, see Group scope.
  4. If you are using the Challenge-Handshake Authentication Protocol (CHAP), enable support for reversibly encrypted passwords in the appropriate domains. For more information, see To enable reversibly encrypted passwords in a domain.
  5. If you are using certificate-based authentication, configure the domain in which IAS server computers will be members for the auto-enrollment of computer certificates. For more information, see To configure automatic certificate allocation from an enterprise CA.

Configuring the primary IAS server on a domain controller

To configure the primary IAS server on a domain controller, do the following:

  1. On the domain controller, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the IAS server computer (the domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the IAS server authenticates connection attempts for user accounts in other domains, verify that these domains have a two-way trust with the domain in which the IAS server computer is a member. Next, configure the IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.

    4. If the IAS server authenticates connection attempts for user accounts in other domains, and those domains do not have a two-way trust with the domain in which the IAS server computer is a member, see Authentication across forests.

  4. Enable file logging for accounting and authentication events. For more information, see To configure log file properties.
  5. If needed, configure additional UDP ports for authentication and accounting messages that are sent by RADIUS clients. For more information, see To configure IAS port information. By default, IAS uses UDP ports 1812 and 1645 for authentication and ports 1813 and 1646 for accounting.
  6. Add the dial-up and VPN servers as RADIUS clients of the IAS server. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets. Enable the use of the Message Authenticator attribute, but only when it is also supported by the RADIUS client.
  7. Create remote access policies that reflect your remote access usage scenarios.

    8. For example, to configure a remote access policy to permit members of the Contractors group dial-up connections from 8:00 AM to 5:00 PM, Monday through Friday, create a new custom remote access policy with the following settings:

    • Policy name: Contractor connections
    • Conditions:
      • Windows-Groups matches Contractors
    • Permission: Grant remote access permission
    • Profile settings, Dial-in constraints tab:
      • Allow access only on these days and at these times is set to 8:00 AM to 5:00 PM, Monday through Friday.
      • Allow access only through these media is set to Async (Modem).

      All other settings are at their default values.

  8. As another example, to configure a remote access policy that requires VPN connections for members of the Employees group to use smart card authentication and 128-bit encryption, use the New Remote Access Policy Wizard to create a common VPN policy with the following settings:
    • Policy name: VPN connections
    • Access Method: VPN access
    • User or Group: Select Group, and then specify the Employees group (example).
    • Authentication methods: Select Smart Card or other Certificate, and then clear all other check boxes.
    • Policy Encryption Level: Select the Strongest encryption check box, and then clear all other check boxes.

    For additional examples of remote access policies, see Remote access policies examples.

    If you have created new remote access policies, either delete the default remote access policy named Allow access if dial-up permission is enabled, or move it so that it is the last policy to be evaluated. For more information, see To delete a remote access policy and To change the policy evaluation order.

Configuring the secondary IAS server on a different domain controller

To configure the secondary IAS server on a different domain controller, do the following:

  1. On the other domain controller, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the secondary IAS server computer (the other domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the secondary IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the secondary IAS server computer is a member. Next, configure the secondary IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.

    4. If the secondary IAS server authenticates connection attempts for user accounts in other domains, and those domains do not have a two-way trust with the domain in which the secondary IAS server computer is a member, see Authentication across forests.

  4. Copy the configuration of the primary IAS server to the secondary IAS server. For more information, see To copy the IAS configuration to another server.

Configuring RADIUS authentication and accounting on dial-up and VPN servers

To configure each dial-up or VPN server to use the primary and secondary IAS servers for authentication, authorization, and accounting of remote access connections, do the following:

  1. If the dial-up or VPN server is a computer running XOX; XOX; XOX; or Windows 2000 and the Routing and Remote Access service; configure the primary and secondary IAS servers as RADIUS servers for both RADIUS authentication and accounting. For more information, see To use RADIUS authentication and To use RADIUS accounting.
  2. If the dial-up or VPN server is a computer running Windows NT Server 4.0 and the Routing and Remote Access Service (RRAS), see the Windows NT Server 4.0 online Help for information about how to configure the primary and secondary IAS servers as RADIUS servers for RADIUS authentication.
  3. If the dial-up or VPN server is a third-party network access server (NAS), see the documentation for the NAS to determine how to configure it as a RADIUS client with two RADIUS servers (the primary and secondary IAS servers).


Extranet access

This topic describes how IAS and the Routing and Remote Access service are used to support an extranet. An extranet is an extension of an organization intranet that is used to facilitate communication with business partners. It provides business partners with limited access to resources on an organization's intranet through a virtual private network (VPN) connection over the Internet. This enhances the speed and efficiency of the business relationship. The organization has multiple business partners, each of which need access to only a specific subnet or set of addresses within the organization's network. Network access control is defined at the IP level using IP packet filters for specific connection categories. The filters that are applied to VPN connections can be specified by using remote access policies.

This topic describes a typical configuration for an organization extranet that uses:

  • Two IAS servers.

    • Two IAS servers (one primary and one secondary) are used to provide fault tolerance for RADIUS-based authentication. If only one RADIUS server is configured and it becomes unavailable, VPN users cannot connect. By using two IAS servers and configuring all VPN servers (RADIUS clients) for both the primary and secondary IAS servers, the RADIUS clients can detect when the primary RADIUS server is unavailable and automatically fail over to the secondary IAS server.

  • Active Directory domains.

    • Active Directory domains contain the user accounts, passwords, and dial-in properties that each IAS server requires to authenticate user credentials and evaluate both authorization and connection constraints. To optimize IAS authentication and authorization response times and minimize network traffic, IAS is installed on domain controllers.

  • Custom remote access policies.

    • Remote access policies are configured to specify, based on group membership, how different business partners can access different extranet resources.

  • VPN servers.

    • VPN servers consist of computers running XOX; XOX; XOX; and Windows 2000 and the Routing and Remote Access service.

The following illustration shows the configuration for VPN-based remote access to the extranet by business partners.

Business partner extranet access

Note

  • This topic only describes how to configure IAS. It does not describe the configuration of Active Directory, the VPN servers, or the resources on the extranet. For more information about how to deploy these components, see the appropriate Help topics.

To configure IAS for this example, complete the following steps:

  • Configure Active Directory for user accounts, groups, and certificate auto-enrollment.
  • Configure the primary IAS server on a domain controller.
  • Configure the secondary IAS server on a different domain controller.
  • Configure RADIUS authentication and accounting on VPN servers.

Configuring user accounts, groups, and certificate auto-enrollment

To configure user accounts, groups, and certificate auto-enrollment, do the following:

  1. Ensure that all business partners that are making remote access connections have a corresponding user account. Configure the user principal names (UPNs) for business partner accounts by using the organization name of the business partner. For example, for a user account named Someone for the business partner Microsoft, configure the UPN as someone@example.microsoft.com.
  2. Manage your business partner's extranet access by user by setting the remote access permission on user accounts to Allow access or Deny access. To manage your business partner's extranet by group, set the remote access permission on user accounts to Control access through Remote Access Policy. For more information, see To configure remote access permission for a user.
  3. Organize your business partner user accounts into the appropriate universal and nested global groups in order to take advantage of group-based remote access policies. Create global groups for each business partner and then add the appropriate user accounts. Next, create universal groups for business partner categories that contain the global groups as members. For example, for the business partner Microsoft, create a global group named Microsoft and add all Microsoft user accounts to the group. Then, because Microsoft is a supplier business partner, create a universal group named Suppliers and add the Microsoft global group as a member. For more information, see Group scope.

Configuring the primary IAS server on a domain controller

To configure the primary IAS server on a domain controller, do the following:

  1. On the domain controller, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the IAS server computer (the domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the IAS server is authenticating connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the IAS server computer is a member. Next, configure the IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.
  4. Enable file logging of accounting, authentication, and periodic status events. For more information, see To configure log file properties.
  5. Add the VPN servers as RADIUS clients of the IAS server. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets.
  6. Create remote access policies that reflect your required business partner extranet usage.

    7. For example, to create a remote access policy that restricts all VPN remote access traffic for members of the Suppliers group to the subnet of 192.168.47.0/24, use the New Remote Access Policy Wizard to create a new custom remote access policy with the following settings:

    • Policy name: Supplier business partner connections
    • Conditions:
      • Windows-Groups matches Suppliers
    • Permission: Grant remote access permission
    • Profile settings, Dial-in Constraints tab:
      • Allow access only through these media and the Virtual (VPN) media type are selected.
    • Profile settings, IP tab:
      • Input packet filter:
        • Deny all traffic except those listed below
        • Destination network, IP address: 192.168.47.0
        • Destination network, Subnet mask: 255.255.255.0
        • Protocol: Any
      • Output packet filter:
        • Deny all traffic except those listed below
        • Source network, IP address: 192.168.47.0
        • Source network, Subnet mask: 255.255.255.0
        • Protocol: Any
    • Profile settings, Authentication tab:
      • Select the Microsoft Encrypted Authentication version 2 (MS-CHAP v2) check box, and then clear all other check boxes.
    • Profile settings, Encryption tab:
      • Select the Strongest check box, and then clear all other check boxes.

    For more information, see To add a remote access policy.

    As another example, to create a remote access policy that restricts all VPN remote access traffic for members of the business partners Investors group to the IP address of 10.59.192.17, create a new remote access policy with the following settings:

    • Policy name: Investor business partner connections
    • Conditions:
      • Windows-Groups matches Investors
    • Permission: Grant remote access permission
    • Profile settings, Dial-in Constraints tab:
      • Allow access only through these media and the Virtual (VPN) media type are selected.
    • Profile settings, IP tab:
      • Input packet filter:
        • Deny all traffic except those listed below
        • Destination network, IP address: 10.59.192.17
        • Destination network, Subnet mask: 255.255.255.255
        • Protocol: Any
      • Output packet filter:
        • Deny all traffic except those listed below
        • Source network, IP address: 10.59.192.17
        • Source network, Subnet mask: 255.255.255.255
        • Protocol: Any
    • Profile settings, Authentication tab:
      • Select the Microsoft Encrypted Authentication version 2 (MS-CHAP v2) check box, and then clear all other check boxes.
    • Profile settings, Encryption tab:
      • Select the Strongest check box, and then clear all other check boxes.

    For more information, see To add a remote access policy.

    For additional examples of remote access policies, see Remote access policies examples.

    Delete the default remote access policies, or move them so that they are the last policies to be evaluated. For more information, see To delete a remote access policy and To change the policy evaluation order.

  7. Ensure that a computer certificate that can be validated by computers using smart cards is installed on the IAS server computer. For more information, see Computer certificates for certificate-based authentication.

Configuring the secondary IAS server on a different domain controller

To configure the secondary IAS server on a different domain controller, do the following:

  1. On the other domain controller, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the secondary IAS server computer (the other domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the secondary IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the secondary IAS server computer is a member. Next, configure the secondary IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.
  4. Ensure that a computer certificate that can be validated by computers using smart cards is installed on the IAS server computer. For more information, see Computer certificates for certificate-based authentication.
  5. Copy the configuration of the primary IAS server to the secondary IAS server. For more information, see To copy the IAS configuration to another server.

Configuring RADIUS authentication and accounting on the VPN servers

To configure each VPN server to use the primary and secondary IAS servers for authentication, authorization, and accounting of remote access connections, do the following:

  1. If the VPN server is a computer running XOX; XOX; XOX; or Windows 2000 and the Routing and Remote Access service, configure the primary and secondary IAS servers as RADIUS servers for both RADIUS authentication and accounting. For more information, see To use RADIUS authentication and To use RADIUS accounting.
  2. If the VPN server is a computer running Windows NT Server 4.0 and the Routing and Remote Access Service (RRAS), see the Windows NT Server 4.0 online Help for information about how to configure the primary and secondary IAS servers as RADIUS servers for RADIUS authentication.


Internet access

This topic describes how IAS is used to authenticate and authorize Internet connections for the customers of an Internet service provider (ISP). In this example, the ISP has a single data center that supports a large number of customers. Dial-up servers are distributed with multiple Points of Presence (POPs). The ISP offers two service plans: A basic plan for users with dial-up modems and a premium plan that provides support for ISDN connections. Connection authorization is provided to customers based on the subscription plan.

For each basic plan customer, a Connection Manager service profile is used to enable access to the Internet through the ISP's POPs. For each premium plan user, the same Connection Manager service profile is used to enable ISDN access. The service profile contains both dial-up and ISDN POPs. Connection Manager makes the appropriate POPs available based on the type of connection device that the user selects.

This topic describes a configuration for an ISP that uses:

  • Two IAS servers.

    • Two IAS servers (one primary and one secondary) are used to provide fault tolerance for RADIUS-based authentication. If only one RADIUS server is configured and it becomes unavailable, ISP customers cannot connect to the Internet. By using two IAS servers and configuring all dial-up servers (RADIUS clients) for both the primary and secondary IAS servers, RADIUS clients detect when the primary RADIUS server is unavailable and automatically fail over to the secondary IAS server.

  • Active Directory domains.

    • Active Directory domains contain the user accounts, passwords, and dial-in properties that each IAS server requires to authenticate user credentials and evaluate both authorization and connection constraints. To optimize IAS authentication and authorization response times and minimize network traffic, IAS is installed on domain controllers.

  • Custom remote access policies.

    • Remote access policies are configured to specify, based on group membership, the different types of connection constraints for the two service plans (basic and premium).

  • Multiple dial-up servers.

    • Dial-up servers consist of third-party network access server (NAS) devices, and computers running different versions of Windows and the Routing and Remote Access service. The dial-up servers are geographically distributed at various POPs so that ISP customers can access the Internet with a local call.

The following illustration shows the configuration of an ISP providing Internet access.

Internet access using an ISP

Note

  • This topic only describes how to configure IAS. It does not describe the configuration of Active Directory, the dial-up servers, or the Connection Manager profile. For more information about how to deploy these components, see the appropriate Help topics.

To configure IAS to support Internet access for an ISP, complete the following steps:

  • Configure Active Directory for user accounts and groups.
  • Configure the primary IAS server on a domain controller.
  • Configure the secondary IAS server on a different domain controller.
  • Configure RADIUS accounting and authentication on dial-up servers.

Configuring user accounts and groups

To configure user accounts and groups, do the following:

  1. Ensure that all customers that are making Internet connections have a corresponding user account. The user principal names that are created should contain the @ (at) sign, followed by the ISP name (for example, UserName@ISPName).
  2. If you want to manage access by group, ensure that all user accounts are configured with the Control access through Remote Access Policy remote access permission. For more information, see To configure remote access permission for a user.
  3. Create two universal groups: one for basic plan users (named BasicPlanUsers) and one for premium plan users (named PremiumPlanUsers). Because of the large number of potential users, create global groups and make user accounts members of global groups. Next, add the global groups as members of the universal groups. For more information, see Group scope.
  4. If some customers are using the Challenge-Handshake Authentication Protocol (CHAP), you must enable support for reversibly encrypted passwords in the appropriate domains. For more information, see To enable reversibly encrypted passwords in a domain.

Configuring the primary IAS server on a domain controller

To configure the primary IAS server on a domain controller, do the following:

  1. On the domain controller, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the IAS server computer (the domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the IAS server computer is a member. Next, configure the IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.
  4. Enable file logging for accounting and authentication events. For more information, see To configure log file properties.
  5. If needed, configure additional UDP ports for authentication and accounting messages that are sent by RADIUS clients. For more information, see To configure IAS port information. By default, IAS uses UDP ports 1812 and 1645 for authentication and ports 1813 and 1646 for accounting.
  6. Add the dial-up servers as RADIUS clients of the IAS server. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets. Enable the use of the Message Authenticator attribute only when it is supported by the RADIUS client.
  7. Create remote access policies for both basic and premium plan customers.

    8. Create two remote access policies. One policy is used to authorize basic plan connections (by using the BasicPlanUsers group). The other policy is used to authorize premium plan connections (by using the PremiumPlanUsers group).

    • Authorize connections for basic plan users by using the New Remote Access Policy Wizard to create a common VPN policy with the following settings:
      • Policy name: Basic plan connections
      • Conditions:
        • Windows-Groups matches BasicPlanUsers
      • Permission: Grant remote access permission
      • Profile settings, Dial-in Constraints tab:
        • Allow access only through these media and the Async (Modem) media type are selected.
      • Profile settings, Authentication tab:
        • The Microsoft Encrypted Authentication version 2 (MS-CHAP v2), Microsoft Encrypted Authentication (MS-CHAP), and Encrypted Authentication (CHAP) protocols are selected.

      For more information, see To add a remote access policy.

    • Authorize connections for premium plan users by creating a new remote access policy with the following settings:
      • Policy name: Premium plan connections
      • Conditions:
        • Windows-Groups matches PremiumPlanUsers
      • Permission: Grant remote access permission
      • Profile settings, Dial-in Constraints tab:
        • Allow access only through these media is selected, and then the ISDN Async V.110, ISDN Async V.120, and ISDN Async media types are selected.
      • Profile settings, Authentication tab:
        • The Microsoft Encrypted Authentication version 2 (MS-CHAP v2), Microsoft Encrypted Authentication (MS-CHAP), and Encrypted Authentication (CHAP) protocols are selected.
    • Because all of the ISP customers are using either the basic or premium plan, delete the default remote access policies so that no other types of connections are authorized. For more information, see To delete a remote access policy.

    For additional examples of remote access policies, see Remote access policies examples.

Configuring the secondary IAS server on a different domain controller

To configure the secondary IAS server on a different domain controller, do the following:

  1. On the other domain controller, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the secondary IAS server computer (the other domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the secondary IAS server is authenticating connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the secondary IAS server computer is a member. Next, configure the secondary IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.
  4. Copy the configuration of the primary IAS server to the secondary IAS server. For more information, see To copy the IAS configuration to another server.

Configuring RADIUS accounting and authentication on dial-up servers

To configure each dial-up server to use the primary and secondary IAS servers for authentication, authorization, and accounting of remote access connections, do the following:

  1. If the dial-up server is a computer running XOX; XOX; XOX; or Windows 2000 and the Routing and Remote Access service, configure the primary and secondary IAS servers as RADIUS servers for both RADIUS authentication and accounting. For more information, see To use RADIUS authentication and To use RADIUS accounting.
  2. If the dial-up server is a computer running Windows NT Server 4.0 and the Routing and Remote Access Service (RRAS), see the Windows NT Server 4.0 online Help for information about how to configure the primary and secondary IAS servers as RADIUS servers for RADIUS authentication.
  3. If the dial-up server is a third-party network access server (NAS), see the documentation for the NAS to determine how to configure it as a RADIUS client with two RADIUS servers (the primary and secondary IAS servers).


Outsourced VPN remote access

This topic describes how IAS is used by both an outsourced service provider and an organization to outsource VPN-based remote access. The outsourced service provider offers worldwide Points of Presence (POPs), which organization employees can call. After the call is made, the employee's computer makes a Point-to-Point Tunneling Protocol (PPTP) VPN connection to one of the organization's VPN servers.

The organization in this example configuration has a large central location with remote users. Each user requires secure access to the organization network. The organization has determined that it is more cost-effective to provide VPN remote access through outsourcing than to implement and maintain its own dial-up remote access infrastructure.

The encryption and authentication requirements for the Internet connection are less stringent than those required for the VPN connection. For example, the Internet connection uses CHAP without encryption, while the VPN connection uses smart cards and Extensible Authentication Protocol-Transport Level Security (EAP-TLS) with 128-bit encryption.

This topic describes a configuration for an organization that uses:

  • Two IAS servers.

    • Two IAS servers (one primary and one secondary) are used to provide fault tolerance for RADIUS-based authentication, authorization, and accounting. If only one RADIUS server is configured and it becomes unavailable, dial-up and VPN users cannot connect. By using two IAS servers, the IAS proxies in the ISP network can detect when the primary RADIUS server becomes unavailable and automatically fail over to the secondary IAS server. The IAS servers are placed in the perimeter network.

  • Active Directory domains.

    • Active Directory domains contain the user accounts, passwords, and dial-in properties that each IAS server requires to authenticate user credentials and evaluate both authorization and connection constraints.

  • Smart card certificate infrastructure.

    • The Extensible Authentication Protocol-Transport Level Security (EAP-TLS) authentication protocol is used with smart cards to authenticate VPN remote access users and provide the highest level of security for VPN authentication.

  • Custom remote access policies.

    • Remote access policies are configured to specify, based on group membership, the different types of connection constraints for users.

  • Connection Manager.

    • Connection Manager is used to create a profile with all of the phone numbers of the ISP's POPs. This automates both the dialing of the ISP and the creation of the VPN connection. Remote access users select the location from which they are dialing, and then select either a local or other appropriate ISP phone number (POP) from the phone book in the Connection Manager service profile. Remote access users connect to the ISP's dial-up access server through the Challenge Handshake Password Authentication (CHAP). The realm name portion of the user name is used by the ISP's proxies to forward authentication requests to an IAS proxy in the organization’s perimeter network. After the ISP connection is made, the Connection Manager profile automatically initiates a VPN connection to one of the organization's VPN servers.

  • VPN servers.

    • VPN servers consist of computers running XOX; XOX; XOX; and Windows 2000 and the Routing and Remote Access service.

This topic also describes a configuration for an ISP that uses:

  • Two IAS proxies in the ISP's network.

    • The ISP uses RADIUS proxies on its network to forward RADIUS request messages between the ISP dial-up servers and the RADIUS servers of multiple customers. Two IAS proxies are used to provide fault tolerance for RADIUS authentication.

  • Dial-up access servers.

    • Dial-up servers consist of computers running:

    • XOX
    • XOX
    • XOX
    • Windows 2000 and the Routing and Remote Access service
    • Third-party network access server (NAS) devices

The following illustration shows the outsourced VPN configuration.

Outsourced VPN remote access

Note

  • This topic only describes how to configure IAS. It does not describe the configuration of Active Directory domains, the smart card certificate infrastructure, Connection Manager, or the VPN servers. For more information about how to deploy these components, see the appropriate Help topics.

To configure IAS for this example, complete the following steps:

  • Configure Active Directory for user accounts and groups.
  • Configure the primary IAS server in the perimeter network.
  • Configure the secondary IAS server in the perimeter network.
  • Configure RADIUS authentication and accounting on VPN servers.
  • Configure the Internet firewall to support RADIUS traffic.
  • Configure the primary IAS proxy at the service provider.
  • Configure the secondary IAS proxy at the service provider.
  • Configure RADIUS accounting and authentication on the dial-up access servers at the service provider.

Configuring user accounts and groups

To configure user accounts and groups, do the following:

  1. Ensure that all users who are making remote access connections have a corresponding user account.
  2. If you want to manage access by group, ensure that all user accounts are configured with the Control access through Remote Access Policy remote access permission. For more information, see To configure remote access permission for a user.
  3. Create two universal groups: one for employees (named Employees) and one for contractors (named Contractors). Because of the large number of potential users, create global groups and add the user accounts as members to the appropriate group. Next, add the global groups as members to the universal groups. For more information, see Group scope.
  4. Because the ISP requires the use of Challenge-Handshake Authentication Protocol (CHAP) authentication for the dial-up connection, you must enable support for reversibly encrypted passwords for the appropriate domains. For more information, see To enable reversibly encrypted passwords in a domain.

Configuring the primary IAS server in the perimeter network

To configure the primary IAS server in the perimeter network, do the following:

  1. On a computer running XOX; XOX; or XOX in the perimeter network; install IAS as an optional networking component. For more information, see To install IAS. The computer on which IAS is installed is not required to be dedicated to forwarding RADIUS messages. You can install IAS on a Web server, file server, or DNS server.
  2. Configure the IAS server computer to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the IAS server is authenticating connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the IAS server computer is a member. Next, configure the IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.

    4. If the IAS server is authenticating connection attempts for user accounts in other domains, and those domains do not have a two-way trust with the domain in which the IAS server computer is a member, see Authentication across forests.

  4. Enable file logging for accounting and authentication events. For more information, see To configure log file properties.
  5. If needed, configure additional UDP ports for RADIUS messages that are sent by the ISP's RADIUS proxies. For more information, see To configure IAS port information. By default, IAS uses UDP ports 1812 and 1645 for authentication and ports 1813 and 1646 for accounting.
  6. Add the service provider's RADIUS proxies as RADIUS clients of the IAS server. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets.
  7. Create remote access policies that allow VPN remote access for employees and deny it for contractors.

    8. Use the New Remote Access Policy Wizard to create a common remote access policy that both allows VPN remote access for members of the Employees group and requires the use of EAP-TLS and 128-bit encryption with the following settings:

    • Policy name: VPN connections for employees
    • Access Method: VPN access
    • User or Group: Select Group, and then specify the Employees group (example).
    • Authentication methods: Select the Extensible Authentication Protocol check box, ensure that the Smart Card or other Certificate EAP type is selected, and then clear all other check boxes.
    • Policy Encryption Level: Select the Strongest encryption check box, and then clear all other check boxes.

    Create a custom remote access policy that denies VPN remote access for members of the Contractors group with the following settings:

    • Policy name: Deny VPN connections for contractors
    • Conditions:
      • Windows-Groups matches Contractors
      • NAS-port-type matches Virtual (VPN)
    • Permission: Deny remote access permission

    For additional examples of remote access policies, see Remote access policies examples.

  8. Delete the default remote access policy named Allow access if dial-up permission is enabled. For more information, see To delete a remote access policy.

Configuring the secondary IAS server in the perimeter network

To configure the secondary IAS server on another computer in the perimeter network, do the following:

  1. On another computer running XOX; XOX; or XOX in the perimeter network; install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the secondary IAS server computer (the other domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the secondary IAS server is authenticating connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the secondary IAS server computer is a member. Next, configure the secondary IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.

    4. If the secondary IAS server is authenticating connection attempts for user accounts in other domains, and those domains do not have a two-way trust with the domain in which the secondary IAS server computer is a member, see Authentication across forests.

  4. Copy the configuration from the primary IAS proxy to the secondary IAS proxy in the perimeter network. For more information, see To copy the IAS configuration to another server.

Configuring RADIUS authentication and accounting on the VPN servers

To configure each VPN server to use the primary and secondary IAS servers for authentication, authorization, and accounting of remote access connections, do the following:

  1. If the VPN server is a computer running XOX; XOX; XOX; or Windows 2000 and the Routing and Remote Access service, configure the primary and secondary IAS servers in the perimeter network as RADIUS servers for both RADIUS authentication and accounting. For more information, see To use RADIUS authentication and To use RADIUS accounting.
  2. If the VPN server is a computer running Windows NT Server 4.0 and the Routing and Remote Access Service (RRAS), see the Windows NT Server 4.0 online Help for information about how to configure the primary and secondary IAS servers as RADIUS servers for RADIUS authentication.
  3. If the VPN server is a third-party network access server (NAS), see the documentation for the NAS to determine how to configure it as a RADIUS client with two RADIUS servers (the primary and secondary IAS servers).

Configuring the Internet firewall to support RADIUS traffic

  1. Configure the Internet firewall to allow RADIUS traffic between the IAS servers in the perimeter network and the IAS proxies in the ISP's network.

    2. For more information, see IAS and firewalls.

Configuring the primary IAS proxy at the service provider

  1. On a computer running XOX; XOX; or XOX in the ISP's network; install IAS as an optional networking component. For more information, see To install IAS. The computer on which IAS is installed is not required to be dedicated to forwarding RADIUS messages. You can install IAS on a Web server, file server, or DNS server.
  2. If needed, configure additional UDP ports for authentication and accounting messages that are sent by the ISP's dial-up access servers. For more information, see To configure IAS port information. By default, IAS uses UDP ports 1812 and 1645 for authentication and 1813 and 1646 for accounting.
  3. Add the ISP's dial-up access servers as RADIUS clients of the IAS proxy. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets.
  4. Create a connection request policy that forwards RADIUS request messages on the basis of the ISP customer’s realm name.

    5. Use the New Connection Request Policy Wizard to create a connection request policy with the condition that the user name matches the realm name for the customer's organization and forwards RADIUS request messages to a remote RADIUS server for authentication. In the New Connection Request Policy Wizard, use the New Remote RADIUS Server Group Wizard to create a remote RADIUS server group with members that include the two IAS servers in the customer's perimeter network.

    For more information, see To add a connection request policy.

  5. Delete the default connection request policy named Use Windows authentication for all users. For more information, see To delete a connection request policy.

Configuring the secondary IAS proxy at the service provider

To configure the secondary IAS proxy on another computer in the perimeter network, do the following:

  1. On another computer running XOX; XOX; or XOX in the ISP's network; install IAS as an optional networking component. For more information, see To install IAS.
  2. Copy the configuration of the primary IAS proxy to the secondary IAS proxy in the ISP's network. For more information, see To copy the IAS configuration to another server.

Configuring RADIUS accounting and authentication on the dial-up access servers at the service provider

To configure each dial-up or VPN server to use the primary and secondary IAS servers for authentication, authorization, and accounting of remote access connections, do the following:

  1. If the dial-up or VPN server is a computer running XOX; XOX; XOX; or Windows 2000 and the Routing and Remote Access service, configure the primary and secondary IAS proxies in the ISP's network as RADIUS servers for both RADIUS authentication and accounting. For more information, see To use RADIUS authentication and To use RADIUS accounting.
  2. If the dial-up or VPN server is a computer running Windows NT Server 4.0 and the Routing and Remote Access Service (RRAS), see the Windows NT Server 4.0 online Help for information about how to configure the primary and secondary IAS proxies in the ISP's network as RADIUS servers for RADIUS authentication.
  3. If the dial-up or VPN server is a third-party network access server (NAS), see the documentation for the NAS to determine how to configure it as a RADIUS client with two RADIUS servers (the primary and secondary IAS proxies) in the ISP's network.


Outsourced wireless access

This topic describes how IAS is used by both an outsourced wireless provider and an organization to outsource wireless Internet access. The wireless service provider offers remote wireless access points in locations such as airports. Employees of an organization can use these points to access the Internet. The wireless service provider forwards the access request of a client to an IAS server in the organization. The IAS server provides authentication and authorization. The wireless service provider determines the employee’s organization from the realm name portion of the employee's user name during the authentication process. This enables the service provider to bill the organization for the employee’s use of the wireless connection.

This topic describes a configuration for an organization that uses:

  • Two IAS servers.

    • Two IAS servers (one primary and one secondary) are used to provide fault tolerance for RADIUS-based authentication, authorization, and accounting. If only one RADIUS server is configured and it becomes unavailable, outsourced wireless clients cannot connect. By using two IAS servers, the IAS proxies in the wireless service provider's network can detect when the primary RADIUS server is unavailable and automatically fail over to the secondary IAS server. The IAS servers are placed in the perimeter network.

  • Active Directory domains.

    • Active Directory domains contain the user accounts, passwords, and dial-in properties that each IAS server requires to authenticate user credentials and evaluate both authorization and connection constraints.

  • A certificate infrastructure.

    • The Extensible Authentication Protocol-Transport Level Security (EAP-TLS) authentication protocol is used to authenticate wireless clients with locally installed user certificates.

  • A wireless remote access policy.

    • A common remote access policy is configured so that authenticated wireless users can access the Internet.

This topic also describes a configuration for a wireless service provider that uses:

  • Two IAS proxies in the wireless service provider's network.

    • The wireless service provider uses RADIUS proxies in its network to forward RADIUS request messages between the wireless access points and the RADIUS servers. Two IAS proxies are used to provide fault tolerance for RADIUS authentication.

  • Multiple wireless access points.

    • Third-party wireless access points provide wireless access in different airports.

The following illustration shows the outsourced wireless configuration.

Outsourced wireless access

Note

  • This topic only describes how to configure IAS. It does not describe the configuration of Active Directory domains, the certificate infrastructure, or the wireless access points. For more information about how to deploy these components, see the appropriate Help topics.

To configure IAS for this example, complete the following steps:

  • Configure Active Directory for user accounts and groups.
  • Configure the primary IAS server in the perimeter network.
  • Configure the secondary IAS server in the perimeter network.
  • Configure the Internet firewall to support RADIUS traffic.
  • Configure the primary IAS proxy at the service provider.
  • Configure the secondary IAS proxy at the service provider.
  • Configure RADIUS accounting and authentication on the wireless access points at the service provider.

Configuring user accounts and groups

To configure user accounts and groups, do the following:

  1. Ensure that all users that are making remote access connections have a corresponding user account.
  2. If you want to manage access by group, ensure that all user accounts are configured with the Control access through Remote Access Policy remote access permission. For more information, see To configure remote access permission for a user.
  3. Organize your wireless access users into the appropriate universal and nested groups in order to take advantage of group-based remote access policies. For example, create a universal group named WirelessUsers that contains global groups of wireless user accounts. For more information, see Group scope.

Configuring the primary IAS server in the perimeter network

To configure the primary IAS server in the perimeter network, do the following:

  1. On a computer running XOX; XOX; or XOX in the perimeter network; install IAS as an optional networking component. For more information, see To install IAS. The computer on which IAS is installed is not required to be dedicated to forwarding RADIUS messages. You can install IAS on a Web server, file server, or DNS server.
  2. Configure the IAS server computer to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the IAS server is authenticating connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the IAS server computer is a member. Next, configure the IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.

    4. If the IAS server is authenticating connection attempts for user accounts in other domains, and those domains do not have a two-way trust with the domain in which the IAS server computer is a member, see Authentication across forests.

  4. Enable file logging for accounting and authentication events. For more information, see To configure log file properties.
  5. If needed, configure additional UDP ports for RADIUS messages that are sent by the wireless service provider's RADIUS proxies. For more information, see To configure IAS port information. By default, IAS uses UDP ports 1812 and 1645 for authentication and ports 1813 and 1646 for accounting.
  6. Add the service provider's RADIUS proxies as RADIUS clients of the IAS server. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets.
  7. Use the New Remote Access Policy Wizard to create a common wireless policy with the following settings:
    • Policy name: Wireless access
    • Access Method: Wireless access
    • User or Group: Select Group, and then specify the WirelessUsers group (example).
    • Authentication methods: Select Smart Card or other Certificate. If you have multiple computer certificates, click Configure, and then select the appropriate computer certificate.
    • Policy encryption level: Clear the Basic encryption (MPPE 40-bit) and Basic encryption (MPPE 56-bit) check boxes.

    For additional examples of remote access policies, see Remote access policies examples.

  8. Delete the default remote access policies, or ensure that they are the last policies to be evaluated. For more information, see To delete a remote access policy and To change the policy evaluation order.

Configuring the secondary IAS server in the perimeter network

To configure the secondary IAS server on another computer in the perimeter network, do the following:

  1. On another computer running XOX; XOX; or XOX in the perimeter network; install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the secondary IAS server computer (the other domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the secondary IAS server is authenticating connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the secondary IAS server computer is a member. Next, configure the secondary IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.

    4. If the secondary IAS server is authenticating connection attempts for user accounts in other domains, and those domains do not have a two-way trust with the domain in which the secondary IAS server computer is a member, see Authentication across forests.

  4. Copy the configuration of the primary IAS proxy to the secondary IAS proxy in the perimeter network. For more information, see To copy the IAS configuration to another server.

Configuring the Internet firewall to support RADIUS traffic

To configure the Internet firewall to support RADIUS traffic, do the following:

  1. Configure the Internet firewall to allow RADIUS traffic between the IAS servers in the perimeter network and the IAS proxies in the wireless service provider's network.

    2. For more information, see IAS and firewalls

Configuring the primary IAS proxy at the service provider

To configure the primary IAS proxy at the service provider, do the following:

  1. On a computer running XOX; XOX; or XOX in the wireless service provider's network; install IAS as an optional networking component. For more information, see To install IAS. The computer on which IAS is installed is not required to be dedicated to forwarding RADIUS messages. You can install IAS on a Web server, file server, or DNS server.
  2. If needed, configure additional UDP ports for authentication and accounting messages that are sent by the wireless service provider's access points. For more information, see To configure IAS port information. By default, IAS uses UDP ports 1812 and 1645 for authentication and ports 1813 and 1646 for accounting.
  3. Add the wireless service provider's access points as RADIUS clients of the IAS proxy. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets.
  4. Create a connection request policy that forwards RADIUS request messages based on the realm name of the wireless service provider's customer.

    5. Use the New Connection Request Policy Wizard to create a connection request policy that forwards connection requests to a remote RADIUS server group for authentication and where the user name matches the realm name for the customer's organization. In the New Connection Request Policy Wizard, use the New Remote RADIUS Server Group Wizard to create a remote RADIUS server group with members that include the two IAS servers in the customer's perimeter network.

    For more information, see To add a connection request policy.

  5. Delete the default connection request policy named Use Windows authentication for all users. For more information, see To delete a connection request policy.

Configuring the secondary IAS proxy at the service provider

To configure the secondary IAS proxy on another computer in the perimeter network, do the following:

  1. On another computer running XOX; XOX; or XOX in the wireless service provider network; install IAS as an optional networking component. For more information, see To install IAS.
  2. Copy the configuration of the primary IAS proxy to the secondary IAS proxy in the wireless service provider's network. For more information, see To copy the IAS configuration to another server.

Configuring RADIUS accounting and authentication on the wireless access points at the service provider

Configure each wireless access point as a RADIUS client with two RADIUS servers (the primary and secondary IAS servers). For more information, see the documentation for the wireless access point.


Ethernet switch access

This topic describes how IAS can be used to support authentication, authorization, and accounting for authenticated Ethernet switch connections to an organization. In contrast to user-authenticated connections, such as dial-up and VPN connections, Ethernet connections use computer certificates and computer authentication to validate the computer that is connecting to the Ethernet switch. This topic describes a typical configuration for an organization that uses:

  • Two IAS servers.

    • Two IAS servers (one primary and one secondary) are used to provide fault tolerance for RADIUS-based authentication. If only one RADIUS server is configured and it becomes unavailable, authenticating switch clients cannot connect. By using two IAS servers and configuring all authenticating Ethernet switches (RADIUS clients) for both the primary and secondary IAS servers, the RADIUS clients can detect when the primary RADIUS server is unavailable and automatically fail over to the secondary IAS server.

  • Active Directory domains.

    • Active Directory domains contain the user accounts, passwords, and dial-in properties that each IAS server requires to authenticate user credentials and evaluate both authorization and connection constraints. To optimize IAS authentication and authorization response times and minimize network traffic, IAS is installed on domain controllers.

  • A computer certificate infrastructure.

    • The Extensible Authentication Protocol-Transport Level Security (EAP-TLS) authentication protocol is used with computer certificates to authenticate Ethernet connections and provide the highest level of security for authentication.

  • Ethernet switch remote access policies.

    • Remote access policies are configured for authenticated switch connections so that guest switch users obtain restricted access to a virtual LAN (VLAN) that contains a certificate server and authenticated switch users obtain unrestricted access to the organization intranet.

  • Multiple authenticating switches.

    • Multiple third-party Ethernet authenticating switches provide access in different buildings of an organization.

  • A certificate server on a separate VLAN for new Ethernet switch clients.

    • A certificate server is placed on a separate virtual local area network (VLAN) and used by a new switch client to obtain a computer certificate for subsequent switch access. After 10 minutes of receiving a guest connection, the switch client is disconnected. When the switch client computer reconnects, it authenticates by using the newly installed computer certificate and obtains authenticated switch access to the network.

The following illustration shows an Ethernet switch configuration.

Ethernet switch access

Notes

  • This topic only describes how to configure IAS. It does not describe the configuration of Active Directory domains, the certificate infrastructure, or Ethernet switches. For more information about how to deploy these components, see the appropriate Help topics.
  • This topic describes the bootstrapping of new Ethernet clients by using a VLAN that contains a certificate server. You can also bootstrap new Ethernet clients by using an unauthenticated Ethernet connection or a certificate that has been extracted to a floppy disk.

To configure IAS for this example, complete the following steps:

  • Configure Active Directory for computer accounts and groups.
  • Configure the primary IAS server on a domain controller.
  • Configure the secondary IAS server on a different domain controller.
  • Configure RADIUS authentication and accounting on Ethernet switches.

Configuring computer accounts and groups

To configure computer accounts and groups, do the following:

  1. Ensure that all computers that are making authenticating switch connections have a corresponding computer account.
  2. If you want to manage switch access by group, set the remote access permission on computer accounts to Control access through Remote Access Policy. For more information, see To configure remote access permission for a user.
  3. Organize switch access computers into the appropriate universal and nested groups in order to take advantage of group-based remote access policies. For example, create a universal group named SwitchComputers that contains global groups of switch computer accounts. For more information, see Group scope.
  4. Configure the domain in which the IAS server computers are members for the auto-enrollment of computer certificates. For more information, see To configure automatic certificate allocation from an enterprise CA.
  5. Configure the Guest account to allow guest access for new Ethernet clients. For more information, see Guest authentication. Enable reversibly encrypted password storage on the Guest account. For more information, see User and computer accounts.
  6. Create a group named Guests, and add the Guest account as a member. For more information, see To create a new group.

Configuring the primary IAS server on a domain controller

To configure the primary IAS server on a domain controller, do the following:

  1. On the domain controller, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the IAS server computer (the domain controller) to read the properties of user and computer accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the IAS server authenticates connection attempts for user and computer accounts in other domains, verify that the other domains have a two-way trust with the domain in which the IAS server computer is a member. Next, configure the IAS server computer to read the properties of user and computer accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.

    4. If the IAS server authenticates connection attempts for user and computer accounts in other domains, and those domains do not have a two-way trust with the domain in which the IAS server computer is a member, see Authentication across forests.

  4. Enable file logging for accounting and authentication events. For more information, see To configure log file properties.
  5. If needed, configure additional UDP ports for authentication and accounting messages that are sent by RADIUS clients. For more information, see To configure IAS port information. By default, IAS uses UDP ports 1812 and 1645 for authentication and ports 1813 and 1646 for accounting.
  6. Add the authenticating Ethernet switches as RADIUS clients of the IAS server. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets. Enable the use of the Message Authenticator attribute only when it is supported by the Ethernet switch.
  7. Use the New Remote Access Policy Wizard to create a common Ethernet policy with the following settings:
    • Policy name: Ethernet switch access
    • Access Method: Ethernet
    • User or Group: Select Group, and then specify the SwitchComputers group (example).
    • Authentication methods: Select Smart Card or other Certificate. If you have multiple computer certificates, click Configure, and then select the appropriate computer certificate.
  8. If you are using certificate-based authentication, you can use the New Remote Access Policy Wizard to create a custom Ethernet switch policy with the following settings:
    • Policy name: New switch access
    • Conditions:
      • NAS-Port-Type matches Ethernet
      • Windows-Groups matches Guests
    • Permission: Grant remote access permission
    • Profile settings, Dial-in Constraints tab:
      • Select the Minutes client can be connected check box, and then type 10.
    • Profile settings, Authentication tab:
      • Select Extensible Authentication Protocol and the MD-5 Challenge EAP type, and then clear all other check boxes.
    • Profile settings, Advanced tab:
      • Add the Tunnel-Type attribute with the value of Virtual LANs (VLAN).
      • Add the Tunnel-Pvt-Group-ID attribute with the value of the VLAN ID that corresponds to the VLAN that contains the certificate server for new switch clients.

    For additional examples of remote access policies, see Remote access policies examples.

  9. Delete the default remote access policies, or ensure that they are the last policies to be evaluated. For more information, see To delete a remote access policy and To change the policy evaluation order.

Configuring the secondary IAS server on a different domain controller

To configure the secondary IAS server on a different domain controller, do the following:

  1. On the other domain controller, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the secondary IAS server computer (the other domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the secondary IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the secondary IAS server computer is a member. Next, configure the secondary IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.

    4. If the secondary IAS server authenticates connection attempts for user accounts in other domains, and those domains do not have a two-way trust with the domain in which the secondary IAS server computer is a member, see Authentication across forests.

  4. Copy the configuration of the primary IAS server to the secondary IAS server. For more information, see To copy the IAS configuration to another server.

Configuring RADIUS authentication and accounting on Ethernet switches

To configure your third-party Ethernet switch RADIUS client with two RADIUS servers (the primary and secondary IAS servers), see the Ethernet switch documentation.


Deploying IAS as a RADIUS proxy

This section covers:

  • Planning for IAS as a RADIUS proxy
  • IAS as a RADIUS proxy

Note

  • XOX


Planning for IAS as a RADIUS proxy

This section covers:

  • IAS as a RADIUS proxy design considerations
  • IAS as a RADIUS proxy security considerations

Note

  • XOX


IAS as a RADIUS proxy design considerations

Consider the following design issues when deploying IAS as a RADIUS proxy:

  • The common uses of IAS as a RADIUS proxy

    • For more information about common ways to use IAS as a RADIUS proxy, see IAS as a RADIUS proxy.

  • Connection request policy configuration

    • The default connection request policy named Use Windows authentication for all users is configured for IAS when it is used as a RADIUS server. To create a connection request policy to use IAS as a RADIUS proxy, you must first create a remote RADIUS server group. Next, create a connection request policy that forwards authentication requests to a remote RADIUS server group. Finally, either delete the default connection request policy or move the new connection request policy so that it is evaluated first. For more information, see Introduction to connection request processing. For an example of a connection request policy configured when IAS is being used as a RADIUS proxy, see Remote RADIUS server.

  • Realm replacement and attribute manipulation

    • To convert realm names and configure RADIUS message forwarding based on the realm name, you must configure attribute manipulation for the User-Name attribute on the appropriate connection request policy. For more information, see Connection request policies and To configure attribute manipulation. For an example of a connection request policy that forwards authentication requests based on a specific realm name, see Remote RADIUS server.

    If you are using the MS-CHAP v2 authentication protocol, you cannot manipulate the User Name attribute if the connection request policy is used to forward the RADIUS message. The only exception occurs when a backslash character (\) is used and the manipulation only affects the information to the left of it. A backslash character is typically used to indicate a domain name (the information to the left of it) and a user account name within the domain (the information to the right of it). In this case, only attribute manipulation rules that modify or replace the domain name are allowed.

  • The use of additional RADIUS attributes and vendor-specific attributes

    • If you plan to return additional RADIUS attributes and vendor-specific attributes (VSAs) with RADIUS requests, you must add the RADIUS attributes and VSAs to the appropriate connection request policy. For more information, see Vendor-specific attribute overview and To configure advanced attributes.

  • Remote RADIUS server group configuration

    • To forward RADIUS requests, the connection request policy must be configured to use a remote RADIUS server group (a list of one or more RADIUS servers to which RADIUS messages are forwarded). For more information, see Remote RADIUS server groups and Configure remote RADIUS server groups.

  • Copy logging information at the IAS proxy

    • The IAS proxy can record all RADIUS accounting information in the local log file. This creates a central location for all authentication and accounting information for all of the access servers of the IAS proxy. For more information, see Connection request policies.

  • Authentication and accounting ports

    • When you configure a server in a remote RADIUS server group, you can configure custom UDP ports to which RADIUS authentication and accounting messages are sent. The default UDP port for authentication requests is 1812. The default UDP port for accounting requests is 1813. For more information, see Remote RADIUS server groups and To configure the authentication and accounting settings of a group member.

  • Load balancing and failure detection

    • When you configure multiple servers in a remote RADIUS server group, you can configure settings that determine how the IAS server balances the load of authentication and accounting requests over the RADIUS servers in the group. You can use additional settings to configure IAS to detect and recover from the failure of a remote RADIUS server group member. For more information, see To configure the load balancing properties of a group member.

  • Multiple IAS servers

    • To provide fault tolerance for RADIUS-based authentication and accounting, you should always use at least two IAS servers. One IAS server is used as the primary RADIUS proxy and the other is used as a backup. Access servers or other RADIUS proxies are configured for both IAS servers. They switch to using the backup IAS proxy when the primary IAS proxy becomes unavailable. For information about how to synchronize the configuration of multiple IAS servers, see Managing multiple IAS servers.

Note

  • XOX


IAS as a RADIUS proxy security considerations

Consider the following security issues when deploying IAS as a RADIUS proxy:

  • Shared secrets

    • Configure strong shared secrets to prevent dictionary attacks and change them frequently. Strong shared secrets are a long (more than 22 characters) sequence of random letters, numbers, and punctuation. For more information, see Shared secrets.

  • Firewall configuration

    • If your IAS proxy is on a perimeter network, configure your Internet firewall (between your perimeter network and the Internet) to allow RADIUS messages to pass between your IAS proxy and RADIUS clients on the Internet. You might need to configure an additional firewall that is placed between your perimeter network and your intranet, to allow RADIUS traffic to flow between the IAS proxy on the perimeter network and an IAS server on the intranet. For more information, see IAS and firewalls.

  • Message Authenticator attribute

    • You can use the RADIUS Message Authenticator attribute (also known as a digital signature or the signature attribute) to ensure that RADIUS Access-Request messages for connection requests were sent from a RADIUS client configured with the correct shared secret. The Message Authenticator attribute is always used with EAP—without having to enable it on the IAS server and access server. For the PAP, CHAP, MS-CHAP, and MS-CHAP v2 authentication protocols, you must enable the use of the Message Authenticator attribute on both the IAS server (as part of the configuration of the RADIUS client in Internet Authentication Service) and the RADIUS client (the access server or RADIUS proxy). Ensure that the RADIUS client supports the Message Authenticator attribute before enabling it. For more information, see To edit RADIUS client configuration.

    For information about enabling the RADIUS Message Authenticator attribute for your access server, see the appropriate access server documentation. For the Routing and Remote Access service, the use of the RADIUS Message Authenticator attribute is enabled from the properties of a RADIUS server when you configure RADIUS authentication. For more information, see To use RADIUS authentication.

  • Using IPSec filters to lock down IAS proxy servers

    • You can configure IPSec filters to allow specific network traffic to pass through network interfaces on RADIUS servers. These filters can be applied to organizational units and stored in Active Directory, or they can be created and applied to individual servers. For more information, see Securing RADIUS traffic with IPSec.

  • Password Authentication Protocol (PAP)

    • The use of Password Authentication Protocol (PAP) is strongly discouraged when using RADIUS proxies. For more information, see IAS and firewalls.

Note

  • XOX


IAS as a RADIUS proxy

This section covers:

  • Authentication across forests
  • Outsourced dial and a proxy in the perimeter network
  • Using a different authentication database
  • Using IAS proxy for load balancing
  • Mapping network authentication and authorization

Note

  • XOX


Authentication across forests

This topic describes how IAS can be used as both a RADIUS server and proxy to provide authentication between two forests. This configuration can also be used to provide authentication between both untrusted domains and one-way trusted domains.

Notes

  • When using EAP-TLS with certificates as the authentication method, you need to use one or more RADIUS proxy servers that forward authentication requests to the appropriate forest, even when the forests have a two-way, transitive trust relationship.
  • When using authentication methods other than EAP-TLS with certificates, IAS supports authentication without a RADIUS proxy across two forests when they consist of only domain controllers running XOX; XOX; and XOX; and contain only Windows Server 2003 domains. For more information, see Accessing resources across forests and Domain and forest functionality.

The following configuration is for an organization that uses:

  • Active Directory domains.

    • Active Directory domains contain the user accounts, passwords, and dial-in properties that each IAS server requires to authenticate user credentials and evaluate both authorization and connection constraints. To optimize IAS authentication and authorization response times and minimize network traffic, IAS is installed on domain controllers.

  • Two IAS servers in each forest.

    • Two IAS servers (one primary and one secondary) are used to provide fault tolerance for RADIUS-based authentication, authorization, and accounting in each forest. If only one RADIUS server is configured and it becomes unavailable, access clients for that forest cannot connect. By using two IAS servers and configuring the IAS proxies for both primary and secondary IAS servers, the IAS proxies can detect when the primary RADIUS server is unavailable and automatically fail over to the secondary IAS server.

  • Remote access policies.

    • Remote access policies are configured to specify, based on group membership, the different types of connection constraints for users.

  • Two IAS proxies.

    • Two IAS proxies are used to provide fault tolerance for RADIUS requests that are sent from access servers.

The following illustration shows the authentication across forests configuration that is using IAS proxies.

Authentication across forests

Note

  • This topic only describes how to configure IAS. It does not describe the configuration of Active Directory domains or access servers. For more information about how to deploy these components, see the appropriate Help topics.

To configure IAS for this example, complete the following steps:

  • Configure the Active Directory forests for user accounts and groups.
  • Configure the primary IAS server on a domain controller in the first forest.
  • Configure the secondary IAS server on a different domain controller in the first forest.
  • Configure the primary IAS server on a domain controller in the second forest.
  • Configure the secondary IAS server on a different domain controller in the second forest.
  • Configure the primary IAS proxy.
  • Configure the secondary IAS proxy.
  • Configure RADIUS authentication and accounting on access servers.

Configuring forests for user accounts and groups

To configure forests for user accounts and groups, do the following:

  1. Ensure that all users who are making network access connections have a corresponding user account.
  2. Manage your network access by group by setting the remote access permission on user accounts to Control access through Remote Access Policy. For more information, see To configure remote access permission for a user.
  3. Organize your remote access users into the appropriate universal and nested groups in order to take advantage of group-based remote access policies. For more information, see Group scope.
  4. If you are using the Challenge-Handshake Authentication Protocol (CHAP), enable support for reversibly encrypted passwords for the appropriate domains. For more information, see To enable reversibly encrypted passwords in a domain.

Configuring the primary IAS server on a domain controller in the first forest

To configure the primary IAS server on a domain controller in the first forest, do the following:

  1. On the domain controller in the first forest, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the IAS server computer (the domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the IAS server is authenticating connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the IAS server computer is a member. Next, configure the IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.
  4. Enable file logging for accounting and authentication events. For more information, see To configure log file properties.
  5. Add the IAS proxies as RADIUS clients of the IAS server. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets.
  6. Create the appropriate remote access policies for access clients in the first forest.

    7. For examples of remote access policies, see Remote access policies examples.

Configuring the secondary IAS server on a different domain controller in the first forest

To configure the secondary IAS server on a different domain controller in the first forest, do the following:

  1. On the other domain controller in the first forest, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the secondary IAS server computer (the other domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the secondary IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the secondary IAS server computer is a member. Next, configure the secondary IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.
  4. Copy the configuration of the primary IAS server to the secondary IAS server. For more information, see To copy the IAS configuration to another server.

Configuring the primary IAS server on a domain controller in the second forest

To configure the primary IAS server on a domain controller in the second forest, do the following:

  1. On the domain controller in the second forest, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the IAS server computer (the domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the IAS server computer is a member. Next, configure the IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.
  4. Enable file logging for accounting and authentication events. For more information, see To configure log file properties.
  5. Add the IAS proxies as RADIUS clients of the IAS server. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets.
  6. Create the appropriate remote access policies for access clients in the second forest.

    7. For examples of remote access policies, see Remote access policies examples.

Configuring the secondary IAS server on a different domain controller in the second forest

To configure the secondary IAS server on a different domain controller in the second forest, do the following:

  1. On the other domain controller in the second forest, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the secondary IAS server computer (the other domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the secondary IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the secondary IAS server computer is a member. Next, configure the secondary IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.
  4. Copy the configuration of the primary IAS server to the secondary IAS server. For more information, see To copy the IAS configuration to another server.

Configuring the primary IAS proxy

To configure the primary IAS proxy, do the following:
  1. On a computer running XOX; XOX; or XOX; install IAS as an optional networking component. For more information, see To install IAS. The computer on which IAS is installed is not required to be dedicated to forwarding RADIUS messages. For example, You can install IAS on a Web server, file server, or DNS server.
  2. If needed, configure additional UDP ports for RADIUS messages that are sent by the access servers. For more information, see To configure IAS port information. By default, IAS uses UDP ports 1812 and 1645 for authentication and ports 1813 and 1646 for accounting.
  3. Add the access servers as RADIUS clients of the IAS proxy. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets.
  4. Create a connection request policy that forwards RADIUS request messages (that are based on the realm name of accounts in the first forest) to IAS servers in the first forest.

    5. Use the New Connection Request Policy Wizard to create a connection request policy that forwards connection requests to a remote RADIUS server group and where the realm name matches the realm name of the user accounts in the first forest. Clear the check box that removes the realm name for authentication. In the New Connection Request Policy Wizard, use the New Remote RADIUS Server Group Wizard to create a remote RADIUS server group with members that include the two IAS servers in the first forest.

    For more information, see To add a connection request policy.

  5. Create a connection request policy that forwards RADIUS request messages (that are based on the realm name of accounts in the second forest) to IAS servers in the second forest.

    6. Use the New Connection Request Policy Wizard to create a connection request policy that forwards connection requests to a remote RADIUS server group and where the realm name matches the realm name of the user accounts in the second forest. Clear the check box that removes the realm name for authentication. In the New Connection Request Policy Wizard, use the New Remote RADIUS Server Group Wizard to create a remote RADIUS server group with members that include the two IAS servers in the second forest.

    For more information, see To add a connection request policy.

  6. Delete the default connection request policy named Use Windows authentication for all users. For more information, see To delete a connection request policy.

Configuring the secondary IAS proxy

To configure the secondary IAS proxy on another computer, do the following:

  1. On another computer running XOX; XOX; or XOX; install IAS as an optional networking component. For more information, see To install IAS.
  2. Copy the configuration of the primary IAS proxy to the secondary IAS proxy. For more information, see To copy the IAS configuration to another server.

Configuring RADIUS authentication and accounting on the access servers

To configure each access server to use the primary and secondary IAS proxies for the authentication, authorization, and accounting of network connections, do the following:

  1. If the dial-up or VPN server is a computer running XOX; XOX; XOX; or Windows 2000 and the Routing and Remote Access service, configure the primary and secondary IAS proxies as RADIUS servers for both RADIUS authentication and accounting. For more information, see To use RADIUS authentication and To use RADIUS accounting.
  2. If the dial-up or VPN server is a computer running Windows NT Server 4.0 and the Routing and Remote Access Service (RRAS), see the Windows NT Server 4.0 online Help for information about how to configure the primary and secondary IAS proxies as RADIUS servers for RADIUS authentication.
  3. If the dial-up server, VPN server, wireless access point, or authenticating switch is a third-party access server, see the documentation for the access server to determine how to configure it as a RADIUS client with two RADIUS servers (the primary and secondary IAS proxies).

For more information, see Forest trusts, Accessing resources across forests, Upgrading from a Windows NT domain, and Best practices for Active Directory Domains and Trusts.

Note

  • XOX


Outsourced dial and a proxy in the perimeter network

This topic describes how IAS can be used as a RADIUS proxy to forward messages between the RADIUS proxies of an outsourced dial service provider and RADIUS servers within an organization intranet. The outsourced service provider offers worldwide Points of Presence (POPs), which the employees of an organization can call. After the call is completed, the employee's computer is connected to the organization's intranet.

This topic describes a configuration for an organization that uses:

  • Two IAS servers.

    • Two IAS servers (one primary and one secondary) are used to provide fault tolerance for RADIUS-based authentication, authorization, and accounting. If only one RADIUS server is configured and it becomes unavailable, dial-in and VPN users cannot connect. By using two IAS servers and configuring both primary and secondary IAS proxies in the perimeter network for both the primary and secondary IAS servers, the IAS proxies can detect when the primary RADIUS server is unavailable and automatically fail over to the secondary IAS server.

  • Active Directory domains.

    • Active Directory domains contain the user accounts, passwords, and dial-in properties that each IAS server requires to authenticate user credentials and evaluate both authorization and connection constraints. To optimize IAS authentication and authorization response times and minimize network traffic, IAS is installed on domain controllers.

  • Custom remote access policies.

    • Remote access policies are configured to specify, based on group membership, the different types of connection constraints for users.

  • Two IAS proxies in the perimeter network.

    • To simplify the configuration of the intranet firewall, IAS proxies are used in the perimeter network instead of IAS servers. When IAS servers are used in the perimeter network, you must either configure each IAS server computer with two network adapters (one connected to the perimeter network and one connected to the intranet), or configure the intranet firewall to allow Active Directory traffic between the IAS servers on the perimeter network and all of the domain controllers in the intranet. By replacing the IAS server computers with IAS proxies, the IAS proxy computers do not require two network adapters. Additionally, the intranet firewall is only required to be configured to allow RADIUS traffic between the IAS proxies in the perimeter network and the IAS servers in the intranet.

    Two IAS proxies are used in the perimeter network to provide fault tolerance for RADIUS requests that are sent from the service provider's proxies.

  • Connection Manager.

    • To automate service provider dialing, Connection Manager is used to create a profile with all of the phone numbers of the service provider POPs. Remote access users select the location from which they are dialing, and then select the appropriate phone number (POP) from the phone book in the Connection Manager service profile for the service provider. The remote access user connects to the service provider's dial-in access server through Challenge Handshake Password Authentication (CHAP). The realm name portion of the user name is used by the service provider's proxies to forward the authentication requests to an IAS proxy in the perimeter network of the organization.

This topic also describes a configuration for a service provider that uses:

  • Two IAS proxies in the service provider's network.

    • The service provider uses RADIUS proxies in its network to forward RADIUS request messages between the dial-in servers of the service provider and the RADIUS servers or proxies of multiple customers across the Internet. Two IAS proxies are used to provide fault tolerance for RADIUS authentication.

  • Dial-up access servers.

    • Dial-up servers consist of computers running:

    • XOX
    • XOX
    • XOX
    • Windows 2000 and the Routing and Remote Access service
    • Third-party network access server (NAS) devices

The following illustration shows the outsourced dial configuration using IAS proxies in the organization's intranet.

Outsourced dial and using IAS proxies in the perimeter network

Note

  • This topic only describes how to configure IAS. It does not describe the configuration of Active Directory domains or Connection Manager. For more information about how to deploy these components, see the appropriate Help topics.

To configure IAS for this example, complete the following steps:

  • Configure Active Directory for user accounts and groups.
  • Configure the primary IAS server on a domain controller.
  • Configure the secondary IAS server on a different domain controller.
  • Configure RADIUS authentication and accounting on VPN servers.
  • Configure the primary IAS proxy in the perimeter network.
  • Configure the secondary IAS proxy in the perimeter network.
  • Configure the intranet and Internet firewalls to support RADIUS traffic.
  • Configure the primary IAS proxy at the service provider.
  • Configure the secondary IAS proxy at the service provider.
  • Configure RADIUS accounting and authentication on the dial-up access servers at the service provider.

Configuring user accounts and groups

To configure user accounts and groups, do the following:

  1. Ensure that all users who are making remote access connections have a corresponding user account.
  2. Manage your network access by group by setting the remote access permission on user accounts to Control access through Remote Access Policy. For more information, see To configure remote access permission for a user.
  3. Organize your remote access users into the appropriate universal and nested groups in order to take advantage of group-based remote access policies. For more information, see Group scope.
  4. Because the outsourced service provider requires the use of Challenge-Handshake Authentication Protocol (CHAP) authentication for the dial-in connection, you must enable support for reversibly encrypted passwords for the appropriate domains. For more information, see To enable reversibly encrypted passwords in a domain.

Configuring the primary IAS server on a domain controller

To configure the primary IAS server on a domain controller, do the following:

  1. On the domain controller, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the IAS server computer (the domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the IAS server computer is a member. Next, configure the IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.

    4. If the IAS server is authenticating connection attempts for user accounts in other domains, and those domains do not have a two-way trust with the domain in which the IAS server computer is a member, see Authentication across forests.

  4. Enable file logging for accounting and authentication events. For more information, see To configure log file properties.
  5. Add the IAS proxies in the perimeter network as RADIUS clients of the IAS server. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets.
  6. Create remote access policies that accurately reflect your remote access usage.

    7. For example, to configure a custom remote access policy to permit members of the Contractors group to connect from 8:00 AM to 5:00 PM, Monday through Friday, use the New Remote Access Policy Wizard to create a new custom remote access policy with the following settings:

    • Policy name: Contractor connections
    • Conditions:
      • Windows-Groups matches Contractors
    • Permission: Grant remote access permission
    • Profile settings, Dial-in Constraints tab:
      • Allow access only on these days and at these times is set to 8:00 AM to 5:00 PM, Monday through Friday.

    To configure a remote access policy that requires members of the Executives group to use EAP-TLS authentication and 128-bit encryption, use the New Remote Access Policy Wizard to create a common remote access policy with the following settings:

    • Policy name: High security connections for executives
    • Access Method: Dial-up access
    • User or Group: Select Group, and then specify the Executives group (example).
    • Authentication methods: Select Extensible Authentication Protocol (EAP) and, in Type, select Smart Card or other Certificate. If you have multiple computer certificates, click Configure, select the appropriate computer certificate, and then clear all other check boxes.
    • Policy Encryption Level: Select the Strongest encryption (MPPE 128-bit) check box, and then clear all other check boxes.

    For additional examples of remote access policies, see Remote access policies examples.

    If you have created new remote access policies, either delete the default remote access policies, or ensure that they are the last policies to be evaluated. For more information, see To delete a remote access policy and To change the policy evaluation order.

Configuring the secondary IAS server on a different domain controller

To configure the secondary IAS server on a different domain controller, do the following:

  1. On the other domain controller, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the secondary IAS server computer (the other domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the secondary IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the secondary IAS server computer is a member. Next, configure the secondary IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.

    4. If the secondary IAS server authenticates connection attempts for user accounts in other domains, and those domains do not have a two-way trust with the domain in which the secondary IAS server computer is a member, see Authentication across forests.

  4. Copy the configuration of the primary IAS server to the secondary IAS server. For more information, see To copy the IAS configuration to another server.

Configuring RADIUS authentication and accounting on the VPN servers

To configure each VPN server to use the primary and secondary IAS servers for authentication, authorization, and accounting of remote access connections, do the following:

  1. If the VPN server is a computer running XOX; XOX; XOX; or Windows 2000 and the Routing and Remote Access service, configure the primary and secondary IAS servers in the perimeter network as RADIUS servers for both RADIUS authentication and accounting. For more information, see To use RADIUS authentication and To use RADIUS accounting.
  2. If the VPN server is a computer running Windows NT Server 4.0 and the Routing and Remote Access Service (RRAS), see the Windows NT Server 4.0 online Help for instructions about how to configure the primary and secondary IAS servers as RADIUS servers for RADIUS authentication.
  3. If the VPN server is a third-party network access server (NAS), see the documentation for the NAS to determine how to configure it as a RADIUS client with two RADIUS servers (the primary and secondary IAS servers).

Configuring the primary IAS proxy in the perimeter network

To configure the primary IAS proxy in the perimeter network, do the following:

  1. On a computer running XOX; XOX; or XOX in the perimeter network; install IAS as an optional networking component. For more information, see To install IAS. The computer on which IAS is installed is not required to be dedicated to forwarding RADIUS messages. You can install IAS on a Web server, file server, or DNS server.
  2. If needed, configure additional UDP ports for RADIUS messages that are sent by the service provider's RADIUS proxies. For more information, see To configure IAS port information. By default, IAS uses UDP ports 1812 and 1645 for authentication and ports 1813 and 1646 for accounting.
  3. Add the service provider's RADIUS proxies as RADIUS clients of the IAS server. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets.
  4. Create a connection request policy that forwards RADIUS request messages based on the realm name of your organization.

    5. Use the New Connection Request Policy Wizard to create a connection request policy that forwards connection requests to a remote RADIUS server group and where the realm name matches the realm name of the user accounts in your organization. Clear the check box that removes the realm name for authentication. In the New Connection Request Policy Wizard, use the New Remote RADIUS Server Group Wizard to create a remote RADIUS server group with members that include the two IAS servers within your intranet.

    For more information, see To add a connection request policy.

  5. Delete the default connection request policy named Use Windows authentication for all users. For more information, see To delete a connection request policy.

Configuring the secondary IAS proxy in the perimeter network

To configure the secondary IAS proxy on another computer in the perimeter network, do the following:

  1. On another computer running XOX; XOX; or XOX in the perimeter network; install IAS as an optional networking component. For more information, see To install IAS.
  2. Copy the configuration of the primary IAS proxy to the secondary IAS proxy in the perimeter network. For more information, see To copy the IAS configuration to another server.

Configuring the intranet and Internet firewalls to support RADIUS traffic

To configure the intranet and Internet firewalls to support RADIUS traffic, do the following:

  1. Configure the intranet firewall to allow RADIUS traffic between the IAS proxies in the perimeter network and the IAS servers in the intranet.
  2. Configure the Internet firewall to allow RADIUS traffic between the IAS proxies in the perimeter network and the IAS proxies in the service provider's network.

    3. For more information, see IAS and firewalls

Configuring the primary IAS proxy at the service provider

To configure the primary IAS proxy at the service provider, do the following:

  1. On a computer running XOX; XOX; or XOX in the service provider's network; install IAS as an optional networking component. For more information, see To install IAS. The computer on which IAS is installed is not required to be dedicated to forwarding RADIUS messages. You can install IAS on a Web server, file server, or DNS server.
  2. If needed, configure additional UDP ports for authentication and accounting messages that are sent by the service provider's dial-up access servers. For more information, see To configure IAS port information. By default, IAS uses UDP ports 1812 and 1645 for authentication and ports 1813 and 1646 for accounting.
  3. Add the service provider's dial-up access servers as RADIUS clients of the IAS proxy. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets.
  4. Create a connection request policy that forwards RADIUS request messages based on the realm name of the service provider's customer.

    5. Use the New Connection Request Policy Wizard to create a connection request policy that forwards connection requests to a remote RADIUS server group and where the realm name matches the realm name of the customer's organization. Clear the check box that removes the realm name for authentication. In the New Connection Request Policy Wizard, use the New Remote RADIUS Server Group Wizard to create a remote RADIUS server group with members that include the two IAS proxies in the customer's perimeter network.

    For more information, see To add a connection request policy.

  5. Delete the default connection request policy named Use Windows authentication for all users. For more information, see To delete a connection request policy.

Configuring the secondary IAS proxy at the service provider

To configure the secondary IAS proxy on another computer in the perimeter network, do the following:

  1. On another computer running XOX; XOX; or XOX in the service provider's network; install IAS as an optional networking component. For more information, see To install IAS.
  2. Copy the configuration of the primary IAS proxy to the secondary IAS proxy in the service provider's network. For more information, see To copy the IAS configuration to another server.

Configuring RADIUS accounting and authentication on the dial-up servers at the service provider

To configure each dial-up server to use the primary and secondary IAS proxies in the service provider's network for the authentication, authorization, and accounting of dial-up connections, do the following:

  1. If the dial-up or VPN server is a computer running XOX; XOX; XOX; or Windows 2000 and the Routing and Remote Access service, configure the primary and secondary IAS proxies in the service provider's network as RADIUS servers for both RADIUS authentication and accounting. For more information, see To use RADIUS authentication and To use RADIUS accounting.
  2. If the dial-up or VPN server is a computer running Windows NT Server 4.0 and the Routing and Remote Access Service (RRAS), see the Windows NT Server 4.0 online Help for information about how to configure the primary and secondary IAS proxies in the service provider's network as RADIUS servers for RADIUS authentication.
  3. If the dial-up or VPN server is a third-party network access server (NAS), see the documentation for the NAS to determine how to configure it as a RADIUS client with two RADIUS servers (the primary and secondary IAS proxies in the service provider's network).

Note

  • XOX


Using a different authentication database

This topic describes how IAS can be used as a RADIUS proxy to forward RADIUS messages between access servers and two different user account databases. An Active Directory forest and another user account database are used as examples.

The following configuration is for an organization that uses:

  • Active Directory domains.

    • Active Directory domains contain the user accounts, passwords, and dial-in properties that each IAS server requires to authenticate user credentials and evaluate both authorization and connection constraints. To optimize IAS authentication and authorization response times and minimize network traffic, IAS is installed on domain controllers.

  • Another user account database.

    • There is another user account database that is used to authenticate and authorize connection attempts. Examples of other user account databases are Novell Directory Services (NDS) and Structured Query Language (SQL). Because IAS can only access Windows-based user account databases, a third-party RADIUS server must be used to access another user account database.

  • Two IAS servers for each authentication database.

    • Two IAS servers (one primary and one secondary) are used to provide fault tolerance for RADIUS-based authentication, authorization, and accounting for each user account database. If only one RADIUS server is configured and it becomes unavailable, access clients for that user account database cannot connect. By using two IAS servers and configuring the IAS proxies for both primary and secondary IAS servers for each account database, the IAS proxies can detect when the primary RADIUS server is unavailable and automatically fail over to the secondary IAS server.

  • Remote access policies.

    • Remote access policies are configured to specify, based on group membership, the different types of connection constraints for users.

  • Two IAS proxies.

    • Two IAS proxies are used to provide fault tolerance for RADIUS requests that are sent from access servers.

The following illustration shows the use of IAS proxies to forward RADIUS messages between the access servers and the RADIUS servers that are accessing two different user account databases.

Using a different authentication database

Note

  • This topic only describes how to configure IAS. It does not describe the configuration of Active Directory domains, access servers, the third-party RADIUS servers, or the other user account database. For more information about how to deploy these components, see the appropriate Help topics.

To configure IAS for this example, complete the following steps:

  • Configure the Active Directory forest for user accounts and groups.
  • Configure the primary IAS server on a domain controller.
  • Configure the secondary IAS server on a different domain controller.
  • Configure the primary and secondary RADIUS servers for the other user account database.
  • Configure the primary IAS proxy.
  • Configure the secondary IAS proxy.
  • Configure RADIUS authentication and accounting on the access servers.

Configuring the forests for user accounts and groups

To configure the forest for user accounts and groups, do the following:

  1. Ensure that all users that are making network access connections have a corresponding user account.
  2. Manage your network access by group by setting the remote access permission on user accounts to Control access through Remote Access Policy. For more information, see To configure remote access permission for a user.
  3. Organize your remote access users into the appropriate universal and nested groups in order to take advantage of group-based remote access policies. For more information, see Group scope.
  4. If you are using the Challenge-Handshake Authentication Protocol (CHAP), enable support for reversibly encrypted passwords for the appropriate domains. For more information, see To enable reversibly encrypted passwords in a domain.

Configuring the primary IAS server on a domain controller

To configure the primary IAS server on a domain controller, do the following:

  1. On the domain controller, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the IAS server computer (the domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the IAS server computer is a member. Next, configure the IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.

    4. If the IAS server authenticates connection attempts for user accounts in other domains, and those domains do not have a two-way trust with the domain in which the IAS server computer is a member, see Authentication across forests.

  4. Enable file logging for accounting and authentication events. For more information, see To configure log file properties.
  5. Add the IAS proxies as RADIUS clients of the IAS server. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets.
  6. Create the appropriate remote access policies for access clients.

    7. For examples of remote access policies, see Remote access policies examples.

Configuring the secondary IAS server on a different domain controller

To configure the secondary IAS server on a different domain controller, do the following:

  1. On the other domain controller, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the secondary IAS server computer (the other domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the secondary IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the secondary IAS server computer is a member. Next, configure the secondary IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.

    4. If the secondary IAS server authenticates connection attempts for user accounts in other domains, and those domains do not have a two-way trust with the domain in which the IAS server computer is a member, see Authentication across forests.

  4. Copy the configuration of the primary IAS server to the secondary IAS server. For more information, see To copy the IAS configuration to another server.

Configuring the primary and secondary RADIUS servers for the other user account database

To configure the primary and secondary RADIUS servers to access the additional user account database and to add the two IAS proxies as RADIUS clients, see the documentation for the RADIUS servers.

Configuring the primary IAS proxy

To configure the primary IAS proxy, do the following:
  1. On a computer running XOX; XOX; or XOX; install IAS as an optional networking component. For more information, see To install IAS. The computer on which IAS is installed is not required to be dedicated to forwarding RADIUS messages. For example, you can install IAS on a Web server, file server, or DNS server.
  2. If needed, configure additional UDP ports for RADIUS messages that are sent by the access servers. For more information, see To configure IAS port information. By default, IAS uses UDP ports 1812 and 1645 for authentication and ports 1813 and 1646 for accounting.
  3. Add the access servers as RADIUS clients of the IAS server. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets.
  4. Create a connection request policy that forwards RADIUS request messages to the IAS servers where the realm name matches the user accounts in the forest.

    5. Use the New Connection Request Policy Wizard to create a connection request policy that forwards connection requests to a remote RADIUS server group and where the realm name matches the realm name for the user accounts in the forest. Clear the check box that removes the realm name for authentication. In the New Connection Request Policy Wizard, use the New Remote RADIUS Server Group Wizard to create a remote RADIUS server group with members that include the two IAS servers.

    For more information, see To add a connection request policy.

  5. Create a connection request policy that forwards RADIUS request messages based on the realm name of accounts in the additional user account database to the RADIUS servers.

    6. Use the New Connection Request Policy Wizard to create a connection request policy that forwards connection requests to a remote RADIUS server and where the realm name matches the realm name for the user accounts in the additional user account database. Clear the check box that removes the realm name for authentication. In the New Connection Request Policy Wizard, use the New Remote RADIUS Server Group Wizard to create a remote RADIUS server group with members that include the two RADIUS servers.

    For more information, see To add a connection request policy.

  6. Delete the default connection request policy named Use Windows authentication for all users. For more information, see To delete a connection request policy.

Configuring the secondary IAS proxy

To configure the secondary IAS proxy on another computer, do the following:

  1. On another computer running XOX; XOX; or XOX; install IAS as an optional networking component. For more information, see To install IAS.
  2. Copy the configuration of the primary IAS proxy to the secondary IAS proxy. For more information, see To copy the IAS configuration to another server.

Configuring RADIUS authentication and accounting on the access servers

To configure each access server to use the primary and secondary IAS proxies for the authentication, authorization, and accounting of network connections, do the following:

  1. If the dial-up or VPN server is a computer running XOX; XOX; XOX; or Windows 2000 and the Routing and Remote Access service, configure the primary and secondary IAS proxies as RADIUS servers for both RADIUS authentication and accounting. For more information, see To use RADIUS authentication and To use RADIUS accounting.
  2. If the dial-up or VPN server is a computer running Windows NT Server 4.0 and the Routing and Remote Access Service (RRAS), see the Windows NT Server 4.0 online Help for information about how to configure the primary and secondary IAS proxies as RADIUS servers for RADIUS authentication.
  3. If the dial-up server, VPN server, wireless access point, or authenticating switch is a third-party access server, see the documentation for the access server to determine how to configure it as a RADIUS client with two RADIUS servers (the primary and secondary IAS proxies).

Note

  • XOX


Using IAS proxy for load balancing

This topic describes how IAS proxies, placed between access servers and IAS servers, can be used to balance the load of a large volume of authentication traffic. Without IAS proxies, each access server balances its RADIUS requests across multiple RADIUS servers and detects unavailable RADIUS servers. By using IAS proxy, consistent load balancing is used to spread the load of authentication, authorization, and accounting traffic across all the IAS servers in the organization. Additionally, there is a consistent scheme for failure detection and RADIUS server failover.

The following configuration is for an organization that uses:

  • Active Directory domains.

    • Active Directory domains contain the user accounts, passwords, and dial-in properties that each IAS server requires to authenticate user credentials and evaluate both authorization and connection constraints. To optimize IAS authentication and authorization response times and minimize network traffic, IAS is installed on domain controllers.

  • Multiple IAS servers.

    • To balance the load of RADIUS authentication, authorization, and accounting across multiple domain controllers, IAS is installed as a RADIUS server on them.

  • Remote access policies.

    • Remote access policies are configured to specify, based on group membership, the different types of connection constraints for users.

  • Two IAS proxies.

    • Two IAS proxies are used to provide fault tolerance for RADIUS requests that are sent from access servers.

The following illustration shows IAS proxies used to balance the load of RADIUS traffic across multiple IAS servers.

Using IAS proxy for load balancing

Note

  • This topic only describes how to configure IAS. It does not describe the configuration of Active Directory domains or access servers. For more information about how to deploy these components, see the appropriate Help topics.

To configure IAS for this example, complete the following steps:

  • Configure the Active Directory forests for user accounts and groups.
  • Configure the IAS server on domain controllers.
  • Configure the primary IAS proxy.
  • Configure the secondary IAS proxy.
  • Configure RADIUS authentication and accounting on access servers.

Configuring forests for user accounts and groups

To configure Active Directory for user accounts and groups, do the following:

  1. Ensure that all users that are making network access connections have a corresponding user account.
  2. Manage your network access by group by setting the remote access permission on user accounts to Control access through Remote Access Policy. For more information, see To configure remote access permission for a user.
  3. Organize your remote access users into the appropriate universal and nested groups in order to take advantage of group-based remote access policies. For more information, see Group scope.
  4. If you are using the Challenge-Handshake Authentication Protocol (CHAP), enable support for reversibly encrypted passwords for the appropriate domains. For more information, see To enable reversibly encrypted passwords in a domain.

Configuring the IAS server on domain controllers

To configure IAS as a RADIUS server on each domain controller, do the following:

  1. On the domain controller, install IAS as an optional networking component. For more information, see To install IAS.
  2. Configure the IAS server computer (the domain controller) to read the properties of user accounts in the domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  3. If the IAS server authenticates connection attempts for user accounts in other domains, verify that the other domains have a two-way trust with the domain in which the IAS server computer is a member. Next, configure the IAS server computer to read the properties of user accounts in other domains. For more information, see To enable the IAS server to read user accounts in Active Directory. For more information about trust relationships, see Trust direction.
  4. Enable file logging for accounting and authentication events. For more information, see To configure log file properties.
  5. Add the IAS proxies as RADIUS clients of the IAS server. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets.
  6. Create the appropriate remote access policies for access clients.

    7. For examples of remote access policies, see Remote access policies examples.

Configuring the primary IAS proxy

To configure the primary IAS proxy, do the following:
  1. On a computer running XOX; XOX; or XOX; install IAS as an optional networking component. For more information, see To install IAS. The computer on which IAS is installed is not required to be dedicated to forwarding RADIUS messages. For example, You can install IAS on a Web server, file server, or DNS server.
  2. If needed, configure additional UDP ports for RADIUS messages that are sent by the access servers. For more information, see To configure IAS port information. By default, IAS uses UDP ports 1812 and 1645 for authentication and ports 1813 and 1646 for accounting.
  3. Add the access servers as RADIUS clients of the IAS server. For more information, see To add RADIUS clients. Verify that you are configuring the correct name or IP address and shared secrets. For more information, see Shared secrets.
  4. Use the New Remote RADIUS Server Group Wizard to create a custom remote RADIUS server group. Add each IAS server as a member of the remote RADIUS server group and configure each group member with the priority of 1 and a weight of 50.
  5. Create a connection request policy that forwards RADIUS request messages to the IAS servers where the realm name matches the accounts in the domain.

    6. Use the New Connection Request Policy Wizard to create a connection request policy that forwards connection requests to a remote RADIUS server and where the realm name matches the realm name for the user accounts in the forest. Clear the check box that removes the realm name for authentication. Select the previously created remote RADIUS server group as the group to forward connection requests.

    For more information, see To add a connection request policy.

  6. Delete the default connection request policy named Use Windows authentication for all users. For more information, see To delete a connection request policy.

Configuring the secondary IAS proxy

To configure the secondary IAS proxy on another computer, do the following:

  1. On another computer running XOX; XOX; or XOX; install IAS as an optional networking component. For more information, see To install IAS.
  2. Copy the configuration of the primary IAS proxy to the secondary IAS proxy. For more information, see To copy the IAS configuration to another server.

Configuring RADIUS authentication and accounting on the access servers

To configure each access server to use the primary and secondary IAS proxies for the authentication, authorization, and accounting of network connections, do the following:

  1. If the dial-up or VPN server is a computer running XOX; XOX; XOX; or Windows 2000 and the Routing and Remote Access service, configure the primary and secondary IAS proxies as RADIUS servers for both RADIUS authentication and accounting. For more information, see To use RADIUS authentication and To use RADIUS accounting.
  2. If the dial-up or VPN server is a computer running Windows NT Server 4.0 and the Routing and Remote Access Service (RRAS), see the Windows NT Server 4.0 online Help for information about how to configure the primary and secondary IAS proxies as RADIUS servers for RADIUS authentication.
  3. If the dial-up or VPN server is a third-party access server, see the documentation for the access server to determine how to configure it as a RADIUS client with two RADIUS servers (the primary and secondary IAS proxies).

Note

  • XOX


Mapping network authentication and authorization

You can use IAS proxy to split network access authorization and authentication between two user account databases. You can authenticate visitors (such as partner organization employees) with their password-based credentials stored in an external partner organization user database, while performing authorization with your local Active Directory user account database. To split authentication and authorization, you must create a local user account for each visitor. The visitor account user name must map to an account in the partner organization user database with the same user name. When the visitor logs on to your network, the external user database provides authentication, while the local user database and remote access policies are used to process authorization.

The forwarding of authentication requests to the partner organization RADIUS server is necessary only when visitor authentication is performed with password-based credentials. Visitors can also be authenticated by mapping certificates to local user accounts. If a partner organization uses certificate-based authentication, you can authenticate visitors by trusting the partner organization certification authority (CA) and mapping visitor certificates to local user accounts. Because the visitor is authenticated locally with a certificate, it is not necessary to forward authentication requests to the remote RADIUS server at the partner organization.

For more information about certificate mapping, see Mapping certificates to user accounts, To map a certificate to a user account, and To map an account from a trusted non-Windows Kerberos realm to a user account.

Mapping with password-based authentication

When partner organizations use password-based authentication, you must configure local user accounts for visitors and configure the IAS proxy server to forward authentication requests to a remote RADIUS server group that contains the partner company RADIUS server.

Configuring visitor user accounts

If you are using password-based authentication, you must create a user account for each visitor. The visitor user account must be created so that the user name in the local database and the user name in the partner organization user database match exactly. To allow visitors access to your organization network while authenticating them at their partner organization, perform the following actions to configure visitor accounts:

  • Add the user principal name suffix to the domain.

    For more information, see To add user principal name suffixes.

  • Create an organizational unit that will contain the user accounts for visitors.

    For more information, see To create a new organizational unit.

  • Create user accounts in the organizational unit for visitors.

    When you create the user account, the user logon name must exactly match the visitor's user logon name as configured in the user account database at the partner organization. For example, if the user's user logon name at Microsoft Corporation is user@microsoft.com, designate "user" as the User logon name while creating the new user account with Active Directory Users and Computers. Also, select the correct UPN suffix from the drop-down list of suffixes. For example, if in step one you added the UPN suffix "microsoft.com", select "@microsoft.com" from the list. For more information, see To create a new user account.

  • Configure user account properties

    Make sure that the user account is configured in a way that will allow the visitor network access, but will also contain any necessary security restrictions. For example, in user account properties, on the Dial-in tab, you can set Remote Access Permission (Dial-in or VPN) to Allow access.

Configuring the IAS proxy server

To allow visitors access to your organization network, you need to perform the following actions on your IAS proxy server:

  • Configure the partner organization RADIUS server as a member of a Remote RADIUS server group.

    Run the New Remote RADIUS Server Group Wizard, create and name a custom group, and then add the partner organization RADIUS server (or servers) to the group. While adding each server, configure the shared secret (obtained from the partner organization) on the Authentication/Accounting tab of the Add RADIUS server dialog box.

    For more information, see To add a remote RADIUS server group and Configure the members of a remote RADIUS server group.

  • Configure a connection request policy for visitor access.

    To determine whether a specific connection attempt request or an accounting message received from a RADIUS client should be processed locally or forwarded to another RADIUS server, the IAS server uses connection request processing. When you allow visitor access with external authentication, you must configure a minimum of two connection request policies on your IAS proxy server. One policy allows your organization employees access, while denying access to other network access attempts. Another policy allows visitor access. When you configure your policy evaluation order, place the policy or policies for your organization users last, with the visitor policy processed first. For more information, see To change the policy evaluation order.

    To configure a connection request policy, run the New Connection Request Policy Wizard, create and name a custom policy, and then add Policy Conditions. You can configure as many conditions as you want, but you must include the User-Name attribute. Use wildcard and other characters described in Pattern matching syntax to configure a value that must be matched by the user principal name (UPN) suffix your visitors will use when logging on. For example, if you want to authenticate all visitors from Microsoft Corporation with this connection request policy, you can type "^.@microsoft\.com$" in User-Name. In Request Processing Method, click Edit Profile, and then click the Advanced tab. Click Add, and then add the attribute Remote-RADIUS-to-Windows-User-Mapping, with the attribute value set to True. This attribute tells the IAS proxy server to authenticate users (whose properties match other policy conditions) against the RADIUS servers configured in the Remote RADIUS Server Group. On the Attribute tab, you can configure replacement text for the User-Name attribute, as well as configure any other attributes that you require. On the Authentication tab, click Forward requests to the following remote RADIUS server group for authentication, and then choose the Remote RADIUS server group that can authenticate your visitors.

    For more information, see To add a connection request policy, Realm names, Configure connection request processing, and Connection request processing.

  • Configure a remote access policy for visitor access.

    Because you can create remote access policies that are based on different types of connections and group membership, you can create a remote access policy used specifically to process network access attempts by visitors. At minimum, you need two remote access policies: one for your employees and a different one for visitors. For more information, see Introduction to remote access policies and Remote access policies examples.

  • Ensure that network access servers are configured as RADIUS clients to this IAS proxy.

    When visitors log on to your network, they do so through network access servers, such as wireless access points. These access points must be configured as RADIUS clients to your IAS proxy server.

    For more information, see Configure RADIUS clients.

After the IAS proxy is configured to forward authentication requests and user accounts for visitors are created in Active Directory, the password-based authentication request is forwarded to the partner organization RADIUS server when the visitor logs onto your organization network. If the user is authenticated, authorization is performed against your organization Active Directory user database. Active Directory returns user attributes (values configured for the user account, such as Allow access on the Dial-in tab of user properties), and IAS performs policy evaluation against these local user account attributes.

Important

  • By configuring a local user account with the UPN of an account in the remote partner organization user account database, you map one account to the other. If the partner organization changes the user name of an account you have mapped, you must change the user name in your user account database, too.

Mapping with certificate-based authentication

Certificate-based authentication is more secure than password-based authentication. In addition, when you map certificates to user accounts instead of using password-based authentication methods, an authentication request is not forwarded to the partner organization RADIUS server and user account database. For these reasons, certificate mapping enhances security and can significantly reduce logon time for users.

A certificate is mapped to a user account in one of two ways: a single certificate is mapped to a single user account (one-to-one mapping) or multiple certificates are mapped to one user account (many-to-one mapping).

One-to-one mapping

For one-to-one mapping of certificates to visitor user accounts, you must perform the following steps:

  • Create a user account for each visitor according to the steps in Configuring visitor user accounts.

    Because the user account itself is not mapped to the user account at the partner organization, the user account names do not have to exactly match the user account names in the partner organization user accounts database. Configuring the local account with the same user name, however, can make it easier to configure realm manipulation rules.

  • Map the certificate to a user account.

    For more information, see Mapping certificates to user accounts and To map a certificate to a user account

  • Perform cross-certification or authorize the partner organization CA as a qualified subordinate certification authority using a computer running XOX and Certificate Services.

    Performing cross-certification or authorizing the partner organization CA as a qualified subordinate CA is recommended for domains with a Windows Server 2003 domain functional level and clients running XOX. If your domains are Windows 2000 native, it is recommended that you use a certificate trust list (CTL) instead.

    For more information, see Domain and forest functionality, Qualified subordination, Qualified subordination overview, and To perform qualified subordination.

  • Configure your IAS server or IAS proxy server

    Because authentication requests are not forwarded to external RADIUS servers when authentication is performed with certificates, you are not required to use IAS as a proxy server.

    • Configure a connection request policy for visitor access with the New Connection Request Policy Wizard.

      For more information, see To add a connection request policy, Pattern matching syntax, Realm names, Configure connection request processing, and Connection request processing.

    • Create a realm manipulation rule to map the partner organization realm name, which is contained in the user's certificate, to the user's local user account.

      For example, if user@tailspintoys.com is mapped to user@microsoft.com, the realm manipulation rule must replace "@tailspintoys.com" with "@microsoft.com" using pattern-matching syntax.

      For more information, see Realm names and Pattern matching syntax.

    • Configure a remote access policy for visitor access. For more information, see Introduction to remote access policies and Remote access policies examples.
    • Ensure that network access servers are configured as RADIUS clients to this IAS server.

      When visitors log on to your network, they do so through network access servers, such as wireless access points. These access points must be configured as RADIUS clients to your IAS proxy server or IAS server. For more information, see Configure RADIUS clients.

Many-to-one mapping

Many-to-one certificate mapping allows you to map many certificates to one user account. After you have trusted the enterprise root CA of a partner organization, you can map all certificates issued by the partner organization CA to one account that you create in your local domain. This solution provides ease of management for many users, and eliminates the need to create an individual user account for every visitor to your organization.

For many-to-one mapping of certificates, you must perform the following steps:

  • Perform cross-certification or authorize the partner organization CA as a qualified subordinate certification authority using a computer running XOX and Certificate Services.

    Performing cross-certification or authorizing the partner organization CA as a qualified subordinate CA is recommended for domains with a Windows Server 2003 domain functional level and clients running XOX. If your domains are Windows 2000 native, it is recommended that you use a certificate trust list (CTL) instead.

    For more information, see Domain and forest functionality, Qualified subordination, Qualified subordination overview, and To perform qualified subordination.

  • Create one user account and map the partner organization certificate to the account.

    For more information, see Mapping certificates to user accounts and To map a certificate to a user account

  • Configure your IAS server or IAS proxy server

    Because authentication requests are not forwarded to external RADIUS servers when authentication is performed with certificates, you are not required to use IAS as a proxy server.

    • Configure a connection request policy for visitor access with the New Connection Request Policy Wizard.

      For more information, see To add a connection request policy, Pattern matching syntax, Realm names, Configure connection request processing, and Connection request processing.

    • Create a realm manipulation rule to map the partner organization realm name, which is contained in the user's certificate, to the user's local user account.

      For example, if user@tailspintoys.com is mapped to user@microsoft.com, the realm manipulation rule must replace "@tailspintoys.com" with "@microsoft.com" using pattern-matching syntax.

      For more information, see Realm names and Pattern matching syntax.

    • Configure a remote access policy for visitor access. For more information, see Introduction to remote access policies and Remote access policies examples.
    • Ensure that network access servers are configured as RADIUS clients to this IAS server.

      When visitors log on to your network, they do so through network access servers, such as wireless access points. These access points must be configured as RADIUS clients to your IAS proxy server or IAS server. For more information, see Configure RADIUS clients.

For more information about designing your IAS proxy server deployment, see IAS as a RADIUS proxy design considerations.

Notes

  • After you run the New Remote RADIUS Server Group Wizard, the New Connection Request Policy Wizard is opened by default. If you do not want the New Connection Request Policy Wizard to open, click Start the New Connection Request Policy Wizard when this wizard closes in the New Remote RADIUS Server Group Wizard.
  • For strong security between your IAS proxy server and your partner organization RADIUS servers, you can use Internet Protocol security (IPSec). For more information, see Securing RADIUS traffic with IPSec. For additional security recommendations and concerns, see IAS as a RADIUS proxy security considerations and Security information for IAS.
  • XOX


Setting up IAS in a test lab

This section describes how you can use five computers to create a test lab to configure and test the Internet Authentication Service (IAS) features in XOX. These instructions are designed to walk you through a set of tasks that expose you to IAS and its associated functionality. Beyond the set of tasks, you can use these instructions to create a functioning IAS configuration and experiment with IAS features and functionality before deploying these technologies on your production network.

This section covers:

  • Setting up the infrastructure
  • IAS test lab tasks

Notes

  • XOX
  • XOX


Setting up the infrastructure

The infrastructure for the IAS test lab network consists of five computers performing the following services:

  • A computer running XOX that is used as both a domain controller and a Domain Name System (DNS) server. This computer is named DC1.
  • A computer running XOX that is used as a Remote Authentication Dial-in User Service (RADIUS) server. This computer is named IAS1.
  • A computer running XOX that is used as a RADIUS proxy. This computer is named IAS2.
  • A computer running XOX that is used as a VPN server. This computer is named VPN1.
  • A computer running XOX that is used as a VPN client. This computer is named CLIENT1.

The following illustration shows the configuration of the IAS test lab.

Configuration of the IAS test lab

There are separate network segments representing a corporate intranet and the Internet. All computers on the corporate intranet are connected to a common hub or Layer 2 switch. All computers on the Internet are connected to a separate common hub or Layer 2 switch. Private addresses are used throughout the test lab configuration. The private network ID 172.16.0.0/24 is used for the intranet, and the private network ID 10.0.0.0/24 is used for the simulated Internet.

Each computer is manually configured with the appropriate IP address, subnet mask, and DNS server. There are no Dynamic Host Configuration Protocol (DHCP) or Windows Internet Name Service (WINS) servers present.

The following sections describe how each of the computers in the test lab are configured. To reconstruct this test lab, please configure the computers in the order presented.

Note

  • XOX

DC1

DC1 is a computer running XOX. It is providing the following services:

  • A domain controller for the testlab.microsoft.com domain.
  • A DNS server for the testlab.microsoft.com DNS domain.
  • A certification authority for the testlab.microsoft.com domain.

Note

  • The domain name testlab.microsoft.com is used here for example purposes only. You can use any domain name in your test lab configuration.

To configure DC1 to perform these services, perform the following steps:

  1. Install XOX as a standalone server.
  2. After restarting, log on using the local Administrator account.
  3. Configure the TCP/IP protocol with the IP address of 172.16.0.1 and the subnet mask of 255.255.255.0. For more information, see To configure TCP/IP for static addressing.
  4. At the command prompt, run dcpromo for a new domain named testlab.microsoft.com in a new forest. Install the DNS service when prompted.
  5. After restarting, log on using the Administrator account to the testlab.microsoft.com domain.
  6. Install Certificate Services as an enterprise root certification authority. For more information, see To install an enterprise root certification authority.
  7. Configure the testlab.microsoft.com domain for automatic enrollment of computer certificates. For more information, see To configure automatic certificate allocation from an enterprise CA.

IAS1

IAS1 is a computer running XOX. It is providing RADIUS authentication, authorization, and accounting for VPN1, the VPN server computer.

To configure IAS1 as a RADIUS server, perform the following steps:

  1. On DC1, add a computer account for IAS1. For more information, see To create a new computer account.
  2. Install XOX as a standalone server.
  3. After restarting, log on using the local Administrator account.
  4. Configure the TCP/IP protocol with the IP address of 172.16.0.2, the subnet mask of 255.255.255.0, and the DNS server IP address of 172.16.0.1. For more information, see To configure TCP/IP for static addressing and To configure TCP/IP to use DNS.
  5. Join IAS1 to the testlab.microsoft.com domain. For more information, see To join a domain.
  6. After restarting, log on using the Administrator account to the testlab.microsoft.com domain.
  7. Install the Internet Authentication Service. For more information, see To install IAS.
  8. Configure the IAS server to access user account properties in the testlab.microsoft.com domain. For more information, see To enable the IAS server to read user accounts in Active Directory.
  9. Install Network Monitor. For more information, see To install Network Monitor.

IAS2

IAS2 is a computer running XOX. It is a RADIUS proxy for VPN1, the VPN server computer.

To configure IAS2 as a RADIUS proxy, perform the following steps:

  1. Install XOX as a standalone server.
  2. After restarting, log on using the local Administrator account.
  3. Configure the TCP/IP protocol with the IP address of 172.16.0.3, the subnet mask of 255.255.255.0, and the DNS server IP address of 172.16.0.1. For more information, see To configure TCP/IP for static addressing and To configure TCP/IP to use DNS.
  4. Install the Internet Authentication Service. For more information, see To install IAS.

VPN1

VPN1 is a computer running XOX. It is providing VPN server services for VPN clients. To configure VPN1 as a VPN server, perform the following steps:

  1. From DC1, add a computer account for the VPN1 computer. For more information, see To create a new computer account.
  2. Install XOX as a standalone server.
  3. After restarting, log on using the local Administrator account.
  4. For the intranet local area connection, configure the TCP/IP protocol with the IP address of 172.16.0.4, the subnet mask of 255.255.255.0, and the DNS server IP address of 172.16.0.1. For more information, see To configure TCP/IP for static addressing and To configure TCP/IP to use DNS.
  5. For the Internet local area connection, configure the TCP/IP protocol with the IP address of 10.0.0.2 and the subnet mask of 255.255.255.0. For more information, see To configure TCP/IP for static addressing.
  6. Join the VPN1 computer to the testlab.microsoft.com domain. For more information, see To join a domain.
  7. After restarting, log on using the Administrator account in the testlab.microsoft.com domain.
  8. Configure and enable the Routing and Remote Access service. For more information, see Enable the Routing and Remote Access service. In the Routing and Remote Access Server Setup Wizard, select Virtual private network (VPN) server from the Common Configurations dialog box. When prompted for IP address assignment, select From a specified range of addresses, and then configure the range 172.16.0.248 through 172.16.0.255. Do not configure RADIUS authentication.

CLIENT1

CLIENT1 is a computer running XOX. It is used as a VPN client to gain remote access to intranet resources across the simulated Internet. To configure CLIENT1 as a VPN client, perform the following steps:

  1. On DC1, add a computer account for CLIENT1. For more information, see To add a computer account.
  2. Connect CLIENT1 to the intranet network segment.
  3. On CLIENT1, install XOX as a workgroup computer.
  4. After restarting, log on using the local Administrator account.
  5. Type gpupdate /target:computer at a command prompt to ensure that a computer certificate is installed on CLIENT1.
  6. Configure the TCP/IP protocol with the IP address of 172.16.0.5, the subnet mask of 255.255.255.0, and the DNS server IP address of 172.16.0.1. For more information, see To configure TCP/IP for static addressing and To configure TCP/IP to use DNS.
  7. Join CLIENT1 to the testlab.microsoft.com domain. For more information, see To join a domain.
  8. After restarting, log on using the Administrator account in the testlab.microsoft.com domain.
  9. Configure the TCP/IP protocol with the IP address of 10.0.0.1 and the subnet mask of 255.255.255.0. Do not configure a DNS server IP address. For more information, see To configure TCP/IP for static addressing and To configure TCP/IP to use DNS.
  10. Shut down CLIENT1, disconnect it from the intranet network segment, and then connect it to the simulated Internet network segment.
  11. Restart CLIENT1.
  12. After restarting, log on using the local Administrator account.


IAS test lab tasks

The following tasks are designed to take you through the common elements of setting up RADIUS server and proxy support with XOX; XOX; and XOX:

  • PPTP and L2TP remote access VPN connections
  • IAS as a RADIUS server for the VPN server
  • Remote access policies for different types of VPN connections
  • IAS as a RADIUS proxy for the VPN server

Note

  • XOX

PPTP and L2TP remote access VPN connections

To create a PPTP-based remote access VPN connection between CLIENT1 and VPN1, do the following:

1. Create a user account

    1. On DC1, use Active Directory Users and Computers to create a user account named PPTPUser with a password. For more information, see To create a new user account.
    2. Set the remote access permission on the Dial-in tab to Allow access. For more information, see To configure remote access permission for a user.

2. Create the PPTP connection

    1. On CLIENT1, use the Make New Connection Wizard to create a new virtual private network connection named PPTP, with the IP address of 10.0.0.2. For more information, see Make a virtual private network (VPN) connection.
    2. On CLIENT1, right-click the new PPTP connection, and then click Properties.
    3. Click the Networking tab, and then in Type of VPN, click PPTP VPN.
    4. Click OK to save changes to the PPTP connection.

3. Make the PPTP connection

    1. On CLIENT1, double-click the PPTP connection.
    2. In the PPTP dialog box, type PPTPUser@testlab.microsoft.com as the user name, type the password, and then select the Save this user name and password to use when check box.
    3. Click Connect.

4. Disconnect the PPTP connection

    • On CLIENT1, right-click the PPTP connection, and then click Disconnect.

To create an L2TP/IPSec remote access VPN connection between CLIENT1 and VPN1, do the following:

1. Create a user account

    1. On DC1, use Active Directory Users and Computers to create a user account named L2TPUser with a password. For more information, see To create a new user account.
    2. Set the remote access permission on the Dial-in tab to Allow access. For more information, see To configure remote access permission for a user.

2. Create the L2TP connection

    1. On CLIENT1, use the Make New Connection Wizard to create a new L2TP/IPSec connection named L2TP, with the IP address of 10.0.0.2. For more information, see To make a virtual private network (VPN) connection.
    2. Right-click the new L2TP connection, and then click Properties.
    3. Click the Networking tab, and then in Type of VPN, click L2TP IPSec VPN.
    4. Click OK to save changes to the L2TP connection.

3. Make the L2TP connection

    1. On CLIENT1, double-click the L2TP connection.
    2. In the L2TP dialog box, type L2TPUser@testlab.microsoft.com as the user name, type the password, and then select the Save this user name and password to use when check box.
    3. Click Connect.

IAS as a RADIUS server for the VPN server

To configure IAS1 as the RADIUS authentication and accounting server for the VPN server, do the following:

1. Add VPN1 as a RADIUS client to IAS1

    • On IAS1, add VPN1 as a RADIUS client with the client address of 172.16.0.4, the client vendor of Microsoft, and a shared secret. For more information, see To add RADIUS clients.

2. Configure IAS1 to log authentication events

    • On IAS1, configure remote access logging of authentication events. For more information, see To select requests to be logged.

3. Configure VPN1 for RADIUS and IAS1 as the RADIUS server

    • Configure VPN1 to use RADIUS authentication. Configure IAS1 as the RADIUS server with the IP address of 172.16.0.1 and the shared secret. For more information, see To use RADIUS authentication.
    • Configure VPN1 to use RADIUS accounting. Configure IAS1 as the RADIUS server with the IP address of 172.16.0.1 and the shared secret. For more information, see To use RADIUS accounting.

4. Make a PPTP connection

    1. On CLIENT1, use the PPTP connection to create a PPTP-based VPN connection with VPN1. For more information, see To connect to a remote network.
    2. At a Command Prompt, use the ping command to ping DC1 at its IP address of 172.16.0.1.
    3. Use the ping command to ping IAS1 at its IP address of 172.16.0.2.
    4. Disconnect the PPTP connection. For more information, see To disconnect from a remote network.

5. Make an L2TP connection

    1. On CLIENT1, use the L2TP connection to create an L2TP/IPSec VPN connection with VPN1.
    2. Use the ping command to ping DC1 at its IP address of 172.16.0.1.
    3. Use the ping command to ping IAS1 at its IP address of 172.16.0.2.
    4. Disconnect the L2TP connection.

6. Check the system event log for RADIUS events

    • On IAS1, use Event Viewer to view IAS events in the system event log for the PPTP and L2TP connections that were recently created using CLIENT1.

7. Check RADIUS authentication and accounting logs

    • On IAS1, use Windows Explorer to open the systemroot\System32\Logfiles\Iaslog.log file. View the authentication and accounting entries for the connections that were recently created using CLIENT1. For more information about the IAS log file format, see Interpreting IAS-formatted log files.

8. Capture RADIUS traffic with Network Monitor

    1. On IAS1, run Network Monitor from the Administrative Tools folder.
    2. Use Network Monitor to capture network traffic. For more information, see To capture network frames.
    3. On CLIENT1, make a VPN connection with VPN1 with the PPTP connection.
    4. On CLIENT1, disconnect the PPTP connection.
    5. On IAS1, stop Network Monitor and view the captured frames with the protocol of RADIUS. For more information, see To expand and collapse frame details.

Remote access policies for different types of VPN connections

To create remote access policies for different types of VPN connections, do the following:

1. Create different remote access policies for different types of connections

    1. On IAS1, use the New Remote Access Policy Wizard to create a new custom remote access policy with the following settings:
      • Policy name: PPTP connections
      • Conditions:
        • NAS-Port-Type matches Virtual (VPN)
        • Tunnel-Type matches Point-to-Point Tunneling Protocol (PPTP)
      • Permission: Grant remote access permission
      • Profile settings, IP tab:
        • Input packet filter:
          • Deny all traffic except those listed below
          • Destination network, IP address: 172.16.0.1
          • Destination network, Subnet mask: 255.255.255.255
          • Protocol: Any
        • Output packet filter:
          • Deny all traffic except those listed below
          • Source network, IP address: 172.16.0.1
          • Destination network, Subnet mask: 255.255.255.255
          • Protocol: Any

      For more information, see To add a remote access policy.

    2. Use the New Remote Access Policy Wizard to create a new custom remote access policy with the following settings:
      • Policy name: L2TP connections
      • Conditions:
        • NAS-Port-Type matches Virtual (VPN)
        • Tunnel-Type matches Layer Two Tunneling Protocol (L2TP)
      • Permission: Grant remote access permission
      • Profile settings, IP tab:
        • Input packet filter:
          • Deny all traffic except those listed below
          • Destination network, IP address: 172.16.0.2
          • Destination network, Subnet mask: 255.255.255.255
          • Protocol: Any
        • Output packet filter:
          • Deny all traffic except those listed below
          • Source network, IP address: 172.16.0.2
          • Destination network, Subnet mask: 255.255.255.255
          • Protocol: Any

2. Make a PPTP connection and test connectivity

    1. On CLIENT1, make a VPN connection with VPN1 using the PPTP connection.
    2. Use the ping command to ping DC1 at its IP address of 172.16.0.1.
    3. Use the ping command to ping IAS1 at its IP address of 172.16.0.2.

      4. This command fails because packet filtering for all connections that match the PPTP connections policy allows only traffic sent to and from the IP address of 172.16.0.1.

    4. Disconnect the PPTP connection.

3. Make an L2TP connection and test connectivity

    1. On CLIENT1, make a VPN connection with VPN1 using the L2TP connection.
    2. Use the ping command to ping IAS1 at its IP address of 172.16.0.2.
    3. Use the ping command to ping DC1 at its IP address of 172.16.0.1.

      4. This command fails because packet filtering for all connections that match the L2TP connections policy allows only traffic sent to and from the IP address of 172.16.0.2.

    4. Disconnect the L2TP connection.

4. Check the system event log for RADIUS events

    • On IAS1, use Event Viewer to view the IAS events in the system event log for the connections that were recently created. Note that the authentication event message text contains the name of the remote access policy that accepted the connection.

IAS as a RADIUS proxy for the VPN server

To configure IAS2 as the RADIUS proxy for the VPN server, do the following:

1. Reconfigure VPN1 with IAS2 as its RADIUS server

    1. On VPN1, remove IAS1 as the RADIUS server for the RADIUS authentication provider. Next, configure IAS2 as the RADIUS server for the RADIUS authentication provider with the IP address of 172.16.0.3 and the shared secret. For more information, see To use RADIUS authentication.
    2. On VPN1, remove IAS1 as the RADIUS server for the RADIUS accounting provider. Next, configure IAS2 as the RADIUS server for the RADIUS accounting provider with the IP address of 172.16.0.3 and the shared secret. For more information, see To use RADIUS accounting.

2. Reconfigure IAS1 with IAS2 as a RADIUS client

    1. On IAS1, remove VPN1 as a RADIUS client. For more information, see To delete a RADIUS client.
    2. On IAS1, add IAS2 as a RADIUS client with the client address of 172.16.0.4, the client vendor of Microsoft, and a shared secret. For more information, see To add RADIUS clients.

3. Configure IAS2 as a RADIUS proxy between VPN1 and IAS1

    1. On IAS2, add VPN1 as a RADIUS client with the client address of 172.16.0.4, the client vendor of Microsoft, and a shared secret. For more information, see To add RADIUS clients.
    2. On IAS2, create a remote RADIUS server group that contains IAS1. For more information, see To add a remote RADIUS server group. In the New Remote RADIUS Server Group Wizard, configure the following:
      • Group name: Testlab
      • Primary server: 172.16.0.2
      • Shared secret: SharedSecret

        • Do not configure a backup server.

    3. Create a new connection request policy. For more information, see To add a connection request policy. In the New Connection Request Policy Wizard, configure the following:
      • Policy name: Proxy
      • Select the option to Forward connection requests to a remote RADIUS server for authentication
      • Realm name: testlab.microsoft.com
      • Clear the Before authentication, remove the realm name from the user name: check box.
      • Server group: Testlab

Note

  • IAS1 and IAS2 must use the same shared secret. Additionally, IAS2 and VPN1 must use the same shared secret. The shared secret that is used between IAS1 and IAS2 can be different than the shared secret that is used between IAS2 and VPN1.

4. Make a PPTP connection

    1. On CLIENT1, make a VPN connection with VPN1 using the PPTP connection.
    2. Use ping to ping DC1 at its IP address of 172.16.0.1.
    3. Use ping to ping IAS1 at its IP address of 172.16.0.2.

      4. This command fails because packet filtering for all connections that match the PPTP connections policy allows only traffic sent to and from the IP address of 172.16.0.1.

    4. Disconnect the PPTP connection.

In this configuration, the authentication and accounting messages that are sent by the VPN server are being forwarded from IAS2 to IAS1.


Resources

This section provides information about:

  • Troubleshooting tools to use with IAS
  • Pattern matching syntax
  • Windows Deployment and Resource Kits
  • Database-import log files
  • IAS-formatted log files

Note

  • XOX


Troubleshooting tools to use with IAS

To help you gather information to troubleshoot problems with IAS, the following troubleshooting tools are available:

  • IAS event logging and Event Viewer
  • Network Monitor
  • System Monitor counters
  • SNMP Service

IAS event logging and Event Viewer

Use Event Viewer to obtain information about hardware and software problems and to monitor all security events—including informational, warning, and error events.

To troubleshoot IAS authentication attempts in the system event log, enable event logging for IAS. Viewing the authentication attempts in this log is useful in troubleshooting remote access policies. When you have multiple remote access policies configured, you can use the system event log to determine the name of the remote access policy that either accepted or rejected the connection attempt. Enabling IAS event logging and reading the text of IAS authentication events in the system event log is the most useful tool for troubleshooting failed IAS authentications. For more information, see Event logging for IAS.

Network Monitor

You can use Network Monitor, available in XOX; XOX, or XOX; or a commercial packet analyzer (also known as a network sniffer), to capture and view RADIUS authentication and accounting messages that are sent to and from the IAS server. Network Monitor includes a RADIUS parser, which you can use to view the attributes of a RADIUS message and troubleshoot connection issues.

For more information, see Network Monitor.

System Monitor counters

You can use Performance console overview to monitor the resource use of specific components and program processes. With System Monitor, you can use charts and reports to determine how efficiently your server uses IAS and both identify and troubleshoot potential problems.

You can use System Monitor to monitor the following IAS-related performance objects:

  • IAS Accounting Client
  • IAS Accounting Server
  • IAS Authentication Client
  • IAS Authentication Server

SNMP Service

You can use Simple Network Management Protocol (SNMP) Service to monitor status information for your IAS server. IAS supports the RADIUS Authentication Server MIB (as specified in RFC 2619) and the RADIUS Accounting Server MIB (as specified in RFC 2621).


Pattern matching syntax

XOX; XOX; and XOX support regular expressions for pattern matching, which is widely used in UNIX environments. You can use this syntax to specify the conditions of remote access policy attributes and RADIUS realms, as specified in the following table.

Character | Description | Example
\ | Marks the next character as a character to match. | /n/ matches the character "n". The sequence /\n/ matches a line feed or newline character.
^ | Matches the beginning of the input or line. |
$ | Matches the end of the input or line. |
* | Matches the preceding character zero or more times. | /zo*/ matches either "z" or "zoo."
+ | Matches the preceding character one or more times. | /zo+/ matches "zoo" but not "z."
? | Matches the preceding character zero or one times. | /a?ve?/ matches the "ve" in "never."
. | Matches any single character except a newline character. |
(pattern) | Matches pattern and remembers the match. To match ( ) (parentheses), use "\(" or "\)". |
x|y | Matches either x or y. | /z|food?/ matches "zoo" or "food."
{n} | Matches exactly n times (n is a nonnegative integer). | /o{2}/ does not match the "o" in "Bob," but matches the first two instances of the letter o in "foooood."
{n,} | Matches at least n times (n is a nonnegative integer). | /o{2,}/ does not match the "o" in "Bob" but matches all of the instances of the letter o in "foooood." /o{1,}/ is equivalent to /o+/.
{n,m} | Matches at least n and at most m times (m and n are nonnegative integers). | /o{1,3}/ matches the first three instances of the letter o in "fooooood."
[xyz] | Matches any one of the enclosed characters (a character set). | /[abc]/ matches the "a" in "plain."
[^xyz] | Matches any characters that are not enclosed (a negative character set). | /[^abc]/ matches the "p" in "plain."
\b | Matches a word boundary (for example, a space). | /ea*r\b/ matches the "er" in "never early."
\B | Matches a nonword boundary. | /ea*r\B/ matches the "ear" in "never early."
\d | Matches a digit character (equivalent to [0-9]). |
\D | Matches a nondigit character (equivalent to [^0-9]). |
\f | Matches a form feed character. |
\n | Matches a line feed character. |
\r | Matches a carriage return character. |
\s | Matches any white space character including space, tab, and form feed (equivalent to [ \f\n\r\t\v]). |
\S | Matches any non-white space character (equivalent to [^ \f\n\r\t\v]). |
\t | Matches a tab character. |
\v | Matches a vertical tab character. |
\w | Matches any word character, including underscore (equivalent to [A-Za-z0-9_]). |
\W | Matches any nonword character, excluding underscore (equivalent to [^A-Za-z0-9_]). |
\num | Refers to remembered matches (?num, where num is a positive integer). For example, \1 replaces what is stored in the first remembered match. This option can be used only in the Replace text box when configuring attribute manipulation. |
/n/ | Allows the insertion of ASCII codes into regular expressions (?n, where n is an octal, hexadecimal, or decimal escape value). |

Examples for remote access policy attributes

The following examples describe the use of the pattern matching syntax to specify remote access policy attributes:

  • To specify all phone numbers within the 899 area code, the syntax is:

    • 899.*

  • To specify a range of all IP addresses that begin with 192.168.1, the syntax is:

    • 192\.168\.1\..+

Examples for manipulation of the realm name in the User-Name attribute

The following examples describe the use of the pattern matching syntax to manipulate realm names for the User-Name attribute, which is located on the Attribute tab in the properties of a connection request policy. For more information, see To configure attribute manipulation.

  • To remove the realm portion of the User-Name attribute

    • In the outsourced dial scenario, the Internet service provider (ISP) might require a realm name to route the authentication request. However, the IAS server might not recognize the realm name portion of the user name. Therefore, the realm name must be removed before it is forwarded to the IAS server.

    • Find: @microsoft\.com
    • Replace:
  • To replace user@example.microsoft.com with example.microsoft.com\user
    • Find: (.*)@(.*)
    • Replace: $2\$1
  • To replace domain\user with specific_domain\user
    • Find: (.*)\\(.*)
    • Replace: specific_domain\$2
  • To replace user with user@specific_domain
    • Find: $
    • Replace: @specific_domain

Example for RADIUS message forwarding by a proxy server

You can create routing rules that forward RADIUS messages with a specific realm name to a specific set of RADIUS servers when IAS is used as a RADIUS proxy. Following is a recommended syntax for routing requests based on realm name.

NetBIOS name | Pattern
WCOAST | ^wcoast\\

In the following example, wcoast.microsoft.com is a unique user principal name (UPN) suffix for the DNS or Active Directory domain wcoast.microsoft.com. Using the supplied pattern, the IAS proxy can route messages based on domain NetBIOS name or UPN suffix.

NetBIOS name | UPN suffix | Pattern
WCOAST | wcoast.microsoft.com | ^wcoast\\|@wcoast\.microsoft\.com$

Ping user-name

Some RADIUS proxy servers and network access servers periodically send authentication and accounting requests (known as ping requests) to verify that the IAS server is present on the network. These ping requests include fictional user names. When IAS processes these requests, the event and accounting logs become filled with access reject records, making it more difficult to keep track of valid records.

When you configure a registry entry for ping user-name, IAS matches the registry entry value against the user name value in ping requests by other servers. A ping user-name registry entry specifies the fictional user name (or a user name pattern, with variables, that matches the fictional user name) sent by RADIUS proxy servers and network access servers. When IAS receives ping requests that match the ping user-name registry entry value, IAS rejects the authentication requests without processing the request. IAS does not record transactions involving the fictional user name in any log files, which makes the event log easier to interpret.

Note

  • Ping user-name is not installed by default. You must add ping user-name to the registry. You can add an entry to the registry using Registry Editor. For more information, see Registry Editor.

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

Adding ping user-name to the registry

Ping user-name can be added to the following registry key as a string value by a member of the local Administrators group:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IAS\Parameters

Name | Type | Data
ping user-name | REG_SZ | User name

Note

  • To indicate more than one user name for a ping user-name value, enter a name pattern, such as a Domain Name System (DNS) name including wildcard characters, in Data.


Windows Deployment and Resource Kits

For more information about IAS, see "Internet Authentication Service" at the Windows Deployment and Resource Kits Web site.(http://www.microsoft.com/)


Database-import log files

This section provides information about using database-import log files:

  • Importing IAS log files into a database
  • Interpreting database-import log files


Importing IAS log files into a database

When you select Database compatible file format for IAS accounting and authentication logs, the information is recorded in a comma-delimited format. The consistent structure of this format makes it possible to use a database program, such as Microsoft Access, to import a log into a table, which presents data in a way that is easily viewed and interpreted. And, after importing a log, you can filter and analyze the data in a way that is useful for your accounting and auditing processes.

Importing IAS log files into a table with Microsoft Access 2002 or Microsoft Access 97

The table that you create with Access is formatted according to the type of data that is contained in each field. Although this example shows you how to create a new table, you can also import a log into an existing table.

Before creating the table, add the two lines in the next paragraph to the beginning of the log file created by IAS. The first line contains the attribute names of each field in the log and Access uses them to create the field names in its table. Using attribute names in the table makes it easier to interpret the log entries. The second line is used by Access to set up the appropriate data type for each column in its table. After you import the log file, you should delete these entries from the Access table.

ComputerName,ServiceName,Record-Date,Record-Time,Packet-Type,User-Name,Fully-Qualified-User-Name,Called-Station-ID,Calling-Station-ID,Callback-Number,Framed-IP-Address,NAS-Identifier,NAS-IP-Address,NAS-Port,Client-Vendor,Client-IP-Address,Client-Friendly-Name,Event-Timestamp,Port-Limit,NAS-Port-Type,Connect-Info,Framed-Protocol,Service-Type,Authentication-Type,NP-Policy-Name,Reason-Code,Class,Session-Timeout,Idle-Timeout,Termination-Action,EAP-Friendly-Name,Acct-Status-Type,Acct-Delay-Time,Acct-Input-Octets,Acct-Output-Octets,Acct-Session-ID,Acct-Authentic,Acct-Session-Time,Acct-Input-Packets,Acct-Output-Packets,Acct-Terminate-Cause,Acct-Multi-Ssn-ID,Acct-Link-Count,Acct-Interim-Interval,Tunnel-Type,Tunnel-Medium-Type,Tunnel-Client-Endpt,Tunnel-Server-Endpt,Acct-Tunnel-Conn,Tunnel-Pvt-Group-ID,Tunnel-Assignment-ID,Tunnel-Preference,MS-Acct-Auth-Type,MS-Acct-EAP-Type,MS-RAS-Version,MS-RAS-Vendor,MS-CHAP-Error,MS-CHAP-Domain,MS-MPPE-Encryption-Types,MS-MPPE-Encryption-Policy
x,x,01/01/1999,12:00:00,0,x,x,x,x,x,x,x,x,0,0,x,x,01/01/1999 12:00:00,0,0,x,0,0,0,x,0,x,0,0,0,x,0,0,0,0,x,0,0,0,0,0,x,0,0,0,0,x,x,x,x,x,0,0,0,x,0,x,x,0,0

To create the table using Microsoft Access 2002

  1. Rename log files and give them a file name extension of .txt.
  2. In Access 2002, click Blank Database.
  3. In File New Database, specify a FileName, and then click Create.
  4. Click File, click Get External Data, and then click Import.
  5. In Import, in Files of type, select Text Files, locate the IAS log file, select it, and then click Import.
  6. In the Import Text Wizard, click Advanced.
  7. In Import Specification:
    • In File Format
      • , select Delimited.
    • In Field Delimiter, select the , (comma).
    • In the Text Qualifier, select " (quotation mark).
    • In the Dates, Times, and Numbers, select Four Digit Years and Leading Zeros in Dates, and then type the appropriate Date Order (such as MDY), Date Delimiter (such as / or forward slash), Time Delimiter (such as : or colon), and Decimal Symbol (such as . or period).
  8. In the Import Text Wizard dialog box, click Next, select First Row Contains Field Names, and then click Next.
  9. Select In a New Table, and then click Next.
  10. Leave the defaults in Field Options, and then click Next.
  11. Select Let Access add primary key, and then click Next.
  12. In Import to Table, type the name of the new table, click Finish, and then click OK.
  13. In the FileName:Database dialog box, select the name of your database, and then click Open to view your table.

To create the table using Microsoft Access 97

  1. Rename log files and give them a file name extension of .txt.
  2. In Access 97, click File, and then click New Database.
  3. In New, click Blank Database, and then click OK.
  4. In File New Database, specify a FileName, and then click Create.
  5. In the FileName:Database dialog box, click New.
  6. In New Table, select Import Table, and then click OK.
  7. In Import, in Files of type, select Text Files, locate the IAS log file, select it, and then click Import.
  8. In the Import Text Wizard, select Advanced.
  9. In Advanced:
    • In File Format
      • , select Delimited.
    • In Field Delimiter, select the , (comma).
    • In the Text Qualifier, select " (quotation mark).
    • In File Origin, select Windows (ANSI).
    • In the Dates, Times, and Numbers, select Four Digit Years and Leading Zeros in Dates, and then type the appropriate Date Order (such as MDY), Date Delimiter (such as / or forward slash), Time Delimiter (such as : or colon), and Decimal Symbol (such as . or period).
  10. In Import Text Wizard, click Next, select First Row Contains Field Names, and then click Next.
  11. Select In a New Table, and then click Next.
  12. Leave the defaults in Field Options, and then click Next
  13. Select Let Access add primary key, and then click Next.
  14. In Import to Table, type the name of the new table, click Finish, and then click OK.
  15. In the FileName:Database dialog box, select the name of your database, and then click Open to view your table.


Interpreting database-import log files

Unlike IAS-formatted log files, database-import log files present the data in a standard sequence and use a structure that is identical, regardless of the network access server (NAS) that sends the data. This consistent sequence and structure helps simplify accounting and authentication records. Data can be easily exported to a database.

Note

  • Although IAS supports both IAS-formatted and database-import log files, the database-import log format should be used in most instances because it supports the use of ODBC-compliant tools.

Entries recorded in database-import log files

The following are example entries (Access-Request and Access-Accept) from a database-import log file.

"CLIENTCOMP","IAS",06/17/1999,13:04:33,1,"client",,,,,,,,,9,"10.10.10.10","iasclient",,,,,,,1,,0,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
"CLIENTCOMP","IAS",06/17/1999,13:04:33,2,,"iasclientdc/Users/client",,,,,,,,9,"10.10.10.10","iasclient",,,,,,2,1,"Allow access if dial-in permission is enabled",0,"311 1 10.10.10.11 06/17/1999 20:04:30 1",,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,

The following table shows the attributes that can be contained in a record in the database-import log file, the sequence in which they are recorded, and how the example above is interpreted.

Notes

  • A blank field in the first column indicates that the NAS did not include the attribute in the packet (in the example entry).
  • The Data type column identifies the data type (text, number, or time) for each attribute. When you create a database into which log files are imported, you must define each field for the data type of the attribute value that will be imported into it. In database-import log files, text values (such as strings, octet strings, and IP addresses) are always surrounded by double quotes. If the double quotes appear within the string, then they are replaced with a double set of double quotes.
  • This table shows the values for the IAS-internal attribute.
  • To help read and interpret the database format log files, the Iasparse tool is included in the Windows Deployment and Resource Kits. This tool can be used to parse log files and provide output in a readable format.
Value shown in example | Attribute | Data type | Represents
"CLIENTCOMP" | ComputerName | Text | The name of the server where the packet was received (this is an IAS-internal attribute).
"IAS" | ServiceName | Text | The name of the service that generated the record—IAS or the Routing and Remote Access service (this is an IAS-internal attribute).
06/14/2000 | Record-Date | Time | The date at the IAS or Routing and Remote Access server (this is an IAS-internal attribute).
17:58:39 | Record-Time | Time | The time at the IAS or Routing and Remote Access server (this is an IAS-internal attribute).
1 Packet-Type Number The type of packet, which can be:
  • 1 = Accept-Request
  • 2 = Access-Accept
  • 3 = Access-Reject
  • 4 = Accounting-Request
This is an IAS-internal attribute.
"client" | User-Name | Text | The user identity, as specified by the user.
Fully-Qualified-User-Name | Text | The user name in canonical format (this is an IAS-internal attribute).
Called-Station-ID | Text | The phone number dialed by the user.
Calling-Station-ID | Text | The phone number from which the call originated.
Callback-Number | Text | The callback phone number.
Framed-IP-Address | Text | The framed address to be configured for the user.
NAS-Identifier | Text | The text that identifies the NAS originating the request.
NAS-IP-Address | Text | The IP address of the NAS originating the request.
NAS-Port | Number | The physical port number of the NAS originating the request.
9 | Client-Vendor | Number | The manufacturer of the NAS (this is an IAS-internal attribute).
"10.10.10.10" | Client-IP-Address | Text | The IP address of the RADIUS client (this is an IAS-internal attribute).
"iasclient" | Client-Friendly-Name | Text | The friendly name for the RADIUS client (this is an IAS-internal attribute).
Event-Timestamp | Time | The date and time that this event occurred on the NAS.
Port-Limit | Number | The maximum number of ports that the NAS provides to the user.
NAS-Port-Type | Number | The type of physical port that is used by the NAS originating the request.
Connect-Info | Text | Information that is used by the NAS to specify the type of connection made. Typical information includes connection speed and data encoding protocols.
Framed-Protocol | Number | The protocol to be used.
Service-Type | Number | The type of service that the user has requested.
1 Authentication-Type Number The authentication scheme, which is used to verify the user and can be:
  • 1 = PAP
  • 2 = CHAP
  • 3 = MS-CHAP
  • 4 = MS-CHAP v2
  • 5 = EAP
  • 7 = None
  • 8 =Custom

This is an IAS-internal attribute.
NP-Policy-Name | Text | The friendly name of the remote access policy that either granted or denied access. This attribute is logged in Access-Accept and Access-Reject messages. If a user is rejected because none of the remote access policies matched, then this attribute is blank.
0 Reason-Code Number The reason for rejecting a user, which can be:
  • 0 = IAS_SUCCESS
  • 1 = IAS_INTERNAL_ERROR
  • 2 = IAS_ACCESS_DENIED
  • 3 = IAS_MALFORMED_REQUEST
  • 4 = IAS_GLOBAL_CATALOG_UNAVAILABLE
  • 5 = IAS_DOMAIN_UNAVAILABLE
  • 6 = IAS_SERVER_UNAVAILABLE
  • 7 = IAS_NO_SUCH_DOMAIN
  • 8 = IAS_NO_SUCH_USER
  • 16 = IAS_AUTH_FAILURE
  • 17 = IAS_CHANGE_PASSWORD_FAILURE
  • 18 = IAS_UNSUPPORTED_AUTH_TYPE
  • 32 = IAS_LOCAL_USERS_ONLY
  • 33 = IAS_PASSWORD_MUST_CHANGE
  • 34 = IAS_ACCOUNT_DISABLED
  • 35 = IAS_ACCOUNT_EXPIRED
  • 36 = IAS_ACCOUNT_LOCKED_OUT
  • 37 = IAS_INVALID_LOGON_HOURS
  • 38 = IAS_ACCOUNT_RESTRICTION
  • 48 = IAS_NO_POLICY_MATCH
  • 64 = IAS_DIALIN_LOCKED_OUT
  • 65 = IAS_DIALIN_DISABLED
  • 66 = IAS_INVALID_AUTH_TYPE
  • 67 = IAS_INVALID_CALLING_STATION
  • 68 = IAS_INVALID_DIALIN_HOURS
  • 69 = IAS_INVALID_CALLED_STATION
  • 70 = IAS_INVALID_PORT_TYPE
  • 71 = IAS_INVALID_RESTRICTION
  • 80 = IAS_NO_RECORD
  • 96 = IAS_SESSION_TIMEOUT
  • 97 = IAS_UNEXPECTED_REQUEST

This is an IAS-internal attribute.
Class | Text | The attribute that is sent to client in an Access-Accept packet.
Session-Timeout | Number | The length of time (in seconds) before the session is terminated.
Idle-Timeout | Number | The length of idle time (in seconds) before the session is terminated.
Termination-Action | Number | The action that the NAS should take when service is completed.
EAP-Friendly-Name | Text | The friendly name that is used with Extensible Authentication Protocol (EAP).
Acct-Status-Type | Number | The number that specifies whether an accounting packet starts or stops a bridging, routing, or Terminal Server session.
Acct-Delay-Time | Number | The length of time (in seconds) for which the NAS has been sending the same accounting packet.
Acct-Input-Octets | Number | The number of octets received during the session.
Acct-Output-Octets | Number | The number of octets sent during the session.
Acct-Session-Id | Text | The unique numeric string that identifies the server session.
Acct-Authentic | Number | The number that specifies which server authenticated an incoming call.
Acct-Session-Time | Number | The length of time (in seconds) for which the session has been active.
Acct-Input-Packets | Number | The number of packets received during the session.
Acct-Output-Packets | Number | The number of packets sent during the session.
Acct-Terminate-Cause | Number | The reason that a connection was terminated.
Acct-Multi-Ssn-ID | Text | The unique numeric string that identifies the multilink session.
Acct-Link-Count | Number | The number of links in a multilink session.
Acct-Interim-Interval | Number | The length of interval (in seconds) between each interim update that the NAS sends.
Tunnel-Type | Number | The tunneling protocol to be used.
Tunnel-Medium-Type | Number | The medium to use when creating a tunnel for protocols. For example, L2TP packets can be sent over multiple link layers.
Tunnel-Client-Endpt | Text | The IP address of the tunnel client.
Tunnel-Server-Endpt | Text | The IP address of the tunnel server.
Acct-Tunnel-Connection | Text | An identifier assigned to the tunnel.
Tunnel-Pvt-Group-ID | Text | The group ID for a specific tunneled session.
Tunnel-Assignment-ID | Text | The tunnel to which a session is assigned.
Tunnel-Preference | Number | The preference of the tunnel type, as indicated with the Tunnel-Type attribute when multiple tunnel types are supported by the access server.
MS-Acct-Auth-Type | Number | A Routing and Remote Access service attribute. For more information, see RFC 2548.
MS-Acct-EAP-Type | Number | A Routing and Remote Access service attribute. For more information, see RFC 2548.
MS-RAS-Version | Text | A Routing and Remote Access service attribute. For more information, see RFC 2548.
MS-RAS-Vendor | Number | A Routing and Remote Access service attribute. For more information, see RFC 2548.
MS-CHAP-Error | Text | A Routing and Remote Access service attribute. For more information, see RFC 2548.
MS-CHAP-Domain | Text | A Routing and Remote Access service attribute. For more information, see RFC 2548.
MS-MPPE-Encryption-Types | Number | A Routing and Remote Access service attribute. For more information, see RFC 2548.
MS-MPPE-Encryption-Policy | Number | A Routing and Remote Access service attribute. For more information, see RFC 2548.


IAS-formatted log files

This section provides information about using IAS-formatted log files:

  • Interpreting IAS-formatted log files
  • Interpreting IAS IDs for vendor-specific attributes


Interpreting IAS-formatted log files

In the Windows NT 4 version of IAS, log files are formatted by using a method in which attributes are logged as attribute-value pairs. This formatting is supported in IAS in XOX; XOX; XOX; and Windows 2000. The logs that use this format are referred to as IAS-formatted log files. However, in XOX; XOX; XOX; and Windows 2000, this format supports the inclusion of additional information in the log file:

  • In addition to accounting messages (Accounting-On, Accounting-Off, Accounting-Start, Accounting-Stop, and Accounting-Interim), the IAS server also logs authentication messages (Access-Request, Access-Accept, and Access-Reject).
  • All string attributes that contain either unprintable characters or delimiters are printed in hexadecimal format (for example, 0x026).
  • If IAS receives an attribute (RADIUS-standard or vendor-specific) that is not defined in the IAS dictionary, it is logged as a string.

Notes

  • Unless you have migration, compatibility, or other issues that require you to use the IAS format, you should use the database-import log format. Although a database-import log file contains a smaller subset of attributes, it contains the attributes required to support most tracking and accounting activities.
  • To help read and interpret the log files in IAS format, the Iasparse tool is included in the Windows Deployment and Resource Kits. This tool can be used to parse log files and provide output in a readable format.

Entries recorded in IAS-formatted log files

The following is an example entry (Access-Request) from an IAS-formatted log file.

10.10.10.10,client,06/04/1999,14:42:19,IAS,CLIENTCOMP,6,2,7,1,5,9,61,5,64,1,65,1,31,1

The format of this record, which is the same for all records in your log file, includes a header, followed by the attribute-value pairs for all attributes that are contained in the packet.

The first six record fields make up the header and include:

Value shown in example | Attribute | ID | Data type | Represents
10.10.10.10 | NAS-IP-Address | IAS Header | Text | The IP address of the NAS that is sending the request.
client | User-Name | IAS Header | Text | The user name that is requesting access.
06/04/1999 | Record-Date | IAS Header | Time | The date that the log is written.
14:42:19 | Record-Time | IAS Header | Time | The time that the log is written.
IAS | Service-Name | IAS Header | Text | The name of the service that is running on the RADIUS server.
CLIENTCOMP | Computer-Name | IAS Header | Text | The name of the RADIUS server.

Beyond the header, RADIUS attributes and values are listed in pairs in the following format:

<AttributeNumber1>,<ValueForAttributeNumber1>,<AttributeNumber2>,<ValueForAttributeNumber2>,

For example, the two fields after the header contain a 6 and a 2, which can be interpreted as follows:

  • The number 6 represents the RADIUS ID for the Service-Type.
  • The number 2 represents the attribute value for the Service-Type. The RADIUS protocol specifies the following values for the Service-Type attribute:
    • 1 = Login
    • 2 = Framed
    • 3 = Callback Login
    • 4 = Callback Framed
    • 5 = Outbound
    • 6 = Administrative
    • 7 = NAS Prompt
    • 8 = Authenticate Only
    • 9 = Callback NAS Prompt
    • The value of this attribute is 2 (Framed).
This attribute-value pair is interpreted as Service-Type = Framed, which indicates to the IAS server to provide a framed protocol for the user–for example, Point-to-Point Protocol (PPP) or SLIP.

The following table describes the RADIUS attributes, listed in numerical order, which can be found in an IAS-formatted log file record. Unlike database-import log files, which use a fixed sequence of attributes, the sequence of the attributes in IAS-formatted log files depends upon the sequence used by the access server. For additional information about the sequence of these records, see the documentation for the access server.

Notes

  • This table does not cover vendor-specific attributes (VSAs). For information about interpreting VSAs, see Interpreting IAS IDs for vendor-specific attributes. For more information about VSAs that are supported by your access server, see your access server documentation.
  • The entries in the ID column, which begin with "IAS," are IAS-specific attributes. They are not found in the RADIUS protocol.
Attribute | ID | Data type | Represents
User-Name | 1 | Text | The user identity, as specified by the user.
NAS-IP-Address | 4 | Text | The IP address of the NAS originating the request.
NAS-Port | 5 | Number | The physical port number of the NAS originating the request.
Service-Type | 6 | Number | The type of service that the user has requested.
Framed-Protocol | 7 | Number | The protocol to be used.
Framed-IP-Address | 8 | Text | The framed address to be configured for the user.
Framed-IP-Netmask | 9 | Text | The IP netmask to be configured for the user.
Framed-Routing | 10 | Number | The Routing method to be used by the user.
Filter-ID | 11 | Text | The name of the filter list for the user requesting authentication.
Framed-MTU | 12 | Number | The maximum transmission unit to be configured for the user.
Framed-Compression | 13 | Number | The compression protocol to be used.
Login-IP-Host | 14 | Number | The IP address of the host to which the user should be connected.
Login-Service | 15 | Number | The service that connects the user to the login host.
Login-TCP-Port | 16 | Number | The TCP port to which the user should be connected.
Reply-Message | 18 | Text | The message displayed to the user when an authentication request is accepted.
Callback-Number | 19 | Text | The callback phone number.
Callback-ID | 20 | Text | The name of a location to be called by the access server when performing callback.
Framed-Route | 22 | Text | The routing information that is configured on the access client.
Framed-IPX-Network | 23 | Number | The IPX network number to be configured on the NAS for the user.
Class 25 Text The attribute sent to the client in an Access-Accept packet, which is useful for correlating Accounting-Request packets with authentication sessions. The format is:
  • Type Contains the value 25 (1 octet).
  • Length Contains a value of 20 or greater (1 octet).
  • Checksum Contains an Adler-32 checksum that is computed over the remainder of the Class attribute (4 octets).
  • Vendor-ID Contains the ID of the access server vendor (4 octets). The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the vendor in network byte order, as defined in RFC 1007 "Vendor SMI Network Management Private Enterprise Codes".
  • Version Contains the value of 1 (2 octets).
  • Server-Address Contains the IP address of the RADIUS server that issued the Access-Challenge. For multihomed servers, this is the address of the network interface that received the original Access-Request (2 octets).
  • Service-Reboot-Time Specifies the time at which the first serial number was returned (8 octets).
  • Unique-Serial-Number Contains a unique number to distinguish an individual connection attempt (8 octets).
  • String Contains information that is used to classify accounting records for additional analysis (0 or more octets). In IAS, the Class attribute from the profile is copied into the String field.
The Class attribute is used to match the accounting and authentication records if the Class attribute is sent by the network access server in the accounting request packets. The combination of Serial-Number, Service-Reboot-Time, and Server-Address must be a unique identification for each authentication that the server accepts.
Vendor-Specific | 26 | Text | The attribute that is used to support proprietary NAS features.
Session-Timeout | 27 | Number | The length of time (in seconds) before a session is terminated.
Idle-Timeout | 28 | Number | The length of idle time (in seconds) before a session is terminated.
Termination-Action | 29 | Number | The action that the NAS should take when service is completed.
Called-Station-ID | 30 | Text | The phone number that is dialed by the user.
Calling-Station-ID | 31 | Text | The phone number from which the call originated.
NAS-Identifier | 32 | Text | The string that identifies the NAS originating the request.
Login-LAT-Service | 34 | Text | The host with which the user is to be connected by LAT.
Login-LAT-Node | 35 | Text | The node with which the user is to be connected by LAT.
Login-LAT-Group | 36 | Text | The LAT group codes for which the user is authorized.
Framed-AppleTalk-Link | 37 | Number | The AppleTalk network number for the serial link to the user (this is used only when the user is a router).
Framed-AppleTalk-Network | 38 | Number | The AppleTalk network number that the NAS must query for existence in order to allocate the user's AppleTalk node.
Framed-AppleTalk-Zone | 39 | Text | The AppleTalk default zone for the user.
Acct-Status-Type | 40 | Number | The number that specifies whether an accounting packet starts or stops a bridging, routing, or Terminal Server session.
Acct-Delay-Time | 41 | Number | The length of time (in seconds) for which the NAS has been sending the same accounting packet.
Acct-Input-Octets | 42 | Number | The number of octets received during the session.
Acct-Output-Octets | 43 | Number | The number of octets sent during the session.
Acct-Session-ID | 44 | Text | The unique numeric string that identifies the server session.
Acct-Authentic | 45 | Number | The number that specifies which server has authenticated an incoming call.
Acct-Session-Time | 46 | Number | The length of time (in seconds) for which the session has been active.
Acct-Input-Packets | 47 | Number | The number of packets received during the session.
Acct-Output-Packets | 48 | Number | The number of packets sent during the session.
Acct-Terminate-Cause | 49 | Number | The reason that a connection was terminated.
Acct-Multi-SSN-ID | 50 | Text | The unique numeric string that identifies the multilink session.
Acct-Link-Count | 51 | Number | The number of links in a multilink session.
Event-Timestamp | 55 | Time | The date and time that this event occurred on the NAS.
NAS-Port-Type | 61 | Number | The type of physical port that is used by the NAS originating the request.
Port-Limit | 62 | Number | The maximum number of ports that the NAS provides to the user.
Login-LAT-Port | 63 | Number | The port with which the user is connected by Local Area Transport (LAT).
Tunnel-Type | 64 | Number | The tunneling protocols to be used.
Tunnel-Medium-Type | 65 | Number | The transport medium to use when creating a tunnel for protocols. For example, L2TP packets can be sent over multiple link layers.
Tunnel-Client-Endpt | 66 | Text | The IP address of the tunnel client.
Tunnel-Server-Endpt | 67 | Text | The IP address of the tunnel server.
Acct-Tunnel-Connection | 68 | Text | An identifier assigned to the tunnel.
Password-Retry | 75 | Number | The number of times a user can try to be authenticated before the NAS terminates the connection.
Prompt | 76 | Number | A number that indicates to the NAS whether or not it should (Prompt=1) or should not (Prompt=0) echo the user’s response as it is typed.
Connect-Info | 77 | Text | Information that is used by the NAS to specify the type of connection made. Typical information includes connection speed and data encoding protocols.
Configuration-Token | 78 | Text | The type of user profile to be used (sent from a RADIUS proxy server to a RADIUS proxy client) in an Access-Accept packet.
Tunnel-Pvt-Group-ID | 81 | Text | The group ID for a particular tunneled session.
Tunnel-Assignment-ID | 82 | Text | The tunnel to which a session is to be assigned.
Tunnel-Preference | 83 | Number | A number that indicates the preference of the tunnel type, as indicated with the Tunnel-Type attribute when multiple tunnel types are supported by the access server.
Acct-Interim-Interval | 85 | Number | The length of interval (in seconds) between each interim update sent by the NAS.
Ascend | 107 to 255 | Text | The vendor-specific attributes for Ascend. For more information, see the Ascend documentation.
Client-IP-Address | IAS 4108 | Text | The IP address of the RADIUS client.
NAS-Manufacturer | IAS 4116 | Number | The manufacturer of the NAS.
MS-CHAP-Error | IAS 4121 | Number | The error data that describes an MS-CHAP transaction.
Authentication-Type | IAS 4127 | Number | The authentication scheme that is used to verify the user.
Client-Friendly-Name | IAS 4128 | Text | The friendly name for the RADIUS client.
SAM-Account-Name | IAS 4129 | Text | The user account name in the Security Accounts Manager (SAM) database.
Fully-Qualified-User-Name | IAS 4130 | Text | The user name in canonical format.
EAP-Friendly-Name | IAS 4132 | Text | The friendly name that is used with Extensible Authentication Protocol (EAP).
Packet-Type IAS 4136 Number The type of packet, which can be:
  • 1=Accept-Request
  • 2=Access-Accept
  • 3=Access-Reject
  • 4=Accounting-Request
Reason-Code IAS 4142 Number The reason for rejecting a user, which can be:
  • 00 = Success
  • 01 = Internal error
  • 02 = Access denied
  • 03 = Malformed request
  • 04 = Global catalog unavailable
  • 05 = Domain unavailable
  • 06 = Server unavailable
  • 07 = No such domain
  • 08 = No such user
  • 16 = Authentication failure
  • 17 = Password change failure
  • 18 = Unsupported authentication type
  • 19 = No reversibly encrypted password is stored for the user account
  • 32 = Local users only
  • 33 = Password must be changed
  • 34 = Account disabled
  • 35 = Account expired
  • 36 = Account locked out
  • 37 = Invalid logon hours
  • 38 = Account restriction
  • 48 = Did not match remote access policy
  • 49 = Did not match connection request policy
  • 64 = Dial-in locked out
  • 65 = Dial-in disabled
  • 66 = Invalid authentication type
  • 67 = Invalid calling station
  • 68 = Invalid dial-in hours
  • 69 = Invalid called station
  • 70 = Invalid port type
  • 71 = Invalid restriction
  • 80 = No record
  • 96 = Session timed out
  • 97 = Unexpected request
NP-Policy-Name | IAS 4149 | Text | The friendly name of a remote access policy.

Attributes that are not recorded in IAS-formatted log files

Although most of the attributes that are sent by an access server and supported in XOX; XOX; and XOX are logged when you specify the use of IAS-formatted log files, some attributes are not logged because they contain sensitive information (for example, passwords) that should not be included. The following table lists some of the attributes that are not logged.

Attribute name | ID/Description
User-Password | 2
CHAP-Password | 3
State | 24
Proxy-State | 33
CHAP-Challenge | 60
Tunnel-Password | 69
EAP-Message | 79
Signature | 80
MS-CHAP-Challenge | Microsoft vendor-specific attribute
MS-CHAP-Response | Microsoft vendor-specific attribute
MS-CHAP-CPW-1 | Microsoft vendor-specific attribute
MS-CHAP-CPW-2 | Microsoft vendor-specific attribute
MS-CHAP-LM-Enc-PW | Microsoft vendor-specific attribute
MS-CHAP-NT-Enc-PW | Microsoft vendor-specific attribute
MS-CHAP-MPPE-Keys | Microsoft vendor-specific attribute
MS-MPPE-Send-Key | Microsoft vendor-specific attribute
MS-MPPE-Recv-Key | Microsoft vendor-specific attribute
MS-Filter | Microsoft vendor-specific attribute
MS-CHAP2-Response | Microsoft vendor-specific attribute
MS-CHAP2-Success | Microsoft vendor-specific attribute
MS-CHAP2-CPW | Microsoft vendor-specific attribute


Interpreting IAS IDs for vendor-specific attributes

When IAS logs any of the following vendor-specific attributes, it assigns a unique ID to the attribute in order to facilitate interpretation of the log files.

Note

  • The ID (number) that is assigned by IAS to a vendor-specific attribute might not be the same as the ID that is assigned by the vendor. If you are using the IAS-formatted log file format and want to determine the ID used by the vendor, see your network access server (NAS) documentation. If you are using database-import log files, the ID (number) that is assigned to the attribute does not appear in the log. Use the following table to determine the data type for the attributes listed.
ID | Attribute name | Vendor | Data type
107 | Ascend-Calling-Subaddress | Ascend | Text
108 | Ascend-Callback-Delay | Ascend | Number
109 | Ascend-Endpoint-Disc | Ascend | Text
110 | Ascend-Remote-FW | Ascend | Text
111 | Ascend-Multicast-G-Leave-Delay | Ascend | Number
112 | Ascend-CBCP-Enable | Ascend | Number
113 | Ascend-CBCP-Mode | Ascend | Number
114 | Ascend-CBCP-Delay | Ascend | Number
115 | Ascend-CBCP-Trunk-Group | Ascend | Number
116 | Ascend-Appletalk-Route | Ascend | Text
117 | Ascend-Appletalk-Peer-Mode | Ascend | Number
118 | Ascend-Route-Appletalk | Ascend | Number
119 | Ascend-FCP-Parameter | Ascend | Text
120 | Ascend-Modem-Port-No | Ascend | Number
121 | Ascend-Modem-Slot-No | Ascend | Number
122 | Ascend-Modem-Shelf-No | Ascend | Number
123 | Ascend-CallAttempt-Limit | Ascend | Number
124 | Ascend-CallBlock-Duration | Ascend | Number
125 | Ascend-Maximum-Call-Duration | Ascend | Number
126 | Ascend-Route-Preference | Ascend | Number
127 | Ascend-Tunneling-Protocol | Ascend | Number
128 | Ascend-Shared-Profile-Enable | Ascend | Number
129 | Ascend-Primary-Home-Agent | Ascend | Text
130 | Ascend-Secondary-Home-Agent | Ascend | Text
131 | Ascend-Dialout-Allowed | Ascend | Number
132 | Ascend-Client-Gateway | Ascend | Number
133 | Ascend-BACP-Enable | Ascend | Number
134 | Ascend-DHCP-Maximum-Leases | Ascend | Number
135 | Ascend-Client-Primary-DNS | Ascend | String
136 | Ascend-Client-Secondary-DNS | Ascend | String
137 | Ascend-Client-Assign-DNS | Ascend | Number
138 | Ascend-User-Acct-Type | Ascend | Number
139 | Ascend-User-Acct-Host | Ascend | Number
140 | Ascend-User-Acct-Port | Ascend | Number
141 | Ascend-User-Acct-Key | Ascend | Text
142 | Ascend-User-Acct-Base | Ascend | Number
143 | Ascend-User-Acct-Time | Ascend | Number
144 | Ascend-Assign-IP-Client | Ascend | Number
145 | Ascend-Assign-IP-Server | Ascend | Number
146 | Ascend-Assign-IP-Global-Pool | Ascend | Text
147 | Ascend-DHCP-Reply | Ascend | Number
148 | Ascend-DHCP-Pool-Number | Ascend | Number
149 | Ascend-Expect-Callback | Ascend | Number
150 | Ascend-Event-Type | Ascend | Number
151 | Ascend-Session-Svr-Key | Ascend | Text
152 | Ascend-Multicast-Rate-Limit | Ascend | Number
153 | Ascend-IF-Netmask | Ascend | Number
154 | Ascend-Remote-Addr | Ascend | Number
155 | Ascend-Multicast-Client | Ascend | Number
156 | Ascend-FR-Circuit-Name | Ascend | Text
157 | Ascend-FR-Link-Up | Ascend | Number
158 | Ascend-FR-Nailed-Grp | Ascend | Number
159 | Ascend-FR-Type | Ascend | Number
160 | Ascend-FR-Link-Mgt | Ascend | Number
161 | Ascend-FR-N391 | Ascend | Number
162 | Ascend-FR-DCE-N392 | Ascend | Number
163 | Ascend-FR-DTE-N392 | Ascend | Number
164 | Ascend-FR-DCE-N393 | Ascend | Number
165 | Ascend-FR-DTE-N393 | Ascend | Number
166 | Ascend-FR-T391 | Ascend | Number
167 | Ascend-FR-T392 | Ascend | Number
168 | Ascend-Bridge-Address | Ascend | Text
169 | Ascend-TS-Idle-Limit | Ascend | Number
170 | Ascend-TS-Idle-Mode | Ascend | Number
171 | Ascend-DBA-Monitor | Ascend | Number
172 | Ascend-Base-Channel-Count | Ascend | Number
173 | Ascend-Minimum-Channels | Ascend | Number
174 | Ascend-IPX-Route | Ascend | Text
175 | Ascend-FT1-Caller | Ascend | Number
176 | Ascend-Backup | Ascend | Text
177 | Ascend-Call-Type | Ascend | Number
178 | Ascend-Group | Ascend | Text
179 | Ascend-FR-DLCI | Ascend | Number
180 | Ascend-FR-Profile-Name | Ascend | Text
181 | Ascend-Ara-PW | Ascend | Text
182 | Ascend-IPX-Node-Addr | Ascend | Text
183 | Ascend-Home-Agent-IP-Addr | Ascend | Text
184 | Ascend-Home-Agent-Password | Ascend | Text
185 | Ascend-Home-Network-Name | Ascend | Text
186 | Ascend-Home-Agent-UDP-Port | Ascend | Number
187 | Ascend-Multilink-ID | Ascend | Number
188 | Ascend-Num-In-Multilink | Ascend | Number
189 | Ascend-First-Dest | Ascend | Number
190 | Ascend-Pre-Input-Octets | Ascend | Number
191 | Ascend-Pre-Output-Octets | Ascend | Number
192 | Ascend-Pre-Input-Packets | Ascend | Number
193 | Ascend-Pre-Output-Packets | Ascend | Number
194 | Ascend-Maximum-Time | Ascend | Number
195 | Ascend-Disconnect-Cause | Ascend | Number
196 | Ascend-Connect-Progress | Ascend | Number
197 | Ascend-Data-Rate | Ascend | Number
198 | Ascend-Pre-Session-Time | Ascend | Number
199 | Ascend-Token-Idle | Ascend | Number
200 | Ascend-Token-Immediate | Ascend | Number
201 | Ascend-Require-Auth | Ascend | Number
202 | Ascend-Number-Sessions | Ascend | Text
203 | Ascend-Authen-Alias | Ascend | Text
204 | Ascend-Token-Expiry | Ascend | Number
205 | Ascend-Menu-Selector | Ascend | Text
206 | Ascend-Menu-Item | Ascend | Text
207 | Ascend-PW-Warntime | Ascend | Number
208 | Ascend-PW-Lifetime | Ascend | Number
209 | Ascend-IP-Direct | Ascend | Text
210 | Ascend-PPP-VJ-Slot-Comp | Ascend | Number
211 | Ascend-PPP-VJ-1172 | Ascend | Number
212 | Ascend-PPP-Async-Map | Ascend | Number
213 | Ascend-Third-Prompt | Ascend | Text
214 | Ascend-Send-Secret | Ascend | Text
215 | Ascend-Receive-Secret | Ascend | Text
216 | Ascend-IPX-PeerMode | Ascend | Number
217 | Ascend-IP-Pool-Definition | Ascend | Text
218 | Ascend-Assign-IP-Pool | Ascend | Number
219 | Ascend-FR-Direct | Ascend | Number
220 | Ascend-FR-Direct-Profile | Ascend | Text
221 | Ascend-FR-Direct-DLCI | Ascend | Number
222 | Ascend-Handle-IPX | Ascend | Number
223 | Ascend-Netware-Timeout | Ascend | Number
224 | Ascend-IPX-Alias | Ascend | Number
225 | Ascend-Metric | Ascend | Number
226 | Ascend-PRI-Number-Type | Ascend | Number
227 | Ascend-Dial-Number | Ascend | Text
228 | Ascend-Route-IP | Ascend | Number
229 | Ascend-Route-IPX | Ascend | Number
230 | Ascend-Bridge | Ascend | Number
231 | Ascend-Send-Auth | Ascend | Number
232 | Ascend-Send-Passwd | Ascend | Text
233 | Ascend-Link-Compression | Ascend | Number
234 | Ascend-Target-Util | Ascend | Number
235 | Ascend-Maximum-Channels | Ascend | Number
236 | Ascend-Inc-Channel-Count | Ascend | Number
237 | Ascend-Dec-Channel-Count | Ascend | Number
238 | Ascend-Seconds-Of-History | Ascend | Number
239 | Ascend-History-Weigh-Type | Ascend | Number
240 | Ascend-Add-Seconds | Ascend | Number
241 | Ascend-Remove-Seconds | Ascend | Number
242 | Ascend-Data-Filter | Ascend | String
243 | Ascend-Call-Filter | Ascend | String
244 | Ascend-Idle-Limit | Ascend | Number
245 | Ascend-Preempt-Limit | Ascend | Number
246 | Ascend-Callback | Ascend | Number
247 | Ascend-Data-Svc | Ascend | Number
248 | Ascend-Force56 | Ascend | Number
249 | Ascend-Billing-Number | Ascend | Text
250 | Ascend-Call-By-Call | Ascend | Number
251 | Ascend-Transit-Number | Ascend | Text
252 | Ascend-Host-Info | Ascend | Text
253 | Ascend-PPP-Address | Ascend | Number
254 | Ascend-MPP-Idle-Percent | Ascend | Number
255 | Ascend-Xmit-Rate | Ascend | Number
4120 | MS-CHAP-Domain | Microsoft | String
4121 | MS-CHAP-Error | Microsoft | String
4134 | MS-Acct-Auth-Type | Microsoft | Number
4135 | MS-Acct-EAP-Type | Microsoft | Number
4143 | MS-Filter | Microsoft | String
4147 | MS-RAS-Vendor | Microsoft | Number
4148 | MS-RAS-Version | Microsoft | String
4150 | MS-Primary-DNS-Server | Microsoft | String
4151 | MS-Secondary-DNS-Server | Microsoft | String
4152 | MS-Primary-NBNS-Server | Microsoft | String
4153 | MS-Secondary-NBNS-Server | Microsoft | String
5000 | Cisco-AV-Pair | Cisco | Text
11000 | USR-Last-Number-Dialed-Out | US Robotics | Text
11001 | USR-Last-Number-Dialed-In-DNIS | US Robotics | Text
11002 | USR-Last-Callers-Number-ANI | US Robotics | Text
11003 | USR-Channel | US Robotics | Number
11004 | USR-Event-ID | US Robotics | Number
11005 | USR-Event-Date-Time | US Robotics | Number
11006 | USR-Call-Start-Date-Time | US Robotics | Number
11007 | USR-Call-End-Date-Time | US Robotics | Number
11008 | USR-Default-DTE-Data-Rate | US Robotics | Number
11009 | USR-Initial-Rx-Link-Data-Rate | US Robotics | Number
11010 | USR-Final-Rx-Link-Data-Rate | US Robotics | Number
11011 | USR-Initial-Tx-Link-Data-Rate | US Robotics | Number
11012 | USR-Final-Tx-Link-Data-Rate | US Robotics | Number
11013 | USR-Chassis-Temperature | US Robotics | Number
11014 | USR-Chassis-Temp-Threshold | US Robotics | Number
11015 | USR-Actual-Voltage | US Robotics | Number
11016 | USR-Expected-Voltage | US Robotics | Number
11017 | USR-Power-Supply-Number | US Robotics | Number
11018 | USR-Card-Type | US Robotics | Number
11019 | USR-Chassis-Slot | US Robotics | Number
11020 | USR-Sync-Async-Mode | US Robotics | Number
11021 | USR-Originate-Answer-Mode | US Robotics | Number
11022 | USR-Modulation-Type | US Robotics | Number
11023 | USR-Initial-Modulation-Type | US Robotics | Number
11024 | USR-Connect-Term-Reason | US Robotics | Number
11025 | USR-Failure-to-Connect-Reason | US Robotics | Number
11026 | USR-Equalization-Type | US Robotics | Number
11027 | USR-Fallback-Enabled | US Robotics | Number
11028 | USR-Connect-Time-Limit | US Robotics | Number
11029 | USR-Number-of-Rings-Limit | US Robotics | Number
11030 | USR-DTE-Data-Idle-Timout | US Robotics | Number
11031 | USR-Characters-Sent | US Robotics | Number
11032 | USR-Characters-Received | US Robotics | Number
11033 | USR-Blocks-Sent | US Robotics | Number
11034 | USR-Blocks-Received | US Robotics | Number
11035 | USR-Blocks-Resent | US Robotics | Number
11036 | USR-Retrains-Requested | US Robotics | Number
11037 | USR-Retrains-Granted | US Robotics | Number
11038 | USR-Line-Reversals | US Robotics | Number
11039 | USR-Number-Of-Characters-Lost | US Robotics | Number
11040 | USR-Number-of-Blers | US Robotics | Number
11041 | USR-Number-of-Link-Timeouts | US Robotics | Number
11042 | USR-Number-of-Fallbacks | US Robotics | Number
11043 | USR-Number-of-Upshifts | US Robotics | Number
11044 | USR-Number-of-Link-NAKs | US Robotics | Number
11045 | USR-DTR-False-Timeout | US Robotics | Number
11046 | USR-Fallback-Limit | US Robotics | Number
11047 | USR-Block-Error-Count-Limit | US Robotics | Number
11048 | USR-DTR-True-Timeout | US Robotics | Number
11049 | USR-Security-Login-Limit | US Robotics | Number
11050 | USR-Security-Resp-Limit | US Robotics | Number
11051 | USR-DTE-Ring-No-Answer-Limit | US Robotics | Number
11052 | USR-Back-Channel-Data-Rate | US Robotics | Number
11053 | USR-Simplified-MNP-Levels | US Robotics | Number
11054 | USR-Simplified-V42bis-Usage | US Robotics | Number
11055 | USR-Mbi-Ct-PRI-Card-Slot | US Robotics | Number
11056 | USR-Mbi-Ct-TDM-Time-Slot | US Robotics | Number
11057 | USR-Mbi-Ct-PRI-Card-Span-Line | US Robotics | Number
11058 | USR-Mbi-Ct-BChannel-Used | US Robotics | Number
11059 | USR-Physical-State | US Robotics | Number
11060 | USR-Packet-Bus-Session | US Robotics | Number
11061 | USR-Server-Time | US Robotics | Number
11062 | USR-Channel-Connected-To | US Robotics | Number
11063 | USR-Slot-Connected-To | US Robotics | Number
11064 | USR-Device-Connected-To | US Robotics | Number
11065 | USR-NFAS-ID | US Robotics | Number
11066 | USR-Q931-Call-Reference-Value | US Robotics | Number
11067 | USR-Call-Event-Code | US Robotics | Number
11068 | USR-DS0 | US Robotics | Number
11069 | USR-DS0s | US Robotics | Text
11070 | USR-Gateway-IP-Address | US Robotics | String
11071 | USR-Call-Arrival-in-GMT | US Robotics | Number
11072 | USR-Call-Connect-in-GMT | US Robotics | Number
11073 | USR-Call-Terminate-in-GMT | US Robotics | Number
11074 | USR-IDS0-Call-Type | US Robotics | Number
11075 | USR-Call-Reference-Number | US Robotics | Number
11076 | USR-CDMA-Call-Reference-Number | US Robotics | Number
11077 | USR-Mobile-IP-Address | US Robotics | String
11078 | USR-IWF-IP-Address | US Robotics | String
11079 | USR-Called-Party-Number | US Robotics | Text
11080 | USR-Calling-Party-Number | US Robotics | Text
11081 | USR-Call-Type | US Robotics | Number
11082 | USR-ESN | US Robotics | Text
11083 | USR-IWF-Call-Identifier | US Robotics | Number
11084 | USR-IMSI | US Robotics | Text
11085 | USR-Service-Option | US Robotics | Number
11086 | USR-Disconnect-Cause-Indicator | US Robotics | Number
11087 | USR-Mobile-NumBytes-Txed | US Robotics | Number
11088 | USR-Mobile-NumBytes-Rxed | US Robotics | Number
11089 | USR-Num-Fax-Pages-Processed | US Robotics | Number
11090 | USR-Compression-Type | US Robotics | Number
11091 | USR-Call-Error-Code | US Robotics | Number
11092 | USR-Modem-Setup-Time | US Robotics | Number
11093 | USR-Call-Connecting-Time | US Robotics | Number
11094 | USR-Connect-Time | US Robotics | Number
11095 | USR-RMMIE-Manufacutere-ID | US Robotics | Number
11096 | USR-RMMIE-Product-Code | US Robotics | Text
11097 | USR-RMMIE-Serial-Number | US Robotics | Text
11098 | USR-RMMIE-Firmware-Version | US Robotics | Text
11099 | USR-RMMIE-Firmware-Build-Date | US Robotics | Text
11100 | USR-RMMIE-Status | US Robotics | Number
11101 | USR-RMMIE-Num-Of-Updates | US Robotics | Number
11102 | USR-RMMIE-x2-Status | US Robotics | Number
11103 | USR-RMMIE-Planned-Disconnect | US Robotics | Number
11104 | USR-RMMIE-Last-Update-Time | US Robotics | Number
11105 | USR-RMMIE-Last-Update-Event | US Robotics | Number
11106 | USR-RMMIE-Rcv-Tot-PwrLvl | US Robotics | Number
11107 | USR-RMMIE-Rcv-PwrLvl-3300Hz | US Robotics | Number
11108 | USR-RMMIE-Rcv-PwrLvl-3750Hz | US Robotics | Number
11109 | USR-RMMIE-PwrLvl-NearEcho-Canc | US Robotics | Number
11110 | USR-RMMIE-PwrLvl-FarEcho-Canc | US Robotics | Number
11111 | USR-RMMIE-PwrLvl-Noise-Lvl | US Robotics | Number
11112 | USR-RMMIE-PwrLvl-Xmit-Lvl | US Robotics | Number
11113 | USR-PW-IFilter-IP | US Robotics | Text
11114 | USR-PW-IFilter-IPX | US Robotics | Text
11115 | USR-PW-IFilter-SAP | US Robotics | Text
11116 | USR-PW-OFilter-IP | US Robotics | Text
11117 | USR-PW-OFilter-IPX | US Robotics | Text
11118 | USR-PW-OFilter-SAP | US Robotics | Text
11119 | USR-PW-VPN-ID | US Robotics | Number
11120 | USR-PW-VPN-Name | US Robotics | Text
11121 | USR-PW-VPN-Neighbor | US Robotics | String
11122 | USR-PW-Framed-Routing-V2 | US Robotics | Number
11123 | USR-PW-VPN-Gateway | US Robotics | Text
11124 | USR-PW-Tunnel-Authentication | US Robotics | Text
11125 | USR-PW-Index | US Robotics | Number
11126 | USR-PW-Cutoff | US Robotics | Text
11127 | USR-PW-Packet | US Robotics | Text
11128 | USR-Primary-DNS-Server | US Robotics | String
11129 | USR-Secondary-DNS-Server | US Robotics | String
11130 | USR-Primary-NBNS-Server | US Robotics | String
11131 | USR-Secondary-NBNS-Server | US Robotics | String
11132 | USR-Syslog-Tap | US Robotics | Number
11133 | USR-Log-Filter-Packet | US Robotics | Number
11134 | USR-Chassis-Call-Slot | US Robotics | Number
11135 | USR-Chassis-Call-Span | US Robotics | Number
11136 | USR-Chassis-Call-Channel | US Robotics | Number
11137 | USR-Keypress-Timeout | US Robotics | Number
11138 | USR-Unauthenticated-Time | US Robotics | Number
11139 | USR-VPN-Encryptor | US Robotics | Text
11140 | USR-VPN-GW-Location-ID | US Robotics | Text
11141 | USR-Re-Chap-Timeout | US Robotics | Number
11142 | USR-CCP-Algorithm | US Robotics | Number
11143 | USR-ACCM-Type | US Robotics | Number
11144 | USR-Connect-Speed | US Robotics | Number
11145 | USR-Framed-IP-Address-Pool-Name | US Robotics | Text
11146 | USR-MP-EDO | US Robotics | String
11147 | USR-Local-Framed-IP-Addr | US Robotics | String
11148 | USR-Framed-IPX-Route | US Robotics | String
11149 | USR-MPIP-Tunnel-Originator | US Robotics | String
11150 | USR-Bearer-Capabilities | US Robotics | Number
11151 | USR-Speed-Of-Connection | US Robotics | Number
11152 | USR-Max-Channels | US Robotics | Number
11153 | USR-Channel-Expansion | US Robotics | Number
11154 | USR-Channel-Decrement | US Robotics | Number
11155 | USR-Expansion-Algorithm | US Robotics | Number
11156 | USR-Compression-Algorithm | US Robotics | Number
11157 | USR-Receive-Acc-Map | US Robotics | Number
11158 | USR-Transmit-Acc-Map | US Robotics | Number
11159 | USR-Compression-Reset-Mode | US Robotics | Number
11160 | USR-Min-Compression-Size | US Robotics | Number
11161 | USR-IP | US Robotics | Number
11162 | USR-IPX | US Robotics | Number
11163 | USR-Filter-Zones | US Robotics | Number
11164 | USR-Appletalk | US Robotics | Number
11165 | USR-Bridging | US Robotics | Number
11166 | USR-Spoofing | US Robotics | Number
11167 | USR-Host-Type | US Robotics | Number
11168 | USR-Send-Name | US Robotics | Text
11169 | USR-Send-Password | US Robotics | Text
11170 | USR-Start-Time | US Robotics | Number
11171 | USR-End-Time | US Robotics | Number
11172 | USR-Send-Script1 | US Robotics | Text
11173 | USR-Reply-Script1 | US Robotics | Text
11174 | USR-Send-Script2 | US Robotics | Text
11175 | USR-Reply-Script2 | US Robotics | Text
11176 | USR-Send-Script3 | US Robotics | Text
11177 | USR-Reply-Script3 | US Robotics | Text
11178 | USR-Send-Script4 | US Robotics | Text
11179 | USR-Reply-Script4 | US Robotics | Text
11180 | USR-Send-Script5 | US Robotics | Text
11181 | USR-Reply-Script5 | US Robotics | Text
11182 | USR-Send-Script6 | US Robotics | Text
11183 | USR-Reply-Script6 | US Robotics | Text
11184 | USR-Terminal-Type | US Robotics | Text
11185 | USR-Appletalk-Network-Range | US Robotics | Number
11186 | USR-Local-IP-Address | US Robotics | Text
11187 | USR-Routing-Protocol | US Robotics | Number
11188 | USR-Modem-Group | US Robotics | Text
11189 | USR-IPX-Routing | US Robotics | Number
11190 | USR-IPX-WAN | US Robotics | Number
11191 | USR-IP-RIP-Policies | US Robotics | Number
11192 | USR-IP-RIP-Simple-Auth-Password | US Robotics | Text
11193 | USR-IP-RIP-Input-Filter | US Robotics | Text
11194 | USR-IP-Call-Input-Filter | US Robotics | Text
11195 | USR-IPX-RIP-Input-Filter | US Robotics | Text
11196 | USR-MP-MRRU | US Robotics | Number
11197 | USR-IPX-Call-Input-Filter | US Robotics | Text
11198 | USR-AT-Input-Filter | US Robotics | Text
11199 | USR-AT-RTMP-Input-Filter | US Robotics | Text
11200 | USR-AT-Zip-Input-Filter | US Robotics | Text
11201 | USR-AT-Call-Input-Filter | US Robotics | Text
11202 | USR-ET-Bridge-Input-Filter | US Robotics | Text
11203 | USR-IP-RIP-Output-Filter | US Robotics | Text
11204 | USR-IP-Call-Output-Filter | US Robotics | Text
11205 | USR-IPX-RIP-Output-Filter | US Robotics | Text
11206 | USR-IPX-Call-Output-Filter | US Robotics | Text
11207 | USR-AT-Output-Filter | US Robotics | Text
11208 | USR-AT-RTMP-Output-Filter | US Robotics | Text
11209 | USR-AT-Zip-Output-Filter | US Robotics | Text
11210 | USR-AT-Call-Output-Filter | US Robotics | Text
11211 | USR-ET-Bridge-Output-Filter | US Robotics | Text
11212 | USR-ET-Bridge-Call-Output-Filter | US Robotics | Text
11213 | USR-IP-Default-Route-Option | US Robotics | Number
11214 | USR-MP-EDO-HIPER | US Robotics | String
11215 | USR-Modem-Training-Time | US Robotics | Number
11216 | USR-Interface-Index | US Robotics | Number
11217 | USR-Tunnel-Security | US Robotics | Number
11218 | USR-Port-Tap | US Robotics | Number
11219 | USR-Port-Tap-Format | US Robotics | Number
11220 | USR-Port-Tap-Output | US Robotics | Number
11221 | USR-Port-Tap-Facility | US Robotics | Number
11222 | USR-Port-Tap-Priority | US Robotics | Number
11223 | USR-Port-Tap-Address | US Robotics | String
11224 | USR-MobileIP-Home-Agent-Address | US Robotics | String
11225 | USR-Tunneled-MLPP | US Robotics | Number
11226 | USR-Multicast-Proxy | US Robotics | Number
11227 | USR-Multicast-Receive | US Robotics | Number
11228 | USR-Multicast-Forwarding | US Robotics | Number
11229 | USR-IGMP-Query-Interval | US Robotics | Number
11230 | USR-IGMP-Maximum-Response-Time | US Robotics | Number
11231 | USR-IGMP-Robustness | US Robotics | Number
11232 | USR-IGMP-Version | US Robotics | Number
11233 | USR-IGMP-Routing | US Robotics | Number
11234 | USR-VTS-Session-Key | US Robotics | Text
11235 | USR-Orig-NAS-Type | US Robotics | Text
11236 | USR-Call-Arrival-Time | US Robotics | Number
11237 | USR-Call-End-Time | US Robotics | Number
11238 | USR-Rad-Multicast-Routing-Ttl | US Robotics | Number
11239 | USR-Rad-Multicast-Routing-Rate-Limit | US Robotics | Number
11240 | USR-Rad-Multicast-Routing-Protocol | US Robotics | Number
11241 | USR-Rad-Multicast-Routing-Boundary | US Robotics | Text
11242 | USR-Rad-Dvmrp-Metric | US Robotics | Number
11243 | USR-Chat-Script-Name | US Robotics | Text
11244 | USR-Chat-Script-Rules | US Robotics | Text
11245 | USR-Rad-Location-Type | US Robotics | Number
11246 | USR-Tunnel-Switch-Endpoint | US Robotics | Text
11247 | USR-OSPF-Addressless-Index | US Robotics | Number
11248 | USR-Callback-Type | US Robotics | Number
11249 | USR-Tunnel-Auth-Hostname | US Robotics | Text
11250 | USR-Acct-Reason-Code | US Robotics | Number
11251 | USR-DNIS-ReAuthentication | US Robotics | Number
11252 | USR-PPP-Source-IP-Filter | US Robotics | Text
11253 | USR-Auth-Mode | US Robotics | Number
11254 | USR-NAS-Type | US Robotics | Number
11255 | USR-Request-Type | US Robotics | Number


Troubleshooting

This section covers:

  • Troubleshooting IAS as a RADIUS server
  • Troubleshooting IAS as a RADIUS proxy

Note

  • XOX


Troubleshooting IAS as a RADIUS server

What problem are you having?

A connection attempt fails.

Cause: IAS has either rejected or discarded the connection attempt for a variety of reasons.

Solution: Verify that IAS is configured for the logging of rejected authentication attempts to the event log. Try the connection again, and then check the system event log for an IAS event for the connection attempt. Use the information in the log to determine the reason the connection attempt was either rejected or discarded and the way to fix the problem.

See also: Event logging for IAS; To configure event logging for IAS

Connection attempts using Protected Extensible Authentication Protocol (PEAP) fail.

Cause: The wireless remote access policy on the IAS server is not configured to use PEAP as the authentication method.

Solution: Create a wireless remote access policy on the IAS server that is configured with PEAP-EAP-MS-CHAPv2 or PEAP-EAP-TLS.

See also: Configure remote access policies; To configure PEAP and EAP methods; Wireless access with secure password authentication

Cause: Remote access policy on the IAS server is configured to reject the user or computer.

Solution: Make sure that your remote access policy and user account settings are not configured to reject user authentication and authorization attempts. For example, if the user belongs to a group that is restricted in remote access policies to accessing the network between 9 A.M. and 5 P.M., any attempt by the user to log on between 5:01 P.M. and 8:59 A.M. will fail. To resolve the issue, change the day and time restrictions in remote access policies, or move the user to another group with different or no day and time restrictions. In addition, user account settings in Active Directory might prevent the user from accessing the network.

See also: Introduction to remote access policies; Elements of a remote access policy; Dial-in properties of a user account

Cause: You are using PEAP-EAP-MS-CHAPv2 as the authentication method and the IAS server does not have a certificate to use for server authentication to the client.

Solution: If the IAS server is a domain member computer, auto-enroll a certificate that contains the Server Authentication purpose in Enhanced Key Usage extensions and is configured according to minimum server certificate requirements. If the IAS server is not a domain member computer, enroll a certificate that contains the Server Authentication purpose in Enhanced Key Usage extensions (and which is configured according to minimum server certificate requirements) using the CA Web enrollment tool, or install a certificate on the IAS server using a floppy disk.

See also: Certificate requirements for EAP

Cause: You are using PEAP-EAP-MS-CHAPv2 as the authentication method and when prompted to make a decision whether or not to trust the server certificate, the user has chosen not to trust the server certificate.

Solution: Instruct users to trust the server certificate at next log on.

Cause: You are using PEAP-EAP-TLS as the authentication method and the client computer does not have a certificate that contains the Client Authentication purpose in Enhanced Key Usage extensions and is configured according to minimum client certificate requirements.

Solution: If the client is a domain member computer, auto-enroll a certificate that contains the Client Authentication purpose in Enhanced Key Usage extensions and is configured according to minimum client certificate requirements. If the client is not a domain member computer, enroll a certificate that contains the Client Authentication purpose in Enhanced Key Usage extensions (and which is configured according to minimum client certificate requirements) using the CA Web enrollment tool, or install a certificate on the IAS server using a floppy disk.

See also: Certificate requirements for EAP

Cause: The client computer does not trust the CA that issued the server certificate.

Solution: Add your organization's root certification authority certificate to the Trusted Root Certification Authorities folder in the computer certificate store.

See also: To retrieve a certification authority certificate from a Windows Server 2003 CA

Cause: You are using PEAP-EAP-TLS as the authentication method and the IAS server does not have a certificate to use for server authentication to the client.

Solution: If the IAS server is a domain member computer, auto-enroll a certificate that contains the Server Authentication purpose in Enhanced Key Usage extensions and is configured according to minimum server certificate requirements. If the IAS server is not a domain member computer, enroll a certificate that contains the Server Authentication purpose in Enhanced Key Usage extensions (and which is configured according to minimum server certificate requirements) using the CA Web enrollment tool, or install a certificate on the IAS server using a floppy disk.

See also: Certificate requirements for EAP

Cause: Group Policy on domain member computers has not been refreshed after the configuration of certificate auto-enrollment.

Solution: Refresh Group Policy on domain member computers. After auto-enrollment is configured and enabled, all domain member computers will receive computer certificates at the next refresh of Group Policy, whether the refresh is triggered manually with the gpupdate command or when the computer next logs on to the domain.

See also: Network access authentication and certificates; To configure automatic certificate allocation from an enterprise CA; Use Windows Server 2003 Certificate Services Web pages; To manage certificates for a computer; and To request a certificate

Computers newly joined to the domain cannot enroll certificates

Cause: When a public key infrastructure (PKI) is deployed and autoenrollment is configured for the domain, Active Directory replication latency can temporarily affect the ability of a client or server to obtain a certificate from a certification authority (CA).

Solution: Verify that Active Directory has replicated to all domain controllers, and then refresh Group Policy to enroll a certificate on the computer. You can refresh Group Policy by running the gpupdate command or by logging on to the domain.

See also: Checklist: Configuring certificate autoenrollment; Authentication methods; Troubleshooting replication

Connection attempts using Password Authentication Protocol (PAP) fail.

Cause: The password is incorrect.

Solution: Try the connection again and verify that the password is correct.

Cause: Mismatched shared secrets.

Solution: Verify that the same shared secret is configured on the access server and for the RADIUS client in Internet Authentication Service.

See also: To edit RADIUS client configuration; Shared secrets

Connection attempts using Microsoft Challenge-Handshake Authentication Protocol (MS-CHAP) fail.

Cause: The password is incorrect.

Solution: Try the connection again and verify that the password is correct.

Cause: The access client is using LAN Manager authentication.

Solution: By default, MS-CHAP for XOX; XOX; and XOX does not support LAN Manager authentication. If you want to allow the use of LAN Manager authentication with MS-CHAP for older Microsoft operating systems such as Windows NT 3.5x and Windows 95, you must set the following registry value to 1 on the IAS server: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\Allow LM Authentication

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

See also: MS-CHAP; To add a value to a registry key entry

Users with 802.1x authenticated switch client connections with EAP or PEAP are not prompted to input credentials and cannot log on

Cause: The icon for the network connection must be displayed in the notification area on the client.

Solution: Configure the network connection properties on the client so that the network connection icon is displayed in the notification area when connected.

See also: To show a network connection icon in the notification area

Cause: The switch is not configured to initiate authentication with an EAP-Request-Identity packet when it detects that a client is active on the port.

Solution: Configure the switch to initiate authentication.

Users who should not have remote access permission can log on.

Cause: A remote access policy might be granting access to these users.

Solution: Check the policy list to ensure that you have not included groups in which the user is a member that should be denied access.

Cause: The remote access permission on the user account dial-in properties is set to Grant access, which overrides the remote access permission of the remote access policy.

Solution: Check the dial-in properties for the user object.

See also: To configure remote access permission for a user; Dial-in properties of a user account

Cause: Remote access policies might be evaluated in the wrong order.

Solution: Authorization is granted or denied by the first policy with conditions that match the connection attempt. Use Move Up to move the policy that denies access to these users, so that it is higher in the list.

See also: To configure remote access permission for a user; Dial-in properties of a user account

Users can log on successfully, but their logon attempts do not appear in the log files.

Cause: IAS is not configured to log successful authentication attempts.

Solution: Configure IAS to log successful authentication attempts in the event log.

See also: Event logging for IAS; To configure event logging for IAS

You have just changed your Active Directory domain from a Windows 2000 mixed domain to a Windows 2000 native domain or a Windows Server 2003 domain, and IAS servers can no longer authenticate valid connection requests.

Cause: After you change a domain from a Windows 2000 mixed domain to a Windows 2000 native domain or a Windows Server 2003 domain, every domain controller in the domain must be restarted in order for the change to replicate.

Solution: Restart the domain controllers so that the IAS servers can authenticate valid connection requests.

See also: Domain and forest functionality

Interim accounting messages are not being recorded in the remote access log file.

Cause: Remote access logging is not configured to record periodic status.

Solution: Configure remote access logging to record periodic status.

Cause: You have not added and configured the Acct-Interim-Interval RADIUS accounting attribute on the Advanced tab of the appropriate remote access policy.

Solution: Add and configure the Acct-Interim-Interval RADIUS accounting attribute on the Advanced tab of the appropriate remote access policy. The value of the Acct-Interim-Interval attribute is the number of seconds between interim accounting updates.

Cause: The access server does not support interim accounting or is not configured to send interim accounting messages.

Solution: Verify that the access server supports interim accounting and the Acct-Interim-Interval attribute. If so, consult the access server documentation for instructions about how to enable interim accounting. The Routing and Remote Access service supports sending interim accounting messages and is enabled from the properties of a RADIUS server when configuring the RADIUS accounting provider.

See also: Logging user authentication and accounting requests; To add RADIUS attributes to a remote access policy; To use RADIUS accounting

Third-party network access servers (NASs) drop connections and IAS sends a Microsoft vendor-specific attribute (MS-RAS-MPPE-Encryption-Policy) to the network access server instead of the NAS's vendor ID.

Cause: The encryption policy as configured in remote access policies is not set to the default.

Solution: The Microsoft VSA MS-RAS-MPPE-Encryption-Policy is sent to third-party network access servers if the encryption policy as configured in remote access policies is not set to the default. The default encryption policy allows all encryption levels and does not contain any attributes specific to the Routing and Remote Access service, so applying default encryption settings will prevent IAS from sending any Microsoft VSAs to third-party NASs. Take the following steps in the profile of the remote access policy:

  • On the Encryption tab, return the encryption policy to the default. Select all encryption levels except No encryption.
  • On the Advanced tab, remove all attributes specific to the Routing and Remote Access service from the list of attributes for the remote access policy.
  • On the IP tab, remove all IP filters.
  • On the Multilink tab, select Server settings determine Multilink usage. Return all other settings to the default (not selected).

See also: To configure encryption; To configure vendor-specific attributes for a remote access policy; Vendor-specific attribute overview; To recreate the default remote access policy; To configure IP options

MS-CHAP v2 or EAP-TLS authentications are being rejected for valid connection attempts.

Cause: The authentication method (in the profile settings of the connection request policy) that matched the connection request is configured for the Accept the connection attempt without performing authentication or authorization setting. MS-CHAP v2 and EAP-TLS are mutual authentication protocols. In mutual authentication, the access client proves that it is a valid access client to the authenticating server and the authenticating server proves that it is a valid authenticating server to the access client. When this authentication option is used, although the connect request is granted, the authenticating server does not provide validation to the access client. As the result, mutual authentication fails.

Solution: Reconfigure connection request policies so that MS-CHAP v2 and EAP-TLS connections are not being accepted without authentication and authorization.

See also: Connection request policies

You can no longer see the Remote Access Policies node in Routing and Remote Access.

Cause: When a Routing and Remote Access server is configured to use RADIUS authentication, the remote access policies on the Routing and Remote Access server are never evaluated for authorization.

Solution: This is intended behavior. If the RADIUS server of the server running the Routing and Remote Access service is an IAS server, remote access policies are configured through Internet Authentication Service.

When you try to open the IAS console, you receive an error message and the console does not open.

Cause: To administer IAS, you must have administrative credentials.

Solution: You can use the Runas command to perform tasks (for example, opening the IAS console), when you are logged on as a member of a group that does not have administrative credentials (such as Users or Power Users). Alternately, you can log on as Administrator to open the console.

See also: To run a program with administrative credentials; To create a shortcut using the runas command; Runas

Note

  • XOX


Troubleshooting IAS as a RADIUS proxy

What problem are you having?

No responses to Access-Request messages are sent through the IAS proxy for valid connection attempts.

Cause: A mismatched shared secret is configured between the IAS proxy and the RADIUS server or proxy to which the RADIUS messages are being forwarded.

Solution: Verify that the shared secret that is configured on the IAS proxy for the appropriate remote RADIUS server group member matches the shared secret of the RADIUS client of the RADIUS server or proxy to which the RADIUS messages are being sent.

See also: Shared secrets

MS-CHAP v2 authentications are being rejected for valid connection attempts.

Cause: Attribute manipulation rules on the profile setting for the connection request policy that is forwarding the requests are modifying the User-Name attribute. This causes the validation of the MS-CHAP v2 hash on the authenticating server to fail. The only exception is when a backslash (\) character is used and the manipulation only affects the information to the left of it. A backslash character is typically used to indicate a domain name (the information to the left of the backslash character) and a user account name within the domain (the information to the right of the backslash character). In this case, attribute manipulation rules that only modify or replace the domain name are allowed.

Solution: Reconfigure attribute manipulation rules so that they are not modifying the User-Name attribute.

See also: Connection request policies

When you try to open the IAS console, you receive an error message and the console does not open.

Cause: To administer IAS, you must have administrative credentials.

Solution: You can use the Runas command to perform tasks (for example, opening the IAS console), when you are logged on as a member of a group that does not have administrative credentials (such as Users or Power Users). Alternately, you can log on as Administrator to open the console.

See also: To run a program with administrative credentials, To create a shortcut using the runas command, Runas

Note

  • XOX