0

I'm currently making ADUser accounts on a server, and one of the standards here is that the accounts must have a password, even if it is a default password that all new accounts share.

I'm a bit confused by the -AccountPassword parameter on New-ADUser cmdlet, and its relation to SecureString. At the moment, I managed to squeeze out a suitable script-testing-password, but I realise that it is probably nowhere near a suitable password for an account, considering the strange parameters I've put on it to get it to work:

$password = ConvertTo-SecureString "Password1" -AsPlainText -Force

I then use this with New-ADUser: -AccountPassword $password.

Could anyone advise on how to deal with a situation like this? Is my approach suitable for a default password, or am I messing up somehow here? I haven't implemented this so it is difficult to tell if it will work effectively.

Maxime Franchot
  • 1,015
  • 1
  • 10
  • 24

1 Answers1

3

In case you have the "User must change password at next logon" set when you set a default password, this approach is pretty normal. If your task is also to not make the default password visible in plaintext, you can use save/load technique on a SecureString which is readable as 100+ hex-symbols, and can be stored as a file. You write a secure string into a file once, then read it from the file and use as a valid secure string in New-ADUser. The primary restriction of a file-based approach is that the string is encrypted by the user's data, using the user that generated the string, so you can't save a SecureString as user A then read it as user B and succeed at decryption.

Vesper
  • 18,599
  • 6
  • 39
  • 61
  • Thank you, this cleared up a lot! I printed the securestring at some point, so I think I may even be able to hardcode the hashed string directly into the document. If not, then considering that the account that has the password on it only creates accounts once, and those accounts hold their own passwords, then does the User-A-User-B problem still occur? – Maxime Franchot Jul 25 '17 at 04:17
  • Well, the problem is still there, but once User A and User B have their own passwords, even decoding the original "default" password won't harm their security. The "problem" is just if you generate the string as one user, then save, then read as another user then try to decrypt, you'll end up with garbage. This is by design. When I had to use a secure string in any script, I did a convert from plain text then save to file run as the user that'll be used to run main script, this approach never failed me. – Vesper Jul 25 '17 at 04:42
  • Does the New-ADUser command not save the user's password (taken from -AccountPassword) somewhere on their account/account details, instead of on the user who ran the script's account? – Maxime Franchot Jul 25 '17 at 04:46
  • Well it does, but once that user changes their default password that info is overwritten. So, this approach is viable for setting default password to users, provided they are forced to change it right away. – Vesper Jul 25 '17 at 04:52