Ask Us About... Security, January 2001

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

by Joel Scambray

"Happy New Year!" from AUAS as we start off by answering your Microsoft Windows® security questions during the (actual) first year of the new millennium.

On This Page

The Unit of Trust: a Forest

The Unit of Trust: a Forest

Q: Is there any way to remove the built-in Enterprise Admins group from a forest? We are currently a single forest/domain that wishes to join a separate forest. Due to security, however, we cannot allow for the possibility of being compromised by a higher level Enterprise Admin.

A: In short, no. The Windows 2000 user interface won't even let you delete the Enterprise Admins group because it is a built-in group.

And it's not just the Enterprise Admins you have to worry about—consider Schema Admins, as well as Domain Admins from all other domains within the forest as well. A little-known fact about Windows 2000 Active Directory® directory service forests is that "domain administrators of any domain in the forest have the potential to take ownership and modify any information in the Configuration container of Active Directory. These changes will be available and replicate to all domain controllers in the forest. Therefore, for any domain that is joined to the forest, you must consider that the domain administrator of that domain is trusted as an equal to any other domain administrator" (Windows 2000 Server Resource Kit Deployment Planning Guide).

This is a departure from Microsoft Windows NT®–style domains, which delineated security boundaries. Not so in Windows 2000, where the security boundary is the forest, which can encompass multiple domains. This may seem scary; but recall that trust relationships only create the potential for inter-domain access—they do not explicitly enable it. A trust relationship is thus often explained as "building a bridge without lifting the toll gate." For example, a trusting domain may use security principles (users or groups) from the trusted domain to populate access control lists (ACLs) on resources, but this is only at the discretion of the administrators of the trusting domain and is not inherently set up.

In general, the Deployment Planning Guide suggests that the following situations might necessitate the creation of more than one forest. (The following material is quoted directly from the Deployment Planning Guide.)

If individual organizations:

• Do not trust each other's administrators. A representation of every object in the forest resides in the global catalog. It is possible for an administrator who has been delegated the ability to create objects to intentionally or unintentionally create a "denial of service" condition. You can create this condition by rapidly creating or deleting objects, thus causing a large amount of replication to the global catalog. Excessive replication can waste network bandwidth and slow down global catalog servers as they spend time to process replication.

• Cannot agree on a forest change policy. Schema changes, configuration changes, and the addition of new domains to a forest have forest-wide impact. Each of the organizations in a forest must agree on a process for implementing these changes, and on the membership of the schema administrators and enterprise administrators groups. If organizations cannot agree on a common policy, they cannot share the same forest.

• Want to limit the scope of a trust relationship. Every domain in a forest trusts every other domain in the forest. Every user in the forest can be included in a group membership or appear on an access control list on any computer in the forest. If you want to prevent certain users from ever being granted permissions to certain resources, then those users must reside in a different forest than the resources. If necessary, you can use explicit trust relationships to allow those users to be granted access to resources in specific domains.

If you are unable to yield administrative control, then I suggest that you maintain your current separate forests. Of course, you then lose all the benefits of a unified forest model, such as a shared Global Catalog and directory object space, and you also add the overhead of managing an additional forest. This is a good illustration of the trade-off between convenience and security.

The Flip Side: Can I Trust an Internet-Facing Domain?

I am also often asked the opposite question: Is it pertinent to create a separate forest in order to add semi-trusted domains to the organization? This question is especially pertinent to creating a domain that will be accessible from the Internet, say for a Web server farm. This situation can be handled in one of two ways.

One option is to create a separate forest/domain and establish old-style, explicit one-way trust to a domain within the main forest to protect it from potential compromise of the Internet-facing forest/domain. But again, you would lose the benefit of a shared directory across all domains in this scenario, while gaining the burden of multi-forest management.

The second option is to collapse the Internet-facing domain into an Organizational Unit (OU) within a domain that is administrated by trusted personnel. The administrator of the OU can then be delegated control over only those objects that are resident in the OU. Even if that account becomes compromised, the damage to the rest of the forest is limited.

DCOM Through Firewalls

Q: Can you list the precautions and actions to be taken when Internet Information Services (IIS) talks on the backend to a business logic server running on Windows 2000 using DCOM through a firewall?

A: This is a common question. Most Web administrators are so focused on making back-end connectivity work efficiently that they forget security basics. I'm glad to see you're not making this mistake!

You seem to have made the first decision correctly, which is to erect a firewall between the Web server and any other business logic. Since it sits at the outermost presentation layer in standard n-tier models of Internet commerce, Web servers are often the first domino to fall to malicious Internet hackers. I would always consider networks containing Web servers to be semi-trusted at best. By establishing strong network access control between the Web farm and any other systems, you greatly reduce risk that an attacker who manages to compromise a Web server will "island-hop" to other vulnerable systems within your internal infrastructure. (I assume that you also have a firewall in front of the Web server as well, or that it sits in a perimeter network (also known as DMZ, demilitarized zone, and screened subnet).)

Using DCOM further reduces this risk by sealing the logic of the interaction between the Web server and the internal business logic server. Unlike text-based scripts that contain clear text passwords, well-written COM objects are much more difficult to usurp for malicious purposes in the scenario where an attacker gains control of the Web server.

OK, now that I've told you what you've done right, let's discuss what can be done to lock things down even further. Because it dynamically allocates ports for applications in the range of 1024 - 65535, DCOM has traditionally proved challenging to integrate with firewalls. In addition, the endpoint mapper that hands off client requests to the assigned port runs on port 135 (TCP and UDP), which is also typically blocked by standard firewall policies. You could make an exception in this case and allow TCP port 135 between the Web server and internal application server. Then configure DCOM to use only TCP and a restricted range of TCP ports according to the 1998 paper" Using Distributed COM with Firewalls" from the Microsoft Developer Network (MSDN®) library.

Another option is to use the Tunneling Transmission Control Protocol, a DCOM transport protocol that became available with Windows NT 4 Service Pack 4 (SP4). Tunneling TCP operates entirely over TCP port 80 and is thus quite easily passed through firewalls. Two considerations here: one, the firewall will not be able to do any application-level filtering of the TCP 80 stream if you are using Tunneling TCP, or it will break the connection. Two, let me re-emphasize that communications should be restricted by IP address to only those servers necessary; opening port 80 from the entire PERIMETER NETWORK to the entire internal network is a no-no.

Assuming that you are not using TCP 80 for other communications, Tunneling TCP is probably your best bet because it only requires one port to be opened on the internal firewall. Consult the above referenced paper on Tunneling TCP for tips on proper configuration.

More Win32 SSH2 Server Products, and That's a Wrap

Before we tidy up this month's Q&A, I wanted to note a new development pointed out by a reader of a past column about Win32 Secure Shell (SSH)–based tools. In that column, I described a free Win32 SSH server and noted that commercial implementations were not available for Windows at the time. It looks like some vendors have been reading my column, as a reader recently informed me that the folks who helped define the SSH standard, SSH Communications Security, just announced Secure Shell for Windows Servers, a Windows NT 4/Windows 2000–compatible SSH2 server implementation for secure terminal connections and file transfer that was slated to be available on December 22, 2000. In last month's column, I noted that Van Dyke Technologies was in beta 2 for their Win32 SSH2 server Vshell. The official 1.0 release of VShell is now available free for 60-day evaluation, after which it costs from $249 to $799 through January 31, 2001. My discussion of these products is not meant as an endorsement of any particular vendor's implementation, but I strongly feel that readers should be keenly aware of the secure remote management features of SSH and the growing availability of options for Win32 SSH servers.

Next month, more of your questions are answered. In the meantime, check out Microsoft Internet Security and Acceleration (ISA) Server, Microsoft's recently announced firewall product. I've been playing with it recently and find it quite robust from a features perspective. Let me know what you think in the AUAS mailbox.

Joel Scambray is a Principal of Foundstone. He is co-author of Hacking Exposed: Network Security Secrets & Solutions, Second Edition, from Osborne-McGraw Hill.

Send your Security questions to the Ask Us About Security mailbox. If your question is selected, you will see your answer in a forthcoming column.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.