AD Passwords about to Expire via Aegis - Methods #4 using the SCM Adapter

over 5 years ago
In this article I will show a fourth method of creating an Aegis workflow to notify Active Directory users that their password will expire in X days, this time using an official adapter.

Method #1 was a very simple workflow based off a single script which performed all the automation tasks. Method #2 replaced the script with individual workflow steps with a mix of command line, script and data manipulation activities using workflow logic. Method #3 took the workflow from Method #2 and replaced scripts and command line activities with Depot activities to make things even easier.

Method #4 is completely different using the SCM adapter (Secure Configuration Manager) for Aegis.

This method is a departure from the previous techniques which all ended up querying AD via one way or another. Numerous other ways could have been done in similar fashion, including use of the Directory and Resource Administrator adapter to have Directory and Resource Manager perform the AD operations in a fully supported manner.

Lets first see how within Secure Configuration Manager we can find users whose passwords expire in X days.

Rather conveniently, Secure Configuration Manager has a security check which does exactly what we want - searches for users whose passwords expire in X days. So our workflow will basically execute this security check and read the results.


Unfortunately the SCM adapter doesn't allow us to directly run a security check, but its not a big deal. It can only run Policy Templates. In any event we want to pre configure the Security Check to meet our requirement so I just create a new policy template with the security check I want to run. This is done in Secure Configuration Manager and is pretty trivial. This is how I configured the check to search my an OU for users :


So this template can be then run inside Secure Configuration Manager on an Active Directory endpoint to test it works before having Aegis run the template.


With a working SCM template we can now configure Aegis to run the template. Note the information in the results, it has handy information like the number of days to expiration which can also be sent to the user.

To run the template in Aegis we need to run the 'Run Policy Template' activity. In this example I am going to use locators to specify the policy template name and the endpoint to run the template on since there may be more than one Secure Configuration Manager system configured on Aegis so it ensures the correct template on the correct Secure Configuration Manager system is selected.


The easiest way to get the locator value is via the Namespace browser. The endpoint locator (not in screenshot) is like this :


and the policy template locator is like this :

/IQSCM_CoreService=sigea-multi1:8044/IQSCM_PolicyTemplate=AD Passwors Expire


When the activity runs it does not wait for the template to complete on the SCM side (since some templates could take hours to complete). Instead it returns a locator to the job and the jobid as output to the activity. The SCM adapter generates an event in Aegis when the job completes - this event will be the signal to Aegis to continue the workflow. So we can use the Aegis activity 'wait for event' configured to wait for Jab Status events with a filter defined for the event attribute job locator to be equal to the job locator returned by the 'run policy template' activity. Some logic should be added so that this wait activity doesn't wait forever obviously!


So now assuming that the event was correctly detected, we can get the results of the template with the 'Get Security Check Results Detail' activity. Most of the inputs to the activity we have already. The input we don't have is the locator of the security check within the policy template we want to get the results for. This again can be gotten from the Namespace browser. The locator in this example looks like this:

/IQSCM_CoreService=sigea-multi1:8044/IQSCM_PolicyTemplate=AD Passwors Expire/IQSCM_Check=31603


Note that the IQSCM_Check object is given by an ID rather than a name. The ID defines the active version of the security check - this ID can change if the security check changes. For example if I change the configuration of the check, from 30 days to 20 days for example and save it a new ID is generated, so hard coding a locator as in my example isn't a good idea. Better that the current value is found dynamically via the find objects activity to ensure you are using the correct value or the activity will not return any results.

The 'Get Security Check Results Detail' activity returns a number of outputs but the most important one is the 'Security Check Results Detail' output which contains the data which we saw when manually running the check through Secure Configuration Manager.


This result is in an Aegis data table format so can be easily manipulated using standard Aegis techniques to loop through the table and get the desired values. You will still need to do an LDAP lookup to get the users email address if you want to notify each user individually, options on doing this were shown in the previous methods.

One caveat in this method however is you do need to handle the scenario where no users have passwords about to expire - the SCM check returns a a table with one row with a message that no users were found - so this would need to be distinguished where one user is found.



How To-Best Practice
Comment List
Related Discussions