My dashboard has authentication enabled and prompts the user for their credentials as soon as they hit the dashboard URL (the web browser presents them with the UAC input box). Where can I pull their credentials from? I’m trying to use $Credential.Username and $Credential.Password in the authentication.ps1 file but those are both null.
The goal would be to export the username/password (encrypted) into a CSV file, then import them into a variable that can be used to run a script with those credentials.
Alternatively, I have not be able to export them to Windows Credential Manager and import them into a secret variable. The missing link being not knowing what variable actually stores their username and password once they input it.
Did you ever find an answer to this? I’m just getting started here and using the active directory module as a starting place, I’m curious if I should be utilizing a service account to query AD or somehow pull the active user’s credentials to run the script.
I’m guessing for the sake of security, the user’s credential’s wouldn’t persist past login, and I don’t know whether it would be bad practice or not to store that for later use.
Hi @jgeron-suhsd, here are a few things (and links to the documentation) that helped me get up and running in my dashboard configuration. I’m currently running version 2.5.4.
Running PowerShell Universal as a service with a service account (after the install, I manually changed the “Log On As” account from local system to my service account).
I am using forms authentication to handling the users logging into the dashboard. That takes care of the log in process when users hit the login page prior to getting access to the dashboard and enter their domain credentials. Within the authentication.ps1 file, I validate that the user exists in Active Directory and then use the Microsoft.PowerShell.SecretManagement module to securely store their credentials. Through this process, You’ll then see the users’ credentials get added in the PowerShell Universal Variables list. From their, your dashboard can pull in their credentials.
Lastly, the user (or the group that the user is a part of) that is going to be running the scripts need to be a member in the following local security policies (local as in on the server that is running PowerShell Universal):
Log on as a service
Adjust memory quotas for a process
Replace a process level token
I’m still working out a few issues with this last piece. Hope that all that info helps!
@adam , any specifics to look for as to why everyone can run scripts as PSU jobs when they are added to the local administrator’s group (on the server running PSU), but jobs fail if they are removed from the local administrators group even though they are members of the three local security policies: “Log on as a service”, “Adjust memory quotas for a process”, and “Replace a process level token”
Hmmm. I’m not sure of other privileges that you may need. From my understanding, you have the correct ones configured. One thing you may be able to do is capture a procmon trace of this process. It should include the attempt to start the process and provide some more information on what may be happening when it fails.
You can save that trace and then send it my way and I can review to see if there is anything I notice.
@mtndrew11 Thanks! I made some progress on my own yesterday, but you definitely have some helpful bits in there that I will be looking into. I’m excited to dig into all of this some more today.
@adam unfortunately, I’m in an environment where I cannot easily obtain and pass over log files. I have the procmon file and it should have captured a couple failed attempts. Is there a specific process or operation I should be looking for?
To note, the Error in the PSU jobs status column is “failed: Error executing job: Did not receive port from client process”
Interesting. It actually sounds like it’s starting the process but the process isn’t communicating back. This typically isn’t what I see when the process fails to start due to permissions.
Let’s hold off digging through the procmon trace and switch on JobDebugging. It’s available in appsettings.json and will produce psu.(port).txt files in the temp directory. These will contain additional information about what’s going on in the job process.
It kind of sounds like the process is actually starting but failing to connect back to the PSU server.
We use [IO.Path]::GetTempPath() to locate the temp directory. It’s likely in the elevated account’s app data directory. Mine expands to: C:\Users\adamr\AppData\Local\Temp
Got it. It was under the service account’s profile similar to the path you provided.
I see the txt files getting created, but a couple things to note…
When I make this attempt with my domain credentials, the psu.(port).txt file is created but is empty (my account is part of the local administrator’s group so it’s not a similar test to my other users using the dashboard).
When another user (not part of the local administrators group but is part of the three local security policies) runs a job, no psu.(port).txt is generated.