Chapter 7. Network enforcement subsystem implementation
283
External User Database
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:
http://www.cisco.com/en/US/partner/products/sw/secursw/ps2086/products_user_
guide_chapter09186a008052e944.html
Unknown user policy
There are a few different scenarios for the
unknown user
. 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.
Clientless user
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
guest-vlan
option in the switch
configuration on all NAC-enabled switches. In our scenario, this was VLAN15,
our
default Quarantine
VLAN. The access lists applied to this VLAN allowed for
DNS and Internet access only. All other traffic is denied. Note that
all of the
configuration for this is done on the switch
. 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
Failed Attempts
.
This concludes the details for the Cisco Secure ACS server configuration for
NAC L2 802.1x.
7.1.2 Configuring the Cisco Secure ACS for NAC L2/L3 IP
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
without
IEEE
802.1x.
Summary of Contents for Tivoli and Cisco
Page 2: ......
Page 16: ...xiv Building a Network Access Control Solution with IBM Tivoli and Cisco Systems...
Page 18: ...xvi Building a Network Access Control Solution with IBM Tivoli and Cisco Systems...
Page 20: ...2 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems...
Page 30: ...12 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems...
Page 56: ...38 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems...
Page 94: ...76 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems...
Page 110: ...92 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems...
Page 142: ...124 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems...
Page 225: ...Chapter 6 Compliance subsystem implementation 207 Figure 6 77 Client connection window...
Page 456: ...438 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems...
Page 458: ...440 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems...
Page 504: ...486 Building a Network Access Control Solution with IBM Tivoli and Cisco Systems...
Page 513: ...Building a Network Access Control Solution with IBM Tivoli and Cisco Systems...
Page 514: ......
Page 515: ......