Jump to content

Backup permissions after v9


Ian A
 Share

Recommended Posts

I've been through the instructions (https://www.clickstudios.com.au/downloads/version9/Passwordstate_Automatic_Backups.pdf) a few times but still not having any luck with backup on build 9100.

 

I'm getting error:

Quote

 

- Testing stopping and starting of Windows Services.....
- Testing writing files to the Passwordstate Folder.....

Authentication Failed = Please check if the UserName and Password you have specified for Backups and Upgrades is correct, and the account has access to write files into the Passwordstate folder.

Please refer to the Instructions tab for full documentation and troubleshooting steps.

 

 

I have a single domain controller which is also running IIS and SQL.  I acknowledge this is unusual / not recommended but this is a home lab.  The relevant settings are:

  • PasswordState folder: C:\inetpub\passwordstate.
  • SQL Server: Local on DC, running as account DOMAIN\SQLService.
  • Backup account: DOMAIN\PwdStateBackup, correctly placed in a password list and found and accepted by the settings screen.
  • Backup destination share: \\DCNETBIOSNAME\Backup\PasswordState (note I have tested this and PasswordState is happy with the destination being a subfolder of the share.

 

I have:

  • NOT made PwdStateBackup a Domain Admin, however if I do then the "Test Permissions" works fine.
  • Granted PwdStateBackup control over the service using SUBINACL (p18).  This seems to get overwritten and needs to be reset but that's not the major issue.
  • Granted Modify rights to PwdStateBackup for the file folder C:\inetpub\passwordstate and \\DCNETBIOSNAME\Backup\PasswordState.
  • Granted EVERYONE Change rights over the share \\DCNETBIOSNAME\Backup - slight deviation from the instructions here, however we don't appear to have got to this stage yet and I don't see why this wouldn't work.
  • Granted PwdStateBackup the "Logon as a batch job" permission via Domain Controllers group policy (Local Policy not an option on a DC) and checked it is not in the "Deny Logon as a batch job" definition.
  • Added the PwdStateBackup account to SQL Server and granted db_backupoperator on the PasswordState database.
  • Added PwdStateBackup to the Remote Management Users group (don't think this is necessary, we aren't accessing it remotely).
  • Enabled PS remoting (don't think this is necessary, we aren't accessing it remotely).
  • Set the PowerShell TLS settings and added the sqlserver module.

 

I've even used ProcessMonitor to see if I can see what it is trying to do.  Setting a Deny on the C:\inetpub\PasswordState folder for PwdStateBackup and then trying the account in and out of the Domain Admins indicates that there is something it does BETWEEN printing "Testing writing files to the Passwordstate Folder" and actually attempting to write the dummy file.  Possibly impersonating the backup user.  This is the bit that I think is failing.

 

Any suggestions?

Link to comment
Share on other sites

Hi Ian,

 

In the next build, due in a few days, we've added an additional setting we can change in the database to see if we can fix this Backup Account Impersonation issue - we've had a couple of customers report it.

 

Once we're able to test this, hopefully it fixes it for you. If it does not, we might need to ask to move Passwordstate off of a domain controller, if possible.

 

We'll post back here as soon as the new build is available.

Regards

Click Studios

Link to comment
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
 Share

×
×
  • Create New...