Enabling SID Filtering

On domain controllers that are running Windows Server 2003 or running Windows 2000 Server SP4 or later, SID filtering is applied by default to an outgoing, external trust to “quarantine” the trusted domain. This feature allows only SIDs from the trusted domain to be included in authorization data.

You might want to enable SID filtering if external trusts are in place that do not have SID filtering applied (that is, that were created on domain controllers running Windows 2000 Server SP3 or earlier).

Requirements

• Credentials: Domain Admins for the trusting domain
• Tools: Netdom.exe (Windows Server 2003 Support Tools)

To enable SID filtering for an outgoing, external trust

1. Log on to a domain controller in the trusting domain using an account with Domain Admins credentials.

2. At the command line, type:

   netdom trusttrusting domain name**/domain**:trusted domain name**/userO:user_name [/passwordO:*] /Quarantine:yes**

   If you do not use the character * for the password, the password appears in plaintext. If you use *, you will be prompted for a password that does not display when you type it.

Enabling Auditing on Important Active Directory Objects

This procedure configures auditing on actions that are performed against specific important Active Directory objects. The actions to be audited are specified in Table 23 through Table 34 earlier in this guide.

Requirements

• Credentials: Domain Admins
• Tools: ADSI Edit (Windows Server 2003 Support Tools)

To set auditing on important Active Directory objects

1. Log on to a domain controller in the root domain by using an account with Domain Admins credentials.

2. In the Run dialog box, type adsiedit.msc, and then click OK.

3. In the console tree, double-click the appropriate directory partition, right-click container_object — where container_object is the topmost object in the domain, configuration, schema, or application directory partition or the domain controller OU in a domain where you want to enable auditing, and then click Properties.

   Application directory partitions do not appear in the ADSI Edit console tree by default. If the appropriate directory partition does not appear in the console tree:

   • On the Action menu, click Connect to.
   • Under Connection point, click Select or type a Distinguished Name or Naming Context, type or select the distinguished name of the directory partition, and then click OK.

4. On the Security tab in the Properties dialog box, click Advanced.

5. On the Auditing tab in the Advanced Security Settings dialog box, click Add.

6. Create auditing settings to match the settings in Table 23 through Table 34 earlier in this guide.

Securing Scripts with Script Signing

Two alternatives exist for creating signed scripts. If you want to develop your own script host, the .NET Framework Software Development Kit (SDK) contains a set of tools for signing scripts: the File Signing Tool (Signcode.exe) and the Certificate Verification Tool (Chktrust.exe). When writing your own script host, call the Win32 API WinVerifyTrust. This API verifies the trust on a .vbs or .js file.

Alternatively, Windows Script Host version 5.6, which ships with Windows Server 2003, includes a signer object for creating and verifying signed scripts. The following JScript® code creates a signed file:

var Signer = new ActiveXObject("Scripting.Signer");
var File  = "c:\\myfile.vbs";
var Cert  = "Jane Q. Programmer";
var Store = "my";
Signer.SignFile(File, Cert, Store);

The following sample, in this case as Microsoft® Visual Basic®, Scripting Edition (VBScript) code, verifies the signing on a file:

Dim Signer, File, ShowUI, FileOK
Set Signer = CreateObject("Scripting.Signer")
File = "c:\newfile.wsf"
ShowUI = True
FileOK = Signer.VerifyFile(File, ShowUI)
If FileOK Then
    WScript.Echo File & " is trusted."
Else
    WScript.Echo File & " is NOT trusted."
End If

For more information about new code-signing features to protect against malicious scripts, see the following article in the MSDN Library at https://msdn.microsoft.com/msdnmag/issues/01/04/WSH/.

For more information about using Windows Script Host, see Help and Support Center for Windows Server 2003.

Updating the Default Domain Policy GPO and the Default Domain Controllers Policy GPO

This procedure modifies either default domain-level Group Policy or the default Domain Controllers OU–level Group Policy.

Requirements

• Credentials: Domain Admins
• Tools: Domain Controller Security Policy or Domain Security Policy (Administrative Tools)

Table 44 contains information about the policies and settings that you can use to update the default GPOs that apply to the domain and to the Domain Controllers OU.

Table 44 Policy Settings for the Default GPOs

Default GPO	Where Policy Is Applied	Policy	Recommended Policy Settings
Default Domain Policy, Account Policies node	Domain root	Password Policy Account Lockout Policy Kerberos Policy	See Table 13 See Table 14 See Table 15
Default Domain Controllers Policy, Local Policies node	Domain Controllers OU	Audit Policy User Rights Assignment	See Table 16 See Table 17

To edit security settings in the Default Domain Policy GPO or the Default Domain Controller Policy GPO

1. Log on with Domain Admins credentials, and then open either Domain Controller Security Policy or Domain Security Policy.

2. In the console tree, under Security Settings, double-click Account Policies or Local Policies, depending on which node contains the settings that you want to change.

3. Click the policy whose settings you want to change, as specified in Table 44.

4. In the details pane, double-click the policy setting that you want to edit.

5. On the Security Policy Setting tab, select or type the recommended value, and then click OK.

6. Restart the computer, or run Secedit /refreshpolicy machine_policy, to apply the settings to the Default Domain GPO or the Default Domain Controllers GPO.

Creating a New GPO on the Domain Controllers OU and Changing Its Precedence

By performing this procedure, you:

• Create a new GPO and add it to the list of Group Policy objects that are linked to the Domain Controllers OU.
• Move the new GPO to a position in the list that is above the Default Domain Controllers GPO, to ensure that its policy settings take precedence over the Default Domain Controllers GPO settings.

Requirements

• Credentials: Domain Admins
• Tools: Active Directory Users and Computers

To create a new GPO on the Domain Controllers OU and increase its precedence

1. Log on with Domain Admins credentials, and then open Active Directory Users and Computers.

2. In the console tree, right-click Domain Controllers, and then click Properties.

3. On the Group Policy tab, click New.

4. In the Group Policy Object Links box, type a name for the new GPO, and then click Edit.

5. In the policy tree under Computer Configuration, double-click Windows Settings, and then double-click Security Settings.

6. Double-click the set of policy settings that you want to define for the new GPO: Local Policies or Event Log.

7. Click the policy whose settings you want to add to the GPO.

8. In the details pane, double-click a setting, type or select values, and then click OK.

9. When you have defined all the settings that you want for the new GPO, close the Group Policy Object Editor window.

10. To move the new GPO to a position above the Default Domain Controllers Policy GPO, on the Group Policy tab, click Up, and then click Close.

11. Restart the computer, or run Secedit /refreshpolicy machine_policy to update the Group Policy settings for the Domain Controllers OU.

Creating a .reg File

To create a scripting solution that changes a registry setting on a computer, you can use the registry editor to add or modify a registry setting and then export the setting to a .reg file. You can use the .reg file in scripts to apply the registry setting to other computers.

Requirements

• Credentials: Administrators
• Tools: Regedit.exe

To export a registry setting to a .reg file

1. Click Start, click Run, type regedit, and then click OK.

   • In the console tree, navigate to the registry entry that you want to include in the file.
   • Add or modify the entry that you want to export to the .reg file.
   • With the entry selected, on the File menu, click Export.

2. In the Save in box, navigate to the location for the .reg file.

3. In the File name box, type a name for the .reg file.

4. Under Export range, click Selected branch, and then click Save.

Creating a Reserve File

This procedure reserves disk space by creating a file on the same disk volume as the Active Directory database. The reserve file size should be the larger of 250 MB or 1 percent of the size of the logical disk volume where the Active Directory database is stored.

Requirements

• Credentials: Domain Admins
• Tools: Fsutil.exe (System32 tool)

To create a reserve file on a domain controller

1. Log on to a computer that is running Windows Server 2003 or Windows XP Professional.

2. Map a network drive to the remote administrative share for the disk volume where the Active Directory database is stored, for example, \\server_Name\C$ or D$. When prompted, provide Domain Admins credentials.

3. Open a command prompt on the computer to which you are logged on, and then change to the mapped drive.

4. Create the reserve file by typing the following command:

   fsutil file createnewreserve_file_name reserve_file_size_in_bytes

5. In Windows Explorer, grant Full Control to Administrators on the reserve file.

Enabling Monitoring for Anonymous Active Directory Access

You can enable monitoring for anonymous access through audit settings on the Active Directory object CN=Server,CN=System,domain,DC=…ForestRootDomain. The audit settings ensure that a Security audit log event is generated whenever an application or service attempts to list or read domain data in Active Directory with anonymous access. The most common generators of these events are applications or services, such as Routing and Remote Access Service, that are running on Windows NT 4.0 domain controllers or on member servers in the context of Local System.

Requirements

• Credentials: Domain Admins
• Tools: ADSI Edit (Windows Server 2003 Support Tools)

To enable monitoring for anonymous Active Directory access

1. Log on to a domain controller in the root domain by using an account with Domain Admins credentials.

2. Click Start, click Run, type adsiedit.msc, and then click OK.

3. In the console tree, double-click the domain, and then click the System container.

4. In the details pane, right-click Server, and then click Properties.

5. On the Security tab, click Advanced.

6. On the Auditing tab, click Add.

7. In the Enter the object name to select box, type anonymous, and then click OK.

8. In the Auditing Entry for Server dialog box, set the auditing entries shown in Table 45.

**Table 45 Audit Settings for CN=Server,CN=System,DC=domain,DC=…**ForestRootDomain

Type	Name	Access	Apply Onto
Success	Anonymous	Read All Properties	This object only
Success	Anonymous	Enumerate Entire SAM Domain	This object only

Monitoring for Anonymous Active Directory Access

In the previous procedure, you enabled security monitoring for anonymous access by setting auditing. The auditing is set on the objects that are accessed anonymously by applications and services from other domain controllers, member servers, or workstations in the domain.

To make the analysis of the aggregated Security event logs easier, export the aggregated Security event logs to a database, such as Microsoft Access. Collect the event logs for about 30 days to ensure that all applications and services have attempted anonymous access, and pay special attention to applications and services that are running on Windows NT 4.0 in the security context of Local System.

Requirements

• Credentials: Domain Admins
• Tools: unspecified database product

To monitor for anonymous Active Directory access

1. Collect Security event logs for 30 days on all domain controllers.

2. Aggregate the event logs from each domain controller into a database.

3. Identify the anonymous access events in the aggregated event logs by querying the Security event log for any events with Event ID = 565 (directory service access events) and the text “anonymous” (case insensitive) in the event.

   Identify the logon IDs that generated the anonymous access for the events that meet the criteria in the previous step.

   The output of this query contains the list of the logon IDs that generated the anonymous access.

4. Identify the logon and logoff events associated with the logon IDs that you identified in the previous step, by querying the results of the events in the previous step for Event ID = 528 (logon events) or Event ID = 540 (logoff events).

5. Identify the domain controllers, member servers, or workstations where the logon and logoff events that you identified in the previous step originated.

6. Identify the applications or services that are running on the domain controllers, member servers, or workstations where the anonymous access originated.

   Examples of applications or services that require anonymous access include Routing and Remote Access Service running on Windows NT 4.0, Microsoft SQL Server running on Windows NT 4.0 (with Integrated or Mixed SQL logon), and print servers running on Windows NT 4.0.

Renaming the Default Administrator Account

This procedure eliminates any information that can alert attackers that this account has elevated privileges. Although an attacker would still need the password, hiding the default Administrator account by renaming it adds an additional layer of protection against password attacks seeking elevation of privilege.

Requirements

• Credentials: Domain Admins
• Tools: Active Directory Users and Computers

To rename the default Administrator account

1. Log on with Domain Admins credentials, and then open Active Directory Users and Computers.

2. In the console tree, click Users.

3. By default, the Administrator account is in the Users container. However, if you have already created a Service Admin subtree, the Administrator account might have been moved to the Users and Groups OU in the new subtree.

4. In the details pane, right-click Administrator, and then click Rename.

5. Type a fictitious account name, and then press ENTER.

6. In the Rename User dialog box, change the Full name, First name, Last name, Display name, User logon name, and User logon name (pre-Windows 2000) values to match the new account name, and then click OK.

7. In the details pane, right-click the renamed account object, and then click Properties.

8. On the General tab, change the Description to resemble other user accounts.

9. On the Account tab, change Account options if needed.

Creating a Decoy Administrator Account

This procedure adds an additional layer of protection when you hide the default Administrator account. An attacker planning a password attack on the Administrator account can be fooled into attacking an account with no special privileges.

Requirements

• Credentials: Domain Admins
• Tools: Active Directory Users and Computers

To create a decoy Administrator account

1. Log on with Domain Admins credentials, and then open Active Directory Users and Computers.

2. In the console tree, right-click the Users container, click New, and then click User.

3. Type the following information:

   • In First name and User logon name, type Administrator.
   • Type and confirm a password.

   Your new account appears in the Users container.

4. In the details pane, right-click Administrator, and then click Properties.

5. On the General tab, in the Description box, type Built-in account for administering the computer/domain, and then click OK.

Changing the Security Descriptor on AdminSDHolder

The security descriptor on AdminSDHolder serves two purposes. First, it controls access to the AdminSDHolder object itself. Second, it acts as the master security descriptor that is periodically applied to the service administrator accounts and their members to ensure that they remain protected.

Requirements

• Credentials: Domain Admins
• Tools: Active Directory Users and Computers

To change the security descriptor on AdminSDHolder

1. Log on with Domain Admins credentials, and then open Active Directory Users and Computers.

2. On the View menu, click Advanced Features.

3. In the console tree, click the System container.

4. In the details pane, right-click AdminSDHolder, and then click Properties.

5. On the Security tab, modify the security descriptor by changing the settings as specified in Table 39.

Denying Logon Access to the Domain

To deny logon access to a domain, limit the locations where the service administrator accounts can log on by denying log on locally to members of the Enterprise Admins, Domain Admins, Server Operators, Backup Operators, and Account Operators groups at the domain level. Doing so prohibits administrators from logging on to any computers in the domain. Also, be sure to follow the procedure in the next section, “Allowing Logon Access to Administrative Workstations,” for restoring logon capability to administrators so that they can log on to administrative workstations.

Requirements

• Credentials: Domain Admins
• Tools: Active Directory Users and Computers

To deny logon access at the domain level to service administrators

1. Log on with Domain Admins credentials, and then open Active Directory Users and Computers.

2. In the console tree, right-click domain_name, and then click Properties.

3. On the Group Policy tab, click Default Domain Policy, and then click Edit.

4. Expand the policy tree to Computer Configuration\Windows Settings\Security Settings\Local Policies, and then click User Rights Assignment.

5. In the details pane, double-click Deny logon locally.

6. Click Define these policy settings, and then click Add.

   Add all of the service administrator accounts (Administrators, Schema Admins, Enterprise Admins, Domain Admins, Server Operators, Backup Operators, and Account Operators) to the list.

Allowing Logon Access to Administrative Workstations

You can limit the locations where the service administrator accounts can log on by allowing logon locally to Enterprise Admins, Domain Admins, Server Operators, Backup Operators, and Account Operators only on administrative workstations. Administrative workstations are the computer objects in the Admin Workstations OU.

To ensure that the default Deny log on locally right is not applied by the Default Domain Policy GPO, you must also define this policy on the OU without adding any users or groups.

Requirements

• Credentials: Domain Admins
• Tools: Active Directory Users and Computers

To allow logon access to the Admin Workstations OU and override the Deny log on locally right in the Default Domain Policy GPO

1. Log on with Domain Admins credentials, and then open Active Directory Users and Computers.

2. In the console tree, right-click Admin Workstations, and then click Properties.

3. On the Group Policy tab, click New.

4. Type Service Administrator Policies, and then click Edit.

5. Expand the policy tree to Computer Configuration\Windows Settings\Security Settings\Local Policies, and then click User Rights Assignment.

6. In the details pane, double-click Allow log on locally.

7. Click Define these policy settings, and then click Add User or Group.

8. Add the Administrators group and Everyone to the list, and then click OK.

9. In the details pane, double-click Deny log on locally.

10. Click Define these policy settings, and then click OK.