To the layperson, the title of this chapter may seem like a hodgepodge of unrelated terms. For the seasoned Active Directory administrator, however, these terms represent the most fundamental and, perhaps, most important concepts within Active Directory. In simple terms, a forest is a collection of data partitions and domains; a domain is a hierarchy of objects in a data partition that is replicated between one or more domain controllers; and a trust is an agreement between two domains or forests to allow security principals (i.e., users, groups, and computers) from one domain or forest to access resources in the other domain or forest.
Active Directory domains are named using the Domain Name System (DNS) namespace. You can group domains that are part of the same contiguous DNS namespace within the same domain tree. For example, the marketing.adatum.com, sales.adatum.com, and adatum.com domains are part of the adatum.com domain tree. A single domain tree is sufficient for most implementations, but one example in which multiple domain trees might be necessary is with large conglomerate corporations. Conglomerates are made up of multiple individual companies in which each company typically wants to maintain its own identity and, therefore, its own namespace. If you need to support noncontiguous namespaces within a single forest, you will need to create multiple domain trees. For example, adatum.com and treyresearch.com can form two separate domain trees within the same forest.
Assuming that each company within the conglomerate wants its Active Directory domain name to be based on its company name, you have two choices for setting up this type of environment. You could either make each company’s domain(s) a domain tree within a single forest, or you could implement multiple forests. One of the biggest differences between the two options is that all the domains within the forest trust each other, whereas separate forests, by default, do not have any trust relationships set up between them. Without trust relationships, users from one forest cannot access resources located in the other forest. In our conglomerate scenario, if you want users in each company to be able to access resources within their own domain, as well as the domains belonging to other companies in the organization, using separate domain trees can create an easier approach than separate forests. However, it’s important to keep in mind when designing your network that forests form the security boundary for Active Directory, as we’ll cover in the next section. This is because transitive trusts are established between the root domains of each domain tree within a forest. As a result, every domain within a forest, regardless of which domain tree it is in, is trusted by every other domain. Figure 2-1 illustrates an example with three domain trees in a forest called adatum.com.
Each domain increases the support costs of Active Directory due to the need for maintaining additional domain controllers, as well as the time you must spend configuring and maintaining the domain. When designing an Active Directory forest, your goal should be to keep the number of domains that you deploy to an absolute minimum. Since the forest constitutes the security boundary for an Active Directory environment, the minimalist approach toward the number of domains you use in an AD design becomes all the more sensible.
With Windows 2000, if you implement the alternative approach and create multiple Active Directory forests, you would have to create individual trusts between the domains in every forest to create the fully trusted model. This can get out of hand pretty quickly if there are numerous domains. Fortunately, with Windows Server 2003 and newer versions, you can use a trust type called a cross-forest trust to create a single transitive trust between two forest root domains. This single trust allows all of the domains in both forests to fully trust one another.
Note
There are many more issues to consider when deciding how many forests, domains, and domain trees to implement. For a thorough explanation of Active Directory design considerations, we recommend reading Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly).
In this chapter, we cover the most common tasks that you would need to do with forests, domains, and trusts. First, we’re going to review how each item is represented within Active Directory.
A forest is a logical structure that is a collection of one or more interconnected domains, plus the configuration and schema naming contexts, as well as any application partitions that have been configured. This means that all domains in a forest share a common configuration and schema between them. Forests are considered the security boundary in Active Directory; by this we mean that if you need to definitively restrict access to a resource within a particular domain so that administrators from other domains do not have any access to it whatsoever, you need to implement a separate forest instead of using an additional domain within the current forest. This security concern is due to the transitive trust relationship that exists between all domains in a forest, the writable naming contexts (NCs) that exist on all domain controllers in a forest, and the extensive rights and permissions that are granted to members of the Administrators group. In the earliest days of Windows 2000 Active Directory, Microsoft advocated an “empty forest root” design with the intention of protecting the enterprise-wide security principals in the forest root domain from being accessible by domain administrators in the child domains. However, subsequent discoveries have indicated that it is in fact the forest, not the domain, that truly provides security separation between distinct groups of resources and administrators.
Active Directory relies on naming contexts to divide the AD database into separate partitions, each of which contains information that is replicated together as a logical unit. At a minimum, an Active Directory forest consists of three naming contexts: the Domain NC for the forest root domain, the Configuration NC, and the Schema NC. Here is a description of the types of partitions that can be part of a forest:
- Configuration NC
This contains data that is applicable across all domains in a forest, and thus is replicated to all domain controllers in the forest. Some of this data includes the site topology, list of partitions, published services, display specifiers, and extended rights.
- Schema NC
This contains the objects that describe how data can be structured and stored in Active Directory. The
classSchemaobjects in the Schema NC represent class definitions for objects. TheattributeSchemaobjects describe what data can be stored with classes. The Schema NC is replicated to all domain controllers in a forest.- Domain NC
A domain is a naming context that holds domain-specific data, including user, group, and computer objects. This forms a collection of objects that is replicated between one or more domain controllers.
- Application partitions
These are configurable partitions that can be rooted anywhere in the forest and can be replicated to any domain controller in the forest, or to a subset of domain controllers. These are not available with Windows 2000.
The Partitions container in the
Configuration NC contains the complete list of all partitions associated
with a particular forest.
Although forests constitute the security boundary in an Active Directory environment, you can split up your AD infrastructure into separate domains to create smaller administrative or replication boundaries within a large-scale network. In Active Directory, domains can also constitute a policy boundary, as certain Group Policy settings such as password policies and account lockout policies can be applied only to domain user accounts at the domain level. However, Windows Server 2008 introduced the concept of a Fine-Grained Password Policy, which allows administrators to configure multiple password and account lockout policies within a single domain.
Domains are represented in Active Directory by domainDNS objects. The distinguished name (DN)
of a domainDNS object directly
corresponds to the fully qualified DNS name of the domain. For example,
the amer.adatum.com domain would have a DN of
dc=amer,dc=adatum,dc=com.
In Active Directory, each domain is a naming context and is also
represented under the Partitions
container in the Configuration NC as a crossRef object, which allows each domain
controller in a forest to be aware of every partition in the forest and
not just those that are held by one particular DC. In this case, the
relative distinguished name (RDN) of the crossRef object is the NetBIOS name of the
domain as defined by the netBIOSName
attribute of the domain object.
In our previous example of amer.adatum.com,
the corresponding crossRef object for
the domain (assuming the forest name was
adatum.com) would be located at cn=AMER,cn=Partitions,cn=Configuration,dc=adatum,dc=com.
Microsoft has relied on trust relationships to provide resource access across domain boundaries since the early days of Windows NT. Before Active Directory, all trust relationships were one-way and nontransitive in nature. A one-way trust relationship, as the name suggests, enables resource access only in a single direction: a single trust relationship will enable resource access only from DomainA to DomainB, but a separate trust would need to be created to enable access in the other direction. A nontransitive trust relationship means that if you create a trust from DomainA to DomainB and a second one from DomainB to DomainC, DomainA does not trust DomainC by default. This one-way nontransitive trust relationship was the only type that was available in Windows NT. Active Directory improved on this by automatically creating two-way transitive trust relationships between every parent and child domain in a domain tree, and between the root domains of all trees in every forest. Thus, all of the domains in a forest effectively trust all of the other domains in the forest.
Trusts are stored as trustedDomain objects within the System container of a domain. Table 2-1 lists some of the
important attributes of trustedDomain
objects.
Table 2-1. Attributes of trustedDomain objects
Attribute | Description |
|---|---|
| Relative distinguished name of the trust. This is the name of the target domain that is trusted. For Windows NT domains, it is the NetBIOS name. For Active Directory domains, it is the DNS name. |
| Flag that indicates whether the trust is disabled, inbound, outbound, or both inbound and outbound. See Recipes and for more information. |
| Flag that indicates if the trust is to a down-level (NT4), up-level (Windows 2000 or later), or Kerberos (e.g., MIT) domain. See Viewing the Trusts for a Domain for more information. |
| Contain miscellaneous properties that can be enabled for a trust. See Viewing the Trusts for a Domain for more information. |
| The name of the trust partner. See Viewing the Trusts for a Domain for more information. |
A trust also has a corresponding user object in the Users container of a domain. This is where the
trust password is stored. The RDN of this user object is the same as the cn attribute for the corresponding trustedDomain object with a $ appended.
On a Windows Server 2008 R2 computer:
Open the Server Manager utility. In the lefthand pane, click Roles.
In the righthand pane, click Add Roles.
Click Next. Place a checkmark next to Active Directory Domain Services.
Click Next, click Add Required Features if applicable, click Next twice, and then click Install.
Click Close and then click the Active Directory Domain Services link in the left pane.
In the righthand pane, click the “Run the Active Directory Domain Services Installation Wizard (dcpromo.exe)” link.
Click Next twice to continue. Click the “Create a new domain in a new forest” radio button and click Next.
Follow the rest of the configuration steps to complete the wizard.
On a Windows Server 2012 computer:
Add the Active Directory Domain Services role. After the role installation, a notification will appear within Server Manager.
Click Notifications, and then click “Promote this server to a domain controller.”
The Active Directory Domain Services Configuration Wizard will appear.
Click “Add a new forest.”
Enter the root domain name and then click Next.
Select the forest and domain functional levels or leave the defaults of Windows Server 2012.
Confirm the options to install a DNS server and a global catalog server (not optional for a new forest and a new forest root domain).
Enter the Directory Services Restore Mode (DSRM) password and then click Next.
Specify the DNS delegation creation, if necessary, and then click Next.
Verify the NetBIOS domain name and then click Next.
Specify the location of the database, or accept the defaults, and then click Next.
Review the selections given while using the wizard. Optionally, click “View script” to see the PowerShell command and then click Next.
After the prerequisites have been successfully validated, click Install to begin the process. After promotion, the server will automatically reboot.
The Install-ADDSForest cmdlet
is used to create a new forest, as shown in the following examples.
The first example installs a new forest, a new forest root domain, and
DNS.
> Install-ADDSForest -DomainName <DomainName> -InstallDNSThe following example installs a new forest, installs a new forest root domain, sets the file locations, sets the domain and forest functional levels, and installs DNS.
> Install-ADDSForest -DatabasePath "D:ADDSDB" -DomainMode "Win2012"↵ -DomainName <DomainName> -DomainNetBIOSName <NetBIOSName> -ForestMode↵ "Win2012" -InstallDNS:$true -LogPath "E:ADDSlogs" -SYSVOLPath↵ "F:ADDSSYSVOL" -Force:$true
The act of creating a forest consists of creating a forest root domain. To do this, you need to promote a Windows Server 2008 R2 or Windows Server 2012 server to be a domain controller for a new domain. When using the GUI method, the promotion process has a wizard interface that requires you to answer several questions about the forest and domain into which you want to promote the server. After it finishes, you will be asked to reboot the computer to complete the promotion process. When using the PowerShell method, the only information needed after running the PowerShell command is the desired Directory Services Restore Mode (DSRM) password.
As you have probably noticed since Windows Server 2008, Microsoft has changed the nomenclature surrounding Active Directory. What used to simply be called “Active Directory” is now “Active Directory Domain Services,” as a number of other server services have been rebranded under the Active Directory umbrella, including Active Directory Certificate Services, Active Directory Rights Management Services, Active Directory Federated Services, and Active Directory Lightweight Directory Services.
“Install a New Windows Server 2012 Active Directory Forest (Level 200)”; Automating the Promotion or Demotion of a Domain Controller for automating the promotion of a domain controller; MS KB 238369 (How to Promote and Demote Domain Controllers in Windows 2000); MS KB 324753 (How to Create an Active Directory Server in Windows Server 2003)
You want to tear down a forest and decommission any domains contained within it because you no longer need it.
To remove a forest, you need to demote all the domain controllers in the forest. When you demote an existing domain controller, you will be given the option to demote the machine to a member server (unless the domain controller is the last domain controller in the domain, in which case the server will become part of a workgroup instead). After that is completed, and depending on how your environment is configured, you may need to remove WINS and DNS entries that were associated with the domain controllers and domains, unless they were automatically removed via WINS deregistration and dynamic DNS (DDNS) during demotion. The following commands can help determine if all entries have been removed:
> netsh wins server \<WINSServerName>show name<DomainNetBiosName>1b > netsh wins server \<WINSServerName>show name<DomainNetBiosName>1c > nslookup<DomainControllerDNSName>> nslookup -type=SRV _ldap._tcp.dc._msdcs.<ForestDNSName>> nslookup<ForestDNSName>
Note
You should run the first two commands for every domain in the forest if the forest contained more than one. The preceding list is not meant to be exhaustive, so be sure to check DNS across all domains and watch for entries for RODCs, if the domain controller that was demoted was an RODC.
The method described in this solution is the graceful way to tear down a forest. You can also use a brute-force method to remove a forest by simply reinstalling the operating system on all domain controllers in the forest. This method is not recommended except in lab or test environments. You’ll also need to make sure any DNS resource records for the domain controllers are removed from your DNS servers since the domain controllers will not dynamically remove them like they do during the demotion process.
You will also want to remove any trusts that have been established for the forest (see Removing a Trust for more details). For more information on how to demote a domain controller, see Demoting a Domain Controller.
Note
To fully remove all traces of an Active Directory forest in Windows Server 2008 and later, you should also remove the Active Directory Domain Services role that has been installed on any of the domain controllers. This will remove the actual system files associated with the AD DS server role. You may also want to remove any associated infrastructure roles from the servers in question, such as the DNS server role or the WINS server role. If you need to forcibly remove a single domain from an AD forest, you can also use the ntdsutil command-line utility; see Removing a Domain for more information.
Viewing the Trusts for a Domain for viewing the trusts for a domain; Removing a Trust for removing a trust; Demoting a Domain Controller for demoting a domain controller
You want to create a new domain that may be part of an existing domain tree or the root of a new domain tree.
On Windows Server 2008 R2, add the Active Directory Domain Services role and then run dcpromo from a command line. Place a checkmark next to “Use advanced mode installation.” You can then select one of the following:
Existing forest
Create a new domain in an existing forest
Create a new domain tree root instead of a new child domain
Create a new domain in a new forest
On Windows Server 2012, add the Active Directory Domain Services role. After the role installation completes, a notification will appear within Server Manager. Click Notifications and then click “Promote this server to a domain controller.” The Active Directory Domain Services Configuration Wizard appears. Select the desired deployment operation (“Add a domain controller to an existing domain,” “Add a new domain to an existing forest,” or “Add a new forest”). Then, configure the remaining options in the wizard to complete the process.
The Install-ADDSDomain cmdlet
is used to create a new domain. The following example installs a new
child domain in an existing forest and installs DNS:
> Install-ADDSDomain -NewDomainName <newdomainname> -ParentDomainNamecontoso.com; -DomainMode Win2012 -DomainType ChildDomain -InstallDNS:$true -NewDomainNetBiosName <newNetBIOSname>
Note that the Install-ADDSDomain cmdlet is available only
if the Active Directory Domain Services role has been installed on the
server where the cmdlet will be run.
The options to create a new domain allow you a great deal of flexibility in creating an Active Directory infrastructure that maps to your organization’s business requirements. You can add a new domain to an existing domain tree, or else create a new domain tree entirely. If you want to create a new domain that is a child domain of a parent domain (for example, contained within the same contiguous namespace), then you are creating a domain in an existing domain tree. If you are creating the first domain in a forest or a domain that is outside the namespace of the forest root, then you are creating a domain in a new domain tree. For example, if you have already created the treyresearch.com domain and then you install the first DC in the amer.treyresearch.com domain, then amer.treyresearch.corp is a child domain. Conversely, if you want to create a domain that is part of the treyresearch.com forest but uses an entirely different naming convention (such as treyresearchasia.com), then you are creating a new domain tree within an existing forest.
Promoting a Server to a Domain Controller for promoting a domain controller; Automating the Promotion or Demotion of a Domain Controller for automating the promotion or demotion of a domain controller
You want to remove a domain from a forest. You may need to remove a domain during test scenarios or if you are collapsing or reducing the number of domains in a forest.
Removing a domain consists of demoting each domain controller in the domain, which can be accomplished by running the Remove Roles and Features Wizard on the domain controllers and following the steps to demote the domain controllers. For the last domain controller in the domain, be sure to select the “Last domain controller in the domain” option in the wizard so that the objects associated with the domain get removed. If you do not select this option for the last domain controller in the domain, take a look at Removing an Orphaned Domain for how to remove an orphaned domain.
Note
If the domain you want to remove has child domains, you must remove the child domains before proceeding.
You can also demote domain controllers by using PowerShell, as shown in the following example:
> Uninstall-ADDSDomainController -LastDomainControllerInDomain -RemoveApplicationPartitions
In the preceding example, two optional parameters have been
specified. The -LastDomainControllerInDomain
parameter is used when demoting the last domain controller,
while the -RemoveApplicationPartitions parameter should
be specified to delete all data associated with any application
partitions in the domain.
After all domain controllers have been demoted, depending on how your environment is configured you may need to remove any WINS and DNS entries that were associated with the domain controllers and domain that were automatically removed via WINS deregistration and DDNS during the demotion process. The following commands can help determine if all entries have been removed:
> netsh wins server \<WINSServerName>show name<DomainNetBiosName>1b > netsh wins server \<WINSServerName>show name<DomainNetBiosName>1c > nslookup<DomainControllerName>> nslookup -type=SRV _ldap._tcp.dc._msdcs.<DomainDNSName>> nslookup<DomainDNSName>
You will also want to remove any trusts that have been established for the domain (see Removing a Trust for more details). For more information on how to demote a domain controller, see Demoting a Domain Controller.
The brute-force method for removing a forest, as described in the discussion for Removing a Forest, is not a good method for removing a domain. Doing so will leave all of the domain controller and server objects, along with the domain object and associated domain naming context, hanging around in the forest. If you used that approach, you would eventually see numerous replication and file replication service errors in the event log caused by failed replication events from the nonexistent domain. You would need to remove the metadata associated with the removed domain using ntdsutil to correct these errors.
To fully remove all traces of an Active Directory forest in Windows Server 2008 and later, you should also remove the Active Directory Domain Services role that has been installed on any of the Windows Server 2008 or later domain controllers. This will remove the actual system files associated with the AD DS server role. You may also want to remove any associated infrastructure roles from the servers in question, such as the DNS server role or the WINS server role.
Removing a Forest; Removing an Orphaned Domain; Viewing the Trusts for a Domain for viewing the trusts for a domain; Removing a Trust for removing a trust; Demoting a Domain Controller for demoting a domain controller; and TechNet for details on removing Active Directory Domain Services
You want to completely remove a domain that was orphaned because the domain was forcibly removed, or the last domain controller in the domain failed or was otherwise decommissioned improperly.
The following commands will forcibly remove an orphaned domain
from a forest. Replace
<DomainControllerName> with the
hostname of the Domain Naming Master Flexible Single Master Operation
(FSMO; pronounced fiz-mo) for the
forest.
1 NTDSUTIL 2 metadata cleanup 3 connections 4 connect to server<DomainControllerName>5 quit 6 select operation target 7 list sites 8 select site<# of site>9 list servers in site 10 select server<# of domain controller>11 list domains 12 select domain<# of domain>13 quit 14 remove selected server (confirm when prompted) 15 list naming context 16 select naming context<# of the DNS Naming Context>17 quit 18 remove selected naming context (confirm when prompted) 19 select operation target 20 list naming context 21 select naming context<# of the domain DN>22 quit 23 remove selected naming context (confirm when prompted)
Removing an orphaned domain consists of removing the domain object
for the domain (e.g., dc=emea,dc=adatum,dc=com), all of its child
objects, and the associated crossRef
object in the Partitions container.
You need to target the Domain Naming FSMO when using
ntdsutil because that server is responsible for
creation and removal of domains.
Before you can use ntdsutil to remove an
orphaned domain, you must first forcibly remove any domain controllers
in that domain that were not gracefully demoted. (Forcibly removing
individual domain controllers will be discussed in Chapter 3.) You must also
remove the DomainDNSZones application
partition associated with the orphaned domain, if this was not
gracefully removed. (Forcibly removing the DomainDNSZones application partition will be
discussed in Chapters 13 and 17.)
Removing an Unsuccessfully Demoted Domain Controller for removing
an unsuccessfully demoted domain controller; MS KB 230306 (How to Remove
Orphaned Domains from Active Directory); MS KB 251307 (How to Remove
Orphaned Domains from Active Directory Without Demoting the Domain
Controllers); MS KB 255229 (Dcpromo Demotion of Last Domain Controller
in Child Domain Does Not Succeed); Chapter 3 for information on
performing a metadata cleanup of individual domain controllers; Chapters
13 and
17 for information on manually removing
the DomainDNSZones application
partition
Open the Active Directory Domains and Trusts snap-in (domain.msc). The list of the domains in the default forest can be browsed in the left pane.
If you want to view the domains for a forest other than the one you are logged in to, right-click on Active Directory Domains and Trusts in the left pane and select Change Forest. Enter the forest root domain name in which you want to browse. In the left pane, expand the forest root domain to see any subdomains.
Finding the Domain Controllers for a Domain for finding the domain controllers for a domain
You want to find the NetBIOS name of a domain. Although Windows
primarily uses DNS for name resolution, the NetBIOS name of a domain is
still important. Some users still rely on the NetBIOS name to log on to
a domain or to applications by using the down-level logon name. The
down-level logon name uses the
<domainname><username>
format.
Open the Active Directory Users and Computers snap-in.
Right-click the domain you want to view in the left pane and select Properties.
The NetBIOS name will be shown in the “Domain name (pre-Windows 2000)” field.
You can also retrieve this information by using the Active Directory Administrative Center, as follows:
Open the Active Directory Administrative Center.
Right-click the domain in the left pane and then select Properties. The NetBIOS name will be shown in the “Pre-Windows 2000 domain name” field.
Obtaining the NetBIOS name of a domain is easier today than it was
before the introduction of the Active Directory module for Windows
PowerShell. Prior to the module, third-party PowerShell modules had to
be used, and the solution was a multiline PowerShell script. Today, we
have the Get-ADDomain cmdlet, which
outputs 29 properties. Running the Get-ADDomain cmdlet without specifying the
desired property will show the output with all 29 properties.
The NetBIOS name of a domain is often referred to with alternative
names. In the command-line example in this recipe, Windows uses the
USERDOMAIN environment variable to
store the NetBIOS name of the domain to which the user logged on. By
running just the set command, you can
display all of the Windows environment variables. This can be helpful
when you need to find out if specific information is already stored
within an environment variable.
You want to rename a domain—for example, due to organizational changes, due to legal restrictions, or because of a merger, acquisition, or divestiture. Renaming a domain is a very involved process and should be done only when absolutely necessary. Changing the name of a domain can have an impact on everything from DNS, replication, and GPOs to DFS and Certificate Services. A domain rename also requires rebooting all domain controllers, member servers, and client computers in the domain!
A domain rename procedure is supported if a forest is running Windows Server 2003 domain controllers or later and is at the Windows Server 2003 forest functional level or later. Microsoft provides a rename tool (rendom.exe) that is used for the process. Here are the commands for a domain rename in Server 2012:
1 rendom /list (this command will produce a file named DomainList.xml) 2 Edit DomainList.xml (Change the domain name to the desired name.) 3 rendom /upload 4 rendom /prepare 5 rendom /execute 6 gpfixup /olddns:adatum.com /newdns:contoso.com 7 gpfixup /oldnb:adatum /newnb:contoso 8 rendom /end
We highly recommend reading additional material on TechNet before attempting the procedure, as well as attempting the procedure in a test lab before performing it against a production environment.
The domain rename process can accommodate very complex changes to your domain model. You can perform the following types of renames:
Rename a domain to a new name without repositioning it in the domain tree.
Reposition a domain within a domain tree.
Create a new domain tree with a renamed domain.
One thing you cannot do with the domain rename procedure is to reposition the forest root domain. You can rename the forest root domain, but you cannot change its status as the forest root domain. Another important limitation to note is that you cannot rename any domain in a forest that has had Exchange 2007 or Exchange 2010 installed, though an environment with Exchange Server 2003 SP1 is capable of handling domain renames. The rendom.exe utility also includes the gpfixup.exe utility, which corrects references to Group Policy objects after the domain name changes. When working with Exchange 2003, you can also use the xdr-fixup tool to correct Exchange attributes to match the new domain name.
You want to change the functional level of a Windows Server 2008 R2 Active Directory domain to the Windows Server 2012 functional level.
Since Windows Server, Active Directory functional levels have
replaced the domain mode that was used in Windows 2000 to signify what
operating systems are allowed to run on the domain controllers in the
domain. With Windows Server 2003 and later, there are functional levels
for both domains and forests, whereas with Windows 2000, the domain mode
applied only to domains. The msDS-Behavior-Version attribute of the
domainDNS object (e.g., dc=amer,dc=adatum,dc=com) holds the current
domain functional level. Table 2-2 shows the six
functional levels, their associated msDS-Behavior-Version values, and the
operating systems that can be used on domain controllers in
each.
Table 2-2. Active Directory domain functional levels
Functional level |
| Valid operating systems for domain controllers |
|---|---|---|
Windows Server 2003 | 2 | Windows Server 2003 and later |
Windows Server 2008 | 3 | Windows Server 2008 and later |
Windows Server 2008 R2 | 4 | Windows Server 2008 R2 and later |
Windows Server 2012 | 5 | Windows Server 2012 |
Various new features of Active Directory are enabled with each domain functional level. See Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly) for more details.
The value contained in msDS-Behavior-Version is mirrored in the
attribute domainFunctionality of the
RootDSE. That means you can perform anonymous queries against the
RootDSE of a domain to quickly determine its current functional
level.
Note
One of the benefits of the GUI solution is that if a problem is encountered, you can save and view the output log, which will contain information on any errors that were found.
You want to raise the functional level of a forest to Windows Server 2012. You should raise the functional level to take advantage of the new features and enhancements available in the latest functional level.
Open the Active Directory Domains and Trusts snap-in (domain.msc).
In the left pane, right-click on Active Directory Domains and Trusts and select Raise Forest Functional Level.
Ensure that “Windows Server 2012” is displayed in the available forest functional level drop-down list and then click Raise. A warning dialog box will appear that mentions that the process may not be reversible. Click OK to proceed.
After a few seconds, you should see a message stating whether the operation was successful.
The Windows Server 2012 forest functional level is very similar to a domain functional level. Even if just one of the domains in the forest is at the domain functional level of Windows Server 2008 R2, you cannot raise the forest above the Windows Server 2008 R2 forest functional level. If you attempt to do so, you will receive an error that the operation cannot be completed. After you raise the last Windows Server 2008 R2 domain functional level to Windows Server 2012, you can then raise the forest functional level as well.
You may be wondering why there is a need to differentiate between forest and domain functional levels. The primary reason is new features. Some new features of Windows Server 2008 R2 require that all domain controllers in the forest are running the appropriate operating system. To ensure that all domain controllers are running a certain operating system throughout a forest, Microsoft had to apply the functional-level concept to forests as well as domains. Windows Server 2012 requires a minimum forest functional level of Windows Server 2003. The Windows Server 2012 forest functional level does not offer any new features, although the Windows Server 2012 domain functional level does offer a couple of new Kerberos authentication options.
The forest functional level is stored in the msDS-Behavior-Version attribute of the
Partitions container in the
Configuration NC. For example, in the adatum.com
forest, it would be stored in cn=partitions,cn=configuration,dc=adatum,dc=com.
The value contained in msDS-Behavior-Version is mirrored to the
forestFunctionality attribute of the
RootDSE, which means you can find the functional level of the forest by
querying the RootDSE.
Note
One of the benefits of the GUI solution is that if a problem occurs, you can save and view the output log, which will contain information on any errors that were encountered.
“Upgrade Domain Controllers to Windows Server 2012” for information about the forest and domain functional levels and other prerequisites; Using AdPrep to Prepare a Domain or Forest for Windows Server 2012 for preparing a forest with AdPrep
You can run the AdPrep tool, which extends the schema and adds several objects in Active Directory. For instance, to prepare a domain or forest for a Windows Server 2012 upgrade, you can first run the following command on the Schema FSMO with the credentials of an account that is in both the Enterprise Admins and Schema Admins groups:
> adprep /forestprep
After the updates from /forestprep have replicated throughout the
forest (see Raising the Functional Level of a Windows Server 2008 or 2008 R2
Forest),
run the following command on the Infrastructure FSMO in each domain with
the credentials of an account in the Domain Admins
group:
> adprep /domainprep
If the updates from /forestprep
have not replicated to at least the Infrastructure FSMO servers in each
domain, an error will be returned when running /domainprep. To debug any problems you
encounter, check out the AdPrep logfiles located at
%SystemRoot%System32DebugAdprepLogs.
Note
AdPrep can be found in the supportadprep directory on the Windows Server 2012 installation media. The tool relies on several files in that directory, so you cannot simply copy that file out to a server and run it. You must run it from a CD or from a location where the entire directory has been copied.
To prepare to add the first Windows Server 2012 domain controller to an existing domain, you will need to run the version of AdPrep contained on Windows Server 2012 installation media. The preparation also includes a third AdPrep switch that will update permissions on existing Group Policy Objects (GPOs) to allow for updated functionality in the Group Policy Management Console (GPMC):
> adprep /domainprep /gpprep
The Windows Server 2012 preparation, in addition to /forestprep, /domainprep, and /domainprep /gpprep, also includes /rodcprep to allow for the installation of
Read-Only Domain Controllers (RODCs), which we will discuss in Chapter 3.
The adprep command prepares a
forest and domains for Windows Server 2012. Both /forestprep and /domainprep must be run before you can upgrade
any domain controllers to Windows Server 2012 or install new Windows
Server 2012 domain controllers.
The adprep command serves a
similar function to the Exchange 2010 setup /forestprep and /domainprep commands, which prepare an Active
Directory forest and domains for Exchange 2010. The adprep /forestprep command extends the schema
and modifies some default security descriptors, which is why it must run
under the credentials of someone in both the Schema
Admins and Enterprise Admins groups. In
addition, the adprep /forestprep and
/domainprep commands add new objects
throughout the forest.
Note
Although not mandatory, it is helpful to run /domainprep from the server hosting the
Infrastructure Master FSMO since this is the DC that controls the
/domainprep process.
Raising the Functional Level of a Windows Server 2008 or 2008 R2 Forest; Determining Whether AdPrep Has Completed for determining whether AdPrep has completed; the Microsoft TechNet site for information about the Windows Server 2008 AdPrep process
You want to determine whether the AdPrep process, described in Using AdPrep to Prepare a Domain or Forest for Windows Server 2012, has successfully prepared a domain or forest for Windows Server 2012. After AdPrep has completed, you will then be ready to start promoting Windows Server 2012 domain controllers.
To determine whether adprep
/forestprep has completed for a Windows Server 2012 upgrade,
run ADSI Edit and then follow these steps:
In the left pane, right-click on ADSI Edit and then click Connect To.
In the Connection Settings window, click the “Select a well known Naming Context” radio button and then click Schema.
In the left pane, double-click “Schema [<FQDN of domain controller>]”.
Right-click the DN of the schema and then click Properties.
Read the value of the
objectVersionattribute. If theobjectVersionattribute shows a value of 56, then theadprep /forestprepcommand completed successfully.
To determine whether adprep
/domainprep has completed for a Windows Server 2012 upgrade,
run ADSI Edit and then follow these steps:
In the left pane, right-click on ADSI Edit and click Connect To.
In the Connection Settings window, click the “Select a well known Naming Context” radio button, and then click “Default naming context.”
In the left pane, double-click “Default naming context [<FQDN of domain controller>].”
Expand the DN of the domain.
Expand the
CN=Systemcontainer.Expand the
CN=DomainUpdatescontainer.Right-click on
CN=ActiveDirectoryUpdateand then click Properties.Read the value of the
revisionattribute. If therevisionattribute has a value of 9, then theadprep /domainprepcommand completed successfully.
As described in Using AdPrep to Prepare a Domain or Forest for Windows Server
2012, the AdPrep utility is
used to prepare an Active Directory forest for the upgrade to Windows
Server 2012. One of the nice features of AdPrep is that it stores its
progress in Active Directory. For /forestprep, the objectVersion attribute of the schema
indicates the level of the forest. For /domainprep, a container with a distinguished
name of cn=DomainUpdates,cn=System,<DomainDN>
is created. After all of the operations have completed successfully, the
objectVersion attribute should show a
value of 56 (see Figure 2-2).
Figure 2-2. ADSI Edit showing the objectVersion attribute of an AD DS
forest that was updated to Windows Server 2012 by running
adprep /forestprep
For /domainprep, a container
with a distinguished name of cn=ActiveDirectoryUpdate,cn=DomainUpdates,cn=System,<DomainDN>
is created. After all of the operations have completed successfully, the
revision attribute of the ActiveDirectoryUpdate object should show a
value of 9 (see Figure 2-3).
Using AdPrep to Prepare a Domain or Forest for Windows Server 2012 for running AdPrep; the Microsoft TechNet site for additional information about the Windows Server 2012 AdPrep process
You want to determine whether a domain controller is ready to be upgraded to Windows Server 2003 or Windows Server 2008.
For Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012, download and run the Microsoft Assessment and Planning Solution Accelerator from the Microsoft website, which will generate upgrade readiness reports to help your organization prepare for an upgrade to Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012.
Prior to Windows Server 2008, the WINNT32 command with the
/checkupgradeonly switch could be
used to assess whether a domain controller could be upgraded. Windows
Server, since 2008, has eliminated the /checkupgradeonly switch in the installation
media, instead opting to provide a free inventory and analysis tool in
the form of the Microsoft Assessment and Planning (MAP) tools.
You want to create a one-way or two-way nontransitive trust from an AD domain to a Windows NT domain, or to a domain within an untrusted Active Directory forest.
Open the Active Directory Domains and Trusts snap-in (domain.msc).
In the left pane, right-click the forest root domain and select Properties.
Click on the Trusts tab.
Click the New Trust button. Then click Next.
Enter the name of the domain and then click Next.
Verify that External trust is selected and then click Next.
Verify that a two-way trust direction is selected and then click Next.
Verify that “This domain only” is selected to create the trust and then click Next.
Verify that “Domain-wide authentication” is selected and then click Next.
Enter a complex password for the trust password and then click Next. Note that the password must meet the domain password policy.
Review the trust settings summary and then click Next.
A message indicating that the trust relationship was created successfully will appear. Click Next to configure the new trust.
Perform the same steps on the trusted domain. Then, on both sides, select Yes to confirm the incoming trust and then click Next.
A success message will appear. Click Finish.
A message will appear from AD DS that mentions that security identifier (SID) filtering is enabled. Click OK.
The external trust should now appear in the Trusts tab of the domain properties.
> netdom trust TrustingDomainName/d:TrustedDomainName/add
For example, to create a trust from the NT4 domain ADATUM_NT4 to the AD domain ADATUM, use the following command:
> netdom trust ADATUM_NT4 /d:ADATUM /add↵ /UserD:ADATUMadministrator /PasswordD:*↵ /UserO:ADATUM_NT4administrator /PasswordO:*
You can make the trust bidirectional (i.e., two-way) by adding a
/TwoWay switch to the
example.
It is common when migrating a single domain within a large, multidomain forest, as in the case of a corporate merger or divestiture, to set up trusts to down-level master account domains or resource domains, or to create a trust relationship with a single AD domain in a remote, untrusted forest. This allows AD users to access resources in the remote domain without providing alternate credentials. In the case of a remote Active Directory forest, you might choose to establish an external trust in order to limit access to and from only the specific domain that you specify, rather than allowing implicit access between all domains on both sides of a transitive trust. In the GUI solution, each side of the trust is completed independently to simulate a typical real-world situation where a distinct administrative team manages each side of the trust.
“Understanding When to Create an External Trust” for details about external trusts; “Understanding Trust Types” for a detailed explanation of the available trust types
Warning
This recipe requires at least the Windows Server 2003 forest functional level in both forests.
You want to create a transitive trust between two AD forests. This causes all domains in both forests to trust each other without the need for additional trusts.
Open the Active Directory Domains and Trusts snap-in (domain.msc).
In the left pane, right-click the forest root domain and select Properties.
Click on the Trusts tab.
Click the New Trust button. Then click Next.
Enter the name of the domain and then click Next.
Select Forest Trust and then click Next.
Verify that a two-way trust direction is selected and then click Next.
Verify that “This domain only” is selected to create the trust and then click Next.
Verify that “Domain-wide authentication” is selected and then click Next.
Enter a complex password for the trust password and then click Next. Note that the password must meet the domain password policy.
Review the trust settings summary and then click Next.
A message indicating that a trust relationship was created successfully will appear. Click Next to configure the new trust.
Perform the same steps on the trusted domain. Then, on both sides, select Yes to confirm the incoming trust and then click Next.
A success message will appear. Click Finish.
The trust should now appear in the Trusts tab of the domain properties.
> netdom trust<Forest1DNSName>/Domain:<Forest2DNSName>/Twoway /Transitive↵ /ADD [/UserD:<Forest2AdminUser>/PasswordD:*]↵ [/UserO:<Forest1AdminUser>/PasswordO:*]
For example, to create a two-way forest trust from the AD forest adatum.com to the AD forest othercorp.com, use the following command:
> netdom trust adatum.com /Domain:othercorp.com /Twoway /Transitive
/ADD /UserD:[email protected] /PasswordD:*↵
/UserO:administrator@adatum.com /PasswordO:*↵A new type of trust called a forest trust was introduced in Windows Server 2003. With a forest trust, you can define a single one-way or two-way transitive trust relationship that extends to all the domains in both forests. You may want to implement a forest trust if you merge with or acquire a company and you want all of the new company’s Active Directory resources to be accessible for users in your Active Directory environment and vice versa. Figure 2-4 shows a cross-forest trust scenario. To create a forest trust, you need to use accounts from the Enterprise Admins group in each forest.
You want to create a shortcut trust between two AD domains that are in the same forest. Shortcut trusts can make the authentication process more efficient between two domains in a forest.
Open the Active Directory Domains and Trusts snap-in (domain.msc).
In the left pane, right-click the forest root domain and select Properties.
Click on the Trusts tab.
Click the New Trust button. Then click Next.
Enter the name of the domain and then click Next.
Verify that a two-way trust direction is selected and then click Next.
Verify that “This domain only” is selected to create the trust and then click Next.
Verify that “Domain-wide authentication” is selected and then click Next.
Enter a complex password for the trust password and then click Next. Note that the password must meet the domain password policy.
Review the trust settings summary and then click Next.
A message indicating that a trust relationship was created successfully will appear. Click Next to configure the new trust.
Perform the same steps on the trusted domain. Then, on both sides, select Yes to confirm the incoming trust and then click Next.
A success message will appear. Click Finish.
The trust should now appear in the Trusts tab of the domain properties.
> netdom trust<Domain1DNSName>/Domain:<Domain2DNSName/Twoway /ADD↵ [/UserD:<Domain2AdminUser>/PasswordD:*]↵ [/UserO:<Domain1AdminUser>/PasswordO:*]
To create a shortcut trust from the
emea.adatum.com domain to the
apac.adatum.com domain, use the
following netdom command:
> netdom trust emea.adatum.com /Domain:apac.adatum.com /Twoway /ADD↵ /UserD:[email protected] /PasswordD:*↵ /UserO:[email protected] /PasswordO:*
Consider the forest shown in Figure 2-5. It has five domains in a single domain tree. For authentication requests for Domain 3 to be processed by Domain 5, the request must traverse the path from Domain 3 to Domain 2 to Domain 1 to Domain 4 to Domain 5. If you create a shortcut trust between Domain 3 and Domain 5, the authentication path is just a single hop from Domain 3 to Domain 5. To create a shortcut trust, you must be a member of the Domain Admins group in both domains, or a member of the Enterprise Admins group.
Open the Active Directory Domains and Trusts snap-in (domain.msc).
In the left pane, right-click the forest root domain and select Properties.
Click on the Trusts tab.
Click the New Trust button. Click Next.
Enter the name of the realm and then click Next.
Verify that “Realm trust” is selected and then click Next.
Select Transitive for the trust transitivity and then click Next.
Verify that a two-way trust is selected for the direction of the trust and then click Next.
Enter a complex password for the trust password; click Next. Note that the password must meet the domain password policy.
Review the trust settings summary and then click Next.
A success message will appear. Click Finish.
The trust should now appear in the Trusts tab of the domain properties.
> netdom trust<ADDomainDNSName>/Domain:<KerberosRealmDNSName>↵ /Realm /ADD /PasswordT:<TrustPassword>↵ [/UserO:<ADDomainAdminUser>/PasswordO:*]
The <TrustPassword> has to
match what was set on the Kerberos side. To create a realm trust from
the adatum.com domain to the Kerberos realm
called kerb.adatum.com, use the following
command:
> netdom trust adatum.com /Domain:kerb.adatum.com↵ /Realm /ADD /PasswordT:MyKerbRealmPassword↵ /UserO:[email protected] /PasswordO:*
You can create a Kerberos realm trust between an Active Directory domain and a non-Windows Kerberos v5 realm. A realm trust can be used to allow clients from the non-Windows Kerberos realm to access resources in Active Directory, and vice versa. See Enabling Kerberos Logging for more information on MIT Kerberos interoperability with Active Directory.
“Understanding When to Create a Realm Trust” for information about realm trusts; “Understanding Trust Types” for a detailed explanation of the available trust types
To enumerate domain trusts using the netdom utility, use the following syntax:
> netdom query trust /Domain:<DomainDNSName>You can also use nltest, available from the Windows Support Tools, as follows:
> nltest /domain_trusts /All_Trusts
Get-ADTrust -filter *
If the adatum.com domain is configured with a two-way external trust with the barcelona.corp domain, running this script from dc1.adatum.com would produce the following output:
Direction : BiDirectional DisallowTransivity : False DistinguishedName : CN=barcelona.corp,CN=System,dc=adatum,dc=com ForestTransitive : True IntraForest : False IsTreeParent : False IsTreeRoot : False Name : barcelona.corp ObjectClass : trustedDomain ObjectGUID : 98616652-c2ec-4057-a7ea-f639e1ec2680 SelectiveAuthentication : False SIDFilteringForestAware : False SIDFilteringQuarantined : False Source : dc=adatum,dc=com Target : barcelona.corp TGTDelegation : False TrustAttributes : 8 TrustedPolicy : TrustingPolicy : TrustType : Uplevel UplevelOnly : False UsesAESKeys : False UsesRC4Encryption : False
You can view the properties of a particular trust by clicking on a trust and clicking the Properties button.
You can include the /Direct
switch with netdom if you want to view only
direct-trust relationships. If you don’t use /Direct, implicit trusts that occur due to
transitive trust relationships will also be listed.
The nltest command can take
the following additional switches to modify the default behavior of
the /domain_trusts
switch:
/PrimaryReturns only the domain that the computer account you’re running
nltestfrom belongs to/ForestReturns domains that are in the same forest as the primary domain
/Direct_OutReturns only those domains that are trusted by the primary domain
/Direct_InReturns only those domains that trust the primary domain
/vDisplays domain SIDs and GUIDs
“Understanding Trusts” for a deep dive into Active Directory trusts
You want to verify that a trust is working correctly. This is the first diagnostic step to take if users notify you that authentication to a remote domain appears to be failing.
For the Windows Server 2003, Windows Server 2008, and Windows Server 2012 versions of the Active Directory Domains and Trusts snap-in:
In the left pane, right-click on the trusting domain and select Properties.
Click the Trusts tab.
Click the domain that is associated with the trust you want to verify.
Click the Properties button.
Click the Validate button and select the option to validate the incoming trust or validate only the outgoing trust.
Verifying a trust consists of checking connectivity between the domains and determining if the shared secrets of a trust are synchronized between the two domains. It is recommended that you validate both sides of the trust. You can validate both sides of the trust by selecting the option to validate the incoming trust during the verification. Otherwise, you have to perform verification from each side independently.
The Active Directory Domains and Trusts screens have not changed between Windows 2003 and Windows Server 2012.
“Understanding Trusts” for a deep dive into Active Directory trusts
You want to reset a trust password. If you’ve determined a trust is broken, you need to reset it, which will allow users to authenticate across it again.
Follow the same directions as in Verifying a Trust. The option to reset the trust will be presented only if the verification/validation did not succeed. In Windows Server 2012, if the trust validation process fails, you will be prompted to reset the trust passwords.
Resetting a trust synchronizes the shared secrets (i.e., passwords) for the trust. The PDC Emulators in both domains are used to synchronize the password, so they must be reachable during the reset process.
Verifying a Trust for verifying a trust
You want to remove a trust. This is commonly done when the remote domain has been decommissioned or access to it is no longer required.
Open the Active Directory Domains and Trusts snap-in (domain.msc).
In the left pane, right-click on the trusting domain and select Properties.
Click the Trusts tab.
Click on the domain that is associated with the trust you want to remove.
Click the Remove button.
Select the option to remove the trust from both domains, or the option to delete the trust only from the local domain, and then click OK.
To remove a trust relationship using the netdom utility, use the following
syntax:
> netdom trust<TrustingDomain>/Domain:<TrustedDomain>/Remove /verbose↵ [/UserO:<TrustingDomainUser>/PasswordO:*]↵ [/UserD:<TrustedDomainUser>/PasswordD:*]
To remove a trust using a combination of AdFind and AdMod, issue the following two commands:
> adfind -b cn=<Trusted Domain>,cn=system,<Domain DN>-dsq | admod -rm > adfind -b cn=<TrustName>$,cn=users,<Domain DN>-dsq | admod -rm
Note
Both of these commands first use AdFind to return the object
that needs to be deleted, and then use the | operator to send that object to AdMod to
perform the actual deletion.
Trusts are stored in Active Directory as two objects: a trustedDomain object in the System container and a user object in the Users container. Both of these objects need to
be removed when deleting a trust. The GUI and netdom solutions take care of that in one
step, but in the AdMod example, both objects needed to be explicitly
deleted.
You want to enable Security Identifier (SID) filtering for a trust. By enabling SID filtering, you can keep a hacker from spoofing an SID across a trust.
A security vulnerability exists with the use of SID history, which is described in detail in MS KB 289243. An administrator in a trusted domain can modify the SID history for a user, which could grant her elevated privileges in the trusting domain. The risk of this exploit is relatively low due to the complexity of forging an SID, but nevertheless, you should be aware of it. To prevent this from happening you can enable SID filtering for a trust. When SID filtering is enabled, the only SIDs that are used as part of a user’s token are from those domains in the trust path of the trusted domain—so if the trusted domain is adatum.com, which has a child domain called emea.adatum.com, SID filtering would accept SIDs from both the adatum.com domain and its child domain, emea. SIDs that are not a part of the trusted domain’s trust path are not included, so an SID from the barcelona.corp would be stripped from the user’s access token. SID filtering makes things more secure, but it prevents the use of SID history and can cause problems with transitive trusts and domain migrations. For example, if we migrated a user from barcelona.corp to adatum.com, that user’s barcelona.corp SID history entry would be ignored as long as SID filtering was in place. You would need to update the access control lists (ACLs) on resources in barcelona.corp to point to the migrated user’s adatum.com SID, which would allow the user to access them with SID filtering in place.
SID filtering is enabled by default on all trust relationships
created in Windows 2000 Service Pack 4 and later. This can cause
unexpected behavior if you create a trust relationship under an earlier
Service Pack version, but then delete and re-create the trust under SP4
or later. You can disable SID filtering by running the netdom command with the /EnableSIDHistory:Yes switch.
You want to enable Quarantine for a trust. By enabling Quarantine, you can greatly restrict the acceptable domain SIDs in a trust relationship.
A security vulnerability exists with the use of SID history, which is described in detail in MS KB 289243. An administrator in a trusted domain can modify the SID history for a user, which could grant him elevated privileges in the trusting domain. The risk of this exploit is relatively low due to the complexity in forging an SID, but nevertheless, you should be aware of it. You can put in strong restrictions in order to minimize the risk of privilege elevation by enabling Quarantine for a trust. When Quarantine is enabled, the only SIDs that are used as part of a user’s token are from those domains in the trusted domain itself. So if the trusted domain is adatum.com, which has a child domain called emea.adatum.com, Quarantine will only accept SIDs from adatum.com itself. Even domain SIDs that are a part of the trusted domain’s trust path are not included, so an SID from emea.adatum.com would be stripped from the user’s access token. Enabling Quarantine for a trust effectively removes the transitivity of a forest trust relationship, restricting the trust relationship to only the domain that you specified when you created the trust. (This causes a forest trust to emulate the default behavior of an external trust instead.)
You can disable Quarantine on a trust relationship by running the
netdom command again and specifying
the /Quarantine:No switch.
You want to enable or disable Selective Authentication for a trust. By enabling Selective Authentication, you can control which computers—in a trusting domain—users in a trusted domain can access. Disabling Selective Authentication will allow users in the trusted domain to authenticate to any computer in the trusting domain.
To enable Selective Authentication:
Open the Active Directory Domains and Trusts snap-in (domain.msc).
To enable Selective Authentication for a forest trust, right-click on the forest root domain and select Properties. To enable Selective Authentication for an external trust, right-click on the domain you wish to configure and select Properties.
On the Trusts tab, right-click on the trust that you wish to administer and select Properties.
On the Authentication tab, click Selective Authentication.
Click OK to finish.
To disable Selective Authentication:
Open the Active Directory Domains and Trusts snap-in (domain.msc).
To enable forest-wide authentication for a forest trust, right-click on the forest root domain and select Properties. To enable domain-wide authentication for an external trust, right-click on the domain you wish to configure and select Properties.
On the Trusts tab, right-click on the trust that you wish to administer and select Properties.
In the case of a forest trust, on the Authentication tab click Forest-Wide Authentication. For an external trust, on the Authentication tab click Domain-Wide Authentication.
Click OK to finish.
To grant permissions on individual computers in the trusting domain:
Open the Active Directory Users and Computers snap-in (dsa.msc).
Right-click on the computer object on which you wish to grant permissions and select Properties.
On the Security tab, select the user or group that you want to authorize, and select the Allow checkbox next to the Allowed to Authenticate permission.
Click OK to finish.
To enable Selective Authentication, use the following syntax:
> netdom trust<TrustingDomain>/Domain:<TrustedDomain>/SelectiveAUTH:Yes↵ [/UserO:<TrustingDomainUser>/PasswordO:*]↵ [/UserD:<TrustedDomainUser>/PasswordD:*]
Note
Use the /SelectiveAUTH:No
switch to enable domain- or forest-wide authentication.
Trust relationships since Windows Server 2003, by default, allow users in a trusted domain to authenticate to and access shared resources on any computer in the trusting domain. Selective Authentication, also known as the Authentication Firewall, will restrict access to only those computers in the trusted domain that you specifically designate. This level of increased security is particularly useful when you need to grant access to shared resources in your forest, but you need to restrict that access to only a limited set of users in the remote forest.
For users in a trusted domain or forest to be able to access resources in a trusting domain or forest, where the trust authentication setting has been set to Selective Authentication, each user must be explicitly granted the Allowed to Authenticate permission on the security descriptor of the computer objects (resource computers) that reside in the trusting domain or forest. By default, only members of the Account Operators, Administrators, Domain Admins, Enterprise Admins, and SYSTEM groups in the trusting domain have the ability to modify this permission.
Warning
Enabling Selective Authentication has the potential to create a huge increase in your AD administrative overhead, and should only be enabled when the security risks justify the administrative implications.
You want to find any duplicate SIDs in a domain. Generally, duplicate SIDs in a domain should not exist, but it is possible in some situations, such as when the relative identifier (RID) FSMO role owner has to be seized.
To find duplicate SIDs, run the following command, replacing
<DomainControllerName> with a domain
controller or domain name:
> ntdsutil "sec acc man" "co to se <DomainControllerName" "check dup sid" q qThe following message will be returned:
Duplicate SID check completed successfully. Check dupsid.log for any duplicates
The dupsid.log file will be in the directory where you started ntdsutil.
If you want to delete any objects that have duplicate SIDs, you can use the following command:
> ntdsutil "sec acc man" "co to se <DomainControllerName>" "clean dup sid" q qLike the check command, the
clean command will generate a
message like the following upon completion:
Duplicate SID cleanup completed successfully. Check dupsid.log for any duplicates
All security principals in Active Directory have an SID, which is used to uniquely identify the object in the Windows security system. There are two parts of an SID: the domain identifier and the RID. Domain controllers are allocated a RID pool from the RID FSMO for the domain. When a new security principal (user, group, or computer) is created, the domain controller takes an RID from its pool to generate an SID for the account.
In some rare circumstances, such as when the RID master role is seized, overlapping RID pools can be allocated, which can ultimately lead to duplicate SIDs. Having duplicate SIDs is a potentially hazardous problem because a user, group, or computer could gain access to sensitive data it was never intended to have access to.
You want to add to the list of attributes by which you can search and sort records within the ADUC (Active Directory Users and Computers) MMC snap-in (dsa.msc).
In this example, we will add the operating system service-pack-level attributes of computer objects to ADUC to allow you to search and sort by these fields:
If an entry for the Configuration NC is not already displayed, do the following:
Right-click on ADSI Edit in the right pane and click “Connect to.”
Under “Select a well-known naming context,” select Configuration. Click Advanced if you need to specify alternate credentials, and then click OK to create the connection.
In the left pane, click on
cn=DisplaySpecifiersand thencn=409. Right-click on the container and select Properties.
Note
If you are using a locale other than one that uses US English, specify the appropriate locale number in place of
cn=409, using the reference listed by Microsoft.Right-click on
cn=computerDisplayand select Properties.Double-click on
attributeDisplayNames. TypeoperatingSystemServicePack, Operating System Service Pack, and click Add.Click Apply, followed by OK.
First create an LDIF file containing the following information and save it as modify_display_specifiers.ldif:
dn: cn=computer-display,cn=409,cn=DisplaySpecifiers,
cn=Configuration, <ForestRootDN>
changetype: modify
add: attributeDisplayNames
attributeDisplayNames: operatingSystemServicePack,Operating System Service Pack
-Then run the following command:
> ldifde -v -i -f modify_display_specifiers.ldf
You can also modify this information using a combination of AdFind and AdMod, as follows:
> adfind -config -rb cn=computer-display,cn=409,cn=DisplaySpecifiers |↵ admod "attributeDisplayNames:+:operatingSystemServicePack,Operating System↵ Service Pack"
When working within the Active Directory Users and Computers MMC snap-in, there are a number of default attributes for each type of object that you can use to either search or sort on. Computer objects, for example, allow you to search and sort by the computer name, description, manager, operating system, and pre-Windows 2000 computer name. Once you add a new attribute to the display specifiers, you can access it by opening ADUC, right-clicking on a container, and clicking on Find. Select Computers in the drop-down box next to Find, and click on Advanced. When you click on Field, you’ll see the new field that you just added; you can now use it to search for objects within the ADUC snap-in.
Modifying an Object for more on modifying an object; MSDN: Attribute-Display-Names [AD Schema]; MSDN: PutEx Method [ADSI]