Search code examples
kerberos

Kerberos is weak: i need to encrypt user identity

I do not like the fact that Kerberos for all types of packets like AS-REQ, AS-REP, TGS-REQ, TGS-REP etc is sending identity (like username) in a plain text.

Is it possible to reconfigure AD and Kerberos so that identity is send encrypted for example in anonymous TLS tunnel ? (other decent protocols like EAP-PEAP or TLS1.3 can send identity is a secure way).

I was pretty sure it's possible but i can not find any solution now....

Thanks,

Solution

  • Yes, in three ways:

    1. "Kerberos over HTTPS" using the MS-KKDCP extension. This uses a regular TLS tunnel to protect the requests.

      On the DC side, the RD Gateway role automatically provides a KKDCP proxy (as the feature seems to be mostly RDP-oriented), but the proxy can also be set up manually without any required roles (instructions therein provided by a MS developer). Alternatively, kdcproxy is a simple Python WSGI app that can act as the proxy.

      On the Windows client side, the proxy can be specified either within .rdp files, or globally via GPO. Meanwhile, Linux (MIT/Heimdal) clients can directly specify the proxy URL for kdc= in their krb5.conf files, or they can retrieve it from DNS URI records.

    2. "Kerberos armoring" using the FAST extension. This uses another set of Kerberos credentials (e.g. machine keytab) to encrypt the AS-REQ.

      Active Directory appears to have native support for FAST as part of "compound authentication" together with the machine credentials. You can enable it via GPO; the armored requests will reveal the machine identity but not the user identity.

      For MIT/Heimdal Kerberos, acquire a generic initial ticket using either standard "anonymous PKINIT" (which is roughly the Kerberos equivalent of EAP-TLS) or the Heimdal-specific GSS-SAnon, then use it with FAST to protect the real AS-REQ. Anonymous PKINIT only reveals a generic "@REALM" identity.

    3. Use a VPN for Kerberos.

      When accessing the AD domain from outside, you'll generally want a VPN for all other AD DC communications anyway (e.g. you really do not want to expose CLDAP or RPC services to the public Internet), so you might as well use it for Kerberos too.