Slashdot Mirror
Managing Multiple User Profiles in Windows XP?
ALC Technician asks: "I work as a computer technician at Ferris State University, and we use Windows based systems for most of our faculty and student computers. We've been running into a lot of issues with user profiles, particularly in Windows XP, such as setting the systems up while logged in as Administrator and getting the configuration to propigate to the standard user accounts. Does anyone have any suggestions on how to give the users appropriate rights to the machine without sacrificing system security?"
REGISTRY... yes... that's an easy way to do this... an easier way is a little thing called Policy Objects. If you are running enough XP systems that it warrants the horrible tradeoffs of having an active directory network, GPO's are an easy way to do this (albeit managing them, and making sure the GPO changes propogate on a network can be a pain in the butt.)
You could also script a global USERS registry change and push it out to a buncha systems... XTEQ X-setup can do this for you, if you aren't adverse to hacking your registries
Or, quite simply, you could log in as the USER you want to change the options for, (in a limited environment this might be easy enough.)
Are your computers joined to a Win2K/2K3 domain, and is Active Directory in place? If so, you should research Group Polices, which can be applied on a per user or per computer (or per group of computers/users, or per domain) basis. If you don't have a domain controller, you can use the local security policy for each machine and that would apply to any user of that machine.
With no domain, usually I just set up the primary user as an administrator and install under that user name. I suppose you could then go in and shut off the administrator status back down to limited.
For new computers: Setup everything like you like it, and then copy the Administrator profile, over-writing the Default User profile. Bang whiz. If you need something more complicated or dynamic, you're looking at GPO, custom ADM templates or tools to make them, maybe some regedit or login scripts - and maybe (maybe not) roaming profiles.
...on what settings you'll be wanting to 'propigate'.
A lot can be done by simply dropping files and folders into C:\Documents and Settings\Default User\ (i.e: Documents, Desktop items, IE Favorites, Start Menu items, etc).
As for anything else, the way to go is thus: create a dummy user that is not an administrator, set everything the way you want it for the system and all programs. Restart; log in as administrator and copy NTUSER.DAT and NTUSER.INI from C:\Documents and Settings\[dummy]\ (where dummy is the name you gave to the account )to C:\Documents and Settings\Default User\; backing up the existing files first, of course, in case you've done something that would cause the system to go tits up.
Now, delete the dummy user and its file and from now on, all users added to the system will get the settings you so lovingly crafted.
You won't have to worry about permissions, because by default everything should be world readable; if it ain't, then add Everyone to the permissions for the Default User directory and don't forget to recurse down from there.
strange things are afoot at the Circle K...
Hi. at UWM, we've run into the same problems. If you're not going to be running a domain, use the group policy editor (available on every Windows XP/2000 machine by default).
Start, Run, "gpedit.msc", and hit OK.
This will bring up the group policies for the local computer, which is similar to the domain GPOs. Except, of course, that they won't be over-written by the Domain GPOs because you won't have any.
Email me if you need more help...
Here's a possible suggestion. About 90% of programs fail to run due to either file permission problems (e.g. requiring RWXD to the original program folder), or because they;re trying to write back to HKLM (most of which is RO). Use tools such as regmon and filemon by sysinternals to find the security violations. Then make a judgement call whether or not to modify the security to allow that program to run. Finally, write a security template which you can then apply to all the machines (use SECEDIT to apply). I created a custom template for our machines at work which works very well.... Cheers, Mike
I empathise with you. Let me see if I can assist.
--User Profiles: First off, I'm assuming you're using roaming profiles. That's where most profile issues stem from. I can't offer much help for you here. We don't use them corporate wide. It was attempted at first, but after we realized it would take a technical staff roughly the size of our user base to make everything run properly even *most* of the time, we opted away from this configuration for 90% of our workstations. (Limited only to our "kiosk" style machines that multiple users will access).
-- Propigation(sp?) of configuration: Your best bet is to do some of this through a GPO on your domain and the remainder through Startup or Login Scripts. And make absolutely sure you have fully tested any GPO changes before you update your production environment. (again, since you didn't state your exact configuration, I am assuming you are in a domain environment--I work in an AD domain, and its been a long time since I've screwed around with NT 4 domain architecture, so I only can hope that this is relavent to you). The general rule that I have used is that if you are trying to add to something (ie, add domain groups to the Local Administrators group), you want to do it through one of the scripts. If you require elevated privileges for the activity (again, adding groups to the local admin group), you must use the startup script. It executes as local system. The problem with the startup script is that it fires off prior to user login, so access to network resources is *somewhat* limited. Get familiar with ADSI and WMI (search on Google on these items and there are hundreds of example VBS scripts (yes, I know...VBS *bleaugh!*) They will solve many of your config problems)
-- User Rights: Unfortunately, locking down the desktop is very difficult if not impossible to do when you're dealing with Windows desktops. Even using the "Users" group, we found that out of 20 or so attempts to install different applications that included spyware, 4 of them installed completely, and 12 of them crashed just *after* the spyware was successfully installed. (The more disturbing part was that none of them would let you uninstall if you weren't an administrator).
The problem is, if you let the user write to the drive or any part of the registery, you can still install many applications. If you don't let the user write to the drive or the registery... you can imagine how useful the workstation may be. If you want to even give the user's a *challenge* at unlocking the workstation, you will have to get far more granular than the defaults. You can go so far as to lock down the system by enforcing that only select executables can run, but even that is far from fool-proof and has a huge overhead of you have a frequently evolving environment. In the end, no matter how hard you try, a simple floppy disk or any number of exploits exist to break local "security".
In doing all of this, bear in mind that legitimate software, such as printer drivers, will not install in a locked down environment. (We've had HP inket drivers that won't even print if the user is not an administrator)
The short of it is: DO the following
1. Setup a group for your techs accounts and add that group to the local admin group on all workstations (see ADSI and Startup Scripts)--(This shouldn't need to be said, but Don't give your techs the domain admin account!).
2. Rename the local administrator account to a random set of characters through a script. Reset the password to that account in the same manner. Again--It's not *perfect* but it's going to ward off some of the less vigilant amoungst your users.
3. Have a CLEAR and DEFINED Acceptable Use Policy. It's even a good idea to make your users sign it directly (Yes, pen and paper in a bit driven world). And ENFORCE the darn thing occasionally. I mean, if you really care what your users are doing with their workstations, this is an absolute must. They will be able to get past the "security", and
"God is dead!" - Nietzsche
"Nietzsche is dead!" - God
If more companies and schools demanded this from their vendors, maybe vendors would start to write better apps. It just amazes me that apps still expect to be able to write to the program directory, for example. Hell, Novell and the idea of ACLs came out when, 1985? And programmers still expect to be able to write anywhere in a file system?
The logo rules would also cover your issues with all users versus user profile settings too.
Not quite the answer you wanted, but it's either logo software, or deal with horrible hacks as has been discussed elsewhere here...
This places a shim in the process space that can fudge things. For instance a request to wrtie to Program Files will be routed to %APPDATA%.
? Fa milyID=7fc46855-b8a4-46cd-a236-3159970fde94&Displa yLang=en
http://www.microsoft.com/downloads/details.aspx
Read the help for it and you'll be surprised how much bad programming you can work around.