Access Denied - 02 Apr 2001

Get answers to your security-related Win2K questions

[Editor's Note: Do you have a security-related question about Windows 2000? Send it to [email protected], and you might see the answer in this column!]

I'm locked out of my Win2K Professional computer, which isn't a member of a domain. I logged on as Administrator and opened the Microsoft Management Console (MMC) Local Security Policy snap-in, then accidentally assigned the Deny logon locally right to the Users group. Now, no one can log on to the computer—not even as Administrator. How can I get back into the system?

If your computer is connected to a network, you can remotely give the Administrator the right to log on locally again. Log on to another Win2K system on the network, then open a command prompt. Connect to your locked-down system as the local Administrator by connecting to its root drive, which I assume is C. Type

net use \win2kproc$ password /user:win2kproadministrator

at the command line, where win2kpro is the name of your computer, and password is the password of the local Administrator account. This connection should work because now you're performing a network logon, and your accidental setting denies only local logons. Now that you're logged on remotely as Administrator, open the MMC Computer Management snap-in, right-click Computer Management (Local), then select Connect to another computer. Enter your computer name, and click OK. In the Computer Management snap-in, open the system toolslocal users and groupsgroupsusers container and delete Authenticated Users and INTERACTIVE as members. Both of these members effectively add the local Administrator account to the Users group (i.e., Authenticated Users and INTERACTIVE implicitly include Administrator). Click Apply, then Close.

Now, you should be able to log on locally. When you do, open the Local Security Policy snap-in and remove the Users group from the Deny logon locally policy. I recommend that you add Authenticated Users and INTERACTIVE back to the Users group.

If you can't reach your system from the network, the fix is more complicated. If your boot volume isn't NTFS, boot to DOS from a DOS boot disk and delete %systemroot%system32grouppolicyadmsystem.adm and %systemroot%system32grouppolicymachineregistry.pol. Then, open %systemroot%system32grouppolicygpt.ini and edit it by adding 1 to the current value of Version=.

If your boot volume is NTFS, you must use a tool such as NTFSDOS from http://www.winternals.com to delete these files and edit gpt.ini. Note that deleting system.adm and registry.pol and editing gpt.ini will erase any changes you've made in group policy.

Next, use an emergency repair disk (ERD) to restore the registry, including the SAM and SECURITY keys. For more information about restoring the registry, see "Backing up, restoring, and recovering the Windows 2000 registry" in Win2K Server Help (Figure 1 shows this Help page). If you didn't make an ERD, you must use the original copy of these keys that Win2K installation created. To get the original copies, boot to DOS from a disk and copy the Sam and Security files from %systemroot%repair to %systemroot%system32config.

Be aware that restoring the original registry causes you to lose changes to users, groups, audit policy, account policy, and rights assignments that you made since you made the copy of the hive files. However, you must replace the SAM and SECURITY keys to erase the rights assignment you made previously, and you must delete the group policy files to prevent the system from executing the rights assignment again.

My system is experiencing inexplicable account lockouts that cause users to call the Help desk to have their account unlocked. To diagnose the problem, I've enabled auditing in the Default Domain Policy organizational unit (OU), which Figure 2 shows. However, no event ID 644 messages appear in the domain controllers' (DCs') Security logs. What am I doing wrong?

When a DC detects that a user account has exceeded the number of failed logons that you've specified in the domain's account policy, the DC logs event ID 644 User account locked—if you've configured the audit policy on the DC correctly. In Figure 2, I see that you've enabled the Audit account management policy for failures only. However, although event ID 644 is in the Audit account management policy, it's actually a successful event—not a failure. In fact, this policy has no failed events, nor do the Audit policy change, Audit process tracking, or Audit system events policies. Enable auditing for successful events of Audit account management, and you'll see event ID 644 appear.

During a recent security audit of my domain, I learned that I should change the name of the Administrator account on all my systems. My organization has more than 1000 workstations and servers. How can I automate this change?

To rename the Administrator account on every computer in your domain, open the MMC Active Directory Users and Computers snap-in, right-click the domain, then select Properties. Click the Group Policy tab, and edit the Default Domain Policy Group Policy Object (GPO). Figure 3, page 14, shows where you specify the name of the Administrator account: Click Computer Configuration, Windows Settings, Security Settings, Security Options, then double-click Rename administrator account, and enter a name. Be aware that Group Policy can rename the Administrator only once. For example, if you use Group Policy to rename Administrator to "Bozo" and later configure Group Policy to rename Administrator to "Dumbo," the account name remains "Bozo" because Group Policy looks for the name "Administrator," not the account's SID. (Of course, you can still change "Bozo" to "Dumbo" with another method, such as opening the Active Directory Users and Computers snap-in, then renaming "Bozo." That would change "Bozo" on only one machine, however.)

Renaming the Administrator account is a common recommendation because the account is a well-known target for attackers. However, be aware that tools such as RedButton have been around for years and will rediscover the Administrator account's name through anonymous connections. To defeat these tools, enable the policy Additional restrictions for anonymous connections under Security Settings. Set the policy to Do not allow enumeration of SAM accounts and shares.

For another method of renaming the Administrator account, see Troy Jerkins, "Change a Subnet's Administrator Password," March 2001. In Jerkins's method, you use a script to accomplish the change.

I have a high-security system for which I must keep unbroken audit trails. If the Security log fills up, I'd rather have Win2K crash than lose audit events. Group Policy contains two policies that might fulfill this need, but they seem synonymous. Security Options (which is under Computer Configuration, Windows Settings, Security Settings, Local Policies) contains the policy Shut down system immediately if unable to log security audits. Settings for Event Log (which is under Computer Configuration, Windows Settings, Security Settings, Event Log) contains the policy Shut down the computer when the security audit log is full. What's the difference between these policies, and which one should I use?

When you enable the policy Shut down system immediately if unable to log security audits, it sets the value of the CrashOnAuditFail of type REG_DWORD entry under the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa registry subkey to 1. If you've enabled this setting and the Security log fills, Win2K sets CrashOnAuditFail to 2 and crashes. After you reboot, Win2K accepts no network connections and lets only members of the Administrator group log on at the console. After logging on, you must reset CrashOnAudit to 1, save and clear the Security log, and reboot. The system then functions as usual.

The other policy, Shut down the computer when the security audit log is full, appears to be an unfinished afterthought (also note that it doesn't appear in the local computer GPO). During testing, I enabled the policy and caused the Security log to fill several times. The first time the log filled, the system initiated a shutdown sequence similar to a typical Win2K shutdown. When I rebooted, however, the system didn't force me to save and clear the log, and the next time the Security log filled, Win2K didn't crash. I researched this policy further in the Microsoft Windows 2000 Resource Kit and found a reference that simply stated that you should use Shut down system immediately if unable to log security audits instead.

What's the best way to display a legal notice to users who are logging on?

To establish legal recourse for intruders and malicious employees, display a legal notice at logon that, among other things, identifies the network a user is entering, informs the user that his or her actions might be monitored, and states that only authorized users are allowed entry. With about 5 minutes of work, you can configure every system in your domain to display such a notice. Open the Active Directory Users and Computers snap-in, right-click the domain, and select Properties. Click the Group Policy tab, and edit the Default Domain Policy GPO as follows: Navigate to Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options, then specify values for Message title for users attempting to log on and Message text for users attempting to log on. You must specify both a title and text, or Win2K won't display the message. Consult your legal department for proper wording.