KERBEROS - Inside OUT

  • Article

Kerberos Checklist

General Kerberos scenario

  1. Client logs in to the KDC using the domain account.
  2. The KDC responds with the TGT. (Provided by the TGS within the KDC).
  3. Now the client sends the TGT and a session request for the particular middle tier machine to the KDC.
  4. The KDC issues back the Session ticket for the middle tier back to the client.
  5. The client uses the Session ticket to communicate with the Middle tier machine.

Checklist

  1. All computers should be running on Windows 2000 and above.
  2. All the IE should be > V 6.0.
  3. All the computers should be in the same domain / trusted domain.
  4. AD should not be in the Load Balancing architectures.
  5. All the machines should be MDAC 2.6 or later.
  6. Ping the middle tier and the Back end servers and see if it resolves the FQDN properly.
  7. Check the following in the IE of the client machine.

i. Enable windows integrated authentication in the IE tools.

ii. Check the bypass proxy settings for the local address.

iii. Middle tier in the Trusted sites.

Check if the middle tier is configured for EMPTY STRING or “Negotiate,NTLM”.

From the command prompt run the following,

Go to the AdminScripts folder in the inetpub.

C:\Inetpub\AdminScripts>cscript adsutil.vbs get

w3svc/NTAuthenticationproviders

  1. Check if it returns the following output,

Microsoft (R) Windows Script Host Version 5.6

Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

NTAuthenticationproviders : (STRING) "Negotiate,NTLM"

  1. If not use the set "Negotiate,NTLM" to set it manually.

cscript adsutil.vbs set w3svc/1/root/Vdir/NTAuthenticationProviders "Negotiate, NTLM"

Active Directory specific check lists

1. Check if the SPN’s are properly set for the middle tier (IIS) for the account under which your Application Pool is running. (If website is in non-default port, include the port number as well separated by “ : ” from the machine name / FQDN )

           Normal scenario:

Only HOST SPN’s are required (created by default) when your Application Pool is running under Local System account or Network Service.

Required SPN’s: (for the account under which your Application Pool is running)

    1. HTTP/machinename
    2. HTTP/machine.domain.com

When your website is using HOST Headers:

Only HOST SPN’s are required (created by default) when your Application Pool is running under Local System account.

For Application Pool running under Network Service, we need the HTTP SPN’s for the computer name.

    1. HTTP/hostheadername
    2. HTTP/hostheadername.domain.com

If the Application pools are running under Domain account then we need the HTTP SPN’s for that Domain account.

1. HTTP/hostheadername

2. HTTP/hostheadername.domain.com

           

            For IIS 7.0 running under the Kernel authentication mode:

No SPN’s are required when you browse the website using the machine name / FQDN and your application pool runs under Local System / Network Service / Domain account.

           

            When your website is using HOST Headers:

When your application pool runs under Local System / Network Service / Domain account the following SPN’s have to be set for the Machine Name.

                       

1. HTTP/hostheadername

2. HTTP/hostheadername.domain.com

2. Check the SPN’s for SQL Server for the account under which your SQL Server service is running.

SPN’s are automatically set for the Local System account and Network Service account.

Stand alone SQL Server:

    1. MSSQLsvc/machinename:1433 (Port number on which SQL is listening)
    2. MSSQLsvc/machinename.domain.com:1433 (Port number on which SQL is listening)

SQL Server in a cluster: (SPN is to be set for the FQDN of the virtual name)

    1. MSSQLsvc/virtualname.domain.com
    2. MSSQLsvc/virtualname.domain.com:1433 (Port number on which the SQL is listening)

3. Verify there are no duplicate SPN’s present.

4. Make sure the USER account is NOT marked “Account is sensitive and not trusted for delegation”.

5. Middle tier computer must be trust for delegation “Trust computer for delegation”.

6. Middle tier service account should be trusted for delegation “Account is trusted for delegation”.

7. Middle tier service account should be in the following groups.

i. Act as part of operating system.

ii. Impersonate a client after authentication.

Middle tier check list

  1. IIS account SPN’s are created.
  2. IIS account is trusted for delegation.
  3. IIS virtual directories are set for windows integrated authentication.
  4. The application connection string should contain Integrated Security = SSPI.
  5. The ASP.NET web application should contain <Identity Impersonate = true/> in the web.config.
  6. The USER must have appropriate permissions.

SQL Server check list

  1. SPN’s should be properly created.
  2. The account should be given permissions in the DB.
  3. The SQL Server should be listening either in TCP or Named pipes.

SUMMARY

KB 811899 – How to troubleshoot cannot generate SSPI context.

KB 294382 – Authentication may fail with ‘401.3’ Error if the web sites HOST HEADER differs from servers NETBIOS name.

KB 262177 – How to enable Kerberos event logging.

KB 817384 – How to use Kerberos authentication for Microsoft SQL Server 2000 Analysis Services.

KB 326985 – How to troubleshoot Kerberos related issues IIS.

KB280830 - Kerberos Authentication May Not Work If User Is in Many Groups

Each group user is a member of makes Kerberos SSPI token bigger Many programs written to use SSPI (like our SQL Server drivers) did not anticipate such large SSPI tokens

KB324914 - SQL Server Connection Fails When RC4 Encryption Is Disabled (we fixed large token issue with this hotfix and later builds of ssnetlib.dll) “Communication link failure” during initial connection is the error you will see when this problem occurs.

HTTP.SYS Overview: https://msdn.microsoft.com/en-us/library/aa364510.aspx

Reporting Service 2008 URL reservations: https://msdn.microsoft.com/en-us/library/bb677364.aspx