First published on TechNet on Feb 13, 2017
Hey Everyone. Randy, Premier Field Engineer, here to discuss some lessons learned from working with a recent merger between two corporations. I don't have enough time or space to go into the details of this major endeavor, so I am going to talk about this experience with a "Top Ten Countdown" style BLOG POST. I'm sure there are many other headaches seen in the field and I would love to hear about them in the comments section. Maybe I can start to consolidate all this into a Wiki about Partnerships and Mergers between two dueling Active Directory environments. Let's get started:
Here we have a File Server (FileServ1.adatum.com) hosting a Share (\\SalesReports\Monthly.) In DNS, we configure a Cname record to direct any DNS query for SalesReports.adatum.com, to the physical host of website Fileserv1.adatum.com.
In Windows XP and SMBv1: We would ask the KDC/Domain Controller for CIFS/SalesReports, because that was the hostname supplied in the UNC Path.
In Vista and SMBv2: We would ask the KDC/Domain Controller for CIFS/FileSrv1.adatum.com, because that was the hostname resolved in the DNS CNAME query.
In Windows 8: We once again returned to the original behavior of asking for CIFS/SalesReports, and adding the "NETDOM COMPUTERNAME /ADD" to supply an alternate name that would register the SPN for you.
The recommendation from Microsoft is to avoid CNAME records if at all possible. This will avoid a variety of headaches because you could see unexpected outcomes as you use other network transports like HTTP.
The next two items on the list are related to FQDN.
The beauty of this solution is that there would be no performance impact (as described in the TechNet documentation) because the workstation is just asking its local Forest and would only be relevant if the logged on user was from a different Forest.
The good news is Windows 8 & 10 clients seem to behave, and I only found this to be an issue with Windows 7 / 2008 systems. This can be a major problem with new SMB Hardening recommendations for \\*\Sysvol and \\*\Netlogon. If you have a One-Way trust and Windows 7 clients with SMB hardening, then they won't be getting group policy across the forest because Kerberos will fail.
Whenever your users traverse the trust, they could be exposed to credential theft. In turn, their users are now your users. Whatever vulnerabilities and compromises they face, are now your problems. You can set up various roadblocks to prevent these issues.
These are just a few examples of considerations. Just keep in mind that this is a major endeavor and should be well planned. Also, think outside of the box. This may be time to consider hosting services in Azure and merging the two forests in Azure AD, while keeping your on premise nice and isolated.
Randy “Trust me” Turner
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.