Security for roaming profiles

Local admins can undo or circumvent any security measure. There is no use in asking until you remove administrative permissions.

I agree having them as local admins is not best practice, but to answer your question, the above should do it.

William's solution set to "Disabled" would work unless one user decided to change ownership of another's profile. They can theoretically still access it as a local admin on the PC.

True, someone could take ownership and still view the files, but then they'd have to grant the ownership back or else it'll jack up the profile. At least that way you'd know if somebody was accessing someone else's files.

I do agree that granting everyone local admin rights and then trying to limit those rights will just create headaches.

About deleting, Frank: Admins that knew about it would use undelete. If cipher.exe were used to safely overwrite, they'd come up with another way.

Useless, admins and security is not possible.

About deleting, Frank: Admins that knew about it would use undelete. If cipher.exe were used to safely overwrite, they'd come up with another way.

That's a bit extreme for 99.999% of users.

Either we go and protect the best we can or we trust. If we trust, then why delete at all?

Don't be ridiculous. You protect against your own users to a point.

Furthermore, they obviously trust the users enough to make them local admins, but not enough to view each other's files... that's their point. 9/10 it is not up to the IT dept to make these calls.

Ok, that's a matter of opinion  I work in defense. This is a half baked measure in my eyes, that's all. I don't go and talk people out of it, especially not in a forum.

It's not something i would personally do either. I just don't understand the desire to try to change a random organizations entire security practice based on a simple question on a forum.

After reading all of these suggestions (THANKS), I have come to the following solution.  As some background, the reason that people are admins of the local machine is that the mission critical piece of software used on every single machine requires admin access to perform updates to the software.

I am going to do a few things:
1. I am going to remove Domain Users from the Administrators group on the workstations using group policy.
2. I will create a Domain Global Group called Computer Administrators and use Group Policy to put this group in the Administrators group on the local machine.
3. When a scheduled update to the client software is to occur, I will put the users in the domain global group Computer Administrators so that when they log in the next morning and start the software, they will be admins.  In the afternoon or whenever I decide, I will remove the users from the global group Computer Admins.
4. Re-think my roaming users strategy and go more towards the folder redirection route.

As far as 1-3 go, is there a better way to do that?  The only problem I can see is that if every person doesn't log in and start the software THAT DAY and I remove them from the global group, the update to the software would fail.

Can the software updates be run as a scheduled task using encrypted credentials?  
Or. could the updates be pushed out to the PCs from central location using a tool like SCCM?

I wonder if a better way to make a user a temp admin would be to create a GPO called Windows Administrators and then edit User Configuration\Preferences\Control Panel Settings\Local Users and Groups and then Update the Administrators group to add the current user.  Then, when everything is done just unlink the GPO.  Sound ok?

Sure, normally yes. Most setups have silent deployment methods incorporated so that a solution could look like this:
1 Have a scheduled task run as system account,make it startable (but not changeable by the users)
2 Have it start setup from a certain folder where users have write access to using silent parameters
->it will be installed
3 in order to ensure no user puts a fake setup inside, use software restriction policies or applocker and restrict that folder with the exception of signed executables by that software vendors.

This isn't too complicated.

"Sound ok?" - no, definitely not, if you would like to maintain a decent security level. It doesn't make a big difference if we make someone admin for a minute or for a lifetime - if he is a little savvy, this will be enough to take over. And you never know if he isn't. That's what security is about. Maintaining enough usability is right on the other end of the scale.

onequick6,

Can you get these updates in .msi files? if so you could just deploy the updates through group policy, and take the user out of the equation.

You could also deploy the software through a logon script if you get an .Exe, even if you cant make it install silently it will run as the local system account if in a login/startup script.

I guess what I'm saying is, its a good idea to not have them as local admin for a lot of reasons, the things McKnife has mentioned are all really unlikely scenarios. You should and probably do have a written computer use policy in your company where the type of behavior mentioned by McKnife is prohibited, and most users generally do not have malicious intent.

 A far more likely scenario is that you will have issues with users installing malware, and adware and toolbars, and background software, and greeting card software and all of the other we hate to see on people's computers.

Even though making them local admins temporarily as opposed to all the time is better, it might still lead to complaints from the user about how sometimes they can do whatever and sometimes they cant, and bla bla. Also like you mentioned it may become a maintenance nightmare.

Hopefully what i said makes sense and isn't just mindless ramblings.

Unfortunately, the software design is such that it checks with the server hosting the app on our network and if there is an update the program will just install them right then.  There is no way to manage that.

"There is no way to manage that" - sure? nowadays, vendors get more and more security aware. Ask them what the recommended procedure for updating is.

another option is something like procmon to see exactly where the software gets an access denied on a limited account, then granting write permission to domain users to that directory until the updates work correctly and the access denied go away.

We did something similar to what NinjaSyle82 suggested, except we created a security group for the app & then gave that group full access to the app folder. That way, only users in that group could launch the app so it could update the files that needed to be updated.

Assigning write permissions to registry keys and file system can work, but usually doesn't. Installers trigger UAC and UAC doesn't care what you modify.

Well, I have modified my approach a bit.  The problem with this particular application is that it triggers updates to not only files stored in the program files folder, it will install any add-ons, like .net, crystal reports, and other stuff.  The vendor doesn't have anything to work with AD or any other management software.

Here is what I have done:

1. Set a group policy to remove all users from the local administrators group and just have it left with the stock settings.
2. Set a group policy for restricted groups to populate administrators with a Domain group called Computer Admins.
3. Got rid of roaming profiles and went with folder redirection storing folders and files in \\servername\users\username

When an update will occur, my only choice will be to populate the Computer Admins group with the user accounts so they become administrators of their machine while the update takes place when they launch the program on "update day."  When the updates are done, I will just empty the Computer Admins group in AD once again.  No, this isn't best practice but it is my only choice given what I am dealing with.  With roaming profiles being gone from the machine and the documents not being cached on the workstations any longer, it is more secure than it was.  Their folders on the server are secured appropriately to offer the protection I am looking for.

This is just another thing I have to be mindful of.  I already have problems with software updates to other programs due to my group policy in place to prevent malware like Cryptowall from attacking.  It prevents execution of files in temp locations and other directories that these malware programs like to use to do their damage.  I'd much rather deal with inconvenience than the aftermath of an infection.

Thanks for all of the suggestions.  I will distribute the points and hope I divide them appropriately.  :)