Today we have released build 9823 of Passwordstate which should fix this issue. Can you please upgrade and test and if there are any issues with this let us know?
It would be nice to have the "title" included (in front) of the tab name when connecting to a remote host through the webbrowser.
Right now, when we connect to a single customer/IP with 3 servers, they all show the same tab name with the "Host Name" in the browser tab. This makes it very hard to distinguish the tabs when connecting to multiple hosts.
We Use AADJ Devices and our internal servics use public signed certs - not much in the way of traditional internal CA infrastructure nor the desire to set it up.
We have WIN-ACME requesting publicly signed certs using the DNS-01 challenge and have configured the certificates to be exportable and to auto update in the site bindings for IIS. Cookie cutter cert management, works well for the base site, no problems there.
The problem is that as far as I can tell this can't/wont update the cert for the remote session gateway.
In Section 9 of the remote session launcher guide there are a few lines of Powershell to update the gateway cert *after* a cert has been exported with a password, however there isn't anyhting 'clean and easy' like the gateway install script that exports it and sets up the gateway in the first place.
Has anyone run into this before and/or made a script to auto export and update the gateway cert?
Alternatively, as a brute force approach, is there any problems that would occur from simply re-triggering the install-gateway-internal.ps1 script after the cert is renewed?
I could probably easily cut out sections like redownloading OPENJDK, but im not sure how 'healthy' re-running the install.bat file would be to a production instance and I'm not familiar enough with powershell to reverse engineer the cert export from IIS and update in the gateway service myself.
Hoping someone else has already run into this one.
I was recently tasked in finding a solution for resetting root passwords for 800+ VMWare ESXi hosts and if Passwordstate would be able to facilitate this.
I initially started looking at the built-in Linux scripts which utilises SSH connections, something we have disabled for our ESXi hosts for security.
Searching through these forums I found a post where someone used PowerCLI to do the heavy lifting, but I found the post didnt quite give me everything I needed to complete the project.
Here is my attempt at demonstrating my solution, in hopes it will help someone out in the future.
Password reset and password validation scripts:
We need to talk about these custom scripts first, as we need the IDs of the script to fill in the JSON data for scripted host ingest
Password reset script:
1. Function Set-ESXiPassword
2. {
3. [CmdletBinding()]
4. param (
5. [String]$HostName,
6. [String]$UserName,
7. [String]$OldPassword,
8. [String]$NewPassword
9. )
10. try {
11. $Connection=Connect-VIServer $HostName -User $UserName -Password $OldPassword
12. }
13. catch {
14. switch -wildcard ($error[0].Exception.ToString().ToLower())
15. {
16. "*incorrect user*" { Write-Output "Incorrect username or password on host '$HostName'"; break}
17. "*" {write-output $error[0].Exception.ToString().ToLower();break}
18. }
19. }
20. try {
21. $change=Set-VMHostAccount -UserAccount $UserName -Password $NewPassword | out-string
22. if ($change -like '*root*'){
23. Write-Output "Success" }
24. else {
25. Write-Output "Failed" }
26. Disconnect-Viserver * -confirm:$false
27. }
28. catch {
29. switch -wildcard ($error[0].Exception.ToString().ToLower())
30. {
31. "*not currently connected*" {Write-Output "It wasn't possible to connect to '$HostName'";break}
32. "*weak password*" { Write-Output "Failed to execute script correctly against Host '$HostName' for the account '$UserName'. It appears the new password did not meet the password complexity requirements on the host."; break }
33. "*" {write-output $error[0].Exception.ToString().ToLower();break}
34. #Add other wildcard matches here as required
35. default { Write-Output "Got here" }
36. }
37. }
38. }
39.
40. Set-ESXiPassword -HostName '[HostName]' -UserName '[UserName]' -OldPassword '[OldPassword]' -NewPassword '[NewPassword]'
This utilises Set-VMHostAccount Powercli command which is baked into an ESXi host and only requires powershell to be open from the Passwordstate webserver to the host (port 443).
The success criteria simply looks for the word root in the output, this may be foolish of me, but there isn't much of a result from the command to parse for a successful result
If the command fails it should be captured by my catch commands
Simple script with attempts to connect to a host via powercli, if there is a connection then output success.
Host/Password Entry:
All of our hosts are domain joined so host discovery was rather straightforward enough by using the built in utility in Passwordstate. Unfortunately there was no easy way to automatically discover host accounts, but since we are only dealing with Root here we can script adding of password entries. You'll need to get your custom script IDs from the ones you created above. This is a one off script and took around one minute to add 800 hosts
Here is the script I used to add password entries:
It would be good to show when a host connection is in use and by who. This would prevent our current situation with someone else on our support team logging into a server and stealing the current support persons session.
Same logic as checking out a password, you connect to a host, the host icon goes to a "checked out" state and is marked as in use by "Bob Smith" until Bob logs out, or checks the host back in.
This would then also allow an additional report for each user to allow them to report on what servers they logged into and for how long that day\week\month, for those that must keep accurate time records and change history logs.
We've had a request for the following for the Self Destruct Message web site:
Add auditing for failed PassPhrase login attempts
Track failed Passphrase login attempts by IP, and lock the user out when they reach the Brute Force login threshhold. The Admin would then need to unblock this IP Address, just like in the main UI.
These changes would provide an additional layer of security, on top of:
Brute Force Lockouts via Session tracking
Guessing the URL of the Self Destruct Message web site
Guessing the randomly generated 32 character Self Destruct ID, needed to view the message
Regards
Click Studios
It would be great if the RDP Linked Credentials would show not only your remote session credentials (if created and linked via hostname match) but also the passwords associated with the host in the dropdown. We have multiple local accounts on our servers and additional domain accounts. Unfortunately, you can only choose either the local accounts or the domain accounts (Via Remote Session Credentials). The colleagues can take the detour via the function on the passwords, but this is quite inconvenient for most.
