Provisioning with Microsoft Identity Lifecycle Manager 2007

A Technical Overview by Oxford Computer Group (www.oxfordcomputergroup.com )

Provisioning with ILM 2007 a technical overview by OCG

Page 1 of 23

Introduction
One of the major benefits of an Identity Management strategy is the ability to automatically create new user accounts in Network Operating System (NOS) directories, email servers, LDAP directories, databases, or any other accessible data sources. This creation process is known as provisioning, and its converse, deletion of accounts, is known as deprovisioning. The benefits of having automated provisioning and deprovisioning are immediate and compelling: there is a clear reduction in administration overhead because a lot of manual effort is eliminated, security is enhanced because accounts are deleted or suspended reliably when an individual leaves the organization or loses rights to resources, and the user experience is enhanced because users are given access to required resources in a timely manner. Identity Lifecycle Manager (ILM) 2007 (along with its predecessor MIIS 2003) is a reliable synchronization engine, that can provision and deprovision accounts in any connected data store that provides some kind of API, or that can exchange data via some file-based process. Out of the box it supports Active Directory, Exchange, SQL Server and many other directories and databases, and custom extensions can be created for handling those directories and databases not provided for out of the box. So for example, if a new user is added to an HR database running on SQL server, ILM can be configured to import it and provision accounts in other systems (like Active Directory) as necessary. This paper is for new and potential new users of ILM 2007 wanting to understand more about provisioning and deprovisioning specifically how to configure ILM to add and delete accounts in connected directories. As such, the paper assumes that readers have at least a basic understanding of ILM and ILM terminology (such as as Metaverse, Connector Space, and Management Agent). Readers who are not familiar with such terminology should read our introductory ILM 2007 White Paper available from the Oxford Computer Group website (http://www.oxfordcomputergroup.com).

Provisioning with ILM 2007 a technical overview by OCG

Page 2 of 23

Contents
Introduction ............................................................................................................................2 Contents..................................................................................................................................3 ILM 2007 Provisioning Concepts..............................................................................................4 The MA Run Cycle................................................................................................................4 Other Scenarios................................................................................................................5 Enabling Provisioning ..........................................................................................................5 Rules Extensions .................................................................................................................6 Types of Rules Extension .................................................................................................6 Developing a Metaverse Rules Extension for Provisioning ......................................................8 Creating an Extension .........................................................................................................8 Metaverse Extension Methods ............................................................................................9 IMVSynchronization.Initialize............................................................................................9 IMVSynchronization.Terminate.........................................................................................9 IMVSynchronization.Provision...........................................................................................9 IMVSynchronization.ShouldDeleteFromMV.....................................................................10 Basic Steps in Provisioning ...............................................................................................10 Provisioning Scenarios ......................................................................................................12 File Based System..........................................................................................................12 Provisioning to Active Directory .....................................................................................15 Deprovisioning .....................................................................................................................19 Conclusion.............................................................................................................................21 Glossary ...............................................................................................................................22 Further Reading ....................................................................................................................23

Provisioning with ILM 2007 a technical overview by OCG

Page 3 of 23

ILM 2007 Provisioning Concepts

The MA Run Cycle
In an ILM implementation, we have a Management Agent (MA) for each connected data source. This MA connects to that source, and also manages the import, synchronization, and export for it as well. We can think of there being a section of the Connector Space (CS) for each MA, corresponding to each connected data source. ILM works on a batch process basis, which means that periodically it will perform some or all of the following operations: An import run for each MA, so that we import the latest changes from each source, which updates CS objects A synchronization run for each MA, so that changes are flowed into the Metaverse, and as part of the same synchronization process, changes in the Metaverse trigger outbound activity, which exports changes to other CS objects (ready for export) An export run for each MA so that changes are exported as required to the data sources (which are really target systems at this stage)

The cycle then starts all over again, with exports being confirmed as part of the next import run. This is a simplified view of the process: not every MA requires an import run, not every MA requires an export run, and the order in which we do all of this might need to be different than what weve described here. The above process applies not only to attribute flow, but also to object flow. From an ILM perspective, provisioning is simply the action of creating new objects in that part of the Connector Space that belongs to the correct MA, ready for export. During the next export run of that MA, a new account (a new object) will be created that corresponds to the connector space object. Similarly, deprovisioning is the marking of a CS object for deletion, ready for export to the connected data source, where the actual account deletion will take place (this will then be confirmed during the next import run). Typically, there will be a Management Agent connected to a data source that is authoritative for new account creation very often this is an HR database or enterprise directory. When new entries are created in this source, they are imported and synchronized, thus creating a new Metaverse object (this is called projection). If provisioning is enabled, code will also run which will create the new CS objects as required; these are pending exports that are ready to be exported to the associated sources. This effectively sets up the pipe-work we need, so that during subsequent synchronization, attributes can flow as required both into and out of the source concerned. Note that a CS object that is connected to a Metaverse object (usually the case) is called a connector. A CS object that is not connected to a Metaverse object (perhaps because it has been imported but not yet been connected to one, nor projected a new one, or has become disconnected from one) is called a disconnector. Here is a simple example of a run cycle:

Provisioning with ILM 2007 a technical overview by OCG

Page 4 of 23

1.

A new user entry is entered manually into the HR database.

2

Metadirectory (SQL Server Store) CS Metaverse

2. The HR database MA runs in 1 import mode and discovers the new entry. A new object is created in HR the HR MA connector space.

3. The HR MA runs in 3 4 synchronization mode, and as it is configured to project new connectors into the AD Metaverse, a new Metaverse object is 5 created that corresponds to the new connector. As ILM is configured for provisioning, the provisioning code runs and a new pending export is created in the Active Directory MA connector space. 4. A new Active Directory user account is created the next time the Active Directory MA runs in Export mode. 5. During the next import run which may or may not be immediately the new object will be confirmed (and any required AD-generated attributes will be imported maybe an email address). Deprovisioning could simply be the opposite sequence, starting with the manual deletion of the HR database entry. More often, no actual deletion takes place in the HR system, but a status attribute is set to indicate termination; depending upon the business rules in place, our code can decide whether the account concerned should be deleted, or disabled and/or moved to a different OU, or disabled then later deleted, or whatever.

Other Scenarios
Another scenario is a central provisioning management system where accounts are authorized. Rather than ILM simply responding to the creation of one object by provisioning others, there could be a manual authorization step. Microsoft has produced Active Directory Lightweight Directory Services (ADLDS formerly ADAM) as a suitable store against which to develop this kind of system. ADLDS should perhaps be the subject of another paper! Yet another scenario is where no single MA is authoritative, but each is authoritative for its own Metaverse entries. This sort of scenario is common where, for instance, multiple email systems are using ILM for address book synchronization. Another common setup is where an HR system exists for employees, another system for contractors, another for students (an enrolment systems, perhaps), and so on.

Enabling Provisioning
It is important to realise that provisioning is not enabled by default in ILM. It is possible to create and configure MAs that project new Metaverse entries, and flow attributes between

Provisioning with ILM 2007 a technical overview by OCG

Page 5 of 23

joined data sources, without the provisioning of new accounts into connected data sources. As long as there is a join between connected directory entries and Metaverse entries, attribute flow will take place in both directions: export and import. Enabling provisioning requires the deliberate intervention by an administrator via the Identity Manager console, and the creation of a Metaverse rules extension in other words, you need to write code to control the provisioning process. The following shows how to enable provisioning, but we strongly recommend that you dont do this until you have a thorough understanding of rules extensions! In the Identity Manager, from the Tools menu, select Options. This brings up a dialog. To enable provisioning: 1. Check Enable Metaverse rules extension check-box 2. Click Create Provisioning Rules Extension 3. Choose between Visual Basic .NET or Visual C# .NET (your choice) 4. If you have Visual Studio .NET installed, it will be invoked and a new Metaverse rules project framework will be built 5. Edit the rules extension (discussed below) as required, build the project and close Visual Studio .NET 6. Make sure that the new rules extension name MVExtension.dll appears in the Rules extension name window and click OK.

Rules Extensions
Rules extensions are dynamic link libraries (.dlls) used with MAs and the Metaverse to extend functionality. For example, a rule extension may be used to combine data from two source attributes from a connected directory (such as sn and givenName) and flow them to one Metaverse attribute (such as displayName). In this case, this would be a MA rules extension and would run appropriately when the MA runs. Rules extensions are created by using programming languages such as Microsoft Visual Basic .NET or C# (actually anything that will generate a DLL correctly).

Types of Rules Extension Management Agent

A Management Agent rules extension is applied at various points during a synchronization run. Each MA has (at most) one rules extension. MA rules include:

Provisioning with ILM 2007 a technical overview by OCG

Page 6 of 23

Connector filter rules Join rules Projection rules Attribute flow rules Deprovisioning rules

Metaverse
A Metaverse rules extension is associated with Metaverse object deletion or provisioning, the latter code being run whenever a Metaverse object is processed (e.g. whenever it is created or modified). There can be only one Metaverse rules extension for each ILM installation (although this extension can call out to code in other assemblies if they are appropriately referenced). The following section provides more details on developing a Metaverse rules extension for provisioning.

Provisioning with ILM 2007 a technical overview by OCG

Page 7 of 23

Developing a Metaverse Rules Extension for Provisioning

Creating an Extension
You can create a rules extension just like any other, however it would be very odd not to use Visual Studio, because of all the help it provides, and if you create it using the Identity Manager, it will have the correct framework (effectively a template with all the correct references and settings, including that it will be created in the ILM extensions folder.). So to create a Metaverse rules extension, follow the instructions in the previous section. If you are using Visual Studio .NET, a new project will be created and a framework for the rules extension will be presented, as shown below:
Imports Microsoft.MetadirectoryServices

Public Class MVExtensionObject Implements IMVSynchronization

Public Sub Initialize() Implements IMvSynchronization.Initialize ' TODO: Add initialization code here End Sub

Public Sub Terminate() Implements IMvSynchronization.Terminate ' TODO: Add termination code here End Sub

Public Sub Provision(ByVal mventry As MVEntry) Implements IMVSynchronization.Provision ' TODO: Remove this throw statement if you implement this method Throw New EntryPointNotImplementedException() End Sub

Public Function ShouldDeleteFromMV(ByVal csentry As CSEntry, ByVal mventry

Provisioning with ILM 2007 a technical overview by OCG

Page 8 of 23

As MVEntry) As Boolean Implements IMVSynchronization.ShouldDeleteFromMV ' TODO: Add MV deletion code here Throw New EntryPointNotImplementedException() End Function End Class

Metaverse Extension Methods

As can be seen above, the Metaverse rules extension supports four methods.

IMVSynchronization.Initialize
The first time that the rules extension DLL is invoked, this Initialize method is called. It is used to initialize the environment in which the other methods will run repeatedly for each object. For example, it can be used to read an XML file or database and set up parameters, or to open a log file. It is not run again unless the Terminate method has run (see next section).

IMVSynchronization.Terminate
The Terminate method is called when this rules extension object (module) is no longer needed. It could be used, for example, to write parameters back to a file or database, or to close a file. If another synchronization takes place within 5 minutes of the last one, the modules is not unloaded, and this means that there is no need to run the Terminate method. The module can be used again (without the need Initialize, either). However, after 5 minutes of inactivity, the Terminate method is run, and the module unloaded to free resources. If the module is then needed again, the whole process starts again with the running of the Initialize method. The module is also unloaded if a change is made to the extensions folder. It is rather obvious that if the DLL file changes, the module needs to be reloaded but any file in the extensions folder (e.g. a parameter file) is really part of the configuration, and so any change in that folder triggers a reload. The point should be made that in a stable production environment, no changes should be taking place in the extensions folder!

IMVSynchronization.Provision
The Provision method is run often. It does not merely run (as you might expect) in response to a change to a Metaverse object it is run whenever a Metaverse object is involved in a synchronization, whether or not it is changed. This means, for example, that the method is run during a full synchronization even though no new data is involved, having the effect of running the method against existing data perhaps because the method has been changed. But it also means that you must write your code so that it doesnt matter how many times it runs, it does the right thing and your solution converges. The method is passed a single parameter, the Metaverse object that is involved in the synchronization; it has no return values. Note that although the method is called Provision, this is a little misleading. It may also be responsible for a wide variety of other activities beyond Provisioning, such as renaming or moving (changing the dn) or disconnecting of a connector which may lead to deprovisioning of the related object, depending on the

Provisioning with ILM 2007 a technical overview by OCG

Page 9 of 23

disconnection properties of the MA concerned. Note that disconnection of a connector may lead to the deletion of the Metaverse object, and this will certainly be the case if you disconnect the last connector, which would be rather obviously true if you were to disconnected all connectors!

IMVSynchronization.ShouldDeleteFromMV
This method has nothing to do with provisioning, but allows a custom rule to be specified for Metaverse object deletion. It is called when a connector is disconnected for any reason, for example: The import and subsequent synchronization of the actual deletion of the CS object concerned The action of a filter in a MA (reacting to an imported attribute change, like a delete status) Disconnection cased by code in the Provision method A manual disconnection by an administrator

The method determines if the Metaverse entry concerned (the one just disconnected from) should be deleted. For example, it might be decided that when the HR system disconnects, the Metaverse object should be deleted. Note that any remaining connectors become disconnectors (in other words they are disconnected), and their corresponding data source objects are handled according to the disconnection properties of the MA(s) concerned (they could be deleted, disabled, moved etc.).

Basic Steps in Provisioning

Provisioning code can be fairly complex, but the following diagram illustrates some basic steps in the simple scenario in which each time an HR record (object) is imported, a target system is provisioned with an object (account, record or whatever).

Provisioning with ILM 2007 a technical overview by OCG

Page 10 of 23

Metadirectory (SQL Server Store) CS

1 HR 2 3 4 5 9 AD 10 7 8 6
Provision Method Dim Target MA As Conn... MA = mventry.Connect.. csentry = MA.StartNew... csentry.DN = [Generat... csentry(unicodePWd)...

Metaverse

1. The HR Database MA runs an import profile and imports a new user into the connector space as a person object. 2. When the HR MA is run with a synchronization profile, the new user is projected into the Metaverse. The MV rules extension is invoked. 3. The first provisioning step is to define which connected data source we are about to provision an object into. We identify the Management Agent which manages that connected directory (in this example, an MA called AD. Noting that we have to declare an object based on the ConnectedMA class (provided by ILM), which is used simply to refer to an MA (Connected in this context has no meaning beyond that it is a connected system):
Dim TargetMA As ConnectedMA TargetMA = mventry.ConnectedMAs("AD")

4. Next, we create a new object in the connector space of the identified management agent. This must be a connector of the appropriate type - in this case a user object class is used. In VB .NET, this would be expressed as follows:
csentry = TargetMA.StartNewConnector(user)

5.

The next step is to set an anchor value for the new connector. This must be unique, and its nature and value will vary depending upon the connected directory type. For example: in Active Directory it is a dn; for a SQLServer database it would be your chosen unique ID. In VB .NET this would be expressed as one or other of these:
' suitable for an LDAP directory like AD

csentry.DN = [Generated DN]

Provisioning with ILM 2007 a technical overview by OCG

Page 11 of 23

csentry(Anchor).Value = [InitValue]

' suitable for other courses like SQL Server

6. You may need to set initial values for other attributes. You would do this for attributes that will either never change again (e.g. other unique values), or attributes that would not be changed by attribute flow (like a password). For example, in AD you might set some Exchange attributes, and/or an initial password.
csentry(unicodePWd).Value = [InitValue] 'could be taken from a file or generated

7. The new connector is then committed to the ILM connector space database table. If the anchor value is not unique, the commit will fail at this point:
csentry.CommitNewConnector()

8. After the provisioning code has completed, normal attribute flow rules configured for the MA concerned will be applied, populating the new connector with Metaverse attribute values. 9. The management agent is run with an Export step, and an object will be created in the data source that corresponds to the newly created CS object. 10. The export is confirmed by an import. It should be stressed that this is a very simplified view of things in fact much too simple! In general you will have to foresee potential errors and handle them for example, you need to check whether a connector already exists, and think about whether the anchor you have chosen is sure to be unique (and whether you should check that, and what to do if it isnt), or what to do if an attribute value on which you are relying is not present? But provisioning code is even more complex than this, because it is here that we express the business logic that decides exactly what must be provisioned where, and when it must happen, and when it must be deprovisioned, or moved, or reprovisioned and so on.

Provisioning Scenarios
This section uses two common scenarios to illustrate how a Metaverse rules extension may be developed for provisioning. In the first scenario, a very basic extension is developed to enable provisioning of new accounts to a file-based MA. The second scenario shows how to provision to Active Directory, including some more advanced DN construction based on Metaverse attribute values.

File Based System

In the following scenario, ILM is being used to provision new accounts from a SQL server HR database (although that is not strictly relevant) into a file-based MA being used to populate a telephone system. The new Metaverse person objects are projected into the Metaverse from the HR database, and then provisioned to the telephone text MA. The following table shows the attribute flow in the HR SQL MA into the Metaverse. Note that the Metaverse attributes displayName and cn are constructed from the SQL MA rules extension and not the Metaverse rules extension. Although cn isnt used in this example, in general it would be useful for provisioning an LDAP system.

Provisioning with ILM 2007 a technical overview by OCG

Page 12 of 23

To create new entries to be exported to the Telephone system, provisioning must be enabled and a Metaverse rules extension created. The following code shows a Metaverse rules extension written in VB .NET suitable for such a job.
Public Sub Provision(ByVal mventry As MVEntry) Implements _ IMVSynchronization.Provision

' ' Provision new MV entries into the Telephone Text MA ' ' First, the telephone system only takes person objects

If mventry.ObjectType.Equals("person") Then

' ' Declare CSentry and ConnectedMA (classes provided by ILM gets instantiated later) Dim csentry As CSEntry Dim TelephoneMA As ConnectedMA ' Declare an ConnectedMA (class provided by ILM) and instantiate correctly TelephoneMA = mventry.ConnectedMAs("Telephone MA")

' Check if there already a connector present for this mventry and this MA If TelephoneMA.Connectors.Count = 0 Then ' Create the new connector csentry = TelephoneMA.Connectors.StartNewConnector("person")

' Set the initial values and commit csentry("EMPID").Values.Add(mventry("employeeID").Value) csentry("NAME").Values.Add(mventry("displayName").Value) csentry.CommitNewConnector()

Provisioning with ILM 2007 a technical overview by OCG

Page 13 of 23

ElseIf TelephoneMA.Connectors.Count = 1 Then ' Connector already exists for this MV object 'Nothing to do in this case Else ' Shouldnt be multiple connectors something is wrong! Throw New UnexpectedDataException("Multiple connectors in Telephone System! EndIf EndIf End Sub

Note that the code:

If TelephoneMA.Connectors.Count = 0 Then

could have been expressed like this:

If mventry.ConnectedMAs("Telephone MA").Connectors.Count = 0 Then

This is arguably clearer as it emphasises that it is the count for this mventry and this MA. Each mventry will have one connector in this MA, or none, and so this count should be 0 (because there isnt one yet) or 1 (because there is) any other result is a problem in this MA. Although in general it is possible to have multiple connectors, this is unusual, should be handled with great care, and is arguably poor practice Whenever a new Metaverse object is projected, a new connector will be created in the Telephone MA connector space, with the initial attributes EMPID and NAME being assigned the values held in the the Metaverse attributes employeeID and displayName respectively. We are relying on the EMPID attribute being unique, as the code above doesn't contain any way of checking this, or of suggesting alternatives if EMPID turns out not to be unique. There are ways of doing this, but there are also ways of ensuring that only a unique value for EMPID gets into the Metaverse in the first place and this is the highly preferable approach. In summary, then: 1. A new user Andrew Flintoff is added to the HR Database.

Provisioning with ILM 2007 a technical overview by OCG

Page 14 of 23

2. This new user is discovered during the next HR MA import run, and projected into the Metaverse during the next HR MA synchronization run which triggers the Provision method.

3. It is important to understand that the new user gets provisioned to the connector space for Telephone MA, even though the Telephone MA has not yet run. 4. When the Telephone MA is run in Export mode, the new user is actually exported, in this case to a flat file in the appropriate format, with the initial values set. Of course the file then becomes an import file for our telephone system.

5. The CS Object is held in Export in Progress state, because as yet we cant even know it has reached the target system. If we run another export it will export the record again. This will go on happening until a import from the telephone system confirms that it has not only been received by the target system, but that because it comes back looking exactly like it went out it has been properly understood.

Provisioning to Active Directory

To prepare for the AD provisioning, we must generate necessary AD attributes from the data available. Either values must be flowed into suitable Metaverse attributes all ready to flow out to such attributes as userPrincipalName (which must be unique within a forest) and sAMAccountName (which is the pre-Windows 2000 logon and must be unique within its domain), or these attributes will have to be built from suitable attribute components when

Provisioning with ILM 2007 a technical overview by OCG

Page 15 of 23

they are needed. In this case we will assume that a rules extension for the HR MA has already constructed unique values and flowed them into the Metaverse displayName, cn and uid attributes, and a specially created sAMAccountname Metaverse attribute. An easy way to ensure uniqueness is to utilize the Employee ID which we have already established is available. If something more user-friendly is wanted along the lines of FirstName.LastName@fabrikam.com, then some kind of logon generator is going to be needed, which will check if this is unique and, if not, apply an algorithm to find something suitable. It is beyond our scope here to discuss all the ways that different organizations approach this but there is a lot to be said for simply making sure that when the employee data is added to the HR system for the very first time, that system checks uniqueness, and the operator interacts with that system to find a suitable alternative if necessary. As further preparation, the AD MA must have been configured to manage a container within Active Directory in our case this is called called ou=employees, ou=fabrikam, dc=fabrikam, dc=com, and all new users from the HR system will be provisioned to this container. You must have imported the container structure before you can provision into it. The following code for AD is equivalent to the earlier file-based MA example and will create a new connector in the AD MA connector space, ready for export:

Public Sub Provision(ByVal mventry As MVEntry) Implements _ IMVSynchronization.Provision

' Check that the HR MA seems to have done its job If mventry("cn").IsPresent Then ' Declare some objects note that a dn is not just a string, but that we need ' a ReferenceValue to hold the dn hierarchically in the form of pointers Dim csentry As CSEntry Dim dn As ReferenceValue Dim rdn As String Dim ParentContainer As String = "OU=employees,OU=Fabrikam,DC=fabrikam,DC=com" Dim Connected_AD_MA As ConnectedMA Connected_AD_MA = mventry.ConnectedMAs("AD MA") ' 'Construct the dn rdn = "CN=" + mventry("cn").Value

Provisioning with ILM 2007 a technical overview by OCG

Page 16 of 23

' EscapeDNComponent takes a dn or string and returns a dn ' Concat can be used to concatenate to parts of a dn dn = Connected_AD_MA.EscapeDNComponent(rdn).Concat(ParentContainer) ' ' If there is no connector present, add a new AD connector ' and add a password If Connected_AD_MA.Connectors.Count = 0 Then csentry = Connected_AD_MA.Connectors.StartNewConnector("user") csentry.DN = dn csentry("unicodepwd").Values.Add("PA$$w0rd") ' OK to set next three attributes if they will never change csentry("userPrincipleName").Value = mventry("uid").Value csentry("sAMAccountName").Value = mventry("sAMAccountName").Value csentry("dsiplayName").Value = mventry("displayName").Value ' If they could change (e.g. bgecasue of marriage), use regular outbound ' attribute flow in the AD MA csentry.CommitNewConnector()

ElseIf Connected_AD_MA.Connectors.Count = 1 Then 'Grab the existing connector and reset the dn (it might have changed) csentry = Connected_AD_MA.Connectors.ByIndex(0) ' it is the only one csentry.DN = dn

Else Throw New UnexpectedDataException("Multiple AD connectors!") End If End If End Sub

Provisioning with ILM 2007 a technical overview by OCG

Page 17 of 23

Once saved and built, this simple code will create new CS objects for the AD MA as pending exports. Note, though, that for simplicity, little attempt has been made to foresee and cope with data problems such as missing attribute values and the cn and other values are assumed to be unique. Running an AD MA in export mode causes any pending exports to be exported into Active Directory where the new user accounts are created. The corresponding CS objects go into an Unconfirmed Export state, because we know the objects arrived in AD. They will not be exported again, but they will stay in this unconfirmed state until an import run imports objects in the same state they went out, confirming that AD understood the data as intended. Notice that the above new entries will be created as disabled accounts. This is the default behaviour of AD if no value is supplied for the userAccountControl attribute. We could have set that attribute to 512 in our provisioning code, which would have created normal, active accounts. In reality it is likely that we will want to go on managing userAccountControl (for example disabling an account if someone takes a sabbatical, and enabling it again when they return) this is done using an MA Rules Extension to manage outbound attribute flow for the AD MA.

Provisioning to specific AD OUs

In the above example, all new accounts were created in a generic "Employees" OU. However, by altering our code, we could arrange for new accounts could be added to specific OUs based upon a Metaverse attribute such as "location" or "department", and for them to be subsequently moved in response to any change. In our example, all employees added to the HR system have an attribute called OfficeLocation that is mapped to the Metaverse attribute location. To provision new employees into an Active Directory OU that matches this attribute the following code could be used:
rdn = "CN=" + mventry("cn").Value ParentContainer = mventry("location").Value + "OU=employees,OU=Fabrikam,DC=fabrikam,DC=com" dn = Connected_AD_MA.EscapeDNComponent(rdn).Concat(ParentContainer)

The rest of ParentContainer does not have to be so hard-wired either it could instead be read as a parameter from and XML file, so that if we ever needed to make a change, we would not have to interfere with the code. The XML file would be read in the IMVSynchronization.Initialize method. Note that in the above we have only talked about attributes flowing from the Metaverse to Active Directory, but once this pipe-work is in place, attributes can flow from AD into the Metaverse and be used elsewhere.

Provisioning with ILM 2007 a technical overview by OCG

Page 18 of 23

Deprovisioning
Deprovisioning is the action of removing an object from a connected data source and this will happen when an export run finds Pending Exports (CS objects) marked for deletion. An object will be marked for deletion if a) it is disconnected from its Metaverse object and b) the MA concerned has been configured to delete disconnected objects:

(Note that we could write code so as to determine with a rules extension). The disconnection of a CS object has to be downstream in other words it is not that the CS Object disconnects from the Metaverse Object, but that the Metaverse Object disconnects the CS Object. Consider this example: 1. An HR record is deleted, or perhaps just has one of its attributes changed to indicate deletion or disablement. That information is imported by the HR MA. 2. During the next synchronization run of the HR MA, the CS Object is either truly deleted and necessarily disconnects from the corresponding Metaverse object. Or a filter rule could disconnect it because of the changed attribute. Either way this is an upstream disconnection. 3. Assuming that the Metaverse Object Deletion rule is set to delete the Metaverse object if the HR system disconnects (this does not need to be done in code), any other CS objects that were connected are now orphans or downstream disconnections. It is these that are subject to the disconnection logic, and that could therefore be deleted. Note that at step two, it is possible simply to flow the attribute change into the Metaverse, which triggers out code to run and decide what to do. It could disconnect all related CS objects, in which case the Metaverse object is deleted, and all disconnections are treated as

Provisioning with ILM 2007 a technical overview by OCG

Page 19 of 23

downstream this time including the CS object that gave rise to the change. The code (which would have to be encapsulated in suitable conditional logic) to disconnect all related CS objects is:
mventry.ConnectedMAs.DeprovisionAll()

Each of the disconnections this causes are treated according to the disconnection logic of the MA concerned. The telephone one might just be deleted, the HR one could be left as a disconnector (so that we dont attempt to delete the HR record, and for the AD one we might write some code which disables it (by modifying userAccountControl) and moves it (by modifying its dn). Alternatively we could leave the HR record and Metaverse object in place, and simply disconnect the ones we need to, using code like:
Connected_AD_MA = mventry.ConnectedMAs("AD MA") csentry = Connected_AD_MA.Connectors.ByIndex(0) csentry.Deprovision()

With the Metaverse object still intact, if the HR system reinstates this person, our Provision method can readily re-provision accounts as necessary.

Provisioning with ILM 2007 a technical overview by OCG

Page 20 of 23

Conclusion
The fundamental ILM provisioning concepts are not complex but there are a few tricks worth knowing. Most of the pipe-work is handled for you by the MA you do not have to actually address the API of the data source, for example. In a sense, all you need to do is create new CS Objects for export (and disconnect them later, perhaps). Remember, though, that you are attempting to express important (and maybe security-sensitive) business logic in this code so dont do this on a production basis unless you are a competent programmer who is confident about the capabilities of ILM and your ability to make it do what you expect! The OCG advanced ILM course number 504 goes into a lot of detail about provisioning.

Provisioning with ILM 2007 a technical overview by OCG

Page 21 of 23

Glossary
AD ADAM AD LDS API Connector Space CRM DCOM DLL ERP FIM GAL GUI HR IDA ILM LDAP LDIF HTTP Metaverse MMS ILM NDS NOS OU PABX PKI RDBMS ROI SQL WMI XML X.500 Active Directory Active Directory Application Mode aka AD Lite (see AD LDS) Active Directory Lightweight Directory Services (see ADAM) Application Programming Interface A staging area in the ILM database used by management agents to move data into and out of a connected data source Customer Relationship Management Distributed Component Object Model Dynamic Linked Library Enterprise Resource Planning Forefront Identity Manager (next version of MSs IDA Platform) Global Address List Graphical User Interface Human Resources Identity and Access Management Identity Lifecycle Manager (current version of MSs IDA Platform) Lightweight Directory Access Protocol (RFC 1777) LDAP Data Interchange Format Hypertext Transfer Protocol A set of tables in the ILM database that contain the integrated identity data from multiple connected sources Microsoft Metadirectory Services (the original version of MSs IDA Platform) Microsoft Identity Integration Server (the previous version of MSs IDA Platform) Novell Directory Services Network Operating System Organizational Unit Private Automatic Branch Exchange (a telephone switch) Public Key Infrastructure Relational Database Management System Return on Investment Structured Query Language Windows Management Instrumentation (a standard interface for querying and controlling IT components) Extensible Mark-up Language (and standard for exchanging rich data) ISO Standard for Global Directory Services

Provisioning with ILM 2007 a technical overview by OCG

Page 22 of 23

Further Reading
Oxford Computer Group: http:/www.oxfordcomputergroup.com Microsoft ILM Web Site: http://www.microsoft.com/ilm Digital ID World: Electronic ID website http://www.digitalidworld.com Burton Group: IDA analysts and consultants http://www.burtongroup.com
LDAPZone: Resource site for directory technology http://www.ldapzone.com

Provisioning with ILM 2007 a technical overview by OCG

Page 23 of 23