local administrator still locked down

[clareq]

On our new domain we are trying to lock down staff as much as possible on desktop PCs, but give them local administrator access on the laptop they are assigned. However, when I add their domain account to the local administrator group on the laptop, they are still affected by the domain GPOs - even off the network. Ideally I'd like them to be able to save on the desktop or in a folder on the C drive and be able to install a printer or program if necessary, but as they can't see the C drive and only get the redirected start menu, none of that is possible. Am I missing something obvious? I really don't want to loosen the GPOs that affect their use of shared machines.

[ChrisH]

Use a loopback policy on the laptop OU and change the settings you want to change.

[clareq]

The settings that are holding are set in the user policy, but I only want to undo them for one particular machine per user. Would a loopback policy allow me to do that? I've come from a RM background, and I'm on a very steep learning curve here. We're using Server 2012 R2 and SCCM if that helps.

[ChrisH]

You set the policy on the machine OU and enable loopback policy processing and this will apply the user settings only on that OU that the computer account is in. To do it on multiple machines for single users would be quite messy but doable.

[clareq]

We have over 100 staff laptops - would we therefore need over 100 separate OUs? That seems very messy - there must be a better way.

[free780]

Put the laptops in a ou. Link the gpo. The restricted groups part of the GPO is not user but computer. Do the staff have to be local admins?

[clareq]

They need to be able to set up their home wireless and printing, save any work they've done at home to the Hard Drive, possibly install software for testing, that sort of thing. I want them locked down on any other machine they use - if they break their laptop due to their stupidity they only inconvenience themselves, on a shared machine they affect other users.

[ChrisH]

So really they won't be using other staff members laptops?

[clareq]

Probably not - there is some sharing going on, I'm sure, but our Laptop agreement does state they won't loan it to another member of staff. I see where you're coming from - a loopback to allow all staff elevated permissions on the staff laptops, on the basis it's their fault if they share it.

[ChrisH]

Yup pretty much.

[clareq]

I'll give it a go in the morning - thanks for the help

[MatthewL]

They need to be able to set up their home wireless and printing, save any work they've done at home to the Hard Drive, possibly install software for testing, that sort of thing. I want them locked down on any other machine they use - if they break their laptop due to their stupidity they only inconvenience themselves, on a shared machine they affect other users.

 

All this can be done without giving them admin rights, just change the relevant GPO's. For the WLAN one you would only need to add them to network configuration group rather than local admins, as regards to printing that is quite easy as we used to let users play with printers settings to their hearts contents.

 

If you do need to give them local admin rights create an AD group i.e. local laptop administrators and add them all to it and apply that, if they have admin rights on their own nothing stopping as such on others, but certainly you can fix all without giving them admin rights.

 

Always work to the principle of least privilege.

[FN-GM]

Use a loopback policy on the laptop OU and change the settings you want to change.

 

I wouldn't use Loop back i would use WMI filter. Have a separate policy for desktops and laptops.

[clareq]

Can't use WMI - there are some shared laptops I want them to have restricted rights on.

[FN-GM]

Can't use WMI - there are some shared laptops I want them to have restricted rights on.

Well then you would make a WMI filter that didn't apply to these laptops. Only make one that is applied to the ones that are not shared.

Edited June 19, 2014 by FN-GM

[JonDaviesBourne]

I would never give anyone other than IT staff the ability to install anything other than maybe printers. Bear in mind that if they are local admins, they could download and install anything when away from the domain and bring back all kinds of nasties.

 

Roaming profiles, folder redirection and make redir. folders available offline.

 

There is a GP setting in User->Administrative Templates->System/Driver Installation for "Allow non-administrators to install drivers for these device setup classes". You can put the GUID for printers in there to allow them to install just printers, then set the scope to just their laptops.

[clareq]

Following advice further up the thread, I've removed them from the local admin group, added them to the local Network Configuration Operators group, which will allow them to add their home wireless, used loopback processing to allow them to see and save to the local drive for working at home. I don't want to make redirected folders available off-line - some redirected My Documents contain over 10Gb of files, but I have allowed redirected appdata and favorites to be available. To a certain extent it needs to be a "work in progress" and I'm sure various thinks will have to be "tweaked" one the system is used in anger, but I've been given plenty of time to develop a new domain, so I'm trying to pre-empt as many problems as I can.

[JonDaviesBourne]

Following advice further up the thread, I've removed them from the local admin group, added them to the local Network Configuration Operators group, which will allow them to add their home wireless, used loopback processing to allow them to see and save to the local drive for working at home. I don't want to make redirected folders available off-line - some redirected My Documents contain over 10Gb of files, but I have allowed redirected appdata and favorites to be available. To a certain extent it needs to be a "work in progress" and I'm sure various thinks will have to be "tweaked" one the system is used in anger, but I've been given plenty of time to develop a new domain, so I'm trying to pre-empt as many problems as I can.

 

I wouldn't worry too much about the making documents available offline. You'll get more of a headache from staff not knowing if they saved to the C: drive or not. The sync only syncs differences, so you'll only get high load when they all first sync up. I would be insistent that standard users (staff/students etc) not be allowed to have any write or modify permissions to any part of C: as malicious scripts could still run with their credentials. Not to mention the fact that anything just saved locally won't be caught in your backups. If they absolutely MUST have local write, then set your image to partition the disk to C: and D: and just give them permissions on D:. I just can't stress enough how much of a bad idea letting staff have any write permissions on their system disk is

 

We've been running our domain this way for this academic year and it's been working like a charm.

 

One thing I'm working on at the moment is making sure that profile size is kept to a minimum (appdata and the like) in case of using a new machine as you'll find logon and logoff times going through the roof. (Found some profiles here that were >40GB)

[TG_MI]

Similar to @JonDaviesBourne, we don't allow our faculty/staff to be local admins with their domain accounts. However, for those individuals or situations where someone absolutely must have an admin account, we create a separate local admin account, specify a complex password and then show them how to use that set of credentials from within their (non-admin domain account) logged-in session. This protects the system from executing "drive-by" malicious code with admin credentials because the user logs in everyday with their non-admin account, and thus, most software that is targeted for malicious code/exploits (browsers, browser plug-ins etc) is running with the non-privileged credentials. Armed with an admin account, they can do little updates/installs when prompted by using ".\LocalAdmAcct" and the password. Yes, they can also run "CouponPrinter.exe" with admin credentials and hose their system, but surprisingly, that doesn't happen as much as you'd think. Obviously, there are systems and situations where you absolutely should not give local admin access (systems with sensitive data) but that's up to your judgement.

 

You can define what accounts should be in the local administrators group in a GPO here: Computer Configuration-->Policies-->Windows Settings-->Security Settings-->Restricted Groups-->Group (BUILTIN\Administrators (Then populate the members).

 

Another thing that strikes me from your initial description is that you were describing a scenario where you wanted to have a subset of machines that had somewhat less restrictive group policy settings than others. The easiest way to accomplish that would be to plop that subset into a SubOU of their current OU, define a GPO for those systems and then apply it to the SubOU. Remember, the GPO applied "closer" to the object (the computer accounts in AD in this case) should take precedence (unless "Enforce" was used on a higher GPO) if there's a conflict between GPO's.

[TG_MI]

One more thought. If your users are new to the concept of not being an admin all day everyday and you are now trying to lock that down, you had better have a method of remote support figured out. Whether its built-in tools like remote assistance/remote desktop (can be configured via GPO) or a third party tool, make sure you have one and that you and your technicians can use it on a moment's notice.

 

I've found that users very much dislike not being an admin (because they don't understand the reasoning behind it and assume you're just doing a power play) and will look for any opportunity to say, "Look, I wasn't able to present at this conference because I couldn't install XYZ and YOU couldn't help me over the phone! I need to be an admin!!!" If you have a remote support tool and plan in place, you can be Jonny-on-the-spot and take care of those things and keep the complaints to a dull roar.

 

You had also better have an idea on how you're going to automate non-Microsoft application updates (like Java, Adobe, etc) because those applications nag the heck out of users each time they have a patch and they will in turn nag you and question your admin policy if you can't patch in a timely manner. So have a method (SCCM, GPO Software push, something) figured out for those things as well.

[clareq]

SCCM is in place. We have remote access when the users are on site. Unfortunately our users are not the most technologically able, some struggle with saving to the default location, so trying to get them to save to a second drive would be "interesting". Our AUP already states that anything not saved in their user area won't be backed up and could be lost if we need to rebuild their machine - we won't go hunting for work to back up. Basically I'm trying to replicate, as far as I can, the RM Privileged User set up, while at the same time making small changes to improve security. I have managed to get my boss to sign off on them not having local admin rights, which they currently have, so I'd like to give them saving to the C drive. I'm expecting a revolt over not saving to the desktop, I'm picking my battles carefully.