But what I'd prefer do is store the password in the users blank attribute and have the $pwd1 pull it from that attribute. Thus a password won't be in a policy in clear text as i want to push this in a GPO to start a script to cleanup Windows 10 for an enterprise environment.
Not sure what the point would be?
I would be happy to stand corrected since I've looked into this before but there don't seem to be a "great" solution.
By using DPAPI (as you do with ConvertTo-SecureString) you would still have to decrypt the string using the same account that created the string and on the same computer.
So it's kind of moot if you want the code/password portable.
Any AD user have read rights in the AD.
So any AD user would most likely have the ability to read the value.
A better option would be to use a key rather than using the default behaviour of ConvertTo-SecureString (e.g. ConvertTo-SecureString -Key ).
But then you would need to store that key somewhere that is accessible to whatever code you want to run.
Then you need to secure that location with e.g. locking down the share/security on the folder/file.
Most articles I read at the time really didn't recommend creating your own key storage, which you would do in point 3.
But it all depends on how much you need to secure the password.
E.g. if a breach of the password have a small impact then maybe storing the password key in a locked down folder is enough.