MORE INFORMATION
The Windows 2000 ACL inheritance model is characterized most significantly
by its dynamic rather than static nature. By default, permissions on child
objects are automatically inherited from their parent. This is specified by
the check box labeled Allow Inheritable Permissions from the parent to
propagate to this object available on the first page of the ACL Editor
dialog box. When checked, the inheritable permissions defined on the parent
object are automatically applied to the child object and cannot be changed
at the child object.
The degree to which a permission is inheritable is defined by the Apply To
dialog box exposed on the Advanced page of the ACL Editor dialog. For
example, assume the following directory structure:
\Parent
|___Child
If the Everyone group has Full Control permissions on the Parent directory
and these permissions apply to this folder, subfolders and files, Everyone
will also have Full Control on the Child directory as long as the Child
directory Allows inheritable permissions from parent to propagate to this
object. This permission on the Child directory cannot be modified on the
Child object itself as long as the Allow inheritable permissions from
parent to propagate to this object is checked. If permissions on the Parent
are changed so that Everyone has Read Only, this modification will also
impact the Child directory automatically. If the inheritance properties for
the Everyone group is modified on the Parent directory so that the
permission apply only to this folder, Everyone will automatically be
removed from the Child directory.
An administrator can define additional permissions on a child object beyond
those that are automatically being inherited. Such permissions are called
Explicit and can be modified on the child object itself at any time.
If an administrator does not want a child object to inherit from its
parent, then the Allow inheritable permissions from parent to propagate to
this object should be cleared. When cleared, the child object is said to be
Protected. At the time the child object is protected, the ACL editor will
ask the administrator what should be done with the permissions that are
currently being inherited. These inherited permissions can be copied to the
child object or removed altogether. When an object is protected, it
contains only Explicit permissions. Note that the child objects with
Windows NT 4.0-style permissions that are not consistent with the
inheritable permissions defined on the parent are automatically protected
under the new ACL inheritance.
Security Configuration Manager allows administrators to override the normal
behavior of the ACL inheritance model by specifying that all child objects
of a given object should be reconfigured whether they are protected or not.
In fact, this is the only mode of operation that is supported in the
Windows NT 4.0 version of Security Configuration Manager and is specified
by selecting the Overwrite radio button when defining the security of a
File System or Registry object through Security Configuration Manager.
In Overwrite mode, all children of the specified object are set to inherit
from the object whose security is being defined. To specify different
security settings for child objects, those child objects must be explicitly
added to the security configuration file. These child objects may be
protected, in which case the object is not impacted by the security of its
parent, or the child objects may inherit, in which case additional explicit
permissions may be defined on the child object. Finally, for child objects
that the administrator does not wish to touch, those child objects should
be added to the security configuration file with the Ignore, rather than
Overwrite, attribute.
SCM is available for download and in the Mssce folder on your Windows NT
4.0 Service Pack 4 CD-ROM. For more information on downloading SCM, please
see the following article in the Microsoft Knowledge Base:
195227
SP4 Security Configuration Manager Available for Download
Known Issues with the New Permissions Editor
- The new Permissions Editor is not exposed when using Regedt32.exe;
however, it is used by Security Configuration Manager when configuring
security for registry keys.
- Permissions edited using the new editor are not viewable using the old
editor. This is because the old editor is limited in terms of its
capabilities to display and edit different kinds of valid permissions.
The old editor works only with permissions that are very simple or have
been edited using itself.
Uninstalling the New Permissions Editor
Uninstalling the new Permissions Editor is not recommended because it will
render Security Configuration Manager nonfunctional. If you must uninstall
it, perform the following steps:
- Go to the %windir%\System32.
- Rename Rshx32_5.dll to Rshx32_5.sav.
- Rename Rshx32.dll to Rshx32_5.dll.
Start Windows NT Explorer and look at the properties on an NTFS file or
folder. The old Permissions Editor should appear on the Security tab.
After reinstalling the old editor, you must examine the security on all
files and folders that you may have edited with the new editor. This will
display an error message stating that the permissions are not viewable and
will give you the opportunity to reset them and redefine new permissions.