Hi,
Am I correct in thinking that when running a task with additional task parameters (Authentication), that I cannot used the “Local (as specific user)” when that Windows user account has been associated with a Microsoft Online account?
Cheers
While I’m on the subject, there is a “Browser Documentation” link in this setting window that doesn’t appear to work as yet (for a few credential types). Can I assume this is for later use?
So the reason for thinking about this is that I have been playing with the PowerShell Secret Management, although this runs under a user scope, but a Certify the Web task with the default authentication would run under a local service user account. My initial tests are on a normal machine with an account associated with a MS Online account.
However, I noted that Certify the Web now has all sorts of stored credentials (such as a normal username/password). How can those credentials then be referenced from a PS script?
OK, FWIW I setup a new local user and defined a stored credential for that user, then set the authentication on the task (PS1 script) to use a Local specified user set as that stored credential.
However, I was still running into issues retrieving secrets and encrypted passwords stored in files for that user content. In the end, I decided I would simply add the following to the script to see what was output:
$env:UserName
Turns out the the machine name was output, so it appears as if the script is not running is the user context.
machineName$
I can’t help but think this would be simpler if I could pass in the other stored creds as arguments into the scripts.
Update - I also added [System.Security.Principal.WindowsIdentity]::GetCurrent().Name to the script and this confirms the user identity the script is running under:
NT AUTHORITY\SYSTEM
Hi, I’ve released v5.1.9 now with a new LogonType selection in the Powershell script task, this lets you decide between the types of impersonation logontype. Usually this is either Network (this works for local users as well as domain users) or New Credential (this is the default and is particularly useful for some processes this in turn have network logons to other resources, but I don’t pretend to understand all the combinations). See also https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-logonusera?redirectedfrom=MSDN
I’ve yet to test this with powershell secrets and there will undoubtedly be other scenarios to consider.
So after basic testing with PS Secrets it would appear that still doesn’t work, I think that’s because the impersonation library we use doesn’t load the user profile. We might have to leave significant changes to impersonation (i.e. implement our own methods instead of using the library) for 5.2 so that it can go through beta testing.
As an aside I note your task probably exports a PEM certificate file, note also that there are built in tasks that do that to various extents, they can also copy the exported file via UNC or sftp.
Thanks for this. Yes, we use PEMs, although the reason to use a Secrets Vault to to enable the script to dynamically manage multiple black box appliances certificates via a RESTful API. SFTP or UNC is not an option.
Essentially, the post certificate update task will launch the generic script that reads in data about this system form JSON file (such as the FQDN to connect to, the Managed Cert that would be used, and of course, the cred used to connect to the API.
I have the PoC working with embedded plain text creds in the JSON file, which I would like to avoid 
. The only reference should be to the secret identifier name saved to the vault, and with the script running as the specific user, it would then read in those creds. Again, all of this work when ran manually.
I know you were also thinking about being able to use Certify the Web’s own credential vault and from the scripting side. Is this still something that could be on the cards?
Yes exposing credentials to scripts is still likely to be added but it needs to be very controlled, the problem I can see is that if any script could read any credential then they would all be easily stolen by a rogue script, so the compromise would be to select only a subset of credentials to pass to the script. Possibly we would also have to consider taking a hash of the script so that changes need to be re-validated by the certify user, so it’s potentially a little complicated.
No worries, and I get it. Trying to do what I’m tying to do at the moment is complicated (separate users, encrypted secrets vaults setup within those user profiles, and even encrypted vault passwords stored in a file bound to that user) but anything that inherently automates the retrieval of creds provides some kind of vector for abuse I guess 
.