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