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

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 Services
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 larger version.)

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 well.

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 to Deny.

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 Computer console.

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 larger version.)

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 Script
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.

[Components]
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

[InternetServer]
PathFTPRoot=D:\Inetpub\Ftproot
PathWWWRoot=D:\Inetpub\Wwwroot

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 me.