Link to home
Start Free TrialLog in
Avatar of halfondj
halfondj

asked on

Active Directory (GPO): Domain users need local admin rights

My network environment is Win 2K server, 1 Active Directory domain with approximately 40 users.  I have the users broken down in 6 OUs, but have only 1 GPO at the domain level (default domain policy).  The reason for that is except for the IT department 5 users, all users should have the same desktop restrictions.

Question 1:  There are 6 users that need local administrator rights to their PC because 2 applications that they use require it - I spoke to the vendors.

The only way I knew to give them local administrator rights to their PC is by going to their PC and adding their domain user name to the local administrators group.

Is this correct or is their a way to control this through a GPO?  I would prefer a GPO, as I want this to be done centrally - not by me going to a specific PC.

Question 2:  When I added the user to local administrators group, the domain level GPO no longer was applied when the user logged onto the domain.  Is this correct?  If so, how can I have a GPO apply to them?  Except for being able to run the two applications that require local administrator rights, I still want the users be restricted re:other things, e.g. IE security, no control panel, etc.

Thanks.
Avatar of BigC666
BigC666

howdy,

you are correct that you can't push local rights, and must do as you say, however if when adding you will use their domain account when setting up the local rights all should be ok.

hope that this helps
Avatar of halfondj

ASKER

Thanks for replying.

>> however if when adding you will use their domain account when setting up the local rights all should be ok.
As I mentioned in my post, that's what I'm doing.  I would just prefer to do it via a GPO.

Do you know the answer to question 2?
SOLUTION
Avatar of BigC666
BigC666

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
I found that any restrictions that I had in the domain GPO was not applied to the domain user set as local admin user, e.g. IE home page in GPO is set to google.com, but the domain user/local admin user did not have that setting.

Any ideas why?

Thanks.
excuse me, i was thinking of power user not admin, i've never tried it with admin
halfondj,
In your Default Domain GPO you can set file permissions. To do this navigate as follows: Computer Configurations\Windows Settings\Security Settings\File System.
Here you can modify the areas that the applications you mentioned need elevated privledges. Find out from the vendor what EXACT FILES need EXACT PERMISSIONS and place them appropriately within your GPO. I would create a seperate GPO if I were you and remember ALWAYS TEST GPO's! The above solution provides for a better all around security plan allowing only those who need it to get it.

Good Luck
Shinds57
I like that idea, but the vendor point-blank said that the user needed local administrator access rights.  Could have something to do with even writing to the registry.  I don't know.

Any additional ideas would be appreciated.

Thanks.
Give the domain user full write access to their computer's registry via regedit.
But, I don't know if that is the problem.  I'm just assuming.  Also, I don't want to mess around with regedit.

Thanks.
What we did when we needed this same thing, we created a batch file called Domainusers.bat and it had this line in it.

net localgroup administrators "domain users" /add

That command will add the entire domain users group to the local admin group.  Just create a GPO that has this batch file as a computer startup or a user login script.  Just make sure you put the batch file on a share that everyone can access.
halfondj,

You really need to demand that the vendor tell you the specific rights needed. They just tell you that to make it easier for them to walk  you through installation. Once Installation is done and you begin to use an applications it usually comes down to read/write/create rights on a specific directory/directories. Dont compromise your systems by giving all domain users local admin rights..thats just plain crazy! Another way to look at it is this. Create a "Application Group" add those 6 users to that security group, add that group to the Local Admin group and then set the permissions accordingly. Again, however, Dont let the vendor take the easy route! Demand that they provide you with the information you need to secure YOUR NETWORK!

Good Luck
Shinds57
Sounds like what I did re:giving local admin rights to the specific user on their PC is correct.  I was hoping I could do it a different way.

Does anyone know why the domain level GPO is not applied at all?  If the domain user has local admin rights, does it mean no GPO can apply to them?  Except for letting them read/write/modify whatever folders/values that the vendors require, I still want those users to have a specific IE home page, etc.

Thanks.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
>> Have you tried removing the users from the local admin group and seeing if the GPO applies then?
When I removed the user from the local admin group, the GPO did apply to the user.

The domain default GPO definitely works for all non-local admin users.

Have you tried forcing AD replication after adding the users to local admins?  

gpupdate
Oops,

gpupdate
for WinXP computers and

secedit /refreshpolicy
for Win2K machines
No, I haven't.  I'm unfamilar with those commands.  What's the rules to using them?

Thanks.
After you make your domain users local admins, go to the command prompt and type in that command, depending on your OS.  It will then force the machine to get it's policy for the computer and the current user.  Also try rebooting after this to make sure.

Win2K
            Computer:

                         SECEDIT /REFRESHPOLICY MACHINE_POLICY /ENFORCE


            User:

                         SECEDIT /REFRESHPOLICY USER_POLICY /ENFORCE

WinXP
 
            gpupdate
In my domain level GPO, I disabled the control panel so that the users cannot access it, as well as set the IE homepage to google.com.

If a domain user is also local admin to their PC, would restrictions like the above still apply when they log onto the domain from their PC?

Thanks.
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
If the domain GPO settings do apply, then how would disabling the control panel be enforced if the user has local admin rights?  Doesn't the local admin have full access to their PC?

I know my users did not change anything in the registry.

I apologize for such simple questions, but I want to make sure that I'm doing the administration of our network (users) correctly.

Thanks.

SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
If the GPO overrides local admin rights, then why apply local admin rights to a domain user?

BTW - I don't mean to give you a hard time re:this.  I certainly do appreciate the time you are taking to answer this post.  I'm just a bit confused with how GPOs work with local admin users.

Tomorrow I'll also re-check this.

Thanks again!!
You apply local admin rights so that programs which require admin permissions can run.  We have some ActiveX programs that just won't run unless the user is a local admin.  Still, they get our default screensaver/timeout, links in IE, etc.

The way I see it is that GPO is nothing more than making an easy way to change registry settings and some files on client computers without having to manually change it on each computer.  We have the default homepage set to our company's site, but I prefer to have it set to www.yahoo.com so since I am a local admin, I change it on my computer, but since GPOs are applied after a default interval, it changes back to what we have set for the domain.
Thanks for the explanation.  What do you mean 'after a default interval,...'?  Where is this default interval value set?  Is it possible that I don't have something configured properly and that's why the GPO is not applied - even the GPO login script doesn't run.

The default interval is 90 minutes, but in my experience, it doesn't always happen then.  Usually a reboot will force it, or you can use those commands to force them.
I thought any changes made to GPO settings were effective immediately.  In the past, I have made changes, then logged on as a domain user, and the changes were in effect [immediately].

We have only one AD domain w/4 servers and ~40 workstations.

I just want to add -- If the domain level default GPO is working properly for all domain users, why would it not work on a user's PC when I make them a local admin to their PC?  As soon as I delete the user from the local admin group on their PC, the domain level GPO works fine on their PC.

Thanks.
I may have stated the last post in a confusing way:

>> " As soon as I delete the user from the local admin group on their PC, the domain level GPO works fine on their PC."
  The GPO works fine on the user's PC for all user's other than the user who was added to the local admin group.
They are not always immediate.  It takes time for it to propigate through all your servers and then for the workstations to actually pull it down.  I would make the change and then leave it all day, reboot the PC and then see how it goes.
I confirmed that the local admin user does not get the domain GPO applied.

Can anyone else confirm this?

Thanks.
I'm assuming that either we are overlooking something little, or something else is not in order.  As far as I know, it should be fine, so hopefully someone else has some more input.
Thanks Eagle6990.  I hope so because I want to confirm that I'm doing things correctly.
According to Microsoft Doctrine, you probably shouldn't add the useraccount to the local admins group.  When I am faced with such situations and vendors that don't cooperate, rather than add a user account, I create a Global Security Group for the app in question and make the Group a member of the Local Admins on the machine in question.  Users that need the app can then be members of the group.  This has worked well, and Group Policy still has applied to the user accounts themselves.   Worth a try anyway.
Thanks Ranidae for replying.  I actually tried what you suggested, before you suggested it, but was unsuccessful as I couldn't add a group as a local administrator.  Only usernames could be added.  I really want to add the group.

The vendor I'm dealing with was very cooperative re:that they said their app only works with the user as local admin.

As for the Group Policy applying when a user is made local admin, I've only had a chance to test it again on a Win 2K PC, but it does look like the policy applies.  I may have previously been mistaken or didn't wait long enough.  Tomorrow, I have to test it on a Win XP PC.

Any additional suggestions are certainly appreciated.

Thanks.
I've been adding domain Global Security groups to the local Administrators Group of workstations as long as the workstation is a domain member... are we talking windows 2000 or Nt4?
Windows 2000 and XP.

Can you please outline what's the difference w/adding the group compared to user?  I'm increasing the points.

Thanks.
In your GPO Security Properties check to see if this policy is not being applied to the Admin Group. I again however would spend much more time finding out what files these users need elevated privledges too and apply them there rather than at the root. But hey I guess Im just funny that way...

GL
Shinds57
>> In your GPO Security Properties check to see if this policy is not being applied to the Admin Group.
Sounds like you are refering to the domain administrator.  I was reporting a problem re:the local administrator.  After re-testing, it seems like the policy is working.  Atleast on the Win2K PC.  I have to re-check the WinXP.

I agree with you re:finding out what files/folders the users need access to, but the vendor insists that they need full local admin access rights.

Thanks for your reply.
Alright, I tested this out in the office today.  We have a Domain level GPO that takes away the screensaver tab similar to what you mentioned.  Since we made everyone local administrators, they have access to the tab now, but we also locked down the screensaver they have and the timeout, so even though the users can see the Screensavers tab, they cannot make any changes to it.

I'm not positive why this is happening, probably something about local administrators always have access to all tabs, but they can still have it locked down.
To Eagle6990: Thanks for checking it out.  I still have to do testing here re:this issue.

What OS are your workstations running?  If Win2K and XP, do they work the same way.

Thanks again.
We are running a mix of Win2K and XP for clients, but all I had available to test this with was XP.
I'm guessing that your domain is not running in Native 2000 mode.  You must be running in Native 2000 mode in order to nest groups (making a group a member of a group)...

Here in my environment it works great, my "teachers" security group is a member of the local admins group on any workstation where I have the conflicting software issues.  Group policy still applies to the users themselves as I have set it, and as long as the policies don't conflict with the software, all is good.  Conflicting policies in the past have been denying the right to add registry keys (some software suites need this on a per user temporary basis).

The advantage is that you then don't have to go around making new users members of the local admins at each machine, just add em to the right group.

I've confirmed that this still works here on a windows 2000 domain with all win2k clients.
Is this still and issue?

shinds57
My apologies for taking so long for getting back...

I finally figured out my problem re:why the default domain policy was not applying to a domain user after I added them to the local PC administrators group.

In the security tab of the default domain policy, I had the administrators group set to allow-read and deny-apply group policy.  I didn't know that when a user is added to the local PC administrators group, they are considered to be in the administrators group that is defined on the active server.

The following describes what I did to get what I needed to work:

1.  In the default domain policy on the security tab, I deleted the administrators group.
2.  I created 2 security groups: 1) ABC-Local-Admin-Grp and 2) ABC-No-GPO-Admin-Grp.
The ABC-Local-Admin-Grp contains all users that are in the local administrators group on their PCs.
The ABC-No-GPO-Admin-Grp contains the active directory administrator usernames, e.g. Administrator, adadmin [backup administrator username].
3. In the default domain policy, I added the two security groups to the security tab.
For the ABC-Local-Admin-Grp, I set the permissions to allow-read and allow-apply group policy.
For the ABC-No-GPO-Admin-Grp, I set the permissions to deny-read and deny-apply group policy.

After doing the above, all domain users that I put into the local administrators group on their PCs, now have the default domain policy applied.  In addition, the administrator usernames [administrator and adadmin] works properly - the default domain policy is not applied.

What really helped resolve my problem was that I used the GPRESULT program to see what policies were being applied to the domain.

If anyone has feedback re:how I rectified my problem, I would welcome all comments.

I will need to review all replies to this posting and grant the points.

Thanks to everyone who took the time to respond to  this posting.
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks Eagle6990.  I did know about the application and I agree it's very handy especially for the GPO reporting.