Minor nit below. Otherwise, spot on
observations.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matt Hargraves
Sent: Friday, October 06, 2006 7:56 AM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Assign User rights overs computers with AD
Just to cover some things:
GPOs can make adjustments to computer *or* user object policies. The only way to override these settings is to use the 'loopback processing' option (this can be ugly and I prefer to avoid it). If you have computer settings set on a GPO on an OU, it will only apply to computer objects within that OU, user settings only apply to users within that OU (again, excepting loopback processing within that GPO). This is one of the big reasons why people usually only put computer *or* user objects within a particular OU. It allows you to disable the portion of the GPO that isn't going to get applied to the objects within the OU (disable user settings on GPOs for computer OUs - unless you're using loopback processing and disable computer settings for GPOs on user OUs). There's really no reason to have a computer downloading user settings when it's not necessary and vice-versa.
GPOs can make adjustments to computer *or* user object policies. The only way to override these settings is to use the 'loopback processing' option (this can be ugly and I prefer to avoid it). If you have computer settings set on a GPO on an OU, it will only apply to computer objects within that OU, user settings only apply to users within that OU (again, excepting loopback processing within that GPO). This is one of the big reasons why people usually only put computer *or* user objects within a particular OU. It allows you to disable the portion of the GPO that isn't going to get applied to the objects within the OU (disable user settings on GPOs for computer OUs - unless you're using loopback processing and disable computer settings for GPOs on user OUs). There's really no reason to have a computer downloading user settings when it's not necessary and vice-versa.
This
won't happen regardless. A computer account would never "download" user settings, even if the user side
of a GPO is enabled. Disabling a GPO side is somewhat meaningless because if the
side has no policy in it (i.e. its version is 0) then it won't be processed
anyway. The only time this is useful is if you have settings on a side and you,
for whatever reason, don't want them to be processed. Its kind of a way of
blocking settings that would otherwise be applied by disabling them.
This way, you end up with managing your computer settings separately from your user settings. Common computer settings: Disabling security-related settings, adjusting auditing (event logs, etc....) ACLing directories. Common user settings: Setting environmental variables (default home page, home directory, application settings like Office settings, etc...). Usually the only time you want to put user settings on a computer OU (and enable loopback processing) is for kiosk type computers and then you probably want to make sure that you do something to make sure that it doesn't apply for Administrators. It's usually easier to put these settings on an OU for accounts that will be used for that type of workstation though, so you don't have to worry about loopback.
As many other people stated though, trying to restrict administrators on workstations will as often as not end up with a series of headaches because of applications that require the user to be a local administrator on the computer. Whether this is because of poor programming on the part of the application developers or something else, it doesn't matter. Unless you know that your users won't need to be local admins, you may want to handle this in a very controlled and well tested manner, possibly testing all of your applications with a non-admin account before pushing this setting out to the users.
This way, you end up with managing your computer settings separately from your user settings. Common computer settings: Disabling security-related settings, adjusting auditing (event logs, etc....) ACLing directories. Common user settings: Setting environmental variables (default home page, home directory, application settings like Office settings, etc...). Usually the only time you want to put user settings on a computer OU (and enable loopback processing) is for kiosk type computers and then you probably want to make sure that you do something to make sure that it doesn't apply for Administrators. It's usually easier to put these settings on an OU for accounts that will be used for that type of workstation though, so you don't have to worry about loopback.
As many other people stated though, trying to restrict administrators on workstations will as often as not end up with a series of headaches because of applications that require the user to be a local administrator on the computer. Whether this is because of poor programming on the part of the application developers or something else, it doesn't matter. Unless you know that your users won't need to be local admins, you may want to handle this in a very controlled and well tested manner, possibly testing all of your applications with a non-admin account before pushing this setting out to the users.
On 9/29/06, Dave Wade
<[EMAIL PROTECTED]>
wrote:
I know its over a week since I sent this, but on thinking its probably worth expanding on this. The OU structure is in place to provide two functions:-1) Delegation of management and administration.2) Application of Group PolicyNow because the OU structure is the "ONLY" way <unless you use some added value tool> to provide delegated admin, that needs to be the "Primary" driver when designing the OU Structure.So if you want different people managing Computer and Users, and like me.you like to keep the user and computer policies separate, it makes sense to have Computers and Users in separate OU trees. Because you can't apply a GPO to the "Users" and "Computers" containers it also makes sense not to use these OU.s.On the other hand if you have a very devolved management structure, and you are happy with devolved management of the users and computers, then it might make sense to have an OU tree where the top levels represent management units and you store both computers and users in these trees.Personally I don't like this approach, but for some organization structures it may be better...Dave.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dave Wade
Sent: 23 September 2006 20:50
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Assign User rights overs computers with ADI usually move them out as you can't apply GPO at the "computers" level...
From: [EMAIL PROTECTED] on behalf of Alberto Oviedo
Sent: Fri 22/09/2006 22:40
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Assign User rights overs computers with ADHey Dave. Do you mean separate trees under root "computers"? or Create different OU's for computers?
On 9/22/06, Al Mulnick < [EMAIL PROTECTED]> wrote:Separate "Trees"? That seems a little excessive. Or are we just mixing terms?
On 9/21/06, Dave Wade < [EMAIL PROTECTED]> wrote:I prefer to keep them in seperate trees. In fact we are just doing that at present...
________________________________
From: [EMAIL PROTECTED] on behalf of Alberto Oviedo
Sent: Thu 21/09/2006 17:50
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Assign User rights overs computers with AD
Thanks for your help. really useful.
Is it a good practice to move computer objects to OU where the user of the computer resides?
On 9/20/06, Dave Wade <[EMAIL PROTECTED]> wrote:
Alberto,
Even though we made our users "PowerUsers" we found that we needed to make a number of "tweaks" to cater for poorly written applications. I think we now have about a dozen settings for various ill-behaved applications. The majority of these are to cater for applications that write to places on the "C" drive (other than the windows folders, of course) where applications should not write. We also refreshed permissions on the "all users" profile to make sure users don't delete items from the "all users" desktop or start-menu.
I guess the last thing to note is that we rolled the policy out in manageable chunks of PCs, say 100 at a time, so if there were issues we could cope with the service calls,
Hope this is useful,
Dave.
________________________________
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Al Mulnick
Sent: 20 September 2006 14:13
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Assign User rights overs computers with AD
You can, but I've yet to see it be so simple. The information you're looking for is "restricted groups" but I HIGHLY advise you to be careful and to TEST that prior to using it on your workstations. I also highly advise that you only apply that type of setting to workstations and not on servers (separate them into different OU's).
Another way to do this is with a logon script that adds an account to the local administrators group and removes the user from that group.
The testing is a way to ensure that you don't break applications on the workstations. Some of the more poorly written applications require special access and as a default prefer administrative access rights. They work poorly without them. You'll want to test thoroughly so that you can remove the unneeded rights and still allow your user community to work as expected.
I'm sure there's more cautions I can suggest, but you get the idea.
On 9/20/06, Alberto Oviedo < [EMAIL PROTECTED] > wrote:
Hello. My name is Alberto, I'm from Nicaragua
In our company the support team has granted every user administrator rights over their workstation, We recently migrated to Windows 2003 AD and I want to revoke the privileges tha users have on their computers. Can I do this through AD? It's around 300 users and I don't want to visit every single one of them.
Thanks for your help.
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. As a public body, the Council may be required to disclose this email, or any response to it, under the Freedom of Information Act 2000, unless the information in it is covered by one of the exemptions in the Act.
If you receive this email in error please notify Stockport e-Services via [EMAIL PROTECTED] and then permanently remove it from your system.
Thank you.
http://www.stockport.gov.uk
**********************************************************************
