Windows Domain Controllers

The use of domain controllers in a Windows network has its advantages. Centralized security management, being one of the major ones.

However, there are some disadvantages, also. Recently, we had a customer using domain controllers for security and authentication. The controllers reside at the corporate headquarters, and the remote stores access these to authenticate users when they log in. All was good and well, until the day that their ISP made a mistake, and changed the IP address of the corporate connection. The result? None of the users at the stores could log in! Since they could not access the domain controllers, they were not authenticating. It was not until several hours later, when the ISP got their issues straightened out, that the remote stores could log in and do business.

This downtime could have been avoided in a couple of ways. First, if each of the stores had its own, resident, secondary domain controller, then the authentication would have been occurring at the remote stores, and the remote users would not have been impacted. This still allows for having centralized management. If the password changes, for example, this would flow between the primary domain controller, and the secondary domain controllers at the remote.

The other way that the users could have logged in, was by using the local login, instead of the domain login. However, since the local logins had not been maintained with the domain logins, most could not remember what credentials they needed to use. In addition, there were some security policies that had been implemented, that prevented the users from being able to process, even if they were able to log in locally.

The bottom line is that, like just about everything else in your network environment, the use of domain controllers has to be evaluated, and maintained, with the worst case scenario in mind. There needs to be contingency plans, and fall-back options thought out, documented, and tested.