1

I understand that the principle of Kerberos is to allow authentication between users and services on an unsecured network. Tickets generated by the authentication and ticket-granting service support secure communications and don't require a password to be transmitted across the network.

The flow relies on the auth server in the KDC (s) having a shared secret with the client (c).

However, at some point, the user itself must have been created and generally, users are created from client machines (you don't usually log onto the domain controller to create users)

So how do the user and secret key (Kac) get created in the first place and stored in the KDC database if the password/secret is never sent across the network?

Harsh Tanwar
  • 21
  • 4
mattdevops
  • 37
  • 5

1 Answers1

2

The administration of principals in a KDC's database is outside the scope of the normal Kerberos protocol. Usually it's done using some auxiliary protocol, and each KDC can implement it in any way it wants.

For example, MIT Kerberos has the (SunRPC-based) kadmin protocol, and the kadmin client indeed sends the actual administrator-specified password to the kadmind service running on the KDC. (The RPC message is encrypted using the Kerberos session key, of course.) Heimdal has its own kadmin protocol, mostly incompatible with MIT's but working the same way.

(Both also have "local" versions of the kadmin tool, which directly accesses the KDC database backend – this is how the initial admin accounts are created, typically by running kadmin.local on the server console or through SSH.)

Microsoft Active Directory has several user administration protocols, some of them dating to pre-AD days, but the primary mechanism is LDAP (usually over an GSSAPI/Kerberos-encrypted session, but occassionally TLS-encrypted).

To create a new account in MS AD, the administrator creates an LDAP 'User' or 'Computer' entry with the plain-text 'userPassword' attribute, and the domain controller automatically transforms this attribute into Kerberos keys (instead of storing it raw). The commonly used "AD Users & Computers" applet (dsa.msc) is really an interface to the LDAP directory.

All of the above implementations also support a second administration protocol, the kpasswd protocol whose sole purpose is to allow an existing user to change their password. As you'd expect, it also works by transmitting the user's new password over the network, again making use of Kerberos authentication and encryption. (Password changes can also be done via AD's LDAP or MIT/Heimdal's kadmin, but kpasswd has the advantage of being supported by all three.)

As a final side note, the PKINIT extension uses X.509 certificates to authenticate the AS-REQ – in which case the client doesn't know their own shared secret, so the KDC in fact sends the whole Kc to the client over the network (encrypted using a session key negotiated via DH, somewhat like TLS would). This is mostly used in Active Directory environments with "smart card" authentication.

user1686
  • 13,155
  • 2
  • 35
  • 54
  • So if I understand this correctly in the case of MS AD, the first account to be created is the administrator which occurs locally when AD is installed. This won't transmit a password on the network as the install is local. This creates an entry for administrator with a secret in the KDC database. If more users need to be created, perhaps from the administrators workstation using the user admin tool a session will first be created between the client/server and the admin will enter the password for the first time on the workstation. So it generates a secret which should match the KDC. – mattdevops Aug 09 '21 at 08:49
  • Yes, but the new user's Kerberos secret is generated by the KDC itself, from the received original password – not by the administrator's client (which doesn't necessarily know the supported key types or other policies). – user1686 Aug 09 '21 at 08:55
  • "So it generates a secret which should match the KDC" Yes so the KDC generates the key and stores it. When a remote client attempts to authenticate the KDC responds with a ticket from the AUTH server with details of the TGS. This in encrypted with the shared secret. The client needs to decrypt to read this info so will use the password entered by the user to 'generate' the secret. If the password is the same, the same secret is generated and the message can be decrypted. – mattdevops Aug 09 '21 at 13:14