AD Passwords about to Expire via Aegis - Method #3 using Depot activities

over 5 years ago
In this article I will show a third method of creating an Aegis workflow to notify users that their password will expire in X days.

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.

If there is a problem with Method #2 it is probably going to be that while its not as complex as writing a whole script in a scripting language such as Powershell or VBScript, it still requires some command line and script knowledge and being able to make sense of the results so they can be passed onto subsequent activities.   Re-using some of the steps also may not be easy depending on how they are implemented.  Method #3 basically replaces those command line and scripts in the Method #2 workflow with dedicated activities which are easy to configure, return outputs which are ready to use and require no programming skills.


Starting with the workflow from Method#2 as a template:


The first thing the workflow does is runs a command line to get the default policy for the maximum age of a password, and then parses the output of the command to get the numeric value.  These two activities I will replace with an LDAP Get activity which is downloadable from here along with other LDAP queries for Active Directory - Note if you want to work with LDAP with activities for eDirectory or OpenLDAP you can use the LDAP adapter available here.  You could also replace the standalone AD activities here with the adapter as another option.

The activity is pretty simple to configure - in this case as the Aegis server is part of the domain I want to query I don't need to specify the host although it is best to do so.  The Aegis Activity Broker service account is used for the bind when 'use service account' is specified but you can bind with a different account as required.   As in Option #2. the DN is defined in a workitem attribute for the base object in the directory.   MaxPwdAge is the attribute we want to query for.



At runtime the output is :


So the result is available without the requirement to parse with an extra activity.

The next part of the workflow which can be modified are the two script activities which calculate the start and end times of the search filter.  In method #2 these are scripts which convert a unix timestamp (which is the time format Aegis normally uses) to Win32/Filetime format.  In this case we replace the scripts with an activity which performs the calculation for us which is available here.

This has a simple configuration - just enter the timestamp and specify which conversion to do...


The output again is a result which is directly accessible - the same method is used to get the start time of the search filter and the end time.


Next with the components of the search filter ready, we can now use the LDAP Search activity (again here) to perform the search.  The configuration is easy, here I am searching the entire directory but I could do a search on a specific container object etc also:


Unlike the command line method, this just returns a list of matched users - you'll need to get their attributes like their email address, manager etc. in a separate activity - again from the LDAP for AD activities, the LDAP Get activity.  Here I am requesting the users givenname and mail attributes so I know who to notify and have a personal greeting in the email notification.


This yields a much more integrated workflow without the scripting requirements!

Comment List
Related Discussions