Being busy with multiple projects, I have the chance (euh well….) to encounter sometimes some strange issues during migration activities… In one of these projects, we have encountered quite a lot of errors related to the kerberos authentication mechanism.
This was during a Active Directory migration project. As usual, we were using the ADMT 3.2 migration tool from Microsoft to perform the migration operation. After performing a migration of a custom developed application, some of the functionalities were not available anymore. After some investigations we found out that the problem was related to the kerberos authentication mechanism. I was working with an unpleasant person who didn’t really much experience with migration activities. After some time, this guy sustained that the ADMT tool was not migrating Service Principal Name (spn). You can use SPNs within your Active Directory to support mutual authentication between a client application and a service. Application such SQL or Sharepoint (when configured for Kerberos Authentication) are using SPNs.
I didn’t really agree with this comment. When using the ADMT tool, the migrated user account should keep the same information as before the migration. The service principal name is basically an information that stored in an attribute of the migrated user account. As such, this information should be migrated with the account. I had really hard time trying to explain the concept and the approach used… And I was not able to convinced him (just with words).
Migrating a user account and its associated SPNs
In this situation, you have no choice… you have to check if what you are assuming is correct or not. So we decided to migrate a user account associated with mulitple SPNs from one domain to another domain in order to see how the SPNs attribute would be modified (or unmodified) during the migration process. I was not 100 % sure of my statement but I was expecting that the ADMT migration tool would take this information into account.
The following screenshot show the user account in the source domain (thus not migrated). We went to the adsiedit console, located the object and checked the attributes present. This screenshot shows clearly that service principal names are associated to the user account. This information is indeed stored in Active Directory as a multi-value string attribute
Using the ADMT 3.2, we have performed the migration of user account. After the migration, we have performed exactly the same check. We went through the adsiedit console and checked that the service principal name(s) were migrated with the user account. If you check the screenshot below, you will notice that indeed the SPNs are effectively migrated with the user account
We are in another domain and you can see that the user account have been literally copied. If you do a intra-forest migration, because you are moving the account from one domain to another domain, the attributes will be same as well.
In the screenshots above, if you’ve noticed, we are using NetBios names. What happens when you are using Fully Qualified Domain name ? After the migration, the service principal name will be changed unmodified. So, if in the source domain you have used a FQDN for your SPN such as service.source.com, in the target domain, the service principal name value will be showing service.souce.com. This means that you might want to update the SPN value to meet your new domain naming convention
This small test has demonstrated that indeed the ADMT tool is taking care of the servicePrincipalname during the migration. As I can see, the SPN’s information is restored after the migration and the kerberos authentication should be working after such migration. However, I have to say that during migration you can have some issues related to Kerberos authentication where you need to debug and have quite a good knowledge of the infrastructure you are working on and have at least a basic understanding of the kerberos authentication process.
If you look in Technet, you will probably find some articlesthat can help you in troubleshooting your Kerberos authentication issue
Till Next Time