Domain Controller decommission – Understand LDAP dependencies

By | January 5, 2020

Whenever we add a new Domain Controller (DC) in an existing Active Directory domain, we really don’t need to worry. But when we plan to remove any existing DC, we have to identify the dependencies before decommissioning. In a large environment, a DC handles hell lot of requests from various computer, users and application and if we decomission a DC without identifying and removing the current dependencis, it may lead to severe outage.

There are mainly two types of dependencies:

  • LDAP Dependencis
  • DNS Dependencis

In this article, we will understand the basics of LDAP dependencies and how it can impact your application. Once you know who is hitting the DC, and if they are important, you can remove them from the DC which is going to decommission and point it to any other DC, to avoid any possible outage. In the next article, we see the detailed process to do it.

Wait! Is it really important?

Ok! Let’s understand this…

Suppose you have a domain controller DC-01 which is going to be decommissioned. In your environment, two of the critical applications – App-01 and App-02 has hardcoded with DC-01. Hardcoded means both the apps are specifically using DC-01 to query LDAP from your Active Directory. So practically whenever App-01 and App-02 want to query anything from Active Directory, DC-01 is the guy who servers them. Unlike other applications, these two are directly approaching DC-01 instead of checking the availability of other existing domain controllers.

Now if you suddenly shutdown DC-01, all the other users will automatically select any available domain controller and get themselves authenticated. But due to the configuration, App-01 and App-02 will still try to connect DC-01 only to get authenticated or query anything from LDAP. Since DC-01 is already down, the Active Directory/LDAP query will fail and your app will stop working. If they are really critical apps (such as Banking, IAM, Payment Gateways, etc.), your business will suffer a lot.

But if you have identified that App-01 and App-02 are hardcoded with DC-01, you can change their configuration and point them to another domain controller, say DC-02. In this case, since the dependencies on DC-01 has been removed, there will be no impact if you take DC-01 down.

So, it’s highly recommended that you must check any possible dependencies on a DC and remove them before decommissioning. Domain Controllers in any environment are the backbone of IT Infrastructure and almost each and everything has to pass through them. If anything goes wrong with DCs, the impact will always be Global.

Few things you have to remember before doing the settings:

  • Don’t do it in all the Domain Controllers at the same time, else this will lead you an outage.
  • Make sure there is no FSMO Role available on the DC before doing these settings. If there is any FSMO Role hosted on that DC, transfer it to any other DC before change.
  • Once you collected the logs, make sure to rever the changes. After doing these settings, huge no of logs will be generated in Event Viewer and if you don’t revert the changes, the logs will keep coming.
  • Most important: In logs, you only need to take care of service accounts. you will find lot many computer and user accounts but you can safely ignore them. However if you see any service account, you have to find out for which App this service account is getting used and do the needful.

This is all for this post. In the next post, you will get the detailed Step by Step procedure to identify the LDAP dependencies on a DC.


Leave a Reply

Your email address will not be published. Required fields are marked *