Conditionally Assign CentralPassword policy for employees

Question

Hi Gurus, 
 I'm setting up password management in OneIM, and would like to ensure privileged accounts have higher requirements than regular accounts. 
 I'm using sub-identities (Person.IdentityType=Admin) to own privileged accounts - currently just AD accounts. 
 I want to: 
 
 Be able to apply a complex centralpassword policy, but only to employees with an IdentityType=Admin (or other criteria). 
 (ideally) Sync up the CentralPassword policy with an Active Directory account policy which has been synced in from my domain. I'd like this so that when an AD admin decides to change complexity rules, IM will sync in the changes automatically (which it already does) and apply these to new resets of CentralPassword. 
 
 From what I read in the documentation, I don't really see an OOTB way to do either of the above, though I could be missing something obvious! 
 Any help or suggestions appreciated. Happy to clarify anything if required. 
 Glen.

Markus Weiss-Ehlers · Answer

Hi Glen, 
 the password policies do not support free conditions to distinguish different type of person. But you can use the use the built-in extensibility features of the password policies. 
 If you need to have automated-syncing from AD to OneIM password policies you need to customize this on your own as this is no OOTB feature. Honestly, this should happen on a rare occasion based on my customer experience. 
 The following steps describe how the built-in extensibility features could be used to achieve your first use-case. 
 I took that from a similar but not identical use-case, so be warned. 
 
 Use-Case 
 A customer wants to use different password policies for the person-based logins according to the different types of identities OneIM is providing. 
 Solution 
 Use the ability to extend the view QBMVPwdPolicyColumns that defines what columns support password policies and where the system is going to search for them. 
 Step-by-step instructions 
 
 Create a new custom lookup-table that will be used as your anchor for identifying the password policy to use for a specific person (Do not forget to assign the needed permissions!). 
 Extend the person schema with an FK to the freshly created lookup-table (Do not forget to assign the needed permissions!). 
 Create a new view-addon for the View QBMVPwdPolicyColumns , that points to the DialogColumn Person.CentralPassword using the freshly created lookup-table as UID_DialogTableReference and the added FK at the Person object as ScopeReferenceColumns. Please take a look at the following SQL that uses an FK called Person.CCC_UID_CCCIdentityType as scope reference column to my custom lookup-table CCCIdentityType as table reference. It should have a lower sort order than the standard password policy assigned to the column Person.DialogUserPassword . select 'CCC' as ModuleName	
	, 'CCC-E0E5B96D4B9E9140B8BD368B331DE15E'	as UID_DialogTableReference
	, null as ReferenceWhereClause 
	, 'QER-5367B9FB892448D593ACA9DBAC8EDC2D' as UID_DialogColumn
	, 'Person' as TableName
	, 'CentralPassword' as ColumnName
	, 09 as SortOrder 
	, 'CCC_UID_CCCIdentityType' as ScopeReferenceColumns 
 Add the custom table as valid reference table to the dynamic FK QBMObjectHasPwdPolicy.ObjectKeyElement. 
 Now, you are able to create new password policies and assign them to the person table, using elements of your custom lookup-table as scope reference. See some sample screenshots from my sample implementation. (Here my sample implementation differs as I did that for the column Person.DialogUserPassword. So you need to adapt but I hope you see the idea.) 
 The only thing you have to do with the person objects now is to set the added FK accordingly depending on the password policy you want to use. The nice thing is that if the FK value is not set and the system cannot find a policy based on the FK it will fall back to the next password policy defined for the same column having a higher sort order. And of course, setting the value for the FK based on some templates or scripts should not be an issue at all. 
 
 Please keep in mind that, if you use my sample here for the column Person.DialogUserPassword as originally intended, you would need to disable the default schedule Reminder system user password expires to avoid issues with the process plan Inform employees about expired system user password .

Endpoint Privilege Management

Conditionally Assign CentralPassword policy for employees