Security Advisor

Will R2 Make You More Secure?

The new version of Windows Server 2003 has some components directly targed at security pros, but they may not be what your network needs. Joern Wettern takes a detailed look to help you decide.

• By Joern Wettern
• 10/01/2005

In outlining its roadmap for Windows Server, Microsoft committed to releasing a feature update to the 2003 version approximately two years after it first appeared. As such, this release seems to be targeted mainly at customers in Software Assurance or another of Microsoft's subscription programs. After all, why pay yearly fees if the software only gets updated every four years?

Bill Boswell gave an overview of R2's new features in his July Windows Insider column ("What's New in R2"). Most of the improvements aren't directly security-related. Microsoft spent more time on other areas after concentrating so much on security in Service Pack 1, which was released last March. The focus in R2 is on adding new functionality, like making connections to branch offices easier and more efficient.

Security wasn't completely ignored, however. Two of the new components are directly targeted at security pros:

• Active Directory Federation Services (ADFS) promises to allow for authentication across AD forests.
• New services for Unix will better integrate Unix and Windows environments.

Let's take a look at R2's security features and see if it's something you need on your network.

Extend Authentication with ADFS
Five years ago when AD was officially born, Microsoft said it would make it much easier for companies to work together and establish trusts between internal and external domains. Users from one company could use their regular credentials to log on to a partner's network. For example, an HP hardware engineer on assignment at Microsoft would use his corporate credentials to log on to Microsoft's corporate network and access Microsoft's resources.

This sounds like a great idea. In the real world, however, few companies are willing to establish domain trusts with other companies (even Microsoft doesn't do this). Setting up a full-fledged domain or forest trust between companies simply allows too much network access.

At the same time, though, many organizations are adopting information-sharing models designed to let employees and partners collaborate. For example, there's a huge growth in SharePoint sites being extended to allow partner access from the Internet. Setting up authentication for such projects can be time-consuming and frustrating, since you need to establish and maintain a user account database for external users. Most often this means configuring and maintaining a new domain or AD forest for all external users. Not only is this a lot of extra work, but you also have to rely on the partner companies to notify you about user changes, such as when someone has left or changed jobs within the company.

That's where ADFS comes in. It's designed to simplify collaboration between business partners without requiring users to remember different user names and passwords for access to each company's resources. It does this by allowing Web applications to trust credentials from other forests without requiring full-fledged trust relationships. Such a limited trust can help in a number of scenarios, but the most common ones are business-to-business communications, customer access to relevant data and DMZ authentication.

Business-to-Business
Let's start with B-to-B. Consider the network configuration in Figure 1. General Widgets maintains an ordering and inventory Web site for both their own employees and employees of Allied Wingdings. Access to the site needs to be controlled based on user accounts.

Figure 1. Active Directory Federation Services makes it easy for users from these two business-to-business companies to access information in the other domain. (Click image to view larger version.)

This is easy to configure for users in the General Widgets forest because the Web server is in the same AD forest as the user accounts. Both companies have to add ADFS to a server running Windows 2003 to also allow Allied Wingdings users to authenticate with their regular logon credentials. Once they do this, the ADFS server on the resource site (General Widgets) recognizes credentials from the account side (Allied Wingdings) and creates the access tokens required by the Web application.

Even better, if General Widgets has multiple Web apps running on different servers, ADFS creates access tokens for all of them. Users are only asked for their credentials once, creating a single sign-on (SSO) experience. Once everything is set up, a purchase manager at Allied Wingdings logs on to his computer with his Allied Wingdings account and password. When he then connects to the General Widgets Web site to place an order for 100 Widgets, no separate authentication is required and no dialog box asks for a user name and password. Authentication will be as automatic and effortless as if he was using an internal Web application.

It sounds easy enough, but there's a catch. If your Web application isn't ADFS-aware, you have to create a "shadow account" in the resource domain for each user in the accounts domain. These shadow accounts do not require configuration, but setting them up can still be a lot of work. Things get easier if your Web application is ADFS-aware, but there are only few of those today. R2 includes a new version of SharePoint Services that will work with ADFS, and Microsoft has promised more. Also, because ADFS is standards-based, there will be more interoperability with third-party applications. As of today, though, you'll probably have a lot of configuration to do once ADFS is installed.

Authenticating Customers
ADFS can also be a huge help if you have customers that access your Web applications. Today you often have to create a separate AD forest to maintain accounts for these customers. R2 includes a new version of ADAM (Active Directory Application Mode) that lets you store these user accounts with much less infrastructure overhead than maintaining a whole AD forest. Because ADFS can create access tokens for user accounts that are defined in ADAM, you can create an SSO experience for your customers and control access to applications both for your organization's employees and your customers .

ADFS can use accounts from multiple sources and create access tokens for them and present these access tokens to one or more Web servers. Of course, configuring such an infrastructure works best if the Web applications are ADFS-aware. ADFS also requires customer accounts to be stored in AD or ADAM. If you're currently using AD to store user accounts for Web access, you should definitely look at how ADFS can simplify your life and create an SSO experience for your customers.

Active Directory and the DMZ
Many companies set up a DMZ for servers that need to be accessible from the Internet. As long as all user accounts for authenticated access are stored on domain controllers in the DMZ, and all domain controllers for this forest are in your DMZ, configuring authentication is easy.

But if you also want to use accounts in your internal forest to access DMZ resources, you have to choose between two methods, both of which erode the protection the DMZ is designed to provide. Regardless of whether you make DMZ servers members of an internal domain or create a trust relationship between internal and DMZ domains, you have to allow AD traffic across your firewall. This isn't a good solution—enabling AD communications across a firewall creates enough holes in the firewall to make it look like Swiss cheese.

ADFS can help in this scenario, too (see Figure 2). Instead of creating a trust relationship between a forest in the DMZ and an internal forest, use ADFS to handle the authentication. Doing this means that you have to open fewer ports in your firewall, and no user account information from your internal domain needs to be stored on servers in the DMZ; but employees with internal user accounts can still use DMZ-based Web applications and be seamlessly authenticated.

Figure 2. Since authentication happens in the DMZ, rather than internal domain controllers, Active Directory Federation Services can make your DMZ more effective, and your network more secure. (Click image to view larger version.)

Unix Integration
Many companies have a mixed Windows-Unix environment, and R2 promises to help integrate these two systems better by synchronizing user accounts and passwords.

Unix servers most often use NIS for centralized authentication; R2 maintains the NIS master database on a Windows domain controller, allowing you to use the same username and password to access all Windows and Unix servers. Password changes will be automatically synchronized between AD and NIS. This can be a great solution in an organization that primarily uses Windows but also has a number of Unix-based systems.

What You Can Do Now
If you think that ADFS or better Unix integration can help you solve current authentication challenges, you should take a look at Microsoft's R2 Web site, www.microsoft.com/windowsserver2003/r2/default.mspx, as soon as possible to download the public release that allows you to test the new features yourself. The site also has several whitepapers on ADFS, including a walkthrough document that lists the steps needed to set up ADFS in a test environment. Even if you don't see an immediate need for ADFS, you should take a look. I expect Windows-based Web applications to be increasingly ADFS-aware, turning this technology into a standard tool for configuring Web applications, including SharePoint. Exploring this technology now will make it easy to take advantage of what ADFS has to offer once there is broader application support.