Solved

Give local administrator rights only when logged on locally

Posted on 2011-09-20
11
824 Views
Last Modified: 2012-05-12
Hi all

I have set up a group policy to add the members of the helpdesk group the the BUILTIN\Administrators group. This way, they can log on any workstation and do anything they have to do on them.
I did this via Computer Configuration > Windows Settings > Security Settings > Restricted Groups

Now, the problem is that they can access any file on any computer via the administrative shares (C$, D$, etc...).
I am OK for them to be able to access anything on a workstation when locally logged on it, but not to have access to these administrative shares.

Is there a way to give them local administrative privileges only when they are locally logged on the workstations ?

Thanks a lot !
0
Comment
Question by:thewild
  • 5
  • 4
  • 2
11 Comments
 
LVL 3

Expert Comment

by:dahesi
ID: 36565410
maybe with this local policy:

"Deny Access to This computer from the network"
0
 
LVL 4

Author Comment

by:thewild
ID: 36565469
I don't want to completely deny access from the network, I only want these users not to have access from the network.
Network access is needed, for remote installations for instance.
0
 
LVL 3

Expert Comment

by:dahesi
ID: 36565591
i guess this is the only way :\
an admin is an admin. full access.

correct me if i'm wrong..
0
 
LVL 3

Expert Comment

by:dahesi
ID: 36565599
sry for double post.. in german its called "Hauptbenutzer". searching for the english translation... "main users" or something?
this group has restricted admin rights and as far as i know.. no access to the admin shares..
0
 
LVL 4

Author Comment

by:thewild
ID: 36565609
I believe this would be "Power Users".
They do not have enough privileges, all our users are already members of the "Power Users" group.
0
Why You Should Analyze Threat Actor TTPs

After years of analyzing threat actor behavior, it’s become clear that at any given time there are specific tactics, techniques, and procedures (TTPs) that are particularly prevalent. By analyzing and understanding these TTPs, you can dramatically enhance your security program.

 
LVL 9

Accepted Solution

by:
Chev_PCN earned 250 total points
ID: 36565735
Hi TheWild.
Unfortunately there are two seperate aspects to this.  One is access, and one is permissions.
Permissions for domain objects cannot be split, only aggregated.  If a user has sufficient permissions to  install programs, then by default they will need to be able to log on over the network and write to various disks or folders.  You also cannot redefine permissions for the admin shares (IPC$ etc).
Even if you deny the domain account admin access on the PC and allow the team members to use the local admin accounts to do their work, you still do not have proper SOD (segregation of duties) as you have simply changed this from a technical to a HR issue.  How then do you control the team from using the admin account?
To try & help more, If the admins have rights to log on and to do remote installs, why specifically do you need to restrict access to the admin shares?
0
 
LVL 3

Assisted Solution

by:dahesi
dahesi earned 250 total points
ID: 36565742
the last idea is not a real restriction.. its more a psychologic aspect:

you can activate an "audit policy" (Audit Object Access for Success) which will log the file access.
this maybe prevent your helpdesk users to access the computers over the network.

otherwise i got no clue how to deal with it.
0
 
LVL 4

Author Comment

by:thewild
ID: 36565799
@Chev_PCN :
Actually, members of the helpdesk group do not perform remote installations, only local installations. They locally log on workstations and install what they have to.
I realize that having local administrative rights give complete access to all files and folders, but I wish there were an option to prevent local administrators to have access to the administrative shares, and give that right to domain admins instead

@dahesi :
Actually, having an audit policy might be an acceptable solution. That way, they could technically do things they are not allowed to do (i.e. open private user files), but the policy would allow domain admins to have a control over this.
But how do you specifically audit access via the administrative shares ? Is this only possible ?
0
 
LVL 9

Expert Comment

by:Chev_PCN
ID: 36565841
Auditing is going to be difficult unless you have  SNMP trap forwarding configured & a logfile collector / analyser on the network.  Local access on the PC's will only be logged on the PC's themselves.  The only way an auditor will know if illegal access has been gained would be to troll the security log on each & every single PC for the privilege use events, which is a huge amount of effort & time. Also, how far back do you want to keep the logs?  Do you really want 1G or more of logs on each PC?
You could use something like Kiwi:  http://www.solarwinds.com/products/kiwi_syslog_server/
0
 
LVL 3

Expert Comment

by:dahesi
ID: 36565842
if you want to restrict the audit to "shares" only (as far as i know, its not possible to choose different shares/adminshares), you have to activate the "object audit" (success/...) first and then go to the detailed security auditing settings and activate the "Audit Detailed File Share".
this will audit each access to a file or folder within these shares.

quote from MS: There are no system access control lists (SACLs) for shared folders. If this policy setting is enabled, access to all shared files and folders on the system is audited.

hope this helps
0
 
LVL 4

Author Comment

by:thewild
ID: 36565918
Indeed, if logs are only stored locally, they would be useless in my case.
I don't want to setup a logfile collector just for this. To much hassle, it's just not worth the pain.

I believe I will switch back to the old method : remove the helpdesk users from the local administrators group, create a "helpdesk" user with local administrative rights and tell them to use this account for any installation / administration task on a workstation...

Thanks for your help on this matter !
0

Featured Post

Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

Join & Write a Comment

There are two modes of restricted groups GPOs. Replacing mode:   Additive mode:   How do they work? Replacing mode: Everything (users, groups, computers) that is member of the local administrators group will be cleared out. After th…
My last post dealt with using group policy preferences to set file associations, a very handy usage for a GPP. Today I am going to share another cool GPP trick, this may be a specific scenario but I run into these situations frequently in my activit…
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…

708 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

17 Experts available now in Live!

Get 1:1 Help Now