Jump to content
trexman

Password reset on remote server

Recommended Posts

Hello,

 

We want to use Passwordstate to reset all administrator accounts of our customer servers once a year.

I played with the Password Reset and Password Validation Scripts to checkout the manual way but neither are working. I also read the "Password Reset Prerequisites" but I'm still stuck.

 

To my environment:

The Passwordstate "Server" is a Windows 10 PC in our company AD.

The Servers I want to reset the password are external customer pc and server which have a VPN connection to our Passwordstate Server.

None of the customer servers have a AD or are connected to our AD. So they are all standalone server.

 

I started with the Password Validation Scripts. Here I get this error:

 


Executing for Host '10.0.4.47' at 12.09.2016 18:33:30.

Failed to validate the local password for account 'administrator' on Host '10.0.4.47'. Error = 

Exception calling "ValidateCredentials" with "3" argument(s):  "The network path was not found."

 

If I use the Username ".\administrator" I get a different error message:

 


Executing for Host '10.0.4.47' at 12.09.2016 18:38:43.

Failed to validate the local password for account '.\administrator' on Host '10.0.4.47'. Error = 

Exception calling "ValidateCredentials" with "3" argument(s):  "Access Denied"

 

The username and password of the 10.0.4.47 is correct. What I'm doing wrong?

 

Thanks

 

Christian

Share this post


Link to post
Share on other sites

Hi Christian,

 

We'll try our best to help you with this scenario, but generally we only support environments which use Active Directory - as trying to configure resets using Local Admin accounts, instead of domain ones, may cause issues.

 

When you say you have a VPN connection to the Passwordstate server, can you explain a bit more what you mean here. Have you just opened some ports, or is it a true VPN with all ports open. PowerShell remoting does require ports 5985 and 5986 to be open.

 

When on your Passwordstate server, can you do a test PowerShell Remoting session to the PC/Server at the other end? Below is how you can test this.

 

Enter-PSSession -ComputerName <hostname>

 

Regards

Click Studios

Share this post


Link to post
Share on other sites

Hello Support,

thanks for your help.

 

I read this a few times in this forum that it is "necessary" for the password reset part, that you have everything in an AD. But I don't see the need for a password reset tool if I use AD...

In my case we have round about 30-40 standalone customer server where I want to reset the password by click :)

My explanation about the VPN was only to tell you, that the servers are "around the world" and we have full access to them on all ports.

 

I tried your test with a remote PS session. It didn't work at the beginning but with this How To it works now:

http://www.howtogeek.com/117192/how-to-run-powershell-commands-on-remote-computers/

 

 

Unfortunately is the result of the Password Validation Scripts still the same.

Do I have to use the Username "administrator" or ".\administrator" to use the account of the remote server?

(The password seams to be checked... if I use the wrong one I get a password incorrect error)

 

Christian

Share this post


Link to post
Share on other sites

Hi Christian,

 

The reason we say AD is required, is because you need to use an account which has sufficient privileges to perform PowerShell Remoting to the Host. When you configure Passwordstate to perform resets, you need to select a "Privileged Account" which you've added into the screen Administration -> Privileged Account Credentials. Using a Domain account here is a lot easier, as you can have just one Privileged Account per domain. If you don't have a domain, which we've never tested with, you would need to have the same Local Administrator account with the same UserName and Password on each server - otherwise you may need many privileged accounts, and it's going to get very messy.

 

With the HowToGeek article, did you run these commands on your Passwordstate web server? When using PowerShell remoting and IP Addresses, I believe this needs to be done on your web server.

 

The Username should be in the format of just 'administrator', not './administrator'. You can also test the validation scripts manually from the screen Resets -> Scripts - Password Validation.

 

Hopefully we can get some time soon, and we'll try and test this for you. But please be aware that this might not work, as it's not a supported configuration as we've mentioned.

 

Regards

Click Studios

Share this post


Link to post
Share on other sites

Hello Support,

 

Quote

otherwise you may need many privileged accounts, and it's going to get very messy.

 

Yes I know. Therefore we are looking for a password management tool :)

Hmm, I'm thinking more and more that we need another solution for our situation/environment.

 

Is it generally possible to reset the "local" administrator password of a standalone server if we use this administrator also as Privileged Account?

 

Yes I did the PS session test from the Passwordstate server where the IIS is running. So I think the connection is correct but either the IIS or the validation script has a problem with this.

And Yes I tested it with the "Test Script Manually" function.

 

I really appreciate your help even so Passwordstate was not designed for this.

It would be great it you can test or improve the password reset for standalone server (without AD). I believe that it would be helpful also for other Administrator´s.

 

 

Christian

Share this post


Link to post
Share on other sites

Hi Christian,

 

We've run some tests today to replicate this issue, and everything is working as per normal for us.  This is what we've done, and I've included some screenshots below:

 

  1. Set up a Windows 8 machine in a workgroup, on a different subnet to our production network.  This machine has two local accounts called administrator and tsand.  tsand is just a standard account
  2. Made the Administrator account the Privileged account used to reset account passwords on this Windows 8 machine
  3. Added the machine into my hosts screen as the IP address, which is 192.168.2.101 (please note our normal network is on the 10.*.*.* range, but we are able to ping and PS Remote into anything on the 192.* range)
  4. Set up 2 separate Password records enabled for resets - one for tsand and the other for administrator
  5. linked the privileged account for this back to the administrator record I set up for it in step 5

I then performed manual and scheduled resets on both records, and also performed manual and scheduled heartbeats on both records, and all were successful.

 

Quote

Is it generally possible to reset the "local" administrator password of a standalone server if we use this administrator also as Privileged Account?

 

Yep, this is possible and was part of my test.  If you can get the resets for the administrator account, you'll notice the password for it will be updated in the password record, and also it will automatically update it in the Privileged Account screen.

 

Quote

It would be great it you can test or improve the password reset for standalone server (without AD). I believe that it would be helpful also for other Administrator´s.

 

We are actually developing Passwordstate 8 as we speak, which is designed to work in remote sites with no VPN, and no direct link open back to your own network.  It will do this by installing an agent inside each of your customers' networks, so hopefully this will make these sorts of tasks easier for our customers:) 

 

 

 

Can you compare the below screenshots of my priv account and password records, and see if you have anything set up differently to what I have?  if you can PS Remote into your customers machines, we can't see why it wouldn't work, apart from obvious stuff like standard Windows permissions to perform the resets (not likely, you are using the administrator account) or incorrect passwords, or disabled admin accounts etc.

 

Standard Account called tsand on 192.168.2.101

 

2016-09-16_14-03-58.png

2016-09-16_14-04-07.png

2016-09-16_14-04-15.png

 

 

Administrator account on 192.168.2.101

 

2016-09-16_14-03-28.png

2016-09-16_14-03-38.png

2016-09-16_14-03-46.png

 

 

Privileged Account Linked to the Administrator Account on 192.168.2.101 - both passwords match and when resetting both are updated

 

2016-09-16_14-04-34.png

 

 

 

Auditing data showing password resets are working, along with manual and scheduled heartbeats

 

2016-09-16_14-07-15.png

 

Share this post


Link to post
Share on other sites

Hello,

 

thanks for the detailed description. I tried this your steps above on our system and started all over again.

My first problem is that I can't choose a Privileged account in the password dialog. The message is: Not Required

 

Here are my screens for this:

 

screen1.jpg

screen2.jpg

screen3.jpg

Share this post


Link to post
Share on other sites

Hi Trexman,

 

You first need to go to the screen Administration -> Privileged Account Credentials, and assign permissions to the credentials you have created here - you do this from the Actions dropdown menu for the record.

 

We require customers to assign permissions to these accounts for security reasons, as you would not want any user being able to have access to them.

 

Regards

Click Studios

Share this post


Link to post
Share on other sites

Hello Support,

 

It works... partially.

I can now reset a password of a normal user and also for the administrator user. The update of the Privileged Account also works as you described.

Thanks so much for this.

 

But the validation or heartbeats checks (manually or scheduled) failed with the message I mentioned at the beginning.

 

Quote

A manual Account Heartbeat check failed to validated the password for account administrator (\Kunden\WOAZ) of Account Type

'Windows' on Host 10.0.4.47. Error = Failed to validate the local password for account 'administrator' on Host '10.0.4.47'.

Error = Exception calling "ValidateCredentials" with "3" argument(s): "The network path was not found."

 

Do you have any idea what this means or how I can debug this?

Are the big "logical" differences between the validation and reset scripts?

 

 

Christian

Share this post


Link to post
Share on other sites

Hi trexman,


This working for us, so can you please let us know what build of Passwordstate you are using? We did modify this validation script a little while ago to overcome UAC issues, and possibly you are not using the latest script.

Regards

Click Studios

Share this post


Link to post
Share on other sites

Hi Christain,

 

After you have done this upgrade, can you also do the following before testing again:

  • Go to the screen Administration -> Password Resets
  • Click on the 'Scripts - Password Validation' button
  • And then for the script 'Validate Password for Windows Account', select 'Restore Default Script' from the Actions menu

Thanks
Click Studios

Share this post


Link to post
Share on other sites

Hello Support,

 

I had still the same problem, but.... I found it after a long powershell problem search.

It was the service RemoteRegistry which was not running on the remote server (192.168.2.101 in your example).

 

I found out, that this service is normally disabled or on manual startup at Windows 7, 8.1 and 10

 

The question is: Is this service needed for the validation script?

Is it not a security issue if you enable the RemoteRegistry service?

 

 

Best regards

Christian

Share this post


Link to post
Share on other sites

Hi Christian,

There is nothing specific in our script which uses the Registry. We do an open TCP port test to see if the Host is online, and then we use the System.DirectoryServices.AccountManagement assembly from .NET to perform the validation. This validation occurs from the Passwordstate Windows Server, and we do not use PowerShell Remoting here like for resets. So possibly this assembly requires this, but we didn't run into this issue with any of our testing.

Regards
Click Studios

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×