Migrating Passwords Without Using RC4 Encryption

New Recommendations for Password Synchronization

During migrations, one of the most asked for features is to synchronize a user’s password between the source and target environment. This allows users to transition between the two environments much more seamlessly and allows for simpler administration of user objects, especially when users continue to need access to resources that still exist in the source environment. Users who are trying to manage multiple accounts most often lead to higher support desk call volumes and more complaints during a migration.

Free tools such as ADMT and most 3^rd party tools manage the copying or synchronization of the passwords by copying the NTLM password hash in the source and writing that hash value to the target Active Directory object. That method is simple, easy, and effective, but the challenge is that using the NTLM hash and the RC4 encryption method for Kerberos is quite old and poses vulnerabilities, specifically when using Kerberos.

RC4 encryption with Kerberos has been used for an exceptionally long time, but both Microsoft and STIG (Security Technical Implementation Guide) security requirements suggest disabling the RC4 encryption and using a more modern encryption method such as AES (Advanced Encryption Standard). So, while these recommendations have been around for some time, Microsoft is now pushing security updates that disable the use of RC4 encryption with Kerberos.

So why does that matter?

If we can synchronize over the password hashes to the target tenant, everything should be fine, right? Well, for the password hash, yes, but there is a catch. When you migrate an Active Directory user object over to the target environment, the password hash is the same as the source hash. However, for environments where they have disabled RC4, accessing resources and applications via Kerberos (which is nearly everything) will use a more modern method of authentication which will require a salt to use Kerberos.  The old Microsoft implementation of Kerberos using RC4 does not require a salt, and that is the crux of this issue.

What is a salt, and why is it important when synchronizing passwords?

A salt is simply additional data that can be used to help ensure Kerberos connections are more secure than just passing the NTLM hash.

For example, in figure 1, the following user is from an environment where they are still using RC4 without a salt value:

You can see on the bottom that the NTLM value is “1a4b1757588cab6298e29e91c06df58d” which equals ‘Pa$$word”

Here is another user from that same environment:

Guess what? That password shown in figure 2 has the same value as the previous user, meaning we can now gain access to that account. There is giant ‘rainbow tables’ of common passwords and their hashes which makes gaining access to Kerberos-protected services extremely easy. So, when using Microsoft’s implementation of Kerberos using RC4, only the NTLM hash is used.

Here is what a salt looks like in an environment where the RC4 encryption has been replaced with AES

When you apply the latest Microsoft security patches, RC4 will be disabled and will be replaced with AES encryption automatically.

The Issue with Un-Salted Security Keys during a Migration

So, what exactly does salting of passwords and security keys mean when doing Active Directory migrations that involve synchronizing user passwords to a target environment where RC4 encryption has been disabled? Well, it is complicated, but it is about how and when the salt value is created.

Salt values are generated when a user is created, or a password is changed.  So, when you use tools to synchronize password hashes, it is just copying a value from the source to the target, not ‘building’ a new AD account and setting a password though Active Directory. The challenge comes when the target user logs in to their newly migrated computer and tries to access a service that uses Kerberos for authentication.  While the user will be able to log in to their machine without an issue, accessing applications that use Kerberos for authentication will fail. Considering how many modern applications now use Kerberos for authentication, this can be a significant issue for migrated users and administrators fielding calls.

How to Address the Lack of a Salt

So, we know that having a salt is critical to accessing Kerberos protected services using modern Kerberos authentication with AES. However, for migrated users who do not have a salt, they will not be able to access those services. To address this issue, we need to generate the salt for the user to ensure they can access Kerboeros protected services.

When the user changes the password in the target environment, Active Directory will automatically create the new salt and access those Kerberos protected services.

Making these changes, however, can pose a few challenges:

If a user were to log in to their newly migrated machine with their target credentials (that were synchronized over from source), Active Directory would validate those credentials and allow the user to log in to the machine. If the user hit Ctrl-Alt-Del and selected change password to set a new password, after the user enters their new password and clicks submit, they would see an error that the encryption type is not supported (Figure 4).

This error is encountered because the password change process is using Kerberos, and as we know, since we do not have a salt created for the user, the Kerberos keys being passed internally are not going to be accepted. This will be the case for any Kerberos protected application, and this poses a significant challenge when migrating users and their passwords. 

As of now, there are only 3 options available to address this issue:

1. Enable RC4 encryption in the target environment until the migration is completed. This will allow the users to continue to use their newly migrated passwords in the target environment and allow them to access Kerberos protected services (see Figure 5 below).

2. Have a target administrator reset their password. By having the administrator reset the password for the users, the process of generating the salt will be streamlined for the user, and they will then be able to access Kerberos protected applications like normal. The downside to this is that the newly migrated target users will have to be told what their new passwords are, making the need to synchronize passwords unnecessary.

3. Provide an alternative solution to resetting passwords. We know the synchronized password will allow the migrated user to log in to their machine, but the user will not be able to access Kerberos protected services. Although, things like web applications can be accessed, which could provide the user with a portal to update their password and generate the salt. This could be performed when the user first logs in to the device and will then allow the user to work normally after the new password (and salt) is generated for that user.

The Choice is Yours

As you can see, the options are challenging and will require careful planning when migrating users from source to target environments if the target has RC4 encryption disabled. This is something being worked on by 3rd-party vendors as we speak, and hopefully a more automated process will be developed shortly.