It is a wrapper around Get-Credential, with some extra features. But instead, I have a better option: a PowerShell module you can use in your own projects that does all the hard work for you. That means you don’t need an encryption or decryption key at all.Īt this point, I could show you examples of how to use these cmdlets, as many others already did. And DPAPI uses your logon credentials to encrypt and decrypt the data. But if you don’t specify the -Key or -SecureKey parameters, the Windows Data Protection API ( DPAPI) is used. But wait… where do you store the decryption key? That is where the PowerShell “ConvertFrom-SecureString” and “ConvertTo-SecureString” cmdlets come to the rescue.Īt first, these cmdlets don’t seem to help much. The only option left is storing your credentials in an encrypted file. Remember: administrators can get access to any file. And storing credentials in an unencrypted file, which hopefully only you have access to, is not much better. Storing your username and password in the script itself is the worst choice you can make. If you can’t use IWA, then entering your credential every time you start a script gets annoying very fast, especially if you have to enter your credentials several times a day.
The problem is: IWA only works if the resource is Active Directory aware and in the same Active Directory domain or a trusting domain. Using Integrated Windows Authentication (IWA) is by far the most secure option, and you should always use this if possible. Store the username and password in an encrypted file.Store the username and password in a file protected with an ACL.Store the username and password in the script itself.Request the username and password every time you run the script.When you write a script that uses credentials to access a resource, there is always the dilemma of how to request or store those credentials, especially when other users are going to use your script.
0 kommentar(er)
