Troubleshooting Kerberos Constrained Delegation Issues

Troubleshooting Kerberos Constrained Delegation Issues

book

Article ID: CTX139117

calendar_today

Updated On:

Description

This article provides troubleshooting information for Kerberos Constrained Delegation (KCD) issues and is applicable for release earlier to 10.1 build 120.x.

Background

KCD fails on NetScaler when delegating Windows Server 2008 R2 Domain Controller.

Troubleshooting KCD Issues

To troubleshoot the issue, complete the following steps:

  1. Verify the authentication negotiateAction and the NegiotatePolicy on NetScaler. The action consists of the domain name, user, user password, the OU string and the Default Authentication Group.
    sh authentication negotiateAction <name>
    sh authentication negotiatePolicy <name>

  2. Verify if the negotiation policies are bound at the global level (Global or Vserver level).
    If the domain join is still unsuccessful, verify the user privileges, that is, the user must have the Active Directory (AD) rights to establish account. The domain administrator privileges are not required for any normal user with delegated control in that OU with Read/Write access.
    Permission will be able to create or delete computer objects as shown in the following screen shot:

    User-added image

    User-added image

  3. Verify the negotiateAction if the customer has multiple levels of OU in the AD. For example, if the user has dn=OU=Level3, OU=Level2,OU=Level1,OU=TESTOU,DC=EXAMPLE,DC=COM then the user should have an authentication negotiateAction as follows:
    > add authentication negotiateaction <name> -domain EXAMPLE.COM -domainuser <Svc_Account> -domainUserPasswd <Password> -OU “Level3,OU=Level2,OU=Level1,OU=TESTOU”

  4. Examine the aaad.debug logs for any errors. For every thirty seconds, NetScaler probes the AD. If there are any issues, an error will be logged that helps to determine the cause of the failure in KCD.

  5. Verify if the likewise process is running on NetScaler shell.
    # ps aux | grep –I likewise

    root 1415 0.0 0.0 44828 392 ?? S 19Aug13 0:12.03 /opt/likewise
    root 1431 0.0 0.0 38144 0 ?? IW - 0:00.00 /opt/likewise
    root 1432 0.0 0.0 45252 0 ?? IW - 0:00.00 /opt/likewise
    root 1434 0.0 0.0 29456 0 ?? IW - 0:00.00 /opt/likewise
    root 1435 0.0 0.1 49024 980 ?? I 19Aug13 3:13.31 /opt/likewise
    root 1436 0.0 0.1 66916 2268 ?? I 19Aug13 16:55.21 /opt/likewise
  6. Verify the status of the AD by getting the status of the likewise process:
    # /opt/likewise/bin/lw-get-status

    The following sample output (KCD is not configured) provides information about the AD server, uptime, status, and so on:
    root@SFMonitor# /opt/likewise/bin/lw-get-status

    LSA Server Status:
    Compiled daemon version: 5.0.0.0
    Packaged product version: 6.1.0.0Uptime: 25 days 0 hours 18 minutes 21 seconds
    [Authentication provider: lsa-activedirectory-provider]
    Status: Unknown
    Mode: Unknown
    [Authentication provider: lsa-local-provider]
    Status: Online
    Mode: Local system
    Domain: NS
  7. In case the likewise process is not running, you can manually restart the process and redo the negotiateaction:
    #/opt/likewise/bin/nslw.sh restart_lwagent

  8. If the domain join still fails then manually enter the domain. This step is not recommend. Generally add authentication negiotiateAction should suffice but there are situations in which the domain has to be added manually:
    #/opt/likewise/bin/domainjoin-cli join <domain name> <username> 

    The domain password is prompted when you run the preceding command.

  9. The resolve.conf file can also be used in case the domain join fails. Create a name server to the /etc/hosts file and add KCD to the /etc/resolve.conf file.

Additional Troubleshooting Steps to Validate KCD

The command  klist –k provides the location of the keytab file and the domain principal name. This information is used in kinit string and in t_s4u commands.

# klist –k
Keytab name: WRFILE: /nsconfig/krb/ns_kcd.keytab
KVNO Principal
---- --------------------------------------------------------------------------
1 dummy@DUMMY.COM
>> Kinit string:
#/opt/likewise/bin/kinit -k -t /nsconfig/krb/ns_kcd.keytab -f host/domain@<domain>'

The preceding command will help to verify if NetScaler is requesting any ticket from the AD. Capture a trace to verify if NetScaler is sending any AS-REQ to the AD with the Client Principal Name.

>> t_s4u string:
/opt/likewise/bin/t_s4u <domain@domain> http/<delegate server> /nsconfig/krb/ns_kcd.keytab

If you receive a warning then verify the Kerberos preauth option on the AD and also verify that the delegation of AD is set to “any authentication protocol”.

Issue/Introduction

This article provides troubleshooting information for Kerberos constrained delegation issues.