IAS Authentication

In the process of identifying dial-up users and admitting them to a secure network or site, different servers handle different aspects of the task.

A network access server (NAS) operates as a client of an IAS server. The client is responsible for passing user information to designated IAS servers, and then acting on the response.

IAS is responsible for receiving user connection requests, authenticating the user, authorizing the connection attempt, and then returning all configuration information necessary for the RADIUS client to deliver service to the user. Figure 8.5 illustrates the general IAS authentication process.

Figure 8.5 IAS Authentication Process

When a user attempts to connect to a network through a dial-up connection or virtual private 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, NAS tries to negotiate a connection by using EAP, 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 packet.

3. The IAS server first verifies that the RADIUS Access-Request packet is sent from a configured RADIUS client by checking the source IP address. If the Access-Request packet was sent by a valid RADIUS client, and if digital signatures are enabled for the RADIUS client, the digital signature in the packet is checked using the shared secret. A shared secret is a text string that serves as a special password between RADIUS server and the RADIUS clients connected to it. Each IAS server must have a shared secret for each NAS or other IAS server that forwards RADIUS requests to it. There are a few rules you must follow to successfully set up a shared secret:

   • The shared secret must be exactly the same at both servers.

   • Secrets are case-sensitive.

   • Secrets can use any standard alphanumeric characters or any special characters.

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

5. If digital signatures are enabled and the verification of the digital signature is successful, the IAS server queries the Windows 2000–based 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.