We have requirements to accomplish two things where access to data should be readily available is not because it is stored in the password blob. We need to send emails to users 2 weeks before their password expires. We have devised a workaround by using an additional attribute and a PX to set it whenever a password is changed. The problem is that if the password policy ever changes, this PX also needs to change (documentation, redundant functionality and repetition).
We also have a requirement to monitor last login and email people 2 weeks ahead of being disabled for inactivity. Last login is right there in the password blob, but we can't get to it, so we're trying to come up with a workaround like enabling dxPwdLoginTime in CA Directory. But I'm not sure how to enable access to that from an IdM PX. Plus this should not be a thing because SSO/IdM has the value sitting in the password blob.
I was just wondering if there is a hidden LAH or anything that can be used to gain access to this data which should be readily available to IdM in the first place?
If you want to set up password aging and enable dxPwdLastChange, use the commands (https://docops.ca.com/ca-directory/12-6/en/administrating/manage-user-accounts-and-passwords/create-a-password-policy/how-to-set-account-expiry-rules and https://docops.ca.com/ca-directory/12-6/en/reference/commands-reference/set-password-age-command ):
set password-policy = true;
set password-age = 14;
set password-history = 20;
set password-min-age = 1;
Use those in IdM, expose those using the user store XML (make sure they are set are readonly):
<ImsManagedObjectAttr physicalname="dxPwdLoginTime" description="Last pass" displayname="Days since password changed" valuetype="String" wellknown="%PASSWORD_AGE%" maxlength="0" permission="READONLY" hidden="true" searchable="false"/>
You can now us a PX or Balk task to query the "%PASSWORD_AGE%" and send notification accordingly.
You might want to set another "notification” attribute to keep tabs on the message sending so you don't flood the user
I will try this out in early 2018. Thanks.
We performed the above procedure to expose the dxPwdLoginTime to IdM and can see it in a view user task. We're trying to use this attribute in a Bulk Task to send an email to users who have been inactive for 180 days letting them know that they will be disabled in 2 weeks for inactivity. We're also using same attribute to disable the users 2 weeks later. The Date filter for the format used by CA Directory doesn't seem to work. CA Directory stores the dxPwdLoginTime in yyyyMMddHHmmss.SSSZ format (ex: dxPwdLoginTime: 20180103161114.361Z). Has anyone ever cracked the secret to getting IdM's date filter format to accept this? When I use a fake attribute set with yyyyMMdd it works fine, but this Date format has me baffled. Ideas?
Use a partial string, dropping the milliseconds yyyyMMddHHmmss instead of yyyyMMddHHmmss in the comparison string.
Better yet, you can try only the yyyyMMdd or yyyyMMddHHmm
Correction, yyyyMMddHHmmss is the minimum required for match