Novell Home

Windows XP User Account Creation

Novell Cool Solutions: Trench

Digg This - Slashdot This

Updated: 4 May 2005

Sherry H. wrote: I work for a school system, with all Novell servers and Windows 95/98/XP workstations. As we wage the war against Windows patches & antivirus updates, we need a way to create a local Windows admin account on our workstations with a common password, in order to allow us to use the common patch/antivirus scanners available (like MBSA, etc.). Does someone have a program that can be executed through a Novell login script that would create an admin account on the workstation with a specified password? We really don't want to move to domains, Active Directory, etc., but need someway to balance the Windows workstation/Novell server environment. I would like for the creation process to not require any user intervention, but perhaps pull the account name and password from a file we can edit. The account could be a hidden account.

OPEN CALL: Anyone have a great solution to help Sherry? Let us know.


Patrick Farrell

If the account that is logging in is also admin equivalent, they can do a batch file similar to this to create a user avuser with password av123

@echo off
if exist c:\windows\avdone.usr goto done
net user avuser av123 /add
net localgroup administrators avuser /add
echo hello > c:\windows\avdone.usr

Add this to the login script.

Danny Wall

You can do this with two command lines. I prefer to make a ZfD app object out of this, and this prevents problems with the user logging in needing to be an administrator. In a login script, it would resemble this:

net user <username> <password> /add /active:yes 
 net localgroup <local group> <local account> /<ADD> 

The first command creates a user, sets the password, and activates the user. The second command adds that user to the specified group.

David Moloney

Use ZENworks to create a policy dynamic local user policy. See TID 10058297.

Jason Emery

You can run a net user command from a batch file launched using ZENworks to create the user and password on each machine. Just get on an XP machine and from a command line type net user /? to get the correct syntax. You will have to elevate privileges for the application to allow it to run as administrator on the local box when running the ZENworks app. By doing it this way the next time the machine is logged in it will create the account. This will also work no matter who logs in. Just remember to set the application to run only once on each machine that you associate it with.

Brian Mantler

There are a couple of things that can be done here.

  • First, when deploying your computers have a local admin account with a standard password set up.
  • Second, use ZENworks and net use to create an admin account. You could then add this user to the admin group
  • Third, use something like psexec from to run net use on the destination computer.
  • Or fourth, just use ZENworks to run the antivirus exe with system rights. This avoids having to create an extra admin user altogether.

Greg Nash

We've been doing this for our organization, however we also have been moving to a secured workstation model. Unfortunately only a few locations have implemented ZENworks, so I've come up with a solution that could be run from the login script.

Since the users only have restricted rights, we need to wrap the NET command to elevate its privileges to be able to create the new account. We use the CPAU utility to accomplish this.

By wrapping the NET command in the encrypted job file, we keep our admin passwords secure, and have the ability to consolidate accounts/passwords on all our machines.

To use this method, create two CPAU job files, and copy them, as well as the batch file and CPAU to a network accessible drive.

Call the batch file from your login script (i.e. @z:\addaccount)

Here's the main batch file (to be called from login script). Edit to suit your environment (usernames, paths, passwords, etc.)

@echo off
if exist C:\Documents and Settings\[NEWUSERNAME]\NTUSER.DAT goto done
cpau -dec -file 
copy z:\addaccount\*.* C:\Documents and Settings\NormalUser\Local Settings\Temp\
cd C:\Documents and Settings\NormalUser\Local Settings\Temp\
cpau -dec -file newacct.job -profile -wait
cpau -dec -file admingroup.job -profile -wait
del /q C:\Documents and Settings\Administrator\Local Settings\Temp\cpau.exe
del /q C:\Documents and Settings\Administrator\Local Settings\Temp\*.job

To create newacct.job:
cpau -u administrator -p <youradminpass> -enc -ex "net user newuser newuserpass /add" -file newacct.job

To create admingroup.job:
cpau -u administrator -p <youradminpass> -enc -ex "net localgroup administrators newuser /add" -file newacct.job

How it works:

The batch file checks to see if the NTUSER.DAT exists for the user you created. If it already exists, it just exits.

If it doesn't exist, it copies CPAU and the job files to a local temp dirctory (CPAU cannot be called off network drives directly for security reasons).

It executes the two NET commands which are wrapped with CPAU. This elevates this process only with admin privileges.

It then deletes the temp files, and exits.

Dan Verbarg

I renamed the default administrator account on all my machines. I use this account to be my local admin account. I don't keep the name the same though, I rename it to something else. There is a tool out there called renuser, so you can rename a Windows user from the command prompt.

I used ZEN to do deliver this exe locally, run it hidden, and run it as unsecure system user for those who are not admins. This way I did not have to worry about anyone stopping and seeing a batch file running with the new username and password or finding the batch file and reading it.

I then created another ZEN app to change the password using the standard windows command net use. This is also run hidden and as unsecure system user.

Both apps are set to run once and the second one is dependent on the first one running.

Now if I ever want to change the password or username, I just up the version by one and change the appropriate information.

The key is being able to do both through a command prompt and with ZEN, this way, nothing is visible to the end user.

Frits H. Willemsen

This is not a tested solution. But anyhow this is my shot at the problem.

I would use the following tools/commands.

The standard windows net user and net group command gives the opportunity to create the user and make him administrator.

On 2000/XP you have to be administrator to do this. A solution is to use Nal from ZENworks because Nal has system rights.

Make a Nal application object that runs the script. Give only workstations the right to see the script (you can only give this right through ConsoleOne in the volume directory-tree) Be sure to use UNC because the nal system user does not recognize drive letters. In this way your users cannot see the password in the batchfile.

If you don't have ZENworks you could use the runas command from windows. Obviously you will need to know the administrator's password ;-).


Placing of a password in the loginscript is a security problem because everyone has read access to it.

What you can do is to place it in a batchfile in a directory where the users only have R rights. You can call the batchfile from the loginscript. If you give it an ordinary name a possible "hacker" would hopefully not recognize it.

This is also not bullet-proof because you cannot browse to the file but you can open it if you know the name and fill it in the requestor box. This will at least give some protection.


ZENworks is the only clean and secure way. 3 times Hooray for ZEN.


For Win98 (NOT tried on 95):
Turn on user profiles, make a single local account (don't call it administrator as this will conflict with the XP advice later, but you can call it something like "Admin", etc.)

On your NetWare server, create a config.pol file using poledit from MS and using adm files you can set the default user, i.e. anyone but the "Admin" account you made have a few rights and set admin to have full rights.

Then call the config.pol file at user login.

Make the location of the config.pol file public so everyone can access it, but set the NetWare rights to read only to prevent anyone appending or deleting it.

For XP ( I assume it's XP Pro not home):
Disable the Administrator account and create a local account called "Admin" or another name, it's not important as long as it isn't a reserved name such as user, guest etc. (ours is called eggnchips) and ensure not over 8 characters for dos compatibility - pet hate is the dos "name ~1" )

And assign it administrator rights (or if you prefer, rename Administrator account to Admin etc).

On the NetWare tab there is Windows name, set this login tab to Guest as default (or whatever level of rights you wish to assign) and it will login to the workstation as (Guest,etc) while having the correct access for users.

While logged in as the user, if you want to, say, update your antivirus, you can select the file and use the "Run As" command and select (Run as) Admin.

If you leave the Administrator account name as Administrator, you may find that people lock the account by attempting incorrect logins/passwords, by renaming the account this won't happen as the Administrator's account isn't called that!

Theo Chaojareon

ZENworks is the way to go with this..... but if you want to try approaching the problem from a different angle...

You can enable automatic updating for your anti-virus and for windows. This would solve the patching. Typically this would mean pushing regkeys and restarting machines (if everyone is admin to their machines).

If you want to have more control of the updating, Microsoft offers Windows Updating Service (formerly Software Update Service) for free. Most antivirus providers offer enterprise controlled updating but it costs money.

Tom Shelton

Why don't you try using the Dynamic local user policy. Once you enable this and add users to it, if they log onto a machine it will create a local administrator account while they are logged on and then will remove it when they log off.

Siraj Matin

I created this bat file that can be executed through a Novell login script and that would create a user account on the workstation with the same name as their NDS user name and a temp password of abcabc. Later the users can synchronize their window and NDS password.

I hope this helps.

; by matin,  create users from the NDS LOGIN NAME
@echo off
if exist c:\windows\%LOGIN_NAME%.usr goto done
net user %LOGIN_NAME% abcabc /add
net localgroup administrators %LOGIN_NAME% /add
echo hello > c:\windows\%LOGIN_NAME%.usr


ZENworks for Desktops 6.5 will create the user account for you. Use the Dynamic Local User function of the Desktop product, not the whole ZENworks 6.5 suite. When you log into the PC the Novell Client authenticates you to the network and then uses its GINA.dll to create the account in Windows. The password will be whatever you logged into the network with. I have been using this for some time now on Windows 2000 and XP.

The account it creates on the PC is dictated by you to be an administrator, power user, user, etc, by what you enter into the Dynamic Local User settings in ZENworks.

Tony Pedretti

Using a ZENworks custom policy setup in an Unsecure system context/impersonation associated via workstation objects, this can be done both silently and securely. The policy calls wscript.exe from the local workstation passing a Windows script file (.vbs) stored on a network path where only the workstation objects/containers have access and can be executed during user login.

The .vbs file contains text similar to the following. You may need to adjust for your environment.


Set WshShell = WScript.CreateObject("WScript.Shell")
Set WshNetwork = WScript.CreateObject("WScript.Network")

strCOMPUTERNAME = WshNetwork.ComputerName
Set objComputer = GetObject("WinNT://" & strCOMPUTERNAME & ",computer")

'Turns error processing on, disables error prompts in the interface and 
allows the script to continue
On Error Resume Next

' try to connect to user object to see if account is a local user
Set objUser = objComputer.GetObject("user", "EnterUserObjectNameHere")

' local user exists
If Err.Number = 0 Then
	On Error Goto 0

	objUser.SetPassword "EnterUserObjectPasswordHere"

	'Set account so its not disabled
	objuser.accountdisabled = FALSE

	'Set Password so it doesn't expire
	lngUF = objUser.Get("userFlags")
	objUser.Put "userFlags", lngUF

	'Activate the above settings

'local user does not exist
	On Error Goto 0

	'Create account and populate account info
	Set objUser = objComputer.Create("user", "EnterUserObjectNameHere")
	objUser.FullName = "Enter user's full name here"
	objUser.Description = "Enter user object's description here"
	objUser.SetPassword "EnterUserObjectPasswordHere"

	'Set Password so it doesn't expire
	lngUF = objUser.Get("userFlags")
	objUser.Put "userFlags", lngUF

	'Activate the above settings

	'Add account to Administrators group
	Set objGroup = GetObject("WinNT://" & strCOMPUTERNAME & 
End If

'Clears any error numbers returned from above lines


For more information

See: Microsoft Windows Script Technologies

Or download the Microsoft Windows Script 5.6 Documentation.

You can get further information about Windows scripts from Microsoft's*

Blaze Surfer

Short sweet and straight to the point.

I'm pretty new to all this, but what I have done to overcome the problem of having a plain text password easily viewable to anyone with read access (anyone that is going to have a login script run to complete this task), is use a free coding language.

Language of choice is simple I know, but hey. Autoedit 3

This could be done with any other scripting or coding language I assume, though Autoedit allows you to run DOS or cmd line tools and commands silently without having to supply a password openly.

The code attached should be pretty self-explanatory.

You will need a copy of autoit3 - it's free but very useful.

; ----------------------------------------------------------------------------
; AutoIt Version: 3.1.0
; Author: 	S.w.Mc        
; Script Function:
;	To Create a windows user on a machine from a login script
;	without having your passwords displayed.
;	One could also look further into this and use the dos runas command
;	have this work from any user that logs in regardless of user level.
;	***Note***
;	Once you have modified variables below you would then need to compile
;	this script into an exe using the autoit compiler. 
; ----------------------------------------------------------------------------

; Script Start - Add your code below here

Global $NewUser = "Admin"					;This is the User account to be created
Global $Newpass = "******"					;This is were you enter the password you want for this account
Global $Comment = "School Administration Account"	;This is a discription of the account that is added to the windows. Optional - leave blank for nothing to be entered
Global $FName = "System Admin"				;This is the Full name section of the account. Optional - leave blank for nothing to be entered

Func CreateUser();
RunWait('net user  '& $Newuser & ' ' & $Newpass & ' /add /fullname:"' & $FName & '" /comment:"' & $comment & '"', '', @SW_HIDE)

RunWait('net user  '& $user & ' /EXPIRES:never', '', @SW_HIDE)

RunWait('net localgroup users ' & $user & ' /delete', '', @SW_HIDE)

RunWait('net localgroup Administrators ' & $user & ' /add', '', @SW_HIDE)

RunWait('net accounts /maxpwage:unlimited', '', @SW_HIDE)


Scott McGregor

To prevent users from reading your password you can use Autoedit 3 to encrypt your source code into an EXE file which in turn encrypts all text within the file.

Then when you run the EXE it runs the commands. Now, say you needed to change the password, you could either decrypt it or just keep a copy of the source code.

All this is done using the Autoedit 3 software.

Also when you do encrypt your source file or compile it as it is, you have the option to specify a password that is then required to decrypt the file for editing.

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© 2014 Novell