Verify the Client Settings

Perform the following checks to ensure that the Client settings are accurate:
Verify the HTTP Browser Settings
Web browsers must be configured to attempt an automatic authentication only for specific servers or domains. Each web browser has a different set of settings for this configuration.
  • Chrome/Chromium
    Verify that both the AuthServerWhitelist and AuthNegotiateDelegateWhitelist settings are configured. From Google Chrome 86, these settings have been renamed to AuthServerAllowlist and AuthNegotiateDelegateAllowlist. For information, see the
    Google documentation
    .
  • Mozilla Firefox
    Verify that the network.negotiate-auth.trusted-uris and the network.negotiate-auth.delegation-uris settings are configured. These settings do not support the wildcard characters like *. For information, see the
    Mozilla documentation
    .
  • cURL
    Verify that both the --negotiate and --delegation always options are used. For information, see the
    cURL documentation
    .
Verify the Status of Windows Defender Credential Guard
Ensure that Windows Defender Credential Guard is disabled on the Windows client. To disable Windows Defender Credential Guard, perform the following steps:
  1. Set the value of the following registry keys to
    0
    on the Windows client:
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LsaCfgFlags
    • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DeviceGuard\LsaCfgFlags
  2. Restart the Windows client.
For information about Windows Defender Credential Guard, see the Microsoft documentation.
Verify HTTP Status Codes
Verify that the Client receives the following HTTP status codes:
HTTP 302 Response
When the Client accesses a Kerberos-protected resource and the request does not contain a valid SiteMinder session, then the client is redirected to the Kerberos credential collector URL through the HTTP 302 response. If the HTTP 302 is not received, then either the resource is not protected or the client request contains a valid SiteMinder session. If the HTTP 302 is received but the Client is redirected to the Kerberos credential collector URL, then the resource is not protected by the Kerberos authentication scheme.
HTTP 401 Response
When the HTTP user-agent follows the HTTP 302 redirect to the creds.kcc page, verify that the HTTP 401 response with the response header contains WWW-Authenticate: Negotiate. If HTTP 500 is received, then there is a problem on the Web Agent. Troubleshoot the Web Agent and then continue troubleshooting the Client once the Client receives the HTTP 401 response.
Use Client Utilities to Manage the Kerberos Environment
Learn about the different Client utilities that can help you manage your Kerberos environment.
klist
(For client applications connecting only to a UNIX KDC only)
Use klist to list the contents of a keytab file. It also lists the Kerberos tickets held in a credentials cache, or the keys held in a keytab file. The flag
–f
provides information about tickets flags. These tickets are forwarded to complete the Kerberos authentication process.
The following text is a sample of a klist output:
bash-2.05$ klist Ticket cache: /tmp/krb5cc_1002 Default principal: HTTP/[email protected] Valid starting Expires Service principal Mon Dec 22 15:00:03 2014 Mon Dec 22 21:40:03 2014 krbtgt/[email protected]
kinit
Use the kinit program to obtain and cache an initial ticket-granting ticket for the user and service principal at the UNIX KDC host and KDC client.
The kinit syntax for the user principal is:
kinit
principal_name
This command prompts for the password used while creating the user principal.
The kinit syntax (it can vary from host to host) for service principal is:
kinit -k [-t
keytab_file
]
principal_name
keytab_file
specifies the location of the keytab file that contains the service principal name.
principal_name
is the name of the service principal
The kinit command does not prompt for a password because it uses a keytab file to authenticate the service principal.
  • Install any network packet trace utility on the workstation to see the Kerberos tokens exchanged between the browser and web server. The token starting with TIR indicates NTLM tokens, and tokens starting with YII denote the Kerberos tokens.
ktpass
Verify the version of ktpass utility. The ktpass command tool utility is included in the Windows support tools and can be installed from MSDN download.
kvno
Confirm the key version number (kvno). The kvno of the service principal must match the kvno of its keytab file. The kvno number of any keytab is displayed when it is created.
To determine the version number of a service account for Windows Active Directory, use the ADSI Edit as follows:
  1. Run adsiedit.msc from command prompt.
  2. Go to service account, under CN=Users, DC=domain, DC=com under drop-down Domain (fqdn_ADhost) at the left.
  3. Right-click the service account and click properties.
  4. Verify the value of the msDs-KeyVersionNumber attribute, which matches the one shown while creating the keytab file for the service account.
The kvno for any user account changes every time that its password is changed. If the version numbers do not match, create an account and keytab, or change the password to match the kvno to the kvno of the keytab.
To determine the version number of a service account for a UNIX MIT KDC, enter the following command:
kvno
principal_name
Check for Kerberos HTTP Service Ticket
Verify that the Client can obtain an HTTP service ticket. This step verifies that the HTTP user-agent is properly configured for integrated authentication and it can automatically retrieve an HTTP service ticket to authenticate to the web server. If the Client does not have an HTTP service ticket, then either the HTTP browser is not configured correctly or there is another issue. Verify the HTTP browser configuration again and then continue to the next step of monitoring the network traffic.
To verify the Kerberos HTTP service ticket on Windows, use the
Microsoft Windows klist.exe program
by using the fully qualified path to klist.exe under C:\windows\system32 and search the output for
HTTP
.
> C:\windows\system32\klist.exe | findstr HTTP Server: HTTP/www.example.com @ EXAMPLE.COM
To verify the Kerberos HTTP service ticket on Linux, use the
klist program
and search the output for
HTTP
.
$ klist | grep HTTP 10/23/17 21:30:39 10/24/17 07:30:39 HTTP/www.example.com@ 10/23/17 21:30:39 10/24/17 07:30:39 HTTP/[email protected]
Check for HTTP Authorization Header
If the HTTP browser is able to successfully retrieve an HTTP service ticket, then the next request for the Kerberos credential collector URL contains an HTTP authorization request header. The value of the HTTP authorization request header is
Negotiate YII...
where
YII
is the beginning of the Base64-encoded Kerberos HTTP ticket.
Use a proxy like Fiddler to capture the HTTP traffic from the web browser, especially if the HTTP traffic is encrypted. Sometimes, the developer's tools feature of an HTTP browser does not show all the traffic or all the request/response headers. Use a proxy that is designed for capturing the browser traffic in such cases.
Capture Client Network Traffic
While tools like Fiddler are useful for capturing the web browser traffic, they do not capture the raw network traffic. Use a tool like Wireshark to capture the network traffic. Focus on DNS, Kerberos, and HTTP traffic by setting an appropriate capture filter such as port 53, port 80, or port 88.
Check DNS
Check that DNS queries are returning
A records
and not CNAME records. Use tools like
nslookup.exe
on Windows or
dig
on Linux to check DNS. Also, if Wireshark is used to capture DNS and Kerberos traffic, you might see requests for a Kerberos ticket for the server name that is returned in a DNS A record rather than the CNAME that is used to access the web server. Ensure that the server name in the Kerberos request from the Client matches the expected name.
Using DNS CNAME records complicates the authentication flow. The CNAME record is used when a proxy is used; when the proxy is not used, the A record that the CNAME points to is used instead. Prefer using DNS A records, if possible, to reduce the complexity and to support troubleshooting using proxy tools like Fiddler.
Check Key Version Number
Check the Kerberos HTTP ticket version number retrieved by the Client. It is in TGS response messages and called
kvno
. Note the number and compare it with the key version number in the keytab file of Web Agent when you start to focus on the Web Agent troubleshooting.