Jump to content

Recommended Posts

Posted

Hi, I am attempting to test if this will work in our environment, which is a single standalone system, not domain-connected at all. It is a single system, technically in a workgroup, but doesn't connect to any other systems. Passwordstate will be installed on this one system, and it will be the only one managed by it.

So far I have gotten it to work to create a privileged account for resets, but I have had to configure it as so:

image.png.870aa7a3d76bd83ed94436bcde0cee04.png

 

I have had to put the username as '.\svc_pstate' instead of simply 'svc_pstate' to get it to work. This would not be a problem, except I want it to be linked to a record for password resets, so this would be updated when the password expires automatically. Unfortunately, the password record for it in the list does not allow me to link it to the privileged account so that it will update. 
 

image.png.471118c5b23bbcb236a923ca750086a3.png

 

Is there any way to get this to work? Should I have to put the privileged account as '.\svc_pstate' to get it to work in the first place on a local non-domain system? It will not work if I just use 'svc_pstate'. I want to be able to schedule resets, including the privileged account... but as it is configured right now, I would have to manually update the svc_pstate privileged credentials when it would change.

 

Thanks.

Posted

Hi Damcoole,

 

I've had a look at this today, and I've set up the same sort of environment you have but was able to get it working ok with the need to prepend the .\ to the username on the Privileged Accounts screen.  I was able to link the privileged account to its own password record as well, and I even used that account to reset not only itself, but also another user on the same machine several times.

 

Could you possibly let me know what the error is in the recent activity, when your Password Reset fails?

 

I wonder if you could also change the Host name of win10vm in passwordstate to a IP Address instead?  You shouldn't need to do this but I'm wondering if Passwordstate is having an issue resolving the win10vm host name for any reason?

 

Regards,

Support

Posted
8 hours ago, support said:

Hi Damcoole,

 

I've had a look at this today, and I've set up the same sort of environment you have but was able to get it working ok with the need to prepend the .\ to the username on the Privileged Accounts screen.  I was able to link the privileged account to its own password record as well, and I even used that account to reset not only itself, but also another user on the same machine several times.

 

Could you possibly let me know what the error is in the recent activity, when your Password Reset fails?

 

I wonder if you could also change the Host name of win10vm in passwordstate to a IP Address instead?  You shouldn't need to do this but I'm wondering if Passwordstate is having an issue resolving the win10vm host name for any reason?

 

Regards,

Support

In your above sentence, did you mean 'without the need to prepend the .\'?

 

If so, when I changed it back to without the .\, I can choose the link in the privileged account screen, but it doesn't work. I get the following error on password reset:

The Passwordstate Windows Service failed to process the Password Reset Script 'Reset Windows Password' against Host 'win10vm' for the account 'svc_pstate' (\Service Accounts). As a result, no changes have been made to this record in Passwordstate. Error = Failed to reset the local password for account 'svc_pstate' on Host 'win10vm'.Error = [win10vm] Connecting to remote server win10vm failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x8009030d occurred while using Negotiate authentication: A specified logon session does not exist. It may already have been terminated. Possible causes are: -The user name or password specified are invalid. -Kerberos is used when no authentication method and no user name are specified. -Kerberos accepts domain user names, but not local user names. -The Service Principal Name (SPN) for the remote computer name and port does not exist. -The client and remote computers are in different domai

I also tried changing to the IP address, then I get this error when trying a reset:

The Passwordstate Windows Service failed to process the Password Reset Script 'Reset Windows Password' against Host '192.168.6.128' for the account 'svc_pstate' (\Service Accounts). As a result, no changes have been made to this record in Passwordstate. Error = Failed to reset the local password for account 'svc_pstate' on Host '192.168.6.128'.Error = [192.168.6.128] Connecting to remote server 192.168.6.128 failed with the following error message : The WinRM client cannot process the request. If the authentication scheme is different from Kerberos, or if the client computer is not joined to a domain, then HTTPS transport must be used or the destination machine must be added to the TrustedHosts configuration setting. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. You can get more information about that by running the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help to 

And lastly, if I use the .\ in the privileged account, it resets the password perfectly, but I can't link to the password list in the privileged accounts screen.

Posted

Well, I have found a workaround for the time being that seems to work for this environment:

I made a very minor modification to the 'Reset Windows Password' script... and I mean very minor. I added a .\ to the last line of the script before [PrivilegedAccountUserName]:
 

Set-WindowsPassword -HostName '[HostName]' -UserName '[UserName]' -OldPassword '[OldPassword]' -NewPassword '[NewPassword]' -PrivilegedAccountUserName '.\[PrivilegedAccountUserName]' -PrivilegedAccountPassword '[PrivilegedAccountPassword]'

I left the .\ off of the actual Privileged Account name so I could link to the password in the list. I did a reset, and everything updated correctly.


For now, this should work for my setup I think. It would be nice if this wasn't required or was built-in functionality at some point though.

Thanks for the help, if you have any other ideas that I might be overlooking that don't require script modification, please let me know.

Posted

Hello damcole,

 

This should not be required, as I did not need to do this in our environment. If we ever update this script, it will overwrite the change you made, so can you please answer the following questions to see if we can figure this out:

  • What Build Number of Passwordstate are you using?
  • Could you possibly let me know what the error is in the recent activity, when your Password Reset fails?
  • I wonder if you could also change the Host name of win10vm in passwordstate to a IP Address instead ?

Regards

Click Studios

Posted

To answer your questions:

1. Build 8884

2. The error message is as follows: 

<110>2020-03-10 07:13:17 192.168.6.128   Passwordstate: The Passwordstate Windows Service failed to process the Password Reset Script 'Reset Windows Password' against Host 'win10vm' for the account 'svc_pstate' (\Service Accounts). As a result, no changes have been made to this record in Passwordstate. Error = Failed to reset the local password for account 'svc_pstate' on Host 'win10vm'.Error = [win10vm] Connecting to remote server win10vm failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x8009030d occurred while using Negotiate authentication: A specified logon session does not exist. It may already have been terminated.   Possible causes are:  -The user name or password specified are invalid.  -Kerberos is used when no authentication method and no user name are specified.  -Kerberos accepts domain user names, but not local user names.  -The Service Principal Name (SPN) for the remote computer name and port does not exist.  -The client and remote computers are in different domai Client IP Address = 192.168.6.128. PasswordListID = 2, PasswordID = 1

3. I tried changing to the IP, and get the same error.

 

As for the script, I actually made a separate copy of the script, I didn't overwrite the inbuilt one - so I should be safe there even after updates, right?


To clarify my environment, it is set up as just one system - Win10vm. There are no other systems that it is connected to, and it also does not have internet access, it is 100% standalone. Passwordstate is installed on Win10vm so it is both the host and the client.

Posted

Hi damcoole,

 

Yes, if you have cloned our script, then you will be fine for furture upgrades

Since this appears to be a workgroup computer, can you have a look at section '12 Account Discovery and Password Resets between Non-Trusted Active Directory Domains, or against Workgroup Computers'  - in the following document - https://www.clickstudios.com.au/downloads/version9/Password_Discovery_Reset_and_Validation_Requirements.pdf

We would recommend rebooting after making this change.

Regards

Click Studios

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
×
×
  • Create New...