Guest

Cisco NAC Appliance (Clean Access)

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

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

Document ID: 97251

Updated: Dec 01, 2008

   Print

Introduction

This document describes how to use Microsoft Windows Active Directory (AD) Single Sign On (SSO) in order to configure and troubleshoot the Cisco Network Admission Control (NAC) Appliance, formerly known as Cisco Clean Access (CCA).

Prerequisites

Requirements

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

Components Used

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.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Configure Windows SSO

The information in this section describes how to configure the features presented in this document.

Set up the AD SSO Provider

nac-ad-sso1.gif

  • 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).

Run KTPass on the DC

KTPass is a tool available as a part of Windows 2000/2003 support tools. Refer to Cisco NAC Appliance - Clean Access Server Installation and Configuration Guide, Release 4.1(2) 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.

C:\Program Files\Support Tools>ktpass -princ
	 ccasso/prem-vm-2003.win2k3.local@WIN2K3.LOCAL -mapuser ccasso
	 -pass Cisco123 -out c:\test.keytab -ptype KRB5_NT_PRINCIPAL +DesOnly
Using legacy password setting method
//confirms ccasso acct is mapped
Successfully mapped ccasso/prem-vm-2003.win2k3.local to ccasso.
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.

In order to support Windows 7, you must run KTPASS as shown in this example:

C:\Program Files\Support Tools>KTPASS.EXE -princ 
newadsso/[adserver.]domain.com@DOMAIN.COM -mapuser newadsso 
-pass PasswordText -out c:\newadsso.keytab -ptype KRB5_NT_PRINCIPAL

Also, make sure that the realm name that appears after @ highlighted is always in upper case letters.

Configure SSO on the CAS

Choose CCA Servers > Manage > Authentication > Windows Auth > Active Directory SSO in order to open the AD window, and verify these items:

  • 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. Using the values in this example, you can 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).

nac-ad-sso2.gif

Verify the SSO Service is Started

Complete these steps:

  1. Go to CCA Servers > Manage > Status in order to verify that the SSO service is started.

    nac-ad-sso3.gif

  2. Run this command in order to verify that the CAS now listens on TCP 8910 (used for Windows SSO).

    [root@cs-ccas02 ~]#netstat -a | grep 8910
       tcp        0      0 *:8910                      *:*
       LISTEN

Open Ports to the DC

In order to open the appropriate ports to the DC, complete these steps:

Note: For testing, always open complete access to the DC. Then, once SSO works, you can tie it down to specific ports.

  1. Make sure the following ports are allowed in the untrusted role to Active Directory:

    • TCP: 88, 135, 445, 389/636, 1025, 1026

    • UDP: 88, 389

    Note:  TCP PORT 445 must be open for Windows Password Reset to work correctly.

  2. Ensure that the client runs CCA Agent 4.0.0.1 or later.

  3. Log in to the PC with the Windows Domain credentials.

    Note: Make sure you are logging into the domain and not the local account.

Client Sees Agent Performing SSO

nac-ad-sso4.gif

SSO Completed

nac-ad-sso5.gif

SSO User Seen on the Online User List

nac-ad-sso6.gif

Troubleshoot Windows SSO

Error: Could not start the SSO service. Please check the configuration.

Problem

You receive this error:

nac-ad-sso7.gif

Solution

In order to resolve this issue, complete these steps:

  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.

  2. 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).

    Note: 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.

  3. 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).

  4. Log into CAS directly as https://<CAS-IP-address>/admin. Then, click Support Logs and change the logging level for the Active Directory Communication Logging to Info.

    nac-ad-sso8.gif

  5. Re-create the problem and download the support logs.

Client Authentication does not Work

Problem

AD SSO service is started, but client authentication does not work.

Solution

UDP ports were not open in the unauthenticated role. After you add these ports to the traffic policies, authentication should work.

Unable to run SSO on windows 7 PC

Problem

SSO is not working for machines that run the Windows 7 operating system.

Solution 1

In order to resolve this issue, enable DES encryption on machine that runs the Windows 7 operating system, and then re-run the KTPass. Complete these steps in order to enable DES on a Windows 7 PC:

  1. Log in to the Windows 7 client machine as an administrator.

  2. Go to Start > Control Panel > System and Security > Administrative Tools > Local Security Policy > Local Policies/Security > Options.

  3. Choose Network security > Configure encryption types allowed.

  4. On the Local Security Settings tab, check the check boxes to enable all options, except the Future encryption types option.

Solution 2

In order to resolve this issue, run this command on the Windows 2003 Server (if it needs to support Windows 7 as well):

C:\Program Files\Support Tools> ktpass.exe -princ 
casuser/cca-eng-domain.cisco.com@CCA-ENG-DOMAIN.CISCO.COM-mapusercasuser -pass 
Cisco123 -out c:\casuser.keytab -ptype KRB5_NT_PRINCIPAL

For more information, refer to Configure AD SSO in a Windows 7 Environment.

Unable to configure linux client support for a user in NAC environment

Problem

Unable to configure Linux client support for a user in NAC environment.

Solution

Web Agent or Agent are not supported on Linux. NAC supports Linux with Web Login only without any posture assessment. Once the machine is authenticated through the Web Login, the user should be assigned to a final user role that you configure. The user will then have access according to the traffic policy of the user role. Refer to the Cisco bug CSCti54517 (registered customers only) for more information.

SSO Service is Started, but Client does not Perform SSO

This is usually due to some communication issue between the DC/client PC or between the client PC and the CAS.

Here are a few things to verify:

  • 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.

Kerbtray

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.

nac-ad-sso9.gif

CAS Logs – Cannot Start SSO Service

The log file of interest on the CAS is /perfigo/logs/perfigo-redirect-log0.log.0.

AD SSO Service does not start on CAS is a CAS-DC communication issue:

  1. SEVERE: startServer - SSO Service authentication failed. 
    Clock skew too great (37)
    Aug 3, 2006 7:52:48 PM com.perfigo.wlan.jmx.admin.GSSServer loginToKDC

    This means the clock is not synchronized between the CAS and the domain controller.

  2. Aug 21, 2006 3:39:11 PM com.perfigo.wlan.jmx.admin.GSSServer loginToKDC
        INFO: GSSServer - SPN : [ccass/PreM-vM-2003.win2k3public.local@WIN2K3PUBLIC.LOCAL]
    Aug 21, 2006 3:39:11 PM com.perfigo.wlan.jmx.admin.GSSServer loginToKDC
    SEVERE: startServer - SSO Service authentication failed. 
    Client not found in Kerberos database (6)
    Aug 21, 2006 3:39:11 PM com.perfigo.wlan.jmx.admin.GSSServer startServer
    WARNING: GSSServer loginSubject could not be created.
    

    This means the username is incorrect. Note the wrong username “ccass”, error code 6 and the last warning.

  3. 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
    SEVERE: startServer - SSO Service authentication failed. 
    Pre-authentication information was invalid (24)
    Aug 21, 2006 3:40:26 PM com.perfigo.wlan.jmx.admin.GSSServer startServer
    WARNING: GSSServer loginSubject could not be created.
    

    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.

    Note: 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.

Client – CAS Communication Issue:

Aug 3, 2006 10:03:05 AM com.perfigo.wlan.jmx.admin.GSSHandler run
         SEVERE: GSS Error: Failure unspecified at GSS-API level 
(Mechanism level: Clock skew too great (37))

This error is seen when the client PC time is not synchronized with the DC.

Note: The difference between this error and the one where the CAS time is not synchronized with the DC.

Known Issues

  • Cisco bug ID CSCse64395 (registered customers only) —4.0 Agent does not resolve DNS for Windows SSO.

    This issue is resolved in CCA Agent 4.0.0.1.

  • Cisco bug ID CSCse46141 (registered customers only) —SSO fails in case CAS cannot reach the AD server during startup.

    The workaround is to go to CCA Servers > Manage [CAS_IP] Authentication > Windows Auth > Active Directory SSO, and click Update 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.

  • Windows 7 and Windows 2008 do not support SSO as SSO uses DES encryption that is not supported by Windows 7 or Windows 2008.

Related Information

Updated: Dec 01, 2008
Document ID: 97251