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.

iptables complete

So after a weekend primarily away from my computer (probably for the better :-) I had the chance to sit down and work out iptables. Although the Gentoo Wiki article was helpful in getting the kernel configured correctly, I did not want to write an iptables start script- after all, iptables is a service, so why not utilize it as such? Instead, I used Linux Home Networking's tutorial to create my own firewall script, complete with logging. I was also fortunate to reference a pre-built firewall script, authored by a friend and coworker, that he uses as a standard template for all of his RHEL5 servers at UGA.

I created three chains, LOG_DROP, LOG_ACCEPT, and LOG_REJECT, to log packets when needed. I did not use LOG_DROP, nor LOG_REJECT (maybe in the future?), and instead am just using REJECT with --reject-with tcp-reset for TCP packets and icmp-port-unreachable for UDP packets to help mask the fact that I'm using a firewall. If the packets are simply dropped, it'd be pretty easy for an intruder to realize that I'm running a firewall because his packets would not result in the standard --tcp-reset or icmp-port-unreachable to indicate a nonexistent service. In the future, I may consider logging some of the rejected packets.

Right now the only services I am logging when accepted are SSH & SFTP (both use port 22), as logging every http request is impractical.

Unlogged accepts include http (port 80) and SAMBA (netbios-ssn, microsoft-ds, UDP 137 & 138). One key problem I had was allowing SAMBA to continue to work with the firewall enabled. With iptables running, I could only access my SAMBA shares by using the machine's IP, and not its hostname. While this problem was frustrating, it forced me to better manage my system by ensuring that samba was configured correctly (/etc/samba/smb.conf), my hostnames were set properly (it was not- only localhost was set in /etc/hosts), as well as resolv.conf (/etc/resolv.conf). This forum post eventually led me to realize that I needed to accept traffic on ports 137 & 138 on top of netbios-ssn (UDP 139), and microsoft-ds (TCP 445).

Further securing SAMBA, I specified the allowed source IPs on my network, both within smb.conf and iptables. If there's anything I've learned, its that redundancy in terms of security is never a bad idea.

Below is a (modified) iptables firewall script:

#!/bin/bash

# Stateful firewall for hostname

########################
# Ethernet Information #
########################

# Device: lo
# IP: 127.0.0.1
# Hostname: localhost

# Device: eth0
# IP: 192.168.2.3
# Hostname: hostname

# Flush all tables
iptables -F

# Remove all non-default cahins
iptables -X

#+-------------------------------+
#| Setup Firewall Process chains |
#+-------------------------------+

# Create a LOG_DROP chain for dropped incoming requests to be logged
iptables -N LOG_DROP
iptables -A LOG_DROP -j LOG --log-level info --log-prefix "Firewall-LOG_DROP: "
iptables -A LOG_DROP -j DROP

# Create a LOG_REJECT chain for rejected incoming requests to be logged
iptables -N LOG_REJECT
iptables -A LOG_REJECT -j LOG --log-level info --log-prefix "Firewall-LOG_REJECT: "
iptables -A LOG_REJECT -j REJECT

# Create a LOG_ACCEPT chain for accepted incoming requests to be logged
iptables -N LOG_ACCEPT
iptables -A LOG_ACCEPT -j LOG --log-level info --log-prefix "Firewall-LOG_ACCEPT: "
iptables -A LOG_ACCEPT -j ACCEPT


# Accept all connections from localhost
iptables -A INPUT -i lo -j ACCEPT

# Accept reply packets
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Accept PING requests
iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT

#+-----------------------------------+
#| Accepted services that ARE Logged |
#+-----------------------------------+

#SSH & SFTP (TCP)
iptables -A INPUT -p tcp --dport ssh -j LOG_ACCEPT

#+---------------------------------------+
#| Accepted services that are NOT Logged |
#+---------------------------------------+
# HTTP (TCP)
iptables -A INPUT -p tcp --dport http -j ACCEPT

# HTTPS (TCP)
#iptables -A INPUT -p tcp --dport https -j ACCEPT

# TOMCAT (TCP)
#iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
# If we're only using TOMCAT (no apache), we can forward traffic to 8080
#iptables -t nat -A OUTPUT -d localhost -p tcp --dport 80 -j REDIRECT --to-ports 8080
#iptables -t nat -A OUTPUT -d hostname -p tcp --dport 80 -j REDIRECT --to-ports 8080
#iptables -t nat -A PREROUTING -d hostname -p tcp --dport 80 -j REDIRECT --to-ports 8080

# RAILS (TCP)
#iptables -A INPUT -p tcp --dport 3000

# netbios-ssn (UDP)
#iptables -A INPUT -p udp --dport netbios-ssn -j ACCEPT
iptables -A INPUT -p udp --source 192.168.2.0/24 --dport netbios-ssn -j ACCEPT

# netbios-ssn (TCP)
#iptables -A INPUT -p tcp --dport netbios-ssn -j ACCEPT
iptables -A INPUT -p tcp --source 192.168.2.0/24 --dport netbios-ssn -j ACCEPT

# microsoft-ds (TCP)
#iptables -A INPUT -p tcp --dport microsoft-ds -j ACCEPT
iptables -A INPUT -p tcp --source 192.168.2.0/24 --dport microsoft-ds -j ACCEPT

# microsoft-ds (UDP)
#iptables -A INPUT -p udp --dport microsoft-ds -j ACCEPT
iptables -A INPUT -p udp --source 192.168.2.0/24 --dport microsoft-ds -j ACCEPT

# nmbd (UDP) required for SAMBA to send requests via broadcasting
iptables -A INPUT -p udp --source 192.168.2.0/24 --dport 137:138 -j ACCEPT
#iptables -A OUTPUT -p udp --dport 137:138 -j ACCEPT

# LOG & Drop malicious IPs
#iptables -A INPUT --source xxx.xxx.xxx.xxx -j LOG_DROP

# Reject remaining packets, do so with tcp-reset and icmp-port-unreachable
# so hackers don't know we're running a firewall
iptables -A INPUT -p tcp -i eth0 -j REJECT --reject-with tcp-reset
iptables -A INPUT -p udp -i eth0 -j REJECT --reject-with icmp-port-unreachable

I really enjoyed this project and learned a lot. After getting my basic firewall set up, I feel confident that I could do it again, now that I understand most of the iptables flags and commands
NAT translation and masquerading may be a project for a different day, but at least now I'm familiar with what they are and how they work.

Furthermore, I think this project will serve as a good segway into my next one, which is better learning SAMBA and how to configure it.

IPTables

It is high time I really sat down and figured out IPTables. Similar to my experience with SAMBA, I've used IPTables in the past, though I was more just shooting in the dark than masterfully configuring my ever-important firewall.

I think I'll get started on this first, as it is 1.) interesting 2.) important, and 3.) something I should have done a long time ago.

So, my initial project line-up as of right now is as follows:

1.) Learn how to properly and diligently manage ip tables
2.) Explore SAMBA further and get it working pristinely at my home set up
3.) Set up SSHFS and figure out how to use keys instead of tunneled clear-text passwords

Some useful links to aid me in my quest:
Gentoo-Wiki HOWTO_IPtables_and_stateful_firewalls
IP Tables Tutorial