AddThis Social Bookmark Button

Listen Print

Security Issues in Windows 2000's DSR Mode

by Paul Robichaux
09/20/2000

Active Directory is quite unlike the Security Accounts Manager (SAM) database we all came to know and love. The SAM was Windows NT's mechanism for storing and managing domain account information, but under the new Windows 2000 regime, the SAM is largely deprecated. It's still used to handle local machine accounts, but domain accounts are stored in, replicated by, and controlled through Active Directory. This change has its good and bad points, which I'm not going to go into here. Instead, I want to focus on one significant change that's not obvious at first blush: how the security of your network is impacted by the presence of a new boot mode designed for use in disaster recovery.

The Directory Services Restore (DSR) Mode

Despite the fact that Active Directory is a core part of Windows 2000, it's really just a big database and some associated services and interfaces that allow you, and some system components, to modify, query, add, or remove directory data. That's actually good news. In Windows NT, if the domain SAM database were damaged, you couldn't boot the affected server, and you'd have to restore it pretty much from the beginning. In Windows 2000, you can use a special boot mode called Directory Services Restore (DSR) mode. You boot into DSR mode by pressing F8 during the boot process. When you do, it's essentially like booting a Unix machine into single-user mode: The system starts normally, but the directory services don't start. This allows you to restore the directory databases, services, and configuration from a backup and restart those services only when you're ready.

However, when you boot into DSR mode you still have to log on. Since Active Directory isn't available, the credentials you provide are validated against the same type of SAM database used in Windows NT, and that means there's still a SAM database on disk. This proto-SAM is built when you migrate an existing Windows NT domain to Windows 2000, or when you create a new Windows 2000 domain. It contains credentials for the administrator account used to log on in DSR mode as well as for some built-in users and groups, which are required for the system to boot into DSR mode.

Why SAM Is Not Your Friend

Ordinarily, this wouldn't seem like a big deal. After all, there's no way to programmatically access the SAM contents unless the server is booted into DSR mode. However, the existence of the SAM file itself means that an attacker with physical access to a machine could steal the SAM file (which is stored in %systemroot%\system32\config\SAM), and run it through a password cracker like l0phtcrack. In general, this is as bad for your network as leaving all your valuables out on your front porch is bad for you. We can't get rid of the DSR mode SAM, since its presence is required to use DSR mode at all, so instead we need to find some way to tighten things up.

Protecting the Crown Jewels

While it would be nice to not have a SAM database at all, there are a number of things you can do to strengthen your DSR SAM against attack. The first step is so obvious that most people overlook it: maintain good physical security on your servers! In the security world, it's a truism that if an attacker can get physical access to your machine, you lose. There are just too many different ways to compromise, steal, or otherwise degrade the function of a box, if you can get your hands on it. So, spend a few bucks on locks or whatever other physical security measures make sense in your environment, and don't forget to safeguard your backup media. (The SAM database gets backed up as part of the Windows 2000 system state.)

The second measure is just as easy: Don't use the same password for multiple accounts. In particular, choose different passwords for the domain Administrator account (stored in Active Directory), and the DSR Administrator account (stored in the SAM). This rule is usually observed in the breach, but it's super valuable. If someone does get your SAM, do you want them to recover a password that's only useful for DSR mode, or one that unlocks your entire Active Directory treasure chest?

Thirdly, I recommend that you turn on auditing on the SAM file by using the appropriate group policy object. Of course, turning on auditing requires that you make an effort to periodically check the event logs for suspicious access. You might be thinking about the SYSKEY tool at this point (which I discuss at length in Chapter 9, "Administering the Registry," of Managing the Windows 2000 Registry). However, you should stop thinking about it. There's no way to apply SYSKEY to the DSR SAM, and SYSKEY itself is always on in Windows 2000.

A Final Danger

Microsoft's documentation makes a point that bears repeating: You are more likely to have a service interruption because you can't find or remember the DSR password than because someone attacks your SAM. For example, what happens if you're the only one who knows the password and you're out of the country when the server needs to be restored? Ooops. It's a good idea to design a process for storing high-value passwords in a way that keeps them secure, yet accessible. One method I like is to choose a random string of 20 or more characters, divide the string in half, and store each half in a separate, sealed envelope. The envelopes themselves can go to two different secure locations, like a safe-deposit box, the CEO's safe, or anywhere else where they'll be protected from loss or compromise.

Summary

It might seem like DSR mode causes more problems than it solves, but I couldn't disagree more. The ability to restore just the directory on a failed server is invaluable, because it makes it much easier to recover a downed box. That power comes with a few added warnings, though, just like those big yellow "WARNING" labels on lawn mowers. Now that you've been warned, safeguard your DSR SAM and relax in the knowledge that you're now better protected against server failures and security compromises.

Paul Robichaux is an experienced software developer and author and the principal of Robichaux and Associates, Inc. He has worked on Unix, Macintosh, and Win32 development projects over the past eight years, including a stint on Intergraph's OLE team. He is the author of Managing the Windows 2000 Registry, Managing the Windows NT Registry, and Managing Microsoft Exchange Server, all published by O'Reilly.

O'Reilly & Associates recently released Managing the Windows 2000 Registry.