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.
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.
Related
There are many posts on viewing and comparing secureString objects. Many use .Net's Marshal method, which even its advocates admit is convoluted. A quicker method involves placing the secure string into a PSCredential object and using the GetNetworkCredential() method. Example below:
$ssn = Read-Host("Enter your social security number") -AsSecureString
$ssn
"You entered $clearText = $((New-Object PSCredential($ssn,'.')).GetNetworkCredential().Password)"
The second line outputs:
System.Security.SecureString
The third line outputs:
You entered 123456789
This is a nice little hack. I can use -AsSecureString to (1)obscure the user's input on the screen and (2) keep the string encrypted in memory. And I can also decrypt the SecureString for String methods (check length, validate input, compare to another secure string).
Is this still secure? Certainly at the moment "GetNetworkCredential()" is called, there's a decrypted string in memory. Is that string/pointer removed after the method completes? Or does it sit in memory until garbage collection erases it?
Previously in SugarCRM, the following statement was enough:
UPDATE users SET user_hash = MD5('PASSWORD') WHERE user_name = 'USERNAME';
I can't find a single site on how to do it now with SuiteCRM?
I found this:
Can I still use MD5 passwords? I’m used to that and can easily administer passwords in the database using just MD5.
Sugar will still recognize passwords stored in MD5 format, but anytime a password is changed it will convert to the newer format. Unless very old PHP build (5.2) used in a system where better
crypt() is not available, new password will use salted hashing algorithm.
Posted it on SugarCRM's site:
https://developer.sugarcrm.com/2012/05/16/new-for-sugar-6-5-stronger-password-storage-encryption/
It turns out that SuiteCRM uses this new password format too, but, as well, it still recognizes md5 passwords, so, same sql statement works:
UPDATE users SET user_hash = MD5('PASSWORD') WHERE user_name = 'USERNAME';
I did it and it works :)
Btw, same post recommends change passwords with PHP crypt like this:
crypt(md5("newpassword"))
Maybe it can help someone else.
I know this is a total novice question, but any help would be greatly appreciated.
So I'm creating my first app in Treeline and simply want to check to see if a username / password combination is valid.
What's the best way to do that given the current machines that are available? Attempted to use the Password machine with "Check Password" but wasn't immediately clear how you take the hashed password returned from "find user" and compare it to the hashed pw already stored.
Ended up figuring this out after some trial and error.
Use the Find One User machine which will return the encrypted password. Then use the Check Password machine using your unencrypted password parameter as the first value, then the FindOneUser variable as the second.
If you click the FindOneUser bubble, it will turn into a dropdown and it will allow you to choose the password key from the dictionary.
I have a Python3 program which sends emails. It reads variables from a config file, and one of these is the password of the email account which sends the emails. Now, it is in clear text, but it should not, so I am looking for a way to hide it.
I thought about writing directly the result of applying md5 to the password, like for example:
password = 'write_here_the_password_encrypted'
But the following code would not work:
server = smtplib.SMTP('smtp.gmail.com:587')
server.starttls()
server.login(username, password)
server.sendmail(from_email, to_emails, msg)
server.quit()
Is there anyway to make work the line server.login(username, password) if the password is encrypted?
login method from SMTP needs only plain password, not some hash of it, so the only way to make it work - unencrypt password before passing to login().
But as md5 is one way hash function (or intended to be one way), so you cannot decode the password, once you coded it into md5 hash. But even if you could, that anyone who has access to you config will also could.
What you need to do - is to separate passwords and other sensitive information to separate file, and store it in safe location, not accessible to unauthorized persons.
I'm syncing users from an external system into ours. I need to set the user's password in our Active Directory.
I am only provided SHA1's of the external user's passwords and setPassword will hash whatever I is input.
Is setting the User's unicodePwd the actual hash field?
If so, can I just set it to the provided hash?
If not, how/can I set the hash being stored by Active-Directory?
AD does not store just one type of hash. When you change your password, the DC receives the plaintext version of the password, checks its complexity and then generates and stores MD4, MD5, PBKDF2 (4096 * SHA1) and several other kinds of hashes. It is because each authentication mechanism (NTLM, Kerberos, Digest,...) uses a different hash function and AD needs to support them all.
The password hashes are stored in these AD attributes: unicodePwd, dBCSPwd, lmPwdHistory, ntPwdHistory and supplementalCredentials. For security reasons, you cannot read them through LDAP or ADSI. But I have recently found a way to retrieve them and created a PowerShell cmdlet that can do that:
Get-ADReplAccount -SamAccountName John -Domain Contoso -Server LON-DC1
There is also a poorly documented way to push MD4 hashes (AKA NT hashes) to workstation or AD through the legacy SAMR protocol. As there are no built-in commands that expose this functionality, I have created PowerShell cmdlets to do that, too.
To generate a NT hash, you can use this PowerShell command:
$hash = ConvertTo-NTHash (Read-Host -AsSecureString)
And finally, this command pushes the NT hash to AD:
Set-SamAccountPasswordHash -SamAccountName john -Domain ADATUM -NTHash $hash -Server dc1.adatum.com
These commands can be used to migrate passwords between local and domain accounts or between AD and Samba. But be careful, Kerberos-AES and WDigest authentication will not work with this account, only NTLM and Kerberos-RC4.
As far as I understand you can't set unicodePwd to the actual hash field. You can use the userPasswd as you want for your own check but it's not used bys Active-Directory.
As far as I know, what you want is not possible. You can change/set passwords in AD using at least three different protocols:
LDAP (actually LDAPS)
Kerberos Change Password Protocol
NTLM - I am not sure if the latest versions of AD still support it
Am 100% sure that LDAP cannot be used, but you may want to check the other two, as there may be some way to do it with them.