Managing Multiple User Profiles in Windows XP? 55
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, GPO XTEQ (Score:5, Informative)
You could also script a global USERS registry change and push it out to a buncha systems... XTEQ X-setup [xteq.com] 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.)
Re:Registry, GPO XTEQ (Score:1)
What he said. Microsoft excreted Win2K and WinXP with the idea that they will be joined to a domain where everything is taken care of by GPO's and such.
On the other fork, how many of you run Linux as root, or, if not, how often do you 'su' or 'sudo' to get things done, eh? Be honest, now!
Re:Registry, GPO XTEQ (Score:1)
I never have to su to configure things that are specific to my user, only to configure system wide things.
Re:Registry, GPO XTEQ (Score:2)
On the internal server, running Mandrake, I su to run updates as needed and to power down/reboot. Almost never there.
On my personal workstation, I su to install, update, and change settings. As this is a development box, fairly frequently as I test new things. But I never find I have to su to run programs, mess with my personal settings, load the
Re:Registry, GPO XTEQ (Score:2)
Sadly, GPO's are the most retarded idea MS ever developed.
There is no way to debug what you're doing -- as your directory gets older and more complex, things will get ugly. You'll have no idea why people can change their password when they're logged in, but not while they are logging in and prompt to..
out
Re:Registry, GPO XTEQ (Score:1)
What Software? (Score:3, Interesting)
You Idiot! (Score:1, Funny)
Re:You Idiot! (Score:5, Funny)
It had better be at least linux 8 or higher.
Re:You Idiot! (Score:1)
Re:You Idiot! (Score:2)
--Bryan
Re:You Idiot! (Score:4, Funny)
Re:You Idiot! (Score:1)
Yeah man. Excellente! It'll be like when Michael Bolton (the skinny coder) in Office Space beat the fax machine with the wrong end of the baseball bat.
Group Policy or Local Security Policy (Score:3, Informative)
Re:Group Policy or Local Security Policy (Score:2, Informative)
Re:Group Policy or Local Security Policy (Score:1)
Damnit.
Software Alternatives (Score:1)
Re:Software Alternatives (Score:1)
Re:Software Alternatives (Score:1)
Secure against what? (Score:1)
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?
Hmm (Score:3, Informative)
Are we a Windows hotline now? (Score:4, Informative)
Well that depends... (Score:3, Informative)
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.
Re:Well that depends... (Score:2, Informative)
Re:Well that depends... (Score:1)
GPEDIT.MSC (Score:4, Informative)
Hi. at UWM [uwm.edu], 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...
Security Templates (Score:4, Informative)
Great attitude, dude(tte)s (Score:2, Insightful)
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, t
Re:Great attitude, dude(tte)s (Score:2, Interesting)
You have to know your enemy (read: Gates) before you can defeat him. Truly the only reason I *HATE* Microsoft is because of their license agreements, and their corporate tactics. I don't *hate* Windows XP, but I won't sell my soul in a license agreement to Microsoft so that they can feel warm and cuddly that I have not stolen their software.
I can't stand a company that just blatently assumes that e
sigh. (Score:1, Troll)
you're using the wrong tool.
I don't envy you: Some Help (Score:3, Informative)
--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
What we do... (Score:2)
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 wa
Domain, reading (Score:2)
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.
Demand Windows Logo Compliance (Score:4, Informative)
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...
Application Compatibility Toolkit (Score:1, Informative)
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.
Windows is not a NOS (Score:1)