Restoring Default Permissions to Windows NT System Files

Last reviewed: September 19, 1997
Article ID: Q153094

The information in this article applies to:

Microsoft Windows NT Workstation versions 3.5, 3.51, and 4.0
Microsoft Windows NT Server versions 3.5, 3.51, and 4.0

SUMMARY

When an administrator attempts to secure the Microsoft Windows NT system by changing the default Windows NT file system (NTFS) file and directory permissions set up on the <%winnt_root%> and/or the default system directories and subdirectories, some functions, such as users' ability to log on to the network, may be impaired. In extreme cases the system may blue screen on startup. If the system starts, the default permissions can be restored. If the system blue screens, the original system can be restored by installing a second copy of Windows NT.

MORE INFORMATION

The following procedure does not work in Windows NT 4.0. For additional information, please see the following article in the Microsoft Knowledge Base:

   ARTICLE-ID: Q157963
   TITLE     : SETACL.EXE not available in Windows NT 4.0

If the System Starts

Use the following procedures to restore the default permissions on the system files in the <winnt_root> and all default subdirectories.

WARNING: Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.

Logon as administrator.
The built-in SYSTEM account needs access to the Windows NT default directories and subdirectories. To get this access, do the following:
a. In File Manager use Security/Permissions to grant the SYSTEM account FULL CONTROL to the root directory of the NTFS volume that contains Windows NT.

b. Next, either select the option to Replace Permissions on

   Subdirectories, which gives SYSTEM access to the entire volume,

-or-

   go to the system's root directory (typically, WINNT35) and give
   SYSTEM full control of that directory and all subdirectories. SYSTEM
   should always have full control of all system files.

Start Registry Editor (Regedt32.exe).

Go to the following registry location:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SessionManager

Double-click the value BootExecute.

Under BootExecute, you may find a few entries, such as:

      autocheck autochk *

After any entries, add on a separate line:

      setacl /a \DosDevices\<systemdrive>:\<winnt_root>

\System32\winperms.txt \DosDevices\<systemdrive>:

NOTE that this added entry should all be on the same line under the autocheck entry.

Here <systemdrive> is the drive that Windows NT is installed on and <winnt_root> is the Windows NT root directory on that drive.

After adding the change on a typical system, the BootExecute entry looks like this while in the reged32 multi-string editor:

   autocheck autochk *
   setacl /a \DosDevices\c:\winnt35\system32\winperms.txt \DosDevices\c:

Save changes by clicking OK.

Exit the registry editor and restart the computer.

On restart, the system will set security on the system files just as it does when converting from FAT to NTFS file systems.

No Additional file security needs to be placed on the Windows NT system files if they are residing on NTFS. Any further restrictions may curtail the ability of users to log on to the individual computer or the domain.

However, it is possible to restrict user access to system files. As long as the SYSTEM account has full control of all system files, user access (usually through the group EVERYONE) can be restricted.

NOTE: Microsoft recommends using the default permissions for Windows NT. Changing these permissions may make it impossible for users to log on, print, access logon scripts, or gain access to other necessary functions. As with using the Registry Editor, make these changes at your own risk. Always have a recovery plan in case you need to revert to a previous setup.

The MINIMUM PERMISSIONS necessary to log on (again, assuming SYSTEM has full control of the volume root and all system directories and files) are:

     System_root (e.g. c:\winnt35) ------------ Everyone - READ
     System_root\system32 --------------------- Everyone - READ/EXECUTE
     System_root\system32\repl\import\scripts - Everyone - READ/EXECUTE
          (only if your users have logon scripts)

Depending on your environment, additional permissions may be necessary.

If The System Does Not Start (Blue Screen with STOP 21A)

If the administrator has modified permissions, rebooted the computer, and now receives a blue screen, then the most likely cause is that the SYSTEM account does not have adequate access to the system files and directories.

To restore access:

Install a new copy of Windows NT INTO A NEW DIRECTORY on the same volume as the existing copy. Of course, you will need to start up with the boot disks.

WARNING: If you install a new copy of NT in the same directory as the existing copy, you will erase the existing copy, all existing accounts, and so on.

Boot to the new copy of Windows NT.
Use File Manager to give the System account Full Control of the volume root and all system files and directories.

You should now be able to boot to the original copy of Windows NT. Follow the instructions above (under "If the System Starts")to restore default permissions on your system.

Additional query words: prodnt security
Keywords : ntfilesys nthowto ntsetup NTSrvWkst kbother
Version : 3.5 3.51 4.0
Platform : winnt

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: September 19, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.