Use Powershell script to pull password from active directory attribute

This topic contains 1 reply, has 2 voices, and was last updated by Profile photo of Fredrik Kacsmarck Fredrik Kacsmarck 1 month ago.

  • Author
    Posts
  • #73526
    Profile photo of Jeff Scharfenberg
    Jeff Scharfenberg
    Participant

    How could I pull a password from an active directory attribute in powershell so that i don't have to have it in clear text on the network?

    I believe I know how to set a user in a script and password.

    $user = "domain\service.account" 
    $pwd1 = "big long huge string of characters"
    $pwd = ($pwd1 | ConvertTo-SecureString)
    $Credential = New-Object System.Management.Automation.PSCredential $user, $pwd
    $args = "\\domain.local\location\location\location\Script\script.ps1"
    Start-Process powershell.exe -Credential $Credential -ArgumentList ("-file $args")
    

    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.

    thanks,

  • #73535
    Profile photo of Fredrik Kacsmarck
    Fredrik Kacsmarck
    Participant

    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.

    1.
    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.

    2.
    Any AD user have read rights in the AD.
    So any AD user would most likely have the ability to read the value.

    3.
    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.

    4.
    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.

You must be logged in to reply to this topic.