451 > dsacls <ObjectDN> 14.7.2.3 Using VBScript Unfortunately, the code to view the ACEs in an ACL is quite messy and long. This will be included as part of the code on the web site for the book (http://www.oreilly.com/catalog/activedckbk/ ). 14.7.3 Discussion Viewing an object's ACL is a common task and should already be familiar to most administrators. The ACL editor is useful for checking the permissions that have been set on objects, especially after running the Delegation of Control Wizard. In addition to viewing permissions, the options available in the GUI include, viewing Auditing settings and the Owner of the object. Knowing the owner of and object is important because ownership confers certain inherent rights. Because the ACL Editor is the same for NTFS permissions and properties as it is for Active Directory objects, you should feel comfortable with the look and feel of the interface—it is exactly the same as File and Folder permissions. I also highly recommend getting familiar with the Advanced View of the ACL Editor, as this is truly the view in which you can determine what is going on with permissions. The Basic view presents a list of security principals that have permissions configured, but it will not always show every ACE entry. The Advanced view will show the complete picture including the scope of permissions for ACEs down to the object and even attribute level. 14.7.4 See Also Recipe 14.10 for changing an ACL and Recipe 15.12 for auditing of object access Recipe 14.8 Customizing the ACL Editor 14.8.1 Problem You want to set permissions on attributes that do not show up in the default ACL Editor. 14.8.2 Solution The ACL Editor shows only a subset of the object's attributes that permissions can be set on. These can be seen in the ACL Editor by clicking the Advanced button, adding or editing a permission entry, and selecting the Properties tab. An attribute can have a read permission, write permission, or both, either of which can be set to Allow or Deny. If the attribute you want to secure is not in the list, you will need to modify the %SystemRoot%\system32\dssec.dat file on the computer running the ACL Editor. 452 There are sections for each object class, represented in square brackets—e.g., [user]. Underneath that heading is a list of attributes that you can configure to display or not display in the ACL Editor. These are the first few lines for the [user] section: [user] aCSPolicyName=7 adminCount=7 allowedAttributes=7 The value to the right of the attribute determines whether it is shown in the ACL Editor. The valid values include the following: 0 Both Read Property and Write Property are displayed for attribute. 1 Write property is displayed for the attribute. 2 Read property is displayed for the attribute. 7 No entries are displayed for the attribute. If the attribute is not defined, then the default value (specified by @, if present) is used. 14.8.3 Discussion Much like the Delegation of Control Wizard, you can customize the attributes that are shown in the ACL Editor, but you still need to distribute the dssec.dat file to all computers that need to see the change. A good example of when this recipe is needed is for delegating the ability to unlock accounts. This is common in larger organizations where you want to assign this task to the help desk without giving them additional rights on user objects. In this case, you need to set the lockoutTime in the [user] section of the dssec.dat file to 0. 14.8.4 See Also MS KB 296490 (How to Modify the Filtered Properties of an Object) and MS KB 294952 (How To Delegate the Unlock Account Right) 453 Recipe 14.9 Viewing the Effective Permissions on an Object 14.9.1 Problem You want to view the effective permissions for a user or group on a particular object. 14.9.2 Solution 14.9.2.1 Using a graphical user interface 1. Open the ACL Editor. You can do this by viewing the properties of an object (right-click on the object and select Properties) with a tool, such as Active Directory Users and Computers (ADUC) or ADSI Edit. Select the Security tab. To see the Security tab with ADUC, you must select View Advanced Features from the menu. 2. Click the Advanced button. 3. Select the Effective Permissions tab. 4. Click the Select button to bring up the Object Editor. 5. Find the user or group you for which want to see the effective permissions. 6. The results will be shown under Effective Permissions. The Effective Permissions tab is available only in the Windows Server 2003 version of the ACL Editor. For Windows 2000, you'll need to use the acldiag solution. 14.9.2.2 Using a command-line interface > acldiag <ObjectDN> /geteffective:<UserOrGroup> 14.9.3 Discussion Viewing the permissions on an object does not tell the whole story as to what the actual translated permissions are for a user or group on that object. The effective permissions of an object take into account all group membership and any inherited permissions that may have been applied further up the tree. Recipe 14.10 Changing the ACL of an Object 14.10.1 Problem You want to change the ACL on an object to grant or restrict access to it for a user or group. 14.10.2 Solution 14.10.2.1 Using a graphical user interface 454 1. Open the ACL Editor. You can do this by viewing the properties of an object (right-click on the object and select Properties) with a tool, such as Active Directory Users and Computers (ADUC) or ADSI Edit. Select the Security tab. To see the Security tab with ADUC, you must select View Advanced Features from the menu. 2. Click the Advanced button to view a list of the individual ACEs. 14.10.2.2 Using a command-line interface > dsacls <ObjectDN> 14.10.2.3 Using VBScript See Recipe 7.7, Recipe 8.2, Recipe 13.6, and Recipe 17.9 for several examples of modifying an ACL with VBScript. 14.10.3 Discussion Changing the ACL of an object is a common task for administrators in any but the most basic AD implementations because, as shown in Recipe 14.5 and Recipe 14.6, the Delegation of Control Wizard is limited and cumbersome to extend and deploy. The GUI and command-line methods are useful for one-off changes to permissions, but for making global changes to a number of objects you should consider using a script. 14.10.4 See Also MS KB 281146 (How to Use Dsacls.exe in Windows 2000) Recipe 14.11 Changing the Default ACL for an Object Class in the Schema 14.11.1 Problem You want to change the default ACL for an object class in the schema. 14.11.2 Solution 14.11.2.1 Using a graphical user interface 1. Open the Active Directory Schema snap-in. 2. In the left pane, browse to the class you want to modify. 3. Right-click on it and select Properties. 4. Select the Default Security tab. 5. Use the ACL Editor to change the ACL. 6. Click OK. 455 The Default Security tab is available only in the Windows Server 2003 version of the Active Directory Schema snap-in. See MS KB 265399 for the manual approach that is needed with Windows 2000. 14.11.3 Discussion Each instantiated object in Active Directory has an associated structural class that defines a default security descriptor (defaultSecurityDescriptor attribute). When an object is created, the default security descriptor is applied to it. This, along with inheritable permissions from the parent container, determines how an object's security descriptor is initially defined. 14.11.4 See Also Recipe 14.12 for comparing the ACL of an object to the default defined in the schema, Recipe 14.13 for resetting the ACL of an object to that defined in the schema, and MS KB 265399 (HOW TO: Change Default Permissions for Objects That Are Created in the Active Directory) Recipe 14.12 Comparing the ACL of an Object to the Default Defined in the Schema 14.12.1 Problem You want to determine if an object has the permissions defined in the schema for its object class as part of its ACL. 14.12.2 Solution 14.12.2.1 Using a command-line interface > acldiag <ObjectDN> /schema 14.12.3 Discussion For more on the default security descriptor, see Recipe 14.11. 14.12.4 See Also Recipe 14.13 for resetting an object's ACL to the default defined in the schema 456 Recipe 14.13 Resetting an Object's ACL to the Default Defined in the Schema 14.13.1 Problem You want to reset an object's ACL to the one defined in the schema for the object's object class. 14.13.2 Solution 14.13.2.1 Using a graphical user interface This is available only in the Windows Server 2003 version of the ACL Editor. 1. Open the ACL Editor. You can do this by viewing the properties of an object (right-click on the object and select Properties) with a tool, such as Active Directory Users and Computers (ADUC) or ADSI Edit. Select the Security tab. To see the Security tab with ADUC, you must select View Advanced Features from the menu. 2. Click the Advanced button. 3. Click the Default button. 4. Click OK twice. 14.13.2.2 Using a command-line interface > dsacls <ObjectDN> /s 14.13.3 Discussion For more on the default security descriptor, see Recipe 14.11. Recipe 14.14 Preventing the LM Hash of a Password from Being Stored 14.14.1 Problem You want to prevent the LM hash for new passwords from being stored in Active Directory. The LM hash is primarily used for backwards compatibility with Windows 95 and 98 clients. The LM hash is susceptible to brute force attacks. 14.14.2 Solution For Windows 2000, you need to create the following Registry key on all domain controllers: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\NoLMHash. Note that this is a key and not a value entry. Also, this is only supported on W2K SP2 and later domain controllers. 457 For Windows Server 2003, the NoLMHash key has turned into a DWORD value entry under the HKLM\SYSTEM\CurrentControlSet\Control\Lsa key. This value should be set to 1. You can accomplish this by modifying the Default Domain Controller Security Policy as described next. 14.14.2.1 Using a graphical user interface 1. Open the Default Domain Controller Security Policy snap-in. 2. In the left pane, expand Local Policies Security Options. 3. In the right pane, double-click on Network security: Do not store LAN Manager hash value on next password change. 4. Check the box beside Define this policy setting. 5. Click the Enabled radio button. 14.14.3 Discussion If you do not have Windows 98 or older clients in your domain, you should consider disabling the storage of the LM password hash for users. The LM hash uses an old algorithm (pre- Windows NT 4.0) and is considered to be relatively weak compared to the NT hash that is also stored. The LM hash is generated only for passwords that are shorter than 15 characters. So if you are one of the few people who have a password longer than this, the LM hash is not stored for you. 14.14.4 See Also MS KB 299656 (How to Prevent Windows from Storing a LAN Manager Hash of Your Password in Active Directory and Local SAM Databases) Recipe 14.15 Enabling List Object Access Mode 14.15.1 Problem You want to prevent any authenticated user from being able to browse the contents of Active Directory by default. Enabling List Object Access mode means users will need explicit permissions to see directory listings of containers. 14.15.2 Solution 14.15.2.1 Using a graphical user interface 1. Open ADSI Edit. 2. In the Configuration partition, browse to cn=Services cn=Windows NT cn=Directory Service. 3. In the left pane, right-click on the Directory Service object and select Properties. 458 4. Double-click on the dSHeuristics attribute. 5. If the attribute is empty, set it with the value: 001. If the attribute has an existing value, make sure the third bit (from the left) is set to 1. 6. Click OK twice. 14.15.2.2 Using VBScript ' This code enables or disables list object mode for a forest. ' SCRIPT CONFIGURATION boolEnableListObject = 1 ' e.g. 1 to enable, 0 to disable ' END CONFIGURATION set objRootDSE = GetObject("LDAP://RootDSE") set objDS = GetObject( _ "LDAP://cn=Directory Service,cn=Windows NT,cn=Services," _ & objRootDSE.Get("configurationNamingContext") ) strDSH = objDS.Get("dSHeuristics") if len(strDSH) = 1 then strDSH = strDSH & "0" end if strNewDSH = Left(strDSH,2) & boolEnableListObject if len(strDSH) > 3 then strNewDSH = strNewDSH & Right(strDSH, len(strDSH) - 3) end if WScript.Echo "Old value: " & strDSH WScript.Echo "New value: " & strNewDSH if strDSH <> strNewDSH then objDS.Put "dSHeuristics", strNewDSH objDS.SetInfo WScript.Echo "Successfully set list object mode to " & _ boolEnableListObject else WScript.Echo "List object mode already set to " & boolEnableListObject end if 14.15.3 Discussion List Object Access mode is useful if you want your users to only view a subset of objects when doing a directory listing of a particular container or you do not want them to be able to list the objects in a container at all. By default, the Authenticated Users group is granted the List Contents access control right over objects in a domain. If you remove or deny this right on a container by modifying the ACL, users will not be able to get a listing of the objects in that container in tools, such as Active Directory Users and Computers or ADSI Edit. To limit the objects' users can see when they do a listing, you first need to enable List Object Access mode as described in the solution. You should then remove the List Contents access control right on the target container. Lastly, you'll need to grant the List Object right to the objects the users or groups should be able to list. 459 Enabling List Object Access mode can significantly increase the administration overhead for configuring ACLs in Active Directory. 14.15.4 See Also MSDN: Controlling Object Visibility and Microsoft's High-Volume Hosting Site at http://www.microsoft.com/serviceproviders/deployment/hvh_ad_deploy.asp Recipe 14.16 Modifying the ACL on Administrator Accounts 14.16.1 Problem You want to modify the ACL for user accounts that are members of one of the administrative groups. 14.16.2 Solution Using one of the methods described in Recipe 14.10, modify the ACL on the cn=AdminSDHolder,cn=Systems,<DomainDN> object in the domain the administrator accounts reside in. The ACL on this object gets applied every hour to all user accounts that are members of the administrative groups. 14.16.3 Discussion If you've ever tried to directly modify the ACL on a user account that was a member of one of the administrative groups in Active Directory, or you modified the ACL on the OU containing an administrative account and wondered why the account's ACL was overwritten later, you've come to the right place. The Admin SD Holder feature of Active Directory is one that many administrators stumble upon after much grinding of teeth. However, after you realize the purpose for it, you'll understand it is a necessary feature. Once an hour, a process on the PDC Emulator, which I'll refer to as the Admin SD Holder process, compares the ACL on the AdminSDHolder object to the ACL on the accounts that are in administrative groups in the domain. If it detects a difference, it will overwrite the account ACL and disable inheritance. If you later remove a user from an administrative group, you will need to reapply any inherited permissions and enable inheritance if necessary. The Admin SD Holder process will not take care of this for you. The Admin SD Holder process is intended to subvert any malicious activity by a user that has been delegated rights over an OU or container that contains an account that is in one of the administrative groups. The malicious user could, for example, reset the password of the account and log in to the domain using that account, which would give him elevated privileges to do even more malicious things. 460 These are the groups included as part of the Admin SD Holder processing: • Administrators • Account Operators • Cert Publishers • Backup Operators • Domain Admins • Enterprise Admins • Print Operators • Schema Admins • Server Operators The Administrator and Krbtgt user accounts are also specifically checked during the Admin SD Holder process. 14.16.4 See Also MS KB 232199 (Description and Update of the Active Directory AdminSDHolder Object), MS KB 306398 (AdminSDHolder Object Affects Delegation of Control for Past Administrator Accounts), and MS KB 817433 (Delegated Permissions Are Not Available and Inheritance Is Automatically Disabled) Recipe 14.17 Viewing and Purging Your Kerberos Tickets 14.17.1 Problem You want to view and possibly purge your Kerberos tickets. 14.17.2 Solution Both the kerbtray and klist utilities can be found in the Resource Kit. 14.17.2.1 Using a graphical user interface 1. Run kerbtray.exe from the command line or Start Run. 2. A new icon (green) should show up in the system tray (where the system time is located). Double-click on that icon. This will allow you to view your current tickets. 3. To purge your tickets, right-click on the kerbtray icon in the system tray and select Purge Tickets. 4. Close the kerbtray window and reopen it by right-clicking on the kerbtray icon and selecting List Tickets. 14.17.2.2 Using a command-line interface . in Active Directory. The LM hash is primarily used for backwards compatibility with Windows 95 and 98 clients. The LM hash is susceptible to brute force attacks. 14.14.2 Solution For Windows. Security tab is available only in the Windows Server 2003 version of the Active Directory Schema snap-in. See MS KB 265399 for the manual approach that is needed with Windows 2000. 14.11.3 Discussion. inherent rights. Because the ACL Editor is the same for NTFS permissions and properties as it is for Active Directory objects, you should feel comfortable with the look and feel of the interface—it