January 19th, 2006, 11:59 PM
No save for work stations
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.
January 20th, 2006, 07:33 AM
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.
January 20th, 2006, 09:34 AM
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.
January 20th, 2006, 04:30 PM
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
Experience is something you don't get until just after you need it.
January 20th, 2006, 08:07 PM
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.
January 20th, 2006, 09:36 PM
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
January 20th, 2006, 09:54 PM
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?
January 22nd, 2006, 10:26 AM
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.
January 25th, 2006, 02:12 PM
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)?
January 25th, 2006, 02:21 PM
IT, e-commerce, Retail, Programme & Project Management, EPoS, Supply Chain and Logistic Services. Yorkshire. http://www.bigi.uk.com