One of the many strengths of Passwordstate is that it uses RBAC, or Role Based Access Control to assign granular permissions to objects stored within the system. RBAC restricts access based on a person’s role and is one of the main methods for advanced access control. In Passwordstate this means that users can only access the credentials, hosts and information that’s related to their job and that they’ve been assigned access to. Access can be based on their need to view, create, or modify credentials or stored information. Using RBAC helps in securing your company’s credentials and subsequently the access to sensitive information.
What’s needed to assign Granular Permissions?
The majority of Passwordstate implementations are Active Directory Integrated. This means that Passwordstate has been installed so that it can readily integrate with and utilise/synchronise User Accounts and Security Groups setup in Microsoft’s Active Directory. This allows you to fast track the appropriate Accounts and Security Groups rather than creating them from scratch (if you are using Forms Based Authentication).
The choice to setup your system as Active Directory Integrated or to use Forms Based Authentication is performed on initial setup under System Settings;
But don’t be concerned if you’ve setup Forms Based Authentication, we supply documentation on our website that guides you through the migration from Forms Based to Active Directory Integrated (and AD to Forms Based). Navigate to https://www.clickstudios.com.au/documentation/ and follow the appropriate documentation as indicated below;
How do you assign these Granular Permissions?
First, you’ll need to ensure the Security Groups and User accounts have been imported into Passwordstate and that you have a folder hierarchy that looks similar to your organizational structure. For reference, a blog on setting up a folder structure matching a fictious organizational structure is located here https://blog.clickstudios.com.au/guide-to-set-up-folder-structure-and-permissions/.
Next, you’ll need to ensure you’ve added the required Security Groups from AD that contain the users you want to assign permissions for. While the image below has a lot of arrows it is straight forward. Navigate to Administration->Security Groups and click on the Add AD Security Group located beneath the display grid on the Left-Hand Side. This will take you to the screen below. Now search for the Security Group Name you’re after, Select the Name in the Security Groups Search Results and then click Save;
You can of course do the same thing with User Accounts, but you’re better off assigning permissions based on Security Groups as a general rule.
You can now assign permissions for this Security Group on Folders and Password Lists. The example here is the Security Group Server Administrators has been granted Modify Permissions on the Password List SharePoint Accounts,
So…What Are User Account Policies?
User Account Policies allow you to manage specific sets of settings for groups of users. The settings relate to various user settings normally set under a User’s ‘Preferences’ area, and ‘Screen Options’ for Password Lists and Folders. When a User Account Policy is applied to a User (in this context as a member of a Security Group) it disables their ability to modify the settings under ‘Preferences’ themselves.
There are 34 different settings that can be applied to a User Account Policy. While a lot of the options control cosmetic settings, such as Specifying the Base Color or Show Header row on all Passwords Grids the keys ones of interest for this blog are;
- Mask Password Visibility on Add/View/Edit Pages
- Auto Generate New Password When Adding a New Record
- Specify which Authentication option will apply to the user’s account
- In the Passwords Navigation Tree, Use Load On Demand Feature
- Show the Permission Model icon indicators next to Folders and Password Lists in the Passwords Navigation Tree
- Make the Recent Activity Grid visible to the user
- Set the Mobile default home page to Password List Search or Password Search
These settings are particularly useful for different groups of users. For example, you could mandate that all members of Server Administrators, that by virtue of their role have access to highly privileged accounts, can’t just use SSO (Single Sign-On). Instead, the User Account Policy for the Security Group Server Administrators ensures that in addition to SSO they must use Google Authenticator as a second method of authentication when logging into Passwordstate.
To setup User Account Policies, navigate to Administration->User Account Policies and click on Add. This will take you to the Add User Account Policy screen,
From here you’ll need to provide a Policy Name and Policy Description, and change the required settings across the following areas;
- User Preferences
- Password List Screen Options
- Home Page Screen Options
- Mobile Access Options, and,
- Password List Options.
Once you made all your changes click Save at the bottom of the Screen.
Apply the User Account Policy to your Security Group
Now we’ve created a User Account Policy, in this case Google Authenticator, we can apply it to the Server Administrators Security Group. Select the Action menu next to the User Account Policy and click Apply Policy to Users. This will bring up the User Account Policy Permissions screen. It’s then a matter of searching for the Security Group, selecting it with the >> button and clicking Save.
Now when all Server Administrators browse to your Passwordstate URL they will be prompted to enter their Google Authenticator OTP even though the global authentication settings under Administration->System Settings->authentication options->Web Authentication Options are set to Passthrough AD Authentication.
User Account Policies Are Additive
When developing your User Account Policies, you can do so in a couple of ways. You could go ‘all out’ and have one policy for the primary Security Group that caters for all the settings you want to take effect. Or you can take the ‘incremental’ approach and have policies with only a few settings in them.
The latter approach of incremental policies is effective in that you can reuse those policies time and again for different Security Groups. And when the policies are applied at logon they are additive. By this we mean that the all of the applicable policies are applied to the user. You just need to remember that if you have the same setting in multiple policies, but each policy has a different value, the last of those policies takes priority. Polices are applied top to bottom with those lower in the policy grid taking precedence over those higher in the grid.
User Account Policies are an extremely useful tool when catering for different settings for different groups of users. All that is required is some thought and testing to achieve the results you want.
Got feedback? We’d love to hear it via support@clickstudios.com.au