This document describes how to configure Extensible Authentication
Protocol–Transport Layer Security (EAP-TLS) with Cisco Secure Access Control
System (ACS) for Windows version 3.2.

Note: Machine authentication is not supported with Novell Certificate
Authority (CA). ACS can use EAP-TLS to support machine authentication to
Microsoft Windows Active Directory. The end user client might limit the
protocol for user authentication to the same protocol that is used for machine
authentication. That is, use of EAP-TLS for machine authentication might
require the use of EAP-TLS for user authentication. For more information about
machine authentication, refer to the
Machine
Authentication section of the User Guide for Cisco Secure
Access Control Server 4.1.

The information presented in this document was created from devices in
a specific lab environment. All of the devices used in this document started
with a cleared (default) configuration. If you are working in a live network,
ensure that you understand the potential impact of any command before using
it.

Both EAP-TLS and Protected Extensible Authentication Protocol (PEAP)
build and use a TLS/Secure Socket Layer (SSL) tunnel. EAP-TLS uses mutual
authentication in which both the ACS (authentication, authorization, and
accounting [AAA]) server and clients have certificates and prove their
identities to each other. PEAP, however, uses only server-side authentication;
only the server has a certificate and proves its identity to the client.

Choose the wireless network from the list of available networks,
and then click Configure.

On the Authentication tab, check the Enable IEEE 802.1x
authentication for this network check box.

Choose Smart Card or other Certificate from the
EAP type drop-down list, and then click Properties.

Note: In order to enable machine authentication, check the
Authenticate as computer when computer information is
available check box.

Click the Use a certificate on this computer radio
button, and then check the Use simple certificate selection
check box.

Check the Validate server certificatecheck box,
and click OK.

Note: When the client joins the domain, the CA's certificate is
installed automatically as a Trusted Root Certification Authority. The client
automatically implicitly trusts the CA that signed the client's certificate.
Additional CAs can be trusted by checking them in the Trusted Root
Certification Authorities list.

On the Association tab of the network properties window, check the
Data encryption (WEP enabled) and The key is provided
for me automatically check boxes.

Click OK, and then click OK again
in order to close the network configuration window.

This section provides information you can use to troubleshoot your
configuration.

Verify that MS Certificate Services has been installed as an
Enterprise root CA on a Windows 2000 Advanced Server with Service Pack
3.

Verify that you are using Cisco Secure ACS for Windows version 3.2
with Windows 2000 and Service Pack 3.

If machine authentication fails on the wireless client, there will be
no network connectivity on the wireless connection. Only accounts that have
their profiles cached on the wireless client will be able to log in to the
domain. The machine must be plugged in to a wired network or set for wireless
connection with no 802.1x security.

If automatic enrollment with the CA fails when it joins the domain,
check Event Viewer for possible reasons.

If the wireless client's user profile does not have a valid
certificate, you can still log on to the machine and domain if the password is
correct, but note that the wireless connection will not have
connectivity.

If the ACS certificate on the wireless client is invalid (which
depends on the certificate's valid "from" and "to" dates, the client's date and
time settings, and CA trust), then the client will reject it and authentication
will fail. The ACS will log the failed authentication in the web interface
under Reports and Activity > Failed Attempts > Failed Attempts
XXX.csv with the Authentication Failure-Code similar to "EAP-TLS or
PEAP authentication failed during SSL handshake." The expected error message in
the CSAuth.log file is similar to this message:

If the client's certificate on the ACS is invalid (which depends on
the certificate's valid "from" and "to" dates, the server's date and time
settings, and CA trust), then the server will reject it and authentication will
fail. The ACS will log the failed authentication in the web interface under
Reports and Activity > Failed Attempts > Failed Attempts
XXX.csv with the Authentication Failure-Code similar to "EAP-TLS or
PEAP authentication failed during SSL handshake." If the ACS rejects the
client's certificate because the ACS does not trust the CA, the expected error
message in the CSAuth.log file is similar to this message:

In the logs on the ACS web interface, under both Reports and
Activity > Passed Authentications > Passed Authentications
XXX.csv and Reports and Activity > Failed Attempts >
Failed Attempts XXX.csv, EAP-TLS authentications are shown in the
format <user-id>@<domain>. PEAP authentications are shown in the
format <DOMAIN>\<user-id>.

You can verify the ACS server's certificate and trust by following
the steps below.

Log in to Windows on the ACS server with an account that has
administrator privileges.

Go to Start > Run, type mmc,
and click OK in order to open the Microsoft Management
Console.

On the menu bar, go to Console > Add/Remove
Snap-in, and click Add.

Choose Certificates, and click
Add.

Choose Computer account, click
Next, and then choose Local computer (the computer
this console is running on).

Click Finish, click Close, and
then click OK.

In order to verify that the ACS server has a valid server-side
certificate, go to Console Root > Certificates (Local Computer) >
Personal > Certificates, and verify that there is a certificate for
the ACS server (named OurACS in this example).

Open the certificate, and verify these items:

There is no warning about the certificate not being verified for
all its intended purposes.

There is no warning about the certificate not being
trusted.

"This certificate is intended to - Ensures the identity of a
remote computer."

The certificate has not expired and has become valid (check for
valid "from" and "to" dates).

"You have a private key that corresponds to this
certificate."

On the Details tab, verify that the Version field has the value V3
and that the Enhanced Key Usage field has Server Authentication
(1.3.6.1.5.5.7.3.1).

In order to verify that the ACS server trusts the CA server, go to
Console Root > Certificates (Local Computer) > Trusted Root
Certification Authorities > Certificates, and verify that there is
a certificate for the CA server (named Our TAC CA in this example).

Open the certificate, and verify these items:

There is no warning about the certificate not being verified for
all its intended purposes.

There is no warning about the certificate not being
trusted.

The certificate's intended purpose is correct.

The certificate has not expired and has become valid (check for
valid "from" and "to" dates).

If the ACS and client did not use the same root CA, then verify
that the whole chain of CA servers' certificates have been installed. The same
applies if the certificate was obtained from a subcertificate
authority.

You can verify the wireless client's machine certificate and trust by
following the steps below.

Log in to Windows on the ACS server with an account that has
administrator privileges. Open Microsoft Management Console by going to
Start > Run, typing mmc, and clicking
OK.

On the menu bar, go to Console > Add/Remove
Snap-in, and then click Add.

Select Certificates and click
Add.

Select Computer account, click
Next, and then select Local computer (the computer
this console is running on).

Click Finish, click Close, and
then click OK.

Verify that the machine has a valid client-side certificate. If the
certificate is invalid, machine authentication will fail. To verify the
certificate, go to Console Root > Certificates (Local Computer) >
Personal > Certificates. Verify that there is a certificate for the
machine; the name will be in the format <host-name>.<domain>. Open
the certificate and verify the following items.

There is no warning about the certificate not being verified for
all its intended purposes.

There is no warning about the certificate not being
trusted.

"This certificate is intended to - Proves your identity to a
remote computer."

The certificate has not expired and has become valid (check for
valid "from" and "to" dates).

"You have a private key that corresponds to this
certificate."

On the Details tab, verify that the Version field has the value V3
and that the Enhanced Key Usage field contains at least the value Client
Authentication (1.3.6.1.5.5.7.3.2); additional purposes may be listed. Ensure
that the Subject field contains the value CN =
<host-name>.<domain>;
additional values may be listed. Verify that the host-name and domain match
what is specified in the certificate.

To verify that the client's profile trusts the CA server, go to
Console Root > Certificates (Current User) > Trusted Root
Certification Authorities > Certificates. Verify that there is a
certificate for the CA server (named Our TAC CA in this example). Open the
certificate and verify the following items.

There is no warning about the certificate not being verified for
all its intended purposes.

There is no warning about the certificate not being
trusted.

The certificate's intended purpose is correct.

The certificate has not expired and has become valid (check for
valid "from" and "to" dates).

If the ACS and client did not use the same root CA, then verify that
the whole chain of CA servers' certificates have been installed. The same
applies if the certificate was obtained from a subcertificate
authority.

Verify that the user account exists in the internal database of the
AAA server or on one of the configured external databases, and ensure that the
account has not been disabled.

Certificates issued by the CA built on the Secure Hash Algorithm 2
(SHA-2) are not compatible with Cisco Secure ACS since they are developed with
Java which does not support SHA-2 as of now. In order to resolve this issue,
reinstall the CA and configure it to issue certificates with
SHA-1.