Captain
Captain
282 views

Reset password custom workflow to verify bad pwds in Active Directory or Azure Active Directory

Hi All,

We have IDM 4.7 engine and idmapps application on Linux environment. We have an Active Directory driver that works fine for user/group provisioning.

We have a IDM workflow to reset the service accounts password by the owner of the user. The owner user login to idmapps, access the reset service account password workflow. Then he/she can generate/set a new password. The password is set in IDM and it is synchronized to Active Directory. It works fine.

Now, we have a new requirement. That is: When the user is generating and key in the password, the workflow will have to connect to Active Directory or Azure Active Directory and verify the password policy and bad password lists (provided by Microsoft). If the password is already in bad password list, it should not accept, pop up a message.

The reason is, the organization is planning to implement Azure Active Directory bad password audit/verification. Azure Active Directory connects to Microsoft site for getting/verifying the latest bad passwords. As we understand that this bad password list is dynamic, keeps get updated every now and then.

Is this possible from IDM workflow (before click submit) to connect to AD or AAD to verify bad passwords? Is this doable...

If its doable, could you share some details on this.

Thanks,

-dk

Labels (1)
5 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

I believe, you talking about Azure AD Password Protection.
I don't think, that Azure AD Password Protection allows "pre-processing" or password validation.

The DC Agent service of Azure AD Password Protection receives password-validation requests from the password filter DLL of the DC Agent. The DC Agent service processes them by using the current (locally available) password policy and returns the result of pass or fail.

https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad
Vice Admiral
Vice Admiral

I have written code to make SOAP and REST calls from the legacy form engine, not so sure about Forms.io/nginx...



However, in order to work around the SOP (Same Origin Policy) which prevents you from making web service calls from Javascript going to a different server than the HTML source server, I wrote a simple proxy which I put on the same Tomcat instance as ID Apps.



I documented that here:

https://community.microfocus.com/t5/Identity-Manager-Tips/Querying-a-Connected-System-from-a-Workflow-Form/ta-p/1776902



This is not exactly the same solution but you can derive a what you are looking for from it.


Knowledge Partner Knowledge Partner
Knowledge Partner

I found an official MS statement about the ability to "validate a password":
The Azure AD Password Protection DC agent software can only validate passwords when it's installed on a DC, and only for password changes that are sent to that DC. It's not possible to control which DCs are chosen by Windows client machines for processing user password changes. To guarantee consistent behavior and universal Azure AD Password Protection security enforcement, the DC agent software must be installed on all DCs in a domain.
https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad-on-premises

 

Currently, I didn't see any info about Azure AD Password Protection API and the ability to validate passwords thru "back-door" (API call/PowerShell/etc).

Vice Admiral
Vice Admiral

@al_b  is there any initiatives from NetIQ with Microsoft to support  their Password Synchronization feature  in AzureAD from non Microsoft technology such as  NetIQ Identiy Manager without using "Graph API or Powershell" Apis (Users  actual  password being sent under Htt(S) transport)?

I know their AzureAD Connect technology does "password hash sync" which is not users actual password but synchronize the users password hash of the of hash (double hash) sync from original password from Active Directory to AzureAD and in both ways from AzureAD to Active Directory and from Active Directory to AzureAD.

 

I know Microsoft support non microsoft technology but using their own product Microsoft Identity Manager (as LDAP Management Agent) (Azure AD Connect light).

/Maqsood.

 

 

 

 

Knowledge Partner Knowledge Partner
Knowledge Partner

Hi Maqsood,
I'm not sure...


Password hash sync is the method used by ADConnect/MIM for on-premiss/AAD password synchronization.
Azure AD Password Protection is not related to password sync "directly".


Azure AD Password Protection detects and blocks known weak passwords and their variants, and can also block additional weak terms that are specific to your organization.
The Azure AD Identity Protection team constantly analyzes Azure AD security telemetry data looking for commonly used weak or compromised passwords. Specifically, the analysis looks for base terms that often are used as the basis for weak passwords. When weak terms are found, they're added to the global banned password list. The contents of the global banned password list aren't based on any external data source, but on the results of Azure AD security telemetry and analysis.

DC agent captures the user's password change (exactly how we doing it with our AD Driver PWFILTER.DLL) and validates this new password against this "global" banned password list and some other parameters in AAD and on-prem AD and decline this password change if according to Azure AD Password Protection calculation this new password is weak.

The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.