IBM Tivoli and Cisco 사용자 설명서

 Chapter 7. Network enforcement subsystem implementation 

One of the most common methods of deploying an ACS is to use an external 
user database, such as Active Directory, or using a token server, for user and 
machine authentication. We did not use this method in the writing of this book. 
However, should you require information about how to do this, please refer to the 
following URL:

There are a few different scenarios for the 

. In the simplest sense, 

an unknown user is one that does not have a valid user account, either on the 
ACS (if it is providing the authentication) or on an external user database, such 
as Microsoft Active Directory, but has the CTA with supplicant installed. In this 
case, the user will be prompted to enter their dot1x credentials, which will of 
course fail. This is by design, and the user will be kept off the network. The way 
to address this is that the user would have to log a call with the Helpdesk to have 
her account created or recreated.

If a client tries to connect who does not have the CTA installed in a NAC L2 
802.1x environment, there is no way to authenticate them via dot1x, nor is there 
any way to validate their posture. It does not matter whether they have a valid 
user account, as there is no way that their credentials can get to the ACS. The 
way to address this issue is to use the 

 option in the switch 

configuration on all NAC-enabled switches. In our scenario, this was VLAN15, 
our 

 VLAN. The access lists applied to this VLAN allowed for 

DNS and Internet access only. All other traffic is denied. Note that 

. There is nothing to do on the ACS. 

Once the user has an IP address for the guest-vlan, there will be an entry in the 
ACS under 

.

This concludes the details for the Cisco Secure ACS server configuration for 
NAC L2 802.1x.

This section documents the changes that must be made to the previous section 
to configure the ACS for a NAC deployment using L2IP or L3 

 IEEE 

802.1x.