IWA kerberos authentication falling back to NTLM on the ProxySG
search cancel

IWA kerberos authentication falling back to NTLM on the ProxySG

book

Article ID: 188801

calendar_today

Updated On:

Products

ProxySG Software - SGOS

Issue/Introduction

This article applies to the following situations:
  • The client machine is configured to authenticate with an explicit proxy and the proxy setting is a DNS alias (CNAME record)
  • This issue is usually seen when configuring a load-balanced Kerberos user, where we have to set the Service Principal Name (SPN) on the AD account used
  • A packet capture on the client machine shows an invalid principal name response

Cause

There is a potential misconfiguration of the service principal name assigned to the AD account used for authentication. Typically you would use the DNS name specified in the proxy setting, however, when an alias is used this is not correct. The SPN assigned to the account needs to be the dereferenced alias record.

To verify if this is the issue you've encountered, do the following:

  1. Perform an nslookup for the hostname used in the proxy setting to determine if it is an alias.

    Example:
    C:\Users\user>nslookup proxy-alias.ws2012.lab

    Server:  vm1.ws2012.lab
    Address:  192.168.2.2

    Name:    proxy.ws2012.lab
    Address:  192.168.2.3
    Aliases:  proxy-alias.ws2012.lab

    In this example, the proxy-alias.ws2012.lab is specified in the proxy setting and is an alias for proxy.ws2012.lab.

  2. Check the SPN assigned to the proxy's account:

C:\Windows\system32>setspn -L proxyaccount
Registered ServicePrincipalNames for CN=proxyaccount,CN=Users,DC=ws2012,DC=lab:
        HTTP/proxy-alias.ws2012.lab

We can see the alias was specified for the SPN which confirms the misconfiguration.

Resolution

To resolve the problem, you will need to add the dereferenced alias as a service principal name on the proxy's active directory account.

We can add the correct SPN with the following command:

C:\Windows\system32>setspn -A HTTP/proxy.ws2012.lab proxyaccount
Checking domain DC=ws2012,DC=lab
Registering ServicePrincipalNames for CN=proxyaccount,CN=Users,DC=ws2012,DC=lab
        HTTP/proxy.ws2012.lab
Updated object


When testing authentication, you can use the klist command on the client's command line to confirm we are getting a Kerberos ticket:

C:\Users\user>klist
....
#1>     Client: user @ WS2012.LAB
        Server: HTTP/proxy.ws2012.lab @ WS2012.LAB
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 4/15/2020 10:05:28 (local)
        End Time:   4/15/2020 17:50:17 (local)
        Renew Time: 4/21/2020 12:21:46 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: vm1.ws2012.lab
Powered by Wolken Software