I recently worked on a project where the client had some users who may not be logging into their accounts for 6 months or more, but their corporate policy was to disable accounts that had been dormant for more than 3 months.
In order to allow these users to log in, they needed a mechanism to allow users to re-enable the accounts themselves in a secure manner. To solve this, we decided that a user who successfully answers the security questions in the self-service password reset portal should not only be able to reset his password, but that action should re-enable the account in AD.
To accomplish this, we wrote a custom workflow activity that is called whenever the Gate Data on the Gate Registration object is modified.
The custom workflow activity design looks like this:
When a password reset is issued, the incoming request target is the gate registration object. This contains a value “UserID” that is the Resource ID of the user.
In order to update the user in AD via an LDAP call, we need the user’s sAMAccountName. So, the first read resource activity is used to read the UserID for the user from the Gate Registration object and that is passed to the second read resource activity to look up the user’s sAMAccountName.
Here is the code to get the UserID:
In our system, the portal object has an attribute, “EmployeeStatus” to let us check if a user is terminated before attempting to issue the LDAP call to update the user’s userAccountControl in AD.
In order to issue the LDAP call, this activity has configurable properties for the LDAP path, ADMA account name and encrypted password. These are used in the LDAP call as follows:
