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

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

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.

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

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.

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

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

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.

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

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

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.

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

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

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

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.

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.

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.

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.

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.

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

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.

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

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.
  
  

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

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.
  
  

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.

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.

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.

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

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

EAP-authenticated communication

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

TLS caching of certificate properties

Deploying PEAP

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

PEAP-TLS

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.
  
  

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.
  
  

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.
    
    

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

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.

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

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

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.

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.
   
   

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

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.
     
     

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
     
     

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

You can use remote access policies to manage authorization by user or by group.

Authorization by user

Authorization by group

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.

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)

Verify Caller ID

Callback Options

Assign a Static IP Address

Apply Static Routes

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

• Conditions
  
  
• Remote access permission
  
  
• Profile
  
  

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

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.

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.

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
  
  

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.
  
  

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.

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.

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.

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.
  
  

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.

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.
  
  

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.
     
     

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.

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

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.

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

MSDE 2000 database

Stored procedure

Custom accounting-forwarder component

SQL server

IAS database

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

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

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.
  
  

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.
  
  

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.
    
    

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.
  
  

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.
  
  

Find: @microsoft\.com

Replace:

Find: (.*)@(.*)

Replace: $2\$1

Find: (.*)\\(.*)

Replace: specific_domain\$2

Find: $

Replace: @specific_domain