Problem overview
One of the most common use-cases that need to be solved for our clients is the Re-Hire use case. In the medical industry, this is especially prevalent due to the changes in the industry as a result of COVID and nurses moving from hospital to hospital to meet the demand. These became known as “Traveling Nurses” because they could work for a hospital on a six month contract, leave for another six-months, and then be re-hired. Of course, the Re-Hire use cases is not unique to the medical environment and this is just one example that outlines the importance of dealing with the situation.
So what happens when a person is re-hired and needs to have their Active Directory account re-assigned to them? That depends on a number of conditions, including the client policy on Re-Hired users and their Active Directory retention requirements. Some possible solutions are:
- The Active Directory account has been deleted and needs to be re-created
- The Active Directory account has not been deleted and remains correlated to an Identity that was re-hired within the Identity data retention window (e.g. with the last six months)
But what if the user was re-hired outside the Identity data retention window but still wants the same Active Directory account and that account was not deleted (due to Active Directory retention requirements) and remains uncorrelated? Well, SailPoint has a documented account correlation rule for that exact use case.
Correlating the Active Directory account
The account correlation rule is applied to the Identity source, it looks up searchable Active Directory attribute values to match the “new” (Re-Hired) record to, and correlates the Identity to the Active Directory account, and the Re-Hired user now has their previous account. This process is the opposite of what happens when an Active Directory aggregation (with disableOptimization = true) occurs where the AD account correlates to the Identity. This can happen because even though it is an uncorrelated account, the Active Directory account is part of its own “Unregistered” Identity Cube:
Benefits of this approach:
- Identities are correlated to the Active Directory account containing the Re-Hired person’s unique ID
- Active Directory Birthright Role does not create a new accounts for the user
- SailPoint-documented rule requiring little modification
Drawbacks of this approach:
- Account Correlation rule is cloud-based and must be deployed by Expert Services (a paid service)
- Not extensible to multiple sources
Implementing the rule
This cloud correlation rule requires slight modification in order to utilize in your environment. This include updating the ID values for your AD Source as well as the name of the searchable attribute that contains all of your Active Directory account names. Once deployed through an Expert Services request (as required for all cloud rules), this correlation rule should be applied to the Identity Source and not on Active Directory itself. The rule can be applied using the PATCH /v3/sources/[HR Source ID] API
[
{
"op": "replace",
"path": "/accountCorrelationRule",
"value": [
{
"type": "RULE",
"id":"fe65756c29974a8d9920f56114e1ff9f",
"name": "HR Correlation Rule"
}
]
}
]
The name and ID for the rule can be found using the /beta/sp-config endpoint with the following body:
{
"description": "Export all Rules",
"includeTypes": [
"RULE"
],
"objectOptions": {}
}
Tools such as VS-Code offer similar functionality.
With this in place, when the re-hired account is aggregated, the correlation takes place immediately - before any Birthright Roles trigger new account creations as required.
Correlating existing accounts
We have the Active Directory account taken care of for the Re-Hired user, but there are other existing accounts that also need to be correlated to the re-hired user and the approach above is not extensible to multiple sources. Epic is an application common in the medical industry and their accounts are not ever deleted for medical data retention requirements and you can see the effect of using the above solution below:
So what can be done in a Re-Hire scenario when we have these two accounts that we want attached to the same Identity cube? Rather than using the above rule (which can correlate only a single account), an Identity Profile can be created for Uncorrelated Active Directory accounts. This Identity Profile needs to have the following fields defined, at a minimum:
uid: Active Directory - sAMAccountName)sn(Active Directory - sn)givenName(Active Directory - givenName)email(Active Directory - mail + transform, if required).
Once these are created, correlation settings or rules can be used to associate the Epic account with the newly created Identity’s uid field. This leads to a standalone Identity that can be correlated with the HR record (again, using the uid field) once it is re-activated and the accounts are all correlated to a single Identity.
Benefits of this approach:
- Extensible to multiple sources
- Uses out-of-the-box correlation logic to combine Identities
- Active Directory and Epic Birthright Roles do not create a new accounts for the user
- No cloud rule is required
Drawbacks of this approach:
- A material increase in the number of Identities can occur, leading to a licensing cost change
- Not extensible to multiple sources
Conclusion
In summary, there are different ways to correlate existing accounts to a re-hired user. But in the case of multiple accounts being correlated to a rehired Identity, creating Identities from orphaned accounts can be a simple and reliable way to create a bundle of all of that re-hired user’s accounts.