We’ve recently had a number of customers enquiring about Single Sign-On (SSO) to Passwordstate where they have multiple Active Directory Domains. In these scenarios, the configuration is typically set for all user accounts located on one Domain and Application Resources including Passwordstate, located on the second Domain.
Normally Single Sign-On with Passwordstate works by passing through the currently logged in user’s credentials, used when logging into their Active Directory Domain from their Windows Operating System, to the Passwordstate instance. In the case of having multiple Domains, as outlined at top of this blog, you may receive additional prompting.
To recap on how to setup Passwordstate for SSO please refer to https://blog.clickstudios.com.au/diagnose-and-fix-passthrough-authentication-issues/.
Browser Prompting
In the examples for this blog, we’ve setup 2 AD Domains with the required trusts. An Applications Resources Domain (abbreviated to ARD) and a User Accounts Domain (abbreviated to UAD). Next, we’ve configured SSO and then attempt to navigate to a test Passwordstate instance located in ARD. The following prompt is received when navigating to the Passwordstate login URL;
In this image it’s the web browser prompting for these credentials. The request hasn’t yet been received by your Passwordstate instance located in ARD.
How do you know this? The Red Circle 1 above shows that the authorization is required for a URL (in ARD), compared to the Domain name shown at Red Circle 2 (UAD). If you simply enter your Username and Password it won’t work – there are no user accounts located in ARD. Instead, you’ll need to enter your Username in the format of Domain\Username and then your Password. This will then log you into the Passwordstate instance.
Rather than getting your users to remember entering Domain\Username and then your Password you can make changes to your web browser Local Intranet Zone to allow the passthrough of credentials, and in doing so, enable SSO to work.
Group Policy Settings
There’s a couple of ways to resolve this. You could;
- Ask your users to make the change themselves (if you’ve given them permission, and don’t care about service), or,
- (If it’s a real slow day) you could visit each user and do it for them, or,
- Make the changes via Group Policy.
Let’s face it, after you’ve done a couple you’ll be well over having to do it manually. That being the case we’ll explore doing it via Group Policy.
To do this you’ll need to edit an existing Group Policy called Site To Zone Assignment List, on the UAD and add to this a wildcard of *.ARD where ARD is the name of the Applications Resources Domain.
The Group Policy is located under User Configuration->Policies->Administrative Templates->Windows Components->Internet Explorer->Internet Control Panel->Security Page,
In the Show Contents dialog box, your wildcard of *.UAD, where UAD is the name of your User Accounts Domain, has a value of 1 (shown with Red Circle 3). The second row repeats this for your wildcard of *.ARD, where ARD is the name of your Applications Resources Domain, and it also has a value of 1 (shown with Red Circle 4). The value of 1 sets the wildcard entries, or domains, as being located in the Security Zone of Intranet.
Now after you perform a Group Policy update, and then navigate to the Passwordstate instance login URL, located in the ARD, SSO works correctly with your credentials from the UAD passed through without the user being prompted to supply them. If you’d like to share your feedback please send it through to support@clickstudios.com.au