You look at Windows Server 2012 R2 and you tell yourself: "that would be nice if I could leverage all those new features". Then you remember...
- Adding new domain controllers is usually not a problem. Besides, if you want to add your new DCs in a smooth way, without impacting the existing environment, you can follow this excellent post which, despite its age, is still valid for Windows Server 2012 R2: Minimizing Risk During AD Upgrades.
- Removing the old ones is what you are worried about. "What if I have applications using explicitly one specific domain controller's name or IP?" Well, unless you reuse the same name and same IP address for your new domain controller, it might break things. And breaking things isn't fun...
How can we do it without breaking things?
First, it is important that all applications consuming Active Directory data (for authentication as well as for data storage) are configured in a way that they are not bound to a specific DC. Being proactive means two things:
- Communicate and educate the applications' owners about the magic the NetLogon service does. If possible, craft the list of all business critical apps, sit down with the team in charge of administering them and try to determine how their apps are discovering domain controllers.
- When acquiring new software, ask the vendors if their applications are discovering a domain controller through the Windows API or if they require a hardcoded configuration. And be careful! Specifying the FQDN of the domain name might bring some flexibility but does not necessarily imply that the applications use Windows API to discover domain controllers. We'll discuss about it later on this article.
Second, we can try to detect which applications are using this kind of hardcoded configuration. This is a tough one. You cannot just look at the logs of the domain controllers because the decision of using a specific DC is done on the clients' side. So enabling LDAP logging will just basically list all your active clients without the possibility to distinguish if it comes from a hardcoded app or a regular Windows client. When replacing a DC with a new one with a new name, you might be tempted to create a DNS alias to point to the new DC. It might do the trick for the application but it's in fact just punting. You will have to maintain the DNS record. However some functionalities such as LDAPs or Kerberos could go bad with this DNS spoofing workaround. It looks like a goner...
Read more at source - http://blogs.technet.com/b/pie/archive/2014/07/13/how-to-detect-applications-using-hardcoded-dc-name-or-ip.aspx
0 comments:
Post a Comment