How IAS Technology Works

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

 

In this section

• RADIUS Protocol

• IAS Roles

• IAS as a RADIUS Server

• IAS as a RADIUS Proxy

Internet Authentication Service (IAS) is the Microsoft implementation of a Remote Authentication Dial-In User Service (RADIUS) server and proxy in Microsoft Windows Server 2003; Standard Edition, Windows Server 2003; Enterprise Edition, and Windows Server 2003; Datacenter Edition. As a RADIUS server, IAS performs centralized connection authentication, authorization, accounting, and auditing (AAAA) 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 RFC 2865 and RFC 2866.

RADIUS Protocol

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 (AP) — 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 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 (NASs) might use UDP port 1645 for RADIUS authentication messages and UDP port 1646 for RADIUS accounting messages. By default, IAS supports receiving RADIUS messages sent to both sets of UDP ports.

The RADIUS protocol is implemented solely between NASs (RADIUS clients) and IAS servers and proxies (RADIUS servers and proxies). A user’s client computer does not use the RADIUS protocol when connecting to a NAS.

RADIUS Authentication Process

The RADIUS authentication process begins when a user attempts to access a network through a NAS that is configured as a RADIUS client to a RADIUS server.

For example, when the remote access user sends credentials using the Challenge Handshake Authentication Protocol (CHAP), the RADIUS client creates a RADIUS Access-Request message containing such attributes as the Port ID the user is accessing and the results of the CHAP authentication process (the user name, the challenge string, and the response of the remote access client).

The RADIUS Access-Request message is sent from the RADIUS client to the RADIUS server. If a response is not received within a length of time, the request is re-sent. The RADIUS client can also be configured to forward requests to an alternate server or servers in the event that the primary server is down or unreachable. An alternate server can be used either after a specified number of tries to the primary server are not responded to, or in a round-robin fashion.

In the case of the Routing and Remote Access service, multiple RADIUS servers can be added and prioritized using a scoring mechanism. If a primary RADIUS server does not respond within three seconds, the Routing and Remote Access service automatically switches to the RADIUS server with the next highest score.

After the RADIUS server receives the request, it validates the sending RADIUS client. Validation occurs by verifying that the RADIUS Access-Request message is sent from a configured RADIUS client. If the Access-Request message is sent by a valid RADIUS client, and if the Message-Authenticator attribute is required for the RADIUS client, the value of the Message-Authenticator attribute is verified using the RADIUS shared secret. If the Message-Authenticator attribute is either missing or contains an incorrect value, the RADIUS message is silently discarded — that is, the message is discarded without logging an event in the Event Log or making an entry in the IAS accounting log.

If the RADIUS client is valid, the RADIUS server consults a database of users to find the user whose name matches the User-Name attribute in the request. The user account contains a list of requirements that must be met to allow access for the user. This list of requirements can include verification of the password, and it can also specify whether the user is allowed access.

If any condition where the authentication or authorization is not met, the RADIUS server sends a RADIUS Access-Reject message in response, indicating that this user request is not valid.

If all conditions are met, the list of configuration values for the user is placed into a RADIUS Access-Accept message that is sent back to the RADIUS client. These values include a list of RADIUS attributes and all necessary values to deliver the desired service. For Serial Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP) service types, this can include values such as encryption types, the Class attribute, Maximum Transmission Unit (MTU), as well as the desired compression and packet filter identifiers.

RADIUS Message Format

The following section provides information that might be useful for the following:

• Understanding a Network Monitor capture.

• Understanding the different message formats for analyzing the accounting log.

• Entering vendor-specific attribute (VSA) numbers.

RADIUS messages sent to the RADIUS server are sent as UDP messages. RADIUS authentication messages are sent using UDP port 1812, and RADIUS accounting messages are sent on UDP port 1813. Some older NASs use UDP port 1645 for RADIUS authentication messages and UDP port 1646 for RADIUS accounting messages.

IAS supports the receiving of RADIUS messages on any configurable set of ports; however by default it is configured to receive messages on both sets of UDP ports. Exactly one RADIUS message is encapsulated in the UDP payload.

General Packet Structure

The figure, “General Structure of RADIUS Packet,” provides a summary of the data structure of a RADIUS packet. The RADIUS client or server sends the fields from top to bottom, or from the Code field in vertical order to the Attributes.

General Structure of RADIUS Packet

Code field

The Code field is 1 byte long and indicates the type of RADIUS message. A message with an invalid Code field is silently discarded. The defined values for the RADIUS Code field are listed in the following table “Values for the RADIUS Code Field.”

Values for the RADIUS Code Field

Codes (Decimal)	Packets
1	Access-Request
2	Access-Accept
3	Access-Reject
4	Accounting-Request
5	Accounting-Response
11	Access-Challenge
12	Status-Server (experimental)
13	Status-Client (experimental)
255	Reserved

Identifier field

The Identifier field is 1 byte long and is used to match a request with its corresponding response.

Length field

The Length field is two octets long and indicates the entire length of the RADIUS message, including the Code, Identifier, Length, and Authenticator fields, and the RADIUS attributes. The Length field can vary from 20 to 4,096 bytes.

Authenticator field

The Authenticator field is sixteen octets long and contains the information that the RADIUS client and server use to verify that the message came from a computer that is configured with a common shared secret

Attributes section

The Attributes section of the RADIUS message contains one or more RADIUS attributes, which carry the specific authentication, authorization, information, and configuration details for RADIUS messages.

RADIUS Attributes

The figure, “RADIUS Attribute Structure,” shows the structure of each RADIUS attribute. RADIUS attributes use the common Type-Length-Value format used by other protocols.

RADIUS Attribute Structure

Type field

The Type field is 1 byte long and indicates the specific type of RADIUS attribute. The RADIUS Standard attributes are listed in the following table, “RADIUS Standard Attribute Types.” For information about other RADIUS attributes and their use, see RFCs 2865 and 2866.

RADIUS Standard Attribute Types

Type Values	Description	Type Values	Description
1	User-Name	45	Acct-Authentic
2	User-Password	46	Acct-Session-Time
3	CHAP-Password	47	Acct-Input-Packets
4	NAS-IP-Address	48	Acct-Output-Messages
5	NAS-Port	49	Acct-Terminate-Cause
6	Service-Type	50	Acct-Multi-Session-Id
7	Framed-Protocol	51	Acct-Link-Count
8	Framed-IP-Address	52	Acct-Input-Gigawords
9	Framed-IP-Netmask	53	Acct-Output-Gigawords
10	Framed-Routing	55	Event-Timestamp
11	Filter-ID	60	CHAP-Challenge
12	Framed-MTU	61	NAS-Port-Type
13	Framed-Compression	62	Port-Limit
14	Login-IP-Host	63	Login-LAT-Port
15	Login-Service	64	Tunnel-Type
16	Login-TCP-Port	65	Tunnel-Medium-Type
18	Reply-Message	66	Tunnel-Client-Endpt
19	Callback-Number	67	Tunnel-Server-Endpt
20	Callback-Id	68	Acct-Tunnel-Connection
22	Framed-Route	69	Tunnel-Password
23	Framed-IPX-Network	70	ARAP-Password
24	State	71	ARAP-Features
25	Class	72	ARAP-Zone-Access
26	Vendor-Specific	73	ARAP-Security
27	Session-Time-out	74	ARAP-Security-Data
28	Idle-Time-out	75	Password-Retry
29	Termination-Action	76	PROMPT
30	Called-Station-Id	77	Connect-Info
31	Calling-Station-Id	78	Configuration-Token
32	NAS-Identifier	79	EAP-Message
33	Proxy-State	80	Message-Authenticator
34	Login-LAT-Service	81	Tunnel-Pvt-Group-ID
35	Login-LAT-Node	82	Tunnel-Assignment-ID
36	Login-LAT-Group	83	Tunnel-Preference
37	Framed-AppleTalk-Link	84	ARAP-Challenge-Response
38	Framed-AppleTalk-Network	85	Acct-Interim-Interval
39	Framed-AppleTalk-Zone	86	Acct-Tunnel-Packets-Lost
40	Acct-Status-Type	87	NAS-Port-Id
41	Acct-Delay-Time	88	Framed-Pool
42	Acct-Input-Octets	90	Tunnel-Client-Auth-ID
43	Acct-Output-Octets	91	Tunnel-Server-Auth-ID
1	User-Name	45	Acct-Authentic
2	User-Password	46	Acct-Session-Time
44	Acct-Session-Id

Length field

The Length field indicates the length of the attribute, including the Type, Length, and Value fields.

Value field

The Value field is zero or more octets and contains information specific to the Attribute. The format and length of the Value field is based on the type of RADIUS attribute. Note that value 26 is reserved for VSAs.

Vendor-Specific Attributes

VSAs are available to allow vendors to support their own proprietary attributes that are not covered in RFC 2865. IAS includes VSAs from a number of vendors in its multivendor dictionary. However, this list evolves over time and new attributes, and vendors are always being added.

You can add attributes that are not in the IAS multivendor dictionary as Vendor-Specific (RADIUS standard attribute type 26) on the Advanced tab of a remote access policy profile. Therefore, unlike many RADIUS implementations that allow you to add attributes to their multivendor dictionary, IAS allows you to add attributes to each remote access policy profile. To use attribute type 26, an administrator must know the VSA format and the exact information to enter. The VSA formats are documented in the following section. For information about what values to enter, see your NAS documentation. The following figure, “Vendor-Specific Attribute Structure,” shows the structure of the VSA structure.

Vendor-Specific Attribute Structure

Type value

The Type value is set to 26 (0x1A) to indicate a VSA.

Length value

The Length value is set to the number of bytes in the VSA.

Vendor-ID

Vendor-ID is 4 octets long. The high-order octet is 0, and the low-order is 3 octets. Together, they make up the Structure and Identification of Management Information (SMI) Network Management Private Enterprise Code of the vendor.

String field

The String field is the VSA consisting of one or more octets. To conform to the recommendation of RFC 2865, the String field should consist of the fields as shown in the figure “Structure of the String Field.”

Structure of the String Field

Vendor type

The Type value is used to indicate a specific VSA for the vendor.

Vendor length

The Type value is set to the number of bytes in the string.

Attribute-Specific field

The Attribute-Specific field contains the data for the specific vendor attribute.

Vendors who do not conform to RFC 2865 use the attribute type 26 to identify a VSA but do not use the Vendor Type, Vendor Length, and Attribute-Specific fields within the String field. In this case, the VSA format appears as shown in the figure, “Structure of the String Field,” earlier in this section.

When adding a VSA for a particular NAS as type 26, you need to know whether the attribute conforms to RFC 2865. For information about whether your NAS uses the VSA format documented in the figure, “Structure of the String Field,” earlier in this section, see your NAS documentation.

VSAs are configured from the Vendor-Specific Attribute Information dialog box when adding a Vendor-Specific Attribute from the Advanced tab of a remote access policy profile. If the VSA format conforms to RFC 2865, use the Yes. It conforms. option and configure the attribute with the vendor-assigned attribute number, attribute format, and attribute value as defined in NAS documentation. If the VSA format does not conform to RFC 2865, choose No. It does not conform, and configure the attribute with the hexadecimal attribute value, which includes the string of the VSA format (everything after Vendor-ID) as defined in NAS documentation.

RADIUS Message Example

A Windows Server 2003 Point-to-Point Tunneling Protocol (PPTP) client attempts a remote access connection to a Windows Server 2003 VPN server. The VPN server is at the IP address 10.10.210.13, and the IAS server is at the IP address 10.10.210.12.

Access-Request Message

The following Network Monitor capture display shows the Access-Request message sent by the VPN server to the IAS server.

+ IP: ID = 0x850; Proto = UDP; Len: 248
+ UDP: Src Port: Unknown, (1327); Dst Port: Unknown (1812); Length = 228 (0xE4)
  RADIUS: Message Type: Access Request(1)
  RADIUS: Message Type = Access Request
  RADIUS: Identifier = 2 (0x2)
  RADIUS: Length = 220 (0xDC)
  RADIUS: Authenticator = 8A 6F DC 03 23 5F 4B 62 CA 40 92 38 DC 75
          CB 74
  RADIUS: Attribute Type: NAS IP Address(4)
    RADIUS: Attribute type = NAS IP Address
    RADIUS: Attribute length = 6 (0x6)
    RADIUS: NAS IP address = 10.10.210.13
  RADIUS: Attribute Type: Service Type(6)
    RADIUS: Attribute type = Service Type
    RADIUS: Attribute length = 6 (0x6)
    RADIUS: Service type = Framed
  RADIUS: Attribute Type: Framed Protocol(7)
    RADIUS: Attribute type = Framed Protocol
    RADIUS: Attribute length = 6 (0x6)
    RADIUS: Framed protocol = PPP
  RADIUS: Attribute Type: NAS Port(5)
    RADIUS: Attribute type = NAS Port
    RADIUS: Attribute length = 6 (0x6)
    RADIUS: NAS port = 32 (0x20)
  RADIUS: Attribute Type: Vendor Specific(26)
    RADIUS: Attribute type = Vendor Specific
    RADIUS: Attribute length = 12 (0xC)
    RADIUS: Vendor ID = 311 (0x137)
    RADIUS: Vendor string =   _
  RADIUS: Attribute Type: Vendor Specific(26)
    RADIUS: Attribute type = Vendor Specific
    RADIUS: Attribute length = 18 (0x12)
    RADIUS: Vendor ID = 311 (0x137)
    RADIUS: Vendor string = MSRASV5.00
  RADIUS: Attribute Type: NAS Port Type(61)
    RADIUS: Attribute type = NAS Port Type
    RADIUS: Attribute length = 6 (0x6)
    RADIUS: NAS port type = Virtual
  RADIUS: Attribute Type: Tunnel Type(64)
    RADIUS: Attribute type = Tunnel Type
    RADIUS: Attribute length = 6 (0x6)
    RADIUS: Tag = 0 (0x0)
    RADIUS: Tunnel type = Point-to-Point Tunneling Protocol(PPTP)
  RADIUS: Attribute Type: Tunnel Media Type(65)
    RADIUS: Attribute type = Tunnel Media Type
    RADIUS: Attribute length = 6 (0x6)
    RADIUS: Tag = 0 (0x0)
    RADIUS: Tunnel media type = IP (IP version 4)
  RADIUS: Attribute Type: Calling Station ID(31)
    RADIUS: Attribute type = Calling Station ID
    RADIUS: Attribute length = 14 (0xE)
    RADIUS: Calling station ID = 10.10.14.226
  RADIUS: Attribute Type: Tunnel Client Endpoint(66)
    RADIUS: Attribute type = Tunnel Client Endpoint
    RADIUS: Attribute length = 14 (0xE)
    RADIUS: Tunnel client endpoint = 10.10.14.226
  RADIUS: Attribute Type: User Name(1)
    RADIUS: Attribute type = User Name
    RADIUS: Attribute length = 18 (0x12)
    RADIUS: User name = NTRESKIT\johndoe
  RADIUS: Attribute Type: Vendor Specific(26)
    RADIUS: Attribute type = Vendor Specific
    RADIUS: Attribute length = 24 (0x18)
    RADIUS: Vendor ID = 311 (0x137)
    RADIUS: Vendor string = _+-_e_$+fN<N
  RADIUS: Attribute Type: Vendor Specific(26)
    RADIUS: Attribute type = Vendor Specific
    RADIUS: Attribute length = 58 (0x3A)
    RADIUS: Vendor ID = 311 (0x137)
    RADIUS: Vendor string = _4

The RADIUS attributes sent by the VPN server include the framed protocol, the service type, the class, various tunnel attributes for the PPTP connection, and a series of VSAs for Microsoft CHAP (MS-CHAP v1) authentication. For more information about Microsoft vendor-specific RADIUS attributes, see RFC 2548.

Access-Accept Message

The following Network Monitor capture display shows the Access-Accept message sent by the IAS server to the VPN server.

+ IP: ID = 0xB18; Proto = UDP; Len: 248
+ UDP: Src Port: Unknown, (1812); Dst Port: Unknown (1327); Length = 228 (0xE4)
  RADIUS: Message Type: Access Accept(2)
  RADIUS: Message Type = Access Accept
  RADIUS: Identifier = 2 (0x2)
  RADIUS: Length = 220 (0xDC)
  RADIUS: Authenticator = 52 E19 98 2E F8 E2 D3 B7 3B E1 24 5B 72          55 9E
  RADIUS: Attribute Type: Framed Protocol(7)
    RADIUS: Attribute type = Framed Protocol
    RADIUS: Attribute length = 6 (0x6)
    RADIUS: Framed protocol = PPP
  RADIUS: Attribute Type: Service Type(6)
    RADIUS: Attribute type = Service Type
    RADIUS: Attribute length = 6 (0x6)
    RADIUS: Service type = Framed
  RADIUS: Attribute Type: Class(25)
    RADIUS: Attribute type = Class
    RADIUS: Attribute length = 32 (0x20)
    RADIUS: Class = <$_@
  RADIUS: Attribute Type: Vendor Specific(26)
    RADIUS: Attribute type = Vendor Specific
    RADIUS: Attribute length = 42 (0x2A)
    RADIUS: Vendor ID = 311 (0x137)
    RADIUS: Vendor string = _$_DZ,Sc7__:+RW_t-qxF                        (-+%p6
  RADIUS: Attribute Type: Vendor Specific(26)
    RADIUS: Attribute type = Vendor Specific
    RADIUS: Attribute length = 42 (0x2A)
    RADIUS: Vendor ID = 311 (0x137)
    RADIUS: Vendor string = _$_
  RADIUS: Attribute Type: Vendor Specific(26)
    RADIUS: Attribute type = Vendor Specific
    RADIUS: Attribute length = 51 (0x33)
    RADIUS: Vendor ID = 311 (0x137)
    RADIUS: Vendor string = _-
  RADIUS: Attribute Type: Vendor Specific(26)
    RADIUS: Attribute type = Vendor Specific
    RADIUS: Attribute length = 21 (0x15)
    RADIUS: Vendor ID = 311 (0x137)
    RADIUS: Vendor string =

The RADIUS attributes sent by the IAS server include the user name, the service type, the framed protocol, the service class, and a series of VSAs for MS-CHAP authentication.

Validating an Incoming RADIUS Message

For RADIUS packets for which IAS is acting as RADIUS server, IAS performs the following validation checks:

1. IAS first verifies that the RADIUS message was sent from a configured RADIUS client by checking the source IP address of the RADIUS message.

2. If the message is not from a configured RADIUS client, it is silently discarded and an event is logged in the system event log.

3. IAS checks to ensure that the packet type is valid for the port on which it was received and then checks the structure of the RADIUS message. Items checked include valid values of the Code field, the size of the RADIUS message, and the size of the RADIUS attributes in the RADIUS message. IAS also checks whether or not the attributes themselves are the expected data type. If the attribute is not the expected data type, or if the RADIUS message is malformed, the message is discarded and an event is logged in the system event log.

4. The User-Name attribute is checked for the value of the Ping User-Name registry setting. If there is a match between the value of the User-Name attribute and the value of the Ping User-Name registry setting, IAS sends an Access-Reject for authentication requests and an accounting response for accounting requests.

5. If the Message-Authenticator attribute is present, its value is validated using the shared secret. A shared secret is a text string that serves as a password between a RADIUS server and a RADIUS client.

For RADIUS request packets for which IAS is acting as RADIUS proxy, IAS performs the following validation checks:

1. IAS first verifies that the RADIUS message was sent from a configured RADIUS client by checking the source IP address of the RADIUS message.

   If the message is not from a configured RADIUS client, it is silently discarded, and an event is logged in the system event log.

2. IAS checks to ensure that the packet type is valid for the port on which it was received and then checks the structure of the RADIUS message. Items checked include valid values of the Code field, the size of the RADIUS message, and the size of the RADIUS attributes in the RADIUS message.

   If the RADIUS message is malformed, it is silently discarded and an event is logged in the system event log.

3. IAS checks for the presence of the Proxy-State attribute and whether the value of the Proxy-State attribute corresponds to an active proxy session in the proxy session table. If the RADIUS message does not contain a valid Proxy-State attribute, it is silently discarded and an event is logged in the system event log.

4. If the Message-Authenticator attribute is present, its value is validated using the shared secret. A shared secret is a text string that serves as a password between a RADIUS server and a RADIUS client. If the Message-Authenticator attribute is required but missing, or verification of its value fails, the message is silently discarded, and an event is logged in the system event log.

For RADIUS response packets for which IAS is acting as RADIUS proxy, IAS performs the following validation checks:

1. IAS first verifies that the RADIUS message was sent from a configured remote RADIUS server by checking the source IP address of the RADIUS message.

2. If the message is not from a configured remote RADIUS server, it is silently discarded and an event is logged in the system event log.

3. IAS checks to ensure that the packet type is valid for the port on which it was received and then checks the structure of the RADIUS message. Items checked include valid values of the Code field, the size of the RADIUS message, and the size of the RADIUS attributes in the RADIUS message.

4. If the RADIUS message is malformed, it is silently discarded, and an event is logged in the system event log.

5. IAS checks for the presence of the Proxy-State attribute and whether the value of the Proxy-State attribute corresponds to an active proxy session in the proxy session table. If the RADIUS message does not contain a valid Proxy-State attribute, it is silently discarded and an event is logged in the system event log.

6. IAS checks the IP source address and UDP source port of the message against the matching entry in the proxy session table to verify that the message was sent from the remote RADIUS server to which the initial request was sent.

7. The value of the Authenticator field is checked.

   If the RADIUS message contains an invalid Authenticator field, it is silently discarded and an event is logged in the system event log. This is typically caused by mismatched shared secrets between the IAS server and the remote RADIUS server sending the RADIUS message.

8. If the Message-Authenticator attribute is present, its value is validated using the shared secret. If the Message-Authenticator attribute is required but missing, or verification of its value fails, the message is silently discarded, and an event is logged in the system event log.

IAS Roles

In Microsoft Windows 2000, you can use IAS only as a RADIUS server. In Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition, you can use IAS as either a RADIUS server or a RADIUS proxy. In addition, you can use IAS simultaneously as both proxy and server to perform AAAA on some Access-Request messages while forwarding others to remote RADIUS server groups. 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, you must add the computer account of the IAS server to the RAS and IAS Servers group for each domain.

When configuring your IAS server to function as a RADIUS server, proxy server, or both, it is important to understand how IAS processes each Access-Request message received from a RADIUS client.

Using IAS as a RADIUS Server

When you use IAS as a RADIUS server, Access-Request messages are authenticated with Active Directory, a Microsoft Windows NT Server 4.0 domain, or by the Security Account Manager (SAM) in Microsoft Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. Access-Request messages are authorized with the user or computer account dial-in properties and remote access policies that are configured on the IAS server. Additionally, IAS can return an Access-Accept message without authenticating and authorizing the Access-Request message.

The contents of user authentication and accounting requests are logged in a local log file or are sent to a Structured Query Language (SQL) Server database, depending on how remote access logging settings are configured in the IAS console.

You can use IAS as a RADIUS server to do the following:

• Centralize authentication, authorization, and accounting for a heterogeneous set of access servers.

• Deploy secure password authentication with Protected Extensible Authentication Protocol (PEAP) for 802.1X authenticating switches and wireless clients

• Use a Windows NT Server 4.0 domain, an Active Directory domain, or the local SAM as your user account database.

• Centralize both the configuration of remote access policies and connection logging for accounting when you are using the Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; or Windows 2000 Routing and Remote Access service on multiple dial-up servers, VPN servers, or demand-dial routers.

• Outsource 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.

Note

• The configuration of IAS servers running on products in the Windows 2000 Server family can be imported into products in the Windows Server 2003 family by using netsh AAAA commands. The reverse, however, is not possible. To centrally manage IAS on both Windows 2000 and Windows Server 2003, you can first make configuration changes on IAS servers running Windows 2000, and then import the new server configuration into IAS servers running Windows Server 2003.

When you configure IAS as a RADIUS server, Access-Request messages are processed locally. In this process, IAS does the following:

1. Validates the RADIUS packet. The incoming Access-Request message is validated for source IP address, the digital signature, valid attributes, and so on. If the RADIUS message is not valid, an event is logged in the system event log and the RADIUS Access-Request message is discarded. An Access-Reject message is not sent.

   Checks for auto-reject. Auto Reject, also called Ping User-Name, is used to send an immediate Access-Reject message when the User-Name attribute in the Access-Request message matches a specific value.

   Some RADIUS proxy servers and network access servers periodically send authentication and accounting requests, or 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 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 value of the User-Name attribute in ping requests that other servers make. If the registry entry and the user name value match, IAS automatically rejects the request but does not create an event or accounting log entry.

2. Performs connection request policy evaluation. If no connection request policies are matched, an event is logged in the system event log and the RADIUS Access-Request message is discarded.

3. Applies realm stripping rules. IAS determines or defines the domain name and the user identity for the Access-Request message. If the User-Name attribute in the Access-Request message is not the Auto Reject name, then the user identity is determined. User identity is how IAS identifies the user for the purposes of authentication and authorization. Typically, the user identity is the string value of the User-Name RADIUS attribute. If the User-Name attribute is not present, the user identity is set to the Guest account or the account specified by the Default User Identity registry value.

   IAS can use any RADIUS attribute to identify the user. The RADIUS attribute that IAS uses to identify the user is configurable by setting the User Identity Attribute registry setting.

4. Determines authentication server. IAS determines whether to authenticate locally or forward to a remote RADIUS server group (In this example, the message is authenticated locally and is not forwarded.)

5. Performs name cracking. Name cracking is the resolution of the user identity to a user account using user principal names (UPNs), Lightweight Directory Access Protocol (LDAP), distinguished names (DNA), Canonical Names, and so on. If a user principal name is encountered by IAS, IAS performs a query to the Active Directory Global Catalog in an attempt to resolve the name. To speed up this process, a copy of the Global Catalog must be located on a domain controller within the same site as the IAS server.

   When the user identity does not contain a domain name, IAS supplies a domain name. By default, the IAS-supplied domain name is the domain for which the IAS server is a member. You can specify the IAS-supplied domain by means of the DefaultDomain registry setting.

6. Checks for authentication plug-ins. The existence of authentication plug-ins is checked. Authentication plug-ins are optional components created using the IAS software development kit (SDK); each plug-in can return Accept, Reject, or Continue. If an authentication plug-in returns an Accept, the user is considered to be authenticated and the account is then validated. If the authentication plug-in returns a Reject, an Access-Reject message is sent, and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings. If the authentication plug-in returns a Continue, the next plug-in is checked. If there are no more plug-ins, the user still needs to be authenticated.The authentication plug-in can also return RADIUS attributes to be included in the Access-Accept message.

7. Checks for remote access account lockout. After the authentication plug-ins are checked, the registry on the IAS server is read for remote access account lockout entry for the user account. If the account is locked out by way of the remote access account lockout, IAS sends an Access-Reject message back to the NAS and logs an authentication event. For more information, see “IAS Tools and Settings.”

8. Checks for PAP, CHAP, MS-CHAP . If Password Authentication Protocol (PAP), CHAP, Microsoft Challenge Handshake Authentication Protocol (MS-CHAP v1), or MS-CHAP v2 are used to authenticate the remote access client, IAS consults an authentication sub-module based on the authentication protocol to perform the authentication. The user’s credentials (user name and password) are authenticated against the user name and password of the accounts database (either a domain or the local accounts database), and the group membership of the user account is determined. The exact method of authentication varies depending on the authentication protocol.

   If the authentication of the credentials is not successful, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings.

   If either EAP or unauthenticated access is being used, then the user authentication process is bypassed. EAP authentication takes place later in this process. For unauthenticated access, no user authentication is performed.

9. Validates user account. Based on the user or computer account determined through name cracking, the user account is validated to discover whether the account is locked out (which is not the same as remote access account lockout), whether the account is disabled, and whether the user account’s password has expired. If the user account is not valid, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings.

10. Performs remote access policy evaluation. Remote access policies configured on the IAS server are evaluated to find a policy that matches the parameters of the connection. If a matching policy is not found, an Access-Reject message is sent and an event is logged.

11. Checks user properties and profile properties. If the Ignore-User-Dialin-Properties attribute is set to 0, the dial-in properties of the user account and the profile properties of the matching remote access policy are evaluated against the parameters of the connection attempt to ensure that the connection attempt is allowed. If the Ignore-User-Dialin-Properties attribute is set to 1, the profile properties from the matching policy become the set of properties for the connection.

    If the connection attempt is not allowed, an Access-Reject message is sent, and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings.

12. Checks for EAP authentication. If Extensible Authentication Protocol (EAP) is the authentication protocol used for the connection attempt, EAP authentication takes place. The initial negotiation for EAP consists of selecting EAP as the authentication protocol and negotiating an EAP type. Based on the EAP type, the profile settings for the matching policy are checked to ensure that the EAP type is allowed. If the EAP type is not allowed with the profile settings, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the IAS accounting log, depending on the configured logging settings.

    If the EAP type is allowed with the profile settings, EAP authentication for the EAP type occurs. IAS sends an EAP challenge to the NAS requesting it to start EAP negotiation. Communications between EAP modules on a RADIUS client and server are tunneled using the RADIUS protocol. After negotiation is complete, an EAP provider can return attributes that are sent back to the NAS in the Access-Accept message. If EAP authentication fails, an Access-Reject message is sent, and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings.

13. Checks for authorization plug-ins. The existence of authorization plug-ins is checked. Authorization plug-ins are optional components you can create using the IAS SDK. Each plug-in can return either Reject or Continue. If the authorization plug-in returns a Reject, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings. If the authorization plug-in returns Continue, the next plug-in is checked. If there are no more plug-ins, the user is considered to be authorized.

    The authorization plug-in can also return RADIUS attributes to be included in the Access-Accept message.

14. Sends an Access-Accept. If the dial-in properties of the user account, the profile properties of the matching remote access policy, and the conditions imposed by authorization plug-ins allow the connection attempt, an Access-Accept message is sent back to the NAS. Included with the Access-Accept message is the set of RADIUS attributes for the restrictions on the connection. In addition, an authentication success event is logged in either the system event log or the IAS authentication log, depending on the configured logging settings.

The authentication and authorization process for the Routing and Remote Access service, when configured for Windows authentication, requires steps 6 through 15 of this process. The authentication and authorization success and failure are the return values of functions called by the Routing and Remote Access service. Local event or authentication logging depends on the configured logging settings of the Routing and Remote Access service.

Using IAS as a RADIUS Proxy

When you use IAS as a RADIUS proxy, Access-Request messages are forwarded to a remote RADIUS server for authentication and authorization.

If you configure the IAS proxy to map user accounts between a remote RADIUS server and the local user accounts database, Access-Request messages are authenticated by the remote server and are authorized with the user or computer account dial-in properties and remote access policies that are configured on the IAS proxy.

IAS can also 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) and forwarded to another RADIUS server for accounting.

You can use IAS as a RADIUS proxy when the following conditions exist:

• 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 untrusted 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 NASs 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 Microsoft Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition. The forest functional level must be Windows Server 2003, and there must be a two-way trust relationship between forests. If you use Extensible Authentication Protocol-Transport Layer Security (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.

• Your user accounts database is not a Windows user accounts database, and it is not compliant with LDAP. Additionally, you are using a non-Microsoft RADIUS server. In this case, the IAS proxy server forwards connection requests that match a specified realm name to a non-Microsoft RADIUS server in a remote RADIUS server group. The remote RADIUS server performs authentication and authorization against the non-Microsoft user accounts database. Examples of non-Microsoft user accounts databases include Novell Directory Services (NDS) and 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.

• You are a service provider that offers outsourced dial, VPN, or wireless network access services to multiple customers. Your NASs 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. .

When you configure IAS as a RADIUS proxy, Access-Request messages are forwarded to a remote RADIUS server and are processed remotely.

When you map external user accounts to a local Windows user account, authentication is performed remotely and authorization is performed locally. In this process, IAS does the following tasks:

1. Validates the RADIUS packet. The incoming Access-Request message is validated for source IP address, the digital signature, valid attributes, and so on. If the RADIUS message is not valid, an event is logged in the system event log and the RADIUS Access-Request message is discarded. An Access-Reject message is not sent.

2. Checks for auto-reject. Auto Reject, also called Ping User-Name, is used to send an immediate Access-Reject message when the User-Name attribute in the Access-Request message matches a specific value.

   Some RADIUS proxy servers and NASs periodically send authentication and accounting requests, also called 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 value of the User-Name attribute in ping requests made by other servers. If the registry entry and the user name value match, IAS rejects the request but does not create an event or accounting log entry.

3. Performs connection request policy evaluation. Connection request policies configured on the IAS server are evaluated to find a policy that matches the parameters of the connection. If a policy is found that matches the connection request, the name of the remote RADIUS server group to which the Access-Request should be forwarded is injected into the message.

   If a matching policy is not found, an Access-Reject message is sent and an event is logged. For more information about connection request policies and policy evaluation logic, see “Connection Request Policies” later in this section.

4. Applies realm stripping rules. IAS determines or defines the domain name and the user identity for the Access-Request message. If the User-Name attribute in the Access-Request message is not the Auto Reject name, then the user identity is determined. User identity is the value that IAS uses to identify the user for the purposes of authentication and authorization. Typically, the user identity is the string value of the User-Name RADIUS attribute. If the User-Name attribute is not present, the user identity is set to the Guest account or the account specified by the Default User Identity registry value.

   IAS can use any RADIUS attribute to identify the user. The RADIUS attribute that IAS uses to identify the user is configurable by setting the User Identity Attribute registry setting.

5. Determines whether to authenticate locally or forward to a remote RADIUS server group. Based on the realm portion of the user name, the IAS proxy determines whether to forward the message or continue to process it locally.

6. Check for authentication plug-ins. The existence of authentication plug-ins is checked. Authentication plug-ins are optional components you can create with the IAS SDK; each plug-in can return Accept, Reject, or Continue. If an authentication plug-in returns an Accept, the user is considered to be authenticated and the account is then validated. If the authentication plug-in returns a Reject, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings. If the authentication plug-in returns a Continue, the next plug-in is checked. If there are no more plug-ins, the user still needs to be authenticated.

   The authentication plug-in can also return RADIUS attributes to be included in the Access-Accept message.

7. Forward the Access-Request to a remote RADIUS server group. IAS creates a RADIUS message, which includes the attributes received from the RADIUS client, with the exception of the proxy state attribute. IAS forwards the message to the remote RADIUS server group specified in the request. When a valid reply is received from the remote server, attributes from the RADIUS packet are merged with the attributes in the request. Attributes returned by the remote RADIUS server are not added if the same attribute has already been added by the connection request policy. In other words, local settings override remote settings.

8. Maps a remote user account to a local Windows account. If the IAS proxy server is configured to map an external user account to a local Windows account, and if the remote RADIUS server has performed authentication and returned an Access-Accept, mapping of the accounts is performed.

   If mapping is not configured, IAS proceeds to number 12 in this process, “Check for authorization plug-ins.” For more information about account mapping, see “Mapping Network Authentication and Authorization” later in this section.

9. Validates user account. Based on the user or computer account that is determined by means of name cracking, the user account is validated to check whether the account is locked out (which is not the same as remote access account lockout), whether the account is disabled, and whether the user account’s password has expired. If the user account is not valid, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings.

10. Performs remote access policy evaluation. Remote access policies configured on the IAS server are evaluated to find a policy that matches the parameters of the connection. If a matching policy is not found, an Access-Reject message is sent and an event is logged.

11. Checks user properties and profile properties. If the Ignore-User-Dialin-Properties attribute is set to 0, the dial-in properties of the user account and the profile properties of the matching remote access policy are evaluated against the parameters of the connection attempt. This is done to ensure that the connection attempt is allowed. If the Ignore-User-Dialin-Properties attribute is set to 1, the profile properties from the matching policy become the set of properties for the connection.

    If the connection attempt is not allowed, an Access-Reject message is sent, and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings.

12. Checks for authorization plug-ins. Authorization plug-ins are optional components created using the IAS SDK. Each plug-in can return either Reject or Continue. If an authorization plug-in is installed and it returns a Reject, an Access-Reject message is sent and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings. If the authorization plug-in returns Continue, the next plug-in is checked. If there are no more plug-ins, the user is authorized.

    An authorization plug-in can also return RADIUS attributes to be included in the Access-Accept message.

13. Sends an Access-Accept. If the dial-in properties of the user account, the profile properties of the matching remote access policy, and the conditions imposed by authorization plug-ins allow the connection attempt, an Access-Accept message is sent back to the NAS. Included with the Access-Accept message is the set of RADIUS attributes for the restrictions on the connection. In addition, an authentication success event is logged in the system event log or the IAS authentication log, depending on the configured logging settings.

IAS as a RADIUS Server

IAS can be used as a RADIUS server to perform AAAA for connection requests at RADIUS clients. A RADIUS client can be either a NAS or a RADIUS proxy. When 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 a Microsoft Windows NT Server 4.0 domain, an Active Directory domain, or the local 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 RADIUS clients send.

• Accounting requests are stored in a local log file or a SQL server database for analysis.

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

1. Access servers, such as dial-up NASs, VPN servers, and wireless APs, receive connection requests from access clients.

2. The access server that is 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. IAS checks the user name for a domain name. If a domain name is specified and IAS is configured to access the user accounts database in the specified domain, IAS proceeds with processing the connection request. 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. IAS resolves a user name without a specified domain name by using the following sequence:

   1. IAS checks the default domain registry key. If a default domain is specified, IAS authenticates the user against the domain specified in the registry key.

   2. If the IAS server is a member of a domain, IAS authenticates the user against the domain to which it is joined.

   3. If the IAS server is not a member of a domain, IAS authenticates the user against the local SAM database.

6. IAS checks the user identity in the User-Name attribute. User identity is what IAS uses to identify the user for the purposes of authentication and authorization. Typically, the user identity is the string value of the User-Name RADIUS attribute. If the User-Name attribute is not present, the user identity is set to the Guest account or the account specified by the Default User Identity registry value.

7. The dial-in properties of the user account are obtained by using a secure connection to a domain controller.

8. The connection attempt is authorized with both the dial-in properties of the user account and remote access policies. If the connection attempt is both authenticated and authorized, the IAS server sends an Access-Accept message to the access server.

9. If the connection attempt is either not authenticated or not authorized, or the connection request parameters do not match a connection request policy and a remote access policy, the IAS server sends an Access-Reject message to the access server.

10. 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 in IAS format, database-compatible format, or to a SQL Server.

11. The IAS server sends an Accounting-Response to the access server.

The access server also sends Accounting-Request messages when the connection is being established, when the access client connection is closed, and when the access server is started and stopped.

IAS Authentication

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.

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 the access client, the access server, and the RADIUS server. 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 v1 , then CHAP, 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 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-MS-CHAP v2, which provides secure password authentication.

Authentication process

A NAS functions as a RADIUS client of an IAS server. The NAS can be a dial-up server, VPN server, wireless AP, or an authenticating switch. When a user or computer attempts to log on to a network through a NAS, the access client sends identity information, such as account credentials, to the access server. The access server sends the credentials to the RADIUS server.

When the NAS passes the account credentials to IAS, IAS authenticates the user or computer by sending the supplied credentials to a domain controller that compares the credentials with the credentials of an account in the accounts database. IAS also verifies that the account is authorized to access all or part of the network by examining properties of the account in Active Directory and by using remote access policies configured on the IAS server.

If the user is authenticated and authorized, IAS returns necessary configuration information to the RADIUS client so that it can deliver service to the user.

When a user or computer attempts to connect to a network, the authentication request is processed as follows:

1. The NAS tries to negotiate a connection with the remote access client by using the most secure protocol first, then the next least secure protocol, and so on, down to the least secure protocol (for example, the NAS tries to negotiate a connection by using EAP, MS-CHAP v2, then MS-CHAP , then CHAP, and finally PAP).

2. The NAS forwards the authentication request to an IAS server in the form of a RADIUS Access-Request message.

3. The IAS server validates the RADIUS Access-Request message.

4. If digital signatures are enabled and the verification of the digital signature fails, the IAS server silently discards the message. When the NAS does not get a response within its time-out period, it retries and then disconnects the user. If the IAS server cannot connect to the domain controller or cannot find the domain controller the user belongs to, it silently discards the message. This allows a RADIUS proxy to retransmit the request to the backup IAS server, which would then attempt to authenticate the user against the database of the domain.

5. If digital signatures are enabled and the verification of the digital signature is successful, the IAS server queries the domain controller, which validates the user credentials.

6. If the user credentials are authentic, the IAS server evaluates the connection attempt against the configured remote access policies and the dial-in properties of the user’s account to decide whether to authorize the request. If the connection attempt matches the conditions of at least one policy and the user account dial-in properties, remote access policy properties, and the remote access policy profile properties authorize the connection, IAS sends a RADIUS Access-Accept message to the NAS that sent the Access-Request message. The Access-Accept message authorizes the connection but also contains connection parameters based on the remote access policy profile settings and the dial-in properties of the user account. The NAS interprets this authorization data to determine the connection parameters that the server has authorized.

If the user is not authentic or the user’s attempt to connect does not match conditions in at least one policy, or matches conditions in a policy that denies access, IAS sends a RADIUS Access-Reject message to the NAS, and the NAS disconnects the user.

Ping User-Name value

The 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 NASs to IAS servers to test whether the IAS server is available. 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.

Adding Ping User-Name to the registry

When you add Ping User-Name to the registry, you must supply values for Name, Type, and Data, as shown in the following table, "Ping User-Name Values."

Ping User-Name Values

Name	Type
ping user-name	REG_SZ	User name

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.

IAS and Tunneling

The entire process of packet encapsulation, transmission, and de-encapsulation is called tunneling. Tunneling 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 logical path in the transit internetwork through which the encapsulated packets travel is called a tunnel.

With remote access VPN connections, there are two types of tunneling: voluntary and compulsory

Voluntary tunneling

When a client computer is configured with the appropriate tunneling protocol, the user or client computer can issue a VPN request to create and configure a voluntary tunnel from the client computer to the VPN server. In this case, the user’s computer is a tunnel endpoint that acts as the tunnel client, and the VPN server is the tunnel server.

A simple example of voluntary tunneling occurs when a user with a dial-up connection to the Internet through an Internet service provider (ISP) connects to an organization VPN server that is also connected to the Internet. In this scenario, the user has two separate accounts, each account having its own set of credentials:

• A set of credentials for an account with an ISP

• A set of credentials for an account with the organization

To connect to the organization VPN server, the client computer uses a dial-up modem to attempt to connect to the ISP dial-up server. The user supplies his ISP account credentials, is authenticated by the ISP RADIUS server against the ISP user accounts database, and is authorized by the ISP RADIUS server to connect to the ISP and the Internet.

After the dial-up connection is established and the client computer is on the Internet, the user initiates a VPN connection to his organization VPN server. The VPN server is configured as a RADIUS client to an IAS server at the organization. The user supplies organization account credentials for the connection attempt, and the organization IAS server uses the credentials to authenticate and authorize the user against an Active Directory user accounts database. After the user is authenticated and authorized, the VPN tunnel is established and the user can access organization resources.

In another example, IAS is used in an outsourced bulk dial scenario for voluntary tunneling. In the outsourced bulk dial scenario, an ISP is providing both dial-up and non-dedicated broadband digital subscriber line (DSL) Internet access for all the employees of an organization. Rather than providing the ISP with a copy of its user accounts database, the organization and the ISP use IAS as a RADIUS proxy so that users, when connecting to the ISP, can be authenticated and authorized using the organization RADIUS servers and Active Directory user accounts database on the organization network. This provides strong security and prevents exposure of sensitive information contained in the user accounts database to the ISP and its employees.

When the organization employee attempts to connect to the organization VPN server, the following process occurs:

1. The client computer establishes the dial-up or DSL connection to the ISP NAS.

2. Based on the connection parameters, the NAS sends an Access-Request message to an IAS server that is configured as a RADIUS proxy.

3. The RADIUS proxy processes the Access-Request message and determines where to send it based on the realm portion of the User-Name attribute. The RADIUS proxy forwards the Access-Request message to the organization IAS server, which is accessible on the Internet through a firewall configured to allow traffic on the default RADIUS UDP ports of 1812 (authentication) and 1813 (accounting).

4. The organization IAS server authenticates and authorizes the connection attempt of the client computer and sends an Access-Accept message back to the RADIUS proxy.

5. The RADIUS proxy forwards the Access-Accept message to the ISP NAS and the ISP NAS connects the client computer to the Internet.

6. After it is on the Internet, the client computer initiates a VPN tunnel connection with the organization VPN tunnel server on the Internet.

7. Based on the tunnel connection parameters, the tunnel server sends an Access-Request message to the organization IAS server.

8. The organization IAS server authenticates and authorizes the connection attempt of the tunnel client and sends an Access-Accept message back to the tunnel server.

9. The tunnel server completes the tunnel creation and the tunnel client can now send packets to the organization intranet through the tunnel across the Internet.

The figure, “Voluntary Tunnel Created by a Dial-Up User,” illustrates the establishment of a voluntary VPN tunnel by a dial-up user.

Voluntary Tunnel Created by a Dial-Up User

Voluntary tunneling is not different from other types of network access, and IAS can be used for authentication, authorization, and accounting when the tunnel server is configured as a RADIUS client to the IAS server.

Compulsory tunneling

Compulsory tunneling is the creation of a secure tunnel by another computer or network device on behalf of the client computer. Compulsory tunnels are configured and created automatically for the user 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, acting as the tunnel client. The dial-up access server dialed by the client computer is the tunnel endpoint, acting as the tunnel client.

A number of vendors that sell dial-up access servers have implemented the ability to create a tunnel on behalf of a dial-up client. The computer or network device providing the tunnel for the client computer is known as a Front End Processor (FEP) in PPTP, a Layer Two Tunneling Protocol (L2TP), an Access Concentrator in L2TP, or an IP Security Gateway in Internet Protocol Security (IPSec).

In this section, “How IAS Works,” the acronym FEP describes this functionality, regardless of the tunneling protocol. To carry out 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.

A corporation can contract with an ISP to deploy a nationwide set of FEPs. These FEPs can establish tunnels across the Internet to a tunnel server connected to the private network of the corporation, thereby consolidating calls from geographically diverse locations into a single Internet connection at the corporate network.

The following figure, “Compulsory Tunnel Created by a Tunneling-Enabled NAS,” shows the client computer placing a dial-up call to a tunneling-enabled NAS at the ISP to authenticate against an IAS server on the other side of the tunnel.

Compulsory Tunnel Created by a Tunneling-Enabled NAS

The preceding figure, “Compulsory Tunnel Created by a Tunneling-Enabled NAS,” illustrates how IAS is used in an outsourced bulk dial scenario for compulsory tunneling.

In the outsourced bulk-dial scenario, a dial-up client establishes a dial-up connection to an ISP that is providing tunneled access across the Internet for all the employees of an organization. Based on the dial-up connection parameters, the ISP NAS sends an Access-Request message to an IAS server. The ISP IAS server authorizes, but does not authenticate, the tunnel connection. The ISP IAS server sends an Access-Accept message to the ISP NAS with a series of VPN tunnel attributes. The ISP NAS then acts as a tunnel client and creates a VPN tunnel to the VPN tunnel server of the organization that faces the Internet.

Note

• Typically, IAS provides both authentication and authorization. However, it is common for the ISP IAS server to provide only authorization when the dial-in user is authenticated by the organization IAS server.

The ISP NAS then sends a PPP message to the dial-up client to restart the authentication process so that the dial-up user can be authenticated by the organization IAS server through the tunnel. The dial-up client sends the authentication information to the ISP NAS, which encapsulates the user account credentials and sends them through the tunnel to the organization tunnel server.

After the user account credentials are received by the tunnel server, the tunnel server sends an Access-Request message to the organization IAS server. The organization IAS server authenticates and authorizes the connection of the dial-up client to the tunnel server and sends an Access-Accept message to the tunnel server. The tunnel server then completes the connection to the dial-up client.

All data that is sent by the dial-up client is automatically sent through the tunnel to the tunnel server by the ISP NAS.

This configuration is known as compulsory tunneling because the client is compelled to use the tunnel created by the FEP. After the initial connection is made, all network traffic to and from the client is automatically sent through the tunnel.

In addition, you can configure IAS to instruct an FEP to tunnel different remote access clients to different tunnel servers.

Unlike the separate tunnels created for each voluntary client, a compulsory tunnel between the FEP and organization VPN server can be shared by multiple dial-up clients. When a second client dials into the same access server (the FEP) to reach a destination for which a tunnel already exists, the data traffic for the new client is carried over the existing VPN tunnel.

The following RADIUS Attributes are used to carry the tunneling information from the IAS server to the NAS.

Used in authorization only:

• Tunnel-Pvt-Group-ID

• Tunnel-Assignment-ID

• Tunnel-Preference

• Tunnel-Password

• Tunnel-Client-Auth-ID

• Tunnel-Server-Auth-ID

Used in authorization and accounting:

• Tunnel-Type (such as PPTP and L2TP)

• Tunnel-Medium-Type (X.25, ATM, Frame Relay, IP, and so on)

• Tunnel-Client-Endpt

• Tunnel-Server-Endpt

Used for accounting only:

• Acct-Tunnel-Connection

The Windows Server 2003 or Windows 2000 Routing and Remote Access service cannot be used as a FEP for compulsory tunneling.

Authentication Methods

The RADIUS protocol supports several PPP authentication protocols, each with its advantages and disadvantages in terms of security, usability, and breadth of support. The protocol used is determined by the configuration of the NAS device. For information about support for the various authentication protocols, see your NAS documentation, or consult your ISP or other vendor support.

The following sections focus on the advantages and disadvantages of the authentication protocols that are currently supported by IAS, and discuss how to deploy certificate-based authentication methods. The information is also useful in configuring a particular authentication method for network access authentication.

PAP

Password Authentication Protocol (PAP) sends a password as a plaintext string from the user’s computer to the NAS device. When the NAS forwards the password as the User-Password attribute in the Access-Request message, it is encrypted using the RADIUS shared secret as an encryption key. PAP is the most flexible protocol because passing a plaintext password to the authentication server enables that server to compare the password with nearly any storage format. For example, UNIX passwords are stored as one-way encrypted strings that cannot be decrypted. PAP passwords can be compared to these strings by reproducing the one-way encryption method.

Note

• The use of this authentication method is not recommended for security reasons.

When PAP is enabled as an authentication protocol, user passwords are sent from a client to a NAS in plaintext form. The NAS encrypts the password, using the shared secret, and then sends it in an Access-Request message. Because a RADIUS proxy must encrypt the PAP password by using the shared secret of its forwarding RADIUS server, a RADIUS proxy must decrypt the PAP password, using the shared secret between the RADIUS proxy and the NAS. Because it uses a plaintext version of the password, PAP has a number of security vulnerabilities. Although the RADIUS protocol encrypts the password, it is transmitted as plaintext across the dial-up connection.

PAP-based authentication is enabled:

• On the appropriate remote access policy. PAP is disabled by default.

• On a remote access client.

• As an authentication protocol on the remote access server. For the Routing and Remote Access service, PAP is disabled by default.

For information about a default setting on a particular NAS, see your NAS documentation.

If you set the User passwords to be changed at the next attempt to log on option, users must first log on using a local area network (LAN) connection and change the password before attempting to log on with a remote access connection using PAP. PAP and CHAP do not support changing passwords during the authentication process. If the password is not first changed using a LAN connection, logon fails. An alternative method for changing passwords is to temporarily log on using MS-CHAP to change the password.

Note

• A malicious user or process on a RADIUS proxy can record user names and passwords for PAP connections while the password is in its plaintext form. For this reason, the use of PAP is highly discouraged, especially for virtual private network connections.

CHAP

Challenge Handshake Authentication Protocol (CHAP) is designed to address the concern of passing passwords in plaintext. By using CHAP, the NAS sends a random number challenge to the user’s computer. The challenge and the user’s password is then hashed by using Message Digest 5 (MD5). The client computer then sends the hash as a response to the NAS challenge and the NAS forwards both the challenge and response in the RADIUS Access-Request message.

When the authenticating server receives the RADIUS message, it uses the challenge and the user’s password to create its own version of the response. If the version of the server matches the response supplied by the user’s computer, the access request is accepted.

CHAP responses cannot be reused because NAS devices send a unique challenge each time a client computer connects to them. Because the algorithm for calculating CHAP responses is well known, it is very important that passwords be carefully chosen and sufficiently long. CHAP passwords that are common words or names are vulnerable to dictionary attacks if they can be discovered by comparing responses to the CHAP challenge with every entry in a dictionary. Passwords that are not sufficiently long can be discovered by brute force by comparing the CHAP response to sequential trials until a match to the user’s response is found.

Historically, CHAP is the most common dial-up authentication protocol used. When the server does not store the same password that was used to calculate the CHAP response, it cannot calculate an equivalent response. Because standard CHAP clients use the plaintext version of the password to create the CHAP challenge response, passwords must be stored in a reversibly encrypted form on the server to validate the CHAP response of the client.

Although the IAS server supports CHAP, a Windows NT 4.0–based domain controller cannot validate CHAP requests without support for storing reversibly encrypted passwords. This support is available in Windows Server 2003 and Windows 2000; in Windows NT 4.0, this support is available after installing Service Pack 3 or later.

CHAP-based authentication is enabled when you have done the following:

• Enabled CHAP on the appropriate remote access policy. CHAP is disabled by default.

• Enabled storage of a reversibly encrypted form of the user’s password. For a stand-alone server, use computer Group Policy to enable storage of reversibly encrypted passwords for all users of the computer. For Active Directory domains, Group Policy at the domain or Organizational Unit (OU) level can be used.

• Forced a reset of users' passwords so that the new password is in a reversibly encrypted form. When you enable passwords to be stored in a reversibly encrypted form, the current passwords are in a non-reversibly encrypted form and are not automatically changed. You must either reset user passwords or set user passwords to be changed the next time you log on. After the password is changed, it is stored in a reversibly encrypted form.

• Enabled CHAP on the remote access client.

• Enabled CHAP as an authentication protocol on the remote access server. For the Routing and Remote Access service, CHAP is disabled by default.

For information about a default setting on a particular NAS, see your NAS documentation.

If you set the User passwords to be changed at the next attempt to log on option, the user must first log on using a LAN connection and change the password before attempting to log on with a remote access connection using CHAP. CHAP and PAP do not support changing passwords during the authentication process. If the password is not first changed by using a LAN connection, logon fails. As an alternative to this method for changing passwords, you can temporarily log on by using MS-CHAP to change the password.

MS-CHAP v1

MS-CHAP v1, is a variant of CHAP that does not require a plaintext version of the password on the authenticating server. In MS-CHAP v1, the challenge response is calculated with a hashed version of the password and the NAS challenge. This enables authentication over the Internet to a Windows Server 2003 or Windows 2000 domain controller.

Note

• The use of this authentication method is not recommended for security reasons.

MS-CHAP v1 passwords are stored more securely at the server but have the same vulnerabilities to dictionary and brute force attacks as CHAP. If you deploy MS-CHAP v1, use strong passwords for all user accounts. A strong password includes the following:

• Has at least seven characters.

• Does not contain your user name, real name, or company name.

• Does not contain a complete dictionary word.

• Is significantly different from previous passwords. Incremental passwords (Password1, Password2, Password3) are not strong.

• Contains characters from each of the following four groups: uppercase letters, lowercase letters, numerals, and symbols.

With MS-CHAP v1 in Windows Server 2003, users are prompted to change their password before it expires. In addition, you can configure MS-CHAP v1 on the profile of a remote access policy by using the Allow user to change password after it has expired check box to allow or prevent users from changing a password after it has expired.

Note

• If the Allow user to change password after it has expired check box is disabled, and a user’s password expires, the user is denied access and cannot change the password to regain network access.

MS-CHAP v1 is enabled as follows :

• As an authentication protocol on the remote access server. MS-CHAP v 1 is not enabled by default on the Routing and Remote Access service. For information about default settings on other NASs, see your NAS documentation.

• On the appropriate remote access policy. MS-CHAP v 1 is not enabled by default.

• On a remote access client.

By default, MS-CHAP v1 for Windows Server 2003 does not support LAN Manager authentication. This is a change from Windows 2000.

If you want to enable the use of LAN Manager authentication with MS-CHAP v1 for older operating systems, such as Microsoft Windows NT 3.5x and Microsoft Windows 95, you must change the value of Allow LM Authentication in the Windows registry.

MS-CHAP v2

Microsoft CHAP v2 (MS-CHAP v2) provides mutual authentication, stronger initial data encryption keys, and different encryption keys for sending and receiving. For VPN connections, Windows Server 2003 offers MS-CHAP v 2 before offering MS-CHAP v1. Windows clients that have been updated with the most recent service pack accept MS-CHAP v2 when it is offered.

MS-CHAP v2 is a one-way encrypted password, mutual authentication process that works as follows:

1. The remote access server sends a challenge to the remote access client that consists of a session identifier and an arbitrary challenge string.

2. The remote access client sends a response that contains the following:

   • The user name.

   • An arbitrary peer challenge string.

   • A one-way encryption of the received challenge string, the peer challenge string, the session identifier, and the user’s password.

3. The remote access server checks the response from the client and sends back a response containing:

   • An indication of the success or failure of the connection attempt.

   • An authenticated response based on the sent challenge string, the peer challenge string, the encrypted response of the client, and the encrypted version of the user’s password.

4. The remote access client verifies the authentication response and, if correct, uses the connection. If the authentication response is not correct, the remote access client terminates the connection.

5. If a user authenticates by using MS-CHAP v2 and attempts to use an expired password, MS-CHAP prompts the user to change the password while connecting to the server. Other authentication protocols do not support this feature effectively locking out the user who used the expired password. New to Windows Server 2003 is the ability to prevent a user from changing their expired password using MS-CHAP v2 by clearing the Allow user to change password after it has expired check box, under the Microsoft Encrypted Authentication version 2 (MS-CHAP v2) check box on the Authentication tab on the profile of a remote access policy.

MS-CHAP v2 is enabled as follows:

• As an authentication protocol on the remote access server. MS-CHAP v2 is enabled by default on the Routing and Remote Access service. For information about default settings on other NASs, see your NAS documentation.

• On the appropriate remote access policy. MS-CHAP v2 is enabled by default.

• On the remote access client.

For information about default settings on other NASs, see your NAS documentation.

Note

• Note Windows 95 and Microsoft Windows 98 support MS-CHAP v2 only for VPN connections. Windows 95 and Windows 98 do not support MS-CHAP v2 for dial-up connections.

EAP

Extensible Authentication Protocol (EAP) is an extension to PPP that works with dial-up, PPTP, L2TP, and 802.1X authentication clients. EAP allows the addition of new authentication methods known as EAP types. Both the access client and the remote access server must support the same EAP type for successful authentication to occur.

Windows Server 2003 includes an EAP infrastructure and two EAP types, EAP-MD5 and EAP-TLS. The IAS proxy implementation in Windows Server 2003 can forward EAP messages to a RADIUS server.

When you configure EAP as an authentication method in a remote access policy on an IAS server, NASs configured with RADIUS authentication can pass EAP messages from access clients to the IAS server or proxy using the RADIUS protocol. The EAP messages sent between the access client and access server are encapsulated and formatted as RADIUS messages between the remote access server and the RADIUS server.

One advantage of EAP is that EAP types do not need to be installed at each NAS, only at the RADIUS server. In a typical use of EAP, a NAS is configured to use EAP and to use RADIUS as its authentication provider. When a connection is made, the network access client negotiates the use of EAP with the NAS. When the client sends an EAP message to the NAS, the NAS encapsulates the EAP message as a RADIUS message and sends it to its configured RADIUS server. The RADIUS server processes the message and sends a RADIUS-encapsulated EAP message back to the NAS. The NAS then forwards the EAP message to the network access client. In this configuration, the NAS is only a pass-through device. All processing of EAP messages occurs at the network access client and the RADIUS server.

EAP-MD5

MD5 with CHAP (EAP-MD5) is a required EAP type that uses the same challenge-handshake protocol as PPP-based CHAP, but the challenges and responses are sent as EAP messages. A typical use for EAP-MD5 is to authenticate the credentials of remote access clients by using user name and password security systems. You can use EAP-MD5 to test EAP interoperability.

EAP-TLS

Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) is an EAP type that is used in certificate-based security environments. To use smart cards for remote access authentication, you can deploy a PKI with Certificate Services in Windows Server 2003 or with a non-Microsoft certification authority, and then configure the EAP-TLS authentication method in remote access policies on your IAS servers. The EAP-TLS exchange of messages provides mutual authentication, negotiation of the encryption method, and secured private key exchange between the network access client and the IAS server. EAP-TLS provides the strongest authentication and key exchange method.

Use of the TLS authentication type with EAP (EAP-TLS) reduces latency for authentication requests because, during the first authentication attempt, TLS caches certificate properties on the access client and on the IAS server. For subsequent authentication attempts, TLS uses the cached certificate properties instead of reading the certificate from the certificate store on the IAS server or client computer. In addition, the load on the IAS server that is typically caused by processing certificates is greatly reduced, improving server performance. Improved performance and response time are especially useful for wireless networks because the wireless client frequently authenticates to the network when moved from one AP to another.

EAP-TLS also supports computer authentication by using the computer account and computer certificate (also called machine certificate). For computer authentication with EAP-TLS, you must install a computer certificate on the client computer. This certificate is used to authenticate the client computer so that the computer can obtain network connectivity and Group Policy updates prior to user login. For user authentication with EAP-TLS, after a network connection is made and the user logs in, a user certificate on the client computer is necessary.

The computer certificate is installed on the IAS server computer so that during EAP-TLS authentication, the IAS server has a certificate to send to the client computer for mutual authentication, regardless of whether the client computer authenticates with a computer certificate or a user certificate. The computer and user-certificates that are submitted by the access client and the IAS server during EAP-TLS authentication, must conform to specified requirements. For more information about these requirements, see “Using Certificate-Based Authentication Methods” later in this section.

Deploying EAP

When you configure a remote access policy with EAP, 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.

EAP-TLS is not supported if the IAS server is not a member of the domain.

Note

• When deploying EAP-TLS, 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 dialog box, on the Subject Name tab, in Subject name format, select a value other than None.

EAP-based authentication is enabled when:

• EAP is enabled as an authentication protocol on the NAS.

• EAP is enabled on the IAS server and configure the EAP type on the appropriate remote access policy.

• EAP is enabled and configure EAP on a network access client.

In addition to the EAP types defined and supported in Windows Server 2003, you can include new EAP authentication methods by using the EAP Software Development Kit.

Note

• When using EAP-TLS on computers running Microsoft Windows XP (prior to Service Pack 1), you must have user certificates stored on the computer for user authentication (instead of using smart cards). For computers running Windows Server 2003, Windows XP (Service Pack 1 or later), or Windows 2000, you can use either user certificates stored on the computer or a smart card for user authentication.

Protected Extensible Authentication Protocol

Protected Extensible Authentication Protocol (PEAP) is a new member of the family of EAP authentication methods. PEAP uses TLS to create an encrypted channel between an authenticating PEAP client, such as a wireless client computer, and a PEAP authenticator, such as an IAS server. PEAP does not specify an authentication type. Instead, it provides additional security for other EAP authentication protocols, such as MS-CHAP v2, which can operate within the TLS encrypted channel provided by PEAP. PEAP is used as an authentication method for 802.1X connections, such as 802.11 wireless connections and authenticating switches. PEAP is not supported for VPN or other remote access clients.

To use PEAP in your environment with Windows Server 2003, IAS requires little infrastructure change. If your wireless APs support 802.1X and EAP, then you can use PEAP without any additional changes to your wireless APs. In addition, PEAP is available for Microsoft Windows XP, Service Pack 1 and later; Windows 2000, Service Pack 4; and Pocket PC 2002.

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

• 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 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 that can authenticate the IAS or RADIUS server. Because the server also authenticates the client, mutual authentication occurs.

• Support for computer authentication using the client computer account and computer certificate.

• Protection against the deployment of an unauthorized wireless access point (AP) or authenticating switch 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 server. Because of this, the access server cannot decrypt the messages protected by PEAP.

• PEAP fast reconnect reduces the latency for authentication requests and responses between an access client and the IAS server when the access client moves from one AP to another. The IAS server caches a portion of the access client credentials and uses these cached credentials to quickly authorize the connection after the client is associated with a new AP.

PEAP authentication process

There are two stages in the PEAP authentication process. The first stage establishes a secure channel between the EAP client and the IAS server. The second stage provides EAP authentication between the EAP client and the IAS server. The following example describes the two stage PEAP authentication process for wireless clients:

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 AP. If Shared Key Authentication is configured for use at the AP, then 802.1X is not used. If the AP is configured for Open System Authentication, 802.1X is used. After the IEEE 802.11-based association is successfully established between the client and AP, the TLS session is negotiated with the RADIUS server. The key that is derived during this negotiation is used to encrypt all subsequent communication, and the TLS encrypted channel is established.

EAP-authenticated communication

An EAP negotiation in which the wireless client authenticates to the IAS server occurs through the TLS channel. The IAS server authenticates the user or client computer with the method that is determined by the EAP type and selected for use within PEAP (either TLS or MS-CHAP v2). The AP only forwards messages between wireless client and RADIUS server. The AP (or person monitoring the AP) cannot decrypt these messages because the AP is not the TLS endpoint.MS-CHAP v2

802.11 wireless deployments using PEAP

You can choose either of these two EAP types to use with PEAP: MS-CHAP v2 or TLS.

MS-CHAP v2 uses credentials (user name and password) for user authentication, and a certificate in the server computer certificate store for server authentication.

TLS uses either certificates installed in the client computer certificate store or a smart card to authenticate a user or client computer, and a certificate in the server computer certificate store for server authentication.

PEAP with EAP-MS-CHAP v2

PEAP with EAP-MS-CHAP v2 (PEAP-MS-CHAP v2) 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 server is required to have a certificate. Additionally, the server certificate can be issued by a public CA that is trusted by the client computer, meaning that the public CA certificate already exists in the Trusted Root Certification Authority folder in 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-MS-CHAP v2 provides improved security over MS-CHAP v2 by using mutual authentication, by preventing an unauthorized server from negotiating the least secure authentication method, and by providing key generation with TLS. PEAP-MS-CHAP v2 requires that the client trust the certificates provided by the server.

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-TLS) uses certificates for server authentication and either certificates or smart cards for user and client computer authentication. To use PEAP-TLS, you must deploy a PKI.

PEAP-TLS also supports computer authentication by using the computer account and computer certificate. For computer authentication with PEAP-TLS, you must install a computer certificate, on the client computer. A computer certificate installed on the client computer is used to authenticate the client computer so that the computer can obtain network connectivity and Group Policy updates prior to user login. For user authentication with PEAP-TLS after a network connection is made and the user logs in, a user certificate on the client computer is necessary.

The computer certificate is installed on the IAS server computer so that during PEAP-TLS authentication, the IAS server has a certificate to send to the client computer for mutual authentication, regardless of whether the client computer authenticates with a computer certificate or a user certificate. The computer and user certificates submitted by the access client and the IAS server during PEAP-TLS authentication must conform to the requirements specified in the section "Using Certificate-Based Authentication Methods."

TLS caching of certificate properties

When using the PEAP-TLS and EAP-TLS authentication methods with certificates, TLS uses cached certificate properties instead of reading the certificate from the certificate store on the IAS server.

If a certificate is deleted, its TLS credential cache entry is removed. If a certificate is renewed, its TLS credential cache entry is removed and TLS caches properties for the renewed certificate. If a certificate expires, 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.

Deploying PEAP

PEAP is used as an authentication method for 802.1X-based connections and is not supported for VPN or other remote access clients. When you deploy both PEAP and EAP unprotected by PEAP on the same network, do not use the same authentication type (MS-CHAP v2 or TLS) with and without PEAP.

For example, if you deploy PEAP with EAP-TLS (PEAP-TLS), do not also deploy EAP-TLS without PEAP. Deploying authentication methods with the same type — one with and the other without external protection of PEAP or IPSec — creates a security issue.

If you need to deploy both PEAP and EAP on the same network, use different authentication types for each deployment.

An example of a deployment of both authentication methods that does not introduce a security issue is to use PEAP-MS-CHAP v2 for secure password authentication for wireless clients while using EAP-TLS as the authentication method for remote access clients using VPN connections. For this configuration, two remote access policies are configured at the IAS server, one for wireless clients and one for VPN clients, with the appropriate authentication method and type configured for each policy.

PEAP fast reconnect

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

Wireless APs are configured as RADIUS clients to RADIUS servers. If a wireless client roams between APs that are configured as clients of the same RADIUS server, the client is not required to be authenticated with each new association.

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 TLS handle of the new PEAP authenticator is cached by the client. The client can cache TLS handles for multiple PEAP authenticators. For smart cards or PEAP-MS-CHAP v2 authentication, the user is asked to supply the personal identification number (PIN) or credentials, respectively.

The following tables, PEAP-MS-CHAP v2 and “PEAP-TLS” describe authentication behavior with PEAP-MS-CHAP v2 and PEAP-TLS when wireless clients roam from one wireless AP to a new AP. PEAP authentication behavior differs when wireless APs are configured either as clients to the same RADIUS server or as clients to different RADIUS servers.

PEAP-MS-CHAP v2

New AP Is RADIUS Client to Same RADIUS Server	New AP Is RADIUS Client to a Different RADIUS Server
The user is not prompted for credentials each time the client computer associates with a new AP.	The user is prompted for credentials on this initial association. By default, the domain credentials of the currently logged in user are sent automatically. The next time the client computer associates with an AP 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 AP that is a client to this server, the server is not required to be reauthenticated.

PEAP-TLS

New AP is RADIUS Client to Same RADIUS Server	New AP Is RADIUS Client to a Different RADIUS Server
The wireless client and RADIUS server are not required to exchange certificates.	The wireless client and RADIUS server exchange certificates on this initial association. The next time the client computer associates with an AP that is a RADIUS client to this RADIUS server, certificates are not exchanged.
The user is not prompted for a smart card PIN each time the wireless client computer associates with a new AP.	The user is prompted for a smart card PIN on this initial association. The next time the client computer associates with an AP that is a RADIUS client to this RADIUS server, the user is not prompted for the PIN. When the TLS cache expires, the user is prompted to reenter the PIN.

PEAP fast reconnect requires the following:

• Both the PEAP client (802.11 wireless client) and PEAP authenticator (RADIUS server) must have fast reconnect enabled.

• All APs 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 APs 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 AP cannot be configured to prefer a RADIUS server, you can configure an IAS RADIUS proxy with a preferred RADIUS server.

PEAP-based authentication is enabled when:

• You install a certificate on the IAS server that meets the minimum server certificate requirements.

• You configure PEAP as the authentication method for a remote access policy on your IAS server.

• You enable and configure PEAP on a remote access client.

Using Certificate-Based Authentication Methods

Certificates are used for network access authentication because they provide strong security for authenticating users and computers and eliminate the need for less secure password-based authentication methods.

Two authentication methods use certificates: EAP-TLS and PEAP. Both methods always use certificates for server authentication, and both the remote access client and the IAS server are TLS endpoints during the authentication process, providing strong security.

Depending on the authentication type configured with the authentication method, certificates might also be used for user authentication and client computer authentication. Certificates are stored in one of two places: either in the computer or user certificate store, or embedded in a computer chip on a smart card. If you deploy EAP-TLS, user authentication can be performed by using either a smart card or a certificate in the Current User certificate store on the client computer. If you deploy PEAP-TLS, the same is true. If you deploy PEAP-MS-CHAP v2, certificates are not used on the client computer; the user supplies password-based credentials when logging on to the network.

You can configure remote access policies in IAS to use EAP-TLS to perform certificate-based authentication for many types of network access, including VPN and wireless connections. In addition, you can use PEAP as the authentication method for wireless or wired 802.1X connections.

To deploy certificates to users and computers, you must first do the following:

• Design a PKI.

• Deploy a CA by using Certificate Services or by using a third party certification authority.

• Design and publish one or more certificates using Certificate Templates, which are installed with Certificate Services.

• Select one or more distribution methods (also called certificate enrollment methods) to install the certificates on computers and distribute them to users.

If you deploy PEAP-MS-CHAP v2 for wireless clients, you can use a non-Microsoft CA to obtain a server certificate.

Because user authentication is accomplished with password-based credentials with PEAP-MS-CHAP v2, you do not need to deploy a PKI or a CA on your network, however the server certificate you obtain from a third party CA must conform to server certificate requirements.

All certificates that are used for network access authentication must meet the requirements for X.509 certificates and work for connections that use Secure Sockets Layer-Transport Layer Security (SSL/TLS). After this minimum requirement is met, both server and client certificates must meet the additional requirements listed in the “Server certificate requirements” section.

Server certificate requirements

You can configure clients to validate server certificates by using the Validate server certificate option. Using PEAP-MS-CHAP v2, PEAP-TLS, or EAP-TLS as the authentication method, the client accepts the authentication attempt of the server when the certificate meets the following requirements:

• The Subject name contains a value. If you issue a certificate to your IAS server that has a blank Subject, the certificate is not available to authenticate your IAS server.

• The computer certificate on the server chains to a trusted root CA and does not fail any of the checks that are performed by CryptoAPI.

• The IAS or VPN server computer certificate is configured with the Server Authentication purpose in Enhanced Key Usage (EKU) extensions (the object identifier for Server Authentication is 1.3.6.1.5.5.7.3.1).

• The server certificate is configured with a required cryptographic service provider (CSP) value of Microsoft RSA SChannel Cryptographic Provider.

• The Subject Alternative Name (SubjectAltName) extension, if used, must contain the DNS name of the server. With PEAP and EAP-TLS, servers display a list of all installed certificates in the computer’s certificate store, with the following exceptions:

  • Certificates that do not contain the Server Authentication purpose in EKU extensions are not displayed.

  • Certificates that do not contain a Subject name are not displayed.

  • Servers do not display registry-based and smart card-logon certificates.

Note

• You can designate which certificate is used by the IAS or VPN server in the remote access policy profile. When you configure EAP and PEAP authentication methods that require a certificate for server authentication and you do not select a specific certificate in the Smart Card or other Certificate Properties dialog box, the IAS or VPN server automatically selects a certificate from the computer certificate store. If the server obtains a newer certificate, it uses the new certificate. This might cause the IAS or VPN server to use a certificate that is not correctly configured for authentication, causing authentication to fail as the result. To prevent this, always manually select a server certificate when configuring PEAP and EAP authentication methods that require one.

Client certificate requirements

With EAP-TLS or PEAP-TLS, the server accepts the client authentication attempt when the certificate meets the following requirements:

• The client certificate is issued by an enterprise CA or mapped to a user or computer account in Active Directory.

• The user or computer certificate on the client chains to a trusted root CA, includes the Client Authentication purpose in EKU extensions (the object identifier for Client Authentication is 1.3.6.1.5.5.7.3.2), and fails neither the checks that are performed by CryptoAPI and specified in the remote access policy nor the Certificate object identifier checks that are specified in IAS remote access policy.

• The 802.1X client does not use registry-based certificates that are either smart card-logon or password-protected certificates.

• For user certificates, the Subject Alternative Name (SubjectAltName) extension in the certificate contains the user principal name (UPN).

• For computer certificates, the Subject Alternative Name (SubjectAltName) extension in the certificate must contain the fully qualified domain name (FQDN) of the client, which is also called the DNS name. With PEAP-TLS and EAP-TLS, clients display a list of all installed certificates in the Certificates snap-in with the following exceptions:

  • Wireless clients do not display registry-based and smart card-logon certificates.

  • Wireless clients and VPN clients do not display password-protected certificates.

  • Certificates that do not contain the Client Authentication purpose in EKU extensions are not displayed.

Certificate enrollment methods and domain membership

The domain membership of computers for which you want to enroll certificates affects the certificate enrollment method that you can choose. Certificates for domain member computers can be enrolled automatically (also known as auto-enrollment), while an administrator must enroll certificates for non-domain member computers using the CA Web enrollment pages or a floppy disk. The certificate enrollment method for non-domain member computers is known as a trust bootstrap process, through which certificates are created and then manually requested or distributed securely by administrators, providing administrators the ability to build common trust between non-domain member computers and the domain.

Domain member certificate enrollment

If your VPN server, IAS server, or client running Windows 2000 or Windows XP Professional is a member of a domain running Windows Server 2003 and Active Directory, you can configure the auto-enrollment of computer and user certificates through Group Policy. After auto-enrollment is configured and enabled, all domain member computers receive computer certificates the next time Group Policy is refreshed whether the refresh is triggered manually by using the gpupdate command or automatically when logging on to the domain.

If your computer is a member of a domain where Active Directory is not installed, you can install computer certificates manually by requesting them through the Certificates snap-in.

Note

• Computers running Windows 2000 can auto-enroll computer certificates only.

Non-domain member certificate enrollment

Certificate enrollment for computers that are not domain members cannot be done with auto-enrollment. When a computer is joined to a domain, a trust is established that allows auto-enrollment to occur without administrator intervention. When a computer is not joined to a domain, trust is not established and a certificate is not issued. Trust must be established using one of the following methods:

• An administrator (who is, by definition, trusted) must request a computer or user certificate by using the CA Web enrollment tool.

• An administrator must save a computer or user certificate to a floppy disk and install it on the non-domain member computer. Or, when the computer is not accessible to the administrator (for example, a home computer connecting to an organization network by means of an L2TP/IPSec VPN connection), a domain user whom the administrator trusts can install the certificate.

• An administrator can distribute a user certificate on a smart card issued to a user (computer certificates are not distributed on smart cards).

Many network infrastructures contain VPN and IAS servers that are not domain members. For example, a VPN server in a perimeter network might not be a domain member for security purposes. In this case, a computer certificate with the Server Authentication purpose contained in the EKU extensions must be installed on the non-domain member VPN server before it can successfully negotiate L2TP/IPSec-based VPN connections with clients. Note that if the non-domain member VPN server is used as an endpoint for a VPN connection with another VPN server, EKU extensions must contain both the Server Authentication and Client Authentication purposes.

Choosing certificate templates and certificate enrollment methods

Windows Server 2003, Standard Edition, provides different certificate templates from Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition.

If you run an enterprise CA on a computer that runs Windows Server 2003, Standard Edition, you can use the following table, “Certificate Use for Windows Server 2003, Standard Edition,” to determine the following: the best certificate templates; the certificate purposes configured in the EKU extensions of the certificate; and the certificate enrollment method for your requirements.

Certificate Use for Windows Server 2003, Standard Edition

Object and Domain Membership	Certificate Template	Certificate Purposes	Preferred Certificate Enrollment Method	Alternate Certificate Enrollment Method
VPN or IAS server, domain member	Computer	Server Authentication	Auto-enrollment	Request a certificate with the Certificates snap-in
VPN server with site-to-site connection, domain member	Computer	Server Authentication and Client Authentication	Auto-enrollment	Request a certificate with the Certificates snap-in
Windows XP Professional client, domain member	Computer	Client Authentication	Auto-enrollment	Request a certificate with the Certificates snap-in
VPN or IAS server, non-domain member	Computer	Server Authentication	CA Web enrollment tool	Install from a floppy disk
VPN server with site-to-site connection, non-domain member	Computer	Server Authentication and Client Authentication	CA Web enrollment tool	Install from a floppy disk
Windows XP Professional client, non-domain member	Computer	Client Authentication	CA Web enrollment tool	Install from a floppy disk
User, domain user	User	Client Authentication	Auto-enrollment	Use a smart card or the CA Web enrollment tool

If you are running an enterprise CA on a computer running Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; the 64-bit of Windows Server 2003, Enterprise Edition; or the 64-bit version of Windows Server 2003, Datacenter Edition, you can use the following table, “Certificate Use for Other Versions of Windows Server 2003,” to determine the best certificate templates and certificate enrollment method for your requirements.

Certificate Use for Other Versions of Windows Server 2003

Object and Domain Membership	Certificate Template	Certificate Purpose	Preferred Certificate Enrollment Method	Alternate Certificate Enrollment Method
VPN or IAS server, domain member	RAS and IAS Server	Server Authentication	Auto-enrollment	Request a certificate with the Certificates snap-in
Windows XP Professional client, domain member	Workstation Authentication	Client Authentication	Auto-enrollment	Request a certificate with the Certificates snap-in
VPN or IAS server, non-domain member	RAS and IAS Server	Server Authentication	CA Web enrollment tool	Install from a floppy disk
Windows XP Professional client, non-domain member	Workstation Authentication	Client Authentication	CA Web enrollment tool	Install from a floppy disk

Note

• If your server running IAS is not a domain controller but is a member of a domain with a Windows 2000 mixed functional level, you must add the server to the access control list (ACL) of the RAS and IAS Server certificate template. You must also configure the correct permissions for auto-enrollment. There are different procedures for adding single servers and groups of servers to the ACL.

You can add an individual server to the ACL for the RAS and IAS Server certificate template by doing the following: In Certificate Templates, select the template RAS and IAS Server, and then add the IAS server to the template Security properties. For more information, see "To allow subjects to request a certificate that is based on the template" in Help and Support Center for Windows Server 2003. After you add your IAS server to the ACL, grant Read, Enroll, and Auto-enroll permissions.

You can manage a group of servers by adding the servers to a new global or universal group, and then adding the group to the ACL of the certificate template:

1. In Active Directory Users and Computers, create a new global or universal group for IAS servers. Next, add to the group all computers that are IAS servers, are not domain controllers, and are members of a domain with a Windows 2000 mixed functional level.

2. In Certificate Templates, select the RAS and IAS Server template, and then add the group you created to the template Security properties by completing the steps.

After you add your new group, grant Read, Enroll, and Auto-enroll permissions.

Unauthenticated Access

The unauthenticated access method allows remote access users to log on without having their identity verified by IAS. For example, IAS does not verify the user’s name and password against an account in Active Directory when unauthenticated access is enabled. The only user validation performed with the unauthenticated access method is authorization to verify that the user has permission to access the network.

Enabling unauthenticated access presents security risks that you must carefully consider to determine whether to enable this authentication method. Three scenarios that illustrate typical security considerations for unauthenticated access include the following: Guest Access; Dialed Number Identification Service (DNIS) authorization; and Automatic Number Identification/Calling Line Identification (ANI/CLI) authorization.

Guest access for PPP users

Guest access is the ability to log on to a domain without a user name or a password. Both Routing and Remote Access service and IAS must be configured to support unauthenticated access.

When a remote access server receives a connection attempt, it negotiates with the user different authentication types enabled at the server. If the client accepts one of them, it sends the appropriate credentials for the accepted authentication type. It the user refuses authentication, Routing and Remote Access service checks its properties to verify if unauthenticated access is enabled and, if enabled, forwards the Access-Request message to IAS. This Access-Request message does not contain a User-Name attribute or any other credentials.

When IAS receives the message without a User-Name attribute, it processes the message as an attempt by the user to connect as guest. In this case, IAS uses the name of the guest account in a domain as the user identity. IAS then evaluates policies to determine the right profile. If a match is found, and unauthenticated access is enabled in the profile, other authorizations are validated, and an Access-Accept message is returned. The accounting log file logs the user identity and authentication type, which can be used to determine whether the user is logged on with guest access.

You can enable Guest access by doing the following:

1. Enable unauthenticated access on the remote access server.

2. Enable unauthenticated access on the appropriate remote access policy.

3. Enable the Guest account.

4. Set the remote access permission on the Guest account to either Allow access or Control access through Remote Access Policy depending on your remote access policy administrative model.

If you do not want to enable the Guest account, do the following:

1. Create a user account and set the remote access permission to either Allow access or Control access through Remote Access Policy.

2. Set the Default User Identity registry value on the authenticating server (either the remote access server or the IAS server) to the name of the account.

Following is an example of guest access.

1. During PPP negotiation, the dial-in client rejects all of the PPP authentication protocols of the NAS.

2. If the NAS is configured to allowed unauthenticated access, the NAS sends an Access-Request message without the User-Name attribute and without a password. For the Windows Server 2003 or Windows 2000 Routing and Remote Access service, unauthenticated access is enabled from the Authentication tab on the properties of a server in the Routing and Remote Access snap-in.

3. Because the User-Name attribute is not included in the Access-Request message and by default the IAS user identity is using the User-Name attribute, the user identity is set to Guest (or the value of Default User Identity).

4. With the user identity of Guest and an unauthenticated connection attempt, The authentication and authorization process as discussed earlier in the chapter is performed. If the connection attempt matches a policy whose profile settings have unauthenticated access enabled and the Guest account is enabled and has the appropriate remote access permission, IAS sends an Access-Accept message to the NAS.

DNIS authorization

Dialed Number Identification Service (DNIS) authorization is the authorization of a connection attempt based on the number called. This attribute is referred to as Called-Station-ID. DNIS is used by standard telecommunication companies. This service returns the number called to the called party. Based on the Called-Station-ID attribute, IAS can deliver different services to dial-up/remote access users.

You can enable DNIS authorization by doing the following tasks:

1. Enable unauthenticated access on the remote access server.

2. Create a remote access policy on the authenticating server (remote access server or IAS server) for DNIS-based authorization with the Called-Station-ID condition set to the phone number.

3. Enable unauthenticated access on the remote access policy for DNIS-based authorization.

ANI authorization

ANI authorization is based on the number the user calls from. This attribute is referred to as Calling Station ID, or Caller ID. Based on the Calling-Station-ID attribute, IAS can deliver different services to dial-up/remote access users.

Using ANI authorization is different from using the Caller ID dial-in property of a user account. ANI authorization is performed when the user does not type any user name or password, and refuses to use any valid authentication method. In this case, IAS receives Calling-Station-ID, and no user name and password. To support ANI authorization, the Active Directory must have user accounts with Caller IDs as user names. This kind of authentication is used with the cellular phone authentication and by ISPs in Germany and Japan.

When using the Caller ID property on a user account, the user types in credentials, such as a user name and password, and uses a valid authentication method to log on. IAS authenticates the user with the credentials, and then compares the Calling-Station-ID attribute in the Access-Request to the Caller ID property of the user account to authorize the connection attempt.

You can enable ANI authorization by doing the following:

1. Enable unauthenticated access on the remote access server.

2. Enable unauthenticated access on the appropriate remote access policy for ANI/CLI-based authentication.

3. Create a user account for each number calling, for which you want to provide ANI/CLI authorization. The name of the user account must match the number that the user is dialing from. For example, If a user is dialing in from 555-0100, create a "5550100" user account.

4. Set the User Identity Attribute registry value to 31 on the authenticating server.

   To always use the calling number as the user identity, set the Override User-Name registry value to 1 on the authenticating server.

Note

• If the Override User-Name is set to 1 and the User Identity Attribute is set to 31, then the authenticating server can perform only ANI/CLI-based authentication. The result is that normal authentication using authentication protocols such as MS CHAP v1, CHAP, and EAP is disabled.

ANI example

The following example explains how ANI/CLI authorization works for a dial-up client with an existing user account called 5550100. The client is dialing in from the phone number 555-0100.

1. During PPP negotiation, the dial-in client rejects all of the PPP authentication protocols of the NAS.

2. If the NAS is configured to allow unauthenticated access, the NAS sends an Access-Request message without the User-Name attribute and without a password. (For the Routing and Remote Access service, you can enable unauthenticated access on the Authentication tab in the properties of a server in the Routing and Remote Access snap-in.)

3. Because the User-Name attribute is not included in the Access-Request message, and the IAS user identity is set to use the Calling-Station-ID attribute, the user identity is set to 5550100.

4. With the user identity of 5550100 and an unauthenticated connection attempt, the authentication and authorization process is performed. IAS sends an Access-Accept message to the NAS if the following two conditions are met:

   • The connection attempt matches a policy with a profile setting of unauthenticated access enabled.

   • The 550100 account has the appropriate remote access permissions.

MAC address authorization

Media Access Control (MAC) address authorization functions in the same way as ANI authorization, but it is used for wireless clients and clients connecting to your network by using an 802.1X authenticating switch.

MAC address authorization is based on the MAC address of the network adapter installed in the user’s client computer. Like ANI authorization, MAC address authorization uses the Calling-Station-ID attribute instead of user name and password or certificate-based credentials to identify the user during the connection attempt.

MAC address authorization is performed when the user does not type in any user name or password, and refuses to use any valid authentication method. In this case, IAS receives Calling-Station-ID, and no user name and password. To support MAC address authorization, the Active Directory must have user accounts with MAC addresses as user names.

MAC address authorization is enabled when you do the following:

1. Enable MAC address authorization on access servers (such as wireless APs).

2. Enable unauthenticated access on the appropriate remote access policy for MAC address-based authentication, and enable PAP.

3. Create a user account for each MAC address for which you want to provide MAC address authorization. The name of the user account must match the MAC address of the network adapter installed in the computer from which the user is connecting. The format of the password assigned to the account is determined by the network access server vendor. Review the network access server documentation to determine the appropriate password.

4. Set the User Identity Attribute registry value to 31 on the authenticating server. This registry value location is: HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy

   • The User Identity Attribute registry DWORD decimal value: 31

5. To always use the MAC address as the user identity, set the Override User-Name registry value to 1 on the IAS server. This registry value location is: HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy

   • The Override User-Name registry DWORD decimal value: 1

IAS Authorization

You can use the authorization feature of IAS to allow or deny connection attempts that are based on the connection parameters. The following sections include in-depth information about configuring remote access policies and VSAs.

Remote Access Policies

In Windows NT, versions 3.5, 3.51, and 4.0, authorization is based on 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 IAS in Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; 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.

Remote access policies validate several 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 time-out time

• Maximum session time

• Encryption strength

• IP packet filters

• Advanced restrictions:

  • IP address for PPP connections

  • Static routes

The following settings can also affect connection restrictions:

• Group membership

• Type of connection

• Time of day

• Authentication methods

• Identity of the access server

• Access client phone number or media access control (MAC) address

• Whether unauthenticated access is allowed

It is important to remember that a network connection is accepted only if the settings of the connection attempt match at least one of the configured remote access policies (subject to the conditions of the dial-in properties of the user object and the profile properties of the remote access policy). If the settings of the connection attempt do not match at least one of the remote access policies, the connection attempt is rejected regardless of the dial-in properties of the user account.

For Windows Server 2003 and Windows 2000 IAS servers, remote access policies are administered from the Routing and Remote Access snap-in (when configured for Windows authentication) or the IAS snap-in.

Authorizing access

You can use remote access policies to manage authorization by user or 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 to Deny access. Optionally, create different remote access policies based on different types of connections. For example, you might want to have one remote access policy for dial-up connections and a different remote access policy 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. You can use existing Active Directory groups when you configure remote access policies in IAS, or you can use the Active Directory Users and Computers snap-in to create new Windows groups upon which to base your remote access policies. 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 have a large number of user accounts, you can configure IAS to ignore the dial-in properties of user accounts instead of individually configuring each account to Control access through Remote Access Policy. You can set Ignore-User-Dialin-Properties on the Advanced tab of a remote access policy profile in the IAS console.

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.

Note

• It is not recommended that you manage network access authorization by user while also setting user account dial-in properties to Control access through Remote Access Policy. When you set user account dial-in properties to Control access through Remote Access Policy, manage network access authorization by group instead of by user.

Local vs. Centralized Policy Management

Because remote access policies are stored locally on either a remote access server or an IAS server, you must take the following steps in order to use centralized management of a single set of remote access policies for multiple remote access or VPN servers:

1. Install IAS as a Remote Authentication Dial-In User Service (RADIUS) server on a computer.

2. Configure IAS with RADIUS clients that correspond to each of the NASs.

3. On the IAS server, create the central set of policies that all NASs are using.

4. Configure each of the NASs as a RADIUS client to the IAS server.

After you configure a Windows Server 2003 or Windows 2000 remote access server as a RADIUS client to an IAS server, the local remote access policies stored on the remote access server are no longer used.

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

Dial-in properties of a user object

In Windows Server 2003, the user object for a stand-alone server or Active Directory–based server contains a set of dial-in properties that are used when allowing or denying a connection attempt made by a user. For a stand-alone server, the dial-in properties are available on the Dial-in tab of the user object in the local User Manager. For an Active Directory–based server, the dial-in properties are available on the Dial-in tab of the user object in the Active Directory Users and Computers snap-in. The Windows NT 4.0 User Manager for Domains administrative tool cannot be used for Active Directory–based servers.

The dial-in properties for a user object are the following:

Remote Access Permission (Dial-in or VPN)

Use this property to set whether remote access is explicitly allowed, denied, or determined through remote access policies. If access is explicitly allowed, remote access policy conditions or user object or profile properties can override the setting. The Control access through Remote Access Policy option is available only on user objects for stand-alone Routing and Remote Access service servers or members of a domain that has a Windows 2000 native or Windows Server 2003 domain functional level.

Note

• When the domain functional level in Active Directory is set to Windows 2000 mixed, the Control access through Remote Access Policy radio button is disabled on the Dial-in tab in user account Properties. To enable the use of Control access through Remote Access Policy, you must raise the domain functional level in Active Directory to either Windows 2000 native or Windows Server 2003.

By default, the Administrator and Guest accounts are set to Control access through Remote Access Policy on a stand-alone remote access server or in a Windows 2000 native domain. For a Windows 2000 mixed domain, the Administrator and Guest accounts are set to Deny access by default. New accounts created on a stand-alone remote access server or in a Windows 2000 native domain are set to Control access through Remote Access Policy. New accounts created in a domain with a Windows 2000 mixed domain functional level are set to Deny access.

Verify Caller ID

When Caller ID 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 Windows 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 establishment at a phone number set by the caller or a specific phone number set by the administrator.

Assign a Static IP Address

If this property is enabled, the administrator assigns a specific IP address to the user when the connection is made.

Apply Static Routes

If this property is enabled, the administrator defines a series of static IP routes that are added to the routing table of the remote access server when a connection is made. This setting is designed for user accounts that Windows Server 2003 or Windows 2000 routers use for demand-dial routing.

For a user account that is a member of a Windows NT 4.0 domain or a Windows 2000 mixed domain, only the Allow access and Deny access Remote Access Permission options and Callback Options dial-in properties are available. In addition, the User Manager for Domains administrative tool can be used to grant or deny dial-in access and set callback options.

For a user account that is on a stand-alone server or in a Windows 2000 native domain, the callback number can be of unlimited size. For a user account that is in a Windows NT 4.0 domain or a Windows 2000 mixed domain, the callback number can only be 128 characters long. Callback numbers that are long than 128 characters are truncated during a callback connection attempt, which results in a failed callback connection.

When a Windows NT 4.0 RAS server uses a Windows 2000 native domain to obtain the dial-in properties of a user account, the Control access through Remote Access Policy option is retrieved as Deny access. Callback settings are retrieved correctly.

User accounts upgraded to Windows Server 2003 or Windows 2000 that were configured with dial-in permission enabled are set to Allow access. User accounts upgraded to Windows Server 2003 or Windows 2000 that were configured with dial-in permission disabled are set to Control access through Remote Access Policy.

A Windows NT 4.0 Remote Access Service (RAS) server does not use remote access policies. It is recommended that you upgrade Windows NT 4.0 RAS servers to take advantage of remote access policies.

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

Remote access policy 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, all of the conditions must match the settings of the connection attempt in order for the connection attempt to match the policy. Not all NASs send all of the IAS server-specific attributes.

The table “Condition Attributes for a Remote Access Policy” shows the condition attributes that you can set for a remote access policy.

Condition Attributes 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 NAS. This attribute is a character string. You can use pattern matching syntax to specify area codes. In order to receive called station ID information during a call, the phone line, the hardware, and the Windows Server 2003 driver for the hardware must support the passing of the called ID. Otherwise, the called station ID is manually set for each 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.
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 IAS. This attribute is a character string. You can use pattern matching syntax to specify client names.
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.
Client Vendor	The vendor of the NAS that requests authentication. Ensure that you configure the NAS vendor when registering the RADIUS client on the IAS server. For example, the Routing and Remote Access service is the Microsoft NAS manufacturer. You can use this attribute to configure separate policies for RADIUS clients from different NAS manufacturers. This attribute is used by the IAS server.
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 NAS. This attribute is a character string. You can use pattern matching syntax to specify multiple NASs.
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.
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 Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; Windows Server 2003, Datacenter Edition; Windows XP; 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. You cannot use the built-in local or domain groups for the Windows Groups attribute.

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.

Remote access permission

IAS evaluates all remote access policies in the ordered list of remote access policies in an effort to match policy conditions with the connection attempt. If IAS can match all of the conditions of one of the remote access policies with the settings of the connection attempt, the matching remote access policy is used for the request. IAS then determines remote access permission by evaluating the setting for If a connection request matches the specified conditions. If a connection request matches the specified conditions is a setting found in the properties of a remote access policy, and can have one of the following values:

• Deny remote access permission . If Deny remote access permission is set on the policy, then remote access permission is denied.

• Grant remote access permission. If Grant remote access permission is set on the policy, then remote access permission is granted.

Remote access permission is also granted or denied for each user account. The user account 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 with either the user account permissions setting or the policy permission setting is the first step in accepting a connection. The connection attempt is then subjected to the settings of the user account properties and the policy profile properties and restrictions. If the connection attempt does not match the settings of the user account properties or the profile properties, or if specific restrictions defined in the profile prevent the connection, the connection attempt is rejected. For example, if the remote access policy profile restricts connections to use only EAP as an authentication method but the connection attempt is made using MS-CHAP v2 by a client that is not configured to use EAP, the connection attempt is rejected even when the value of If a connection request matches the specified conditions is Grant remote access permission.

By default, the Deny remote access permission policy permission is selected.

Profile

A remote access policy profile is a set of properties that are applied to a connection when the connection is granted remote access permission, either through the user account permission setting or the policy permission setting. 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 (Idle-Timeout) 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 (Session-Timeout) The maximum 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 (Called-Station-ID) 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 (NAS-Port-Type) The specific media type, such as modem (also known as async), ISDN (also known as virtual), or 802.11 wireless that a caller must use so that a connection is allowed. If the media 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.

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 VSAs 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 computer running Windows Server 2003 and the Routing and Remote Access service, but are not applied to dial-on-demand connections.

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.

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. With Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition, you can specify whether users can change their expired passwords using MS-CHAP and MS-CHAP v2.

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.

Encryption

You can set encryption properties for the following encryption strengths:

• No Encryption

  When selected, this option allows an unencrypted connection. To require encryption, clear the No Encryption option. For L2TP over IPSec-based VPN connections, the Authentication Header (AH) is used.

• Basic

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

• Strong

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

• Strongest

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

Advanced

You can set Advanced properties to specify the series of RADIUS attributes that are sent back to the RADIUS client by the IAS server. RADIUS attributes are specific to performing RADIUS authentication and are ignored by the remote access server. By default, Framed-Protocol is set to PPP and Service-Type is set to Framed.

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

Configuration issues

Following are several issues that might impact your configuration of IAS, depending on your network and needs:

• Some elements of a remote access policy correspond to RADIUS attributes that are used during RADIUS-based authentication. For remote access policies on an IAS server, verify that the NASs 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 authentication requests from that NAS are denied.

• You can only use the Generate-Session-Time-out 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-Time-out 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.

• 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 time-out in your remote access policy or connection request policy for wireless connections (using the Session-Time-out 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 APs might end the connection during reauthentication. For more information, see your hardware documentation.

Default remote access policies

Two default remote access policies are installed with IAS in Windows Server 2003, with the following names and configurations:

1. The Connections to Microsoft Routing and Remote Access server policy has the following configuration:

   • Policy conditions are set to process Access-Request messages sent by RADIUS clients that are computers running the Microsoft Routing and Remote Access service. This policy condition is set by using the MS-RAS Vendor attribute with a wildcard value of ^311$.

   • Permission is set to Deny remote access permission.

   • Two connection attributes are configured in profile properties: Framed-Protocol is configured with a value of PPP, and Service-Type is configured with a value of Framed.

   • Connections that use no encryption are not allowed. Only connections using basic, strong, or strongest encryption are allowed.

   • IP packet filters are configured to allow traffic only between the IAS server and network access servers configured as RADIUS clients.

   • All other profile properties are set to default values.

2. The Connections to other access servers policy has the following configuration:

   • The Day-and-Time-Restrictions condition is set to all times and all days.

   • Permission is set to Deny remote access permission.

   • Two connection attributes are configured in profile properties: Framed-Protocol is configured with a value of PPP, and Service-Type is configured with a value of Framed.

   • All profile properties are set to default values.

Vendor Profiles

Some vendors use VSAs to provide functionality that is not supported in standard attributes. IAS enables you to create or modify VSAs to take advantage of the proprietary functionality that is supported by some NAS vendors.

If you need to configure more than one VSA for a specific profile, you must arrange them in the appropriate order. If you are using filters and the order of the filters is important, use the arrow buttons to rearrange the attributes.

Example 1

The following example demonstrates the procedure of adding a Cisco VSA to a profile. The example illustrates only the mechanism of adding a standard-conforming VSA to a profile. Cisco VSAs are readily available through the IAS multi-vendor dictionary.

Cisco VSAs conform to the RADIUS RFC 2548 for Vendor-Specific Attributes (type 26). The following information is for a Cisco attribute to specify a primary DNS server:

• Vendor ID: 9. This is the unique ID for Cisco. When you specify that vendor, this is automatically supplied.

• Vendor Type: 1. This is the vendor-type number for VSAs that take the attribute-value pair form, referred to in Cisco documentation as “cisco-avpair.”

• Data Type: String.

• Format: If the attribute is mandatory, the format 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 particular 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 also be used for RADIUS.

The Cisco attribute used to specify a primary DNS server appears as follows:

ip:dns-servers=10.10.10.10

Example 2

The following example demonstrates how to add a 3Com/U.S. Robotics VSA to a profile.

Note

• Example 2 is included only to illustrate the mechanism for adding a standard nonconforming VSA to a profile. 3Com/U.S. Robotics VSAs are readily available from the IAS multivendor dictionary.

U.S. Robotics VSAs do not conform to the recommended format for Vendor-Specific Attributes (type 26) in RFC 2865. Therefore, all U.S. Robotics VSAs must be entered in hexadecimal format. 

The following information is for a U.S. Robotics attribute to specify a primary DNS/NBNS server:

• Vendor ID: 429. This is the unique ID for U.S. Robotics. When you specify that vendor, this ID is automatically supplied.

• Indicator: 0x900F

• Data Type: String

• Format: The VSA must be entered in hexadecimal format.

For more information about the proprietary attributes of U.S. Robotics, see your U.S. Robotics documentation.

Accepting a Connection Attempt

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

1. The first policy in the ordered list of remote access policies is checked. If there are no policies, the connection attempt is rejected.

2. If all the conditions of the policy do not match the connection attempt, go to next policy. If there are no more policies, reject the connection attempt.

3. If all the 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 properties and profile properties:

     If the connection attempt does not match the settings of the user account properties and profile properties, reject the connection attempt.

     If the connection attempt matches the settings of the user account properties and profile properties, accept the connection attempt.

5. 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. In that case, 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 properties and profile properties:

     If the connection attempt does not match the settings of the user account properties and profile properties, reject the connection attempt.

     If the connection attempt matches the settings of the user account properties and profile properties, accept the connection attempt.

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

IAS Accounting

Support for the RADIUS standard allows IAS to log the accounting data produced by NASs and IAS. User authentication and accounting requests and periodic data recorded in log files is used primarily for IAS troubleshooting, connection analysis, and billing purposes. In addition, accounting records can provide you with a useful tool when analyzing possible security problems, such as an attempt by a malicious user to access network resources. You can log accounting data in three formats, including IAS format, database-compatible format, and SQL Server Logging format.

RADIUS Accounting

IAS supports RADIUS accounting, with which an administrator can track network usage for auditing and billing purposes. Accounting data can also be queried by Help desk and other applications to assist with network access troubleshooting. RADIUS accounting provides the following benefits:

• Real-time data collection.

• Accounting data can be collected from a central location.

• Non-Microsoft products can be used to analyze RADIUS accounting data to provide charge-back, troubleshooting, performance, and exception reports.

When configured for accounting, IAS can log accounting data to a log file or to a SQL Server database.

When a RADIUS client is configured to use RADIUS accounting, at the start of service delivery it generates an Accounting-Start message describing the type of service being delivered and the user it is being delivered to. The message is then sent to the RADIUS Accounting server, which sends back an acknowledgment to the RADIUS client. At the end of service delivery, the client generates an Accounting-Stop message describing the type of service that was delivered and statistics (optional), such as elapsed time, input and output octets, or input and output packets. It then sends that data to the RADIUS accounting server, which sends back an acknowledgment to the RADIUS client.

The Accounting-Request message (whether for the Start or Stop message) is submitted to the RADIUS accounting server through the network. If no response is returned within a length of time, the request is re-sent a number of times. The client can also forward requests to an alternate server or servers in the event that the primary server is down or unreachable. An alternate server can be used either after a number of tries to the primary server fail, or in a round-robin fashion. If the RADIUS accounting server can not successfully record the accounting message, it does not send an Accounting-Response acknowledgment to the RADIUS client. For example, when the log file gets filled up, IAS starts discarding accounting messages. This prompts the RADIUS client to switch to the backup IAS server.

SQL Server Logging

You can use SQL Server logging to record user authentication and accounting requests received from one or more NASs to a data source on a computer running the Microsoft SQL Server Desktop Engine (MSDE 2000) or Microsoft SQL Server 2000. Accounting data is passed from IAS in eXtensible Markup Language (XML) format to a stored procedure in an MSDE 2000 or SQL Server 2000 database, which support both SQL and XML (SQLXML).

Logging to a SQL Server 2000 relational database instead of a standard text file (that is, either IAS format or database-compatible format) has many advantages, including the following:

• Relationships between data tables enable the flexible creation of dynamic data views by using queries and reports.

• SQL Server 2000 has high-speed optimizations that can effectively support very large, terabyte-sized databases.

• Multiple bulk copy operations can be performed concurrently against a single table in SQL Server to speed data entry.

• The Transact-SQL BACKUP and RESTORE statements are optimized to read through a database serially and write in parallel to multiple backup devices. In addition, SQL Server 2000 supports differential backups, which replicate only the data changed after the last backup.

• You can configure SQL Server logging to provide failover and redundancy, and multiple IAS servers can log to the same database, providing ease of administration.

• Data from multiple IAS servers can be stored in the same database, providing a centralized data source for many IAS servers and the ability to achieve a more comprehensive data view for applications that query the database, such as Help desk applications.

In addition, you can improve logging performance and, in some circumstances, reduce the cost of deploying SQL Server logging by using MSDE 2000 databases installed on each IAS server.

The recommended deployment model for SQL Server logging is to configure IAS to log to a stored procedure in a MSDE 2000 database installed on the local server. You can then write a program, service, or component that periodically publishes the accounting data from the MSDE 2000 database to a central SQL Server.

Components of IAS SQL Server logging

IAS SQL Server logging includes several components, some of which are installed on the IAS server, and some of which are configured on the computer running SQL Server 2000.

The figure, “IAS SQL Server Logging,” illustrates the components of SQL Server logging with IAS in Windows Server 2003 and a computer running SQL Server 2000.

IAS SQL Server Logging

IAS server

A computer running Windows Server 2003 and IAS configured to use SQL Server logging.

MSDE 2000 database

A data engine and database built and based on core SQL Server technology that is installed on the computer running Windows Server 2003 and IAS.

Stored procedure

A group of Transact-SQL statements compiled into a single execution plan, or program, that runs inside the MSDE 2000 database on the computer running Windows Server 2003 and IAS. The stored procedure must be named report_event. Report_event accepts and processes data from the IAS server and stores it in MSDE 2000 tables.

Custom accounting-forwarder component

A low-level program installed on the computer running Windows Server 2003 and IAS that automatically manages and administers the MSDE 2000 database. The custom component, service, or application should periodically publish records from the MSDE 2000 database on the IAS server to the IAS database on the computer running SQL Server. The custom component should also flag records as published, and delete previously published records from the MSDE 2000 database during off-peak hours. If there are multiple IAS servers configured for SQL Server logging, each server must have the custom component installed to process records in the local MSDE 2000 database and forward records to the SQL Server database.

SQL server

A computer or computer cluster running SQL Server 2000. If you have a small IAS deployment, you might need only one computer running SQL Server; if you have a large IAS deployment in an enterprise network environment, you might need more than one computer running SQL Server or a cluster of computers running SQL Server.

IAS database

A database on the computer running SQL Server dedicated to storing the records from all IAS servers configured for SQL Server logging.

Configuring accounting to provide the best session correlation

When you use an application to query your SQL Server 2000 database, it is important that sufficient data is logged to provide the application the ability to correlate related fields and information into a cohesive view of any particular user session. This is called session correlation. To provide the best session correlation, take the following actions:

• Use NASs that send the Class attribute in all accounting-requests. The Class attribute is sent to the RADIUS client in an Access-Accept message, and is useful for correlating Accounting-Request messages with authentication sessions.

• If the Class attribute is sent by the NAS in the accounting request messages, it can be used to match the accounting and authentication records. The combination of the attributes Unique-Serial-Number, Service-Reboot-Time, and Server-Address must be a unique identification for each authentication that the server accepts.

• Use NASs that support interim accounting.

• Use NASs that send on/off accounting messages.

• Use NASs that support the storing and forwarding of accounting data. NASs that support this feature can store accounting data in circumstances when it cannot communicate with the IAS server. When the IAS server is available, the NAS forwards the stored records to the IAS server, providing increased reliability in accounting over NASs that do not provide this feature.

• Always configure the Acct-Interim-Interval attribute in remote access policies. The Acct-Interim-Interval attribute sets the interval (in seconds) between each interim update that the NAS sends. You can add the Acct-Interim-Interval RADIUS attribute on the Advanced tab on the profile settings of the remote access policy. According to RFC 2869, the value of the Acct-Interim-Interval attribute must not be smaller than 60 seconds, or one minute, and should not be smaller than 600 seconds, or 10 minutes. For more information, see RFC 2869, “RADIUS Extensions.”

• Ensure that logging of periodic status is enabled on your IAS servers.

IAS log file

IAS can create a log file based on the data returned by the NASs. This information is useful for keeping track of usage and correlating authentication information with accounting records (for example, to discover missing records or instances of over-billing).

IAS supports two formats of the log file: IAS format and database. Database format allows you to keep track of a predetermined set of attributes, and IAS format is more detailed and can contain information about all attributes. Use database format if you want to import the data directly into a database. The IAS format can be used if you need to record more detailed information than the database log format allows.

Note

• The IAS log file contains all the IAS user-related events. IAS service and system-related events are recorded in the Event log files.

IAS Authentication and Domain Functionality

IAS authentication features and behavior vary with the functional levels of the domains in which IAS is running. Knowing the differences is useful when making decisions about a particular domain in which IAS is deployed.

Domain and forest functionality, introduced in Windows Server 2003 Active Directory, provides a way to enable domain- or forest-wide Active Directory features within your network environment. Different levels of domain functionality and forest functionality are available depending on your environment.

If all domain controllers in your domain or forest are running Windows Server 2003 and the functional level is set to Windows Server 2003, all domain- and forest-wide features are available. When Windows NT 4.0 or Windows 2000 domain controllers are included in your domain or forest with domain controllers running Windows Server 2003, Active Directory features are limited.

The concept of enabling additional functionality in Active Directory exists in Windows 2000 with mixed and native modes. Mixed-mode domains can contain Windows NT 4.0 backup domain controllers and cannot use Universal security groups, group nesting, and security ID (SID) history capabilities. When the domain is set to native mode, Universal security groups, group nesting, and SID history capabilities are available. Domain controllers running Windows 2000 Server are not aware of domain and forest functionality.

Domain Functionality

Domain functionality enables features that will affect the entire domain and that domain only. Four domain functional levels are available: Windows 2000 mixed (default), Windows 2000 native, Windows Server 2003 interim, and Windows Server 2003. By default, domains operate at the Windows 2000 mixed functional level.

The following table, “Domain Controller Support by Domain Functional Level,” lists the domain functional levels and their corresponding supported domain controllers.

Domain Controller Support by Domain Functional Level

Domain Functional Level	Domain Controllers Supported
Windows 2000 mixed (default)	Windows NT 4.0 Windows 2000 Windows Server 2003 family
Windows 2000 native	Windows 2000 Windows Server 2003 family
Windows Server 2003 interim	Windows NT 4.0 Windows Server 2003 family
Windows Server 2003	Windows Server 2003 family

IAS is capable of authenticating access requests received through the RADIUS protocol against domains with Windows 2000 native, Windows 2000 mixed, Windows Server 2003 interim, and Windows Server 2003 domain functional levels. When you have a stand-alone IAS server, IAS can also authenticate access requests when configured with a Windows Server 2003 local accounts database.

The IAS authentication features and capabilities available to administrators are dependant upon the domain functional level of a particular domain against which the users authenticate.

The Windows Server 2003 Domain Functional Level

Domains configured with the Windows Server 2003 domain functional level provide the most flexibility in managing remote access through groups, including full support for all features.

The Windows Server 2003 Interim Domain Functional Level

Domains with a Windows Server 2003 interim functional level are mainly used for migration from Windows NT 4.0 to Windows Server 2003. For IAS, a Windows Server 2003 interim domain acts exactly like a Windows NT 4.0 domain.

For an IAS server that is a member of a Windows Server 2003 interim domain, the following authentication and remote access management features are available:

• User account dial-in properties

• Remote access permissions include only Allow access and Deny access

  Without the Control access through Remote Access Policy option, policy-based management using groups becomes more difficult because the user’s remote access permission overrides remote access policy permissions.

• Callback options

In order for the IAS server to access user account dial-in properties stored in Active Directory, the Internet Authentication service must run in the security context of a computer account that is a member of the RAS and IAS Servers security group. This assignment can be implemented through the Active Directory Users and Computers snap-in or by registering the IAS server in the IAS snap-in. You can also use the netsh ras add registeredserver command.

If IAS is a member of Windows NT 4.0 domain but has to authenticate users against a trusted Active Directory domain, it is not able to gain access to Active Directory because its computer account cannot become a member of the RAS and IAS Servers security group. In this case, verify that the Everyone group is added to the Pre-Windows 2000 Compatible Access group with the net localgroup "Pre-Windows 2000 Compatible Access" command. If not, issue the net localgroup "Pre-Windows 2000 Compatible Access" everyone /add command on a domain controller computer and then restart the domain controller computer.

The Windows 2000 Native Domain Functional Level

From the network access management perspective, the following benefits are available in the Windows 2000 native domain functional level:

• Full ability to manage remote access permissions through groups. An administrator can use the universal group feature to create a single policy for users in different domains. Nested groups can be used to organize extremely large numbers of users into smaller groups for better management.

• An ability to connect remote network to office network. You can specify routes for the remote network through Static Routes.

• Support for User Principal Names (UPNs).

Users can have the same UPN regardless of what domain the user belongs to. This indirection provides scalability that might be required in organizations that have large number of domains.

The following is a detailed list of authentication and remote management features available for an IAS server that is a member of a domain with a Windows 2000 domain functional level.

• User or computer account dial-in properties, which include:

  • All remote access permissions options are available, including Allow access, Deny access, and Control access through Remote Access Policy.

  • Caller-ID

  • Callback options

  • Static IP address

  • Static routes

• Support for UPNs and Universal Groups

• Support for EAP-TLS and PEAP.

In order for the IAS server to access user account dial-in properties stored in Active Directory, IAS must run in the security context of a computer account that is a member of the RAS and IAS Servers security group. This assignment can be implemented through the Active Directory Users and Computers snap-in or by registering the IAS server in the IAS snap-in. You can also use the netsh ras add registeredserver command.

The Windows 2000 Mixed Domain Functional Level

Domains with a Windows 2000 mixed functional level are mainly used for migration from Windows NT 4.0 to Windows Server 2003 or Windows 2000. For IAS, a Windows 2000 mixed domain acts exactly like a Windows NT 4.0 domain.

For an IAS server that is a member of a Windows 2000 mixed domain, the following authentication and remote access management features are available:

• User account dial-in properties

• Remote access permissions include only Allow access and Deny access

  Note

  • Without the Control access through Remote Access Policy option, policy-based management, using groups becomes more difficult because the user’s remote access permission overrides remote access policy permissions.

• Callback options

Just as in Windows 2000 native domains, in order for the IAS server to access user account dial-in properties stored in Active Directory, the Internet Authentication service must run in the security context of a computer account that is a member of the RAS and IAS Servers security group. This assignment can be implemented through the Active Directory Users and Computers snap-in or by registering the IAS server in the IAS snap-in. You can also use the netsh ras add registeredserver command.

If IAS is a member of Windows NT 4.0 domain but has to authenticate users against a trusted Active Directory domain, it is not able to gain access to Active Directory because its computer account cannot become a member of the RAS and IAS Servers security group. In this case, verify that the Everyone group is added to the Pre-Windows 2000 Compatible Access group with the net localgroup "Pre-Windows 2000 Compatible Access" command. If not, issue the net localgroup "Pre-Windows 2000 Compatible Access" everyone /add command on a domain controller computer and then restart the domain controller computer.

Stand-Alone IAS Servers

Stand-alone IAS servers can be used in very small networks with no domains. All the users need to be defined in the local accounts database of a stand-alone server.

The following authentication features are available on a stand-alone IAS server:

• Dial-in User Account Properties

  • All remote access permission options, including Allow access, Deny access, and Control access through Remote Access Policy

• Caller-ID

• Callback options

• Static IP address

• Static routes

Support for UPNs, Universal Groups, and EAP-TLS is not available on a stand-alone IAS server computer.

User account dial-in properties can be administered through the properties of the Incoming Connections connection in the Network Connections folder or through the Local Users and Groups snap-in.

Differences in IAS Implementations

A previous version of IAS was released with the Windows NT 4.0 Option Pack. The following section describes the differences in behavior between the two versions.

Windows NT 4.0 IAS

• If no domain name is specified during authentication, the IAS server authenticates the user against only the local SAM database.

• IAS does not use the callback permissions for all user objects. IAS

• IAS log files are written in ASCII.

Windows 2000 and Windows Server 2003 IAS

IAS resolves a user name with no domain specified by using the following sequence:

• IAS determines a default domain from the registry, if one is specified there.

  • If the IAS server is a member of a domain, IAS authenticates the user against that domain.

  • If the IAS server is not a member of a domain, IAS authenticates the user against the local SAM database.

• IAS uses the callback permissions for all user objects.

• IAS log files are multi-language and are written in UTF-8.

IAS as a RADIUS Proxy

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

The figure, “IAS as a RADIUS Proxy,” illustrates how the feature can be used to relays messages between RADIUS clients (access servers) and either RADIUS servers or another RADIUS proxy.

IAS as a RADIUS Proxy

IAS acts as a RADIUS proxy for incoming RADIUS messages when the message matches a connection request policy that is configured to forward the request to a remote RADIUS server group.

When IAS is a RADIUS proxy between a RADIUS client and a RADIUS server, the messages that RADIUS sends for network access are forwarded as follows:

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.

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

11. The RADIUS server sends an Accounting-Response to the IAS RADIUS proxy, where it is forwarded to the access server.

Access-Request Messages

Forwarding a RADIUS Access-Request message from a RADIUS client to a RADIUS server results in the following changes to the RADIUS Access-Request message:

• Attribute manipulation rules are applied and the RADIUS attribute is modified according to the configured find and replace rules.

• All RADIUS message fields for which the RADIUS shared secret is used are recalculated. The recalculation is performed by using the shared secret of the IAS server and the remote RADIUS server to which the message is being forwarded. These RADIUS attributes include the Message Authenticator (also known as the Signature attribute), User-Name, Tunnel-Password, and MS-CHAP -MPPE-Keys. Additionally, the Authenticator field in the RADIUS header is recalculated.

• If the Access-Request message contains a Proxy-State attribute indicating that the message has been forwarded by another RADIUS proxy, the contents of the Proxy-State attribute are saved in a proxy session table and the Proxy-State attribute is rewritten with a value determined by the IAS server. The new value of the Proxy-State attribute is stored in a proxy session table.

When forwarding the Access-Request message, the set of additional RADIUS attributes as configured on the Advanced tab from the profile settings of the matching connection request policy is stored in the proxy session table. These attributes are not actually added to the Access-Request message but are saved for the response to the Access-Request message.

Access-Accept Messages

The proxy-state attribute in the Access-Accept message is used to find the corresponding entry in the proxy session table. The entry in the proxy session table indicates the IP address of the client to which the message is forwarded, the Proxy-State attribute of the original Access-Request message, and any additional RADIUS attributes to add. If an entry is not found, the Access-Accept message is discarded.

Forwarding a RADIUS Access-Accept message from a RADIUS server to a RADIUS client results in the following changes to the RADIUS Access-Accept message:

• All RADIUS message fields for which the RADIUS shared secret is used are recalculated by using the shared secret of the IAS server and the RADIUS client to which the message is being forwarded. These RADIUS attributes include the Message Authenticator (also known as the Signature attribute), Tunnel-Password, and MS-CHAP -MPPE-Keys. Additionally, the Authenticator field in the RADIUS header is recalculated.

• If the proxy session table entry contains an original Proxy-State attribute, the Proxy-State attribute in the Access-Accept message is replaced with the original Proxy-State attribute of the Access-Request message.

• If the proxy session table entry contains an additional RADIUS attributes, these RADIUS attributes are added to the Access-Accept message. If any of these RADIUS attributes are already present, their values are overwritten with new values.

Access-Reject Messages

The proxy-state attribute in the Access-Reject message is used to lookup the corresponding entry in the proxy session table. The entry in the proxy session table indicates the IP address of the client to which the message is to be forwarded, the Proxy-State attribute of the original Access-Request message, and any additional RADIUS attributes to add. If an entry is not found, the Access-Reject message is discarded.

Forwarding a RADIUS Access-Reject message from a RADIUS server to a RADIUS client results in the following changes to the RADIUS Access-Reject message:

• All RADIUS message fields for which the RADIUS shared secret are used are recalculated by using the shared secret of the IAS server and the RADIUS client to which the message is being forwarded. These RADIUS attributes include the Message Authenticator (also known as the Signature attribute), Tunnel-Password, and MS-CHAP -MPPE-Keys. Additionally, the Authenticator field in the RADIUS header is recalculated.

• If the proxy session table entry contains an original Proxy-State attribute, the Proxy-State attribute in the Access-Reject message is replaced with the Proxy-State attribute of the original Access-Request message.

• If the proxy session table entry contains an additional RADIUS attributes, these RADIUS attributes are added to the Access-Reject message. If any of these RADIUS attributes are already present, their values are overwritten with new values.

Accounting-Request Messages

When a RADIUS proxy forwards a RADIUS Accounting-Request message from a RADIUS client to a RADIUS server, it results in the following changes:

• Attribute manipulation rules are applied and the RADIUS attribute is modified according to the configured find and replace rules.

• All RADIUS message fields for which the RADIUS shared secret are used are recalculated using the shared secret of the IAS server and the remote RADIUS server to which the message is being forwarded. These RADIUS attributes include the Message Authenticator (also known as the Signature attribute) and User-Name. Additionally, the Authenticator field in the RADIUS header is recalculated.

• If the Accounting-Request message contains a Proxy-State attribute indicating that the message has been forwarded by another RADIUS proxy, the contents of the Proxy-State attribute are saved in a proxy session table and the Proxy-State attribute is rewritten with a value determined by the IAS server. The new value of the Proxy-State attribute is stored in a proxy session table.

When forwarding the Accounting-Request message, the set of additional RADIUS attributes as configured on the Advanced tab from the profile settings of the matching connection request policy is stored in the proxy session table. These attributes are not actually added to the Accounting-Request message but are saved for the response to the Accounting-Request message.

Accounting-Response Messages

The Proxy-State attribute in the Accounting-Response message is used to lookup the corresponding entry in the proxy session table. The entry in the proxy session table indicates the IP address of the client to which the message is to be forwarded, the Proxy-State attribute of the original Accounting-Request message, and any additional RADIUS attributes to add. If an entry is not found, the Accounting-Response message is discarded.

When a RADIUS proxy forwards a RADIUS Accounting-Response message from a RADIUS server to a RADIUS client, it results in the following changes to the RADIUS Accounting-Response message:

• All RADIUS message fields for which the RADIUS shared secret are used are recalculated using the shared secret of the IAS server and the RADIUS client to which the message is being forwarded, such as the Message Authenticator (also known as the Signature attribute). Additionally, the Authenticator field in the RADIUS header is recalculated.

• If the proxy session table entry contains an original Proxy-State attribute, the Proxy-State attribute in the Accounting-Response message is replaced with the original Proxy-State attribute of the Accounting-Request message.

• If the proxy session table entry contains additional RADIUS attributes, these RADIUS attributes are added to the Accounting-Response message. If any of these RADIUS attributes are already present, their values are overwritten with new values.

Connection Request Processing

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 the following:

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

• Remote RADIUS server groups that specify multiple RADIUS servers when an incoming RADIUS request message is forwarded.

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. Using 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 implemented in many new RADIUS deployments.

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.

Elements of a Connection Request Policy

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:

• If the RADIUS request message matching all of the conditions of a connection request policy, the profile settings of the policy are applied to determine how the message is processed.

Policy 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 conditions must match the attributes of the incoming RADIUS message so that the RADIUS request message matches the policy.

The following table, “Connection Request Policy Condition Attributes,” shows the condition attributes that you can set for a connection request policy.

Connection Request Policy Condition Attributes

Attribute name	Description
Called Station ID	The phone number of the NAS. This attribute is a character string. You can use pattern matching syntax to specify area codes.
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.
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.
Client IP Address	The IP address of the NAS (the RADIUS client). This attribute is a character string. You can use pattern matching syntax to specify IP networks.
Client Vendor	The vendor of the NAS that is requesting authentication. You can use this attribute to configure separate policies for different NAS manufacturers that are configured as RADIUS clients to an IAS server.
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 date 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 NAS. This attribute is a character string. You can use pattern matching syntax to specify NAS identifiers.
NAS IP Address	The IP address of the NAS (the RADIUS client). This attribute is a character string. You can use pattern matching syntax to specify IP networks.
NAS Port Type	The type of media used by the caller. Examples are analog phone lines (known as async), ISDN, and tunnels or virtual private networks (known as virtual).
Remote RADIUS to Windows User Mapping	Specifies that authorization is performed locally with remote access policies and user account properties, and authentication is performed against a remote RADIUS server. For example, visitors to your network are authenticated by their organization’s RADIUS server, while a Windows user account created for the visitor at your organization is used for authorization. This configuration allows you to provide visitors with limited access to your network resources, while authenticating them against the user account database at their own organization.
Service Type	The type of service 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.
Tunnel Type	The type of tunnel 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 Windows Server 2003 and Windows 2000 remote access clients and demand-dial routers.
User Name	The user name used by the access client in the RADIUS message. This attribute is a character string. You can use pattern matching syntax to specify client names.

Policy 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 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 SAM on Windows Server 2003, Standard Edition; Windows Server 2003, Enterprise Edition; and Windows Server 2003, Datacenter Edition, 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 verify the user credentials and do not check user account properties or remote access policies to verify that the user is authorized to access network resources. An Access-Accept message is immediately sent to the RADIUS client by IAS without performing authentication or authorization. This setting is used for some types of compulsory tunneling where the access client is tunneled before the users credentials are authenticated.

  This authentication option cannot be used when the authentication protocol of the access client is PEAP, MS-CHAP v2, or EAP-TLS, 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.

Accounting options

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.

Attribute manipulation rules

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

Attribute manipulation rule processing occurs for one of the preceding attributes before the RADIUS message is subject to authentication and accounting settings.

You can configure attribute manipulation rules in the profile of a connection request policy. When you configure attribute manipulation rules, you specify text that you want IAS to find in the attribute and you specify replacement text. While processing attribute manipulation rules, IAS seeks the text you specify in the rule. If the text is found in the attribute, IAS deletes the text and replaces it with the replacement text that you specify in the rule.

Configuring an attribute manipulation rule for the User Name attribute in IAS for Windows Server 2003 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 this character. 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.

Note

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

Advanced properties

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.

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.

Realm Names

When an access client sends password-based user account credentials during connection attempts with a NAS, a user name and password are included. The user name consists of two elements:

• Identification of the user account name.

• Identification of the user account location on the network.

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 two forms of realm names:

• The realm name can be a prefix.

  For example, Microsoft\user1, where Microsoft is the name of a Windows NT 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.

When initiating a network connection, users can be required to provide the realm name as either a prefix or a suffix when typing account credentials in the Connect dialog box. For example, when the owner of the account user1 connects to microsoft.com with a VPN connection, they can be required to type either MICROSOFT\user1 or user1@microsoft.com.

If you use Connection Manager Administration Kit (CMAK) to create Connection Manager profiles for distribution to users, the profile can be configured to automatically append the realm name to the user account name during connection attempts by users.

For example, you can specify a realm name and syntax when you create a custom dialing package with CMAK so that the user must specify only the user account name.

In this circumstance, if the realm name is Microsoft, the correct syntax is to specify the realm name as a prefix. When a user logs on with the account name user1, the user enters the string “user1,” but does not enter a realm name. The Connection Manager profile automatically appends the realm name to user1 and sends the following user name to the NAS: MICROSOFT\user1.

For more information, see “Pattern Matching Syntax” later in this section.

RADIUS User-Name Attribute

During the authentication phase of the connection attempt, the user name is passed from the access client to the access server. The access server creates an Access-Request message, using the user name as the value for the RADIUS attribute User-Name. The access server, which is configured as a RADIUS client to an IAS server or IAS proxy, sends the Access-Request message containing the User-Name attribute to the IAS server or proxy.

The IAS server evaluates the Access-Request message against the set of configured connection request policies. Connection request policies are a set of conditions and profile settings that determine, for any incoming RADIUS request message, whether the message is processed locally or forwarded to another RADIUS server. The realm name, contained in the RADIUS User-Name attribute, can be specified in the connection request policy and assist IAS in determining how to route connection requests.

Using Realm Names to Route Connection Requests

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 (a remote RADIUS server group) 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 in 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.

IAS attribute manipulation rules use regular expression 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 by IAS to determine whether to process the message locally or to forward the message to a remote RADIUS server group:

• When IAS is configured as a RADIUS server, the Access-Request message is processed locally

• When IAS is configured as a RADIUS proxy, the Access-Request message is forwarded to another RADIUS server that is configured as a member of a remote RADIUS server group.

Pattern Matching Syntax

IAS supports 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, “Pattern Matching Syntax Characters.”

Pattern Matching Syntax Characters

Character	Description	Example
\	Marks the next character as a character to match.	/“n”/ matches the character “n”. The seque“n”ce /\“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,}	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 “foooood.”
[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 “p”lain.
\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 illustrate 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 illustrate the use of the pattern matching syntax to manipulate realm names for the User-Name attribute. In the first example, the realm name is removed before the message is forwarded by an IAS proxy to an IAS server. In the other examples, additional variations of realm name manipulation are demonstrated.

To remove the realm portion of the User-Name attribute

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. A recommended syntax for routing requests based on realm name follows:

• NetBIOS name: WCOAST

• Pattern: ^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 as follows:

• NetBIOS name: WCOAST

• UPN suffix: wcoast.microsoft.com

• Pattern: ^wcoast\\|@wcoast\.microsoft\.com$

Remote RADIUS Server Groups

A remote RADIUS server group is a named group that contains one or more RADIUS servers to which messages are forwarded by the RADIUS proxy. When IAS is being used as a RADIUS proxy for RADIUS request messages, a remote RADIUS server group must be specified. You can specify various settings to determine the order in which the servers are used by the proxy server. You can also specify how the proxy distributes the RADIUS messages across the 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.

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

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

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, it is recommended that you 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.

Authentication Across Forests

With IAS as a RADIUS proxy configured to forward messages to remote RADIUS server groups in different forests, you can authenticate users across forests. For example, if you have NASs in a perimeter network that serves users from two forests, you can configure the NASs as RADIUS clients to a RADIUS proxy server. At the proxy server you can configure two remote RADIUS server groups, each group containing the RADIUS servers in one forest. When a user connects to a NAS, the RADIUS proxy examines the realm portion of the user name and forwards the message to the remote RADIUS server group for authentication in the Active Directory user accounts database for that forest.

Using Remote RADIUS Server Groups to Focus Accounting

In some circumstances, you might want to assign the task of logging RADIUS accounting data to one or more remote RADIUS server groups, while assigning the task of processing authentication requests to other remote RADIUS server groups. This configuration is especially useful in organizations that regularly query RADIUS accounting data for network access troubleshooting and report creation. If you use IAS as a RADIUS proxy to route accounting data to one or more remote RADIUS server groups, you can configure the RADIUS servers in the remote RADIUS server groups to log to a central SQL Server database. Help desk and other applications can then query this database for comprehensive data views of network access sessions. Fore more information about IAS SQL Server logging, see “IAS Accounting” earlier in this section.

Processing a Connection Request

When an IAS server receives a valid RADIUS message from a RADIUS client, the RADIUS message is processed based on the following:

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.

2. If all the conditions of the policy do not match the RADIUS message, then go to next policy. If there are no more policies and the RADIUS message is an Access-Request message, an Access-Reject message is immediately sent.

3. If all the conditions of the policy match the RADIUS message, then apply the attribute manipulation rules configured in the policy.

4. If the RADIUS message is an Access-Request message, check the authentication settings on the matching connection request policy profile:

   • If the authentication setting is to authenticate using this server, use either the local SAM in Windows Server 2003 or Active Directory for authentication and the local remote access policies and user account dial-in properties for authorization.

   • If the authentication setting is to forward the request to a specific remote RADIUS server group, forward the Access-Request message containing the attribute(s) changed by the attribute manipulation rules to the appropriate RADIUS server in the group based on the priority and weight settings.

   • If the authentication setting is to accept the connection attempt without performing authentication or authorization, send back an Access-Accept message immediately.

5. If the RADIUS message is an accounting 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 containing the attribute(s) changed by the attribute manipulation rules to the appropriate RADIUS server in the group on the basis of priority and weight settings.

   • Based on the settings for remote access logging, log the accounting message in the IAS accounting log.

Using IAS as a RADIUS Proxy for Load Balancing

IAS proxies, placed between access servers and IAS servers, can be used to balance the load of a large volume of authentication traffic. The following figure, "RADIUS Proxy Load Balancing," illustrates how IAS proxies are used for load balancing authentication requests to multiple IAS servers.

RADIUS Proxy Load Balancing

By using IAS as a RADIUS proxy, you can evenly distribute authentication, authorization, and accounting traffic across all the IAS servers in the organization. This load balancing solution is easily scaled up and out as your organization grows, and as you add more NASs and IAS servers.

Additionally, when you use IAS as a RADIUS proxy for load balancing, there is a consistent scheme for failure detection and RADIUS server failover.

Primary characteristics of load balancing include:

1. Active Directory is configured for user accounts and groups. Ensure that all users that are making network access connections have a corresponding user account. Also organize remote access by group to take advantage of group-based remote access policies.

2. Configure IAS as a RADIUS server on each domain controller. Configure IAS to read the user account properties in Active Directory, and configure the IAS proxies as RADIUS clients to the IAS servers.

3. Configure one or more IAS proxy servers. Configure NASs as RADIUS clients to the proxy servers. Use the New Remote RADIUS Server Group Wizard to create a custom remote RADIUS server group, and create a connection request policy that forwards RADIUS request messages to the IAS servers where the realm name matches the accounts in the domain. Also delete the default connection request policy.

4. Configure each access server to use the IAS proxies for the authentication, authorization, and accounting of network connections.

Mapping Network Authentication and Authorization

You can use IAS proxy to split network access authorization and authentication between two user account databases. For example, you can configure IAS to authenticate visitors (such as employees of a partner organization) by using their password-based credentials stored in the external partner organization user database, while performing authorization, using an account created for the visitor, in your local Active Directory user account database.

To split authentication and authorization between two user account databases, you must create a local user account for each visitor. The visitor account user name must map to an account with the same user namein the partner organization user database. 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.

Configuring Visitor User Accounts

If you use 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:

1. Add the user principal name suffix to the domain.

2. Create an organizational unit that contains the user accounts for visitors.

3. 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 visitor’s user logon name at Microsoft Corporation is “user”@microsoft.com, designate “user” as the User logon namein the Active Directory Users and Computers snap-in.

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

5. Configure other user account properties as needed. Make sure that the user account is configured in a way that allows the visitor to have network access, but also contains 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.

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

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

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

• Ensure that NASs are configured as RADIUS clients to this IAS proxy.

  When visitors log on to your network, they do so through NASs, such as wireless APs. These APs must be configured as RADIUS clients to your IAS proxy server.

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.

Note

• 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 also change the user name in your user account database.

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 tasks:

• Create a user account for each visitor.

  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.

• Perform cross-certification or authorize the partner organization CA as a qualified subordinate certification authority using a computer running Windows Server 2003, Enterprise Edition 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 Windows XP. If your domains are Windows 2000 native, it is recommended that you use a certificate trust list (CTL) instead.

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

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

• Configure a remote access policy for visitor access.

• Ensure that NASs are configured as RADIUS clients to this IAS server.

When visitors log on to your network, they do so through NASs, such as wireless APs. These APs must be configured as RADIUS clients to your IAS proxy server or IAS server.

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 Windows Server 2003, Enterprise Edition 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 Windows XP. If your domains are Windows 2000 native, it is recommended that you use a certificate trust list (CTL) instead.

• Create one user account and map the partner organization certificate to the 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.

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

• Ensure that NASs are configured as RADIUS clients to this IAS server.

• Configure a remote access policy for visitor access.

When visitors log on to your network, they do so through NASs, such as wireless APs. These APs must be configured as RADIUS clients to your IAS proxy server or IAS server.

Note

• For strong security between your IAS proxy server and your partner organization RADIUS servers, you can use Internet Protocol security (IPSec).