• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 388
  • Last Modified:

Question on loopback processing

Hi,

I have my domain structure something like below.
<domain>
  | -- User GPOs are attached here
  |
  |---<Site> (there are few user GPOs attached to the sites also)
         | --- <Users Container>
         | --- <Special Computers OU>
         |---- <Computers OU>

 I want to execute a logoff script on special computers when ever a user login to that. I have several computer/user policies configured at domain and site level. I created and linked new GPO(logoff scripts) on Special computers OU with loopback (merge) mode enabled and logoff script configured. But the problem is that, when a user is logging into the special computer, I can see from RSOP that user related policies are getting processed two times. I know the reason for this - in merge mode, when the user is logging in, first all the user policies will get applied and then computer process all the policies to which it has access and has user settings and applies the settings to user(that is what meant by merge mode). Because of this behavior, all the user policies are getting applied twice on special computers. So, I have denied read/apply access to special computers on User GPOs which are at domain and site level. But to my surprise, they are still getting applied though computers are denied to read/apply.

Any one has idea why it is happening like this? I couldn't find any traces of this problem.

Thanks




0
deshaw
Asked:
deshaw
  • 7
  • 4
  • 4
  • +1
5 Solutions
 
AkhaterCommented:
why don't you just apply loopback in replace mode if you just want the special computer OU policies to be applied or block inheritance on the special computers ou level
0
 
deshawAuthor Commented:
Akhater, the reason I didn't use replace mode is, the users should get all remaning policies configured at domain and site level along with the logoff script configured in loopback enabled GPO.
0
 
AkhaterCommented:
well ur script is a user policy denying the computer shouldn't have any effect
 so why not change a bit ur OU structure
0
Easily manage email signatures in Office 365

Managing email signatures in Office 365 can be a challenging task if you don't have the right tool. CodeTwo Email Signatures for Office 365 will help you implement a unified email signature look, no matter what email client is used by users. Test it for free!

 
deshawAuthor Commented:
>well ur script is a user policy denying the computer shouldn't have any effect
I am thinking that, computer is responsible for reading the GPOs which has user settigs. Do you think in other way? I understood this from below references.
References :
------------
        http://osdir.com/ml/activedir/2006-01/msg00322.html 
        http://articles.techrepublic.com.com/5100-10878_11-1055139.html 
        http://www.frickelsoft.net/blog/?p=63
 >so why not change a bit ur OU structure
Changing the OU structure is not a solution for me because we have lot of Dependencies
0
 
AkhaterCommented:
To be honest I've never had to deal with that specific case so we are just thinking out loud,

My understanding is that you've added all computers in the "special computers" OU to a group and you've denied "apply group policy" permission for that group on the logon script assigned at the domain level ?
0
 
AkhaterCommented:
thinking a little bit more you can modify your first logon script (the one on the domain level) to check the OU of the computer it is running on, if that computer is in the "special computers" OU exit

something like

$OU = Retrieve local computer OU
if $ou != "special computers"
your script
else
nothing

0
 
bluntTonyCommented:
This behavious is by design. The reason that denying the computer accounts read and apply permission to user GPOs hasn't made any difference is because computers don't read user GPO's anyway.
The only time user settings are applyed to computer-linked GPOs is in the case of loopback. As you ave mentioned, in merge mode, the process is:
1. On computer startup, the machine reads all the computer settings in GPOs it inherits.
2. On user login, the user settings from all GPOs the user inherits are applied.
3. Aftwerwards, the user settings on GPOs inherited by the computer are then applied.
All three sections are reading different policies, so they are all required to confiugre the user enviornment correctly. The loopback user settings are applied lastly in order for them to 'over-rule' any conflicting settings applied in stage 2.
I don't think this is a problem. If you are experiencing slow login, startup, you can consider consolidating GPOs (the less GPOs read the quicker it becomes) and disabling un-used sections of GPOs (i.e. disable user settings on GPOs applied to computers).
Let me know if I have misunderstood.
0
 
deshawAuthor Commented:
>My understanding is that you've added all computers in the "special computers"
>OU to a group and you've denied "apply group policy" permission for that group
>on the logon script assigned at the domain level ?
Yes, you are right.
And I can not think of educating logoff scripts because, I have few environmental limitations which are stopping me.
0
 
AkhaterCommented:
well i think you are stuck because when we do policy filtering using implicit deny you remove Apply Group Policy to authenticate users and yu allow it only to the group required, and it gets applied to the user even if the computer doesn't have read and applu group policy settings, so I guess what I said previously was right,

In case you want to change your login script here is how to retreive the computer OU in VBS

Set objSysInfo = CreateObject("ADSystemInfo")
 
strComputerName = objSysInfo.ComputerName
 
Set objComputer = GetObject("LDAP://" & strComputerName)
 
strOUName = objComputer.Parent
 
Set objOU = GetObject(strOUName)
 
wscript.echo objou.name

Open in new window

0
 
bluntTonyCommented:
If you want to just apply the logoff script to all users, at domain level, the VB logic is below. Basically the script will only perform the required actions if the current machine is in the OU. Then you don't have to worry about loopback.
Hope this helps...

Set oAdInfo = CreateObject("ADSystemInfo")
Set objPC = GetObject("LDAP://" & oAdInfo.ComputerName)
strOU = "OU=Special Computers"
If Left(objPC.Parent,Len(strOU)) = strOU Then
	'YOUR SCRIPT GOES HERE
	'.
	'.
End if

Open in new window

0
 
bluntTonyCommented:
Sorry akhater - didn't refresh!!
0
 
AkhaterCommented:
no prob :) neither did I
0
 
deshawAuthor Commented:
I want to get more clarity on below point:
>3. Aftwerwards, the user settings on GPOs inherited by the computer are then applied.
Is user account is responsible for reading the GPOs list of computer or computer account is responsible for reading the GPO list of it's own? I think the later because, computer account only known to which it has permissions. Please correct me if I am wrong.
0
 
AkhaterCommented:
I have no reference to backup my words however assuming you want a user policy 1 to apply to only group 1

what you will do is go to the security settings of "Group Policy 1" remove apply group policy settings to the "Authenticated users" add "Group 1" and give the latter "Apply Group Policy"

obviously in "Group 1" you have only the users you want that policy to apply to.

So these users are apply "Group Policy 1" even if the computers they are logging on to have no "Apply Group Policy" Permissions.

So my logic says that it is the user that reading the policy in case of a user policy
0
 
AmericomCommented:
I know its tough to read everything from blackberry. But my understanding is you are trying to have two GPOs, one for logon and one for logoff. The logon GPO has linked to the domain level. You also want users to run logoff script when logging off from the special computers. If that's the case, you only need to configure your logoff GPO in the user configuration section and enable the loopback process in the computer section and link thud logoff GPO to the special computers OU. Unless I am missing something...
0
 
bluntTonyCommented:
Americom is correct - this is basically what I have said, and I think what you already have setup.
I don't think you have a problem, the behaviour we have discussed is by design (unless I am also missing someting :-) ). In answer to your last question, yes, I think it is the computer which applies the second lot of user settings (part 3 of my earlier post).
This set up is normal, and unless you are actually experiencing problems then it's all working as it should. If you would rather not use loopback processing, you can use a simple decision structure in your script (as posted earlier) to check the machine's parent OU in order to decide whether to go ahead and run the script. If you apply this script to an OU already linked to all the required users through GPO inheritence, then this would reduce your processing overhead, as you're not creating anything extra to read during startup or login.
In addition, I would always primarily use the OU structure to administer what GPOs apply to what user/computers. Only use security filtering when the OU structure can no longer provide you with this.
Hope this explains....
0

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

  • 7
  • 4
  • 4
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now