τεχνοσοφια

Perhaps I am mistaken, but I thought one of the biggest purported benefits of the newest incarnation of Active Directory was its supposed reliance upon the more commonly used DNS system for computer name lookups rather the old WINS and NetBIOS lookup system. I've recently installed a new server running Windows Server 2003 Enterprise and hooked it into our Active Directory 2003 domain and configured it to run Terminal Services. Upon this assumption, I disabled NetBIOS in the TCP/IP stack and turned off the TCP/IP NetBIOS Helper service.

When I connect to the server via Remote Desktop and login with a local administrative account, I get in just fine. When I specify my domain credentials, however, my connection is refused because Terminal Services apparently has problems reaching the RPC Server. Says it is unavailable. Turning back on the NetBT Helper service clears this up, but I did not think NetBIOS would be required for name resolution given AD integration with DNS. In the eventlog, TS shows the following error after the "RPC Server is unavailable" error: "Unable to obtain Terminal Server User Configuration".

Any ideas? I'm alright with leaving on the NetBT service, but I just don't understand why it's necessary.

I have tried re-enabling NetBIOS in the stack and that has zero effect on the connection behavior. I have also checked the DNS settings and the AD domain name is in the list of default domains to search through.

NOTE: Perhaps it is due to having external University DNS servers listed instead of the AD DNS servers. Come to think of it, I'm not sure why we would be using external DNS servers if we run AD. Giving this a try.

ADDENDUM: Apparently our AD servers do not run their own DNS; the records are offloaded to the campus DNS system. Perhaps this is the culprit?

What do you do when you've got a server to install and you're too lazy to burn a CD with all the latest service packs and hotfixes? I suppose you could attach the server to the Internet and head over to Microsoft's Windows Update website. But then you would be committing a grievous faux pas among systems people. Only connect an unpatched machine to the Internet if you wish to have it 0wN3d in seconds flat.

One strategy for patching up your server is to install on your local network a server running Windows Software Update Services, and configure IPSec on your new server to allow connections only to the local WSUS server. For the sake of convenience, I have also allowed outgoing DNS requests. If you know the IP address of the WSUS server, these are probably unnecessary, but otherwise shouldn't pose much of a risk.

Here's an IPSec script, which I called newServerLockdown.txt, that you may use to accomplish this task.

# IPSec Configurations to Lock Down a New Server
#
# WHAT IS THE POINT?
# Well, good security practices dictate keeping servers off the network until they have been
# fully patched, which is rarely achievable from system CDs. Thus, before a server is conn-
# ected to the network, we use IPSec to restrict traffic such that no host may initiate an
# incoming connection, and only the local Windows Software Update Server may be contacted.
#
# HOW TO RUN THIS SCRIPT
# netsh -f newServerLockdown.txt
#
# THEN WHAT?
# Once the server is fully patched, hotfixed, and service packed, these IPSec rules may be
# blown away with two commands, or so it is believed by the author:
# netsh ipsec dynamic delete all
# netsh ipsec static delete all
#
# NOTE
# Originally tested on November 23, 2005
# Inspiration from:
# http://www.unisanet.unisa.edu.au/staff/davidgardiner/ipsec/netsh-script.txt
# and
# http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=41571

############# Set IPSec mode to dynamic ############

pushd ipsec dynamic

# Dump packet drops to the Event Log
set config property=ipsecdiagnostics value=7

# Allow as few exemptions as possible
set config property=ipsecexempt value=3

# During boot sequence, allow only stateful connections initiated by the server
set config property=bootmode value=stateful

popd

############ Set IPSec mode back to dynamic ############

pushd ipsec static
set store location=local

# Clean the slate and remember these settings
# DO NOT DO THIS IF YOU DO NOT WANT YOUR STATIC CONFIGS ZAPPED!
delete all

# Create a new policy
add policy name="Restrict to WSUS" activatedefaultrule=NO

# Create actions for filters to use
add filteraction name="PERMIT" action=PERMIT
add filteraction name="BLOCK" action=BLOCK

# Default policy - block everything
add filterlist name="All incoming traffic"
add filter filterlist="All incoming traffic" protocol=ANY srcaddr=ANY dstaddr=ANY description="Block all incoming traffic"
add rule name="Default incoming block" policy="Restrict to WSUS" filterlist="All incoming traffic" filteraction="BLOCK"

# Allow outgoing DNS requests
add filterlist name="DNS resolution"
add filter filterlist="DNS resolution" protocol=TCP srcaddr=ME srcport=0 dstaddr=DNS dstport=53 mirrored=YES
add filter filterlist="DNS resolution" protocol=UDP srcaddr=ME srcport=0 dstaddr=DNS dstport=53 mirrored=YES
add rule name="Allow DNS resolution" policy="Restrict to WSUS" filterlist="DNS resolution" filteraction="PERMIT"

# Allow outgoing HTTP connections to WSUS
add filterlist name="HTTP" description="Allow outbound HTTP connections to WSUS"
add filter filterlist="HTTP" protocol=TCP srcaddr=ME srcport=0 dstaddr=YOUR.WSUS.HOST.NAME dstport=80 mirrored=YES
add filter filterlist="HTTP" protocol=TCP srcaddr=ME srcport=0 dstaddr=YOUR.WSUS.HOST.NAME dstport=443 mirrored=YES
add rule name="Allow HTTP traffic to WSUS" policy="Restrict to WSUS" filterlist="HTTP" filteraction="PERMIT"

# Activate policy
set policy name="Restrict to WSUS" assign=YES

popd
exit