ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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 WindowsSystem32 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.
