support

Hello,
 
We can confirm that turning off the 'Disable Inherittance' setting on a Password List, does not change permissions on the Password List at all. You then need to modify permissions on upper-level folders, if you want to modify permissions on the Lists nested beneath it.

We hope this claeifies.

Regards
Click Studios

All done

Hello Flash,
 
Unfortunately there is no option for the later anymore. We had many requests to open the session in a new tab.

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.
 
 

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.
 
 

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.
 
 

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.
 
 

Hi all,
 
I got this to work in our lab environment and thought I'd share some of that setup.
We have not setup the app service yet, so I can't comment on that.
This isn't a full guide on how to configure Azure AD, Enterprise Applications, the Azure App Proxy Connector or anything like that. It's just the settings that worked for us to make the Passwordstate web interface accessible to external users via the Azure Application Proxy with SAML SSO and Conditional Access policies.
 
As "<BaseURL>" we'll be using "https://passwordstate-<account>.msappproxy.net" where <account> is whatever Microsoft is using for your account there. Obviously you can change 'passwordstate' to something else as well.
 
Azure - Application Proxy configuration
We configured the Azure Application Proxy with identical domain names for internal and external users to ensure links sent our by Passwordstate will just work:
Internal Passwordstate URL: <BaseURL>
External Passwordstate URL: <BaseURL>
 
Pre Authentication is set to Azure Active Directory. We want SAML SSO, after all.
We enabled HTTP-Only, Secure and Persistent Cookies in our lab environment. However, when it comes to Persistent Cookies, you may want to change that to No for a production environment.
 
As we're using the same URLs for internal and external there's no need for URL translation, so we disabled it for Header and Application Body.
 
Azure - Single sign-on configuration
Basic SAML Configuration
Identifier (Entity ID): <BaseURL>
Reply URL (Assertion Consumer Service URL):
<BaseURL> Tick the Default checkbox on this one <BaseURL>/logins/saml/default.aspx Sign on URL: <BaseURL>
Relay State: <BaseURL>/logins/saml/default.aspx
Logout URL: <BaseURL>/?appproxy=logout
 
Attributes & Claims
Unique User Identifier: user.userprincipalname
We didn't change any of the other ones.
Note that you can use user.mail, as per Clickstudio's own Blog. We switched to userprincipalname as we are testing with accounts without email addresses, so this made more sense for us.
Using userprincipalname also requires you to reconfigure Passwordstate and under System Settings -> Authentication Options check the UserPrincipalName option under "Select which field in Passwordstate you want to compare against the SAML Response's Name Identifier - NameID".
 
For the remainder of the Azure (and Passwordstate SAML) configuration, just follow Clickstudio's guide: https://blog.clickstudios.com.au/saml-authentication-with-azure-ad/
Ensure to reconfigure your Base URL in Passwordstate under System Settings -> Miscellaneous to match your <BaseURL>.
 
Certificates
We created a certificate for our internal server using our existing, internal CA.
Doesn't cost anything and we have more control over certificate lifetime and auto-renewal.
 
If you go with a 'proper' custom domain setup (e.g. using https://passwordstate.<domain> for internal and external URL) for the App Proxy, you'll need a public CA certificate to be imported into the App Proxy.
 
Internal DNS
We created a DNS Zone on our internal DNS server to ensure internal systems resolve passwordstate-<account>.msappproxy.net to the internal IP of the Passwordstate server. You can probably force internal users through the Azure App Proxy as well, but at the very least the Azure App Proxy (and the internal Passwordstate server itself) needs to be able to resolve the name to the internal IP of the server or it won't be able to connect.
 
IIS
Ensure to configure your IIS Bindings to use the passwordstate-<account>.msappproxy.net FQDN and assign the correct certificate.
We also disabled Windows Authentication for the passwordstate site as it's not required.
 
 
That's it, SAML SSO should work and you can configure your Conditional Access policies as required.
As mentioned, this isn't a full guide. You need to have your Azure Application Proxy Connector setup and operational, it needs to be able to access the Passwordstate server, the relevant outbound ports/IPs/FQDNs need to be allowed on the firewall, etc.
 
I hope this helps someone else to get their setup working.

Hello Daniel,
 
As of version 9 this is required, as we've made the Password Resets and Account Heartbeats consistent with all other types of accounts, where we now use PowerShell scripts for this purpose.

Regards
Click Studios

Hello Daniel,
 
This PowerShell module is required to be installed on your Passwordstate web server, so we can only presume someone has now uninstalled it. Below are the instructions for this, and please restart the Passwordstate Windows Service after making this change.

Open PowerShell as Admin, and run the command:
 
Add-WindowsFeature RSAT-AD-PowerShell

Regards
Click Studios

Hi tburke,
 
Looking at your forum post again, we think we know what the issue is now. The old In-Place Upgrade method is no longer available, and as of build 9300 our upgrade feature has changed to streamline the process and improve security.  Please follow this new set of instructions to help you get upgraded to the latest build available: https://www.clickstudios.com.au/downloads/version9/Upgrade_Instructions.pdf
 
Before attempting the new upgrade process. Can you please delete the c:\inetpub\passwordstate\upgrades\upgradelog.txt if it exists?
 
The manual uprade method you tried is also no longer supported, because of the way we "can" make changes to the web.config file during the upgrade process. In your web.config file, can you look for the reference to the CodePages above, and change it to the values below:
 
<dependentAssembly>
        <assemblyIdentity name="System.Text.Encoding.CodePages" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-5.0.0.0" newVersion="5.0.0.0" />
      </dependentAssembly>

Regards
Click Studios

Hi tburke,
 
Yes, as of build 9300, there is no option in the UI to do In-Place Upgrades. You need to use the Windows Installer for this.
 
And that's correct, we no longer provide an unattended install option for our software, as we need to use the Windows Installer now - we no longre provide zip files with all the files, for security reasons.

Regards
Click Studios

Hello Mikael,
 
Could you do the following for us:
With SQL Server Management Studio, execute the commands below:           USE Passwordstate
          UPDATE DiscoveryJobs SET InProgress = 0
Now restart your Passwordstate Windows Service to pick up this change also When you next run a job, can you see if our Windows Service is logging any exceptions in the Windows Application Event Log? Thanks
Click Studios

Hello,
 
We do plan on adding support for listing/searching documents, and we'll post back here once the feature is available.

Regards
Click Studios

The cause was found with the help of the support:
The backup user was a member of an AD group that was via GPO assigned the local policy "deny log on locally". After I removed the user, the backup works.

Hello Emad,
 
You can download from the following page without registering to download - https://www.clickstudios.com.au/passwordstate-checksums.aspx

Regards
Click Studios

Hello Jimmy,
 
Google recently made a change in Chrome which broke this functionality, but we have a fix coming in the next release, due in about 3 weeks time.

Regards
Click Studios

Hi Tony,
 
Thanks for the information, and we'll use your screenshots to and do some testing to see if we can reproduce this. In theory, if you do not have a Password List selected for copying settings in the User Account Policy, then we should ignore that System Settings for linking the Password List to the Template.
 
It does sound like a bug, and we'll need to work on a fix for the next release.

Thanks again.

Regards
Click Studios

Hello jtstuedle,
 
The only feature we have for automatically creating User Accounts in Passwordstate is when you synchronize Active Directory Security Groups - for On Premise AD.

If you need some sort of feature for this, then we can move this post into the Feature Requests area of the forums?

Regards
Click Studios

Hey Everyone,
 
Just a quick message to say we are very close to releasing a beta of our new Chrome extension.  Possibly in the next couple of weeks, and this feature is in the new version:)
 
We'll be announcing the beta release on Social Media soon, and we'll report back here to, and you are all welcome to test it out.
 
Thanks again,
Support.

Hey Everyone,
 
Just a quick message to say we are very close to releasing a beta of our new Chrome extension.  Possibly in the next couple of weeks, and this feature is in the new version:)
 
We'll be announcing the beta release on Social Media soon, and we'll report back here to, and you are all welcome to test it out.
 
Thanks again,
Support.

To help us troubleshoot your issue, it is very handy for us to know certain information about your Passwordstate website, database, and the infrastructure that is is running on.  To help speed up our support response times, we've developed a Powershell script that will collect some information about your environment. 
 
To run this script:
Please download the "Passwordstate Support Information Script" script from our Checksums page here https://www.clickstudios.com.au/passwordstate-checksums.aspx.  Extract the zip file and save the ServerInfo.ps1 file on your Passwordstate web server Open Powershell ISE "As Administrator" and open your ServerInfo.ps1 file Run the script When the script has finished it will create a ServerInfo.zip file in the same folder where you have run the script from.  Please email that back to support@clickstudios.com.au for analysis.  
Below is full disclosure of what the script is doing:
This script will not make any changes to your server, or Passwordstate environment Information it collects from your web server is as follows: Current Passwordstate version All Installed Programs on your server Name of your web server Last time your web server was rebooted Free disk space and free memory on your web server A check to see if your web server is a part of a domain, or a workgroup What language the web server is in, plus OS version and .NET version Information about your Passwordstate App Pools in IIS - Names, Path and Identity Type Installation path of your Passwordstate website Passwordstate web bindings in IIS and Authentication options NSLookups and tracerts of each URL for the Passwordstate website only List of certificates names on the web server, expiry date and who they are issued by Powershell version IP address of webserver Information about Passwordstate services - If they are running and who is the logon identity and when they were stopped, and started Local Administrator Accounts if there are any Passwordstate installation folder permissions Event Log errors from the Application Event logs Information from the web.config file - database server name, SQL instance, database name, setup stage and passivenode values.  We also query the username and password out of the connection string, but do not store this anywhere.  We only use this information temporarily to connect to your database and gather the information in the section below The remaining non sensitive part of the web.config file is also collected.  You'll find your web.config file inside the zip file, but you'll see all sensitive info in the ConnectionString and AppSettings Section is redacted. .NET Framework versioning Local Intranet Zone URLs Information in Hosts file Upgrade Log File data  
Information it collects from your database is as follows: How many password lists and passwords Information about Active Directory Domains Count of Password Lists and tree path Count of auditing records Count of total users in the system Count of total Security Groups Passwordstate Licensing information Database Build Number, Base URL and Fips Mode, Ignored URLs and Backup Settings Detailed table sizes in database Email Notification information including Security Groups names and Usernames User Account Policy information including Security Groups names and Usernames  
**NOTE** if your web.config file connections string and AppSettings section is encrypted, we make a temporary copy of this web.config file, and decrypt it to get the connection information out of it, and then we delete this file from the file system.  We do not store any of this data anywhere on the system, nor do we provide secret keys of connections information in the output file you supply back to click studios.
 
**NOTE** If you are not comfortable in sending some or all of this information, we will still do our best to help you resolve your issue.  We may just have to ask a series of questions to get to the bottom of the problem.
 
Regards,
Click Studios

Hello,

Thanks for your request. As a work around, you could run the SQL Query below. Any Password Lists with a TotalPermissions of 0, means there is no Admin on the list.
 
USE Passwordstate
SELECT PasswordLists.PasswordListID, PasswordLists.PasswordList, PasswordLists.Description, PasswordLists.TreePath, (SELECT COUNT(PasswordListID) FROM [PasswordListsACL] PSSWD WHERE (PSSWD.PasswordListID = PasswordLists.PasswordListID) AND (PSSWD.Permissions = 'A')) As TotalPermissions
FROM [PasswordLists] 
WHERE (PasswordLists.PrivatePasswordList = 0) AND (PasswordLists.Folder <> 1) 
GROUP BY PasswordLists.PasswordListID, PasswordLists.PasswordList, PasswordLists.Description, PasswordLists.TreePath
ORDER BY PasswordLists.PasswordList

Regards
Click Studios

If using the High Availability module in Passwordstate, this will mean you have two webservers hosting two Passwordstate websites, and most likely you'll have two SQL databases replicating data in real time.  You will find the names and roles of your servers under Administration -> Authorized Web Servers, as per below screenshot:
 

 
If the Polling Health is a visual reference that both servers are in sync, so if it is red in colour this could mean there is an issue you need to address.  The mechanics of how the polling process works depend on if you have yoru HA web server set to run in Passive mode (server is in Read Only mode), or Active (Server is in Read/Write mode).
 
Please note, you should always have one server on this page that has the Primary Server role assigned. This is very important as it will ensure the Passwordstate Windows Service is fully functional and processes a number of different tasks in the background.
 
To troubleshoot why the polling health icons are red, please check the following:
 
Passive Mode:
If your HA server is set to Passive, the the Passwordstate service on the secondary server will make a call on a regular schedule to the primary site API.  If it can contact it, it will show a successful green icon.
 
Things to check:
When logged into to your Primary Passwordstate site, check the URL under Administration -> System Settings -> Miscellaneous is correct. Ensure the Passwordstate Service on the secondary web server is running From your Secondary server, perform a Powershell open port test back to your primary website to ensure no firewalls are blocking access.  Example is test-netconnection passwordstate.com.au -port 443 From your secondary server, try browsing to the poll test URL by appending /api/highavailability/primarypoll/polltest to your normal Passwordstate URL.  If this works, you will see a Success:True message in the body of the website.  If you do not see this, please investigate if you have load balancers or proxy servers that are blocking this API call, and possibly bypass these devices as a quick test to rule them out. Look in the Application Event logs for any errors, and if you find any, but can't work out what they are, submit them to Click Studios support for review (support@clickstudios.com.au)  
Active Mode:
If running your HA server in Active mode, instead of making a call to the API it will insert the date, time and build number directly to the secondary database, and then when replication occurs back to the primary database this will be displayed as a healthy green polling status in the both of your Passwordstate websites.
 
Things to check:
Passwordstate service on the secondary web server is running Database replication is working (try adding a test password record into the system and then log into the second website to see if that password record is visible there - this should be almost instant if SQL replication is working) Look in the Application Event logs for any errors, and if you find any, but can't work out what they are, submit them to Click Studios support for review (support@clickstudios.com.au)  
**TIP**
Another quick way to check replication is working correctly is to do a count of auditing events against both databases.  This SQL query below should be run against both database servers, and they will and they will be exactly the same if replication is working correctly.
 
Use Passwordstate
Select count(*) from auditing
 
 
Regards,
Support:)
 

Hi Habskilla,
 
Sorry, the WinAPI (Windows API) can only be called from Windows Machines using PowerShell. With the use of PowerShell, you can execute the script under the identity of an Active Directory account, which then gives you the same level of access as if you were logged into Passwordstate.

For Linux machines, you will need to use the standard API, which used API Keys for authentication.

Regards
Click Studios