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.
The Situation
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.
Note:
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
Conclusions
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
See ya
FYI – The issue with the SPN attributes not being migrated (and DNSHostName) is actually in the context of Migrating Computer objects, not User objects – in particular when migrating to DCs running on 2012R2 or newer, as SPN uniqueness was introduced here.
Microsoft released a hotfix/workaround:
https://support.microsoft.com/en-us/help/3070083/duplicate-spn-check-on-windows-server-2012-r2-based-domain-controller
@Seb,
seems that you didn’t fully read the post… we are not speaking about duplicates spn or spn of computer accounts but we simply mention the fact that the ADMT can migrate SPN information
Till next time
See ya
Seb you are the best. Exactly what I was looking for.
@E,
Good to hear that you have found what you are looking for
Thank for the visit
Till next time
See ya
Seb (the commentor, not the author) points out the important point. Yes, ADMT will *try* to migrate/copy the SPNs, but it will fail and the computer hostname will not be generated (and thus domain login will fail with ‘missing computer account trust relationship’ message) if you are doing an INTRA-domain migration as detailed in Seb’s post.
So the fact that ADMT is copying SPN is.. well, not wrong, but that’s not what people will care about. In Intra-domain migration using W2K12R2 it will fail to be copied and you will have issues.
@Andrew,
Thank you for visiting our blog and providing feedback. Indeed, the post was more focusing on Inter-Forest migration where the object are recreated in target domain and where attributes are copied as is. In Intra forest migration, ADMT will indeed try to copy the object which can cause issue with SPN attributes. We usually use PowerShell to deal with this situation (export – modify – import updated SPN).. You can also indeed loose duplicate spn Restriction… There are indeed plenty of options..
So thank you for indeed outline that intra-forest is indeed more work to be done and more things to be looked at 🙂
Till next time
See ya