×

IDMWORKS Blog

How to Add Password Expiration Exception Windows in NetIQ IDM


If your company or institution experiences seasonal periods where users are expected to not access their resources daily, for example a school or college, there may be a desire to manipulate password expiration dates on accounts to prevent passwords from expiring during those periods of reduced activity.  The problem with this desire is that in an automated system where password policies define a hard password lifetime of X days there is no way to conditionally evaluate if a password expiration falls into these “exception windows” to be reduced or extended as part of the password policy.  This means that an external and custom process would be needed to perform the necessary checks and modifications to achieve that goal.

Whereas this could be achieved by doing simple LDAP queries to find accounts that expire within the date range and other simple LDIF imports to edit those dates to a more acceptable time it means that someone has to manually  process these actions, create and run scripts to perform these actions, and/or review the results for accuracy.  Not to mention, that when performing bulk changes like that, it is common that all dates are set to the same date for simplicity.  It requires much less time and/or code to give all users the same date than it does to perform calculations for varied expiration dates.  This typically results a large influx of passwords expiring at the same time which can impact productivity and/or create a dramatic increase in calls to your institution’s help desk.

Before we get into the technical solution, you may be asking yourself, “why would I need something like this?”  The answer is simple, in an environment where users are away for extended periods of time it is a common issue to have users return to expired accounts with no way to reset the password or authenticate into the system.  This causes a number of issues and delays in productivity that could be avoided if the passwords did not expire during that recess, particularly in educational environments where students and faculty may be gone for several weeks to a few months between logins.  Imagine the chaos and issues that would arise on the first day of class when many, if not most, of the students and staff can’t login to the network to access their materials.  By programmatically evaluating and adjusting password expiration dates with these known periods of inactivity these types of issues can largely be avoided, or at least minimized.

The other common question related to this practice is “but what about security? Doesn’t this fly in the face of best security practices?”  Not really, no.  Most best practices for passwords only stipulate that a password has an expiration date but those lifetimes can vary from place to place.  There is no hard and fast rule that says a password should never be more than X days old.  Those expiration ranges are generally based industry standards, security recommendations for associated systems, etc.  Depending on your institution’s field of business there may be driving factors that say your passwords expire every 30 days while other businesses are fine with 90 days or more.  This means that implementing a solution to programmatically alter password expiration dates that may extend beyond your institution’s standard password policy lifetime is subjective to what your industry and your security team is willing to allow within your environment.  Depending on your audit standards and industry such a practice may not be advisable but generally speaking, people in those fields know as much and would not be interested in such a solution.  This article and its proposed solution is geared more towards those who’s security standards would allow for such a solution to meet a need that may not exist in all fields.

With the decision made to implement a solution to alleviate this issue, the actual amount of work needed to execute such a solution is actually pretty minimal within an IDM solution like Identity Manager from NetIQ/MicroFocus.  Their IDM solution uses a real-time event engine that can detect changes to a user’s password expiration date as soon as its made.  That password expiration date change event can then be immediately evaluated to see if the new expiration date falls in to one or more exception date ranges and if the date is found to be in one of those ranges, the solution can automatically adjust the password expiration date to beyond that window.  No clumsy LDAP queries, questionable LDIF imports, custom scripts, manual tasks, or even scheduled tasks.  In a MicroFocus IDM environment it can happen in real-time using the IDM solution’s built-in automation processes which support full logging and auditing capabilities that may not be available in custom and manual approaches.

So how does the solution work?

The solution uses a simple approach using the following four components within your MicroFocus IDM environment:
● A mapping table to hold the list of date ranges and extension lengths
● A Global Configuration Variable (GCV) with the path to the mapping table
● A Loopback/Null driver with a filter set to monitor the password expiration date attribute on the Subscriber channel
● A rule in the Loopback/Null driver to perform the necessary date check logic

In this demonstration, we will use a typical school/college as our example institution.  Education environments typically have several “breaks” in attendance throughout a year and are ideal candidates for this solution.

We start the solution by creating our mapping table.  The table columns can be named whatever makes sense to you but in this example the columns used are as follows:

Session_Name
● This is a case insensitive text field that holds the easy reference description for the scheduled break, e.g. Spring Break, Winter Break, Thanksgiving, etc.
● Values entered in this field MUST be unique for the driver rule logic as expected.  If more than one row has the same Session_Name value it could cause the driver rule to read data from the wrong row as the driver rule matches on the Session_Name field values.

Session_Start
● This is a case insensitive text field that holds the first date in the current exception window range.
● The dates listed in this field are in MM/dd/yyyy format.
● The date format can be edited to fit your desired format but the sample code provided in this article expects this format to be used so any changes to the format in this mapping table would need to be accounted for in the code used in the driver rule.

Session_End
● This is a case insensitive text field that holds the last date in the current exception window range.
● The dates listed in this field are in the MM/dd/yyyy format.
● The date format can be edited to fit your desired format but the sample code provided in this article expects this format to be used so any changes to the format in this mapping table would need to be accounted for in the code used in the driver rule.

Session_Active
● This is a case insensitive field that basically holds a TRUE/FALSE flag that is used in the driver rule to determine which date ranges are to be considered during evaluation.
● Rows set to FALSE in this field will be ignored by the driver rule.

Session_Extension
● This is a numeric field that holds the number of days the rule will automatically add to the current password expiration date.
● The driver rule uses an iteration approach and will apply this number of days to the current password expiration date until that date is no longer in the date range specified.

Next, it is recommended that you create a Global Configuration Variable (GCV) either on the driver or the driver set to hold the path of the mapping table.  The driver rule will allow you to browse and select the mapping table from the project library but if there are differences in your IDM tree names between environments the GCV allows for easier transition from environment to environment and reduces the risk for errors in future updates to that driver/policy.  It doesn’t have to be anything fancy, just a case insensitive string value.

GCV Example:

Now that we have our mapping table created and populated along with a GCV that points to our mapping table all that is left to do is apply the driver logic to detect changes to users password expiration dates and adjust as needed.

For those familiar with the MicroFocus IDM product, you know that in order for the driver to react to changes on that attribute that it has to be added to the driver’s filter and set to “Notify” for the Subscriber channel.  For those, not familiar, it looks like this in Designer:

Now, some may be asking why the driver filter is set to “Notify” instead of “Synchronize”.  In a Loopback/Null driver like this the driver is not configured to synchronize.  The driver reads and writes to the identity store so the source is also the destination.  These types of drivers are usually used to evaluate and react to internal processes only so the rules that detect the changes generally handle the output back to the source so Notify is sufficient to raise the necessary events in the driver engine and is more efficient than Synchronize because it prevents accidental processes in the Publisher channel.

The last piece of the puzzle is the actual driver rule that puts all of this into action.  Below is the rule XML code that can be copied and pasted into your Designer project to quickly create the basic logic.  We will delve into the code specifics below.

For those who don’t want to read the XML code, here is a screenshot of the completed rule in Designer:

The conditions for this sample are rule are pretty basic and can be tailored to fit your user base as needed but basically the condition checks for modify events where the Password Expiration Time is changing as part of the modify event.  Generally speaking, there would probably not be a big need to execute this logic on new accounts being provisioned, especially if part of the on-boarding process includes an account “claiming” step that requires the new user to change their password, so the condition does not include account creations, renames, moves, or deletes; only standard modifies that include a change to the password expiration.

The rule actions is where the real meat of this solution exists.

First, we set two local variables, both equal to the original Password Expiration Time attribute value.  We will keep one variable set to the original value (lv_CurExp) and manipulate the other (lv_NewExp) throughout the rule’s logic.  At the end of the rule we will compare the two values and if they are still the same then we know that no change was needed to the attribute in the data store otherwise we update the expiration date attribute with the new value.  This is a code efficiency check to ensure the rule is not making unnecessary calls to the data store to execute updates that are not needed.

Next, we create a nodeset array variable that contains all of the values in the Session_Name column of our mapping table for rows where Session_Active is equal to TRUE.

With the nodeset array created, now we need to loop through date ranges and compare against our editable expiration date variable (lv_NewExp).  Within the iteration, for each active session found in the mapping table we need to read the Session_Start date and Session_End date fields into local variables, lv_RawStartDate and lv_RawEndDate respectively.  With those “raw” date values, we need to convert them to the same date format that our user’s expiration date has, !CTIME; lv_StartDate and lv_EndDate respectively.  And finally, we need to set another local variable that contains the number of days to increment the lv_NewExp value if needed for that session, lv_SessionExtend.

Now that we have the current session’s data from the mapping table and the dates are formatted to match the current password expiration date format, we need to check to see if our expiration date value (lv_NewExp) falls between our Start and End dates (lv_StartDate, lv_EndDate).  We do this using XPath expressions as part of a Do While loop to see if our lv_NewExp date value is greater than or equal to our lv_StartDate value AND the lv_NewExp date value is less than or equal to our lv_EndDate value.

Since the XPath expression checks are part of a Do While loop, the checks will continue to iterate and execute the following actions until the condition is no longer met.  This means that the loop will automatically continue to execute until the lv_NewExp value is no longer within the current session’s date range.  As long as the lv_NewExp date value is within that range though the rule will add X number of days to the current lv_NewExp date value based on the Session_Extension field in the mapping table for the current session which is held in the lv_SessionExtend variable in the logic.

After all active sessions have been iterated through and the expiration date has been evaluated, the last step is to check to see if the expiration date value has changed from the original value.  If the value has changed then the rule will modify the user account object in the data store to update the password expiration date attribute to the new value.  If the value has not changed then the rule exits without taking any additional actions on the user account object and thus leaving the password expiration date set to the original value.

And that’s it.  With a simple mapping table and a few lines of code in a driver rule your MicroFocus IDM solution can automatically adjust password expiration dates in real-time to prevent passwords from expiring during times that might be prohibitive to your environment.

And now a few extra thoughts…

A Word of Warning

Just as a word of warning, depending on the date ranges entered in your mapping table and the session extension values you could potentially create scenarios where password expiration dates are extended into other exception date ranges which could result in A) a password not expiring for a very long time and B) a password that was extended past one range but put into another range that had already been checked.  Of these two scenarios, B is the one that most people might find frustrating because the system allowed an expiration date to be set during an exception window.  Odds are that most exception windows will not be too close to one another so as long as you set your session expiration increment values to reasonable values this can be largely avoided.  I would not recommend setting a Session_Extension value of 30 if your Session_Start and Session_End range is only a week long.  Reasonable extension values can avoid the expiration ranges with minimal iterations while reducing any chance of conflict with other ranges in the table.

Mapping Table Data Check

Yes, the mapping table is static data that will need to be maintained as future date ranges need to be added.  The dates of breaks from most schools vary from year to year so as each year’s breaks are scheduled those dates would need to be added to the mapping table for this process to work over time.  With a little extra work, you can create a scheduled job on the driver to run at a reasonable interval like once a week or once a month that checks the dates in the mapping table and sends an email alert as the table data begins to reach its end,  Below is a sample rule for such a job:

This rule will check all values in the mapping table for rows with a Session_Active value to TRUE.  If the Session_End dates have been expired for more than 20 days or will expire in the next 20 days the rule sends an email from a template to a GCV based addressee notifying the recipient(s) that the mapping table data needs to managed to keep the expiration extension process working.

Other Scenarios

Based on the driver rule logic shared in this article other solutions can have similar logic applied.  Even though the driver rule checks real-time password expiration date changes and adjusts as needed a similar rule could be created for a scheduled job that could be manually run by an administrator before a given break to have the rule search the data store for any users who may still have an expiration date in the upcoming range so that it can be automatically extended.  This could work as a fail-safe in conjunction with the rule above to help ensure a few users as possible are impacted by an expired password during or following such a break.

For time based accounts like contractors or vendors who may have an account expiration date associated with their account a similar rule could validate the account expiration date and adjust it accordingly to prevent an account from being disabled while its sponsor or administrator is gone during a scheduled recess.

Conversely, additional security can be applied to accounts that may expire during these windows.  The driver logic could detect that an account was set to expire during a scheduled break and as a result it automatically creates a trigger within the IDM system to take additional actions on that account if/when the account expires during a scheduled break that may prevent the account from being activated or reset until the break was over.

Questions, comments or concerns? Feel free to reach out to us below, or email us at IDMWORKS to learn more about how you can protect your organization and customers.

Leave a Reply

Your email address will not be published. Required fields are marked *