It determines the software required by the ad ds for all its features to work.

Active Directory Domain Services

Active Directory Domain Services (AD DS) stores information about users, computers, and other devices on the network. AD DS is required to install directory-enabled applications. The following are improvements made in AD DS functionality:

Auditing (log value changes that are made to AD DS objects and their attributes)

Fine-grained password policies (functionality to assign a special password and account lockout policies for different sets of users)

Read-only DCs (hosts a read-only partition of the AD DS database)

Restartable AD DS (can be stopped so that updates can be applied to a DC)

Database mounting tool (compare different backups, eliminating multiple restores)

User interface improvements (updated AD DS Installation Wizard)

Active Directory Domains and Trusts

The Active Directory Domains and Trusts console is used to manually create trust relationships between domains and to raise the forest functional level. The Active Directory Domains and Trusts console is accessed from the Administrative Tools folder in the Start Menu (see Figure 4.32).

To raise the forest functional level, right-click on the domain name in the console and select the option Raise Forest Functional Level. The Domains and Trusts console can also be used to transfer the Domain Naming Service FSMO role to another DC. This is accomplished by opening the Domains and Trusts console on the DC that you want to transfer the role to. Then, right-click on the root node of Active Directory Domains and Trusts and choose the option Operations Masters. Click the Change button to transfer the FSMO role to this DC.

Windows Server 2003 Domain Functional Level

The Windows Server 2003 domain functional level supports both Windows Server 2003 and Windows Server 2008 DCs. This level does not allow for the presence of Windows NT or Windows 2000 DCs, and is designed to support an upgrade from 2003 to 2008. All 2003 Active Directory domain features are enabled at this level, providing a good balance between security and backward compatibility.

DCs not supported at this level:

Windows NT 4.0 DCs

Windows 2000 DCs

The following Active Directory domain-wide functions are supported at both this level and the Windows 2000 domain functional level:

Universal Security Groups

Group nesting

Converting groups between distribution and security groups

SIDHistory

The following upgraded Active Directory domain-wide functionality is supported at this domain functional level:

DC rename

Logon timestamp attribute updated and replicated

User password support on the InetOrgPerson objectClass

Constrained delegation

Users and Computers container redirection

Can be raised to the Windows Server 2008 domain functional level

Can never be lowered to the Windows 2000 domain functional level

In the Windows Server 2003 domain functional level, only Windows Server 2003 and Windows Server 2008 DCs can exist.

Active Directory Domains and Trusts

The Active Directory Domains and Trusts console is used to manage domains and the trust relationships between them. As shown in Figure 1.17, the console tree of this tool includes a node for domains making up the network. By selecting the Active Directory Domains and Trusts node, a listing of domains will appear in the right pane. Using this tool, you can create, modify, and delete trust relationships between domains, set the suffix for UPNs, and raise domain and forest functional levels. This enables administrators to control how domains function, and how they interoperate.

Using the Active Directory Domains and Trusts console, you can create a variety of different types of trusts between domains and forests. Earlier, we discussed how parent and child domains and domain trees use a two-way transitive trust to share resources between domains. The two-way transitive trust means that both domains trust one another, as well as any other domains with which they have similar trust relationships. In addition to this type of trust, additional trusts can be created:

Shortcut trust

Forest trust

Realm trust

External trust

A shortcut trust is transitive, and can be either one-way or two-way. This means that either one domain can trust another but not vice versa, or both domains can trust each other. This type of trust is used to connect two domains in a forest, and is particularly useful when the domains are in different trees. By creating a shortcut, one domain can connect with another quickly, improving logon times between domains. Connection is quicker because, when two domains in different trees connect via the implicit trusts that exist by default, the trust path must go all the way up the tree to the root domain, across to the other tree’s root domain, and back down the second tree. A shortcut trust, as its name indicates, creates a direct trust between the two domains in different trees.

To illustrate this, let’s look at the situation in Figure 1.18. If a user in DomainD wanted to use resources in Domain2, he or she would be authenticating to a domain that is located in a different tree. Without a shortcut trust, the connection would go through DomainA, across the trust between the two trees to Domain1, and then to Domain2.With a shortcut trust, DomainD and Domain2 would have a direct trust between them that could be used for authentication. As we can also see in Figure 1.18, multiple shortcut trusts can exist, allowing users to be authenticated to other domains that they commonly need to access.

A forest trust is also transitive, and can be one-way or two-way. As shown in Figure 1.19, this type of trust is used to connect two different forests, so that users in each forest can use resources in the other. Using this type of trust, a user in a domain in one forest could be authenticated and access resources located in a domain that’s in another forest. This allows different areas of the network to be interconnected, even though they are separated by administrative boundaries.

A realm trust can be one-way or two-way, and can also be either transitive or nontransitive. Nontransitive means that the trust relationship doesn’t extend beyond the two parties. For example, let’s say DomainA trusts DomainB, and DomainB trusts DomainC. Because the trust is nontransitive, DomainA and DomainC don’t trust one another because there isn’t a trust relationship between them. As shown in Figure 1.20, the realm trust is used when a relationship needs to be created between a Windows Server 2003 domain and a non-Windows realm that uses Kerberos version 5 (such as one running UNIX).

The final type of trust that can be created is an external trust. An external trust is always nontransitive, and can be either one-way or two-way. As shown in Figure 1.21, this type of trust is used to create a relationship between a Windows Server 2003 domain and one running Windows NT 4.0. It can also be used to connect two domains that are in different forests, and don’t have a forest trust connecting them.

The Active Directory Domains and Trusts console is also used for raising domain and forest levels, which enables additional features in Active Directory. Raising domain and forest functional levels depends on what operating systems are running on servers, and is something we discuss in greater detail later in this chapter.

Exam Warning

The Active Directory Domains and Trusts console allows you to create different types of trust relationships to share information and resources between forests, domains, and non-Windows Server 2003 networks. You can create one- and two-way transitive trusts, forest trusts, realm trusts, external trusts, and shortcut trusts. Each has a specific use, and cannot be used in all circumstances. You should familiarize yourself with the use of each type of trust.

Types of Trust Relationships

Two or more Active Directory domains are implicitly or explicitly connected using trust relationships. The authentication requests made from one domain to the other domains use these relationships. The trusts provide a seamless coexistence of resources within the forest structure. Users are granted access to the resources in the other domain(s) after being authenticated in their own domain first. Once authenticated in their own domain, they can traverse the other domains to gain access to their resources.

Test Day Tip

On the day of the test you will want to review the types of trusts as well as when to use each of the different trusts. On the exam, you might be given a scenario that will require you to determine the type of trust that will best meet the requirements in the scenario.

Because there are several new types of trust, you should ensure that you know when it is appropriate to use the different trusts.

The primary advantage of these relationships is that administrators no longer need to create multiple user accounts for each user who needs access to resources within each domain. Administrators can now add the users of the other domains to their access control lists (ACLs) to control access to a resource. To take full advantage of these relationships, the administrator must know about the various types of trust that exist, and when to use them.

Shortcut Trust

Shortcut trusts are transitive in nature and can either be one-way or two-way. These are explicit trusts that you create when the need exists to optimize (“shortcut”) the authentication process. Without shortcut trusts in place, authentication travels up and down the domain tree using the default parent and child trusts, or by using the tree-root trusts. In large complex organizations that use multiple trees, this path can become a bottleneck when authenticating users. To optimize access, the network administrator can create an explicit shortcut trust directly to the target domain (see Figure 5.5).

Figure 5.5. Shortcut Trust

These trusts are used when user accounts in one domain need regular access to the resources in another domain. Shortcut trusts can be either one- or two-way.

One way shortcut trusts should be established when the users in one domain need access to resources in the other domain, but those in the second domain do not need access to resources in the first domain.

Two-way trusts should be created when the users in both domains need access to the resources in the other domain. The shortcut trust will effectively shorten the authentication path, especially if the domains belong to two separate trees in the forest.

External Trust

An external trust is used when you need to create a trust between domains outside of your forest. These trusts can be one- or two-way trusts. They are always non-transitive in nature. This means that you have created an explicit trust between the two domains, and domains outside this trust are not affected. You can create an external trust to access resources in a domain in a different forest that is not already covered by a forest trust (see Figure 5.6).

Figure 5.6. External Trust

Exam Warning

You will always need to create an external trust when connecting to a Windows NT 4.0 or earlier domain. These domains are not eligible to participate in Active Directory. These trusts must be one-way trusts. If you have worked with Windows NT 4.0, you will remember that the only trusts allowed were non-transitive one-way trusts.

After the trust has been established between a domain in a forest and a domain outside the forest, the security principals from the domain outside the forests will be able to access the resources in the domain inside the forest. Security principals can be the users, groups, computers, or services from the external domain. They are account holders that are each assigned a security identifier (SID) automatically to control access to the resources in the domain.

The Active Directory in the domain inside the forest will then create foreign security principal objects representing each security principal from the trusted external domain. You can use these foreign security principals in the domain local groups. This means that the domain local groups can have members from the trusted external domain. You use these groups to control access to the resources of the domain.

The foreign security principals are seen in Active Directory Users and Computers. Since the Active Directory automatically creates them, you should not attempt to modify them.

Planning the Network Topology

The next phase in planning your TCP/IP infrastructure is planning the IP routing solution to manage the traffic on your network. This will depend on the physical location of your equipment and users, as well as on how you want to distribute the addresses. When your implement your strategy, you will also need to determine how the hosts on your network will resolve host names and implement the necessary services to provide that functionality. You will need to identify where the services such as DHCP, WINS, DNS, and so on must exist in your network to function properly and reduce the network bandwidth utilization.

DirectAccess

Imagine if you could be anywhere on the planet, connected to the Internet and still have no hassle access to all of your corporate assets. I am sure many of you are thinking, “I already have that! I VPN in, and…”. Well, to be more specific, how about the same LAN style corporate access, but without the VPN hassle?

Well, with Windows 2008 R2, Microsoft released an amazing new feature called DirectAccess, and the name says it all. DirectAccess allows you and your users to gain access to the internal corporate resources in your environment from the Internet, without first connecting to a VPN, and without requiring user intervention to connect!

The benefit is apparent from a user's perspective. They have access to corporate resources such as Web pages, file shares, and applications from any Internet-connected location. It is a secure connection and the user experiences mimics being directly connected to the corporate environment, thus giving the user a seamless experience between being in the office and out of the office.

The benefits that may not be as apparent are the advantages DirectAccess bring into play for the administrative team. Administrators can utilize DirectAccess technology to their advantage in a number of ways. One way DirectAccess lessens the burden of the help desk is by reducing the learning curve associated with VPN access. When users are in the office they have one way of accessing resources. Put them out on the Internet, and now they have to battle with VPN connections before their resource access returns. Account lockout problems can occur, issues around client VPN software must be addressed, and of course, users have to be taught to utilize the software as well.

By deploying DirectAccess connections into corporate resources, look and act the same for a user regardless if they are on the Internet or connected directly to the Intranet. The maintenance and management of VPN software and infrastructure is something that can be scaled down as its usage lessens. Additionally, the Windows 7 and Windows 2008 R2 native DirectAccess feature set leaves your users with little to nothing to learn, since the connection is seamless.

Another benefit that DirectAccess brings to administrators relates to system maintenance. In most corporate environments, mobile users are a wild card. Since they only connect to the environment intermittently, keeping them patched and up to date with the latest policies can be tricky. Normally, an administrator must rely on a user to either VPN into the corporate network or actually walk into a company facility and connect to the LAN. This can make the time between updates unpredictable and it can leave users' machines in a vulnerable state. By being able to access a user's machine whenever they are connected to the Internet, the story changes dramatically.

With DirectAccess, the user merely has to connect to the Internet from anywhere in the world. Once on the Internet, their computer will automatically connect to the corporate network, authenticate, and give them access to network resources while at the same time giving your network maintenance tools the ability to connect to them. By being able to patch and manage policies on machines that normally might not connect into the network for long durations at a time, you can be that much more efficient at keeping your corporate systems up to date. In the next sections, we will explore DirectAccess in more detail to see how you can choose to utilize it to secure and also enable your mobile user workforce.

Which Roles Can Be Installed?

Administrators think of servers in terms of roles. That's our fileserver, that's the DNS server, and so on. A server always fulfills a particular role. For this reason, Microsoft has changed its approach for installing software. A server role provides the key functionality of a particular server. Add/Remove Programs doesn't exist anymore and has been replaced by Server Manager. If you want to add a role or feature, the Server Manager is the place to do it. But Server Manager doesn't work in Server Core because it uses managed code. So should we use the command-line version servermanagercmd.exe? No. Servermanagercmd.exe uses .NET Framework, which isn't modular enough to break it down and let it fit within Server Core. So we use a replacement command called ocsetup. With the command ocsetup, you can install roles and features on Server Core. One Server Core role you can't install with the ocsetup is Active Directory Domain Services (AD DS). In the later section, “Server Core – Administration,” you will learn how to use the ocsetup and how to install AD DS on Server Core.

The following roles can be installed on Server Core:

Active Directory Domain Services

Active Directory Lightweight Directory Services (AD LDS)

DHCP Server

DNS Server

File Services

Print Server

Web Server (IIS) (ASP.net is not available for Server Core)

Hyper-V (This role is not available by default)

Streaming Media Services (This role is not available by default)

A feature is a functionality that is designed to support the main server roles. The features that Server Core supports are outlined next.

The following features can be installed on Server Core:

Failover Clustering

Network Load Balancing

Subsystem for Unix-based applications

Backup

MultipathIo

Removable Storage Management

BitLocker Drive Encryption

To see which roles and features are installed on Server Core, use the command oclist.exe. The result of executing the oclist command on a Server Core machine is shown next. The following output is modified. The subcomponents from the roles and features are not displayed because it generates six pages of output.

Use the listed update names with Ocsetup.exe to install/uninstall a server role or optional feature.

Adding or removing the Active Directory role with OCSetup.exe is not supported. It can leave your server in an unstable state. Always use DCPromo to install or uninstall Active Directory.

Microsoft-Windows-ServerCore-Package

Not Installed:BitLocker

Not Installed:BitLocker-RemoteAdminTool

Not Installed:ClientForNFS-Base

Not Installed:DFSN-Server

Not Installed:DFSR-Infrastructure-ServerEdition

Not Installed:DHCPServerCore

Not Installed:DirectoryServices-ADAM-ServerCore

Not Installed:DirectoryServices-DomainController-ServerFoundation

Not Installed:DNS-Server-Core-Role

Not Installed:FailoverCluster-Core

Not Installed:FRS-Infrastructure

Not Installed:IIS-WebServerRole

Not Installed:Microsoft-Windows-RemovableStorageManagementCore

Not Installed:MultipathIo

Not Installed:NetworkLoadBalancingHeadlessServer

Not Installed:Printing-ServerCore-Role

Not Installed:QWAVE

Not Installed:ServerForNFS-Base

Not Installed:SNMP-SC

Not Installed:SUACore

Not Installed:TelnetClient

Not Installed:WAS-WindowsActivationService

Not Installed:WindowsServerBackup

Not Installed:WINS-SC

If you want to install a role, you can type start /w ocsetup DNS-Server-Core-Role to install DNS. If you want to install DHCP, use the command start /w ocsetup DHCPServerCore. Remember, the commands are case-sensitive. Make sure to supply the correct role or feature name after the command start /w ocsetup because the role names are not consistently used. Some roles are written with a hyphen, while others aren't. If you want to de-install a role, first stop the role service with NET STOP, and then type start /w ocsetupserverrolename/uninstall to uninstall the filled-in role.

Domain Accounts

In the case of a machine that is a member of an Active Directory domain, the administrator must create and manage domain accounts. There are significant differences in the portability of these accounts, their authentication methods, and the access that they can achieve throughout the enterprise. In this section, I take a quick look at the domain account structure and briefly describe some of the differences that need explanation in relation to the domain accounts and their functions (Active Directory is out of the scope of this book). While looking at domain accounts, it's important to understand that these accounts are created and maintained on domain controllers that replicate their content to each other. DCs that hold the domain account database do not use local accounts for their operation. As the DC is created, the tools for management of the user and group accounts switch from a local management console to a new tool, the Active Directory Users and Computers (ADUC) management console. From within this console, administrators are able to create, modify, and control user and group memberships. Figure 2.5 illustrates the ADUC console with the Users container open.

Note the significant difference in the number of default user accounts that are created as you create an Active Directory structure. This container contains not only the default users, but a number of domain-wide security groups that are used to maintain and manage the domain operations. Some new security groups are also created, which include Domain Computers, Domain Controllers, Enterprise Admins, Schema Admins, and Domain Admins, among others. All of these groups are used for domain-wide groupings that allow you to control or grant access to specific operations within the domain. Security groups also allow you to enforce group policy conditions, which I touch on later in this chapter and fully explore in Chapter 6. Figure 2.6 shows us the Built-in Groups that are created in an Active Directory domain.

This collection of groups allows administrators to assign or delegate permission to work within specially defined areas of control to perform system-based tasks in the domain. These built-in groups provide the ability to delegate control. Notice in Figure 2.6 that there is a group called Pre-Windows 2000 Compatible Access. This group can lead to security difficulties, because it can contain the special group Everyone in its membership. When this is true, down-level machines (or attackers) may establish a null session connection with the use of a blank password for anonymous access. In this case, anonymous users (such as to a Web page) could potentially access and obtain control of your machine. This particular configuration requires much diligence as you prepare file and drive access control settings, but may be needed depending on your network's makeup.

There is a not significant difference in the sphere of influence of these groups in Windows 2000 and Windows 2003. Please remember that in NT 4.0, these groups had access only on machines that were either a PDC or BDC. In Windows 2003, these built-in groups have access and control over any Windows 2003 machine that is a domain member, even if it is not a domain controller. This is a change that you must be aware of as you assign membership to these groups. Now, what about the “Everyone” group that is discussed all the time? Windows 2003 also has a number of groups that are not detailed here, but rather are present and utilized based on actions being performed. For instance, the Interactive group contains users who are allowed to log on locally to a machine. The Network group contains users that are allowed to connect from the Network. Membership in these groups is not assigned, but rather occurs during operation of the machine and network operations.