Security concerns when deploying software via GPO

sschmidlap

Hello folks. Going through the second round of building a multiple site, single domain Active Directory network with much more emphasis on security this time rather than just getting things up and running. I am currently working on deploying Office 2003 via GPO which I have done before, but here is what I am contemplating. I will be experimenting and working it out on my own tonight in the lab, but would like to bounce this off the experts. I have my administrative installation share point. Shared as Office 2003. If I give read permissions to Everyone or Authenticated Users, couldn't a standard user simply copy the entire contents of the shared folder? To secure this share but keep the functionality, I am wondering if I should only give read permissions to Domain Computers? What do you think. Again, I will experiment myself with a regular domain user in the lab and try it. Thank you.

sschmidlap

Well, that was easy enough and did the trick. Software is still deployed, but users can't browse or read the contents of the shared folder. Same thing worked on the REMINST share. Just applied permissions for domain admins and system and WDS works just fine but users can't read/copy the .wim files and more importantly the .xml files with username/password info. I never could find the setting to change from plain text but as long as it can't be read I'm fine with it.

sschmidlap

One last thought on this topic. I completely automated WDS to deploy XP, Vista, 7 but it seems to me (theoretically) with my setup anybody could bring in their laptop from home and install whatever os they wanted. Maybe they would have a hard time activating, but still... don't like this wide open. From what I have read the only way to lockdown WDS is by prestaging client computers. Are you kidding me? What if you have 5000 clients in your organization? That seems preposterous. I am wondering if after I have deployed to all clients and these clients are domain joined they will automatically be considered known clients. So when I am done, I can change WDS setting to deploy to known clients only. That way I can reimage existing machines but will have prevented people from bringing in their own laptops and pulling images off the server. Thoughts?

earweed

As a best practice all of your client computers should have been prestaged already. If not you could just put all of your present computers into an OU and work from there. Someone bringing in a computer off the street wouldn't be able to join this comp to your known computer OU (unless they had permissions to join)
As for prestaging all of those comps you could use an excel spreadsheet with all clients and/or computer and import them to AD using CSVDE.

phoeneous

sschmidlap wrote: »

users can't read/copy the .wim files

Just curious, would your users know what to do with a .wim file let alone what it is?

Hyper-Me

sschmidlap wrote: »

One last thought on this topic. I completely automated WDS to deploy XP, Vista, 7 but it seems to me (theoretically) with my setup anybody could bring in their laptop from home and install whatever os they wanted. Maybe they would have a hard time activating, but still... don't like this wide open. From what I have read the only way to lockdown WDS is by prestaging client computers. Are you kidding me? What if you have 5000 clients in your organization? That seems preposterous. I am wondering if after I have deployed to all clients and these clients are domain joined they will automatically be considered known clients. So when I am done, I can change WDS setting to deploy to known clients only. That way I can reimage existing machines but will have prevented people from bringing in their own laptops and pulling images off the server. Thoughts?

huh?

You can set permissions on the REMINST folder, and sub folders (per image group) as you like. Unless end users are doing their own imaging, they dont need access to the folder. Hence the windows logon box you get when you PXE boot into WDS, before you select an image. The images populate based on what you have permission to read.

It's fairly secure, but if you put an answer file on there that automates a username/password input then don't be surprised if someone hops on there and pulls down a WIM.

Addiitonally, you could set the PXE server to require authorization before connecting. It's a pain in the butt, but if you are trying to be "SECURE THE WORLD" guy then thats an option.

Hyper-Me

Let me add some more. Deploying software via GPO only requires that the Domain Computers (or computers its going to) have access to the share if you use the assign to machine method.

Assigning to user or publishing to user is rare, especially with office, because of the lengthy install time. Most places have office on almost every PC anyway, so assigning to user is typically pointless.

If you need to assign to users, make a group called "OfficeInstallUsers" and put those people who need that right in that group, and be done with it.

RobertKaucher

phoeneous wrote: »

Just curious, would your users know what to do with a .wim file let alone what it is?

I have to be an [EMAIL="a@$$"]@$$[/EMAIL] and ask this question... (I'm saying this to play Devil's advocate, not to simply be a jerk)

Is your security policy dependent on the perceived ignorance of your users? I mean, it's not just users. Imagine a person get's their home PC hacked and next thing you know some hacker is poking around via his VPN connection. Then he adds his root kit to the WIM file.

I see no point in allowing domain users any rights to WDS shares. They will not be imaging their own PCs, correct?

phoeneous

RobertKaucher wrote: »

Is your security policy dependent on the perceived ignorance of your users?

Beyond hell no. If it were then I wouldn't have just spent two weeks drafting an acceptable use policy that would rival most pre-nups. Good enough?

That's why my reply to the op started with "Just curious..."

I can be an $$ too

sschmidlap

As far as prestaging, somebody still has to enter in all those GUIDs in an Excel spreadsheet right? Doesn't sound like there is any way to avoid that labor intensive effort for best practices. If there is, would love to know more. This is just a lab at home anyway. If I was in an on the job situation and that was the only way to prestage, of course I would do it. As far as securing the software installation shares, in agreement about assigning Office to computers not users. That is how I set it up to begin with and just changed the share permissions to Administrators and Domain Computers. That should be sufficient. As far as securing WDS, seems like the easiest and simplest way to secure it is to remove the automated WDS login credentials from the answer file as was suggested. I would do that and just turn off WDS after the initial deployment. Would the above be sufficient for decent security? Not trying to secured the world, just want to avoid any glaring holes.

Hyper-Me

I wouldn't leave the credentials in the answer file.

Or better yet, do it this way.

Make two answer files, both the same except

1. Leave this one active, remove the credentials so anyone who PXE boots has to authenticate to retrieve an image.

2. Keep this one for large deployments. Leave the credentials in there. Activate this one when you will be doing many many machines and dont want to type in the password. Remove it when not in use.