Block GPO across trusted domains

[andrea cuozzo]

Hello,

I'd like to block GPO application over users that logon to a trusted domain
from a trusting workstation; here's my situation:

1. domain B (win2k3) trusts domain A (win2k3)
2. user MYTEST belongs to domain A, and to the TEST ou
3. a GPO is applied on the TEST ou in domain A that maps a network drive via
a wsh script
4. workstation MYWKS belongs to domain B

when user MYTEST logs on to the A domain on the MYWKS computer, the GPOs
from domain A get applied to it, and the map drive script runs. Is there a
way to prevent GPO application if the user is logging from a trusted domain
? (eg. if loggin from domain B then don't block domain A GPO application ?)

thanxs

andrea

[Darren Mar-Elia]

The simplest solution I can think of is to remove the Authenticated Users
ACE on that GPO and replace it with the Domain Users group from the trusted
domain. The only issue with this is that Authenticated Users covers computer
accounts as well, so if you have any computer-specific policy in that GPO,
you'll need to add the Domain Computers group as well as Domain Users.

Hope that helps.

--
Darren Mar-Elia
MS-MVP-Windows Management
http://www.gpoguy.com

"andrea cuozzo" <andrea...@hotmail.com> wrote in message
news:uu01CD0c...@TK2MSFTNGP09.phx.gbl...

[andrea cuozzo]

Darren, thanks for the answer, but (as a loyal subscriber of Windows .NET
Magazine) let me abuse of yout patience and try to make my question clearer:

- Domain B (win2k3) trusts domain A (win2k3) with a mono-directional
external trust (completely different namespaces)
- On Domain A. users are subjected to several policies
- On Domain B is a Terminal Server (with Citrix) with a loopback policy (in
replace mode) applied to its computer account, that removes items from the
desktop (among other configurations)
- When a user from domain A logs on to the Terminal Server he sees the
effect of the loopback policy, but also the effect of the policies applied
on domain A (a logon script, in my case). I'm the administrator of domain B,
responsible for the availability of terminal server applications, and I
wouldn't like to find out that a change in the policy from domain A (for
instance, new software installation) may interfere with my servers.
So my desire is to (somehow) block the application of policies coming from
domain A when the user logs on to the Terminal Server, and I thought that
loopback configuration was exactly what I needed, but instead policies from
domain A still seem to get applied.

thanx again

andrea

"Darren Mar-Elia" <dmano...@discussions.microsoft.com> ha scritto nel
messaggio news:Ovmt0k2...@TK2MSFTNGP10.phx.gbl...

[Darren Mar-Elia]

Andrea-
So it sounds like something is broken. If you're truly using loopback
replace mode (I would double-check that by running gpresult on the client)
then you shouldn't see any user policy from domain A unless its a preference
that isn't getting removed. Specifically what policies from domain A are you
getting? Are they Admin. Template policies or other?

--
Darren Mar-Elia
MS-MVP-Windows Management
http://www.gpoguy.com

"andrea cuozzo" <andrea...@hotmail.com> wrote in message

news:O%23aVCiBd...@TK2MSFTNGP12.phx.gbl...

[andreacuozzo]

Darren,

I've checked with gpresult and RSOP and it looks like all of the policies
from domain A don't get applied, except for the following one:

User Configuration --> Windows Settings --> Scripts (Logon-Logoff) -->
Logon --> main.vbs

I'll try to find why this single settings gets applied (I looked over the
site link object, but there's no policy applied to it)

thanxs again

andrea

"Darren Mar-Elia" <dmano...@discussions.microsoft.com> wrote in message
news:edcjpRDd...@tk2msftngp13.phx.gbl...

[Darren Mar-Elia]

Andrea-
Ok, logon scripts should be undone in this scenario but maybe its a bug.
Here's what I would do. On the workstation, while logged on as a user having
this problem, go into the registry under
HKCU\Software\Policies\Microsoft\Windows\System\Scripts. Do you see a
reference to your errant logon script there? If so, then that is the
problem--what should happen is that this should get removed when the user
logs on. Try removing it manually and see if it changes at next logon.

--
Darren Mar-Elia
MS-MVP-Windows Management
http://www.gpoguy.com

"andreacuozzo" <andrea...@hotmail.com> wrote in message
news:OFvXtTHd...@TK2MSFTNGP09.phx.gbl...

[andreacuozzo]

Hi Darren,

while logged on as the user, I looked for the registry path you pointed me
to and found the registry value:

Script=Main.vbs

under the following key:

HKCU\Software\Policies\Microsoft\Windows\System\Scripts\Logon\0\0

until yesterday, the main.vbs script got run and timed-out after some
minutes with a wsh error message (the evidence that it was running); now it
looks like it is not running anymore (or not crashing anymore, but the
chances that the main.vbs script has been modified are very low). I looked
on two clients computer's registry (windows 2000 Professional) and found out
that the logon script registry value is a little different:

path: HKCU\Software\Policies\Microsoft\Windows\System\Scripts\

value: Logon =
\\domain.loc\SysVol\domain.loc\Policies\{R1BAC28F-0E86-42C6-6BA3-LA036E69EB8
3}\User\Scripts

in the script folder, under
\\domain.loc\SysVol\domain.loc\Policies\{R1BAC28F-0E86-42C6-6BA3-LA036E69EB8
3}\User\Scripts, is a script.ini file, like this:

[Logon]
0CmdLine=Main.vbs
0Parameters=/l /d:m /v /o:"Domain.loc"
[Logoff]
0CmdLine=LogoutNotes.exe
0Parameters=
1CmdLine=Logout.vbs
1Parameters=

and two foders, Logon and Logoff, with the scripts inside.

I'm wondering if the differences in the registry keys are because of the
operating system (Windows 2003 Ent Ed. and Windows 2000 Pro), or if the 0\0
registry path added on the W2K3 is something that can be read as "disabled".

thanx again

andrea

"Darren Mar-Elia" <dmano...@discussions.microsoft.com> wrote in message
news:eTDv$DOdEH...@TK2MSFTNGP12.phx.gbl...