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.)
Without sacrificing system security? All I have to say is, "init s".
Half the software I support requires the user to be a Local admin. It is a problem the way we worked around it was to run that software on a terminal server.
You've comitted the gravest sin of them all, asked a question about Windows XP on Slashdot. Three nerds will arrive at your door shortly with the Linux CD and baseball bat.
This space intentionally left blank.
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.
Mabye I am wrong, but I think novell makes something that would manage users?
Does anyone have any suggestions on how to give the users appropriate rights to the machine without sacrificing system security?
What exactly do you need to be secure?
Hopefully after the first few, that'll be the last to a question like this... but then again, this is always the solution here.
/. Answer: Linux does it much better, and for less money. Get it for free here: (insert redhat/linuxiso/freebsd/mandrake/debian url here)
Legitimate Question: *I have a question regarding Windows XX and implimenting XX*
Stock
Except for the fact that most of the damn world uses windows, and the migration process is going to take a while, this elitest atitude is just going to alienate people who are stuck with windows, but use Linux in many situations OTHER than the desktop.
I'm afraid lots of the software out there is just so poorly done that you'll have to make everyone a power user.
User profiles (roaming) are always blowing up on winblows.
You'll just have to lie in the bed you have made for yourself.
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
You're right, installing Linux will be his next problem.
i wonder if carpenters gnash their teeth when people ask how to put screws in with a hammer.
you're using the wrong tool.
US Citizen living abroad? Register to vote!
Even given that Slashdot may not be the best or most appropriate place to seek Windows configuration advice, do you really think the sarcastic and insulting posts here would convince anyone of the professionalism and helpfulness of the Linux community?
Just assume for argument's sake that the original poster is a relative newbie (certainly to Slashdot), a number of you may have just given him his first taste of Open Source support. Nice job!
To paraphrase Tom Lehrer, if you can't say something nice, then the least you can do is to shut up!
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
Hey, my boss was just up at Ferris State for the RESNET conference! I'm down at Ball State...
We have a domain here, but us Housing Techs don't have any admin rights on the domain controllers... Can't do login scripts, set profile locations, group policies across the domain, blah blah blah. We asked for a simple login script, the-powers-that-be flat out said no.
This summer we're (supposedly) dropping Win98 and moving on to XP. For our staff computers, I've created a generic user that I setup just the way I like it. I image a machine and take it to someone. First time the computer boots up I run NewSID just to be safe. Then I have the person login to their domain account to create their local profile (some just give me their password even though I ask them to type it in... sigh). I take over, log them out and login as the administrator. Then I go into the "User Profiles" tab of the system properties (right click on my computer, properties) and copy over my oh-so-perfect profile over to their domain user's profile. I'll add the user as a power user, just to avoid any complaints about why they can't do this-or-that when they could in Win98.
I've been setting up a Win2k file server for the Housing staff to use. I have to use a little batch file in the local startup folder to call a login script on my server so I don't have to visit each computer if/when I need to make a change.
Student computers are simple -- we don't require students to login to use the labs. The account they use is just a "user", and I have Deep Freeze installed on all em. Let em screw the system up, just hit reboot and it goes back to normal.
Kinda lame the way things are setup, but what can ya do?
Setup a Windows 2000 or 2003 domain and enable roaming profiles.
If you can't figure it out, google for info or get a book. It's pretty easy to do.
If you are too cheap to setup a domain, don't bother.
Conformity is the jailer of freedom and enemy of growth. -JFK
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.
After many years of supporting multiple platforms, Windows included, it still astounds me that Windows is obviously not designed so an administrator can easily make changes to the normal users environment/settings/desktop in any reasonable or effecient fasion.
install xp in an unattended setup, and make the user profiles and permissions the way you need them during the first setup. that way every new account will inherit those settings. if you need to manage xp desktops and you can afford it, buy novell zenworks. solves the problem of installing apps for you the easy way. group policy's can be pretty unreliable, if you can script things. there's a wealth of commands in xp (and freeware utils) it's more reliable. i hate microsoft, but supporting linux desktop in the same configuration is not any easier!
As for the question at hand, people have already mentioned gpedit.msc. You guys apparently use Novell client for Windows for logins, and I don't know if eDirectory will serve up group policy settings like Active Directory. If this is the problem you're having, you can have gpedit save the settings locally and have them propagate from the local machine. We do this and it works great. As for distributing changes to the settings over the network, the group policy settings are stored in a text
If you need to figure out what files or registry settings a particular program uses, try regmon or filemon from sysinternals.com. These are indispensible.