IAS Step-by-Step Authentication and Authorization

The diagram shown in Figure 8.6a and Figure 8.6b demonstrates the step-by-step IAS authentication and authorization process.

Note

The authentication and authorization process for the Routing and Remote Access service, when configured for Windows authentication, uses steps 4 through 14 of this process. In all steps, no RADIUS packets are sent. The authentication and authorization success and failure are the return values of functions called by the Routing and Remote Access service. Local event or authentication logging depends on the configured logging settings of the Routing and Remote Access service. For more information, see " Routing and Remote Access Service " in this book.

Figure 8.6a IAS Authentication and Authorization Process

Figure 8.6b IAS Authentication and Authorization Process

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

2. Check for Auto Reject
   Auto Reject is used to send an immediate Access-Reject packet when the User-Name attribute in the Access-Request packet matches a specific value. The periodic sending of an Access-Request packet and reception of an Access-Reject packet assures the RADIUS client that the RADIUS server is still present on the network. An Auto Reject Access-Request message requires special handling because it does not need to be evaluated for authentication and authorization. No authentication log entry is created for Auto Reject requests. This is done to prevent Auto Reject messages from filling up the authentication log file.
   To configure IAS for Auto Reject, configure the Ping User-Name registry setting (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IAS \Parameters) with the user name for Auto Reject packets. If the User-Name attribute of the Access-Request packet matches the Ping User-Name registry setting, an Access-Reject message is sent.

3. Apply realm stripping rules
   If the User-Name attribute in the Access-Request packet is not the Auto Reject name, then the user identity is determined. User identity is how IAS identifies the user for the purposes of authentication and authorization. Normally, the user identity is the string value of the User-Name RADIUS attribute. If the User-Name attribute is not present, the user identity is set to the Guest account or the account specified by the Default User Identity registry value (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services \RemoteAccess\Policy).
   However, IAS can use any RADIUS attribute to identify the user. The RADIUS attribute that IAS uses to identify the user is configurable by setting the User Identity Attribute registry setting (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy) to the number of the RADIUS attribute that is used for the user identity. By default, User Identity Attribute is set to 1, the RADIUS type value for the User-Name RADIUS attribute. For more information about the use of the User Identity Attribute registry setting, see "Unauthenticated Access" later in this chapter.
   Realm stripping rules are then applied and define how the user identity is manipulated before the name is checked for existence. The realm stripping rules consist of an ordered set of <Original string to match>, <Replacement String>. IAS applies the realm stripping rules to the user identity in the configured order. For information about how to configure realm stripping and examples of using pattern syntax to create realm stripping rules, see Windows 2000 Server Help.

4. Perform name cracking
   Name cracking is the resolution of the user identity to a user account using user principal names, Lightweight Directory Access Protocol (LDAP), distinguished names (DNA) Canonical Names, and so on. If a user principal name is encountered by IAS, IAS performs a query to the Active Directory Global Catalog in an attempt to resolve the name. To speed up this process, a copy of the Global Catalog must be located on a domain controller within the same site as the IAS server.
   When the user identity does not contain a domain name, IAS supplies a domain name. By default, the IAS-supplied domain name is the domain for which the IAS server is a member. You can specify the IAS-supplied domain through the DefaultDomain registry setting (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\ControlProtocols \BuiltIn).

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

6. Check for remote access account lockout
   After the authentication plug-ins are checked, the registry on the IAS server is read for the remote access account lockout entry for the user account. If the account is locked out through remote access account lockout, IAS sends an Access-Reject message back to the NAS and logs an authentication event.

Note

Remote access account lockout is a security feature that is enabled through the Windows 2000 registry. Remote access account lockout is used to prevent dictionary attacks against user accounts. For more information about remote access account lockout, see "Remote Access Server" in this book. Remote access account lockout is not related to account lockout on the Windows 2000 user account and the implementation of account lockout policies by using Windows 2000 Group Policy.

1. Check for MS-CHAP, CHAP, and PAP
   If the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) version 1 or version 2, CHAP, or Password Authentication Protocol (PAP) are used to authenticate the remote access client, IAS consults an authentication submodule based on the authentication protocol to perform the authentication. The user's credentials, the user name and password, are authenticated against the user name and password of the accounts database (a domain or the local accounts database) and the group membership of the user account is determined. The exact method of authentication varies depending on the authentication protocol.
   If the authentication of the credentials is not successful, an Access-Reject packet is sent and the authentication failure event is logged in the system event log or the IAS authentication log depending on the configured logging settings.
   If either EAP or unauthenticated access is being used, then the user authentication process is bypassed. EAP authentication takes place later in this process. For unauthenticated access, no user authentication is performed.

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

3. Perform policy evaluation
   Remote access policies configured on the IAS server are evaluated to find a policy that matches the parameters of the connection. If a matching policy is not found, an Access-Reject packet is sent and an event is logged. For more information about remote access policies and policy evaluation logic, see "Remote Access Policies" later in this chapter.

4. Obtain dial-in properties and merge with profile settings
   The dial-in properties for the user account associated with the connection and the profile properties from the matching policy are merged into a set of properties for the connection.

5. Check for EAP authentication
   If EAP is the authentication protocol used for the connection attempt, EAP authentication takes place. The initial negotiation for EAP consists of selecting EAP as the PPP authentication protocol and negotiating an EAP type. Based on the EAP type, the profile settings for the matching policy are checked to ensure that the EAP type is allowed. If the EAP type is not allowed with the profile settings, an Access-Reject packet is sent and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings.
   If the EAP type is allowed with the profile settings, EAP authentication for the EAP type occurs. IAS sends an EAP challenge to NAS asking it to start EAP negotiation. Communications between EAP dynamic-link libraries (DLLs) on a client and server side are tunneled between the client and the IAS server using the RADIUS protocol. After complete, an EAP provider can return attributes that are sent back to the NAS in the Access-Accept packet. If EAP authentication fails, an Access-Reject packet is sent and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings.

6. Check user properties and profile properties
   The dial-in properties of the user account and the profile properties of the matching remote access policy are evaluated against the parameters of the connection attempt to ensure that the connection attempt is allowed. If the connection attempt is not allowed, an Access-Reject packet is sent and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings.

7. Check for authorization plug-ins
   The existence of authorization plug-ins is checked. Authorization plug-ins are optional components created using the IAS SDK. Each plug-in can return either Reject or Continue. If the authorization plug-in returns a Reject, an Access-Reject packet is sent and the authentication failure event is logged in the system event log or the IAS authentication log, depending on the configured logging settings. If the authorization plug-in returns Continue, the next plug-in is checked. If there are no more plug-ins, the user is considered to be authorized.
   The authorization plug-in can also return RADIUS attributes to be included in the Access-Accept packet.

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