The Permissions Manager for Registry keys

What is RegDACL good for?
RegDACL allows you to query and change the discretionary access control list (DACL) of any Windows NT Registry key. You can of course use the program RegEdt32 to set registry permissions, but if you need to edit more than a few machines then you are faced with quite a boring job, not to mention being more prone to make mistakes. RegDACL gives you the ability to use a batch script to perform this job. The freeware versions of RegDACL allow you to define access permissions for the predefined groups Administrators, Everyone, Interactive, Network, System, Creator Owner, User, Authenticated Users, Batch, Local, Service, Anonymous Logon, Domain Administrators, Domain Users and DomainGuests  and in much more detail than RegEdt32 will allow. The registered version of RegDACL will in addition allow you to change permissions for all kinds of local and domain accounts and groups.
There are quite some differences how the programs RegEdt32 for NT 4 and RegEdt32 for NT 5 (often referred to as Windows 2000) manage security settings for Registry keys. For this reason there used to coexist two versions of RegDACL, one for NT 4 and another for NT 5. But most administrators have to manage networks with mixed versions of NT. For this reason we added some more intelligence to the program. Now it first checks which version of NT runs on the target machine. With this knowledge it decides what options are allowed and what method might be the most successful when trying to read and change security settings.

What licence terms apply to the use of RegDACL?
This software was developed with the greatest attention to detail. However, the author can not guarantee that it runs under every version of Windows NT or on each computer flawlessly. Use of this program is at your own discretion. The copyright holder provides the program "as is" without warranty of any kind. RegDACL is a very powerful tool, and with one wrong command you can cause much havoc to your machines! So make sure you know what you do when using this tool! Reading and understanding this document should help you to avoid mistakes!

RegDACL version 5.x is Freeware. You are allowed to distribute this version of the software as long as you include all files as you received them with the zip file, did not change any of them, and do not charge for the distribution. You are not allowed to distribute the file on your web page or ftp server - but you may and should use a link to www.heysoft.de. This will insure you always receive the latest version of the software.

RegDACL version 6.x is available to registered users only as part of RegTools for Windows NT. Other tools in this product are RegOwner and RegAudit for managing ownership and audit settings of Registry keys. Both of these tools are not available as Freeware.

An order form for RegTools is included within the zip file of the freeware versions. Under no circumstances you are allowed to re-distribute registered versions of the software.

What is a DACL?
The Discretionary Access Control List (DACL) is controlled by the owner of an object and specifies the access particular users or groups can have to that object.With RegDACL you can manage DACLs of Registry keys.
An access-control entry (ACE) is an element in an access-control list (ACL). An ACL can have zero or more ACEs. Each ACE controls or monitors access to an object by a specified trustee and contains several fields, all of which you will see in detail by using the command /L.
Note: If you need to manage DACLs of files or directories on an NTFS volume, you can use CACLS, which comes with NT, or the NT resource kit utility XCACLS which provides some extended functionality.

What are the requirements to use the program successfully?

• Windows NT version 4.0 or above
• You must accept the Licence terms.
• In order to query the DACL of a Registry key, you need at least the permission called "Read Control" in Regedt32. RegDACL names this permission as S.
• In order to change the DACL of a Registry key, you need the additional permission "Write DAC". In RegDACL syntax these permissions are called SA.
• If you don't have these permissions, but you are the owner of a key, you can query and change its DACL as well.
• If you don't have permissions to and are not the owner of a key, but you are a member of the Administrators group, you can query and change its DACL as well. This is because members of the Administrators group are kind of god for the NT system ;-) With the registered version of RegTools nothing can stop a member of the administrators group from managing the security settings of any Registry key, at least we are not aware of such an obstacle. If you know one, please let us know!

This is the (quite long ;) help screen you will see when you type RegDACL /?:
 

The help screen of RegDACL

RegDACL 6.0 - DACL Manager for Registry keys for Windows NT 4 and above  Copyright (c) 1999-2001 Frank Heyne Software (http://www.heysoft.de)   Usage: RegDACL Key Commands     Key: [\\computer\]root[\subkey]      \\computer:  remote machine      root: HKLM, HKU, HKCU, HKCC or HKCR      subkey: path to the key you want to change or query     Query Commands:      /L            List DACL (show current permissions)      /E            List Effective current permissions      /Qxx:perms(I) Query perms for xx ("Does ACE with perms exist?")      /Axx:perms    Are perms allowed for xx? ("Does xx have perms effectively?")      /Fxx:Perms(I) Find all subkeys with Perms for xx      /PI           Find all protected subkeys (not available in NT 4)    Change Commands:      /Gxx:perms(I) Grant Access (add Perms to existing permissions) for xx      /Sxx:perms(I) Set Access (overwrite existing permissions with Perms) for xx      /Rxx          Revoke Access (delete all ACEs for xx)      /Dxx:perms(I) Deny Access to Perms for xx      /PC           Protect key and Copy formerly inherited permissions to it      /PR           Protect key and Remove all formerly inherited permissions      /P-           Remove Inheritance protection of this key      /Propagate    Propagate current DACL to all subkeys and remove explicitly                    defined permissions from all subkeys      /Clear        Clear noninherited ACEs (only allowed together with /S)    Important: all /P options are not available in NT 4!    Other Commands:      -Subtree      Apply to entire subtree (needless with /F, /PI, /Propagate)      -ANSI         Use ANSI character set instead of OEM character set      -?            This help screen    Options for xx:      GE = really "Everyone"      GA = predefined group "Administrators"      GU = predefined group "Users"      GT = predefined group "Authenticated Users"      GI = predefined group "Interactive"      GN = predefined group "Network"      GS = predefined group "System"      GO = predefined group "Creator Owner"      GV = predefined group "Service"      GL = predefined group "Local"      GB = predefined group "Batch"      GY = predefined group "Anonymous Logon"      GP = predefined group "System operators"      DA = group "Domain-Administrators"      DU = group "Domain-Users"      DG = group "Domain-Guests"      ALzzz =        Local account zzz of the machine      ADzzz =        Domain account zzz      AQsource\zzz = any Qualified account source\zzz    possible options for Perms:      Q - Query value             L - create Link      W - Write value             D - Delete      C - Create subkey           S - read Security info      E - Enumerate subkeys       A - write dAcl      N - Notify changes          O - write Owner      R - Read (same as QENS);    F - Full access (same as QWCENLDSAO)    possible options for I (Inheritance flags):     (NI)    - No Inheritance (ACE is valid only for the current key)     (CI)    - Container Inherit (ACE is valid for the current key and subkeys)     (CI-NP) - Container Inherit No Propagation (ACE is valid for the current key               and all children, but not for any grandchildren)     (IO)    - Inherit Only (ACE is not valid for the current key, but for               all subkeys)     (IO-NP) - Inherit Only No Propagation (ACE is not valid for the current key               but for all children, but not for any grandchildren)    The following inheritance flags are not available in NT 4:     (ID-NI) - InheriteD ACE which is valid only for this key, but no subkeys     (ID-CI) - InheriteD ACE which is valid for the current key and all subkeys     (ID-IO) - InheriteD ACE which is not valid for this key, but for subkeys

These many parameters might seem a little confusing at first glance, but I will describe every option to you in turn, so finally no questions will be left unanswered.
First you need to provide the following information to RegDACL:

1. The full path to the Registry key whose DACL you wish to modify.
2. Provide at least one command for the query to ask or the changes to make to the specified registry key. If no command is specified the program will do (surprise!) nothing.

Specifying a Registry key

[\\Computer\]Root[\Subkey]

Example:[\\PegasusNT1\]HKLM\System\CurrentControlSet\Enum

HKLM - HKEY_LOCAL_MACHINE
HKU  - HKEY_USERS
HKCU - HKEY_CURRENT_USER
HKCC - HKEY_CURRENT_CONFIG
HKCR - HKEY_CLASSES_ROOT

Switchs
The switch -ANSI
With the -ansi switch you tell the program to use the ANSI character set instead of the default OEM character set. As you probably know, OEM is the default character set of the command line window. ANSI is the usual character set for most GUI programs. The use of this option is recommended if you pipe the output of the utility into a file, which will be processed with a GUI program later.

The switch -SUBTREE (only available in the registered version of RegDACL)
With the -subtree switch you tell RegDACL to employ all command(s) to the specified key and its subtree, instead of just working with the key itself. There are some exceptions: When using the commands /F, /PI or /PROPAGATE, no switch -SUBTREE is allowed because these commands scan the subtree by default.. In addition, it would be a problem to interpret the return values of the commands /Q or /A in conjunction with -SUBTREE. For this reason these combinations are not allowed either.
 
Commands
You can group as many commands as you like at the same time, with the exception of /F, /PI and /PROPAGATE, which are not allowed together with other commands. Commands are processed in the following order:

1. If found, one of the commands /F, /PI or /PROPAGATE  is executed and the program will halt.
2. If found, the command /L is executed.
3. If found, the command /E is executed.
4. If found, one of the commands /Q or /A is executed and the program will halt.
5. If the program is not halted at this point, then any remaining commands are executed from left to right.

Column 1 - Inheritance flags
Windows NT allows some very specific inheritance settings, but strangely enough they cannot be applied using the built in registry editors that come with NT 4. RegDACL, however, allows you to take full advantage of these detailed settings as explained below.

(CI) (Container Inherit) - By default, when a new registry subkey is created with Regedit or Regedt32,  it inherits the permissions of its parent, (which is what the key located one level above in the tree structure is referred to as) .
(IO) (Inherit Only) This ACE is applied only on entries created under a parent subkey (children and grandchildren), but not for the parent key (= this key) itself. This is the only useful setting for the pseudo account Creator-Owner, as shown in tutorial 2.
(NI) (No Inherit) - You may create an ACE which won't be inherited at all - it will apply only to the specified key.
(NP) (No Progpagate) -Valid only together with either (CI) or (IO). The option NP has the effect that the ACE placed on a key is inherited only by its child keys, but will not propagate further to grandchild keys.
Thus:
(CI-NP) would mean that the ACE is valid for the key itself and any subkeys (children) created under it, but not for any possible grandchildren created under these subkeys .
(IO-NP) means that the ACE will apply only to the subkeys of the specified key, not to the key itself or any grandchild keys.
(ID) (InheriteD) - New in Windows 2000. Earlier versions of Windows NT did inherit permissions only when a child object was created. When you later changed the permissions of the parent (without specifying that the permissions of the entire subtree beneath it should be changed as well, thus overwriting all changes made to the DACLs of any subkeys), no permissions of child keys were changed. Because Windows 2000 marks inherited ACEs with a combination of (ID) and one of (CI), (IO) or (NI), it knows everytime whether an ACE was inherited or explicitly applied to this object. This way Windows 2000 can propagate changes of permissions of parent keys to all subkeys which inherited them, while leaving additional ACEs applied to its subkeys alone.
(ID-CI) (InheriteD - Container Inherit) - The inherited ACE is valid for this key and its subkeys. When the origin of this ACE will be changed, the inherited ACE changes as well. It originates from a (CI) entry.
(ID-IO) (InheriteD - Inherit Only) This inherited ACE is valid for entries under the current key (children and grandchildren), but not for the key itself. It originates from an (IO) entry.
(ID-NI) (InheriteD - No Inherit) - This inherited ACE is valid for the current key, but not for its subkeys. It originates from an entry containing the (NP) flag.

Part 2 of this document contains a tutorial demonstrating the effects of different inheritance flags.
Important: If no inheritance flag is specified, RegDACL uses a default value which depends on the selected action. Actions reading something now look for any ACEs. Actions writing something use (CI) as a default - just as it would be if you set your security manually using Regedt32.

Column 2 - Type of the entry
There are only two possibilities, allow and deny. ALLOW means that the entry contains permissions which are allowed for this account. DENY means that the permissions in this entry are denied to this account. As with inheritance information, RegEdt32 in versions prior to NT 5 did not accept DENY ACEs and insisted on deleting the complete DACL, when you clicked on Security | Permissions and the DACL contained at least one DENY entry.

Column 3 - Permissions
NT allows 10 basic permissions for registry keys and 2 composite, which may be combined at your convenience:

Q	Query value (like Read for a file)
W	Write value (Regedt32 "Set Value")
C	Create subkey (like creating a subdirectory in a file system)
E	Enumerate subkeys (like listing files and subdirectories with the DIR command)
N	Notify (needed for using the Win32-API function RegNotifyChangeKeyValue)
O	write Owner (changing the owner associated with the specified key)
L	create Link (normally only the operating system uses this permission)
D	Delete (Removing the specified key, its subkeys, and all associated values)
S	read Security information (Regedt32 "Read Control"- allows the permission holder to read the ACL for the key)
A	write DAC  (Allows the permission owner to change the DACL entries attached to the specified key)

Composite permissions grant two or more of the above listed rights, saving quite a lot of writing.
F - Full access (like QWCENLDSAO)
R - Read (like QENS)

Column 4 - Account
This column reports which group or account the entry is in effect for. This can be a predefined (account groups built into NT) group, or any custom created local or domain group, or individual user account.
Example 1 is from a standalone machine which is not a member of an NT domain. The last entry belongs to a deleted user account.

The command /E
With this command you can view the Effective permissions (those which are actively in effect) for a key. The table shows that only accounts which have at least one entry in the DACL are displayed. Lets have a look at the differences in the results produced by the commands /L and /E here in Example 2:
 

Example 2

C:\Reg> RegDACL hklm\software\test /L /E  Access Control List for Registry key  "hklm\software\test":   (CI)    ALLOW  Full access      BUILTIN\Administrators  (IO)    ALLOW  QWCEN-DS--       CREATOR OWNER  (CI)    ALLOW  -W----D---       BUILTIN\Users  (CI)    ALLOW  Read             Everyone  Effective permissions for Registry key "hklm\software\test":  Full access     BUILTIN\Administrators  QW-EN-DS--      BUILTIN\Users  Read            Everyone

The DACL for this key consists of 4 entries, but the list of effective permissions has only 3.

• An ACE exists for the group CREATOR OWNER, but this is only valid for new children of the key (IO) and not for the key itself. This means there is no effective ACE for the group CREATOR OWNER for this key. This is the why the group is not in the list of effective permissions.
• When comparing the rows for the group Users we find differences as well, which aren't contradictory at all, as you might think at first glance. Remember that the group Users is a member of the group Everyone. Because one group has the permissions Read (QENS), and the other the permissions WD, the effective sum for Users is QWENDS.

The command /Q
With this command you can Query a key - whether an entry with one or more permissions exists in its DACL or not. RegDACL will return the result of the query in two different ways. At first it prints the answer as a line of text, at second it answers with different return values. If all queried permissions exist then RegDACL will return 0. If at least one of the queried permissions is missing, then the return value will be 1. The following Examples 3 and 4 were used to query the Registry key from Example 2:
 

Example 3

C:\Reg> RegDACL hklm\software\test  /qgo:q(ci)  Testing ACEs of predefined group "Creator Owner"  for Registry key "hklm\software\test":  FALSE - permission "Q" does not exist

Did you expect a different answer? Then you should check the inheritance info. In example 3 there was the inheritance information (CI) specified, but such an ACE for CREATOR OWNER does not exist, so the answer is correct.
Example 4 gives the answer you might have expected in Example 3: Notice the difference- no inheritance information is specified, and because you want to read the DACL the inheritance information defaults to "All types".
 

Example 4

C:\Reg> RegDACL hklm\software\test  /qgo:q  Testing ACEs of predefined group "Creator Owner"  for Registry key "hklm\software\test":  TRUE - permission "Q" does exist

So what is this return value good for when you can read the answer on the screen?
The answer is that with this kind of functionality you can easily write your own batch script, which starts different actions depending on existing, (or non-existing) permissions of your choice on registry keys of your choice! A very simple example follows to illustrate this. The script test.cmd could be used as follows (note: with the "^" char you can span a command over multiple lines in batch scripts):

@echo off
RegDACL hklm\software /qge:c^
&& echo Everyone can install software on this machine :-(^
|| echo Not Everyone can install software here :-)

When you (like in the following Example 5) call test.cmd, either the command after && or the command after || will be executed. You could of course change out the echo command with something more useful, maybe a command which writes an entry into the eventlog or sends an email to you when an important key with too much permissions is found! Your imagination is the only limit!
 

Example 5

C:\Reg> test  Testing ACEs of really "Everyone"  for Registry key "hklm\software":  TRUE - permission "C" does exist   Everyone can install software on this machine :-(

Attention!
You alone are responsible for insuring that RegDACL is called with valid parameters when you want to start certain actions in dependence on the return value! For instance, when you specify a path to a nonexistant key, the program will always halt with an error! A good practice would be to call RegDACL first with one of the commands /L or /E. If this return value is 0, you can be sure that the path exists and that you can access it (You have the necessary permission and the network connection is up.) When you then in this case use the command /Q (or /A), you can be sure that the return value really will be an answer to your question instead of an error code. Using /Q or /A in conjunction with an invalid command or switch (like -SUBTREE) will also return an error code instead of the result of the query!

The command /A
Compared with command /Q the command /A works like command /E compared with /L. Instead of testing the ACEs (like /Q does) the effective permissions are tested with /A.
The output is the same as in the command /Q - a line of text and a return value, but the return value will be 0 only if all permissions are granted to the specified group (either directly or to another group it is belonging to, like Everyone) and 1 in all other cases. Example 6 applies to the key from example 2 as well.
 

Example 6

C:\Reg> RegDACL hklm\software\test  /ago:q  Testing effective permissions of predefined group "Creator Owner"  for Registry key "hklm\software\test":  TRUE - permission "Q" is granted

Did you expect a different answer, again? Why is the answer of example 3 FALSE and the answer of example 6 TRUE?
The solution is simple: The group CREATOR OWNER does not have an ACE with the effective permission Q for this key, but it is a member of the group Everyone, to which this permission is granted for this key.

The command /F
This command scans the ACEs of all keys in the specified subtree of the Registry. It returns a list of all keys which contain ACEs with the perms you specified. The command /F is available only in the registered version of RegDACL.
 

Example 7

C:\Reg> RegDACL hklm  /fge:d  Searching all Registry keys beneath hklm with the permissions D for really "Everyone":  hklm\Software\Microsoft\Windows\CurrentVersion\Syncmgr  hklm\Software\Microsoft\Windows\CurrentVersion\Syncmgr\AutoSync  hklm\Software\Microsoft\Windows\CurrentVersion\Syncmgr\Handlers  hklm\Software\Microsoft\Windows\CurrentVersion\Syncmgr\Idle

Example 7 lists some keys beneath HKLM which may be deleted by Everybody. By default, Windows 2000 is much better protected against malevolent or stupid users than Windows NT 4.0, but it is not perfect, otherwise this list would be empty.

The command /PI
As discussed earlier in this document, beginning with Windows NT 5 objects inherit their permissions from parents in a new way: Changes made to the DACL of a parent will always propagate to all objects in the subtree beneath the parent. This is very useful in most cases, but there are situations where it is not so good. But there is a solution for such cases: You can uncheck "Allow inheritable permissions from parent to propagate to this object" in the Security | Permissions dialog of RegEdt32. Doing so protects the object from inheriting any ACE from its parents.
The command /PI (available only in the registered version of RegDACL) lists all subkeys which are protected. It does not work in Windows NT 4.0 and earlier.

Example 8

C:\Reg> RegDACL hklm\software\Microsoft  /pi  Searching all protected Registry keys beneath hklm\software\Microsoft\Windows...  hklm\software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket  hklm\software\Microsoft\Windows\CurrentVersion\Group Policy  hklm\software\Microsoft\Windows\CurrentVersion\Installer  hklm\software\Microsoft\Windows\CurrentVersion\Installer\Products  hklm\software\Microsoft\Windows\CurrentVersion\Installer\Products\Secure

Example 8 lists some of the keys beneath HKLM\Software\Microsoft which do not automatically inherit changes made to their parents.

This concludes the description of the commands that allow you to query the DACLs of Registry keys. Now you will become acquainted with the commands which allow you to modify the DACLs of Registry keys. The functions which change ACEs do not accept inheritance options with the (ID) flag set, because this would make no sense! If you want to change such an ACE, do it in the key where it is defined, not in the dependent subkey!

Let us start with the commands /P... which control inheritance. They all work only in Windows NT 5 and above. It is possible, but very dangerous to use these commands together with the switch -SUBTREE. Do not so with keys installed by Windows 2000 itself, you might brake some functionality! While RegEdt32 warns you when making changes equivalent to the /P cammands, RegDACL does not. This is because RegDACL is most often used in scripts which are designed to run without user intervention.

The command /P-
This command removes the inheritance protection of a key. Current ACEs of the key (and its unprotected subkeys) will be replaced by the inheritable ACEs of its parents.
Using this command correspondents to checking "Allow inheritable permissions from parent to propagate to this object" in the Security | Permissions dialog of RegEdt32

The command /PC
This command Protects a key and Copies formerly inherited permissions to it. ACEs defined directly for this key will not change, and in addition all inherited ACEs will be added without the (ID) flag set.
Using this command correspondents to unchecking "Allow inheritable permissions from parent to propagate to this object" in the Security | Permissions dialog of RegEdt32 and answering the following question with "Copy".

The command /PR
This command Protects a key and Removes formerly inherited permissions. ACEs defined directly for this key will not change, but all inherited ACEs with the (ID) flag set will be removed. Make sure there are already some ACEs defined for the key directly before removing all inherited permissions, otherwise you will end up with no access to the key in RegEdt32! (There are emergency exits when you made such a mistake: Either take ownership and give yourself full access to the key or use RegDACL ;-)
Using this command correspondents to unchecking "Allow inheritable permissions from parent to propagate to this object" in the Security | Permissions dialog of RegEdt32 and answering the following question with "Remove".

The command /PROPAGATE
This command (available only in the registered version of RegDACL) PROPAGATES permissions. It matches the checkbox "Reset permissions on all child objects and enable propagation of inheritable permissions" in RegEdt32. The command removes explicitly defined permissions on all subkeys and enables propagation of inheritable permissions to those subkeys. Only inheritable permissions propagated from the specified key will take effect after applying this command. Be warned, even the DACLs of formerly protected subkeys will be overwritten by this powerful command! Do not use this command with keys installed by Windows 2000 itself, you might brake some functionality!

For demonstrating the next commands, let us start with the following permissions:

Example 9

C:\Reg> RegDACL hklm\software\test /l -subtree  Access Access Control List for Registry key "hklm\software\test":  (CI)    DENY   --C-N-----       BUILTIN\Users  (CI)    ALLOW  -W----D---       BUILTIN\Users  (CI)    ALLOW  Read             Everyone  (IO)    ALLOW  QWCEN-DS--       CREATOR OWNER  (CI)    ALLOW  Full access      BUILTIN\Administrators  Access Control List for Registry key "hklm\software\test\Subkey1":  (CI)    DENY   ----N-----       BUILTIN\Administrators  (ID-CI) DENY   --C-N-----       BUILTIN\Users  (ID-CI) ALLOW  -W----D---       BUILTIN\Users  (ID-CI) ALLOW  Read             Everyone  (ID-NI) ALLOW  QWCEN-DS--       TEST\Administrator  (ID-IO) ALLOW  QWCEN-DS--       CREATOR OWNER  (ID-CI) ALLOW  Full access      BUILTIN\Administrators

The command /G
This command grants explicitly the specified group the specified permissions. After the command was executed successfully, the group has at least the specified permissions. If it owned other permissions before, the new permissions will be the sum of the old rights and the newly granted rights. If there was a DENY entry for this group, the newly granted rights will be removed from this entry:
 

Example 10

C:\Reg> RegDACL hklm\software\test\subkey1 /gga:F /ggu:R  Access Granting F access for predefined group "Administrators"   - removing existing "ACCESS DENY" entry   - adding new entry  Granting R access for predefined group "Users"   - adding new entry  C:\Reg> RegDACL hklm\software\test\subkey1 /l  Access Control List for Registry key "hklm\software\test\Subkey1":  (CI)    ALLOW  Full access      BUILTIN\Administrators  (CI)    ALLOW  Read             BUILTIN\Users  (ID-CI) DENY   --C-N-----       BUILTIN\Users  (ID-CI) ALLOW  -W----D---       BUILTIN\Users  (ID-CI) ALLOW  Read             Everyone  (ID-NI) ALLOW  QWCEN-DS--       TEST\Administrator  (ID-IO) ALLOW  QWCEN-DS--       CREATOR OWNER  (ID-CI) ALLOW  Full access      BUILTIN\Administrators

In example 10 we grant the permission Read to registry values under hklm\software\test\Subkey1 to group Users as well as Full access to group Administrators. Subsequently we run the program again with the command /L to verify the changes. Comparing the results with example 9 shows the following:

• The DENY entry for Administrators was removed, because they were granted full access.
• The DENY entry for Users was not removed, because it is an inherited entry, which can only be changed on the parent where it is set.
• Inherited entries (even DENY entries) are always placed behind entries set explicitly for the current key. This overwrites inherited permissions with explicitely defined permissions.
• Inherited and explicitly defined entries will never merge. This makes sense, otherwise the command /PR would not work ;-)

The command /R
This command removes all explicit ACEs for the specified group from the DACL:
 

Example 12

C:\Reg> RegDACL hklm\software\test\subkey1 /rgu  Revoking access for predefined group "Users"  Inherited ACE can not be revoked directly!  C:\Reg> RegDACL hklm\software\test\subkey1 /l  Access Control List for Registry key "hklm\software\test\subkey1":  (CI)    ALLOW  Full access      BUILTIN\Administrators  (ID-CI) DENY   --C-N-----       BUILTIN\Users  (ID-CI) ALLOW  -W----D---       BUILTIN\Users  (ID-CI) ALLOW  Read             Everyone  (ID-NI) ALLOW  QWCEN-DS--       TEST\Administrator  (ID-IO) ALLOW  QWCEN-DS--       CREATOR OWNER  (ID-CI) ALLOW  Full access      BUILTIN\Administrators

Example 12 starts with the result from example 11. Subsequently we run the program again with the command /L to verify the changes. As expected, the explicit ACE for group Users is removed, but not the inherited ACEs. RegDACL warned us accordingly. So be ware that this command did not at all remove all permissions for group Users from the key, because the inherited permissions still apply! To really revoke permissions in Windows 2000, you need to use the next command:

The command /D
This command causes roughly the contrary of the command /G. It adds an ACESS-DENY entry on top of the DACL. If there are ACCESS-ALLOW entries with the specified permissions for this group, they will be changed or removed:
 

Example 13

C:\Reg> RegDACL hklm\software\test\subkey1 /dgu:EWS  Denying EWS access for predefined group "Users"   - adding new "ACCESS DENY" entry  C:\Reg> RegDACL hklm\software\test\subkey1  /l  Access Control List for Registry key "hklm\software\test\subkey1":  (CI)    DENY   -W-E---S--       BUILTIN\Users  (CI)    ALLOW  Full access      BUILTIN\Administrators  (ID-CI) DENY   --C-N-----       BUILTIN\Users  (ID-CI) ALLOW  -W----D---       BUILTIN\Users  (ID-CI) ALLOW  Read             Everyone  (ID-NI) ALLOW  QWCEN-DS--       TEST\Administrator  (ID-IO) ALLOW  QWCEN-DS--       CREATOR OWNER  (ID-CI) ALLOW  Full access      BUILTIN\Administrators

Example 13 starts with the result from example 12. Subsequently we run the program again with the command /L to check the changes. The permissions EWS for group Users will be denied. This example shows nicely how the ACEs are sorted in Windows 2000:

1. Explicit DENY entries
2. Explicit ALLOW entries
3. Inherited DENY entries
4. Inherited ALLOW entries

Attention!
There are really efficient examples for the use of the command /D, and there is no known version of NT, which has problems with DACLs with DENY ACEs. For
unknown reasons though, Regedt32 of NT 4 can't handle such DACLs. In such a case, it deletes the complete DACL when you choose Security | Permissions and answer the question that follows with "yes"!

The command /CLEAR  (only available in the registered version of RegDACL)
With the /clear command you tell RegDACL to delete all noninherited ACEs of the DACL, prior to setting new ACE(s). To prevent the creation of empty DACLs (generating one for a Registry key is not a good idea at all), this command is only allowed in conjunction with the command /S. It is also possible to combine it with the switch -SUBTREE. If you don't want to replace existing ACEs, but only want to remove all explicitly defined permissions, you shold use the command /P- instead of /CLEAR!
Alternatively it is possible to remove superfluous ACEs with the command /R, but with this command you need to name all accounts you want to remove one by another.

Is everything clear now?
When you have read this document carefully and you still have a question or are vague regarding a topic, you can email to fh@heysoft.de. But please check first the Security FAQ for the Windows NT Registry - your question might be already answered there. If you find errors or would like to contribute knowledge to this document, you are encouraged to email us, too.
When your mother tongue is not English or German, you can translate this documentation into your native language and get a registered version of RegTools for free (but you need to ask first, before you start, in case somebody else is working on the same project!)