Windows 7 and Windows 10 client workstations If SGOS can support 17 & 18 etype, how do we tell the KDC (Active Directory) to create tickets for the proxies with these etypes? Is SGOS 6.6.x.x capable of using AES etypes?ģ. What version of Kerberos does SGOS 6.6.x.x run?Ģ. 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.ġ. 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.

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. On the Windows 7 clients that succedd, the KDC encrypts the authenticator ticket for the proxy with eTYPE-ARCFOUR-HMAC-MD5 (23). 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). The Windows 10 computers only advertise two etypes, eTYPE-AES256-CTS-HMAC-SHA1-96 (18) and eTYPE-AES128-CTS-HMAC-SHA1-96 (17). I have compared the client encryption types in the TSG-REQ from our Windows 7 and Windows 10 computers.

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

Xshell 5 테마