Active Directory Port Requirements

Here on the client site, we're in the process of getting our VMWare View 4.6 environment up and working. As one of the required steps, we need to get our vCenter and View Connection Servers on the domain. It so happens that our client runs their own domain (as much as I'd like to run our own), so we've had to coordinate with them for this effort. When trying to join our server to the domain, the servers (which are Windows 2003) are able to query DNS, resolved the FQDN, and identify the Domain Controllers, however we could never get to the point where we're prompted to join our servers. Instead, we receive the following error:

DNS was successfully queried for the service location (SRV) resource record
used to locate an Active Directory Domain Controller for domain local:

The query was for the SRV record for _ldap._tcp.dc._msdcs.local

The following AD DCs were identified by the query:

server1.fqdn
server2.fqdn

Common causes of this error include:

- Host (A) records that map the name of the AD DCs to its IP addresses are
missing or contain incorrect addresses.

- Active Directory Domain Controllers registered in DNS are not connected to
the network or are not running.

We initially thought the error to be related to WINS as TCP port 137 was closed from our VLAN to the client's VLAN that hosts the Domain Controller (yes, even in a 2008 AD Environment, the client still uses WINS). We ensured that TCP 389 was open by using telnet and confirmed that it was. As it turns out, that wasn't the issue. We found that although TCP 389 was allowed, UDP 389 was being blocked. After enabling UDP 389, we were able to query AD fine and join the domain.

This was a bit perplexing to us as I've never known AD to require UDP 389, but perhaps that is because its always been open for me. After a bit of Googling, I learned that LDAP only uses UDP 389 when querying the domain to find the list of domain controllers. After querying DNS and getting a list of possible DCs, the client's netlogon service sends a datagram to each domain controller in the form of a UDP LDAP packet, over UDP 389. All available domain controllers respond with the information for DcGetDCName. The client's netlogon service then caches this information to prevent having to constatly query the DCs. Thanks to Marc Nivens at Experts-Exchange for the tip [link].

So long story short, open TCP AND UDP 389 for LDAP/Active Directory.

Addendum

As noted above, after we had opened UDP 389, we were able to get a credential prompt, however after entering correct credentials, we would still receive some odd errors and could not join the server to the domain. After a bit of Googling, we found this Microsoft Technet article outlines the ports required for 2003 and 2008 domains, most notably the high-level ports.

Windows Batch Scripting and Win2k8 AD GPO Functionality

Created this script and saved it as a .bat file to loop through values stored in a comma-delimited file to reboot specific machines:

FOR /F %%A IN (filename.csv) DO (
ECHO. %%A >> result.txt %1
shutdown -m \\%%A -r -f -t 10 -c "Your workstation will reboot in 10 seconds for scheduled maintenance" >>result.txt %1
)

And some cool functionality that you can do using GPOs in AD 2008:

• Set/Change Local User Passwords on all workstations in the domain
• Map network drives without using vb scripts/batch files
• Map printers without using vb scripts/batch files
• Disable USB storage devices using REG keys
• Disable specific hardware devices (CDROM drives, imaging devices, etc)
  

Fast Forward 8 Months

So again, I have criminally lapsed in my posts on this blog. Since that September post, I left my previous job at the University of Georgia, had a nice 2-week backpacking trip through Europe away from computers and familiar faces, and returned in mid October to begin work for the man a large technology consulting firm, based out of the Atlanta office.

I'm currently on a 6-month 10-month project for a federal government client, spending 4-5 days of the week in the greater DC area, working as, to my dismay, a "Windows Desktop Engineer." I've been able to grab a few server tasks on the side, and the role has afforded me some valuable experience with Windows Server 2008 and Active Directory, however I find myself a good distance away from where my true interests lie: Linux servers and virtualization technologies.

At work, I've learned a good bit about GPO authoring, Active Directory 2008 configuration and management, Ghost Suite 2.5, Windows Server 2008 implementation of DHCP and DNS, enterprise-level IT, and the nature of consulting.

In what little time I have at home every few weekends (I tend to spend weekends in different cities or staying in DC), I've been playing around with Windows Server 2008 and Active Directory architecture in a virtual environment. Since leaving UGA, I had to forfeit my VMWare Workstation license, and thus have been learning to use Sun's VirtualBox. Aside from the networking, I've found that many of the standard features are comparable to VMWare Workstation.

In the coming weeks, I hope to have the opportunity to play around with Xen virtualization and KVM in Linux. More on that later!