ProxySG Kerberos Encryption Types (etype)

[Harry Pilgrim]

We have been running ProxySG 6.6.x.x with IWA Direct Kerberos authentication for several years with no issues.  Recently, IT began rolling out Windows 10 clients, and now authentication from Windows 10 computers is failing back to NTLM.  From my tests and packet catpures, the Kerberos error we are seeing in the packet capture is "eRR-ETYPE-NOSUPP".  This comes from the KDC (Windows Server 2012 R2) to the client in response to the TSG-REQ. 

I have compared the client encryption types in the TSG-REQ from our Windows 7 and Windows 10 computers.  The Windows 10 computers only advertise two etypes, eTYPE-AES256-CTS-HMAC-SHA1-96 (18) and eTYPE-AES128-CTS-HMAC-SHA1-96 (17).  The WIndows 7 clients advertises (5) etypes, including 17 & 18, but also eTYPE-ARCFOUR-HMAC-MD5 (23),  eTYPE-ARCFOUR-HMAC-MD5-56 (24), eTYPE-ARCFOUR-HMAC-OLD-EXP (-135).  On the Windows 7 clients that succedd, the KDC encrypts the authenticator ticket for the proxy with eTYPE-ARCFOUR-HMAC-MD5 (23).

Speaking with IT and Security, they tell me that due to various vulnerabilities, they have disabled RC4 ciphers via GPO in the Windows 10 computers.  This seems to make sense on the surface, but as I understand Kerberos, the KDC keeps track of each Principal's encryption capabilities, and issues tickets based on what that principal can decrypt.  I'm not a WIndows guru, but regardless of the client abilities, the KDC should be able to issue authenticator tickets for services based on the principals abilities, not the client. 

Here are my questions:

1.  What version of Kerberos does SGOS 6.6.x.x run?

2.  Is SGOS 6.6.x.x capable of using AES etypes?

3.  If SGOS can support 17 & 18 etype, how do we tell the KDC (Active Directory) to create tickets for the proxies with these etypes?

Environment:

ProxySG 9000-30 with SGOS 6.6.5.2
Windows 7 and Windows 10 client workstations
Windows Forest/Domain is Server 2012 R2
Proxies in Explicit mode and are hardware load baolanced using an AD Service Principal Name (SPN) and AD service account credentials.

Any suggestions of where to look next would be greatly appreciated.  Since we are failing back to NTLM, we are not experieincing any problems, however, I prefer to use Kerberos vice NTLM for security and efficieny.

Harry Pilgrim
 

 

[Migration User]

Hi Harry,

 

          Most of this is going over my head too :( . The AES types you have mentioned are supported as per my check. Since the error client is getting from the KDC for the first AS-REQ, this seems to be when client uses RC4, AES128 and AES256 when requesting. Since you have KDC restricted RC4, it seems to be rejecting it without even considering the other 2 options. Not sure whether this is related to proxy at this initial ticket requesting stage itself. Might need to involve the wizards of Microsoft in this.

[Bhavesh Kumar]

Was this ever resolved? 

We have a similar issue:

We have a clustered appliance connected to domain via direct IWA realm. There is a AD account which has SPN set and DNS a records to point to the Loadbalancer. 

The Kerberos Account which has the SPN set has AES128 and AES256 enabled, however it seems like the appliance has issues decrypting the tickets - when the account has etype set to rc4 then appliance seems to be able to authenticate users.  Unfortunately this is a managed service and we dont have direct access to appliance for logs - We get a splash screen which gives the IWA real error. The vendor has no idea how to troubleshoot this

Any pointers here?

[Matthias Geiser]

Hi Bhavesh,

I'm currently debugging a Kerberos issue with IWA direct and SGOS 7.3, Kerberos encrypted with RC4 is working fine. As soon as we change the encryption type to AES256-CTS-HMAC-SHA1-96 the Proxy cannot decrypt the Kerberos ticket.

With BCAAA AES256-CTS-HMAC-SHA1-96 is working fine as well but not with IWA direct.

Have you resolved your issue? And if so, how?


Best regards, Matthias

[Web C]

Hi Matthias,

Which 7.3.x version do you use? I have no problem with AES256 Kerberos tickets and 7.3.11.2.

[Matthias Geiser]

Hi,

thanks for your response. My customer is using 7.3.9.2 right now.

But we can try 7.3.11.2 as soon as it is released.


Best regards, Matthias

[Web C]

Hi Mattihas,

I have no problem with AES256 tickets and 7.3.11.2. Which version do you use?

[Matthias Geiser]

For documentation:
For whatever reason we had to reset the password for the user used in IWA direct. Afterwards Kerberos worked with AES256. We have no clue why this resolved the issue as the password used before was correct and it worked smoothly with RC4.

Anyways, the issue is resolved now and IWA direct is working correctly with AES 256 Kerberos encryption.

[Ivica Šakić]

Hi,

how do you change which encryption to use RC4 or AES256 ?

Best Regards,

[Matthias Geiser]

Hi Ivica,

you need to change the Kerberos encryption type on your Active Directory. But do not ask my what exact setting this is, as I'm no AD expert. No changes are needed on the proxy or BCAAA.

You can check the Kerberos encryption type used after success full authentication using the "klist" Windows command:

#2>     Client: user @ DOMAIN.COM
        Server: HTTP/proxy.domain.com @ DOMAIN.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 4/11/2023 11:30:13 (local)
        End Time:   4/11/2023 20:57:31 (local)
        Renew Time: 4/18/2023 10:57:31 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: DC1.DOMAIN.COM

Best regards, Matthias