Authentication Methods for use with IAS
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Authentication methods
The authentication of access clients is an important security concern. Authentication methods typically use an authentication protocol that is negotiated during the connection establishment process. IAS also supports unauthenticated connections.
For information about using authentication methods, see the following:
Each authentication method has advantages and disadvantages in terms of security, usability, and breadth of support. The authentication method used is determined by the configuration of both the access server and client. Consult your access server documentation to determine which authentication methods are supported.
You can configure IAS to accept multiple authentication methods. You can also configure your access servers to attempt to negotiate a connection by using the most secure protocol first, and then the next most secure, and so on down to the least secure. For example, the Routing and Remote Access service tries to negotiate a connection using EAP first, then MS-CHAP v2, then MS-CHAP, then CHAP, then SPAP, and then PAP. When EAP is chosen as the authentication method, the negotiation of the EAP type occurs between the access client and the IAS server.
In addition, you can use remote access policies for various authentication methods, depending on the type of client being authenticated. For example, you can create two remote access policies, one for virtual private network (VPN) clients and one for wireless clients--each of which uses a different authentication method. The remote access policy for VPN clients can be configured to use EAP-TLS with smart cards or certificates as the authentication method and authentication type, while the remote access policy for wireless clients can be configured to use PEAP-EAP-MS-CHAP v2, which provides secure password authentication.
Certificate deployments and Active Directory replication
Some authentication methods, such as PEAP and EAP, can use certificates for authentication of computers and users. Latency in Active Directory replication might temporarily affect the ability of a client or server to obtain a certificate from a certification authority (CA). If a computer configured to use certificates for authentication cannot enroll a certificate, authentication fails.
For example, if a new computer running IAS is joined to the domain by a local domain controller, the IAS server is rebooted and Group Policy is applied. After Group Policy is applied and certificate autoenrollment is configured, the IAS server attempts to enroll a certificate with a CA. The CA queries Active Directory to determine whether the IAS server has the security permissions required to enroll a certificate. If the domain controller that joined the IAS server to the domain has replicated IAS server domain membership information across the domain, the CA can verify that the IAS server should receive a certificate. The CA then enrolls a certificate to the IAS server. You can manually refresh Group Policy by logging onto the domain or by running the gpupdate command.
When information about the IAS server domain membership has not replicated to other domain controllers and the CA queries a domain controller that does not yet have information about the IAS server, the CA cannot verify that the IAS server is running on a computer that is a domain member. Because the CA cannot verify that the IAS server has the security permissions to enroll a certificate, the CA does not enroll a certificate for the IAS server. As the result, authentication fails and the server cannot log on to the network.
For more information, see Network access authentication and certificates and Remote Access Policies.
Notes
IEEE 802.1x authentications for wireless and switch clients use only the PEAP and EAP authentication methods.
IAS also supports authentication for computer accounts.
When using the EAP-TLS authentication method with certificates, TLS uses cached certificate properties instead of reading the certificate from the certificate store. If a certificate is either changed or deleted and replaced by a new certificate, TLS continues using outdated cached certificate information until the cache expires or is refreshed. If you change or replace a certificate, you can refresh the TLS cache by restarting the server computer.