Group Policy, Profiles, and IntelliMirror for Windows2003, WindowsXP, and Windows 2000 (Mark Minasi Windows Administrator Library)

Group Policy with Cross-Forest Trusts

Windows 2003 brings a new trust type to the table, a forest trust (also known as a cross-forest trust). The idea is that if you have multiple, unrelated forests, you can join their root domains with one single trust; then, any time new domains pop up in either forest, there is an automatically implied trust relationship.

To do this requires a large commitment from all parties involved. All domains must be in Windows 2003 Functional mode, and all forests must be in Windows 2003 Functional mode. Only then is it possible to create cross-forest trusts via the Active Directory Domains and Trusts utility. For an example of an organization that might use this, see Figure 3.6.

Figure 3.6: Here's one example of how a cross-forest trust can be used.

In this example, all domains trust all other domains via the cross-forest trust. Indeed, a user with an account housed in bigu.edu, say Sol Rosenberg, could sit down at a computer in either corp.com or widgets.corp.com, and log on to his user account, which is maintained in bigu.edu.

What Happens When Logging on to Different Clients Across a Cross-Forest Trust?

So what happens when Sol from bigu.edu has access to various computer types in the corp.com forest? Let's find out.

Logging on to Windows XP (with no Service Pack or with SP1) Across a Cross-Forest Trust

For users logging on to Windows XP machines in Windows 2003 domains, Group Policy across forests acts as if it were one big forest. For instance, if Sol Rosenberg logs into WIDGETS-XPPRO6 at widgets.corp.com or XPPR01 at corp.com, Sol would get the GPOs that affect his user account and the user policy settings that affect him. The Windows XP computer Sol uses will get the GPOs meant for it. (The computer would embrace the policy settings based on the site, the domain, and the OU it's in.)

Makes sense. Take a deep breath , and then read the next section.

Logging on to a Windows 2003 Server Across a Cross-Forest Trust

Here's where things get weird, so try to stay with me. Imagine that Sol Rosenberg in bigu.edu is also the SQL database administrator for a server named WS03-Servl over in corp.com in the Human Resources SQL-Servers OU. From time to time, Sol gets in his car and travels from the BigU campus over to the WS03-Servl computer sitting at the corp.com headquarters. He sits down, logs on locally to the console (where he's been granted access), and he doesn't get the GPOs meant for him (and therefore doesn't get his own policy settings).

Instead the server processes GPOs as if it was using Group Policy Loopback Processing ModeReplace Mode. What does this mean?

• The GPOs that would normally apply to Sol's user account in bigu.edu are ignored by the Windows 2003 server.

• The computer puts on an "I'm a user" hat and says, "Give me the GPOs that would apply to me if I were a user."

So, in our example, we can see that when Sol from bigu.edu logs on to WS03-Servl, his policy settings are ignored. The computer then looks at the GPOs that would apply to users in the Human Resources SQL-Servers OU (where the WS03-Serv1 account resides).

Since no GPOs linked to the Human Resources SQL-Servers OU contain policy settings geared for users, Sol gets no policy settings applied.

After logging on, you can check out the Application Event Log and see Event ID 1109, which states that Sol is "from a different forest logged onto this machine. Cross Forest Group Policy processing is disabled and loopback processing has been enforced in this forest for this user account."

Logging on to Windows 2000 Across a Cross-Forest Trust

Logging on to a Windows 2000 system with SP4 across the trusteither Server or Professional is just like logging on to Windows 2003 Server. That is, the GPOs that affect the user are ignored, and the computer processes Group Policy LoopbackReplace Mode.

Logging on to a Windows 2000 system that doesn't have SP4 (say, SP3 and earlier) across the trusteither Server or Professionalwill not perform loopback. The user will get the expected user settings, and the computer will get the expected computer settings.

Logging on to Windows XP with SP2 Across a Cross-Forest Trust

Logging on to Windows XP with SP2 installed across the trust is just like logging on to Windows 2003 Server (or Windows 2000 Professional with SP4). That is, GPOs that would normally affect users are ignored, and the computer processes Group Policy LoopbackReplace Mode. This might drive system administrators and CIO managers alike nuts.

Imagine that you are halfway through your Windows XP rollout, and then you add Windows XP plus SP2 to the mix. Users will definitely get different settings when logging on to these different machines. So, if things start going haywire, know what the score is by using the chart in the "Cross-Forest Trust Client Matrix" section later in this chapter.

At this point, you're likely scratching your head in disbelief. Why would Sol not get the GPOs that should affect him? The answer is simple: if Sol were assigned software (see Chapter 10), logon scripts, or other potentially dangerous settings, our machine's stability could be affected.

This mechanism protects our systems from stuff that we might not want to happen to it. Since we're not administrating Sol, we don't know what potential harm Sol's settings might do. Then, we need to examine what might happen if the folks at Microsoft decided to do things differently, say, have no GPOs affect Sol when he uses our corp.com machines. That might have been really bad too, because then Sol would have free reign to do whatever he wanted.

So what does Loopback buy us? Loopback makes us think about what happens when users from afar use our systems. Even though, as you know, user policy settings don't affect computers, you can start to design your OUs and GPOs for this occasion. That is, if you setup user policy settings in OUs that just contain servers, and someone in a foreign domain logs on, they'll at least get the user policy settings you intend not what their administrator wanted.

Strange ? Yes, but it works, and this becomes strangely more logical the more you think about it.

What about workstation machines? This is a less-critical problem on workstation machines, because, well, it's just a workstation. If someone is assigned an application (see Chapter 10) that maybe does evil stuff, at least it's only affecting a workstation, not a server that a whole team might have access to.

I have more advice on how to manage this in the "Disabling Loopback Processing When Using Cross-Forest Trusts" section later in this chapter.

Disabling Loopback Processing When Using Cross-Forest Trusts

If you do not want the default behavior, which is that Loopback Replace processing is enabled for the computer, you can set a specific Group Policy to apply to the computers you want to be normal again. Here are my recommendations:

• Keep the default behavior for all servers: Windows 2000 Server + SP4 and Windows 2003 Server. You want them to process in Group Policy LoopbackReplace Mode.

• Return the "normal" behavior for all workstations: Windows 2000 + SP4 and Windows Xp + SP2. Windows 2000 + SP3 (and earlier) and Windows XP + SP1 (and no service pack) are already at the "normal" behavior. You want them to process GPOs using regular processing rules.

To do this, you need to locate the Allow Cross-Forest User Policy and Roaming User Profiles policy setting. Drill down through Computer Configuration ˜ Administrative Templates ˜ System ˜ Group Policy. To set it up, follow these steps:

1. Create a new GPO at the domain level, say, "No Loopback for Cross-Forest." Enable the policy setting named Allow Cross-Forest User Policy and Roaming User Profiles . This will initially affect all computers, including servers.

   However, I suggest that you filter out your server machines so that they keep the default loopback behavior. I suggest you do this as follows :

2. Create a security group called "AllMyServers."

3. Add all the Windows 2000 and Windows 2003 servers (regardless of service pack) in the domain to the AllMyServers group.

4. Deny the AllMyServers group the ability to process this new GPO.

This will maintain the loopback behavior for servers, but go back to normal processing for absolutely all workstations in the domain. This way your servers are protected from other users in trusted forests from potentially doing bad stuff to your servers. But those same users are free to have normal processing on all your workstations.

Cross-Forest Trust Client Matrix

If your head is spinning about what happens to users when they use a specific client across a cross-forest trust, this table is for you. Additionally, Table 3.1 shows which client systems can be set back to normal processing by enabling the Allow Cross-Forest User Policy and Roaming User Profiles policy setting.

Understanding Cross-Forest Trust Permissions

Windows 2003 cross-forest trusts have two modes: Forest-wide Authentication and Selective Authentication, as shown in Figure 3.7. To view the screen shown in Figure 3.7, open Active Directory Domains and Trusts, locate the properties of the trust, click the Authentication tab.

Figure 3.7: You can set Forest-Wide Authentication or Selective Authentication.

In a Windows 2003 Active Directory domain, Full Authentication mode permits Group Policy across forests to act as if it were one big forest. That is, GPOs are processed according to Table 3.1.

We already know that Sol is the SQL database administrator over at corp.com, and we saw what happened when he logged on to the Windows 2003 member server WS03-Serv1. Twice a week, however, Sol works at widgets.corp.com on the WIDGETS-XPPRO3 for some CAD work. Then, the unthinkable happens.

An attack originating at bigu.edu upon corp.com's computers gets the two domain administrators in a heated battle. The corp.com Domain Administrator decides he wants to prevent attacks from bigu.edu, so he enables "Selective Authentication." Now no one from bigu.edu can log on to any of the machines in corp.com or widgets.corp.com. Ergo, Sol will not be able to log on to either his WS03-Serv1 Windows 2003 member server in corp.com or to his WIDGETS-XPPRO3 machine in widgets.corp.com. Sol needs the "Allowed to Authenticate" right on the computer objects he will use. In this example, you can see what is done for WIDGETS-XPPRO3, as shown in Figure 3.8.

Figure 3.8: You need to specifically grant the "Allowed to Authenticate" right in order for Sol to use this machine.

Additional computers in corp.com and widgets.corp.com need these explicit rights if anyone else from bigu.edu is going to use them. Then, Group Policy will process as described earlier and summarized in Table 3.1.