Synchronize Password Hashes between MS Active Directory and UCS

Version 4.4-4 of Univention Corporate Server (UCS) comes with some cool new features, one of them being the new AD Connector app. It makes the synchronization of password hashes between a Microsoft Active Directory domain and a UCS domain significantly more secure and less error-prone. While previous versions could only synchronize NTLM hashes, the AD Connector of UCS 4.4-4 also reads newer hashes, the so-called Kerberos keys which allow single sign-on (SSO) to different applications.

I am a second-year trainee at Univention (job description: IT specialist for application development). I was involved in the development of the new feature and mainly had to deal with three tasks: the AD Connector itself, the OpenLDAP overlay module, and the S4 Connector (Samba). In this blog post I’m going to explain what Kerberos hashes are and how I implemented the new feature.

What does the UCS AD Connector do?

Our AD Connector connects an existing Microsoft Active Directory and a domain managed by UCS. The app allows administrators to set up an automatic synchronization between MS Active Directory and the OpenLDAP directory service of Univention Corporate Server. That way, they avoid additional work and, of course, errors when adjusting the settings manually. Apart from user, group and computer objects, the AD Connector also synchronizes encrypted passwords.

Earlier versions of the app only synced NTLM hashes (NTLM = NT LAN Manager, collection of Microsoft protocols), which is technically outdated and no longer secure. That’s the reason why we wanted to support the syncing of Kerberos hashes – a real challenge, as it turned out, since UCS stores differently created password due to the snchronization.

What are Kerberos Hashes?

Kerberos is a network-based SSO protocol that ­– unlike NTLM – uses temporary tickets to transmit authentication credentials. For example, if users need access to a service in the domain, first the authentication server (AS, Authentication Service) of the key distribution center (KDC) issues a ticket granting ticket (TGT). The TGT contains the IP address of the client, the validity period and a previously generated session key, all in encrypted form. After that, the domain’s ticket granting server can issue a service ticket for connected services. To put it simply: all systems involved check the vailidity of the ticket information with this instance.

All users’ passwords are hashed with several hashing algorithms and stored in the Kerberos database. If someone tries to authenticate himself, the stored hashes are used for comparison. To ensure compatibility between different services, there is a list of different hashes. Some services only work with older hashes (e.g. DES), others support newer algorithms (e.g. AES).

When a new account is created in the UCS domain, five hashes are calculated from the password:

• DES_CBC_CRC
• DES_CBC_MD5
• RC4_HMAC_MD5
• AES128_HMAC_SHA1
• AES256_HMAC_SHA1

In an environment with a Microsoft AD domain and a UCS domain, there are two different Kerberos services (one per domain). The AD Connector’s job is to synchronize the Kerberos hashes between those two services.

Hash and Salt

Previous versions of the AD Connector used to compare only one of the hashes when a password was changed in the AD domain: the NTLM hash (RC4_HMAC_MD5 in Kerberos). All other hashes were not synchronized, which means that only the hash RC4_HMAC_MD5 was overwritten in the UCS domain. Since Kerberos prefers stronger hashes like AES, the password change did not take effect – the AES keys were still generated with the old password. As a result, users could only authenticate with their old password in the UCS domain.

To solve the problem, we first had to check a few things: Is the synchronization of Kerberos keys possible? Can the Kerberos service use hashes from another Kerberos realm? Unfortunately, this is where password salts become an issue: normally, a user password is extended by a character string (the salt) before hashing. By default, this salt includes the domain name (the name of the Kerberos realm). Salting makes sure that identical passwords always lead to different key values. It also means that we have two different salts in our two realms which means the UCS Kerberos service can’t use hashes from the AD Kerberos service because it doesn’t know the correct salt.

So, I was wondering if the passwords would be salted with the other realm name before the generation and the comparison of the hashes. Or does Kerberos use its own realm name for the salts so that the authentication always fails, even if a user enters the correct password?

The Solution: Pre-authentication

Fortunately, the salt is stored unencrypted together with the hash, and it’s also unencrypted during the synchronization. That means the Kerberos services can read the salt which also means that the key distribution center (KDC) always knows the correct salt. However, this salt must be transmitted before authentication. The client that wants to log in must know the salt, because it has to salt and hash its own password correctly before it forwards the information to the KDC.

In fact, the Kerberos service transmits the salt before the authentication. This happens during a process called pre-authentication, which was introduced with the current Kerberos version 5. Pre-authentication sends out certain information in advance to confirm that a client knows the correct password. Only when this is successful, Kerberos sends out the ticket granting ticket. So, when the client makes a request to the authentication service, it receives the message KRB5KDC_ERR_PREAUTH_REQUIRED – an error that Kerberos handles internally.

This message is not only just an error message, it also contains some important information that the KDC transmits to the client. For example, it reveals which hash is being used and it also provides information about the salt that the client can use. So this pre-authentication ensures that Kerberos keys are synchronized between different realms.

The Overlay Module k5pwd

To ensure successful synchronization of the hashes with the UCS domain, the OpenLDAP directory service has to be able to read the hashes. As a result, we had to patch our own overlay module k5pwd. It is used when a password in the AD domain is changed and compared with the UCS domain. The LDAP directory service needs the attribute userPassword for authentication via simple bind. Since AD only sends the NT hash, there is no way to create the attribute in OpenLDAP and compare the entered password.

This is where the k5pwd module comes into the picture: It adds the string {K5KEY} to the userPassword attribute, hashes the password entered by the user and compares it to the NT hash sent by AD. The NT hash has no salt, so we had to customize the overlay module to extract the correct salt from the synchronized keys and use it for hashing, just like Kerberos’ key distribution center.

If you want to use the new Kerberos syncing feature, you have to upgrade all LDAP servers in your domain to UCS 4.4-4.

What about Samba?

Last but not least, we had to overcome the differences between Samba and Microsoft Windows and adapt our S4 Connector. Since Active Directory no longer creates the DES_CBC_CRC by default, but Samba insists on the five hashes mentioned above, we had to bypass this rule to be able to transfer the hashes.

We now transfer the NTLM hash a second time as a dummy and forward it to Samba instead of the DES_CBC_CRC hash – problem solved. This procedure is also used by Microsoft to ensure backwards compatibility.

Learned a lot!

Developing the new feature was really exciting, and I’m happy I was able to solve this problem. During the process I learned a lot about Kerberos, Samba, Microsoft Active Directory, OpenLDAP, and about the interaction of all components and services. I’m glad I have been given the chance to work on such a complex problem.

If you have a question about the new feature or the technology behind it, feel free to post it in our forum or simply comment on this article.