- 1 Exploring Windows 2003 Security: More Active Directory Security Improvements
- 2 Exploring Windows 2003 Security: Configuring Code Access Security
- 3 Exploring Windows 2003 Security: The .NET Framework
- 4 Exploring Windows 2003 Security: SID Filtering and Software Restriction Policies
- 5 Exploring Windows 2003 Security: SID Filtering and Software Restriction Policies
- 6 Exploring Windows 2003 Security: Overview
- 7 ServerWatch Articles by Marcin Policht
- 1 Vapor IO Brings OpenDCRE to General Availability
- 2 VMware Takes the Wraps Off vRealize Automation and vRealize Business
- 3 Microsoft Previews Hyper-V Containers for Windows Server 2016
- 4 Mirantis Led FUEL Project Gets Installed Under OpenStack Big Tent
- 5 Red Hat Enterprise Linux 7.2 Adds Security, DR Features
Exploring Windows 2003 Security: Active Directory and Authentication Security Improvements
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 CatalogThe 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
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.