NAC Appliance (CCA): Configure and Troubleshoot the Active Directory Windows Single Sign On

[LEFT][CODE]http://www.cisco.com/en/US/products/ps6128/products_configuration_example09186a0080884229.shtml[/CODE]
[B][B][SIZE=3]NAC Appliance (CCA): Configure and Troubleshoot the Active Directory Windows Single Sign On (SSO)[/SIZE][/B][/B]


[B]Document ID: 97251[/B]


[B]Contents[/B]
[INDENT] [B] Introduction
[/B] [B] Prerequisites
Requirements
Components Used
Conventions
[/B] [B] Configure Windows SSO
Set up the AD SSO Provider
Run KTPass on the DC
SSO Configuration on the CAS
SSO Service Started
Open Ports to the DC
Client Sees Agent Performing SSO
SSO Completed
SSO User Seen on the Online User List
[/B] [B] Troubleshoot Windows SSO
Could not Start the SSO Service. Please check the configuration.
Problem : Client Authentication does not Work
SSO Service is Started, but Client does not Perform SSO
Kerbtray
CAS Logs – Cannot Start SSO Service
Known Issues
[/B] [B] Cisco Support Community - Featured Conversations
[/B] [B] Related Information [/B] [/INDENT][B] Introduction [/B]

This document describes how to configure and troubleshoot the Cisco Network Admission Control (NAC) Appliance, formerly known as Cisco Clean Access (CCA), using Microsoft® Windows Active Directory (AD) Single Sign On (SSO).
[B] Prerequisites [/B]

[B] Requirements [/B]

Ensure that you meet these requirements before you attempt this configuration:

[LIST][*] Make sure the DC runs Win2K SP4/Win2K3 (Standard or Enterprise) SP1 or Win 2K3 R2. Win 2K3 without SP1 is not supported.[*] Make sure Windows SSO is supported in an AD environment only. Windows NT environment is not supported. Clean Access Agent is a must.[*] Set up the Clean Access Server (CAS) account as shown in the [URL="http://www.cisco.com/en/US/docs/security/nac/appliance/configuration_guide/412/cas/412_cas_book.html"]Cisco NAC Appliance - Clean Access Server Installation and Configuration Guide, Release 4.1(2)[/URL].[/LIST]
[B] Components Used [/B]

The information in this document is based on the NAC Appliance software version 4.x or later.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
[B] Conventions [/B]

Refer to [URL="http://www.cisco.com/en/US/tech/tk801/tk36/technologies_tech_note09186a0080121ac5.shtml"]Cisco Technical Tips Conventions[/URL] for more information on document conventions.
[B] Configure Windows SSO [/B]

In this section, you are presented with the information to configure the features described in this document.
[B] Set up the AD SSO Provider [/B]

[IMG]http://www.cisco.com/image/gif/paws/97251/nac-ad-sso1.gif[/IMG]

[LIST][*] You cannot perform an authentication test to an AD SSO provider or a VPN SSO.[*] The LDAP lookup server is needed only if the users want to do mapping rules for the AD SSO, so that after AD SSO, the users will be placed in roles based on AD attributes. This is not needed to get the basic SSO working (without role mapping).[/LIST]
[B] Run KTPass on the DC [/B]

KTPass is a tool available as a part of Windows 2K/2K3 support tools. Refer to [URL="http://www.cisco.com/en/US/docs/security/nac/appliance/configuration_guide/412/cas/412_cas_book.html"]Cisco NAC Appliance - Clean Access Server Installation and Configuration Guide, Release 4.1(2)[/URL] for more information.
When you run KTPass, it is important to note that the computer name that always falls between the “/” and the “@” matches the name of the DC as it would appear under Control Panel >> System >> Computer Name >> Full Computer Name on the DC.
Also, make sure that the realm name that appears after @ highlighted is always in upper case letters.[INDENT] C:\Program Files\Support Tools>ktpass -princ
ccasso/[I]prem-vm-2003.win2k3.local[/I]@[B]WIN2K3.LOCAL[/B] -mapuser ccasso
-pass Cisco123 -out c:\test.keytab -ptype KRB5_NT_PRINCIPAL +DesOnly
Using legacy password setting method
[B]Successfully mapped ccasso/prem-vm-2003.win2k3.local to ccasso. //confirms ccasso acct is mapped[/B]
Key created.
Output keytab to c:\test.keytab
Keytab version: 0x502
keysize 80 ccasso/prem-vm-2003.win2k3.local@WIN2K3.LOCAL ptype 1
(KRB5_NT_PRINCIPAL) vno 3 etype 0x17 (RC4-HMAC) keylength 16
(0xf2e787d376cbf6d6dd3600132e9c215d)
Account ccasso has been set for DES-only encryption.[/INDENT]In order to support Windows 7, you must run KTPASS as shown in this example:[INDENT] C:\Program Files\Support Tools>KTPASS.EXE -princ
newadsso/[I][adserver.]domain.com[/I]@[B]DOMAIN.COM[/B] -mapuser newadsso
-pass PasswordText -out c:\newadsso.keytab -ptype KRB5_NT_PRINCIPAL[/INDENT]Also, make sure that the realm name that appears after @ highlighted is always in upper case letters.
[B] SSO Configuration on the CAS [/B]

Choose [B]CCA Servers >> Manage >> Authentication >> Windows Auth >> Active Directory SSO[/B] in order to get into the AD window.

[LIST=1][*] Active Directory Domain = Kerberos realm name = Needs to be upper case.[*] Active Directory Server (FQDN)—Make sure that the CAS can resolve this name via DNS. This field cannot be an IP address. In this example, log on to the CAS via Secure Shell (SSH) and perform “nslookup prem-vm-2003.win2k3.local”. Then, make sure it resolves successfully.[*] Make sure FQDN matches the name of the AD server (DC) exactly as it appears under Control Panel > System > Computer Name | Full computer name on the AD server machine (DC).[/LIST]
[IMG]http://www.cisco.com/image/gif/paws/97251/nac-ad-sso2.gif[/IMG]
[B] SSO Service Started [/B]

Complete these steps:

[LIST=1][*] Confirm that the SSO service has been started as shown under [B]CCA Servers>>Manage>>Status[/B].
[IMG]http://www.cisco.com/image/gif/paws/97251/nac-ad-sso3.gif[/IMG][*] Confirm that the CAS now listens on TCP 8910 (used for Windows SSO).
[INDENT] [root@cs-ccas02 ~]#[B]netstat -a | grep 8910[/B]
tcp 0 0 *:8910 *:*
LISTEN[/INDENT][/LIST]
[B] Open Ports to the DC [/B]

Complete these steps:

[LIST=1][*] Open the appropriate ports to the DC.[*] For testing, always open complete access to the DC. Then, once SSO works, you can tie it down to specific ports.
[B]Note: [/B]Make sure the following ports are allowed in the untrusted role to Active Directory:
[LIST][*] [B] TCP[/B]: 88, 135, 445, 389/636, 1025, 1026[*] [B] UDP[/B]: 88, 389[/LIST]
[B]Note: [/B] [I]TCP PORT 445[/I] must be open for Windows Password Reset to work correctly.
[*] Ensure that the client runs CCA Agent 4.0.0.1 or later.[*] Log into the PC using the Windows Domain credentials. Make sure you are logging into the domain and not the local account.[/LIST]
[B] Client Sees Agent Performing SSO [/B]

[IMG]http://www.cisco.com/image/gif/paws/97251/nac-ad-sso4.gif[/IMG]
[B] SSO Completed [/B]

[IMG]http://www.cisco.com/image/gif/paws/97251/nac-ad-sso5.gif[/IMG]
[B] SSO User Seen on the Online User List [/B]

[IMG]http://www.cisco.com/image/gif/paws/97251/nac-ad-sso6.gif[/IMG]
[B] Troubleshoot Windows SSO [/B]

[B] Could not Start the SSO Service. Please check the configuration. [/B]

[IMG]http://www.cisco.com/image/gif/paws/97251/nac-ad-sso7.gif[/IMG]
Complete these steps:

[LIST=1][*] Check to make sure KTPass runs correctly. It is important to check the fields as mentioned in slide X. If KTPass was run incorrectly, delete the account and create a new account on AD and run KTPass again.[*] Make sure time on the CAS is synchronized with the DC.
This step can be performed by pointing them both to the same time server. In lab setups, point the CAS to the DC itself for time (DC runs Windows time). Kerberos is sensitive to clock and the skew cannot be greater than 5 minutes (300 secs).
[B]Note: [/B]When you try to start the AD SSO service of the CAS, an issue might occur with the time syncronization, NTP. If NTP is configured, and clocks are not syncronized, services will not work. Once fixed the services should work.[*] Make sure the Active Directory Domain is in upper case (Realm) and the CAS can resolve FQDN in DNS. For lab setups, you can point to a DC that runs DNS (AD requires at lease one DNS server).[*] Log into CAS directly as https://<[I]CAS-IP-address[/I]>/admin. Then, click [B]Support Logs[/B] and change the logging level for the Active Directory Communication Logging to [B]Info[/B].
[IMG]http://www.cisco.com/image/gif/paws/97251/nac-ad-sso8.gif[/IMG][*] Re-create the problem and download the support logs.[/LIST]
[B] Problem : Client Authentication does not Work [/B]

AD SSO service is started, but client authentication does not work.
[B]Solution[/B]
UDP ports were not open in the unauthenticated role. After you add these ports to the traffic policies, authentication should work.
[B] SSO Service is Started, but Client does not Perform SSO [/B]

This is usually due to some communication issue between the DC/client PC or between the client PC and the CAS.
These are a few things to make sure of:

[LIST][*] Client has Kerberos keys.[*] Ports are open to the DC so the client can connect, receive agent logs, and receive logs on the CAS.[*] Time or clock on the client PC is synchronized with the DC.[*] Confirm CAS is listening on port 8910. A sniffer trace on the client PC will also help.[*] CCA Agent is 4.0.0.1 or later.[*] User is actually logged in using the domain account and not using the local account.[/LIST]
[B] Kerbtray [/B]

Kerbtray can be used to confirm that the client has obtained the Kerberos Tickets (TGT and ST). The concern is for the Service Ticket (ST), which is for the CAS account that you created on the DC.
Kerbtray is a free tool available from Microsoft Support tools. It can also be used to purge the Kerberos Tickets on a client machine.
A green Kerbtray Icon on the system tray indicates that client has active Kerberos Tickets. However, you need to verify that the ticket is correct (valid) for the CAS account.
[IMG]http://www.cisco.com/image/gif/paws/97251/nac-ad-sso9.gif[/IMG]
[B] CAS Logs – Cannot Start SSO Service [/B]

The log file of interest on the CAS is /perfigo/logs/perfigo-redirect-log0.log.0.
[B]AD SSO Service does not start on CAS is a CAS-DC communication issue:[/B]

[LIST=1][*] [INDENT] [B]SEVERE: startServer - SSO Service authentication failed.
Clock skew too great (37)[/B]
Aug 3, 2006 7:52:48 PM com.perfigo.wlan.jmx.admin.GSSServer loginToKDC[/INDENT]This means the clock is not synchronized between the CAS and the domain controller.[*] [INDENT] Aug 21, 2006 3:39:11 PM com.perfigo.wlan.jmx.admin.GSSServer loginToKDC
INFO: GSSServer - [B]SPN : [ccass/PreM-vM-2003.win2k3public.local@WIN2K3PUBLIC.LOCAL][/B]
Aug 21, 2006 3:39:11 PM com.perfigo.wlan.jmx.admin.GSSServer loginToKDC
[B]SEVERE: startServer - SSO Service authentication failed.
Client not found in Kerberos database (6)[/B]
Aug 21, 2006 3:39:11 PM com.perfigo.wlan.jmx.admin.GSSServer startServer
[B]WARNING: GSSServer loginSubject could not be created.[/B][/INDENT]This means the username is incorrect. Note the wrong username “ccass”, error code 6 and the last warning.[*] [INDENT] Aug 21, 2006 3:40:26 PM com.perfigo.wlan.jmx.admin.GSSServer loginToKDC
INFO: GSSServer - SPN : [ccasso/PreM-vM-2003.win2k3public.local@WIN2K3PUBLIC.LOCAL]
Aug 21, 2006 3:40:26 PM com.perfigo.wlan.jmx.admin.GSSServer loginToKDC
[B]SEVERE: startServer - SSO Service authentication failed.
Pre-authentication information was invalid (24)[/B]
Aug 21, 2006 3:40:26 PM com.perfigo.wlan.jmx.admin.GSSServer startServer
[B]WARNING: GSSServer loginSubject could not be created.[/B][/INDENT]The password is incorrect or realm is invalid (not in upper case?). Bad FQDN? KTPass runs incorrectly? Note the Error 24 and the last warning.
[B]Note: [/B]Make sure that the KTPass version is 5.2.3790.0. Unless there is a bad version of KTPass that even if the script is run properly, the SSO service will not start.[/LIST]
[B]Client – CAS Communication Issue:[/B] [INDENT] Aug 3, 2006 10:03:05 AM com.perfigo.wlan.jmx.admin.GSSHandler run
[B]SEVERE: GSS Error: Failure unspecified at GSS-API level
(Mechanism level: Clock skew too great (37))[/B][/INDENT]This error is seen when the client PC time is not synchronized with the DC.
[B]Note: [/B]The difference between this error and the one where the CAS time is not synchronized with the DC.
[B] Known Issues [/B]


[LIST][*] Cisco bug ID [URL="http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCse64395"]CSCse64395[/URL] ([SIZE=-1] [URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) —4.0 Agent does not resolve DNS for Windows SSO.
This issue is resolved in CCA Agent 4.0.0.1.[*] Cisco bug ID [URL="http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCse46141"]CSCse46141[/URL] ([SIZE=-1] [URL="http://tools.cisco.com/RPF/register/register.do"]registered[/URL] customers only[/SIZE]) —SSO fails in case CAS cannot reach the AD server during startup.
The workaround is to go to [B]CCA Servers > Manage [CAS_IP] Authentication > Windows Auth > Active Directory SSO[/B], and click [B]Update[/B] in order to restart the AD SSO service.[*] Perform a service perfigo restart on the CAS. There is a caching issue when the old credentials are cached on the CAS and it does not use the new one until Tomcat is restarted.[*] You cannot limit single user log in for SSO. This is the normal behavior for SSO because it is a kerberos protocol, and there is no option to limit single user log in a kerberos protocol.[*] [I]Windows 7[/I] and [I]Windows 2008[/I] does not [URL="http://support.microsoft.com/kb/977321"]support[/URL] SSO as SSO uses [B]DES[/B] encryption that is not supported by both Windows 7 and Windows 2008[/LIST]

[/LEFT]