Well, this gets a little complicated.
The typical solution is to persist to disk (save) the pwd as secure string (see the code of Get-SBCredential of the AZSBTools PS module).
So, you’d manually invoke
$Cred = Get-SBCredntial -UserName myAzureServicePrincipalName -Refresh -CredPath c:\folder
This will prompt the user to manually enter the secret/pwd, and saves it in encrypted form to a file in the provided folder.
In your production script you retrieve and use the credential by invoking:
$Cred = Get-SBCredntial -UserName myAzureServicePrincipalName -CredPath c:\folder
The complication here is that if this is part of a scheduled tasks that runs under a different user other than than the user who invoked the first command (with the -Refresh option), the second command won’t work because the user credential is what’s used to decrypt the secure string.
I can think of a couple ways to overcome this difficulty:
- Run the first command above with the refresh option under the scheduled task service account (Start-Process … -Credential …)
- Specify what to use to encrypt the secure string with in step 1 instead of the default current user credential. Currently Get-SBCredential does not support using other than the default current user credential to encrypt the pwd, although the underlying Cmdlets do. To that end, I’m working on a function that would use a non-exportable certificate on the computer where the script is invoked to encrypt the pwd of the Azure or other needed accounts, so that the Azure credential is tied to the machine and not to the user invoking the scheduled script…