Jump to content

Search the Community

Showing results for tags 'windows'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Essentials
    • Announcements
  • Passwordstate 8.x
    • General Support
    • Feature Requests
    • Feature Requests - Completed
    • Known Issues
    • Installing Passwordstate
  • Knowledge Base
    • General FAQs
    • Password Resets
    • Remote Session Launcher
    • Mobile Client
    • Passwordstate API
    • Browser Extensions
    • Password Reset Portal
  • Passwordstate 7.x
    • General Support
    • Known Issues

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Google Plus Account


Location


Interests


Biography


Location


Interests


Occupation

Found 5 results

  1. This forum post will describe how to set up a Password Record to automatically reset a Local Windows Admin account on a remote server that is in a Workgroup, and not joined to your domain. Step 1: Ensure you have prerequisites set up for your web server and hosts, as per this forum post (Once off process) Step 2: Add new Password Record configured as follows Screen 1: Ensure you configure the below 5 options correctly and enter in the password for the account. If you configure an Expiry Date it will automatically change the password in Passwordstate and on the Host when that date is reached. Please note if you do not have functioning DNS to your Workgroup server, you may need to add it into the system as an IP Address instead. Please see this forum post on how to configure this: https://www.clickstudios.com.au/community/index.php?/topic/2127-adding-in-a-host-that-does-not-have-functioning-dns/ Screen 2: Ensure the "Reset Windows Password" script is selected under the Reset Options tab, and in this case you do not need to select a privileged Account. Instead when a password reset process is executed, it will connect to the machine using it's own credentials, and it will then perform the reset for itself. There are a couple of prerequisites to allow this to happen, which is mentioned at the bottom of this post: Screen 3: Ensure the "Validate Password for Windows Account" script is selected under the Heartbeat Options tab: Prerequisites for WorkGroup machines to allow for password resets and heartbeats: On your Passwordstate webserver, execute the following Powershell command to trust all hosts: Set-Item WSMAN:\localhost\Client\TrustedHosts -value * (It's possible to specify your workgroup server instead of the wildcard * if you prefer) Ensure you have enabled Powershell Remoting on the Workgroup machine. To do this open Powershell "As Administrator" and execute enable psremoting -force On the same Workgourp machine, you must enable remote connections to the server for your Administrator account. To do this, open Powershell "As Administrator" and execute the command below, which adds a registry key to your system. This is a Microsoft requirement and you can read more about it in this link: https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_remote_troubleshooting?view=powershell-5.1 New-ItemProperty -Name LocalAccountTokenFilterPolicy -Path `HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System` -PropertyType DWord -Value 1
  2. Hi again. As you have seen in today's other thread, I'm working on getting the password resetting for Windows to work without using local admin privileges. Whilst doing so, I've stumbled upon an error in the Windows local account password reset script "Set-WindowsPassword.ps1". I'm working with build 8180. After reducing the Powershell code to its bare essentials and running it on one of my test boxen, I've found that the relevant ScriptBlock contains a Write-Output that it really shouldn't, or that the test is written badly. Its current state leads to false positives. REPRODUCTION: Expire a local admin account's password on a Windows box. A few minutes later, the reset status lights up green as does the heartbeat. However, running another heartbeat attempt sets the HB status to red. Upon closer inspection I also find that the password has NOT been changed. No errors are reported by the reset script, which is recorded as successful in the audit log. DEBUGGING: I've reduced the relevant Powershell code to the bare minimum. I'm running it in Powershell ISE on the target host, with the privileged user account. Running things manually clearly shows an "access denied" message which is not getting caught by the test. EXAMPLE CODE: $HostName = "myhost" $TargetUser = "administrator" $NewPassword = "supersecrettotallynotit-1234" function ScriptBlock () { $account = [ADSI]"WinNT://$HostName/$TargetUser,user" $account.psbase.invoke("SetPassword", $NewPassword) $account.psbase.CommitChanges() Write-Output "Success" # THIS IS YOUR SMOKING GUN } $resultsarray = scriptblock 2>&1 if ($resultsarray -eq "Success") { Write-Output "Success" } else { Write-Output "Failboat" } PROOF: Run the code above ultimately leads to the output "Success", even if the psbase commands fail. In my case, I'm given an "access denied". Taking out the Write-Output from the function makes it exit with "Failboat". Now, if I swap the final IF-THEN-ELSE test with the actual code from the original PS1 (which includes the Switch statement for various error messages), then we see the same pattern. Making ScriptBlock output "Success" always leads to an exit of the script with "Success". Taking out that Write-Output line however, will correctly display the "access denied" error message. FIX: You'll need some error handling in your codeblock, to verify if there's any failures on the remote end and to indicate at which step. function ScriptBlock () { $account = [ADSI]"WinNT://$HostName/$TargetUser,user" $account.psbase.invoke("SetPassword", $NewPassword) if ($?) { $account.psbase.CommitChanges() if ($?) { Write-Output "Success" } else { Write-Output "Failure on commit"} } else { Write-Output "Failure on invoke" } }
  3. Hoya! Another day, another thread I'm in the process of setting up our privileged accounts for Windows and Linux management. Linux is easy in this case, as we'll limit the user through SUDO rules. Fine and dandy. It's Windows that's throwing me off (it's not really my field of expertise). I'm loathe of making a user account that's simply given access to the local "Administrators" group on each host. That feels damn dangerous to me. So I'm trying to hammer down things and make it work with the least possible privileges. Unfortunately I can't get it to work: I'm stuck at the last step. On the AD-level, the Windows privileged user was given delegated password management rights for AD users. That was also easy, so onwards to the local password management! The priv. user was added to AD-group "powershell-remote". I've set up a global policy that's enforced on the target Windows boxen, which adds the members of AD-group "powershell-remote" to these local groups: * Account Operators * Distributed COM Users * Remote Management Users * WinRMRemoteWMIUsers__ This ensures that the priv user can Invoke-Command and Enter-PSSession. But the remote hosts still balk at letting the user interact with things like win32_group through WMI or Get-CIM*. There's also the local WMI Control tool, which can be used to provide access to WMI components to specific users (see here). That's a bummer though, because that would require local changes on all boxen. Apparently you cannot set these permissions through a global policy, so you will need to resort to manual changes, or a script (see the EDIT below). Opening up the ROOT namespace for the privileged account appears to be sufficient for discovery. Will let you know about password changes Suggestions would be more than welcome! EDIT: At least there are scripts available that will help you set the WMI namespace access permissions through Powershell. See here. That's still not ideal though, but that's down to Windows' design. EDIT 2: One workaround that could be very useful, would be if PasswordState would support JEA: Just Enough Admin, a rather new extension for Powershell which allows you to delegate certain (local) tasks to another non-admin user. That would however require an adjusted set of scripts for discovery / validations / resetting. Thanks to my brother-in-law for suggesting JEA.
  4. We are just in the early trial phase of PasswordState and I'm beginning to look into the reset functionality. One of our use cases is that we use AD Accounts for application services (not the new AD Service accounts yet, just standard user accounts). If I set up an automated password reset for that service account, is there a way to automatically update, or at least link it, to the service account as well? If I select 'Active Directory Account' then I can only enter a Domain, not a list of hosts or anything. Am I getting far afield here or am I missing something obvious?
  5. Step 1: Ensure you have prerequisites set up for your web server and hosts, as per this forum post (Once off process) Step 2: Add new Password Record configured as follows: Screen 1: Ensure you configure the below 5 options correctly and enter in the password for the account. If you configure an Expiry Date it will automatically change the password in Passwordstate and on the Host when that date is reached. Screen 2: Ensure you select the appropriate Privileged Account and the Reset Windows Password reset script. Also confirm the Password Reset Schedule is enabled if you want the password to automatically change when the Expiry Date occurs Screen 3: Confirm the Validate Password for Windows Account validation script is selected
×