Create windows user programmatially without hardcoding the password

Question

How to create windows user using some command line tool or windows API or .NET without hard-coding the password, I need a way to create a user with some password without actually knowing this password, (The program knows only its hash for example).

For example:

Any method to create a windows user with a spicific password will be like this:

UsersUtil.CreateUser("username", "SpIcif1c_Passw0rd");

I need an the code to be like this:

UsersUtil.CreateUser("username", "7604905d86ed36b69a657366e5b5c35f");
//"7604905d86ed36b69a657366e5b5c35f" is the hash for SpIcif1c_Passw0rd for example

I need the code of this CreateUser method or something similar!!

Not the downvoter, but there's very little research effort, and kind of unclear what you're asking. What have you tried? Where are you running into problems? http://stackoverflow.com/questions/384304/creating-local-user-account-c-sharp-and-net-2-0 seems like it addresses a lot of how to create an account. — Steven V, Nov 27 '13 at 16:37
My problem is not with creating the user, my problem us how to create it without hard-coding the password, there is thousands of ways to create a windows user programmatially, but you need to put the password as clear text. — Saw, Nov 27 '13 at 16:39
-1 You are not making any sense. You want to create a user with a password, but without the password. Make up your mind. — IInspectable, Nov 27 '13 at 16:50
@IInspectable I know the password hash, or any information windows can use to create the user with this password, but deffirent from the password itself. — Saw, Nov 27 '13 at 16:52
Windows doesn't store the password however, it stores only the hash — Saw, Nov 27 '13 at 16:59
So you know *The* hash. Why do you assume that all password storage facilities use the same hashing algorithm? Have you even thought this through? — IInspectable, Nov 27 '13 at 17:01
@IInspectable And as I recall, Windows uses two different hashing algorithms (LM and NTLM), so in addition to knowing those algorithms, you'd also have to know which was being used on the particular machine. I'd say the best the OP can do is obtain the password from some external source, create the user, then wipe the password from memory. — Carey Gregory, Nov 27 '13 at 22:14
@IInspectable: all he needs to know is the password hash for whatever algorithm the Windows SAM uses (MD5 IIRC). So there's really no reason in principle why this couldn't be possible, although AFAIK Windows provides no supported way to do it. It's a fair question. — Harry Johnston, Nov 28 '13 at 07:05
@Harry If he created the hash, the he must have had the password at some point, so why not pass the password to whichever facility creates a user? If he got the hash from somewhere else, the user already exists - creating it (again) is somewhat nonsensical in that scenario. — IInspectable, Nov 28 '13 at 21:20
@IInspectable: it is usually undesirable to embed a password in an executable. Someone might reverse-engineer the executable and retrieve the password. — Harry Johnston, Nov 28 '13 at 22:26
@Harry That's why you can encrypt parts of your config files. ASP.NET applications usually store passwords in their web.config files, for example. See [Encrypting and Decrypting Configuration Sections](http://msdn.microsoft.com/en-us/library/zhhddkxy.aspx) for details. The same scheme can be applied to your regular .NET application's app.config. — IInspectable, Nov 28 '13 at 22:35
@IInspectable: if the executable can decrypt the password, then so can an attacker. That is not a sensible solution. — Harry Johnston, Nov 28 '13 at 22:42
@IInspectable: note that web applications run on a (hopefully) secure server, so (in theory) nobody malicious gets to look at the config files. In most situations you can't make that assumption. (Actually it's not really good practice for web servers, either, but that's a whole 'nother story.) — Harry Johnston, Nov 28 '13 at 22:45
@Harry This doesn't make sense. You want to create a user account on a machine, and for security reasons you only make the hash available to this user. What good is this user account? You cannot do anything with it, unless you know the password. So you are creating a user account on behalf of a user that cannot do anything with the user account. What's the point in that? — IInspectable, Nov 28 '13 at 22:56
@IInspectable: Huh? What makes you think that the person who the account is intended for doesn't know the password? Perhaps a real-world scenario will help: automatically installing Windows using PXE booting. The automated script on the PXE server needs to set a known Administrator password on the newly installed machines, so that I can log in. Because PXE is unauthenticated, though, I can't stop potential attackers from seeing the script. If the OPs idea was possible, it would be a very convenient solution to this problem. Can you propose another, equally simple, solution? — Harry Johnston, Nov 28 '13 at 23:18
@Harry Something like [AdministratorPassword](http://technet.microsoft.com/en-us/library/cc766409.aspx)? — IInspectable, Nov 29 '13 at 20:59
@IInspectable: no, because then the hypothetical attacker can read the password from the unattended answer file. (It can be "hidden" but this only provides very weak protection.) — Harry Johnston, Nov 29 '13 at 21:42
It should perhaps be mentioned that various other operating systems do in fact provide the functionality the OP is asking for, and yes, it is used on occasion. — Harry Johnston, Nov 29 '13 at 22:51
@IInspectable It is very very very common and logical problem, I have a product that is installed on my clients' windows machines, I need to create a windows user on the customer machine to allow me to support this client remotely, this password is not known to the user of the machine itself, but will be known by the support team only, and in the same application I have many similar scenarios!! I don't need the password to be known in any way if the user has an access to the machine. — Saw, Dec 03 '13 at 08:51
@Mohamed It is very very very common, if you need a backdoor to your clients' machines. If you want to access your clients' systems remotely, and securely, use the technology meant to be used: [Remote Assistance](http://msdn.microsoft.com/en-us/library/aa359213.aspx). I'm surprised your customers are fine with you planting a backdoor entrance to their infrastructure. — IInspectable, Dec 03 '13 at 14:36
@IInspectable This is very clear in the our EULA of our clients, we do need unattended access to our client machines and they are happy for that, because the terminal will be used for our application mainly! I was expecting you to say that :) :) — Saw, Dec 03 '13 at 15:25
@IInspectable however your link about administrator password was very useful, thanks :) — Saw, Dec 03 '13 at 15:28

score 1 · Accepted Answer · answered Nov 28 '13 at 23:26

Unfortunately, there are two problems with this:

To the best of my knowledge Windows doesn't provide any supported mechanism. It might be possible to do this by manipulating the SAM directly, but there's no guarantee that what works today will work tomorrow.
In Windows, the password hash is a password-equivalent, i.e., anyone who knows the hash can (under certain circumstances) access the account as if he or she had the password. So using the hash rather than the password doesn't actually give you the security benefit you're presumably aiming for. (Google "pass the hash" for more information.)

If you post another question describing your scenario, we may be able to suggest alternative approaches, though I'm afraid this is typically an awkward problem to solve. Or, if you prefer, you can email me directly (see my profile for contact details) and I may be able to help.

All I was trying to do is to solve hardcoded passwords problem in some legacy code, I have found some workarounds. — Saw, Dec 03 '13 at 08:41

Create windows user programmatially without hardcoding the password

1 Answers1