No save for work stations

Hello,

Trying to figure out what forum to post this to was the most difficult part. I work for an office that had a forced relocation to another state (about 90% relocated, 10% were allowed to stay at the previous city--you know, the chocalate one). Our IT department was tasked with finding a way to make workstations in our old office (Which run either W2k or xp) unable to save anything anywhere to the local PC or local servers that remain. No one tells us why--I suspect there's a tax issue involved. State2 is where things can be saved, State1 rdp's to state2. In short order I found MS GPMC as a promising tool, however I'm no security expert-I'm a progammer.

I need to pick your brains (brains...mmmmmm lol). What is your preferred method of achieving this? This seems silly to many (it does to us), however we are stuck with this inane directive and have to make it work. We already have WYSE terminals and we could dole these out to state1 users, but somehow this is not the preferred solution--go figure? So what is your preferred method of emasculating your PC's--don't blame me I'm just following orders.

This is a very strange request and I am not sure whether it is really achievable but the logical option you have is to set the ACLs on the file system on both the local PC's and the servers to not allow anyone (who you don't want to) to have write access to any part of the filesystem on the drives on those machines.

To do this from a central location you could use Group Policy on the machines in state 1 to lock down the file systems so that only the user and system accounts you want have access to those file systems.

This is specified under the Security Settings/Options of Computer Configuration in the group folicy tree.
Computer Configuration\Windows Settings\Security Settings\File System

You can specify files and folders and then the ACL in this policy tree.

You would then apply this policy to the State1 machines OU in GPMC.

Note: - Be very careful changing ACLs on all folders, some applications may run with the users context and not be able to write critical application files (or temporary files) if you lock out the normal user accounts from writing to all folders such as temp.

The other thing to think of is you will need to redirect their entire user profiles to State2 servers as many applications use folder in the user profile to write temporary or configuration data, the user will definately need write access to that so this will need to be redirected to State2 Servers.

As I said be very careful, make sure any changes you make are THOROUGHLY TESTED before you implement them otherwise you will have a few SCREAMING clients. You need to be especially careful about removing SYSTEM and the Administrators group from ACLs - this is especially NOT recommended.

Good Luck but as I said you need to be VERY careful when doing this and personally I don't recommend doing it at all but particularly in a hasty/hurried manner.

Cabby80:

You are quite kind in referring to the request as strange--our descriptives have been far more colorful since being tasked with this ludicrous directive. Your suggestion makes good sense, and I agree that the enterprising user still may find a way around this.

GPO seems to be the way we go if we are forced to use PC's, however what management is asking for logically seems to suggest terminals as the way to go--however they want it done with the PC's already on site--go figure.

To admins of library/university/other public PC's: what's your preferred method? Such multi-user environments probably have GPO restrictions similar to what we will need to do. Please advise.

At my previous job I was (among other things) NT administrator for about 2000-2500 workstations and 100-150 servers. Users weren't allowed to save anything on their local machine. They had their home and profile directories on central servers. To prevent users from using their local c: drive we used more or less Cabby80's solution. It was on NT4 back in the days so GPO didn't exist yet. We did use policies to prevent users from tempering with the settings and set ACLs to prevent filesystem modifications. Win2K only made things easier to administer but was basicallly setup the same way.

Some users however found out %TEMP% and %TMP% were writeable by them and consequently abused it to store all sorts of crap.. We solved this by clearing these directories when the user logs off :D

OK, about the ACLs: I tried to find that path on my GPMC, however under Security Settings there is only a File System folder (which seems to have a little lock on the folder icon)--the folder seems empty. What am I getting wrong?

I'm connecting to my W2K server from my desktop running XP Professional SP2. I'm using the GPMC as part of my snap-in of my MMC.

Please advise. Thanks in advance.

You need to add each folder you want to set permissions on via group policy, no folders exist via default.

Try right clicking on 'File System' in the left hand pane and there is probably an add new folder/file/object option
(sorry I'm in Linux at the moment so I can't tell you exactly)

Once you add the file/folder/object you can then set the permissions on it and whether the permissions propergate down the tree to subfolders or not.

I'm not certain what the lock represents but a good place to start having a look is on:
The W2K3 Group Policy site on Microsoft http://www.microsoft.com/windowsserv...y/default.mspx

Doh! It was staring me in the face all the time! I think subconsciously I have allot of resistance to this task (really its quite conscious--but that's my story and I will stick to it).

Being programming-oriented (db's), I'd like to look into how to script this. Any suggestions or references to educate me?

Thanks.

The point of using Group Policy is that you shouldn't need to script it at all, all you need to do is set it once on the Group Policy of the appropriate OU in you AD domain(s) and then these settings are pushed out to all machines residing in that OU automatically.
The time taken for all machines to get the appropriate policy will depend on the GP update/refresh interval in your domain.

Point taken--thanks for your reply. We may have won the argument for WYSE terminals anyway. Why take the time and effort to make a PC an RDP only station we told management? Hopefully they found our IT manager's argument compelling.

I did test some GPO's from MS, only enabling Computer Configuration, however I could never stop the test user from saving a simple text file (I tried the AppStation Profile and gave read only rights to c:\). I wanted to leave the users alone, so they would have their normal rights once they RDP'd into the domain terminal server. I'm guessing I would have had to create a generic user and enabled Computer Configuration, lock it down and use "re-direct". Is my reasoning sound? Can the objective be done with locking down the computer only (I thought so, but I could not get it right)?

Citrix?

Steve

steve.milner:

Please elaborate and educate on : "Citrux?"

You could use deep freeze on everything. http://www.faronics.com/index.asp

Quote:

---

I'm guessing I would have had to create a generic user and enabled Computer Configuration, lock it down and use "re-direct". Is my reasoning sound? Can the objective be done with locking down the computer only (I thought so, but I could not get it right)?

---

I am not sure exactly what you are getting at here but from what I know, all you should have to do is.

On the OU that the state workstations reside in define a GP that applies to machines only in the OU - There is a checkbox in GPMC to disable user policy. i.e your filesystem settings basically making C:\ and all subdirectories read only
Then if you want the user settings, they should already be inherited from the GP on whatever OU your user accounts currently reside in.
** Be careful that they don't conflict - may want to have the Machine policy override the user policy (again an option on the policy in GPMC)
Or you could define a new OU with the users in the State that needs to be locked down and define a User only policy on that OU that have the complimentry settings to your machine settings.

As far as still being able to write a text file is concerned I would:

Check which directories they can write to -> check the ACLs against your policy (the relevent directory may not be inheriting properly)

If the ACLs look right, check your policies to make sure lower level policies or user policies are not overwriting the settings you are after.

Basically if the ACLs has the user having read only access they won't be able to write so I would suggest it is an issue with your policy (the inheritence down the directory structure) or how it is being applied (is another policy overwriting it)

Reiterating my warning to be careful:

Quote:

---

Note: - Be very careful changing ACLs on all folders, some applications may run with the users context and not be able to write critical application files (or temporary files) if you lock out the normal user accounts from writing to all folders such as temp.

The other thing to think of is you will need to redirect their entire user profiles to State2 servers as many applications use folder in the user profile to write temporary or configuration data, the user will definately need write access to that so this will need to be redirected to State2 Servers.

As I said be very careful, make sure any changes you make are THOROUGHLY TESTED before you implement them otherwise you will have a few SCREAMING clients. You need to be especially careful about removing SYSTEM and the Administrators group from ACLs - this is especially NOT recommended.

Good Luck but as I said you need to be VERY careful when doing this and personally I don't recommend doing it at all but particularly in a hasty/hurried manner.

---

Quote:

---

Originally posted here by sard0nicpan
steve.milner:

Please elaborate and educate on : "Citrux?"

---

Goole is your friend:http://www.google.co.uk/search?q=citrix+overview

Try this one:

http://helpdesk.its.uiowa.edu/citrix...s/overview.htm

Steve

Citirix isn't really an option to solve the problem as its only a way of connecting to a remote system. That part is easy. Its the securing of the local machine that he is having issues with.

My question to you is, how far are they taking this? When you say you cannot save anything locally, does this include... swap file? tmp files? I think to really give an answer you need to know what is driving this request. The answer really depends on how far into the rabbit hole you are going.

For the local servers, you can change the shares to be "read only" shares and not have to worry about the ACLs that are on the local drive (assuming noone logs in directly and that IT support is allowed to save stuff to them by this policy).

The answer was: nothing, nada, nyet on the local hard drives.

This is why we pushed for the WYSE terminals--which we already possessed (see my earlier post). They bascially wanted to turn PC's into terminals (rdp to terminal sever), so we argued and argued and finally convinced upper management that what they really wanted were thin clients in State1.

I'm still curious as to how the original task could be accomplished. We did some partial testing and found that either we would shut the PC down totally(make inoperable), or only get partway to the requested solution. One of us could always find a way to write locally--temp folders were an obvious hole.

Thanks for the responses.

Might want to have a look at Windows Disk Protection from the MS shared access toolkit...

That being said, you should have been able to set ACLs to do what you wanted...


Ammo