Taking time to rehash all the reasons why identity management (IDM) is really, really, really important is great, but not today. There are way to many studies done that show the value that good IDM provides. If you do need to make yourself familiar with the well agreed upon benefits take a look at: http://www.microsoft.com/technet/security/guidance/identitymanagement/idmanage/P1Fund_1.mspx?mfr=true. No, I'm not going to type another rant about how bad you need IDM; this time I want to talk to the individuals that have an IDM solution, but are concerned about how to start.
I recently got a call from a buddy of mine who was concerned that after putting ILM in place he found some very startling numbers.
# of users in HR system: <5,000
# of e-mail accounts in mail system: 5,120
# of user accounts in AD: 8,367
The numbers, to say the least, are very concerning. The first question I had was: who has permissions to create accounts in AD? The second was: What is the company policy around account creation? After going back and forth about how the numbers could be bogus, we both concluded that there were over 8,300 user accounts in AD and that SOMETHING had to be done.
Many enterprises hit this same snag after implementing an IDM solution so I figured this would be a great topic to blog about! WARNING!! The following information is focused on ILM, but some of the concepts can be translated to others.
The approach used in the above scenario was three stepped:
1.) reconcile the <5,000 accounts in HR with AD
2.) identity any service or non-user accounts
3.) disable and move the rest
Reconciling with HR
In ILM, “Join Rules” are used to reconcile existing accounts across many connected data systems. Join Rules are used to link metaverse (MV) objects to connector space (CS) objects. There are two main parts to a Join Rule – resolution and search criteria. The search criteria is what is used to compare CS objects to MV objects.
Screen Shot: Join Rule definition screen
While most enterprises have a unique attribute to identify users, few have wide adoption of the unique key across some of the de-centralized departments. This is one of the strengths of Join Rules, the “Add Condition” only needs to be unique between the connected data system and the metaverse. However, you do need to get enough attributes for the user to allow proper resolution from other connected systems. In the above scenario we were able to use two mappings:
1.) SamAccountName => EmployeeID
2.) DisplayName => DisplayName
With two rules we were able to reconcile all but fifty HR accounts (which we later learned that the users were new hires or individuals who are not granted network access). This left around 120 accounts that are mail-enabled, but don’t map to a HR record. Using a MA extension we made a call to AD and pulled the ACL information on the objects (using a sample from http://msdn.microsoft.com/en-us/library/aa706128(VS.85).aspx).
' Get the security descriptor.
Dim x As IADs
Dim sd As IADsSecurityDescriptor
On Error GoTo Cleanup
Set x = GetObject("LDAP://DC=Fabrikam,DC=com")
Set sd = x.Get("ntSecurityDescriptor")
Debug.Print sd.Control
Debug.Print sd.Group
Debug.Print sd.Owner
Debug.Print sd.Revision
Cleanup:
If (Err.Number<>0) Then
MsgBox("An error has occurred. " & Err.Number)
End If
Set x = Nothing
Set sd = Nothing
Based on the information from the Owner field of sd, we were able to chase down a few administrative users that proved to be the top offenders.
Identifying Service Accounts
Finding the service accounts was simple using the steps here: http://technet.microsoft.com/en-us/library/cc772916.aspx.
Disable and Move the Rest
The remaining users (>2,700) we termed “Secret Identities”. While some people within the organization were fine with having these accounts lingering about, after a 14 hour political fight my buddy was able to convince the “powers that be” to allow a disable/rename/removal process. I attended some of the meetings, and I loved the quote from the top security officer of the organization: “Super heroes need secret identities; our users DO NOT!”
Using a MV extension we put a few lines of temporary code in-place to allow for non-joined, non-service accounts to be disabled and moved.
void IMVSynchronization.Provision (MVEntry mventry)
{
const long ADS_UF_NORMAL_ACCOUNT = 0x0200; // Typical user account
const long PASSWD_NOTREQD = 0x0020;
const long ADS_UF_ACCOUNTDISABLE = 0x0002; // Disable user account
numHRConnectors = HRMA.Connectors.Count;
If (0 == numHRConnectors) Then
csentry["userAccountControl"].IntegerValue = ADS_UF_ACCOUNTDISABLE;
csentry.DN = “cn=” + mventry[“employeeID”].value + “,ou=secret users,dc=Fabrikam,dc=edu”;
Done! All the secret identities were moved and disabled during the next MA run cycle.
