We were recently asked to recommend an approach where a project team could test the migration from an existing authentication model to SAML (Security Assertion Markup Language) without impacting on the user’s ability to access Passwordstate.

In the example for this blog, we’re currently set for SSO (Single Sign-On) using Passthrough Authentication.  All clients are Windows based.

Don’t Use Your Own Account!

First things first.  Don’t be tempted to just test the changes to your own account.  Especially if your account is a Security Administrators account.  The last thing you’ll want to be doing is repeatedly logging in with the Emergency Access account to reverse any changes if you get the SAML configuration wrong.  

Take the time, and obtain any relevant approvals required, to establish a valid test account.  This should be setup comparable to that of a typical user.  This sort of account can be especially useful across a number of scenarios, including testing folder and password list permissions, User Account Policies etc. and you can (should) always disable the account when not actively using it. 

Disable Anonymous Authentication

Next, you should temporarily disable Anonymous Authentication in IIS (Internet Information Services).  This can be done by running the Internet Information Service (IIS) Manager Desktop App, navigating to the Passwordstate website, clicking on Authentication icon, selecting Anonymous Authentication and right clicking to get the Disable option as per the image below;

Once this has been done, you’ll need to set the Passwordstate system wide Authentication settings to Manual Login Authentication.  This will mean that users will be prompted to enter their AD credentials to login to Passwordstate while you’re testing.

To do this you’ll navigate to Administration->System Settings->authentication options->Web Authentication Options and select Manual Login Authentication from the Choose Authentication Option: drop down list as shown below (don’t forget to click Save at the bottom of the page),

Set your Test Account for SAML Authentication

Now, you can log in using your test account, and change the authentication option to SAML 2 Authentication under Preferences->authentication options->Web Authentication Option and select the SAML option from the Choose Authentication Option: drop down list then click Save,

You can now log out of Passwordstate and on logging back in again you should be redirected to your SAML provider.  You’ll need to login there and if the authentication settings are correct, you’ll be redirected back to Passwordstate and automatically logged in. 

Note: the reason why you’re logging in twice is Passwordstate only identifies your account once the credentials have been submitted (remember Anonymous Authentication is disabled) and you’ve set a preference for using SAML authentication.  Once it is set as the system wide setting all users, on navigating to the login URL, will be redirected to the SAML providers authentication screen.

Don’t Forget The SAML Authentication Settings…

These are set under Administration->System Settings->authentication options-> Primary Site’s SAML2 Authentication Settings and would need the following fields filled out,

The above represents an effective way to test the configuration and migration to SAML authentication while minimizing the impact to your users.  Once you’ve got it working correctly you can then swap over for all users by changing Administration->System Settings->authentication options->Web Authentication Options and select SAML 2 Authentication from the Choose Authentication Option: drop down list.

If you run a mixed client environment then unfortunately you can’t disable Anonymous Authentication in IIS.  This is a limitation with non windows clients, and IIS.  And once you are using SAML2 Authentication as the system wide authentication setting your users won’t be able to set an individual preference for authentication. 

Share your feedback by emailing it through to support@clickstudios.com.au.

Passwordstate, being a web based solution, has a User Interface (UI) accessible via a published URL.  This enables authorized employees access to create, access and share credentials based on their assigned level of permission.  The UI is the second most basic method of accessing a password record (the first being via our Browser Extensions).

For activities that don’t require user intervention, like scheduled password resets and account validations, we have a Windows Service called Passwordstate Service.  This is created during the Passwordstate Installation process and as the description in the image below states, provides management tasks for Passwordstate, 

But what sort of management tasks are handled by this service.  What special properties or permissions does it require?

The Passwordstate Service is Responsible for…

The Passwordstate Service effectively runs in an unattended manner and is responsible for processing scheduled events.  This is done by reading multiple tables and queueing any jobs due to be run.  When multiple jobs are due at the same time they are dynamically queued and sequentially processed.  The Passwordstate Service executes jobs within a defined security context, for example, using the specified Privileged Account Credential for any Active Directory Password Resets.

The following events are handled by the Passwordstate Service,

• Scheduled Password Resets, Discoveries and Heartbeats
• Scheduled Backups
• Sending Email Notifications
• Checking for new Builds
• Sending Audit Log data to Syslog Server
• Synchronizing AD Security Groups
• Sending Scheduled Reports
• Archiving Auditing data
• Removing Time Based Permissions

In order to perform these events, the Passwordstate Service is in constant communication with the database.  Each type of event has a specific interval timer used to specify when to next poll for that event.

The Passwordstate Service should only ever be set to logon as the Local System Account as per the image below,

It should not be configured to logon as an Active Directory account.  The only exception to this is if you are using Managed Service Accounts (MSA) and Group Managed Service Accounts (gMSA).  If using these you’ll need to ensure you’ve followed the instructions to Configure Passwordstate to use a Managed Service Account (MSA) to connect to the database located in https://www.clickstudios.com.au/downloads/version9/Installation_Instructions.pdf

Restarting the Service

As outlined previously, the Passwordstate Service is responsible for events that don’t require user intervention.  This means restarting the service is non-disruptive for users that are currently logged into Passwordstate.  To restart the Passwordstate Service, simply fire up the Services App, search down the list of services for Passwordstate Service, right click on the service and select Restart as per the image below;

Alternatively, you could fire up the Windows CMD Shell as an Administrator and type in Net Stop “Passwordstate Service” and hit enter.  Once the Passwordstate Service has stopped you’ll need to type in Net Start “Passwordstate Service” and hit enter again as per the image below;   

This performs the equivalent of the Restart command in the Services App (there is no Restart option for the Net command).

The Passwordstate Service enables automation of events that don’t require user intervention.  In the event you need to restart the service you can do so easily and without disrupting your users.

Share your feedback by emailing it through to support@clickstudios.com.au.

On 7^th April 2022 Click Studios released Passwordstate Build 9493 which supported the storing of Unicode characters in the Passwordstate Database.  The change to Unicode ensures the unique representation for every character, no matter the language. Unicode forms the foundation for the representation of languages and symbols in operating systems.

Prior to Build 9493 Passwordstate’s character encoding used Extended ASCII.  The first time a V9 upgrade is performed, from Build 9471 (or earlier), to Build 9493 (or later), it will upgrade the database to Unicode format as a once only operation. 

What Are The Implications?

Customers should be aware that during the upgrade the Passwordstate SQL Database and transaction logfile will increase in size by approx. 300% to 400%.  You’ll need to ensure there is adequate free space available before you start the upgrade, and the location used for your backups can support the additional size of the backups.

If you’ve previously capped the Autogrowth of your Passwordstate database then it’s recommended you temporarily set this to either Unlimited growth, or set the Maximum File Size by multiplying the existing size by a factor of 6 (allowing for additional contingency).  This will need to be done for both the database and the logfile.

To confirm if you’ve capped Autogrowth, or to set the Maximum File Size, start Microsoft SQ Server Management Studio and select the passwordstate database.  Right click on the database and select Properties.  From the Database Properties box click on Files, select the first entry.  If the Autogrowth/Maxsize column shows Unlimited at the end then Autogrowth is uncapped.  If it shows Limited to… then it has been capped.  To change the settings simply click on the box containing … and change the settings as indicated in the image below

Don’t forget to check both the entries and adjust them if necessary.

Shrinking The Database

Once the Passwordstate upgrade has been completed successfully you can shrink down the database and logfile.  Please note, you won’t be able to obtain the same file size you had originally.  Unicode requires more space to store characters than Extended ASCII. 

The easiest and quickest way to shrink your database and logfile is to do the following,

• Start Microsoft SQ Server Management Studio,
• Select the passwordstate database and right-click,
• Select New Query,
• Enter DBCC SHRINKDATABASE (Passwordstate)
• Click the Execute button

When the query has finished executing, you’ll see results in the format shown in the green box below.  Note the figures will be different based on your database and logfile,

Alternatively, you can shrink the database and the logfiles from within SQL Management Studio Tools User Interface without executing a SQL Query.  Please see section 15 of this guide if you’d like to follow this method https://www.clickstudios.com.au/downloads/version9/Installation_Instructions.pdf.

Share your feedback by emailing it through to support@clickstudios.com.au

Way back in February this year (it seems like only a couple of days ago) we published a blog post on Troubleshooting Passwordstate App Server/Mobile App Connections.  The focus of that post was ensuring there was data to synchronize, checking the user had access, generating the QR code and making sure the URL and Public Key were correct.  You can access that blog post here https://blog.clickstudios.com.au/troubleshooting-passwordstate-app-server-mobile-app-connections/

The focus of this blog post is different, in it focuses on troubleshooting the App Error Connection failed message.  This can appear when attempting to scan the QR code into the Mobile App,

But before we start, it’s worthwhile doing a recap on the communications flow between your Mobile App, the App Server and your Passwordstate instance.

Mobile Communication via the App Server

The diagram below offers a high level logical view of the communications flow between a Mobile App and your Passwordstate implementation.  There are two models in the diagram.  The first on the top (green communications lines), shows a Passwordstate instance where the Passwordstate Webserver, Database and App Server are all located on the same box.

The second on the bottom (orange communications lines), shows a Passwordstate instance where the Passwordstate Webserver, Database and App Servers are all located on separate servers.  There are other options such as hosting your App Server, with the Mobile App functional Role, in your DMZ enabling it to be internet facing.  However, the principle of the communications flow between the Mobile app, the App Server and your Passwordstate instance remains essentially the same.

Do you need to Update your software?

To confirm in an update is required to either the App Server or your Mobile App please refer to the following;

1. Refer to the Upgrades Dependency Matrix in https://www.clickstudios.com.au/downloads/version9/Upgrade_Instructions.pdf.  This will identify if an upgrade is required.  If it is, then follow the instructions under Section 6 App Server Upgrade Instructions.  Once you have upgraded you can test scanning the QR code again.

• Navigate to either the Play store, or the Apple store to see if there are updates for your device’s Passwordstate Mobile App.  If a new version exists then download and install it.  Again, once you have upgraded you can test scanning the QR code again.

Is your App Server Reachable?

To test to see if your App Server is reachable is straightforward.  This tests the communications from your Mobile App through to the App Server running your Mobile App functional Role.  To do this open the bowser on your Android or iOS Smartphone and enter the App Server URL that is specified in Passwordstate under Administration->System Settings->mobile access options->Mobile App URL and Security. 

If the App Server is reachable from your smartphone, you’ll see a “200 | Status OK” message like below; 

If you don’t see the “200 | Status OK” message then your App Server URL is not reachable from the smartphone.  This will more than likely be a network related issue (before all the Network Admins start complaining – I used to be one.  Sometimes it is a network related issue).  This can include Firewall or Wi-Fi configuration, or DNS blocking the access.

Confirm your App Server Settings

If you still aren’t able to connect, you’ll need to check your App Server Settings.  The first item to check is that the App Server name is set correctly under Administration->Authorized Web Servers,

The name must be in Netbios format and not specified in FQDN (Fully Qualified Domain Name) format.  If you don’t see your App Server in the display grid on this page then you’ll need to add it by clicking on Add beneath the display grid. 

If the App Server already exists you can check the Functional Roles for that App Server include Mobile App.  To do this click on the name of the App Server and ensure the checkbox for Mobile App is ticked as per the image below,

Check your App Server Web.config File

Next you can check that your App Server’s web.config file is correct.  To do this use Notepad to open the correct web.config file located in C:\inetpub\PasswordstateAppServer.  Look in the <appSettings> section for the following line,

<add key=”SetupStage” value=”Setup Complete” />

If it exists, then someone has accidently added this text into the file. You should delete it and confirm the settings look similar to the image below,

then save your Web.config file, and in IIS, restart the Passwordstate App Server website.  Now you can try the process of scanning in the QR code again.

By following these steps, the majority of issues causing a connection failure can be easily resolved. 

Share your feedback by emailing it through to support@clickstudios.com.au.

Part of the new functionality introduced in Passwordstate Build 9493 is the concept of using Functional Roles.  Functional Roles are supersets of functionality, that are designed, packaged and can be operated independently of your Primary Passwordstate instance.  It provides the ability to offload specific functional workloads from your Passwordstate instance to other webservers.  

To do this it uses the App Server architecture introduced in V9.  The App Server was designed as an extensible platform with the first example of implementing a Functional Role being for our Mobile App connectivity.  As of Build 9493 this has been extended to 7 main roles.  This can be especially useful if you need to offload intensive processing associated with one of these roles to another webserver in your farm.

New Functionality for Authorized Webservers

Under Administration->Authorized Web Servers you can now choose to install multiple App Server instances and assign each of these one or more functional roles.  The roles that can be assigned are;

• Standard API
• Windows Integrated API
• Browser Extensions
• Remote Site Locations Agent
• Password Reset Portal
• Self Destruct Messages

It’s always good practice to add your Authorized Webserver entry prior to installing the App Server on the new webserver.  Once your Passwordstate instance has successfully polled a new App Server it will turn the Polling Health status to green and specify the correct Install Path.  To define a new webserver with a Functional Role, simply click on Add as per the screen below;

This will take you to the Add New Authorized Web Server screen showing the fields to be filled out;

Enter the NetBIOS name for the Web Server Host Name, select the Server Role of App Server and select one or more of the Functional Roles you wish to assign to this instance of the App Server.  Note if offloading Functional Roles to another webserver;

• they should only be with a Server Role of App Server,
• should be deselected from your Primary Server (to avoid confusion and inconsistent results), and,
• Your Primary Server and High Availability Server (if implemented) should always be set the same.

To instal the App Server on the nominated webserver you can download PasswordstateAppServer.exe from within Passwordstate by navigating to Administration->System Settings->Mobile Access Options and click on the Download App Server Installer button.  I’d also highly recommend you first review the Installation and Administration Guide to ensure you’re using the very latest information.  The guide can be accessed via the App Server Install Guide button and is also located on our website here https://www.clickstudios.com.au/downloads/version9/Passwordstate_App_Server_Install_And_Administration_Guide.pdf.

Ensure the Correct URLs are set for Functional Roles

When you offload a Functional Role to another webserver it’s important to ensure you update the URL required for that new webserver;

• For the Standard API, this is specified in your scripts
• For the Windows Integrated API, this is specified in your scripts
• For the Browser Extensions, this is specified under Administration->Browser Extension Settings-> Browser Extension Settings
• For the Remote Site Locations Agent, this is specified under the specific settings for each Remote Site Location.  To find these navigate to Administration->Remote Site Administration->Remote Site Locations
• For the Password Reset Portal, this is specified under Administration->Password Reset Portal Administration->System Settings->miscellaneous
• For the Self Destruct Messages, this is specified under Administration->System Settings->self destruct messages

Please Note, when offloading the Remote Site Locations Agent to an App Server, it will source the upgrade files from that server instead of your core Passwordstate instance when it auto-updates.

Secure Your App Servers

Don’t forget to ensure you encrypt the Web.config file for each App Server instance you deploy.  You’ll need to encrypt both the Database Connection String and the appSettings Section.  For information on how to do this please refer to https://blog.clickstudios.com.au/securing-your-web-config-file/.  Remember you’re encrypting the Web.config file located in c:\inetpub\PasswordstateAppServer.  Again, if you have a different installation directory then you’ll need to look there for the Web.config file.

If you would like to share your feedback, we’d love to hear it.  Just email it through to support@clickstudios.com.au.

A couple of weeks ago we published a blog article on how to create Custom Account Types and Scripts https://blog.clickstudios.com.au/custom-account-types-and-scripts/ .  This week’s blog article builds on that with running through how to add custom Operating Systems and linking these to Hosts.

Adding a Custom Operating System

In our previous blog you’ll have created a Custom Account Type by navigating to Administration->Images and Account Types. 

Now we’ll add a custom Operating System as well.  To do this we’ll navigate to Administration->Host Types & Operating Systems and click on View Operating Systems as shown below, 

This will take you to the screen showing all the Operating Systems, Host Types and AD Attributes.  From here we’ll add the new Operating System by clicking on Add Operating System,

now we’ll specify the Host Type, in our case Linux, and type in the name of the Operating System we’ll add.  In this example we’ll add in GeckoLinux (based on the openSUSE distribution it’s great for out-of-the-box usability on the desktop),

Note, we’ve set the AD Attribute to ‘na’ as the Linux host isn’t added to Active Directory as we’re not interested in scanning AD to import these hosts via discovery jobs in this example.  Once completed we’ll click on Save.

Adding a New Host

Next, we’ll add in a host manually under the Hosts Tab and tag the host with the Custom Operating System entry we created.  To do this we navigate to Hosts and click on Add Host.  This will open the Add New Host screen.  Here we specify the Host Name (GeckoLinux_01), select the Host Type (Linux) and choose GeckoLinux from the drop down list,

We’ll also specify the connection type of SSH and the port number of 22 before clicking on Save.

Then Specify the Credentials, and Reset Scripts

When you Add New Password record for connection to the host, you can select the Account Type of Linux and then start typing in the Host Name (GeckoLinux_01) and it will populate the field correctly.  We’ve also added the Username (Root) and supplied the Password,

then moving reset options tab, the Password Reset Script has been populated correctly with the reset script to be used.  Then simply click on Save to save the Password Record.

If you would like to share your feedback, we’d love to hear it.  Just email it through to support@clickstudios.com.au.

Click Studios provides extensive documentation for our customers.  This covers everything from User and Security Administrator Manuals, Installation Instructions, instructions on how perform upgrades and General Administration tasks.

The approach we use for our documentation is to include everything, and I do mean everything.  We even get the occasional complaint that some of the documentation is too long.  But that’s okay!  Experienced Passwordstate Security Administrators can get to choose what they want to read.  The approach we use means that while the documentation can be long, it can also be used as reference for less experienced Administrators and those new to Passwordstate.

Those wanting to jump straight-in can find our documentation page here https://www.clickstudios.com.au/documentation/ and those wanting to navigate to it via our website menus can find it here,

How do I Move Passwordstate & Upgrade at the same time?

A common support request we receive, is how do you move Passwordstate to a new server and also upgrade it to the latest version.  This is actually a very simple process that we already cater for in our documentation.

First, you’ll need to decide if you’re moving just your Passwordstate Webserver or are you moving the Passwordstate Database as well?  If you are moving the Database then this move must happen first.  This documentation can be located here https://www.clickstudios.com.au/downloads/version9/Move_New_Database_Server.pdf or for those wanting to navigate via our website menus, it’s located here,

By following these instructions in this document, you will effectively;

• Ensure your new Database Server has Microsoft SQL installed, and,
• Your database has been moved.

Once you’ve followed the documentation to move your Passwordstate Database (or if not moving it at all) you’re ready to move your Passwordstate Webserver. This documentation can be located here https://www.clickstudios.com.au/downloads/version9/Move_New_Web_Server.pdf or for those wanting to navigate via our website menus, it’s located here,

Again, by following these instructions in this document, you will effectively;

• Have Installed the correct Build of Passwordstate.  This will be either,
  • Initially Build 8995 (If your current version of Passwordstate is less than Build 8995), and,
  • Then upgraded to the latest V9 Build (if your current Build is 8995 or higher)
• Copied the entire ConnectionStrings and AppSettings sections from your existing Web.config file into the new website.  If your settings are encrypted you must have decrypted them before copying them, and,
• Encrypt your new Web.config’s ConnectionStrings and AppSettings sections as this is best practice and highly recommended.

Other Instructions to Consider

If you are upgrading from a version prior to V9 you may want to also consider the following;

Configuring the built-in backup capability using either a Domain Account using Network Shares or Local Folders, or, using a Local Windows Account with Local Folder.  These can be found by navigating via our website menus here,

Or, directly here https://www.clickstudios.com.au/downloads/version9/Passwordstate_Automatic_Backups.pdf for number 1 in the green circle above, or https://www.clickstudios.com.au/downloads/version9/Passwordstate_Automatic_Backups_Local_Account.pdf for number 2 in the red circle above.

Give our documentation a try.  We think you’ll find it’s easy to understand, straight forward and will help you perform the tasks you need to.  If you would like to share your feedback, we’d love to hear it.  Just email it through to support@clickstudios.com.au.

Passwordstate uses PowerShell scripting as the extensible platform for PAM, or Privileged Account Management.  The PowerShell scripts provided with Passwordstate enable Account Discovery, Password Resets and on-demand or scheduled validation (Heartbeats) to confirm that accounts are being managed through our solution.  For more information on what types of systems can be discovered, reset and validated please refer to our website here https://www.clickstudios.com.au/about/privileged-account-management.aspx .

Where the strength of our PAM solution is evident is through the flexibility and extensibility of the PowerShell scripts.  In the event, that some infrastructure components or business systems in your environment aren’t covered by the large number of default scripts we provide, you can simply copy one of our scripts and modify it for your requirements.

Add your Custom Account Type

As an example, we’ll create a new Account Type, set it to having Password Resets performed against it and associate it with a custom image.

To do this, navigate to Administration->Images and Account Types and click on Add beneath the Images and Account Types display grid.  This will bring up the Add New Account Type screen shown below. 

In our example, we’re going to give it an Account Type Name of Test, ensure the Managed radio button Yes is selected, we’ve clicked on Select and chosen a custom image to upload called Padlock.png and then clicked the Save button.

Add a Password Reset Script

Next, we’re going to setup a Password Reset Script for the Test Account Type.  To do this, navigate to Administration->PowerShell Scripts and click on the Password Resets button.  This will take you to the Password Reset Scripts page.  Now click on Add New Script underneath the display grid and you’ll be presented with the Add Password Reset Script screen below;

Here we’ll add a Script Name of For Test Account Type and a Description of Test and select Create Blank Script from the Create Script Contents From drop down list, then click Save.

Edit the PowerShell Script

Now we can edit the newly created Script by navigating to Administration->PowerShell Scripts and click on the Password Resets button.  Again, this will take you to the Password Reset Scripts page.  Next, we’ll locate the Script Name For Test Account Type and click on the Script Name which is actually a hyperlink,

This will open the Edit Password Reset Script editor, allowing you to insert your code and choose from Host, Dependency and Password Fields to insert into your code as appropriate.  In the example we are inserting the fields of OldPassword and NewPassword,

Once completed click on the Save button.

Password Records using Custom Account Type and Reset Script

Now when you add new password records, on the password details tab you can select the Custom Account type (in our example Test) from the Account Type drop down list and select the Managed Account check boxes for Enabled for Resets and Enabled for Heartbeats,

And on the reset options tab, select the correct reset script (in our example For Test Account Type) from the Password Reset Script drop down list,

When passwords are changed for these records, either manually or as a scheduled task, Passwordstate will reach across to the target system using the Password Reset Script and change the password on those systems.

This is of course a simple example of what needs to be done.  In reality you would create Password Validation and Password Reset scripts and the PowerShell coding required can end up being quite complex.  A best practice approach would see these scripts being developed and tested outside of Passwordstate.  Once they are working as expected and have been through your organizations Change Management processes they can be included as per the instructions in this blog.

If you would like to share your feedback, we’d love to hear it.  Just email it through to support@clickstudios.com.au.

The Mobile Clients introduced in Passwordstate V9 are purpose-built iOS and Android apps.  These authenticate using an independent credential set and allow the secure storing of password records locally on the smartphone, within an encrypted cache. 

You can use the biometric capability of your smartphone to access the data within this cache and all authentication / access of credentials is audited and synced with your Passwordstate instance on the next connection.  We have some exciting news about upcoming features in these apps…but that’s for a future blog.

In the meantime, if you find you have issues in connecting via the App Server or in Synchronizing entries between Passwordstate and the App we’ve produced this troubleshooting blog article for you.    

Ensure there is data to Synchronize…

Interested Passwordstate users have gone to the respective Apple and Google Play stores and downloaded the Apps.  Everything seems to be working and then you start getting support calls related to some users being unable to connect or synchronize credentials to devices. 

The first thing you may want to check is your Password Lists are enabled for Mobile Access.  This is a default setting when you grant a user access to a Password List and is controlled under Administration->System Settings->mobile access options->Mobile App Settings->When adding new permissions to Password Lists, enabled Mobile Access by default being set to Yes. 

You can confirm If they have access by viewing the Password List Permissions, and should see a tick under Mobile Access for the user in question, 

Note that the default setting can be individually selected or deselected when adding permissions to a Password List.  This is done by right clicking on the Password List, selecting View Permissions, and then selecting Grant New Permissions and clicking on the No radio button, 

The Mobile Access Permissions on Password Lists can also be modified in bulk by navigating to Administration->Password Lists->Perform Bulk Processing…->Mobile Access Bulk Permissions.

If this all appears to be correct then you may want to check the user has been granted access to use the Mobile Native App feature.

…Check the user has been granted Access…

You can control which Users or Security Groups have access to the Mobile Native App feature by navigating to Administration->Feature Access->mobile and clicking on the Set Permissions button,

This works exactly the same as other permissions screens.  If they haven’t been granted access, simply search for and add the appropriate Security Group (preferred) or User with the >> button and click Save,

You’ve now checked they have been granted access to the Mobile Native App and have Data to be Synchronized.

…Generate your APP Server QR Code and Password

If the Users are still unable to connect to the App Server or are unable to synchronize data you can try getting them to clear their existing Master Password, supply a new one and generate a new QR Code.

To do this have the user login to Passwordstate and click on Preferences->Preferences->mobile access options->Mobile App Settings and click on the Clear button.  They need to then type in a new Master Password and once done click Save,

This will generate a new QR Code which they’ll need to scan when re-pairing their mobile app.  When re-pairing please ensure the username they are supplying is the one specified under Mobile App Username:.  If this is a domain account the format will be Domain Name\Mobile App Username.  The password is the new Mobile App Master Password they have just set, not their Domain password.

Make sure your URL and Public Key are correct

If you have recently changed your Base URL for the App Server or updated the SSL Certificate, you’ll need to ensure the settings under Administration->System Settings->mobile access options->Mobile App URL and Security have been updated.  If either of these have changed, you’ll need to ensure the URL under Specify the URL for your Passwordstate App Server installation is correct, then click on the Generate New App Pairing Secret,click on the Clear and then Query button to obtain the Public Key for the App Server’s SSL Certificate.  Once done click Save,

If when clicking Query you receive an error message or the Public Key box doesn’t populate then there is an issue with the App Server URL, your DNS or Firewall settings.

When successful, you’ll now need to have each user regenerate their APP Server QR Code and Master Password and re-pair their mobile app as per the previous section.

IIS, DNS and Port Settings

If you are still having issues with connecting to the App Server then you should also check on the following;

• Check that your HTTPS binding in IIS (Internet Information Services) has the same URL you have set under Administration->System Settings->mobile access options->Mobile App URL and Security
• Make sure your DNS entry is set correctly for the App Server URL, and it is pointing to the correct server.  To check this, you can run CMD.exe as an Administrator and type nslookup followed by the FQDN (fully Qualified Domain Name) of the App Server
• Confirm the port you are using for the App Server URL is open. By default it uses port 443 but you should confirm that is the port specified in your IIS binding.  If you have a HA implementation, and are using a SQL Listener as part of SQL Replication between database servers, then the port must be open on both SQL Servers
• Ensure the App Server can communicate to the Passwordstate Database.  Login to the Server hosting the App Server, Start PowerShell as an Administrator and type Test-NetConnection followed by the FQDN of the server followed by -Port 1433.  This will return the IP addresses and a TCPTest Succeeded: True if successful.
• Test that you can reach the App Server URL from your Smartphone.  Type the App Server URL into your Smartphone browser and you should see a 200 | Status OK message on the page.  This means the Smartphone can successfully reach the App Server.  Any other result indicates the App Server URL is not reachable.  You may want to try this test via the business WIFI network and via your Smartphone Carrier’s network if the App Server is internet facing.

By working through these steps, you should be able to troubleshoot the reason why users are unable to connect or synchronize data and resolve the issue for them.

Got feedback you want to share?  Email it through to support@clickstudios.com.au.

The intent of our Password Reset Portal, is to remove unnecessary interaction by Help Desk staff and Systems Administrators when users need to reset their Active Directory Users Accounts.  The portal is aimed at making users self-sufficient at the process, ensuring they can reset the account when they need to, and allow support staff to focus on higher value tasks.

Error: Password Doesn’t Match the Policy

But what happens when the process doesn’t seem to be working?  We recently assisted a customer with a scenario where the users couldn’t seem to match the Password Policy no matter how often they tried.  They attempted to troubleshoot this by generating a password in Passwordstate however this wasn’t being accepted either.  So where do you start to troubleshoot AD Password Resets performed via the Password Reset Portal? 

To start off with let’s use an example of a Password Policy and Failed Reset Message.  This is configured under Administration->Password Reset Portal Administration->Password Policies,

Note: You can set the Failed Reset Message wording so that it’s consistent with the language used within your organization.

Password Reset Portal Process

At a high level, the process that is used within the Password Reset Portal is;

1. When a user resets their AD password, the characteristics of that password must adhere to the Password Policy that has been defined.  For the sake of this blog the Password Policy is the Default Policy and is the same for all fields as we’ve set in the previous image.  Again, this is set by navigating to Administration->Password Reset Portal Administration->Password Policies,
2. As the user types in the new password, the Portal page will report on what characteristics are required to set a password.  These must match the policy and feedback is provided live as they type in the new password,
3. Once all requirements are satisfied the Password Reset Portal will attempt to reach out to Active Directory to reset the password.  At this stage, if your Domain Password Requirements as specified in your Domain Group Policy have further complexities, then the user’s new password will be evaluated against these further complexities.

If the Password Reset is rejected with the Failed Reset Message in the image above, then it is most likely the error you are seeing is coming from your Domain and not the Password Reset Portal.

Settings that Impact on Portal Resets

There are a number of settings that can impact on the Password Reset Portal successfully resetting a user’s password. 

The first is located in a group policy setting.  Open your Group Policy Editor and navigate to Local Computer Policy->Computer Configuration->Windows Settings->Security Settings->Account Policies->Password Policy and look for a Policy setting stating the Minimum password age. 

The Minimum password age of 1 day is the default setting.  It is used to prevent repeated resets until a favourite password can be cycled back in again.  You’ll need to consider the risks associated in changing this default, and if acceptable you can relax this setting and enable multiple password resets per day by changing the Security Setting to ‘0’,

The next setting that can impact on successfully resetting the password is if your permissions associated with impersonation aren’t correct.  To check this, you’ll need to launch the Local Security Policy editor by running secpol.msc.  From there you’ll need to navigate to Security Settings->Local Policies->User Rights Assignment and review the permissions that are set for Impersonate a client after authentication.  These should be set to the following as per the screenshot below.

• Local Service
• Network Service
• Administrators
• IIS_Iusers
• Service

And lastly, it’s possible that you may have a fine grain policy set in Group Policy, that takes precedence over your Standard Password Group Policy. 

This may have been set with a Minimum password age set to something greater than 1, or, may have stricter password complexity requirements.  To check if you have a fine grain policy set up you’ll need to logon to one of your Active Directory Domain Controllers, open the Active Directory Administrative Centre and navigate to System->Password Settings Container as per the image below,

If there is a policy show in the area outlined by the green box above then please check the settings.  If you’re unsure you may want to refer to the person that is applying the policy.

Privileged Account Credential Permissions

One final thing you can check is to confirm the Privileged Account Credential, that you have specified for the Password Reset Portal, has sufficient permissions to reset the AD Accounts.  The Privileged Account Credential is set under Administration->Password Reset Portal Administration-> Privileged Account Credentials. 

This should be a member of the Account Operators Security Group.  If it isn’t working you can temporarily test with as a member of the Domain Admins Security Group.

Got feedback you want to share?  Email it through to support@clickstudios.com.au.