Change administrator name

[DarkShadows]

I would really like to:

1. Specify an encrypted Administrator password in winnt.sif
   
2. Rename Administrator to <NewAdminName>
   
3. Create my other new user accounts.
   
4. Autologon with NewAdminName
   

I can do all of these things, just not together. Number 1 gets in the way of number 4 as documented below.

• Encrypting the Administrator password in the EncryptedAdminPassword entry disables AutoLogon.

Has anyone found a way around this limitation? I have tried the following to the registry file from CmdLines.txt:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"DefaultUserName"="NewAdminName"
"DefaultDomainName"="ComputerName"
"AltDefaultUserName"="NewAdminName"
"AltDefaultDomainName"="ComputerName"
"AutoAdminLogon"="1"

But after GUI setup completes and Windows reboots, the first Administrator logon it gives me an error. I have used TweakUI to set the NewAdminName as the AutoLogon user, and then tried to watch what registry values changed with RegSnap. It shows DefaultUserName and AutoAdminLogon.

Any ideas?

Edited April 17, 2006 by DarkShadows

[cancerface]

@DarkShadows

Do you absolutely have to have the encrypted password set in winnt.sif?

If not, here's an idea:

Use a non encrypted password at winnt.sif, then at cmdlines run a small exe that will:

1. delete (or rename) the 'Administrator' account

2. create a new 'Administrator' account and set the password to whatever you want

3. patch the registry to autologon the new account

and wrap all the above in an encrypted exe so that the new password cannot be easily read.

The drawback in this is that the password will be hardcoded to the exe and although it will be encrypted you will have to create the exe from scratch if you want to change it ...

If this solution is OK with you I can provide more details on the exe creation ...

CF

[DarkShadows]

I know the default Administrator account can be renamed (I'm already doing that). And, I'm pretty sure it can moved to a different group with lesser privileges. But, I was under the impression that it could not be deleted. Isn't this incorrect?

Under the scenario you are suggesting, Is there any way to prevent the new 'Administrator' account from being displayed on the Welcome screen, like the built-in Administrator in account? I'm trying to hide the 'Administrator' account (and its password) from my users. If that is possible, then an unencrypted password for the original Administrator account in winnt.sif isn't so bad.

Hard-coding the password present another challenge as well. It would awesome If the program in question could pull part of the password from an environmental variable at execution time. Then, part of the password would be hard-coded (a more secure portion), while another part would pulled from an environmental variable (a portion that changed from PC to PC). Then each PC would have a unique password, but also containing a secure standard. This could be easily remembered by the people who are authorized to service the PCs, but would be difficult for unauthorized people to ascertain.

Edited April 17, 2006 by DarkShadows

[cancerface]

It all depends on the OS.

In 2K I was not able to direclty delete the Administrator account using netapi32 calls. In XP I was able to do that.

I have not done this (I am using the old 2k style + CTRL-ALT-DEL to logon) but a quick google search showed this which you can try to prevent the user from appearing on the Welcome screen.

It would awesome If the program in question could pull part of the password from an environmental variable at execution time

This one is also easy to do.

I am attaching a compiled script that I wrote which is quite dangerous and as such will not run without a switch. It is working on my english WinXP box but I doubt that it will work on a non-english system right now.

What it does:

1. Check that it is running in XP/2k3

2. Check that the user invoking it is not the Administrator that will be deleted

3. Delete the administrator account

4. create a new administraor account called NewAdmin

5. set the password of the new administrator account to 'DarkShadows' (without the '')

6. patch the registry to for autologon

7. patch the registry according to this article (untested!)

Note that this will NOT work on Windows 95/98/ME/NT/2k, it will NOT work on Domain accounts (just the local Administrator will be re-created)

Again be warned THIS WILL DELETE THE ADMINISTRATOR ACCOUNT AND WILL CREATE A NEW ONE!

So don't blame me afterwards! Run it on a virtual PC first to see how it works ...

If you're happy with it I can send you the code. Let me first work also on the environmental variable idea ...

NewAdminAccount.7z

[Edit]

You do realize ofcourse that once you enable autologon the registry will contain the password of this user as a string ...

Edited April 17, 2006 by cancerface

[DarkShadows]

It all depends on the OS. In 2K I was not able to directly delete the Administrator account using netapi32 calls. In XP I was able to do that.

I'm using Windows XP, so this isn't an issue for me.

...a quick Google search showed this which you can try to prevent the user from appearing on the Welcome screen.

Duh, I have actually read that about that tweak before. I don't know why I never thought about using it in this context!

I am attaching a compiled script that I wrote which is quite dangerous and as such will not run without a switch. It is working on my English WinXP box but I doubt that it will work on a non-English system right now.

I'm using English as well.

What it does:

1. Check that it is running in XP/2k3

2. Check that the user invoking it is not the Administrator that will be deleted

3. Delete the administrator account

4. create a new administrator account called NewAdmin

5. set the password of the new administrator account to 'DarkShadows' (without the '')

6. patch the registry to for autologon

7. patch the registry according to this article (untested!)

1. Good

2. Smart

3. Great. I didn't think this was possible. Have you used this for some time? Are there any Windows issues as a result?

4. So this could be changed (hard-coded) into a customized (encrypted) copy of the code.

5. Same as 4. above.

6. Have you tested this to ensure that the NewAdmin in fact does logon automatically?

Note that this will NOT work on Windows 95/98/ME/NT/2k, it will NOT work on Domain accounts (just the local Administrator will be re-created)

No problems with this, it really shouldn't do this anyway.

You do realize of course that once you enable autologon the registry will contain the password of this user as a string ...

Hmm... This is not good. Like I said above (which i just edited because I didn't say it too clearly), I have used TweakUI to set a user to AutoLogon, and in TweakUI one specifies a password, however using RegSnap, I have never seen the password anywhere. But this was with the renamed Administrator account, which may work differently than another user account.

See, we can't have the password out in the open, that is the major requirement to all of this madness. We want to control what the user accounts are, and what there passwords are, but we do not want them out in the open. If they sit there unencrypted in the registry, they are out in the open. Somehow the most recent version of TweakUI handles this correctly. I'm just trying to find a way to do it before Windows boots the first time.

I have to duck out of my office, customer has developed huge issues. I won't get back to testing this for a couple of days. But I appreciate your assistance!

[cancerface]

I am a bit confused then.

I was under the impression that you wanted to rename the admin account before the 1st GUI logon, enable autologon and (here is my assumption) login with that account (auto), do whatever (create users etc), disable autologon, then leave the station in a state where users can login without seeing the administrator account on the welcome screen.

So why do you need an encrypted admin password?

If you login as NewAdmin (or whatever the account is going to be) then you can change the registry key that enables autologon for this particular account and then logoff, leaving the station in a mode where users can login and use it without having any traces of the admin password in the registry ...

6. Have you tested this to ensure that the NewAdmin in fact does logon automatically?

Yes.

CF

[DarkShadows]

I am a bit confused then.

I was under the impression that you wanted to rename the admin account before the 1st GUI logon, enable autologon and (here is my assumption) login with that account (auto), do whatever (create users etc), disable autologon, then leave the station in a state where users can login without seeing the administrator account on the welcome screen.

• Rename default admin before first GUI logon – correct, this is the best time to rename this because you rename the associated folders as well, and before installing a bunch of software.
  
• Enable autologon – correct, but this will be disabled after all software is installed, and before the next reboot.
  
• Login with that (the renamed default Administrator, or the newly created NewAdmin) account – correct, one time only.
  
• Do whatever (create users etc) – execute installations from GUIRunOnce and RunOnceEx without having to manually logon. However, all user accounts are created in a script launched from CmdLines.txt at T-12.
  
• Disable Autologon and hide the default Administrator account (and/or the newly created NewAdmin account) on the Welcome Screen – correct I plan to have this first Autologon automatically disable itself before it reboots the PC again (but after all the software is installed).
  In other words, I plan no human-interactive actions during the AutoLogon session.
  

So why do you need an encrypted admin password?

Because it presents a security risk.

The Admin password must be unencrypted in the winnt.sif file to support AutoLogon. If someone new what they were looking for, they would have easy access to this password, by simply opening winnt.sif. It is already fairly easy to tell what the New Administrator's user name is by looking at the folders in %SystemDrive%\Documents and Settings. So you would also have easy access to the password, so there goes security out the window. While the Admin password can be encrypted in winnt.sif, doing so disables AutoLogon. I wanted both an encrypted password and AutoLogon.

What you are working on sounds very impressive, but it seems it might have a similar vulnerability, though in the registry. From what you said before, using your code stores the password for NewAdmin unencrypted in the registry. Thus during rebuilding the PC from the XPCD, this password is once again accessible, if a user knows what to look for. (I do not know this is the case in your solution, it just sounded like it might be to me).

So either way, the winnt.sif autologon, or your solution, the rebuild CD would go to my customers with an unencrypted system administrator password on it. I want them to have the XPCD, but not the System Administration account password. I create their own account (at T-13), with Admin privileges, but I do not want them to have access to the System Administration account that is created for the people who maintain the PC. This way we can ensure that one account remains pristine. Of course, the customer could always go in and reset the password on this account from their own account, or even delete this account altogether. But this is okay with us. Customers are free to change this password, or even delete the account itself—doing so means that they have severed their support contract with us. We just do not want them (or anyone) to learn what our system administrator password is, since it is somewhat standard across different customers. For those customers who maintain service contracts with us, we want unfettered access to their PCs so we can perform software upgrades, maintenance, etc. This is all for customers in small businesses where we are not connected by a single Domain. A technician walks up to the PC to perform maintenance. We want the techs logging into a system administration account, and leave the customer accounts alone. Conversely, we want the customer in their own account and leave the system administration account alone.

If you login as NewAdmin (or whatever the account is going to be) then you can change the registry key that enables autologon for this particular account and then log off, leaving the station in a mode where users can login and use it without having any traces of the admin password in the registry ...

This would be okay if we always installed the XPCD. However, the customer gets a copy of the XPCD to rebuild their PC (in case something terrible happens and we cannot get out to them, or they do not retain support services from us). Thus if/when they re-install XPCD onto the system, our password would be out in the open, unencrypted, during that first reboot.

We do not mind that customers can build the system from the XPCD using our System Administration account (the default MS one or a newly created one). We do not care that they can change this System Administration account password, or even delete the account. If they decide to lock out our support techs (by changing our System Administrator's password, or by deleting our account), they are severing their support relationship with us, which is fine—it is their PC. We just do not want them to know our password, that is for our support techs. So we want the XPCD to configure the system for us to support the PC, but hide our password from the customer.

[cancerface]

I see ...

Well M$ has an article describing the risk but there seems to be a way to encrypt the password after all according to this MSDN page.

If this is indeed the case then even if you had an encrypted password at winnt.sif, you can run at cmdlines a tool to delete/rename the admin account, set autologon for the new account and encrypt the password.

I'll play around with this and let you know

CF

[RogueSpear]

I always set AutoLogon entries at cmdlines in a VBscript. Some other food for thought: you can also rename the Guest account and strip away the description, create a fake Administrator account with the default description and make it a member of the Guests group.

And here's a story to start your day off with. I always delete the local admin account from my installs as we've talked about in here. Well one day, someone in a senior level position decided he was a computer expert. So he thinks that unjoining a computer from a domain is somehow going to fix it. Soooo.. no domain membership, no local accounts = neutered computer. Of course this was not his fault. Somehow it was a mistake of the IT department.

[cancerface]

@RogueSpear

Are you referring to this? If not, could you provide the code that will create the password for the administrator at cmdlines then enable autologon without leaving the password as a clear text entry in the registry?

I think the page that I quoted earlier achieves that however, without testing this, it appears to me that the only person who would be able to encrypt his/her password allowing autologon would be the user himself/herself ...

The CryptProtectData function performs encryption on the data in a DATA_BLOB structure. Typically, only a user with the same logon credential as the encrypter can decrypt the data. In addition, the encryption and decryption usually must be done on the same computer

(taken from here)

Kind-of-what-happens in DarkShadows's case: using TweakUI (logged as the admin user) he is enabling an encrypted password which does not appear in the registry. He achieves that however on a session that he has already authenticated as himself, and not as the system account from T12 ...

...

CF

[Edit]

I would not delete the administrator account. In fact I would do what you describe RogueSpear, create a new administrator account, hide it (as DarkShadows suggested), rename the old admin acount, add a looooooong password with many many special characters in, remove from the admin group + disable it (same for Guest account) ...

Edited April 18, 2006 by cancerface

[RogueSpear]

Actually that thread was not what I was referring to, but nonetheless what I do does in fact place the password in the registry in plain text. I don't think that this is that big of a deal however since when the install is completed, those registry entries are cleared out.

I used to be a major security freak myself and would never have considered this to be an acceptable thing to do. But that was in the past. Look at your environment and take practical measures. Spending hour after hour trying to secure something that has little to no chance of actually being compromised is really a waste of time. Unless you are mandated by law to take certain measures (some government agencies, HIPPA, etc) I would step back and look at things, then re-evaluate.

[cancerface]

@RogueSpear

Fair enough.

However the discussion was about getting an encrypted password all the way through so that it won't be exposed as clear text at all

To be honest I don't mind having it there in the first place. In fact I am using clear text passwords on my machine but then again I do not have any clients that rely on that, as DarkShadows does …

@DarkShadows

1. Run unattended using an encrypted password in winnt.sif

2. Run a script to create the new admin (say NewADmin) @T12 (+ delete/rename the default Administrator) WITH autologon (ie clear text in the registry)

3. First GUI that you get, run a script that will do anything you want + will CHANGE the NewAdmin password to something new (this may be, as you suggested, part of an environmental variable, part hardcoded to the exe)

3a. Write a registry key somewhere that you can read later on and says (somehow) that step 3 succeeded

3b. Clear the autologon feature

4. Reboot

Now, your clients can login and do whatever. If they change the pass of the NewAdmin (which you know from step 3 but they don't) then they are severing their support relationship with you.

If the NewAdmin's password is left as the one you set in step 2 AND the flag that you set in step 3a is not there then again you clients are severing their support relationship with you since they did not allow the setup to finish (ie they somehow interfered) ...

Not perfect, but a though nonetheless...

CF

[RogueSpear]

Another option for this scenario that involved support is create a compiled AutoIt script that creates the account. You could run the .exe file during the install, include it on a distro CD, or just make it available for download on your support page for customers to install in the event that they need support. A slightly more complex method would be to make a VBscript that is signed and encrypted. The AutoIt executable method would probably be easier to make and would be more elegant in execution. The downside is that I don't know what sort of security is implemented in compiled AutoIt scripts, so I don't know how hard it would be for someone to decrypt it and obtain the password. My guess is that while it's not a trivial thing to do, it probably doesn't live up to NSA/DoD standards either.

If the account is for authentication to facilitate remote desktop, DameWare, etc. then presumably they would have to have Internet access for that sort of support. If they're bringing the computer in to a service center for support, simply tell them that they need to run the file prior to bringing it in. Or you could just make it a silent part of your general installation routine.

EDIT: In thinking this over, I suppose it would be possible for a keyboard logger to intercept the password when the script executes. Something to think about I guess.

Edited April 18, 2006 by RogueSpear

[DarkShadows]

Let me first say, thanks for all the great ideas you two!

Second, it's a shame Microsoft doesn't support encrypted password with Autologon. I'm sorry but that is so short-sighted to me. If they could justify the development of encrypted passwords they must've acknowledged that as a reasonable business security requirement. But Microsoft seems to think that all PCs are built on a network. But this is simply not the case in a small office home office environment.

@DarkShadows

1. Run unattended using an encrypted password in winnt.sif

2. Run a script to create the new admin (say NewADmin) @T12 (+ delete/rename the default Administrator) WITH autologon (ie clear text in the registry)

3. First GUI that you get, run a script that will do anything you want + will CHANGE the NewAdmin password to something new (this may be, as you suggested, part of an environmental variable, part hardcoded to the exe)

3a. Write a registry key somewhere that you can read later on and says (somehow) that step 3 succeeded

3b. Clear the autologon feature

4. Reboot

Now, your clients can login and do whatever. If they change the pass of the NewAdmin (which you know from step 3 but they don't) then they are severing their support relationship with you.

If the NewAdmin's password is left as the one you set in step 2 AND the flag that you set in step 3a is not there then again you clients are severing their support relationship with you since they did not allow the setup to finish (ie they somehow interfered) ...

Not perfect, but a though nonetheless...

CF

Actually, as I was typing my last post, I was thinking in the back of my mind about a process that was something along these lines. However, I kept hitting stumbling blocks (reasons it might not work). Forgive me, for being laborious here. I'm going to just think-out-loud-and-type through the steps to you've suggested to ensure I accurately envision how this would all work, or see if I can identify and/or mitigate any concerns I had before (when I was thinking of a similar process).

1. Run unattended using an encrypted password in winnt.sif
   I was about to say that there is no real point to encrypting this password if AutoLogon is used. But then, upon further review of the subsequent steps, I realized the PC would never actually autologon using this account. So this password is encrypted only to secure (as in lock everyone out of) the default Administrator account (which will also be renamed to say "OldAdmin" and moved inside of a non-privileged group later). Since we are never going to log on with this account, this password should be very long and strong (lots of special characters) and of course encrypted. (It's too bad this password can only be produced with Setup Manager, else it is just begging to be randomized as well.)
   No need to code this, this is done within Setup Manager and winnt.sif.
   Q: Should winnt.sif include the AutoLogon setting for the purpose of your program?
   
2. Delete or rename the default Administrator (and the default Guest account) @T12.
   I think I'm going to opt for renaming this user account and locking it down, mainly because I don't want to "break" Windows XP. There is no need to develop something new in order to rename the user account; renuser.exe does this already. Furthermore, since this account is essentially being disabled, it can be randomly renamed from PC to PC, and randomly assigned a password; both easily done with the Net LOCALGROUP and Net USER commands respectively, both with the aide of the Environmental Variable %RANDOM% (which generates a semi-random number).
   Q: Is there a command to disable an account via the command prompt in Windows XP?
   
3. Run a script to create the new administrator account (e.g. "NewAdmin") @T12.
   Since this user account's password will be reset later (and would be stored in the registry unencrypted) anyway, there is really no point to even setting a password at this stage. Thus creating this user and granting it administrator privileges is easily done with the Net USER and Net LOCALGROUP commands respectively. I'm also not-at-all concerned about the customers building their own computer with this account when it does not have a password—only when the technician's password is set do I care to protect it.
   Thus far we have been able to do every stage with existing technology, which at this point is setting an encrypted password in winnt.sif, and running a script like this below:

   :: Create an unprivileged security group.
   
   	 Set Disabled=D%RANDOM%I%RANDOM%S%RANDOM%A%RANDOM%B%RANDOM%L%RANDOM%E%RANDOM%D
   	 Net LOCALGROUP "%Disabled%" /ADD /COMMENT:"This group contains all default Windows user accounts that have been disabled. Do not grant this group any permissions on your system!"
   
     :: Move the default Administrator and Guest accounts to the unprivileged group.
   
   	 Net LOCALGROUP "%Disabled%" "Administrator" /Add
   	 Net LOCALGROUP "Administrators" "Administrator" /Delete
   
   	 Net LOCALGROUP "%Disabled%" "Guest" /Add
   	 Net LOCALGROUP "Guests" "Guest" /Delete
   
     :: Set semi-random and difficult passwords for default Administrator and Guest accounts.
   
   	 Net USER "Administrator" "#%RANDOM%@%RANDOM%*%RANDOM%~%RANDOM%&%RANDOM%$"
   	 Net USER "Guest" "#%RANDOM%@%RANDOM%*%RANDOM%~%RANDOM%&%RANDOM%$"
   
     :: Rename the default Administrator account (requires Renuser.exe).
     :: NOTE: the new name must always be enclosed in quotes!
   
   	 Renuser.exe Administrator "A%RANDOM%D%RANDOM%M%RANDOM%I%RANDOM%N"
   	 Renuser.exe Guest "G%RANDOM%U%RANDOM%E%RANDOM%S%RANDOM%T"
   
     :: Create a new System Administration account, and add it to the Administrators group.
   
   	 Net User NewAdmin  /add /fullname:"System Administrator, Fabrikam Co."
   	 Net LOCALGROUP "Administrators" NewAdmin /Add
   
     :: Create any other New User Accounts here.
     :: ------------------------------------------------------------------------

   
   

4. Set Autologon to NewAdmin account @T12.
   Q: This I do not know how to do. Can you help with this one?
   I tried to figure out what the registry settings governed this using RegSnap, but I don't think I got it correct. Now it should be easier, without a password requirement.
   
5. First Boot into Windows Full GUI
   • Windows logs on as NewAdmin – Windows should do this automatically, assuming the previous step works as planned.
     
   • Execute RunOnceEx and GUIRunOnce – Windows should do this automatically, assuming the systems engineer (that would be me) builds the XPCD correctly.
     
   • Execute any other cleanup scripts – Windows should do this automatically, assuming the systems engineer (that would be me) builds the XPCD correctly.
     
   • Change NewAdmin's password to something new and more secure.
     Q: This I do not know how to do. Can you help with this one?
     I can code, but I have yet to play with Windows Scripting Host. So I could use the help here. Here are some ideas I have thought about:
     • This code should be "seeded" with an secret portion of the password (changeable upon compilation, or through some other method).
       
     • The other portion of the password should come from an environmental variable. The name of this environmental variable should be passed as a parameter when the program is executed.
       
     • The program should write a log file detailing what happened and when (minus the new password of course, perhaps with version or build # so as to give a clue of the password seed value).
       
     • Write a status code to a registry key somewhere that can be referenced that each step succeeded.
       

[*] Clear out the autologon details for NewAdmin – This should be a simple registry file import.

[*] Hide NewAdmin from the Welcome screen – This should be a simple registry file import.

[*] Reboot the PC, ready for customer to logon – Windows should do this automatically, assuming the systems engineer (that would be me) builds the XPCD correctly.

Any subsequent system administration duties performed after this stage, are assumed to be entirely manual operations.

I believe this would have the best case (given all of the requirements and constraints). The critical success factor would be how securely the password seed is stored in the code that assigns it.

[cancerface]

Hmmm, lets see:

Q: Should winnt.sif include the AutoLogon setting for the purpose of your program?

No clue. Never tried it before so I am not sure what to expect. I doubt that it will affect things however.

Q: Is there a command to disable an account via the command prompt in Windows XP?

How about doing what was suggested by Jotnar at the first page of this thread:

@echo off
echo Renaming/Creating Accounts
net user guest {s2J234OPH}
renuser guest notguest
net localgroup guests notguest /delete
renuser Administrator admin
net user /add Administrator /active:no /passwordchg:no /passwordreq:yes
netuser Administrator /pwnexp:y
net user Administrator {s2J234OPH}
net localgroup users Administrator /delete

4. Set Autologon to NewAdmin account @T12.

Q: This I do not know how to do. Can you help with this one?

Well this is the tricky part and I can't say I have a direct answer, yet.

According to this MSDN page it is possible to encrypt one's pasword for autologon using the LsaStorePrivateData function of advapi32. M$ warns you not to use the older LSA private data functions and to move to the safer crypt32 ones. The downside to that is that you lose compatibility with WinNT 3+ (!) which is not a problem in your case as you are dealing with XP. However the problem with crypt32 functions is, according to this MSDN page:

... Typically, only a user with the same logon credential as the encrypter can decrypt the data. In addition, the encryption and decryption usually must be done on the same computer...

So here we are, @T12 running scripts logged as the system account trying to encrypt the password of the newly created admin account. Who knows, maybe it can be done. M$ says typically leaving some hope ...

5. First Boot into Windows Full GUI ...

-Windows logs on as NewAdmin – Windows should do this automatically, assuming the previous step works as planned.

-Execute RunOnceEx and GUIRunOnce – Windows should do this automatically, assuming the systems engineer (that would be me) builds the XPCD correctly.

-Execute any other cleanup scripts – Windows should do this automatically, assuming the systems engineer (that would be me) builds the XPCD correctly.

-Change NewAdmin's password to something new and more secure.

Q: This I do not know how to do. Can you help with this one?

I think so. I'll try to reformat this example and make it work. I'll keep you posted

CF