\nUnderstanding Deletions in ILM<\/a>; however there is more that can be said on the subject of user accounts, for which an immediate delete is often not appropriate.<\/p>\n
This article shows how you can use ILM to configure a flexible deprovisioning solution that is customized to your technical, organizational and compliance needs.<\/p>\n
Account Deprovisioning Scenarios in this document<\/h2>\n
We are going to look at the following types of account deprovisioning:<\/p>\n
- \n
- Simple deletion<\/li>\n
- Disabling the account<\/li>\n
- Deleting the account on a time-delayed basis<\/li>\n
- Stopping ILM from managing the account without actually deleting it (disconnection)<\/li>\n<\/ol>\n
Parts to the Account Deprovisioning Puzzle<\/h2>\n
Depending on your needs, you will most likely have to piece together a number of different elements to achieve the desired result.<\/p>\n
Account Disabling:<\/strong><\/p>\n
Deactivating an object normally involves changing one or more of its attributes (eg.: setting userAccountControl on an AD user), and the usual way to do this is with an export attribute flow (EAF).<\/p>\n
See code example \u00e2\u20ac\u0153Disabling Flow Rules<\/a><\/em>\u00e2\u20ac\u009d below.<\/p>\n
Moving deactivated accounts:<\/strong><\/p>\n
- \n
- A common practice is to put disabled accounts in a particular place, such as a \u00e2\u20ac\u0153Disabled<\/em>\u00e2\u20ac\u009d OU.For AD this is a “Rename<\/em>” activity, and is typically done in the metaverse
\nextension code.<\/li>\n- For the \u00e2\u20ac\u0153Stop management<\/em>\u00e2\u20ac\u009d scenario it is also possible to move the account just prior to disconnecting it in the MA Extension Deprovision method.<\/li>\n<\/ul>\n
See code example \u00e2\u20ac\u0153Metaverse Deprovisioning<\/a><\/em>\u00e2\u20ac\u009d below.
\n\u00c2\u00a0<\/p>\nDeleting the connector space (CS) object:<\/strong><\/p>\n
- \n
- The first step to deleting an account is to delete the object that represents it in the connector space.This can happen in one of the following two ways:\n
- \n
- The joined Metaverse object is deleted<\/li>\n
- The joined Metaverse object was disconnected, either manually or by using the
\nCSEntry.Deprovision()<\/em> method in the
\nmetaverse extension code.<\/li>\n<\/ul>\n<\/li>\n- In both cases a deletion will only happen if the “Configure Deprovisioning<\/em>” tab on the MA configuration has been set as follows:\n
- \n
- \u00e2\u20ac\u0153Stage a delete on the object for the next export run<\/em>\u00e2\u20ac\u009d, or<\/li>\n
- \u00e2\u20ac\u0153Determine with a rules extension<\/em>\u00e2\u20ac\u009d AND the rules extension code returns
\nDeprovisionAction.Delete<\/em>.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n\u00c2\u00a0
\nSee code example \u00e2\u20ac\u0153MA Deprovision Sub<\/a><\/em>\u00e2\u20ac\u009d below
\n\u00c2\u00a0
\nSee \u00e2\u20ac\u0153Metaverse Deprovisioning<\/a><\/em>\u00e2\u20ac\u009d for an example of the CSEntry.Deprovision()<\/em> method.
\n\u00c2\u00a0<\/p>\nDeleting the account in the connected data source (CDS):<\/strong><\/p>\n
- \n
- To delete the actual object in the CDS, we must first delete the connector space object using the methods above, after which we should find an export of type \u00e2\u20ac\u0153delete<\/em>\u00e2\u20ac\u009d ready in the connector space.It is then just a matter of running an Export.\n
- \n
- Note that the account used by the MA must have permission to delete objects of this type in the CDS.<\/li>\n
- Note also that if the MA is of type \u00e2\u20ac\u0153Extensible Connectivity\u00e2\u20ac\u009d you must write a Delete method in the Connected Data Source extension (see example below).<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
\u00c2\u00a0
\nSee code example \u00e2\u20ac\u0153XMA Delete Method<\/a>\u00e2\u20ac\u009d below.
\n\u00c2\u00a0<\/p>\nTime dependant deletion:<\/strong><\/p>\n
- \n
- Sometimes you want to delete an object on a certain date \u00e2\u20ac\u201c perhaps an expiration date, or 3 months after the account was disabled.To do this you need the date available on the Metaverse object, which means you have to flow it into the Metaverse from somewhere.\n
- \n
- An example for AD accounts is to use a spare attribute on the account, such as info or one of the extensionAttributes, to write the date at the same time as you disable the account.Flow this value back into the Metaverse and the information will be available.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
\u00c2\u00a0
\nSee code example \u00e2\u20ac\u0153Metaverse Deprovisioning<\/a>\u00e2\u20ac\u009d below.
\n\u00c2\u00a0<\/p>\nDeprovisioning Scenarios<\/h2>\n
Simple Deprovision based on disappearance<\/h3>\n
The simplest deprovisioning scenario, and the one that can be executed without writing any code, is the \u00e2\u20ac\u0153disappearance\u00e2\u20ac\u009d scenario.<\/p>\n
Here an object (or database line, or text file line) disappears from a source MA and is imported as a delete.<\/p>\n
In the Metaverse we have configured our Object Deletion Rule as \u00e2\u20ac\u0153Delete Metaverse object when connector from this management agent is disconnected<\/em>\u00e2\u20ac\u009d and selected our source MA.<\/p>\n
Finally we have configured our other MAs to delete the CS objects when the Metaverse object is deleted.<\/p>\n
In this way we could, for example, delete an AD account because the person\u00e2\u20ac\u2122s record disappeared from the HR data source.<\/p>\n
Caution: This method may lead to unexpected loss of accounts, temper and job!<\/strong><\/p><\/blockquote>\n
As a general rule, it is a bad idea to make destructive decisions based on an absence of information. All sorts of errors, both human and machine, could happen to cause data to be unavailable at the time an Import runs. If you do use this simple approach, only use it for low-priority objects that can be deleted and recreated without much impact.<\/p>\n
Deprovision based on attribute change<\/h3>\n
It is a much better practice to make deprovisioning decisions based on positive data.<\/p>\n
So, with the HR data source, we continue to import resigned people, but with a status flag that indicates they are now inactive.<\/p>\n
We then write some code in the metaverse extension which reacts to the person\u00e2\u20ac\u2122s \u00e2\u20ac\u0153inactive\u00e2\u20ac\u009d status.<\/p>\n
The great advantage to this method is the flexibility it gives us.<\/p>\n
For example, we may deal with the person\u00e2\u20ac\u2122s connected objects in different ways, deleting contacts and application accounts immediately
\nbut, just disabling the AD user account until further notice.<\/p>\nDeprovisioning a connector space object from metaverse extension code is trivial \u00e2\u20ac\u201c all you have to do is add the line<\/p>\n
CSEntry.Deprovision()<\/em><\/p>\n
The bulk of the code before this will be spent in testing attribute values, and connections to different MAs, to determine when conditions are right to issue this command.<\/p>\n
Disable then delete<\/h3>\n
It is simple enough to disable an account using an EAF (see example \u00e2\u20ac\u0153Disabling Flow Rules<\/a>\u00e2\u20ac\u009d below).<\/p>\n
You could also move the account to a special location (see example \u00e2\u20ac\u0153Metaverse Deprovisioning<\/a>\u00e2\u20ac\u009d below).<\/p>\n
However what do you do if you want to remove the account at some point in the future?<\/p>\n
The first thing to be aware of is you must not delete the metaverse object.<\/p>\n
To be able to delete the disabled account in the future it has to be connected to something in the
\nmetaverse.<\/p>\nILM can only manage connectors.<\/p>\n
Next, you will need some kind of datestamp<\/em> on the metaverse object so your
\nmetaverse extension code will know when it\u00e2\u20ac\u2122s OK to delete the account.<\/p>\nThe only way to write a value to a metaverse object is with an IAF \u00e2\u20ac\u201c so this implies writing the
\ndatestamp<\/em> outside ILM, on a CDS object, and then importing it back in.<\/p>\nThe method in the code examples below works like this:<\/p>\n
- \n
- Based on the status attribute in the Metaverse, I export the userAccountControl<\/em> to disable the AD user account,<\/li>\n
- Based on the same rules, I also export today\u00e2\u20ac\u2122s date to the user\u00e2\u20ac\u2122s info attribute,<\/li>\n
- II import info back to a metaverse attribute called disableDate<\/em>,<\/li>\n
- I can then use disableDate<\/em> in my metaverse extension to decide when the time is right to issue a CSEntry.Deprovision().<\/li>\n<\/ol>\n
There are a couple of points to note about this method:<\/p>\n
- \n
- While disables will happen on a delta sync, deletions will only happen on a
\nfull sync.<\/li>\n - The CDS attribute used to hold the date could be modified in the CDS (though you can use this to your advantage if you want to extend the disabled life of an account).<\/li>\n<\/ul>\n
Stop Managing an Object<\/h3>\n
In some cases object deletion is handled in the CDS itself and all you need to do is to stop managing the object.<\/p>\n
In ILM terminology the object becomes a \u00e2\u20ac\u0153disconnector\u00e2\u20ac\u009d and, while it may still exist in the MA\u00e2\u20ac\u2122s connector space, it is no longer connected to a Metaverse object, and ILM can no longer impact it in any way.<\/p>\n
To disconnect rather than delete you actually use exactly the same CSEntry.Deprovision() method, but with the correct option selected on your MA\u00e2\u20ac\u2122s Configure Deprovisioning page.<\/p>\n
You could choose to:<\/p>\n
- \n
- \u00e2\u20ac\u0153Make them disconnectors\u00e2\u20ac\u009d. The object is disconnected but remains in the CS and CDS.It will be reassessed for possible joins at each Full Sync,<\/li>\n
- \u00e2\u20ac\u0153Make them explicit disconnectors\u00e2\u20ac\u009d.Like the above, but it will not be reassessed for possible joins, or<\/li>\n
- Decide with a Rule Extension (see example \u00e2\u20ac\u0153MA Deprovision Sub<\/a>\u00e2\u20ac\u009d below).<\/li>\n<\/ul>\n
The \u00e2\u20ac\u0153explicit\u00e2\u20ac\u009d option needs a bit more discussion.<\/p>\n
If ever you delete and re-import the CS all \u00e2\u20ac\u0153explicit<\/em>\u00e2\u20ac\u009d tags will be lost and the objects become regular disconnectors again, and available for joins.<\/p>\n
This option should only be chosen in particular circumstances, such as when there is a regular and reliable deletion of redundant objects happening in the CDS.<\/p>\n
If you are sure that you will not need to rejoin to an object once it has been disconnected then another idea is to export a blocking attribute before disconnecting.<\/p>\n
For example you export the string \u00e2\u20ac\u0153Unmanaged<\/em>\u00e2\u20ac\u009d to an attribute on the CDS object, and only disconnect it once the attribute value is confirmed.<\/p>\n
You can then use this attribute in a Connection Filter to prevent future re-connections.<\/p>\n
Some Common Problems and Questions<\/h2>\n
I staged some Deletes but I don\u00e2\u20ac\u2122t want to export them now<\/h3>\n
Perhaps there was an error in your code or your import data and you have a bunch of Deletes waiting to go out \u00e2\u20ac\u201c but you really don\u00e2\u20ac\u2122t want to do that!<\/p>\n
Even after correcting the code and re-syncing you may find they turn into Delete-Adds \u00e2\u20ac\u201c these should also not be exported as the actual CDS objects will be deleted and recreated \u00e2\u20ac\u201c not great for AD accounts!<\/p>\n
Unfortunately, the only full-proof fix in this case is a delete and re-import of the connector space.<\/p>\n
I have some old accounts with no HR reference \u00e2\u20ac\u201c will ILM delete them?<\/h3>\n
ILM can only delete objects that it is connected to, so if it never connected to the object it can never delete it.<\/p>\n
If you plan to tidy up unmanaged objects in your CDS then have a look at the tool csexport.exe (from the MIIS\\bin folder) which can be used to export lists of disconnectors.<\/p>\n
How can I block an Export if there are too many Disables?<\/h3>\n
The Export run profile contains an option to stop the job if there are more than a certain number of Deletes queued to go out.<\/p>\n
Unfortunately it is not possible to do something similar for disables with native functionality.<\/p>\n
If something like this is needed then it should be possible to increment a count in a file from the EAF which deactivates the account, and then modify the script which runs the Export profile to first check the count.<\/p>\n
Sideways Joins<\/h3>\n
A scenario you need to watch out for is what I call a \u00e2\u20ac\u0153sideways join<\/em>\u00e2\u20ac\u009d.<\/p>\n
Take a situation where the \u00e2\u20ac\u0153person<\/em>\u00e2\u20ac\u009d object type has one source MA (eg.: HR) and multiple target MAs (AD, Notes, some other applications).<\/p>\n
The source object has been deleted, but one or more of the target objects have remained and are still joined to a
\nmetaverse object.<\/p>\nThe problem here is that these objects won\u00e2\u20ac\u2122t show up in lists of disconnectors and so can remain, unobserved, for some time.<\/p>\n
If deprovisioning logic is based on a value from the source MA then, in a default configuration, this value would have been recalled and is no longer present on the Metaverse object \u00e2\u20ac\u201c so your code is probably just skipping it.<\/p>\n
When writing your metaverse extension code, it is a good idea to test for unexpected situations \u00e2\u20ac\u201c like an object with no connector in the primary source MA \u00e2\u20ac\u201c and then throw an error or otherwise deal with the object.<\/p>\n
I can see Deletes staged in the connector space, but the objects don\u00e2\u20ac\u2122t get deleted in the external system<\/h3>\n
First, look for error messages in Identity Manager and in the Event Log that may indicate the problem.<\/p>\n
Make sure the account used by the MA has the correct permissions in the CDS.<\/p>\n
If it\u00e2\u20ac\u2122s an \u00e2\u20ac\u0153Extensible Connectivity<\/em>\u00e2\u20ac\u009d MA, check that a Delete method has been written in the Connected Data Source Extension.<\/p>\n
I disabled an AD user \u00e2\u20ac\u201c now how do I remove it from groups?<\/h3>\n
This is one with no short answer.<\/p>\n
You cannot manage the memberOf<\/em> attribute on AD users as it is a backlinked attribute.<\/p>\n
So group membership can only be managed through the member attribute of groups.<\/p>\n
This is fine if you are already managing AD groups with ILM \u00e2\u20ac\u201c but not ok if they are managed manually in AD.<\/p>\n
One of the reasons to keep an account in a disabled state for a while is to allow it to be restored quickly with all its previous rights intact \u00e2\u20ac\u201c so removing it from groups may not be the best idea anyway.<\/p>\n
If it is necessary then the choices are to fully take over group management with ILM, or to write a script that removes disabled users from groups, and is run outside of ILM.<\/p>\n
Code Examples<\/h2>\n
MA Deprovision Sub<\/h3>\n
In<\/a> this example, when the Metaverse object is deleted or disconnected, accounts in the \u00e2\u20ac\u0153Student<\/em>\u00e2\u20ac\u009d OU are deleted while accounts in the \u00e2\u20ac\u0153Staff<\/em>\u00e2\u20ac\u009d OU become disconnectors.<\/p>\n
This sub is located in the Management Agent Extension code.<\/p>\n
Public Function Deprovision(ByVal csentry As CSEntry) As DeprovisionAction Implements IMASynchronization.Deprovision\r\n If csentry.DN.ToString.Contains(\"OU=Students\") Then\r\n Return DeprovisionAction.Delete\r\n ElseIf csentry.DN.ToString.Contains(\"OU=Staff\") Then\r\n ' Optionally, rename the cs object or change attributes\r\n ' just prior to disconnecting\r\n Return DeprovisionAction.Disconnect\r\n Else\r\n Throw New UnexpectedDataException(\"DN does not contain \" _\r\n & \"'OU=Staff' or 'OU=Students' so I don't know \" _\r\n & \"which deprovision action to perform.\")\r\n End If\r\nEnd Function<\/pre>\n
Metaverse Deprovisioning<\/h3>\n
In<\/a> this example we use the user\u00e2\u20ac\u2122s status attribute in the Metaverse to decide if the account should be moved to a \u00e2\u20ac\u0153Disabled<\/em>\u00e2\u20ac\u009d OU.<\/p>\n
(The actual account disabling is done by an EAF and the disableDate<\/em> and
\nuserAccountControl<\/em> are flowed back by IAFs \u00e2\u20ac\u201c see below.)<\/p>\nWe then use the disableDate<\/em> attribute on the metaverse object to decide when to perform the final deletion.<\/p>\n
This example subroutine has been called from Sub Provision<\/em> which is located in the Metaverse Extension code.<\/p>\n
Private Sub User_Provisioning(ByVal mventry As MVEntry)\r\n Dim ADMA As ConnectedMA = mventry.ConnectedMAs(\"MyDomain\")\r\n Dim expectedDN As ReferenceValue\r\n Dim ShouldExist As Boolean\r\n Dim DoesExist As Boolean\r\n Const OU_USERS As String = \"OU=Users,OU=MyOrg,DC=mydomain,DC=com\"\r\n Const OU_DISABLED As String = \"OU=Disabled,OU=Users,OU=MyOrg,DC=mydomain,DC=com\"\r\n Const KEEP_DISABLED_DAYS As Integer = 90\r\n\r\n '' Should the account exist?\r\n '' Inactive accounts should exist for KEEP_DISABLED_DAYS after being disabled.\r\n If mventry(\"status\").IsPresent AndAlso mventry(\"status\").StringValue = \"Active\" Then\r\n ShouldExist = True\r\n Else\r\n ShouldExist = False\r\n\r\n If MVEntry(\"userAccountControl\").IsPresent AndAlso _\r\n MVEntry(\"disableDate\").IsPresent Then\r\n\r\n If (MVEntry(\"userAccountControl\").IntegerValue And ADS_UF_ACCOUNTDISABLE) = _\r\n ADS_UF_ACCOUNTDISABLE Then\r\n\r\n 'Account disabled \u00e2\u20ac\u201c allow to exist until deletion date\r\n ShouldExist = True\r\n\r\n Dim disabledDate As DateTime\r\n disabledDate = Convert.ToDateTime(MVEntry(\"disableDate\").StringValue)\r\n If Now.Subtract(disabledDate).Days > KEEP_DISABLED_DAYS Then\r\n ShouldExist = False\r\n End If\r\n Else\r\n 'Account enabled\r\n ShouldExist = True\r\n End If\r\n End If\r\n End If\r\n '' Check if the AD account already exists\r\n Select Case ADMA.Connectors.Count\r\n Case 0\r\n DoesExist = False\r\n Case 1\r\n DoesExist = True\r\n Case Else\r\n Throw New UnexpectedDataException(\"Multiple connectors in MA \" & ADMA.Name)\r\n End Select\r\n\r\n '' Generate the expected DN for the user - to use in renaming or moving\r\n Dim RDN As String = \"CN=\" & mventry(\"displayName\").StringValue\r\n\r\n If mventry(\"status\").StringValue = \"Active\" Then\r\n expectedDN = ADMA.EscapeDNComponent(RDN).Concat(OU_USERS)\r\n Else\r\n expectedDN = ADMA.EscapeDNComponent(RDN).Concat(OU_DISABLED)\r\n End If\r\n\r\n '' Take action based on values of ShouldExist and DoesExist\r\n\r\n If ShouldExist And DoesExist Then\r\n 'Check if account should be renamed or moved\r\n Dim CSEntry As CSEntry = ADMA.Connectors.ByIndex(0)\r\n If CSEntry.DN.ToString.ToLower <> expectedDN.ToString.ToLower Then\r\n CSEntry.DN = expectedDN\r\n End If\r\n\r\n ElseIf ShouldExist And Not DoesExist Then\r\n 'Provision Account\r\n <...>\r\n\r\n ElseIf Not ShouldExist And DoesExist Then\r\n 'Deprovision Account\r\n CSEntry.Deprovision()\r\n\r\n End If\r\n End Sub<\/pre>\n
Disabling Flow Rules<\/h3>\n
With<\/a> these flow rules I disable an AD account and also write a date onto the object (I\u00e2\u20ac\u2122m using info but you can use any free attribute) to indicate when it was disabled.<\/p>\n
I also flow userAccountControl<\/em> and info back into the metaverse so I have access to the values in my
\nmetaverse extension code (above).<\/p>\n![\"\"](\"http:\/\/public.bay.livefilestore.com\/y1p--wnV_K-shH6tRb6q_v9QW6CK8ju5SvYrGmyGW6MnVhzsHhYziWODyCHvP4kcrnF3HUmReTUud6NEi7hpFdUXw\/DP01.jpg\")
<\/p>\nPublic Sub MapAttributesForExport(ByVal FlowRuleName As String, ByVal mventry As MVEntry, ByVal csentry As CSEntry) Implements IMASynchronization.MapAttributesForExport\r\n\r\n Const ADS_UF_NORMAL_ACCOUNT As Long = &H200\r\n Const ADS_UF_ACCOUNTDISABLE As Long = &H2\r\n\r\n Select Case FlowRuleName\r\n\r\n Case \"export_userAccountControl\"\r\n Dim currentValue As Long\r\n\r\n If csentry(\"userAccountControl\").IsPresent Then\r\n currentValue = csentry(\"userAccountControl\").IntegerValue\r\n Else\r\n currentValue = ADS_UF_NORMAL_ACCOUNT\r\n End If\r\n\r\n If mventry(\"status\").IsPresent AndAlso mventry(\"status\").Value = \"Active\" Then\r\n ' Enable account\r\n csentry(\"userAccountControl\").IntegerValue = _\r\n (currentValue Or ADS_UF_NORMAL_ACCOUNT) And (Not ADS_UF_ACCOUNTDISABLE)\r\n\r\n Else\r\n ' Disable account\r\n csentry(\"userAccountControl\").IntegerValue = _\r\n currentValue Or ADS_UF_ACCOUNTDISABLE\r\n End If\r\n\r\n Case \"export_info\"\r\n If mventry(\"status\").IsPresent AndAlso mventry(\"status\").Value = \"Active\" _\r\n AndAlso csentry(\"info\").IsPresent Then\r\n csentry(\"info\").Delete()\r\n ElseIf mventry(\"status\").Value = \"Inactive\" AndAlso _\r\n Not csentry(\"info\").IsPresent Then\r\n csentry(\"info\").StringValue = Now.ToString\r\n End If\r\n\r\n End Select\r\nEnd Sub<\/pre>\n
XMA Delete Method<\/h3>\n
- Based on the status attribute in the Metaverse, I export the userAccountControl<\/em> to disable the AD user account,<\/li>\n
- An example for AD accounts is to use a spare attribute on the account, such as info or one of the extensionAttributes, to write the date at the same time as you disable the account.Flow this value back into the Metaverse and the information will be available.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
- Sometimes you want to delete an object on a certain date \u00e2\u20ac\u201c perhaps an expiration date, or 3 months after the account was disabled.To do this you need the date available on the Metaverse object, which means you have to flow it into the Metaverse from somewhere.\n
- \u00e2\u20ac\u0153Determine with a rules extension<\/em>\u00e2\u20ac\u009d AND the rules extension code returns
- In both cases a deletion will only happen if the “Configure Deprovisioning<\/em>” tab on the MA configuration has been set as follows:\n
- For the \u00e2\u20ac\u0153Stop management<\/em>\u00e2\u20ac\u009d scenario it is also possible to move the account just prior to disconnecting it in the MA Extension Deprovision method.<\/li>\n<\/ul>\n
- A common practice is to put disabled accounts in a particular place, such as a \u00e2\u20ac\u0153Disabled<\/em>\u00e2\u20ac\u009d OU.For AD this is a “Rename<\/em>” activity, and is typically done in the metaverse