Active Directory Cookbook for windows server 2003- P45 doc

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 att

> 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

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)

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

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

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

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

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

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

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

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