Ask the Directory Services Team

Bulk exporting and importing WMI filters for Group Policy

Mike again. Here is an updated version of the blog post which was originally published on the Group Policy blog. Check it out!

Did you know you can import/export WMI filters using GPMC? However, your export is limited to one filter at a time – filter to a single .mof file. You then take the exported .mof file to a different domain and use GPMC to import each file. This is great when you only have one or two WMI filters. What about if you have 15 or 20? No worries! You can do this using the LDIFDE utility. (This is a long but detailed explanation).

First, you need to find the WMI Filter you want to export (and eventually import). GPMC writes WMI filters in the Domain partition at:

CN=SOM,CN=WMIPolicy,CN=System,DC=contoso,DC=com.

The LDAP filter you use to return all WMI filters is (objectclass=msWMI-Som). You can narrow the number of returned items if you know the name of the WMI Filter by using
(&(objectclass=msWMI-Som)(msWMI-Name=filtername)). You can lean more about LDAP search filter syntax from MSDN (http://msdn2.microsoft.com/en-us/library/aa746475.aspx). The following sample command line gives you and idea of how to export the WMI Filter:

LDIFDE -f output.txt –d “dc=contoso.com” –r ”( objectclass=msWMI-Som)” –p subtree

In the example above, -f designates the name of the output file that stores the exported WIM filter objects. Next, -d designates the based distinguished name; that is, where the search for objects starts. In this example, it starts at the beginning of the domain. The –r is an inclusive LDAP search filter. In this example we only want objects of the class
msWMI-Som returned by the query. Lastly, the –p designates that type of search we want to use. A subtree search means the search begins at the designated base distinguished name and searches the entire depth of the tree for objects matching the designated filter—similar to using dir /s on a directory when searching for a file.

Your options may vary. If you have problems exporting the items then add –j . (one dash, the letter J, a space, and one period) to the command line to create a log file in the current folder. A successful output.txt file looks similar to the following:

dn: CN={1154EFFC-0090-4F23-8865-C8D555BF696E},CN=SOM,CN=WMIPolicy,CN=System,DC=contoso,DC=com
changetype: add
objectClass: top
objectClass: msWMI-Som
cn: {1154EFFC-0090-4F23-8865-C8D555BF696E}
distinguishedName:
CN={1154EFFC-0090-4F23-8865-C8D555BF696E},CN=SOM,CN=WMIPolicy,CN=System,DC=con
toso,DC=com
instanceType: 4
whenCreated: 20070808151246.0Z
whenChanged: 20070808151246.0Z
uSNCreated: 40979
uSNChanged: 40979
showInAdvancedViewOnly: TRUE
name: {1154EFFC-0090-4F23-8865-C8D555BF696E}
objectGUID:: EPDEbOIaGEWyX3Z/b+eiKw==
objectCategory: CN=ms-WMI-Som,CN=Schema,CN=Configuration,DC=contoso,DC=com
msWMI-Author: Administrator@CONTOSO.COM
msWMI-ChangeDate: 20070618142622.740000-000
msWMI-CreationDate: 20070618142257.735000-000
msWMI-ID: {1154EFFC-0090-4F23-8865-C8D555BF696E}
msWMI-Name: Imported WMIFilter2
msWMI-Parm1: This is the description for the filter
msWMI-Parm2:
1;3;10;45;WQL;root\CIMv2;Select * from win32_timezone where bias =-300;

Once you successfully export the WMI Filters; you then need to prepare the output file for import.

To prepare the output file for importing:

1. First, save the file as another file name.

2. Then, you need to download the GUIDGEN utility (this is not so important when importing the WMI filter into a different domain). As a reference, this is a guid: {DF380E6C-DB23-44ed-9BF6-435559503347}.

• You MUST change the guids to import into the same domain or it will NOT import.

3. Change the guid (to include open and closing curly braces) in the DN, CN, distinguishedname, name, and msWMI-ID attributes (use the same guid in each of these attributes).

4. If importing into a different domain, change the LDAP path to reflect the new domain in the dn, distinguishedName, and objectCategory attributes. Only change the domain portion of the LDAP path.

5. Next, you need to remark out the whenCreated, whenChanged, USNcreated, USNChanged, objectguid, msWMI-ChangeDate,  and msWMI-CreationDate attributes. Do this by inserting the # character and a space at the beginning of the line for each of the listed attributes.

6. Optionally, you can change the text displayed in msWMI-Name, msWMI-Author, and msWMI-Parm1 attributes.

• msWMI-Name is the display name of the WMI Filter shown in GPMC. 
• msWMI-Author is the UPN format for the person creating the WMI filter.
• msWMI-Parm1 is the description text shown for the WMI filter in GPMC.

The final file should look similar to the following.

dn: CN={4464D2C2-9063-4953-AE6F-A0D231EBF3CD},CN=SOM,CN=WMIPolicy,CN=System,DC=fabrikam,DC=com
changetype: add
objectClass: top
objectClass: msWMI-Som
cn: {4464D2C2-9063-4953-AE6F-A0D231EBF3CD}
distinguishedName:
CN={4464D2C2-9063-4953-AE6F-A0D231EBF3CD},CN=SOM,CN=WMIPolicy,CN=System,DC=fabrikam,DC=com
instanceType: 4
# whenCreated: 20070618142257.0Z
# whenChanged: 20070618142622.0Z
# uSNCreated: 26483
# uSNChanged: 26485
showInAdvancedViewOnly: TRUE
name: {4464D2C2-9063-4953-AE6F-A0D231EBF3CD}
# objectGUID:: 7sA6lK0PVE2fGNOSDTS5Kw==
objectCategory: CN=ms-WMI-Som,CN=Schema,CN=Configuration,DC=fabrikam,DC=com
msWMI-Author: Administrator@fabrikam.COM
# msWMI-ChangeDate: 20070618142622.740000-000
# msWMI-CreationDate: 20070618142257.735000-000
msWMI-ID: {4464D2C2-9063-4953-AE6F-A0D231EBF3CD}
msWMI-Name: Imported WMIFilter2
msWMI-Parm1: This is the description for the filter
msWMI-Parm2:
1;3;10;45;WQL;root\CIMv2;Select * from win32_timezone where bias =-300;

You’re almost ready to import the WMI filters. However, importing or adding a WMI Filter object into AD is a system only operation. You need to enable system only changes on a domain controller for a successful LDIFDE import. To do this, on the domain controller you are using for importing, open the registry editor and create the following registry value.

Key: HKLM\System\CurrentControlSet\Services\NTDS\Parameters
Value Name: Allow System Only Change
Value Type: REG_DWORD
Value Data: 1 (Binary)

Next, you’ll need to reboot the domain controller to activate the new setting. Once the domain controller is rebooted, you can use LDIFDE to import the file into AD. Use the following command:

LDIFDE  -i –f input.txt

If you have problems then add –j . (one dash, the letter J, a space, and one period) to the command line to create a log file in the local folder. Once the import is complete you should delete the System Only Registry key and reboot the domain controller to deactivate the setting. A successful import looks similar to the following.

Connecting to "hq-con-dc-01.fabrikam.com"
Logging in as current user using SSPI
Importing directory from file "import-wmi.ldf"

Loading entries
1: CN={4464D2C2-9063-4953-AE6F-A0D231EBF3CD},CN=SOM,CN=WMIPolicy,CN=System,DC=fabrikam,DC=com
Entry DN: CN={4464D2C2-9063-4953-AE6F-A0D231EBF3CD},CN=SOM,CN=WMIPolicy,CN=System,DC=fabrikam,DC=com
changetype: add
Attribute 0) objectClass:top msWMI-Som
Attribute 1) cn:{4464D2C2-9063-4953-AE6F-A0D231EBF3CD}
Attribute 2) distinguishedName:CN={4464D2C2-9063-4953-AE6F-A0D231EBF3CD},CN=SOM,CN=WMIPolicy,CN=System,DC=fabrikam,DC=com
Attribute 3) instanceType:4
Attribute 4) showInAdvancedViewOnly:TRUE
Attribute 5) name:{4464D2C2-9063-4953-AE6F-A0D231EBF3CD}
Attribute 6) objectCategory:CN=ms-WMI-Som,CN=Schema,CN=Configuration,DC=fabrikam,DC=com
Attribute 7) msWMI-Author:Administrator@FABRIKAM.COM
Attribute 8) msWMI-ID:{4464D2C2-9063-4953-AE6F-A0D231EBF3CD}
Attribute 9) msWMI-Name:Imported WMIFilter2
Attribute 10) msWMI-Parm1:This is the description for the filter
Attribute 11) msWMI-Parm2:1;3;10;45;WQL;root\CIMv2;Select * from win32_timezone where bias =-300;

Entry modified successfully.

1 entry modified successfully.

The command has completed successfully

And there you go: you’ve successfully exported and imported WMI filters.

-Mike Stephens

Troubleshooting Kerberos Authentication problems – Name resolution issues

Hi Rob here. I thought I would show you how we in Microsoft Commercial Technical Support typically troubleshoot Kerberos authentication issues. This discussion should do much to get you more comfortable viewing network traces for Kerberos authentication problems. There are other ways to troubleshoot Kerberos; one could use the Kerberos event logging outlined in KB 262177. Although you could rely on this method, it will take longer to resolve the issue and involves making some educated guesses without the network trace.

I am going to layout my lab configuration in case you want to reproduce the problem and look at the network traces on your own.

Forest layout:

The root domain litwareinc.com has one domain controller in the domain, and one member server.

Domain Controller network configuration:   Host Name:  LTWRE-RT-DC1 IP Address: 10.10.100.20 DNS:  10.10.100.20 WINS: 10.10.100.60

Member Server network configuration: Host Name:  LTWRE-RT-MEM1 IP Address: 10.10.100.21 DNS:  10.10.100.20 WINS: 10.10.100.60

The child domain litware-chld.litwareinc.com has one domain controller in the domain, and one member server.

Domain Controller network configuration:   Host Name:  LTWRE-CHD-DC1 IP Address: 10.10.200.20 DNS:  10.10.200.20 WINS: 10.10.100.60

Member Server network configuration:   Host Name:  LTWRE-CHD-MEM1 IP Address: 10.10.200.21 DNS:  10.10.100.20 WINS: 10.10.100.60

NOTE: I’m stating the obvious here, I know, but this configuration is for testing only. Having only one DC per domain usually means you’ll be rebuilding the forest at some point.

Network based troubleshooting (network captures) is the fastest way to determine the problem, and by learning a few short filters you can effectively troubleshoot most Kerberos-related problems.

You can use any network capture utility that you feel comfortable with. I prefer Netmon, nmcap (part of Netmon 3.x) or netcap (XP and 2003 support tools) to collect the network trace, and I use Wireshark to view the network capture. This is in no way an endorsement of Wireshark – feel free to use Ethereal, Packetyzer, etc.

Problem scenario:

There is a service running on LTWRE-RT-MEM1 server that runs starts /runs as “LocalSystem” account. This service connects to a file share on LTWRE-CHD-MEM1 named “AppShare” to access some files. The Service is failing to retrieve the files and is giving you an error of “Access is denied”. When you attempt to access the share as a domain user account on LTWRE-RT-MEM1 you are able to access the share.

Auditing for Logon/Logoff was enabled on LTWRE-CHD-MEM1, so you start by examining the security event log.

When the LITWAREINC\Administrator attempts to access the share we get the following Audit Event:

Notice how the user that authenticated to the server is the “LITWAREINC\Administrator” account. It used NTLM authentication and the source machine name is LTWRE-RT-MEM1.

When the Service attempts to access the share we get the following Audit Event:

Notice that when the service attempts to authenticate to the server it is doing it anonymously.

Hey, why is the computer authenticating to the other machine using NTLM authentication?
I thought we were in the 21^st century with Kerberos authentication?

As it turns out, starting with Windows XP and Windows Server 2003 a computer cannot not use NTLM authentication when accessing a remote resource. If it does, it will use Anonymous Logon credentials and typically fail.

That means we have to figure out why Kerberos authentication is failing on LTWRE-RT-MEM1 when accessing a share on LTWRE-CHD-MEM1.

Typically when you troubleshoot using network captures, you want to install the network capture utility on both ends of the communications to make sure that there are no network devices (firewalls, routers, switches, VPN appliances, etc.) that are manipulating the packet in between the two systems. We call this taking a double-sided trace.

When working with a customer, we will typically request a double-sided network capture be taken. In this scenario I would start with installing the network capture utility on the source and destination server to see what is going on.

So the next question I guess becomes what are the steps to taking a good network capture?

Well, we want to see all name resolution, and we will also want to ensure that we see the Kerberos tickets (Authentication) in the capture. We also want to make sure that we can reproduce this problem at will to see this problem for ourselves.

So, how can we reproduce the problem?

1. Get a command prompt as the “SYSTEM” and attempt to access the remote system.

On Windows 2000, Windows XP, and Windows Server 2003 we can use the AT command to get a command prompt as the “SYSTEM” account by type the following command:   AT <Military Time in Future> /Interactive “cmd.exe”   i.e.  if the time is currently 7:04 PM you would type in: AT 19:06 /Interactive “cmd.exe”   Then at 7:06 PM you should see a command prompt pop up   NOTE:  You have to do this while logged into the console session.  If you are RDP’ed in you need to start the RDP session with the /console switch otherwise you will never see the command window start.

2. Start the network capture utility.

3. Clear all name resolution cache as well as all cached Kerberos tickets.

• To clear DNS name cache you type in: IPConfig /FlushDNS
• To clear NetBIOS name cache you type in: NBTStat –R
• To clear Kerberos tickets will need KList.exe: KList purge

The above commands need to be done in the command prompt that came up for “SYSTEM”

4. Now you need to run a command that will require authentication to the target server. Either of the following will do:

• Net View \\LTWRE-CHD-MEM1
• Dir \\ltwre-chd-mem1\AppShare

5. Once you get the error message, stop and save the network captures.

Reviewing the network capture:

If you are using Wireshark to view the trace, the Filter is simple: “dns || Kerberos || ip.addr==<IP Address of Target machine>”. Basically, this filter means “Show me all packets sent to or from the target machine, all DNS name queries and responses, and all Kerberos authentication.”

It should look similar to this:

Once you have the network capture, you should see all DNS, Kerberos Authentication (As well as Packets that have Kerberos tickets in them), and anything destined for the remote system.

Before we go over the capture too much, we should probably cover at a high level the steps taken to connect to a remote file share.

1. Resolve the host name for the target system to an IP address.

a. Look in the HOSTS file.
b. Query DNS.
c. Look in the LMHOSTS file.
d. Query WINS / NBNS.

2. Ping the remote system.
3. Negotiate an Authentication protocol. Kerberos is preferred for Windows hosts.
4. Request a Kerberos Ticket.
5. Perform an SMB “Session Setup and AndX request” request and send authentication data (Kerberos ticket or NTLM response).

Let’s look at those steps in more detail.

Step 1 - resolve the name:

Remember, we did “IPConfig /FlushDNS” so that we can see name resolution on the wire. Frame 1 is the query out. Hmm, this looks kind of funny: querying for LTWRE-CHD-MEM1.litwareinc.com. Well, that part should be fine, I suppose, since the DNS server should not find the record. But wait Frame 6 shows that the DNS Server responded to the query with 10.10.200.21, and sure enough that is the correct IP Address for the target server.

Step 2 - ping the remote system:

Yep, the remote system is ping able. See the Echo request and reply. So the system is up and available.

Step 3 - Negotiate Authentication:

So now we negotiate the authentication protocol and the remote system responded; the response is the more important part of the packet. We see that it supports MS KRB5, KRB5, and NTLMSSP; it even gave us the principal name of the system.

Step 4 - Request a Kerberos ticket:

Alright, now to the meat of Kerberos authentication and viewing it in a network trace. If you remember, we used KList Purge command to clear out all tickets on the system. That means that the server has to get a Ticket Granting Ticket (TGT) first, and this is why you are seeing the AS-REQ and AS-REP frames. If Kerberos ticketing is new to you, I would suggest reviewing the blog on how Kerberos works.

Next, we see the TGS-REQ in Frame 18; let’s take a closer look at this packet in the details pane.

You can see that the system is handing its TGT to the Kerberos Key Distribution Center (KDC) under “padata: PA-TGS-REQ” section, and requesting a ticket for server “cifs/LTWRE-CHD-MEM1.litwareinc.com” in the LITWAREINC.COM realm (Windows Domain) under “KDC_REQ_BODY” section.

OK, since we now know that we are requesting a Kerberos ticket for “cifs/LTWRE-CHD-MEM1.litwareinc.com” in the litwareinc.com domain. This will not work since the remote system actually lives in the “litwareinc-chld.litwareinc.com” domain. So you see why the KDC responded back with KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN. Again, if you do not understand this please review the blog on how Kerberos works.

Step 5 - Perform a SMB “Session Setup AndX request”:

So we see in the following Frames:

• Frame 20 shows that, since Kerberos failed due to an unknown service principal name, the NTLMSSP_NEGOTIATE authentication package is selected. Frame 21 shows that the remote system sending the NTLMSSP_CHALLENGE (this is typical) back.
  
• Frame 22 shows that the system sent no NTLM credentials to the remote system. It is authenticating as NT AUTHORITY\Anonymous.
  
• Frame 23 shows that the remote system allowed the session to be created.
  
• Frame 24 & 25 shows that we do a Tree connect to the IPC$ share and get a response.
  
• Frame 26 & 27 shows that we connect the SRVSVC named pipe and get STATUS_ACCESS_DENIED back.

So where do you think things start to go wrong here in the trace?

If you answered DNS name resolution you would be correct. If name resolution is not working properly in the environment it will cause the application requesting a Kerberos ticket to actually request a Service ticket for the wrong service principal name. So if you remember the remote file server I am attempting to connect to “ltwre-chd-mem1.chd.litwareinc.com”, however the DNS Server found a record for “ltwre-chd-mem1.litware.com”. Since we found the remote file server in the “litwareinc.com” domain the Kerberos client requests a service ticket for “cifs/ltwre-chd-mem1.litwareinc.com” as noted in the Kerberos ticket request, and the KDC responds with KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN.

I did another net view specifying the FQDN of LTWRE-CHD-MEM1 and WOW, look at the output:

That actually worked! So, how can we fix this problem?

Actually, there are several different ways to “fix” the problem:

a. Find out why DNS is resolving the machine name incorrectly.

i. Is there a HOST or CNAME record for this name?
ii. Did you configure the DNS Zone for WINS lookup?

b. Configure your application to use the FQDN of the system instead of NetBIOS name.

c. We could add an Service Principal Name to LTWRE-CHD-MEM1 for “CIFS/LTWRE-CHD-MEM1.litwareinc.com”

The best way to “Fix” the problem is to actually fix DNS name resolution. By the way, the lab was configured with “WINS Lookup” enabled on the litwareinc.com DNS Zone. If you are failing to use Kerberos authentication using the LocalSystem account, you are more than likely failing to use Kerberos authentication when users are going to the remote system. However, they are not getting “Access is denied” because user accounts, unlike machine accounts, can fail over to NTLM and authenticate with credentials rather than as Anonymous.

If you find that fixing the DNS problem is not possible, then the next best solution would be to make the application use the FQDN of the server. Keep in mind that the application vendor would need to be involved to use this fix.

The least favorite method to resolve the issue would be to add the SPN to the destination server using the SetSPN.exe tool. This is the least favorite because you are adding another name to the machine account in another domain. What would happen if in the future you bring up a new computer in the root domain with the same name? Now you have a duplicate SPN and this will lead to other Kerberos authentication problems.

Well, I hope that you have learned a few new things like:

• How name resolution problems could cause Kerberos authentication to fail.
  
• How to easily filter network traces to confidently determine where Kerberos authentication is failing.
  
• How the SMB protocol and authentication look in a network trace.

Please keep in mind that there are several other ways that name resolution could cause Kerberos authentication to fail. You could have static WINS entries in the database, or you could have wrong entries in HOSTS / LMHOSTS files. You could be failing because of a CNAME / “A” (HOST) record within your DNS zone, or simply because of the DNS Zone is configured for “WINS Lookup”.

Robert Greene

The Security Descriptor Definition Language of Love (Part 2)

Hi. Jim here from DS here with a follow up to my SDDL blog part I. At the end of my last post I promised to dissect further the SDDL output returned by running the CACLS with the /S switch on tools share as follows:

Here is the output exported to a .txt file:

"D:AI(D;OICI;FA;;;BG)(A;;FA;;;BA)(A;OICIID;FA;;;BA)(A;OICIID;FA;;;SY)(A;OICIIOID;GA;;;CO)(A;OICIID;0x1200a9;;;BU)(A;CIID;LC;;;BU)(A;CIID;DC;;;BU)"

Let’s examine the first segment more closely: "D:AI(D;OICI;FA;;;BG)(A;;FA;;;BA)

Now the second ACE segment: (A;:FA;;;BA)

You get the picture. There is a chart provided at the end which contains all the acronyms in addition to the ones illustrated in this output.

At this point you may be asking why there are there two different ACE entries for Built-in Administrators. The first ACE indicates the ACE applied directly to the object (In this case TOOLS for the BA’s). The second ACE indicates the ACE’s for this object that flow down from TOOLS via inheritance.

This is illustrated in the Permissions tab of Advanced Security Settings for the TOOLS share:

Now you may well be wondering “Jim, how can I use this SDDL wonderment to make my administrative tasks less tedious?"

Well here is an example on how you can do just that.

Scenario: Its Friday at 3pm. You have to deploy 10 printers to the call center. Every single printer should have the exact same security settings for access (oversimplified yes, but you get the point). You need to get this done expediently so as not to miss happy hour. All the printers are IP’d and are installed on your print server. You have applied the necessary security on one printer as follows:

Using the SETPRINTER utility you can view the security applied in SDDL format as follows:

Here is the command as well as the output:

C:\>setprinter -show \\2003dom-member\printer1 3

pSecurityDescriptor="O:BAG:DUD:(A;;LCSWSDRCWDWO;;;BA)(A;OIIO;RPWPSDRCWDWO;;;BA)(A;;SWRC;;;S-1-5-21-329599412-2737779004-1408050790-2604)(A;CIIO;RC;;;CO)(A;OIIO;RPWPSDRCWDWO;;;CO)(A;CIIO;RC;;;S-1-5-21-329599412-2737779004-1408050790-2605)(A;OIIO;RPWPSDRCWDWO;;;S-1-5-21-329599412-2737779004-1408050790-2605)(A;;SWRC;;;S-1-5-21-329599412-2737779004-1408050790-2605)(A;;LCSWSDRCWDWO;;;PU)(A;OIIO;RPWPSDRCWDWO;;;PU)"

Now create yourself a .CMD file containing the following parameters remembering of course to substitute your Print server name and your printer names where indicated. Also be sure NOT to wrap your SDDL parameters as below. This is done here purely for readability. The entire command should be on one line:

You may add as many similarly configured printers as you like.

Included below are charts for the acronyms of the SDDL taken directly from MSDN2. These can also be viewed here:

http://msdn2.microsoft.com/en-us/library/aa374928.aspx

ACE Type

The ACE type designates whether the trustee is allowed, denied or audited.

Value	Description
"A"	ACCESS ALLOWED
"D"	ACCESS DENIED
"OA"	OBJECT ACCESS ALLOWED: ONLY APPLIES TO A SUBSET OF THE OBJECT(S).
"OD"	OBJECT ACCESS DENIED: ONLY APPLIES TO A SUBSET OF THE OBJECT(S).
"AU"	SYSTEM AUDIT
"A"	SYSTEM ALARM
"OU"	OBJECT SYSTEM AUDIT
"OL"	OBJECT SYSTEM ALARM

INHERITANCE Flags

"P	SDDL_PROTECTED	Inheritance from containers that are higher in the folder hierarchy are blocked.
"AI"	SDDL_AUTO_INHERITED	Inheritance is allowed, assuming that "P" Is not also set.
"AR"	SDDL_AUTO_INHERIT_REQ	Child objects inherit permissions from this object.

ACE Flags

The ACE flags denote the inheritance options for the ACE, and if it is a SACL, the audit settings.

Value	Description
"CI"	CONTAINER INHERIT: Child objects that are containers, such as directories, inherit the ACE as an explicit ACE.
"OI"	OBJECT INHERIT: Child objects that are not containers inherit the ACE as an explicit ACE.
"NP"	NO PROPAGATE: ONLY IMMEDIATE CHILDREN INHERIT THIS ACE.
"IO"	INHERITANCE ONLY: ACE DOESN'T APPLY TO THIS OBJECT, BUT MAY AFFECT CHILDREN VIA INHERITANCE.
"ID"	ACE IS INHERITED
"SA"	SUCCESSFUL ACCESS AUDIT
"FA"	FAILED ACCESS AUDIT

Permissions

The Permissions are a list of the incremental permissions given (or denied/audited) to the trustee-these correspond to the permissions discussed earlier and are simply appended together. However, the incremental permissions are not the only permissions available. The table below lists all the permissions.

Value	Description
Generic access rights
"GA"	GENERIC ALL
"GR"	GENERIC READ
"GW"	GENERIC WRITE
"GX"	GENERIC EXECUTE
Directory service access rights
"RC"	Read Permissions
"SD"	Delete
"WD"	Modify Permissions
"WO"	Modify Owner
"RP"	Read All Properties
"WP"	Write All Properties
"CC"	Create All Child Objects
"DC"	Delete All Child Objects
"LC"	List Contents
"SW"	All Validated Writes
"LO"	List Object
"DT"	Delete Subtree
"CR"	All Extended Rights
File access rights
"FA"	FILE ALL ACCESS
"FR"	FILE GENERIC READ
"FW"	FILE GENERIC WRITE
"FX"	FILE GENERIC EXECUTE
Registry key access rights
"KA"	KEY ALL ACCESS
"K"	KEY READ
"KW"	KEY WRITE
"KX"	KEY EXECUTE

Object Type and Inherited Object Type

The ObjectType is a GUID representing an object class, attribute, attribute set, or extended right. If present it limits the ACE to the object the GUID represents. The Inherited Object Type is a GUID representing an object class. If present it limits inheritance of the ACE to the child entries of only that object class.

Trustee

The Trustee is the SID of the user or group being given access (or denied or audited). Instead of a SID, there are several commonly used acronyms for well-known SIDs. These are listed in the table below:

Value	Description
"AO"	Account operators
"RU"	Alias to allow previous Windows 2000
"AN"	Anonymous logon
"AU"	Authenticated users
"BA"	Built-in administrators
"BG"	Built-in guests
"BO"	Backup operators
"BU"	Built-in users
"CA"	Certificate server administrators
"CG"	Creator group
"CO"	Creator owner
"DA"	Domain administrators
"DC"	Domain computers
"DD"	Domain controllers
"DG"	Domain guests
"DU"	Domain users
"EA"	Enterprise administrators
"ED"	Enterprise domain controllers
"WD"	Everyone
"PA"	Group Policy administrators
"IU"	Interactively logged-on user
"LA"	Local administrator
"LG"	Local guest
"LS"	Local service account
"SY"	Local system
"NU"	Network logon user
"NO"	Network configuration operators
"NS"	Network service account
"PO"	Printer operators
"PS"	Personal self
"PU"	Power users
"RS"	RAS servers group
"RD"	Terminal server users