This week has been interesting, mainly in that I was reminded about the simple things in Active Directory and how much harder they become when you dont pay them enough attention. Replication is much like Ron Burgundy — kind of a big deal. If you do not pay enough attention to replication between domain controllers in Active Directory, bad things happen.
Sure they seem like small things, but over time, these small things like change in the couch cushions can add up to a big ticket problem. For me, the issue wasn’t all that bad, but it did take some head scratching (outside the scope of the actual issue) and a brief conversation with someone wiser than I about the symptoms of my issue.
We don’t trust you anymore, go away
Windows 7 is a rather finicky OS (moreso that Windows XP, and probably a bit less so than the OS between XP and 7). Because computers are still objects within Active Directory that access other secured resources within the directory, they too authenticate. In reality, this means that computers have accounts equivalent to User objects within the AD environment. These accounts allow computers to tell Active Directory that they belong within the environment and should be allowed to access resources. Just like when I logon to the domain and request access to resources by providing credentials, computers in the environment do the same.
If for some reason, the Domain Controller cannot match the credentials presented by the computer to what is stored in its database, the Domain Controller refuses authentication and presents a message about trust relationships.
I didn’t create credentials for the computer, what the heck do I do now?
When a computer is added to an Active Directory domain its account is established and the password set. Then the password is managed by the computer and AD and changed automatically about every 30 days or so. If the computer is no longer trusted by the domain, it is likely that the password is incorrect or has gotten lost in translation causing authentication to fail.
My issue was a replication issue which caused the computer accounts of a few workstations to fail authentication. Because it is not the best idea to maintain only one domain controller in any Active Directory environment, and because of the way that AD manages information about objects, replication happens.
Perhaps an example will work here. Suppose I create a user object for John Smith using Active Directory Users and Computers (ADUC) on a Domain Controller named creatively DC1 at my office. John will be starting his new career as a data entry specialist in my company’s Houston office in a week or so. Adding the user account for John to a DC in my office works just as well as if I had flown to Houston (or remoted into the DC there) and added the account. Because replication sends all objects created, maintained, or deleted to all other replication partners within the domain, a user account created in my office on DC1 can be replicated to Houston on DC2 and when John gets to work, he can logon and all is well.
Replication happens in the background and is pretty much out of site when things are going smoothly, but from experience I can tell you that you should check in on your friend replication regularly. Maybe not daily, but weekly for sure. Just to make sure that objects in the directory are being moved around without errors.
What might cause replication problems?
There are any number of settings and configurations that can cause problems with replication. Surely more than I have seen or have time to list here, but some of the basic things are:
- Improperly configured links
- Unmanaged Replication configurations
- Misconfigured Firewalls
- Equipment failure
Improperly configured links
When you establish replication between two (or more) Active Directory domain controllers, you create links between them that allow these DCs to exchange information. The links are one way which means that each domain controller has two links to each replication partner. The links can be configured to handle high speed links (fast connections, like you might see between domain controllers in the same site) and slow links (which may be used to link two remote locations). When the links are configured correctly things work really well, but if you neglect to consider the speed of your Internet connection (on both ends) replication may suffer as a result.
Replicating information across a slow link that is configured to behave like a fast one might be a little less dire to watch than downloading a blu-ray quality video over a dial up connection, but missing information can have rather large repercussions in your environment which may be seen as inability to login, latent access or no access to resources and other things.
Unmanaged replication configurations
By this I am not suggesting that you check on replication statuses every day (depending of course on the size of your environment) but you should be looking at it regularly enough to know what is going on and that replications in all directions are happening as you need them to.
Because Active Directory is a multi-master beast, meaning that any machine configured as a domain controller carries just as much weight as any other machine configured as a domain controller, information for an object that has not yet replicated throughout the environment could be a problem. As in my earlier example, if I created the user object for John Smith, and it failed to replicate to the domain controller in Houston by the time he needed to log in, we might have a problem.
The login would likely happen, but would take a significant amount of time because the most local domain controller didn’t have the information needed to handle the request.
Misconfigured Firewalls (and other Network issues)
Windows includes a firewall to help keep things out of your environment that shouldnt be there. I would recommend disabling the firewall on all your Windows computers and servers because it will likely be a bigger headache than you are ready for. Also because all organizations should use dedicated firewalls to protect their corporate assets from the outside world.
My issue with replication came at the hands of a misconfigured firewall. The firewall was enabled for a good period of time which caused hiccups in the replication of information throughout my Active Directory environment. The symptoms displayed were the previously mentioned domain trust errors that popped up when logging on or trying to unlock a PC.
In my research and previous experience the best fix for the trust problem is to disjoin the affected system from the domain and delete the computer account from Active Directory. Then rejoin the system to AD. Normally this will take care of the symptom. Not necessarily the problem.
Outages and Equipment Failures
There is the obvious replication issue with failures and downed equipment. If the replication is scheduled to occur between two systems and one of those systems is down, obviously replication cannot happen.
Working on these issues is an interesting scenario as well. For the sake of troubleshooting, the usual steps must be followed and checked out even if the steps do not solve the problem, they will likely help you down the path to correcting the problem.
The moral?
Do not be afraid to check out the functionality of your Active Directory environment, being proactive and working to pay attention to things like replication and group policy settings. Keeping up with those tasks before the problem strikes and requires many late nights to correct. You will still have some long nights working with Active Directory, but they can be worth it, without all the fires.
great………..