The Audit Manager for Registry keys

What is RegAudit good for?
RegAudit allows you to query and change the security access control list (SACL) of any Windows NT Registry key. The name of this ACL is a little bit misleading, because it handles only the audit settings of an object. You can of course use the program RegEdt32 to view and change auditing entries of Registry keys, 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. RegAudit gives you the ability to use a batch script to perform this job.
There are quite some differences how the programs RegEdt32 for NT 4 and RegEdt32 for NT 5 (often referred to as Windows 2000) set and read the SACL of a Registry key. These differences are explained in the Security FAQ for the Windows NT Registry. Because most administrators have to manage networks with mixed versions of NT, RegAudit first checks which version of NT runs on the target machine and then decides what options are allowed, what bugs it needs to emulate, and what method might be the most successful when trying to read and change auditing entries.

What licence terms apply to the use of RegAudit?
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. RegAudit is a very powerful tool, so make sure you know what you do when using this tool! Reading and understanding this document should help you to avoid mistakes!
RegAudit is available only as part of RegTools for Windows NT. You are not allowed to use or distribute it outside the company or organization where it is licensed for!

What is a SACL?
The Security Access Control List (SACL) specifies the auditing entries for particular users or groups to that object.With RegAudit you can manage SACLs 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.
 

What are the requirements to use the program successfully?

• Windows NT version 4.0 or above
• You must accept the Licence terms.
• Auditing access to Registry keys does only work when the audit policy for object access is enabled for Success and Failure on your machines.
• In order to query or change the SACL of a Registry key, you need the priviledge Manage auditing and security log. By default, this priviledge is only assigned to Administrators.

1. The full path to the Registry key whose SACL 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
With the -subtree switch you tell RegAudit 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 command /Q in conjunction with -SUBTREE. For this reason this combination is 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 /Q is executed and the program will halt.
4. If the program is not halted at this point, then any remaining commands are executed from left to right.

Column 1 - Audit flags
Windows NT allows to distinguish between successful completed actions and those which returned a failure:
[S] means that the ACE does only generate audit events when the action matching its settings completed Successfully.
[F] means that the ACE does only generate audit events when the action matching its settings returned a Failure.
[A] means that the ACE does Always generate audit events.
Important: If no audit flag is specified, RegAudit uses [A] as default flag.

Column 2 - 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. RegAudit, 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 settings 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 settings of the parent (without specifying that the settings of the entire subtree beneath it should be changed as well, thus overwriting all changes made to the SACLs of any subkeys), no audit settings 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 auditing entries 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.

Important: If no inheritance flag is specified, RegAudit uses a default value which depends on the selected action. Actions reading something look for ACEs with any inheritance flags. Actions writing something use (CI) as a default - just as it would be if you set your security manually using Regedt32.

Column 3 - Actions
NT allows to audit 10 basic actions for Registry keys, 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)

F (Full access like QWCENLDSAO) audits all of the above listed actions, saving quite a lot of writing:
Important: In Windows NT 4 there is no possibility to audit O access with RegEdt32. In deed, setting this option would cause RegEdt32 to display nonsense in some cases. For this reason RegAudit does not allow to set O access on target machines with NT 4. On NT 4 F resolves to QWCENLDSA.

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.

The command /Q
With this command you can Query a key - whether an entry with one or more auditing entries exists in its SACL or not. RegAudit 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 auditing entries exist then RegAudit will return 0. If at least one of the queried auditing entries is missing, then the return value will be 1.

Attention!
You alone are responsible for insuring that RegAudit 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 RegAudit first with the command /L. If this returns a value of 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, you can be sure that the return value really will be an answer to your question instead of an error code. Using /Q 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 /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 auditing entries you specified.

The command /PI
As discussed earlier in this document, beginning with Windows NT 5 objects inherit their auditing entries from parents in a new way: Changes made to the SACL 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 | Audit dialog of RegEdt32. Doing so protects the object from inheriting any ACE from its parents.
The command /PI lists all subkeys which are protected. It does not work in Windows NT 4.0 and earlier.

This concludes the description of the commands that allow you to query the SACLs of Registry keys. Now you will become acquainted with the commands which allow you to modify the SACLs 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.

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 auditing entries from parent to propagate to this object" in the Security | Permissions | Advanced | Auditing 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 auditing entries from parent to propagate to this object" in the Security | Permissions | Advanced | Auditing 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.
Using this command correspondents to unchecking "Allow inheritable auditing entries from parent to propagate to this object" in the Security | Permissions | Advanced | Auditing dialog of RegEdt32 and answering the following question with "Remove".

The command /PROPAGATE
This command PROPAGATES auditing entries. It matches the checkbox "Reset auditing entries on all child objects and enable propagation of inheritable auditing entries" in RegEdt32. The command removes explicitly defined auditing entries on all subkeys and enables propagation of inheritable auditing entries to those subkeys. Only inheritable auditing entries propagated from the specified key will take effect after applying this command. Be warned, even the SACLs of formerly protected subkeys will be overwritten by this powerful command!

The command /A
This command adds the specified auditing entry for the specified account. After the command was executed successfully, the account has at least the specified auditing entry. If there was another auditing entry with the same audit and inheritance flags before, the new auditing entry will contain the sum of the old and the newly added actions.

The command /S
This command re-sets the specified auditing entry for the specified account. After the command was executed successfully, the account has exactly the specified auditing entry.  If there were other noninherited auditing entries for the account before, these entries will be removed.
 
The command /D
This command deletes all explicit ACEs for the specified account from the SACL, but not the inherited ACEs.

The command /CLEAR
With the /clear command you tell RegAudit to delete all noninherited ACEs of the SACL. Alternatively it is possible to remove superfluous ACEs with the command /D, 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.