Exploring Windows 2003 Security: Active Directory and Authentication Security Improvements

Wednesday Sep 3rd 2003 by Marcin Policht

The fifth installment in our Windows Server 2003 security series discusses additional Active Directory and authentication improvements, including domain logons in the absence of a global catalog, handling password resets, and group policies in environments with a cross-forest trust

Previous articles in this series have covered some of the security-related improvements in Active Directory and other authentication areas introduced in Windows Server 2003. This article continues to flesh out the subject by focusing on the following items:

  • Domain logons in the absence of a global catalog
  • Handling password resets of a local administrator account on domain controllers
  • Group policies in environments with cross-forest trusts
  • Auditing last logon time for domain accounts
  • Setting default containers for newly created user and computer accounts

Domain Logons and Global Catalog

In Windows 2000 native mode domains, under normal circumstances the user's logon requires ability to contact a global catalog. The reason for this requirement is the need to verify the user's membership in universal groups. This becomes especially significant when deploying branch offices connected via slow WAN links, which can become easily saturated with global catalog replication traffic.

To remedy such situations, Microsoft introduced a registry key called IgnoreGCFailures, described in Knowledge Base Article Q241789. Once implemented on a domain controller authenticating logons (typically the one located at a remote office), this registry key permits successful logon even when a global catalog is not available.

However, at the same time, Microsoft discourages use of this hack due to its security implications. As you can imagine, if universal security groups are used to deny access to sensitive resources, such protection will be useless once the IgnoreGCFailures key is implemented.

Windows Server 2003 resolves this problem by providing the capability to cache universal group membership. This is configurable from Active Directory Sites and Services under the NTDS Site Settings node by enabling the checkbox labeled "Enable Universal Group Membership" in the NTDS Site Settings Properties dialog box (this implies the creation of a separate site for a location where caching will be enabled and that caching is performed for all domain controllers in that site). In addition, you can specify which site will be used for the refresh (by typing its name in the "Refresh cache from" text box) or you can accept the default, which automatically chooses a global catalog in the closest (in the term of cumulative site link cost) site.

Enabling this setting does not alter the first authentication attempt by a user. The local domain controller still needs to contact the global catalog to check the universal groups to which this user belongs. However, from this point on, the information returned from the global catalog is cached locally and refreshed, by default, every eight hours.

Besides enhancing security, this mechanism has a number of other benefits, including faster login time, decreased replication traffic, and cost savings (since regular domain controllers have lower hardware requirement than global catalogs).

Local Administrator Password Resets on Domain Controllers

As you might be aware, each domain controller, besides hosting Active Directory where all accounts are stored, has a SAM database that contains a local administrator account. This account is the only one available for logon when rebooting the domain controller in the Active Directory Restore Mode (since, at that point, none of domain accounts are available). Its password is set when running domain controller promotion process (DCPROMO).

In Windows 2000, to reset this password, you had to resort to restarting the server in the Active Directory Restore mode (and subsequent reboot to bring the server back to the operational state).

Windows server 2003 handles this issue much more gracefully by including a "Set DSRM Password" option in the NTDSUTIL command line utility. To take advantage of this option, use the following steps:

  • From the Command Prompt interface on a server, type NTDSUTIL (This does not have to be the domain controller on which you want to reset the password). This will display the ntdsutil: prompt.
  • Type Set DSRM Password at the ntdsutil: prompt. This will display Reset DSRM Administrator Password: prompt. You can then type the ? to list available options. You can also abbreviate each of them, as long as the abbreviation uniquely identifies the one you intend to use (e.g., you can type Set DS P instead).
  • Finally, type in Reset Password on Server SERVERNAME where SERVERNAME is the name of the domain controller on which you want to reset the password. You must then type in the password twice (to minimize chance for a typo).
  • Typing Quit (or simply Q) twice will then bring you back to the original command prompt.

As you can expect, the target domain controller must be online (and not in the Active Directory Restore Mode) when this operation is performed. The ability to reset the password without restarting the server simplifies maintaining highly secure environments, where periodic password changes are the norm.

Group Policies in Multi-Forest Environments

Group Policies are intended not only to provide a consistent and user friendly computing environment, but also to enhance its security. In the scenarios involving multiple Windows 2000 forests, it was possible to create trust relationships between domains from separate forests, which in turn allowed cross-forest logons (i.e., UserA from DomainA in ForestA could log on to a computer residing in DomainB in ForestB); however, Group Policies that were assigned to that user did not take effect. With Windows 2003 forest-level trusts, this is no longer the case. Note, however, that this feature requires a Windows 2003 forest functionality level (which means that all domain controllers in both forests must have Windows server 2003 installed).

lastLogonTimestamp User Account Attribute

Frequently, it is important to determine the most recent domain logon for a particular user. Prior to Windows 2003, it was possible to record it (using audit policies), but the information was located only on the authenticating domain controller, so locating it required a search to be conducted throughout all of them.

In Windows 2003, this information is stored in the lastLogonTimestamp Active Directory attribute and replicated across all domain controllers for each domain. This feature requires Windows 2003 domain functionality level. You can extract information using any of Active Directory editing tools (such as ADSI Edit or LDP) or by running custom queries in Active Directory User and Computers (which also offers a days-since-last-logon option available for predefined intervals of 30, 60, 90, 120, and 180 days as part of Common Queries).

Setting Default User and Computer Container

When a new computer is added to a Windows 2000 domain during operating system installation, its account is created in the default Computers container in the Active Directory. This container is not an ogranizational unit, so it is not possible to apply any group policies specifically to objects residing in it, beyond the ones that apply to entire domain (or site). This can be considered a security vulnerability, especially if certain areas within a company require higher levels of security. The same issue applies to creating user accounts via command line (using NET USER command).

Obviously, there are workarounds (e.g., a computer account can be precreated in appropriate container or the process of adding a computer account can be customized through scripting or use of Windows 2000 version of NETDOM.EXE utility), but they require additional engineering effort.

Windows 2003 addresses this problem by allowing the redirection of newly created user and computer accounts to an arbitrarily selected Active Directory container. The target container for newly created users is defined by typing the following at the command prompt of a Windows Server 2003 configuration:

REDIRUSR ou=TargetUserOU,DC=domain,dc=com
where TargetUserOU is the name of the designated container for user accounts, and domain.com is the domain name. Similarly, to specify the target container for newly created computer accounts, you would use:

REDIRCMP ou=TargetComputerOU,DC=Domain,dc=Com
where TargetComputerOU is the name of the designated container for computer accounts and domain.com is the domain name. Both of these utilities (REDIRUSR.EXE and REDIRCMP.EXE) reside in the Windows\System32 folder on any Windows Server 2003 . Their use modifies the wellKnownObjects Active Directory attribute of the PDC emulator, which determines the default location for a number of Active Directory features, including user and computer accounts, as well as Lost and Found and Domain Controllers. Note that this feature requires Windows 2003 domain functional level.

The next article in this series will cover the remaining new features of Windows Server 2003 as related to Active Directory and Authentication.

Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved