What All Ports Are Rrequired By Domain Controllers And Client Computers?

This article explains the key port requirement for Client computers and Domain Controllers communicating with each other.

Active Directory communication takes place using several ports. These ports are required by both client computers and Domain Controllers. As an example, when a client computer tries to find a domain controller it always sends a DNS Query over Port 53 to find the name of the domain controller in the domain.

The following is the list of services and their ports used for Active Directory communication:

* UDP Port 88 for Kerberos authentication
* UDP and TCP Port 135 for domain controllers-to-domain controller and client to domain controller operations.
* TCP Port 139 and UDP 138 for File Replication Service between domain controllers.
* UDP Port 389 for LDAP to handle normal queries from client computers to the domain controllers.
* TCP and UDP Port 445 for File Replication Service
* TCP and UDP Port 464 for Kerberos Password Change
* TCP Port 3268 and 3269 for Global Catalog from client to domain controller.
* TCP and UDP Port 53 for DNS from client to domain controller and domain controller to domain controller.

Opening above ports in Firewall between client computers and domain controllers, or between domain controllers, will enable Active Directory to function properly.

Working with Read Only Domain Controllers

Windows Server 2008, Microsoft has brought back a feature that we have not seen since Windows NT; Read Only Domain Controllers. In this article, I will explain why this is, and the advantages of using Read Only Domain Controllers.

I hardly ever watch television, but when I sat down to write this article, I couldn’t help but remember an episode of 30 Rock that I saw a while back. In that episode, the show’s main character, Liz Lemon, was dating a guy who was the only person in New York City who was still selling pagers. When Liz told him that nobody uses pagers anymore because everybody uses cell phones, he insisted that technology was cyclical, and that the pager was going to make a big comeback.

Although the remark was intended to be comical, I think that technology is more cyclical than most people realize. For example, I do not expect to ever see the pager making a comeback, but is cell phone texting really all that different from the text based pagers that we all had fifteen years ago?

Perhaps a better example of the cyclical nature of some technology is a new type of domain controller found in Windows Server 2008 called a Read Only Domain Controller, or RODC. The reason why I say that this is an example of cyclical technology is because in a way, RODCs are a left over from over a decade ago.

Windows NT was Microsoft’s first Windows Server operating system. Like modern Windows Server operating systems, Windows NT fully supported the use of domains. What was different though, was that only one domain controller within each domain was writable. This domain controller, known as the Primary Domain Controller or PDC, was the only domain controller that an administrator could write information to. The primary domain controller would then propagate updates to the other domain controllers within the domain. These other domain controllers were known as backup domain controllers, and were read only in the sense that they could only be updated by the primary domain controller.

Although this domain model worked, it had its downside. Most notably, a problem with the primary domain controller could cripple the entire domain. As you probably know, Microsoft introduced some major changes to the domain model when they released Windows 2000 Server. Windows 2000 Server introduced two new technologies for domain controllers, both of which are still in use today; the Active Directory, and the multi master domain model.

Although there is still a PDC emulator role and a few other specialized roles, for the most part every domain controller in a multi master domain model is writable. That means that an administrator can apply an update to any domain controller, and the update will eventually be propagated to all of the other domain controllers in the domain.

The multi master domain model was retained in Windows Server 2003, and is still used in Windows Server 2008. However, Windows Server 2008 also allows you to create Read Only Domain Controllers. RODCs are domain controllers on which the Active Directory database cannot be updated directly by administrators. The only way of updating these domain controllers is to apply a change to a writable domain controller, and then allow the change to propagate to a RODC. Sound familiar?

As you can see, RODCs are nothing short of a relic from the days of Windows NT. In this case technology truly has become cyclical! Of course Microsoft would not have brought back RODCs if there were not some advantage to doing so.

Before I begin explaining why Microsoft brought back RODCs, let me first clarify that the use of RODCs is completely optional. If you want every domain controller in your entire forest to be writable, then you can certainly do that.

The other thing that I want to quickly mention is that even though RODCs are very similar to the Backup Domain Controllers (BDCs) that were used in the days of Windows NT, they have evolved a bit. There are a couple of things that are unique about RODCs, and I will point those things out as we go along.

OK, so why did Microsoft bring back RODCs? It has to do with the challenges of supporting branch offices. Branch offices have traditionally been tough to support because of their isolation and because of the nature of the connection between the corporate headquarters and the branch office.

Traditionally, there have been several different options for managing branch offices, but each has its own set of advantages and disadvantages. One of the more common ways of dealing with branch offices is to keep all of the servers in the main office, and provide the branch office users connectivity to those servers through a WAN link.

Of course the most obvious disadvantage to using this method is that if the WAN link goes down then the users who are in the branch office are unable to do much of anything, because they are completely cut off from all of the server resources. Even if the WAN link is functional though, productivity may suffer because the WAN links are often slow and easily congested.

Another common option for dealing with branch offices is to place at least one domain controller in the branch office. Often times, this domain controller will also act as a DNS server and as a global catalog server. That way if the WAN link goes down, the users in the branch office will at least be able to log into the network. Depending on the nature of the branch office user’s jobs, there may also be other servers located at the branch office.

While this solution usually works out pretty well, there are some disadvantages to using it. The primary disadvantage is the cost. Placing servers in branch offices requires the organization to shell out money for server hardware and for any necessary software licenses. There are also support costs to consider. An organization needs to determine whether they want to hire full time IT staff to support the branch office, or if they can deal with the amount of time that it takes the IT staff to travel from the main office to the branch office when onsite support is needed.

Another issue with keeping servers at the branch office is security. It has been my experience that servers located outside of the datacenter are basically unsupervised. They are often just locked in a closet at the branch office, and employees at the office who have a key to the closet have to be trusted not to mess with the servers.

As I mentioned earlier, WAN connections can often be slow and unreliable. Herein lies another problem with placing servers in a branch office. Domain controller replication traffic can congest the WAN link.

This is where RODCs come into play. RODCs are just like any other domain controllers, except that the Active Directory database is not directly writable. Placing an RODC at a branch office does not get rid of Active Directory replication traffic, but it does reduce the workload of the bridgehead servers because only inbound replication traffic is allowed.

RODCs may also improve security, because people at the branch office cannot make any changes to the Active Directory database. Furthermore, no account information is replicated to RODCs. This means that if someone were to steal a RODC, they would not be able to use the information that they get off of it as a means for hacking user accounts. The fact that user account information is not written to RODCs also reduces the amount of replication traffic that flows across the WAN link, but it does mean that with some exceptions user authentication still depends on the WAN link being available.