Avoiding the Windows 2000 Local Profiles Nightmare
Novell Cool Solutions: Trench
By Charles Hucks, Tommy Carter
Digg This -
Posted: 27 Aug 2002
Current version: ZENworks for Desktops 3.2
[Note: Freshly updated with a new suggestion.]
One of the worst crimes against network administrators to date is the forced implementation of user profiles with Windows NT/2000. Microsoft didn't think that one through well enough. So we need a way around it that makes sense. First, I'll give you our solution, then I would like to recommend some improvements in ZEN that could help solve this problem for us.
Most software is per machine, rather than per user. Also, network administrators with more than ten workstations to manage tend to like standardization. So the best thing to do is force everyone to use the same local profile, on a per machine basis. We accomplished this by creating a local user account named 'Workstation'. We liked this name since the logout option on the taskbar would read 'Log Off Workstation'. This user is a member of the local Administrators group. In our case, we found that keeping the user out of this group caused certain software to malfunction. Local security is implemented through ZEN packages. We use a Dynamic Local User policy to manage the existing local account 'Workstation'. Since you don't want your local documents blown away at each logout, setup volatile user caching through Client 32 and use a large window like 365 days. We figure if a user doesn't login to a machine for 365 days, then the documents are expendable. That period may or may not work for you. Associate your users with your ZEN Dynamic Local User policy. If your machines never disconnect from the network, that's all you need. Every user will login with the same local account and the documents won't be destroyed. You can use different ZEN packages to dynamically remove and insert the local user into different local security groups if you like, however as I said, we chose to leave it in the Administrators group.
If your machines do disconnect from the network, you'll need to arrange for users to be able to log on locally without Dynamic Local User. Since ZEN sets the local password to something random (thanks guys) you need to change the password to something known. We wrote a VB script that changes the local user account password at every login. We actually set it to blank. So when users disconnect from the network, they check the box to log on locally, the account 'Workstation' automatically appears because we set it up as part of the Client 32 location profile, and users click OK to login without a password. If you need a password on the local account, of course you can set one, but you'll have to tell users what it is. So the question is how do you set the local password? Of course, you could create a ZEN app that uses the 'NET USER' Windows 2000 command to change the password. If the user account is 'Workstation', the command would be in the form of 'net user workstation password'. This way won't allow a blank password, so far as I've seen. A better way (the one we use) is to write a VB Script to do it for you. With VB Script, you can set a blank password and the script can be encrypted to hide your commands.
Of course, this works for us because the local user is in the Administrators group. If you can't allow that, you'll have to find another method of changing the password, since this one requires that you run it as an Administrator user.
Here are some suggestions for changing the password if you can't allow the local user to be an administrator:
- Windows 2000 has a very useful, almost workable 'RunAs' command line utility that would allow any user to run your command line script in the security context of an Administrator user. The problem with their runas utility is that you can't pass the administrator user's password command line - it's interactive only. That's less than ideal, so see options 2 and 3.
- We found a useful utility called SFImpersonator from the Script Factory. You copy SFImpersonator.dll to the system32 directory and register it using regsvr32.exe. Then you can write a VB Script that calls this DLL, impersonate another user on the system (Administrator) and change the password. Since the script is encrypted, your Administrator password isn't viewable. Since we got this working, the people that wrote SFImpersonator have apparently fallen off the face of the earth. I have included it here. When we found it, it was a free utility. I would have to assume that's still the case - of course, who would dispute it? I've also included the scripts that we wrote for it (very simple).
Contents of password.zip
- SFImpersonator.dll - Runas utility without the hassle unsupported but free
- Encode.wsf - vbscript file to encrypt .VBS files into .VBE files
- Setpass_Simple.vbs - vbscript file to change password, assuming logged in user is an administrator
- Setpass_SF.vbs - vbscript file to change password using SFImpersonator, in case your local user isn't an administrator. You'll need to customize the script with your own local Administrator account name and password. Pretty easy.
- If you don't like the "free DLL from a company that's no longer around" solution, there's a product called TQCRunas which does basically the same thing as Microsoft's Runas, with more flexibility. It works well and is reasonably priced, based on how much work it can save you. Get more information on this one at http://www.quimeras.com.
One of the above should work for any situation. As I mentioned, we're OK with the local user being a local Administrator account, since much of the software works poorly if you're not, and subsequently use the encyrpted simple VB Script for changing the password at every login.
Things that Novell should do with ZEN to help us with this issue:
- Give us the ability to not destroy the local user upon logout when ZEN is managing the local account.
- Give us the option to set the password to something we know for the local managed account, or at least make it blank.
- Give us the option to cache local profiles indefinitely.
- Give us hooks into the 'Run As' functionality of Windows 2000 with App Launcher. Obviously, it's possible.
I hope that all of this helps someone get around the local profiles nightmare.
Garth wrote: You could also use "Security Context" from www.codemill.net (which is supported, and is a COM DLL).
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com