Overview
Within the password management feature, customers often have a desire to leverage a password dictionary to ensure that their end users do not try to use passwords that are inherently weak, commonly used, or determined to have been exposed previously through a data breach. While IdentityNow does offer a password dictionary feature of its own, there are several drawbacks to implementing it: the dictionary size is limited to 2,500 words, it needs to be manually populated by the customer, and it does not allow automatic maintenance to ensure that newly discovered “weak” passwords are immediately added to the list of banned phrases.
For these reasons, customers often want to use a third-party dictionary that allows them to seamlessly integrate a password dictionary with their IdentityNow-defined password policies and allow a hosted provider to keep that dictionary up to date. This guide explains how to integrate one of those services - Azure Password Protection - with IdentityNow.
Assumptions and Prerequisites
This guide assumes that the customer has already purchased an Azure AD tenant with Azure Password Protection via the Premium P1 or P2 license.
Additionally, we assume that the customer has an on-premise Active Directory forest, and that IdentityNow is leveraging Active Directory as a pass-through authentication source for IdentityNow.
Lastly, we assume that the customer is interested in utilizing SailPoint’s password synchronization feature and have thus implemented our Password Interceptor (PWI) within their Active Directory forest. Thus, a password reset change within IdentityNow targets the user’s primary Active Directory account for reset, with other applications defined within the sync group being reset via the PWI detection and propagation flow.
Steps to Integrate Azure Password Protection with IdentityNow
-
Install PWI on the Active Directory domain controller. As documented within the installation guide, PWI needs to be installed on each domain controller in the forest where a user’s password reset request might be received.
-
Configure PWI to communicate with the appropriate IdentityNow tenant.
-
Set up a password sync group in the IdentityNow tenant with Active Directory and any other direct-connected sources which need to have their passwords synchronized within the group (e.g., Okta, Salesforce, etc.).
-
Set up a test identity so you can log in and ensure that this identity has an account in both the Active Directory source and each of the direct-connected sources within the test sync group created in step 3.
-
Also ensure that the identity has strong authentication methods that you have access to, such as alternate email, alternate phone, and/or knowledge-based answers; this is needed to test the password reset functionality.
-
-
Ensure that the identity profile to which your test identity belongs has the Active Directory source designated for the pass-through authentication target application.
-
Initiate a password reset for the identity’s Active Directory account from IdentityNow. This can be done easily using the “forgot password” flow from the IdentityNow sign-in page.
-
Confirm that PWI captures the change and sends it to your other sources within the sync group. This step ensures that the out-of-the-box PWI configuration works properly before you attempt to integrate Azure Password Protection.
-
Log into the Azure portal and confirm that Azure Password Protection is available within your tenant’s license.
-
Install the Azure Password Protection DC Agent per the steps outlined in the Microsoft documentation.
-
Enable Azure Password Protection in your Azure AD tenant.
-
Set up a basic Azure Password Protection policy (e.g., disallow the word “Longhorns” as a password). While Azure Password Protection already has a global list of banned phrases based on Microsoft’s analysis and telemetry data, adding a custom policy with explicit values helps test the functionality more easily.
-
Test resetting a user’s password to your banned phrase in Azure AD. This step ensures that the Azure Password Protection has been set up properly and is enabled to check against your custom policy as well. Now try resetting the Active Directory account’s password to your banned phrase using IdentityNow. You can use the same method as step 6.
-
Confirm that the Azure Password Protection service prevents you from choosing the banned password.
-
Within the IdentityNow UI, you should see the generic message, “You’ve used that password recently, or it is too soon since your last password change.”
- Within the Azure Password Protection DC Agent service installed in step 9 above, you should see an entry confirming that the password change was rejected due to a policy violation.
-
-
Just for good measure, confirm against your secondary sources such as Okta, Salesforce, etc. that the password change did not go through, and your original password is still in effect.
