Introduction: Powershell workflow activities are executed by the FIM Service account by default. There could be a situation where we want to run the Powershell script as another account - which means we need to save these credentials somewhere, preferably NOT in plaintext. Here I'll save the ADMA account password, since we'll use it to execute Update-Recipient on the Exchange Server (and it's a member of Exchange Organization Administrators)
Create a secure password file - Here I've chosen to save the passwords in a directory I already created c:\SecurePW\
Take a look at the file and notice it's NOT stored as plain text, but as a secure string (324 characters).
Read in the encrypted password in your PS script - This is most easily demonstrated by an example. Here we'll do a remote PS session to the CAS server and execute Update-Recipient on the target user.
Param($TargetIdentity)$pass = cat c:\securepw\adma.txt | ConvertTo-SecureString$mycreds = new-object -TypeName System.Management.Automation.PSCredential - Argumentlist "contoso\adma",$pass$session = New-PSSession -configurationName Microsoft.Exchange -Connectionuri http://DC.contoso.com/PowerShell -credential $mycredsImport-PSSession -Session $sessionUpdate-Recipient -Identity $TargetIdentityRemove-PSSession -Session $session
Here the Named Paremeter $TargetIdentity is defined in the activity as [//Target/MailNickname], one of the valid parameter values for Update-Recipient. Of course we could have used the built-in Exchange Provisioning via dropdown in the ADMA, but what fun would that be?
How does it know how to decrypt the password without a key?
Daniel, the securestring approach is not totally secure, but it is more secure than a password in plain text. I came across this post which I think explains it well: stackoverflow.com/.../how-is-securestring-encrypted-and-still-usable
An important caveat is that when the ADMA account (or whatever account we are using for this) changes the password, you will need to go through the steps for creating the secure password file.
Some additional information about the SecureString piece from the DPAPI msdn article (msdn.microsoft.com/.../ms995355.aspx)
"To protect this secret, DPAPI uses the Password-Based Key Derivation Function, PBKDF2, described in PKCS #5. First, DPAPI takes the user's password and passes it through SHA-1 to get a password hash. This is the logon credential mentioned earlier. Next, the password hash is provided to the PBKDF2 function, along with sixteen random bytes for a salt and an iteration count. The PBKDF2 function calls an additional function a number of times, specified by the iteration count, to derive a key from the given data. DPAPI uses SHA-1 for that underlying function. The default iteration count is 4000, which increases the work load required to brute-force compromise the password by a factor of 4000, without creating undue performance restrictions in normal operations."
Thank you Andrew! Very enlightening!