Moving Active Directory operations masters is not something that you need to do every day, and I can never remember how to do it when I need to (well the RID, PDC, infrastructure and domain naming masters are easy enough, but I always forget how to move the schema master because it requires registration of the Active Directory Schema console).

As part of the final preparations for shutting down a virtual machine which I had running as a temporary domain controller, I needed to transfer all of the operations masters roles to the remaining permanent (physical) machine. Full details (along with details for identification of and seizing roles) can be found in the Active Directory how to… manage operations master roles section of the Microsoft Windows Server 2003 TechCenter.

Non-technical colleagues, and friends who work with Microsoft products but outside of a corporate environment often ask me “what is Active Directory” (AD). As I’ve blogged a few 10,000 feet views of Microsoft technologies, I thought I’d produce one for AD.

At the Microsoft Technical Roadshow event last May, Paul Brombley (a messaging technology specialist for Microsoft UK) gave a presentation on Exchange and the Active Directory which included an “AD 101”. As I thought it was an excellent overview I haven’t re-invented the wheel and the following is taken from my notes from that presentation, with a few items added from my own experience.

Active Directory is basically a distributed database. It is hierarchical, with a permissions model, includes a common set of objects and is integrated with Windows Security as the primary means of authentication (and hence authorisation).

AD makes use of DNS as a name service. AD cannot be implemented without DNS although it does not require a Microsoft DNS service – in fact, any DNS server supporting SRV records (RFC 2782) and dynamic DNS updates (RFC 2136) can be used to support Active Directory although there are advantages to using the Windows DNS Server (e.g. AD-integrated DNS zones).

This reliance on DNS is apparent when the logical structure of AD is examined. As for Windows NT, domains can be linked using trust relationships. The main differences with AD are that instead of using NetBIOS names, DNS is the naming service for AD domain (with NetBIOS and WINS only supported for legacy purposes) and that default trusts are two-way transitive Kerberos trusts.

Each AD server is called a domain controller (DC) and all DCs can authenticate users.

Each domain must have at least one DC. One or more domains sharing a common schema are referred to as a forest. If these domains also have a contiguous namespace then they are called a tree, and each forest may contain multiple trees; however the first domain in the forest is always the forest root domain. These concepts are illustrated in the Windows 2000 Advanced Server help documentation: understanding domain trees and forests.

DCs replicate data using a multiple master model (although there are five roles known as operations masters, or FSMOs, which dictate the master server for certain operations at domain or forest level – for more information, see Daniel Petri’s description of the FSMO roles).

There are four naming contexts (NCs) which make up AD:

• The schema NC contains a schema of object definitions. This is common throughout the entire directory and can be changed by a domain administrator running with local system privileges – hence the reason why a forest is a security boundary and not a domain (as is commonly misconceived). The schema NC is replicated between all domain controllers.
• The configuration NC contains details of the replication technologies, domains and servers. This is replicated to all DCs within a forest.
• The domain NC contains objects such as users, groups and contacts. This is replicated to all DCs within a domain; however a DC can also have an additional role of a global catalog (GC) server. The GC is a subset of each domain NC in the forest, merged to form a single view of the objects in the directory (albeit without all attributes). Applications such as Microsoft Exchange make heavy use of GC servers, e.g. to create a global address list.
• The application NC is new to Windows Server 2003 AD and contains volatile application information. This is held on specific DCs within the forest.

An AD site is a group of servers with good connectivity (generally LAN connected). A site can span domains and a domain can cross a number of sites.

In addition to my earlier post on new features in Windows Server 2003 AD include:

• Schema deactivation, whereby certain attributes (not those added by Exchange) can be blanked out (although they are not deleted and remain present in the database).
• Group membership replication improvements, whereby only deltas are replicated (with Windows 2000 sometimes the replication took longer than the 15 minute replication interval).
• Domain renaming (with restrictions).
• Application naming context (discussed above).

(Some of these features require the domain or forest to be running at Windows Server 2003 domain or forest functional level).

So, that’s AD in a nutshell. For further reading, check out Microsoft’s Windows Server 2003 Active Directory pages or Active Directory forestry: investigating and managing objects and attributes for Windows 2000 and Windows Server 2003 by John Craddock and Sally Storey.

A few weeks back I was looking at migrating users between forests using ADMT when the source and target domain names are similar. It worked in my virtual environment but when we went to put it into practice there were some issues caused by different people’s perception of what the sIDHistory attribute will do.

sIDHistory will not avoid the need to enter the correct password to access resources in the original domain.

If there is a trust in place, then the trusting domain will trust users in the trusted domain.

If there is no longer a trust (or as in my client’s case, where there was no direct trust but a sequence of non-transitive external trusts) then sIDHistory will allow migrated users security credentials to be compared with the access control entries (ACEs) in the access control list (ACL) for a resource and if there is a match then they will be authorised; however they still need to be authenticated.

If the passwords are the same in the new and the old domains, then there will be no password prompt (as the hashes will match and the user will authenticate transparently); however if there are different passwords in use, then the correct password for the user’s old account in the resource domain will still need to be supplied.

Further reading

Unable to browse users in trusted domain (Microsoft knowledge base article 263956).
How to use Active Directory Migration Tool version 2 to migrate from Windows 2000 to Windows Server 2003 (Microsoft knowledge base article 326480).
How to Troubleshoot Inter-Forest sIDHistory Migration with ADMTv2 (Microsoft knowledge base article 322970).

One of my clients is undertaking a domain consolidation process, moving to a new Active Directory (AD) forest called companyname.com with two child domains – emea.companyname.com and americas.companyname.com. All of the user accounts from the various NT 4.0 and Windows 2000 domains around the organisation are being migrated into this structure using the Active Directory migration tool (ADMT) but access will be required to resources in the legacy domains (at least in the short term).

This is all reasonably straightforward, or it was until my colleagues unearthed a a new domain in Belgium called companyname.be. Because ADMT is reliant on external (NT 4.0) trust relationships, which are established using NetBIOS names (not DNS), and because emea.companyname.com already has a Kerberos trust with companyname.com, it will not allow an external trust to be created with companyname.be. We don’t want to have to recreate the users and so I had to find a way around the problem. It’s not that complex – just a two step migration, but we also needed to confirm that the sIDHistory attribute for each user would remain in place if the account was migrated more than once (in order to maintain access to resources in the original domain).

To prove this, I created four virtual machines (which run very slowly when the host is a notebook PC with only 1Gb of RAM…) representing domain controllers as follows:

• dc1.companyname.com
• dc2.emea.companyname.com
• dc3.companyname.be
• dc4.transfer.local

I created three users in companyname.be (imaginatively named user1, user2, and user3) and a share called userdata (with some test files), to which users 1 and 2 had access and user 3 was denied access. I also disabled user2 and created a group to which all three users were added as members.

The intention was to transfer the user accounts from companyname.be to transfer.local, and then to perform a second migration from transfer.local to emea.companyname.com, maintaining the account status (enabled or disabled), group membership and passwords, and then using a connection to the files on the share as a test of migrated sIDHistory.

Once I had DNS resolving names across the three forests, I installed ADMT on dc4.transfer.local and migrated the users. ADMT is fairly straightforward to set up and run, but it is necessary to read and fully understand the requirements in Microsoft knowledge base article 326480, with the main points for my client’s scenario being:

• The target domain needs to be running in Windows 2000 native mode or later (without this, the sIDHistory attribute does not exist).
• The computer running ADMT must be a member of either the source or the target domain.
• The source domain must trust the target domain (in order for user and group migration to take place).
• Administrator rights are required in both the source and target domains (e.g. by adding the target domain’s Administrator account to the source domain’s Administrators group and vice versa).

There is also an (undocumented) requirement that a non-blank password must be used for the account used to run ADMT (because I was running on a dedicated test system I was originally using the Administrator accounts with blank passwords, which needed to be changed). There is also some troubleshooting information available in Microsoft knowledge base article 322970.

Once the above are in place, ADMT will complete some of the other requirements for user and group migration, namely:

• Creating a new (empty) local group in the source domain named sourcedomainname$$$.
• Enabling auditing for the success and failure of Audit account management on both domains in the Default Domain Controllers policy.
• Configuring the source domain to allow RPC access to the SAM by setting HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\TcpipClientSupport to 1 on the PDC Emulator for the source domain and restarting that server.

Microsoft knowledge base article 326480 also describes the process for installing the password migration DLL in order to migrate user passwords.

It should be noted that the configuration items above expose serious security weaknesses which must be secured once the migration is completed.

Once the users (with passwords) and group (with membership) had been migrated once, I could install ADMT on dc2.emea.companyname.com and migrate them again, this time from transfer.local to emea.companyname.com.

Finally, to test that the sIDHistory attribute was allowing access to resources in the original source domain (companyname.be), I logged on to dc2.emea.companyname.com and started a command prompt, from which I could issue the following commands:

net use e: \\dc3\userdata /user:emea\user1 password

(i.e. a connection to a resource in the original companyname.be domain, using an account in the emea.companyname.com domain, which as expected, allowed access to the share as well as browsing subject to file permissions on the original resources).

net use e: /del
net use e: \\dc3\userdata /user:emea\user2 password

(as expected, access was denied as the account was disabled).

net use e: /del
net use e: \\dc3\userdata /user:emea\user3 password

(as expected, a connection was made, but access was denied when an attempt was made to browse the share due to denying permissions to user3 on resources in the companyname.be domain).

net use e: /del

All of this indicated a successful migration from companyname.be to emea.companyname.com and so I decided to look a bit closer at the sIDHistory attribute which allows all of this to work.

One of my colleagues had alerted me to an article on security concerns for migrations and upgrades to Windows Active Directory, which confirmed that a single user account might have numerous sIDHistory entries, depending on how many domains contained the user name before the migration and consolidation.

After installing the ADSI Edit support tool from the Windows 2000 media I could see that the sIDHistory attribute had two values on the emea.companyname.com version of the object (shown in the accompanying screenshot), a single value on the transfer.local version of the object and was not present on the original companyname.be version.

Rather unhelpfully, the ADSI Edit representation of the sIDHistory is not in the usual form, but if the ldp.exe support tool is used, then by connecting to the server, binding as an administrator, and viewing the directory tree, the sIDHistory can be seen in its normal form along with the objectSID. As expected the objectSID for user1@companyname.be (S-15-78B99911-320A1743-74B49FF8-451) appeared as the sIDHistory attribute for user1@transfer.local and user1@emea.companyname.com had two values for sIDHistory – the original objectSID from user1@companyname.be (carried over in the sIDHistory from user1@transfer.local) and the objectSID from user1@transfer.local (S-15-11DA0ABB-64495118-320A1743-454).

Incidentally, had this method not worked, my colleagues and I had identified two further potential methods of migrating the users and groups which I did not try:

1. Install a second domain controller in companyname.be, let it replicate, take the original offline and seize the FSMO roles, then upgrade to Windows Server 2003 and rename the domain, allowing a one-step migration to to emea.companyname.com to be used. After this, the Windows Server 2003 domain controller could be taken offline and the original companyname.be Windows 2000 server brought back online (seen as a very complicated solution).
2. Use the clone principal utility to clone the original accounts in the new domain (workable, but requiring some scripting skills and potentially a lot of time).

After many hours of waiting for virtual machines to catch up with my mouse/keyboard, I don’t think I’ll be trying them just yet…

I picked up the following advice for troubleshooting application of group policy objects (GPOs) from John Howard at a recent Microsoft TechNet UK event and thought it might be useful if I posted it here:

1. Is the client operating system Windows 2000 or later? Group policy is not available with legacy clients.
2. Are computer and user accounts valid in the Active Directory (AD) domain? Group policy is not available with NT domains.
3. Are the accounts in the correct organizational unit (OU)?
4. Can clients access the sysvol share on the domain controller? GPOs are partly stored in AD, but also within sysvol.
5. Is AD replicating correctly? AD information and sysvol information are replicated via the file replication service (FRS).
6. What is the connectivity like between the client and the nearest domain controller (it may be useful to know that slow link detection relies on ICMP – if ICMP is disabled then this may cause some issues and further information is contained in Microsoft knowledge base article 816045).
7. Have changes been made to the default policies that may be causing issues? Microsoft recommend that the default policies are not changed, but instead to new policies created to override the defaults (policy precedence is discussed in the priority order for the application of GPOs post from September 2004.
8. Check DNS – Microsoft UK claim that 50% of the GPO calls received by their product support services (PSS) division are actually DNS issues.

If none of the above resolve the issue, then the issue is likely to be with a GPO itself and there are several tools available to assist with diagnosing this. The group policy modelling wizard and group policy results wizard (which includes WMI filtering) are both included within the group policy management console (GPMC), a free download from Microsoft which also provides reports on policy settings (discussed in the new features of Windows Server 2003 Active Directory post from February 2005). GPMC makes use of the resultant set of policy (RSoP) service to ascertain the policies that would have been applied. Although it is an older utility, the gpresult.exe command line tool (along with gpupdate.exe) is extremely useful for diagnosing the application of GPOs.

Unlike Windows NT domains, Active Directory (AD) domains have multiple masters and so all domain controller servers must be kept up-to-date with directory modifications made at other domain controllers. AD uses two forms of replication between domain controllers – directory replication is used for directory objects (users, computers, groups, etc.) and the file replication service (FRS) replicates sysvol items (login scripts, policies, etc.).

Microsoft provides a number of free tools for monitoring and troubleshooting the FRS and at a recent Microsoft TechNet UK event, John Howard demonstrated the sonar and ultrasound tools so I decided to dig a bit deeper into their potential use.

As described in Microsoft knowledge base article 815473, the FRS cannot propagate files that are open while the propagation code is running. So, if files in the sysvol director or files hosted with the distributed file system (DFS – which also uses the FRS) aren’t being replicated, it may be because a user or an application has the files open (e.g. a virus scanner, a disk optimisation tool, or a user profile). When the system encounters sharing violations in either of these situations, it doesn’t post an error message in the FRS event log stating that the file or files to be replicated were open and couldn’t be propagated, so there is a lack of diagnostic information about what went wrong.

The sonar utility (sonar.exe – taken from the Windows 2000 Server resource kit) can help troubleshoot file-sharing violations and other replication problems. Sonar monitors key replication statistics, including traffic levels, backlogs, and free space, providing feedback about any issues and optionally logging to a comma-separated value (.CSV) file.

Sonar is effectively a cut down version of the ultrasound utility, which installs WMI providers on replica members in an organisation and effectively acts as a domain controller replica with the WMI providers gathering FRS status information, which is polled and gathered by the ultrasound controller (the service component of the tool) and pushed into its own database for analysis. By using the user interface portion of ultrasound, known as the console, administrators can configure ultrasound to alert them via email of serious problems and use an incident log to keep track of changes or tasks they performed in response to alerts. Ultrasound can also be used to propagate test files.

Other tools include:

• The file replication service diagnostics tool (frsdiag.exe), which provides a graphical interface to help troubleshoot and diagnose problems with the FRS, gathering snap-shot information about the service, performing automated tests against that data, and compiling an overview of possible problems that may exist in the environment.
• ntfrsutl.exe, shipped with Windows Server 2003 and part of the Windows 2000 Server resource kit, which provides a snapshot view of the FRS internal state dumping the internal tables, thread and memory information for the FRS. It runs against local as well as remote servers but to access the internal information, the logged in user should have the required access on the following registry keys on the target server:
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntfrs\Parameters\Access Checks\Get Internal Information (Full control).
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntfrs\Parameters\Access Checks\Get Ds Polling Interval (Read).
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntfrs\Parameters\Access Checks\Set Ds Polling Interval (Full Control).

The FRS monitoring and troubleshooting tools also include a MOM management pack for the FRS, an FRS monitoring help file and both reporting and scripting packs for Ultrasound.

For directory replication there are two tools of particular use, both of which are available as support tools for installation from the Windows Server 2003 media:

• replmon.exe is the AD replication monitor, which allows an administrator to view the status of AD replication, to view the replication topology in a graphical format and to force replication between domain controller servers. Specifically, the AD replication monitor can be used to:
• See when a replication partner fails.
• View the history of successful and failed replication changes for troubleshooting purposes.
• View the properties of directory replication partners.
• Create applications or scripts to extract specific data from AD.
• View a snapshot of the performance counters on the computer, and the registry configuration of the server.
• Generate status reports that include direct and transitive replication partners, and detail a record of changes.
• Find all direct and transitive replication partners on the network.
• Display replication topology.
• Poll replication partners and generate individual histories of successful and failed replication events.
• Force replication.
• Trigger the knowledge consistency checker (KCC) to recalculate the replication topology.
• Display changes that have not yet replicated from a given replication partner.
• Display a list of the trust relationships maintained by the domain controller being monitored.
• Display the metadata of an AD object’s attributes.
• Monitor replication status of domain controllers from multiple forests.
• repadmin.exe is the replication diagnostics tool, whch assists administrators in diagnosing replication problems between domain controllers by allowing administrators to:
• View the replication topology as seen from the perspective of each domain controller.
• Manually create the replication topology (although in normal practice this should not be necessary as usually, the KCC manages the replication topology for each naming context).
• Force replication events between domain controllers
• View both the replication metadata and up-to-datedness vectors
• Monitor the relative health of an AD forest using the replsummary, showreps, showreps /csv, and showvector /latency operations to check for replication problems.

In the case of directory failure, some of the troubleshooting tools available include:

• dcdiag.exe – a support tool used to analyse domain controllers across the forest.
• netdom.exe – a support tool which can help in verifying domain trust relationships and replication credentials.
• ntdsutil.exe – provided with Windows 2000 and Windows Server 2003 for AD database maintenance, management of FSMO roles and clearing out unnecessary metadata (beware that this is an extremely powerful tool and should be used with care).