GPO linked to one OU but being applied in another

[PreviousPoster]

Hi,

Firstly, my apologies if I'm in the wrong section - please redirect me & I'll happily follow suit.

This questin relates to deploying logon scripts with Group Policy. I've been tasked with creating a new logon script for our domain, using VBScript. This I've done, successfully linked it using Group Policy Management MMC, and tested it on some Win2k, WinXP & Vista desktops & laptops with no issues in GP deployment or script operation.

The logon script is applied under the User Configuration in the object, as I think it should be. The object is linked to sub-OUs which contain only desktops & laptops - I don't want this script running on servers. The Security Filtering is set to include only myself & a couple of other admins for now to (attempt to) limit the scope of the object.

My expectation was that the GPO would then only be applied to objects within those sub-OUs, and only where the user logged/logging on was in the Security Filtering.

However, I logged on to another machine - a Windows 2000 domain controller in another OU completely, a level up from these sub-OUs. Imagine my surprise when my script ran anyway!

Does anyone have any ideas on what I've configured wrong, or how to troubleshoot what GPOs are being applied to the Windows 2000 domain controller, in order to try & establish wth is going on?

Many thanks...

[JerryC]

Simply Stated GPOs with user settings in them must targeted at (or filtered to subsets of) user accounts. GPOs with computer settings in them must targeted at (or filtered to subsets of) machine accounts.

Filtering with Security Groups: They can reside in any OU anywhere in Active Directotry. Targeting a GPO at an OU that contains only a security doesn't get you there as there are no user or machine accounts in that OU to be targeted. When you use security group as filters, the machine accounts in the security group only apply to the computer settings and the user accounts in the security group apply only to the user settings.

========================================
Your Stated Situation
========================================
Not quite clear. There are GPO based settings available for Computer Startup or Shutdown scripts and User Logon or Logoff scripts.

Without special GPO processing parameters involving Loopback Policy processing being engaged, it is impossible to target a User Logon script at an OU containing only machine accounts and expect them to run (e.g. no user account targets). The reverse applies as well in that you cannot target Computer Startup scripts at OUs containing only user accounts (e.g. no machine account targets).

You stated

The logon script is ... linked to sub-OUs which contain only desktops & laptops - I don't want this script running on servers. The Security Filtering is set to include only myself & a couple of other admins for now to (attempt to) limit the scope of the object.

Are you sure it is a User Logon script or is it really a Computer Startup script? To figure out what is applying to your devices and where it is coming from, run the RSoP.msc command.

[PreviousPoster]

Thanks JerryC,

In answer to your question, yes, I'm certain it's a logon script - it's set at User Configuration>>Windows Settings>>Scripts (Logon & Logoff).

I understand what you're saying about the scope - if there are no user accounts in the targeted OUs, then it may not run - however it is running, the confusing fact is that it's running when I logon to machines in other OUs, given that that OU doesn't contain my account or have the GPO linked to it.

Also, I mentioned that the server whose policy I need to trace is Win 2000 Server; is it not the case that RSoP only runs on XP/Win2003?

Thanks again.

[JerryC]

For older devices, use gpresult /v from a command prompt:
[code:1]C:\>gpresult.exe /?

This tool displays the result of Group Policy for the current user and computer.
usage: gpresult [/V] [/S] [/C | /U] [/?]

/V Verbose mode
/S Super verbose mode
/C Computer settings only
/U User settings only[/code]
Look for the User Group Policy Loopback Processing mode setting to be Enabled within the Computer configuration section. If so, is it configured for Replace mode or Merge mode?

The only other explanation for why it runs is that the GPO that has the User Logon Script in it is located along the AD path to the machine accounts (e.g. a GPO located at the root of the domain would be like this). Trying to add filtering against those devices in that GPO would NOT prevent the User Logon Script from running for the "User" accounts logging onto those devices. [It would only prevent "Computer" settings in that GPO from running on those devices.]

This is all trying to explain the behavior, not giving advice on how to accomplish what you want. Is the following "What" you wish to accomplish?

==============================================
Target a User Logon script (VBScript) at specific user accounts in Active Directory, but do not have the script run when those same users log onto certain devices such as servers.
=============================================

Next, if that is your goal, is your AD OU designed in such a way that User Accounts, Desktop/laptop machine accounts, and server machine accounts are located in separate OUs? For example:[code:1]Domain
|
+ (1) User Accounts OUs
|
+ (2) Desktop\Latop Accounts OUs
|
+ (3) Server Accounts OUs
|
+ (4) Domain Controllers
|
+ (5) Other OUs[/code]or[code:1]Domain
|
+ (0) Parent OU
| |
| + (1) User Accounts OUs
| |
| + (2) Desktop\Latop Accounts OUs
| |
| + (3) Server Accounts OUs
|
+ (4) Domain COntrollers
|
+ (5) Other OUs[/code]
If so, then you'd link the GPO with the User Logon script to locations noted as (1) where the user accounts reside. Then, to filter out use of the logon script at Servers/DCs, you'd create a GPO that configures the Computer-side User Group Policy Loopback Processing Mode setting in Replace mode (prevents use of the normal User's AD path GPO settings) and link it to the locateds noted as (3) and (4). [Note: If you configure the loopback setting with Merge mode, then the User Logon script would still launch. Not what I think you want.]

An even better way to do this is to create separate Domain Admin or Server Admin accounts in a separate Privileged Accounts OU. Then Domain and Server admins would only use those accounts (never targeted with the logon script at all) to logon to those devices. This is a best security practice in the industry and enforces the Least Privilege principle. Then it's never an issue. You'd still have to implement the former process on server devices that support Windows Terminal Server/Citrix Metaframe (or any devices where you expect user's to log on directly).

[PreviousPoster]

Great stuff, JerryC.

My initial preparation for this & other work with Group Policy has been to structure AD much like example 2. As such, I think I'm tempted to use that approach with loopback processing.

Given our requirements for security - we do a lot of work on government contracts - we mostly do use specific admin accounts when logging on to servers, and those accounts are in an OU where the logon script won't be attached. However, we also occasionally have need to logon to them using our own accounts, usually in a hurry, so I need to blend both methods.

Many, many thanks for helping me with this, this area of deployment & scope is always the trickiest part.