Mementos of Windows 2000
What would you need to know about Win2K if you were struck with reverse amnesia? Confused? Read on…
- By Bill Boswell
- October 01, 2002
Have you seen the movie “Memento”? No? Then stop here and rent the DVD
and watch the movie. I’ll wait until you get back...
All done? Then you know the premise of the movie. The hero’s wife is
murdered and, during the incident, the hero is injured in a way that prevented
him from developing any short-term memories. This is called reverse amnesia
because the victim remembers everything before the injury but forgets
things learned afterward. New memories last only a few minutes. In the
movie, the hero overcomes this problem and tracks down his wife’s killer
by leaving himself notes on instant photographs. To avoid forgetting the
reason for the photographs, he comes up with an ingenious idea. He tattoos
messages on his body so he can’t possibly forget where to find them.
As an ex-sailor, the idea of having lots of tattoos intrigues me, so
the movie set me to thinking about what would happen if a systems administrator,
like myself, were to get reverse amnesia so that I could remember everything
about NT but nothing about Windows 2000 other than the fact that it uses
Active Directory. I wondered: What items wouldn’t easily be found in the
online help and the system documentation, but are important enough for
a tattoo? And what screenshots would I stuff in my pocket so I could figure
out how things really work every morning when I wake up? What follows
is a short list.
Dynamic DNS Requires Netlogon and the DHCP Client
I’d start with this reminder because everything in AD depends on
a properly configured DNS zone that contains Host (A) and Service Locator
(SRV) records registered by domain controllers.
Win2K and XP member desktops send queries to DNS asking for any _ldap
and _kerberos SRV records that have been registered by domain controllers
in the local site. The DNS server returns every SRV record that fits the
criteria, and the client chooses a logon server by sending a quick LDAP
bind request to each one, then selecting the first to respond.
Keeping these SRV records up to date is crucial to systems operation,
so a domain controller refreshes its DNS records every hour. The service
at the domain controller responsible for registering SRV records is Netlogon.
You can manually register SRV records for a domain controller by stopping
and starting the Netlogon service either using the NET STOP and NET START
commands or the Service.msc console. Stopping Netlogon doesn’t affect
Win2K and XP clients because Kerberos doesn’t use the Netlogon service.
Only down-level clients require Netlogon for authentication.
Domain controllers, along with member servers and desktops, also periodically
register their A and Reverse Lookup Pointer (PTR) records. The DHCP Client
service performs this registration. This is worth noting because when
you harden a server by turning off unnecessary services, you might be
tempted to turn off the DHCP Client service if you use static IP addresses.
Later on, if you change the server’s IP address, you may be surprised
when the resource records in DNS don’t change.
As a further reminder, I’d put a screenshot in my pocket of the standard
TCP/IP configuration settings window with a note on the back saying, “Don’t
point a domain controller at itself for DNS.” This prevents a situation
in which a domain controller with AD-integrated DNS zones becomes unable
to replicate. This is because it needs a critical DNS resource record
it can’t obtain, and it can’t find its replication partners because the
DNS records need updating. This so-called “island” DNS problem is documented
in Knowledge Base article Q275278.
LDP Shows Everything in AD
This reminder is worth a tattoo because it’s easy to forget that
the glitzy MMC consoles don’t tell the whole story about the contents
of AD. If you need to know how an AD-enabled process really works, you
need a tool that lets you look at the real structure of AD. That’s what
LDP is good for. It’s in Support Tools on the Server CD.
The strength of LDP lies in its ignorance of AD. It simply makes LDAP
queries to a domain controller and displays the results without assumptions
about standard containers or object structures. To help my reverse amnesia,
I’d put a screen shot of the main LDP window in my pocket similar to that
shown in Figure 1.
|Figure 1. LDP, which allows LDAP operations to
be performed against AD, can show the AD tree. (Click mage to view
I’d include instructions for making an LDAP connection to a domain controller.
From the menu, select Connection | Bind and give your name, password and
logon domain. Then, from the menu, select View | Tree to populate the
left pane of the LDP window with the contents of the AD tree. As you drill
down through the objects in the tree, notice that a list of attributes
appears in the right pane when you double-click an object. If you have
child domains, LDP shows the contents of the child naming contexts, as
Here’s an example of the usefulness of LDP. Win2K has a feature, if you
want to call it that, permitting a non-administrator to join a computer
to a domain, with the caveat that this can be done a maximum of 10 times.
Recently I was asked how Windows enforces this limit.
The 10-machine limit is a domain-wide limitation, so I fired up LDP and
examined the attributes of the Domain object. I found an attribute called
ms-ds-Machine-Account-Quota with a value of 10 and verified using the
Platform Software Developer’s Kit (SDK) that this was, indeed, the attribute
that set the limit for non-admin computer joins.
Then, using LDP, I determined that the Computer object for a machine
that has been joined to a domain by a non-administrator has an attribute
called ms-ds-Creator-SID. A Computer object created by an administrator
doesn’t contain this attribute. So, when an average user attempts to join
a computer to a domain, the system counts the number of computer objects
that have the user’s SID as a value of the ms-ds-Creator-SID attribute;
if this number exceeds the value for the ms-ds-Machine-Account-Quota attribute,
the user gets a “permission denied” error.
Kerberos Tickets Include Authorization Information
My next tattoo would remind me that Win2K and XP use Kerberos for
both authentication and authorization. The difference is subtle but distinct.
For example, if you visit another company, you may need to show proof
of identity so you can be issued a pass that gets you past the guards
and keeps you from getting interdicted in the hallways. This is authentication.
However, you can’t simply settle down in the first empty cubicle you find
and start making long-distance phone calls. You don’t have authorization
to use company resources in that manner.
Both classic NT and Win2K use access tokens to control authorization.
A process running in a user’s security context has an access token that
contains the user’s SID and the SIDs for any groups to which the user
belongs, along with a list of privileges assigned to the user—privileges
such as Backup and Restore and Logon Locally. Classic NT uses NTLM to
authenticate a user, and part of NTLM includes a secure mechanism called
pass-through authentication that permits a member server to obtain the
necessary information from a domain controller for building a user’s local
access token. Win2K uses Kerberos, not NTLM and pass-through authentication;
this requires some special footwork to get authorization information to
a member server.
Here’s a quick rundown of a Kerberos transaction: When a Win2K or XP
client reaches out to connect to a Win2K member server, the initial connection
request must contain a Kerberos session ticket. This ticket uniquely identifies
the user in a way that can’t be hijacked, forged or replayed.
Before a Kerberos client service can obtain a session ticket for a target
server, it needs proof that the user has already authenticated in the
domain. This is similar to the way an amusement park first requires you
to pay for an admittance ticket then forces you to pay again to get tickets
for specific rides. This proof of initial authentication takes the form
of a Kerberos Ticket Granting Ticket (TGT). Users obtain a TGT when they
first authenticate in the domain. Each time a Kerberos client requests
a session ticket for a particular server, it includes a copy of the TGT.
Once a member server has used a Kerberos session ticket to validate a
user’s identity, it needs a way to build an access token for the user.
A Kerberos ticket has a special field designed to hold vendor-specific
authorization data. Until Win2K, this field saw little commercial use.
Microsoft took advantage of it to hold a data structure called a Privilege
Access Certificate (PAC). The PAC contains the required information for
building a local access token.
This is important enough to warrant a reverse-amnesia tattoo for a couple
of reasons. First, response is affected when a user is added to a new
group. The PAC is inserted into the initial TGT issued to the user during
domain logon. It’s then copied from the TGT into each subsequent session
ticket issued to the user. TGTs are renewed every 10 hours for up to seven
days. If a user is added to a group, the user’s PAC doesn’t get refreshed
automatically. The user must first log off then log back on again to get
a new PAC that contains the SID for the new group. This contrasts with
classic NTLM, where pass-through authentication can give a user access
to a member server following a group membership change without the user
logging off. This occurs if the user hasn’t touched the server and, therefore,
has no existing access token on the server. When the server performs a
pass-through authentication, it gets the user’s new membership information
from the domain controller.
The second reason for the tattoo is to explain certain odd behavior if
a user is a member of many groups. This could cause the PAC to grow large
enough to exceed the allowable size for a UDP datagram. Ordinarily, Kerberos
uses UDP, which doesn’t support fragmented datagrams. If a Kerberos request
or reply exceeds 2,000 bytes, Win2K and XP automatically use TCP. This
can cause interoperability issues and possible performance problems.
The picture I’d put in my pocket for this tattoo would be a screenshot
of the Kerbtray utility from the Support Tools. Figure 2 shows an example.
Kerbtray shows all the TGTs and session tickets obtained by a Kerberos
client, including the name of the domain controller that issued them,
the associated flags and the ticket’s expiration.
|Figure 2. The Kerbtray displays information about
a Kerberos client’s session tickets.
RADIUS Policies Affect RRAS
Basic Routing and Remote Access configurations don’t require tattoos
or photos because, unlike NT, the RRAS service is already installed and
a simple wizard walks you through setting initial parameters. What does
require a memento is the way Win2K uses Remote Access Dial-In User Services
(RADIUS) policies to control standard dial-in access. This only takes
effect, though, when a domain has been shifted to Native mode.
If you create a user while in Mixed mode, the user’s dial-in permissions
are controlled by settings in the user’s account, exactly as they are
in classic NT. Using LDP, a reverse amnesiac would discover that this
dial-in behavior is controlled by an attribute on a User object called
msNPAllowDialin. If this attribute isn’t present, dial-in behavior defaults
Once a domain shifts to Native mode, things get a little complicated.
In Native mode, the default dial-in permissions for accounts without an
msNPAllowDialin attribute shift from Deny to Control Access Through Remote
Access Policy. You can see this in the Account tab of a User object once
you shift to Native mode after closing and reopening the AD Users and
Here’s the reason for the tattoo. The default Remote Access Policy entry
in the RRAS console is set to Deny access 24 hours a day, seven days a
week. You must set this policy to Grant before users without individual,
explicit Allow permissions can dial in using RRAS. The picture I’d use
for this tattoo would be a screen shot of the RRAS console showing the
Properties window for the default Remote Access Policies entry. Figure
3 shows an example.
|Figure 3. The RRAS console, showing the Properties
window for the default Remote Access policy. (Click mage to view
As an addendum to the note on the photograph, I’d include a warning that
changes to the authentication and encryption settings in an RRAS server’s
properties must also be made in the profile for the Remote Access Policies
entry before they’ll take effect.
Bad Guys Sneak In Through IIS—Install With Unattend
By default, Win2K Server setup installs IIS and configures a default
folder for Web files rooted at C:\Inetpub. A variety of exploits take
advantage of this configuration to gain privileged access to system files.
The tattoo is a warning that standard servers without the need for Web
services shouldn’t be running IIS, and public-facing Web servers should
never host folders in the system partition.
The only way to make these configurations is to install Win2K with an
unattended installation script that either skips IIS installation completely
or defines a different logical drive for the Inetpub folder. In addition
to the tattoo, I’d have a slip of paper in my pocket with a list of the
unattended script entries for installing Web and ftp services hosting
default files on the D: drive. The remaining IIS services would be disabled.
iis_common = On
iis_inetmgr = On
iis_www = On
iis_ftp = On
iis_nntp = Off
iis_nntp_docs = Off
iis_pwmgr = Off
iis_smtp = Off
iis_smtp_docs = Off
iis_htmla = Off
iis_w3samp = Off
iis_doc_common = Off
iis_doc_ismcore = Off
iis_doc_asp = Off
iis_doc_sdk = Off
iis_doc_mm = Off
I’d add a note that the Sysocmgr utility can be used after initial Setup
to install IIS services using the same script syntax.
I’d also have a photo like the one in Figure 4 showing a screen shot
of the IIS Lockdown Wizard, a security tool downloaded from Microsoft’s
Web site. This tool makes changes to the security settings in the IIS
metabase that removes many IIS vulnerabilities. The installation includes
an application filter called URLScan that permits defining of which Web
applications are permitted to access a server.
|Figure 4. The IIS Lockdown Wizard lets you choose
the role for a particular server.
No More Tattoo Acreage
I’ve just about run out of room for tattoos, which is a good excuse to
double my intake of pizza and milk shakes. While I add more real estate,
if you have any suggestions for Win2K mementos, please e-mail them to