Windows Server 2008 : Choosing Server Roles

Now, however, solution architects and IT administrators have the problem of not just choosing domain controllers but choosing among several types of domain controllers, DNS settings, server roles, server features, scripting, and hundreds of other options that can be implemented in your campus. Microsoft has adapted to this change in administrative design by introducing many new features and best practices that should be followed in your organization.

Part of the difficulty involved with designing an enterprise with Windows Server 2008 is that there is so much that can be done! In Windows Server 2008 alone, Microsoft released several major features that are particularly important to large environments. For the exam, you will need to be able to fire these features and their buzzwords off at whim, because you can bet a silver dollar that you're going to be seeing all them—either on the certification exam or when you enter the workforce.

Since you already have some familiarity with these new features, I'll briefly cover the most commonly tested features here and point out how you need to consider using these features in a Windows enterprise-level environment, as well as one or two old favorites that still raise their heads once in a while.

1. Security Design Features

Although Microsoft doesn't officially group Windows Server 2008's new features into categories such as security and delegation, it's useful for your purposes to consider the features this way, because it helps put you in the right frame of mind to think about how these features help your overall environment. The two features you'll concentrate on in the following sections are read-only domain controllers and Windows BitLocker encryption.

1.1. Read-Only Domain Controllers

As you probably already know, read-only domain controllers (RODCs) are a hot topic in the IT workplace right now. RODCs are new to Windows Server 2008 and can be run only on Windows Server 2008. However, Windows Server 2003 domain controllers can communicate with them.

An RODC is a domain controller that, as the name implies, contains a "read-only" copy of the Active Directory database that cannot be changed (written to). The primary use for this is in a situation where the physical security of an environment is compromised. In other words, an RODC makes sure that someone can't steal, tamper with, or alter your domain controller and acquire valuable intellectual property, such as usernames, passwords, or other such need-to-know information.

Something else you need to remember about RODCs is that they can use their own version of DNS, called read-only DNS. For design purposes, it's important to remember that read-only DNS functions by a referral system. Whenever a user makes a resolution request, the read-only DNS server makes a referral to another DNS server for name resolution. Effectively, this keeps the server from keeping a writable and updatable table of IP address mappings that can ultimately become compromised.

Figure 1 shows a typical example where a read-only domain controller could be used in a large enterprise environment. Keep in mind as you're studying RODCs that the RODC features fall under the purview of Active Directory Domain Services, along with the very snazzy new restartable Active Directory services feature, which I'll cover later in this book.

Figure 1. RODC placement

1.2. Windows BitLocker

Because of the release of Microsoft Vista, much of the true pizzazz of the incredible BitLocker feature has been downplayed. Why? Well, BitLocker is no longer new. However, the BitLocker feature is absolutely priceless in an enterprise environment. Single-handedly, this role ensures that your Windows server, along with its important data, is encrypted and cannot be read by a malicious intruder who nefariously acquires one of your domain controllers through deceit.

For design purposes, this feature actually opens an entire new level of consideration for the environment. Initially, you have to consider the physical placement of servers. Afterward, you have to think about whether the physical placement of those servers could possibly result in the servers being compromised. It's a rather disturbing thought, but in today's world you really just can't take the chance that your server might never be subject to malicious users.

In general, BitLocker encryption is almost never a bad thing. However, it isn't enabled by default. You, as the administrator, must turn it on. If it makes you feel safer, it isn't a bad practice to enable BitLocker encryption on almost any server that might ever have the chance of being visited by someone that isn't part of your organization. On the extreme end, you could also safely enable it on every Windows Vista and Windows Server 2008 machine in your environment. It's a bit taxing in terms of deployment but worth it in the end.

2. Administration and Delegation Features

It's no secret that administering several thousand users can be a big task that can take a lot of time. Not only is it a big job, but it can be rather complex. Without the ability to delegate some of the numerous tasks that have to be conducted every day, your job would be very difficult. It's because of this that nearly every day Microsoft is trying to incorporate solutions that make our lives as administrators a lot easier. Let's take a look now at some of the great new roles that you can incorporate in your design, such as Active Directory Rights Management Services (AD RMS).

2.1. Active Directory Rights Management Services

AD RMS is a true heavyweight in terms of the new features of Windows Server 2008. With AD RMS, an organization can give its users some administrative control of their individual documents and files, including office documents and emails. Additionally, with AD RMS, administrators and users can create privilege templates that can be defaulted for certain abilities in the environment. For instance, an administrator could create a "read-only" template that users could apply to a report that they'd like to make available on a shared drive somewhere in the organization.

The most important point you need to keep in mind for AD RMS in an environment is this: Active Directory Rights Management Services requires a database server.

If you are designing an environment and your organization doesn't plan to incorporate some sort of database server, you can't deploy this feature.

AD RMS has requirements that go beyond its hardware needs:

• Firewall exceptions (see Table 1)

• One AD RMS server per forest

• IIS with ASP.NET enabled

It's important to point out that AD RMS is not as simple to install as you might think. You need to keep in mind a lot of requirements, and although it might seem like a very convenient feature for your office environment, it does require some planning on your end. You can have an AD RMS server in an extranet, in a single-server environment, connected through a URL, or with several other setups.

For the certification exam, it's important to remember the basic features of AD RMS—the ones in the checklist at the beginning of this section.

If you're asked for a way to give users a right to secure their documents, remember that AD RMS is probably the solution. It's extraordinarily powerful, and if you implement it correctly, it can relieve a lot of headaches. However, if you don't consider the full ramifications of this setup, you can ultimately end up with a less secure network that is running more services than it needs, ultimately draining the usability and portability of your server.

2.2. Active Directory Federation Services

If there's one phrase you need to remember about Active Directory Federation Services (AD FS), it is this: single sign-on (SSO). The overall design purpose of AD FS is to create an environment where users don't have to repeatedly validate their credentials across an environment. From a design standpoint, you may have a situation that looks similar to Figure 2.

Figure 2. Active Directory Federation Services

On the right side of the illustration, you have users who are trying to access an application on server 2. However, they authenticate through server 1. Once they've authenticated through that server, they then have to access yet another server in order to complete the tasks they need to do. As you can imagine, this can be quite annoying to users. It would be particularly irritating if they had to use the same username and password.

By using AD FS, administrators can create a trust policy between servers for the purposes of authentication. This means that in a situation such as Figure 1.16, you could create an environment where users could simply log on to their primary server and then be authenticated throughout the rest of the forest (or multiple forest) environment. It isn't just convenient for them; it's also less burdening on your servers. They get to automatically authenticate through a simple service vs. sending back and forth requests for user information that may require more demanding GUIs or other such programs they have to launch.

When you're first creating your design, Windows Active Directory Federation Services has several options on how it can be installed:

Federation Services

Federation Services is the underlying architecture that provides the ability for users to sign on once in an environment. It does this through a series of designed trusts and allocations that is decided upon far in advance of the actual implementation of the feature. In general, Federation Services can implement single sign-on through one of three general federation designs, also referred to as federation scenarios: Web SSO, Federated Web SSO, and Federated Web SSO with Forest Trust.

Web SSO design

In a simple Web SSO design, all users are external, and therefore no federation trusts exist because there are no partners. According to Microsoft, the primary reason an administrator would need a design such as this is if the organization had an application that needed to be accessed by users on the Internet.

Federated Web SSO design

Sometimes companies merge, form partnerships, or otherwise need to share infrastructures and applications. Before AD FS, the only real way this could be accomplished is by creating separate accounts for each account, as well as a new series of policies and information to remember in addition to the current passwords.

Now, when situations like this occur, administrators can incorporate a design policy that implements the concept of federation trusts. A federation trust is a type of agreement that's made between two organizations that gives them the ability to verify users from one organization to be granted access to another. Federation trusts represented with one-way arrows point to the account side of the trust, as illustrated in 3.

A quick but very important point to consider before continuing is that federation trusts require two servers to authenticate. You can't have a federation trust that authenticates to nothing.

Consider the example in Figure 4. In this figure, you can see a great example of where an organization could use Active Directory Federation Services. MyCorp, a service providing a resource, has a trust established with MegaCorp, an organization with several accounts. Within MegaCorp, several users will need to log in to MegaCorp and have access to the services provided from MyCorp. In this scenario, they can simply log in to MegaCorp and access their applications at whim.

Figure 3. Federation trust

Figure 4. Federated Web SSO design

Federated Web SSO with Forest Trust design

In a Federated Web SSO with Forest Trust design, you are effectively combining Active Directory from multiple forests in different organizations so that users in the account portion can access applications in another organization with their standard username and password. The advantage of this design scheme is that user accounts in the MyCorp domain can also access the application, and therefore resource accounts or groups do not need to be created.

Federation Services proxy

A Federation Services proxy server is a role that serves two purposes for either the account or resource side. On the account side, a federation server acts as a proxy for the actual federation server and also distributes security tokens to web-based clients that need to access resources on the resource partner portion of the agreement. On the resource side, a proxy server just redirects clients to a federation server that can authenticate the clients. Overall, the benefit of a Federation Services proxy is to alleviate the workload of the actual federation server and add another layer of design complexity for best practices.

Claims-aware agent

If an organization happens to be running an application that is claims-aware and needs to have security tokens verified through Active Directory Domains Services, they can use a claims-aware agent. Loosely put, a claims-aware application is a Microsoft ASP.NET application that uses claims that are present in an Active Directory Federation Services security token to provide authorization and personalization to your environment. Normally, you won't be implementing this unless your organization has very specific needs.

Windows token-based agent

A Windows token-based agent is an agent that converts from Active Directory Federation Services to an impersonated Windows NT access token. The reason this might be used is if you have an application that requires Windows authentication and you have to connect via Federation Services. If this is the case, the web agent creates an impersonated authentication token that Windows can use. Some of the aspects of the Windows token-based agent are auditing, application logging, configuration details, and malformed requests.

If you're interested in learning more about Active Directory Federation Services and how it can be used in your environment, Microsoft provides a wonderful online resource on Windows Server 2008 TechNet that gives practical examples of how each of these designs could be implemented. However, for the purposes of the certification exam, the server-level implementation is beyond the scope of this book. What's important for you to remember is the purpose of the service and the different types of designs that can be utilized in your environment.