Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Windows Operating Systems Software

Managing Multiple User Profiles in Windows XP? 55

Posted by Cliff from the finding-better-ways-to-do-things dept.
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?"
This discussion has been archived. No new comments can be posted.

Managing Multiple User Profiles in Windows XP? More

Managing Multiple User Profiles in Windows XP?

Comments Filter:

  • Registry, GPO XTEQ (Score:5, Informative)

    by Oriumpor ( 446718 ) * on Tuesday July 15, 2003 @04:04PM (#6445869) Homepage Journal
    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 [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.)

    • 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!

      • Be honest, now

        I never have to su to configure things that are specific to my user, only to configure system wide things.

      • Well, on my gateway I su only to upgrade and change settings, maybe once every few months. Using Connectix distro there.
        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 .DOC file because the kernel copied the wr
    • GPO's are the way to do it.

      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
      • Group Policies, recall, were a 1.0 release in their Win2000 form. Some improvements were made in their XP/Win2003 form, such as "Resultant Set of Policy", which despite the needlessly complex name just tells you what all your settings will do to a particular user or machine. I myself can't wait until Samba supports it however.

  • What Software? (Score:3, Interesting)

    by lostindenver ( 53192 ) on Tuesday July 15, 2003 @04:09PM (#6445929)
    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 Idiot! (Score:1, Funny)

    by avalys ( 221114 )
    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.

  • Group Policy or Local Security Policy (Score:3, Informative)

    by TomGroves ( 622890 ) on Tuesday July 15, 2003 @04:12PM (#6445960) Homepage
    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?

  • Secure against what? (Score:1)

    by Anonymous Coward

    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)

    by Anonymous Coward on Tuesday July 15, 2003 @04:16PM (#6446033)
    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.

  • Are we a Windows hotline now? (Score:4, Informative)

    by Finni ( 23475 ) on Tuesday July 15, 2003 @04:25PM (#6446120)
    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.

  • Well that depends... (Score:3, Informative)

    by hax0r ( 29263 ) on Tuesday July 15, 2003 @04:25PM (#6446124) Homepage
    ...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.
    • Almost - but not quite. The NTUSER.DAT for a particular user also has it's own internal security permissions. These can be viewed by importing the NTUSER.DAT using REGEDT32. The missing link is to EXPORT the user account, thus allowing the internal permissions to be reset.
    • Much easyer to just use the system applet in control panel to copy that profile over the default user. Don't forget to change permisions to everyone...

  • GPEDIT.MSC (Score:4, Informative)

    by chota ( 577760 ) <chrishota@gmail.com> on Tuesday July 15, 2003 @04:39PM (#6446314) Homepage

    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)

    by Mike Dolan ( 689707 ) on Tuesday July 15, 2003 @04:53PM (#6446484)
    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

  • sigh. (Score:1, Troll)

    by kevin lyda ( 4803 ) *
    i wonder if carpenters gnash their teeth when people ask how to put screws in with a hammer.

    you're using the wrong tool.

  • I don't envy you: Some Help (Score:3, Informative)

    by acousticiris ( 656375 ) * on Tuesday July 15, 2003 @09:18PM (#6448856)
    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
  • 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 wa
  • 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.

  • Demand Windows Logo Compliance (Score:4, Informative)

    by weave ( 48069 ) on Wednesday July 16, 2003 @08:28AM (#6451603) Journal
    It's a hard sell to your users, but unless a product has that nifty Designed for Windows XP [windowslogo.com] logo, it's a crap shoot. So many applications violate common sense rules for multiple user and/or locked-down workstations. The worse they are, the harder your job is.

    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)

    by Anonymous Coward
    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%.

    http://www.microsoft.com/downloads/details.aspx? Fa milyID=7fc46855-b8a4-46cd-a236-3159970fde94&Displa yLang=en

    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.

Slashdot Top Deals

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Close