Access Denied: Overriding a Trust Relationship Within a Forest
You can't disable the trust relationship between domains within a forest, but you can use the deny logon user rights to effectively override it.
June 15, 2003
All domains in a forest implicitly trust one another, but for regulatory reasons relevant to our industry, we can't let DomainA in our forest access DomainB. How can we make trust relationships between domains more granular?
You can't disable the trust relationship between domains in the same forest. However, Windows 2000's Deny logon user rights let you prevent a group of users from connecting to resources on a computer. Simply assign the Deny access to this computer from the network and Deny logon locally rights to DomainA's Domain Users group. Make the assignment in a Group Policy Object (GPO) linked to DomainA's root, and flag the GPO link as No Override.
To use Group Policy to configure the assignment, open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, right-click the domain root, and select Properties. Select the Group Policy tab and click New. Change the name of the new GPO to Mandatory Policies; select Options, No Override; then click OK. The No Override option directs Win2K to apply the settings that are defined in that GPO to all computers and ignore conflicting policies defined in GPOs on subordinate organizational units (OUs). No Override also takes precedence over any OUs for which you've enabled Block Policy Inheritance. Next, click Edit and navigate to Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment. Find the Deny access to this computer from the network and Deny logon locally rights, and grant them to the Domain Users group of the domain you want to exclude. Now, no computer in your domain will let any user from the untrusted domain log on at the console or connect over the network.
You can also use rights to make a single trust relationship more granular. For example, say your R&D domain trusts the CORP domain so that manufacturing requirements planners in the CORP domain can access plans for future products in the R&D domain. No one else in CORP needs access to anything in R&D. Create the Mandatory Policies GPO as I described, then grant Logon locally and Access this computer from the network rights only to R&DDomain Users and CORPMRPPlanners.
The Deny logon user rights apply only to resources that the Server service provides, including shared folders, shared printers, and other resources you view through the MMC Computer Management snap-in. Services that you can't access through the Computer Management snap-in, such as Telnet, Terminal Services, FTP, and WWW Publishing Service, and applications, such as Microsoft SQL Server, Microsoft Exchange Server, Oracle, and SAP R/3, might allow access despite the rights assignments. You need to identify other services that are available in your domain and take measures to block the untrusted domain from accessing them. For some services that are well integrated with Win2K security, such as Telnet and Terminal Services, you can simply make sure that you don't let the Domain Users group from the untrusted domain access the services. In the case of Telnet, create a group called TelnetClients and make sure it doesn't contain users or groups from the untrusted domain. For Terminal Services on Windows Server 2003, you can control user access through the new Allow logon through Terminal Services right. For Win2K, you'll need to deny the Domain Users group Full Control to the Connection object through the MMC Terminal Services Configuration snap-in.
If the untrusted domain corresponds to one or more IP subnets, alternative approaches are to install an internal firewall (e.g., a packet-filtering router) that blocks connections from that domain or to deploy to all the computers in your domain an IP Security (IPSec) policy that blocks packets from any computer that's in a subnet belonging to the untrusted domain. If you use one of these alternatives, make sure that domain controllers (DCs) in your domain don't replicate with DCs in the untrusted domain, or replication failures will result. You can use the MMC Active Directory Sites and Services snap-in to view and reroute replication connections.
About the Author
You May Also Like