provisioning with ilm 2007 090908

8/3/2019 Provisioning With ILM 2007 090908

1/23

Provisioning with Microsoft IdentityLifecycle Manager 2007A Technical Overview by Oxford Computer Group

(www.oxfordcomputergroup.com)

Provisioning with ILM 2007 a technical overview by OCG Page 1 of 23
http://www.oxfordcomputergroup.com/http://www.oxfordcomputergroup.com/


2/23

IntroductionOne 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 isknown asprovisioning, 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).



3/23

ContentsIntroduction ............................................................................................................................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 .....................................................................................15Deprovisioning .....................................................................................................................19

Conclusion .............................................................................................................................21

Glossary ...............................................................................................................................22

Further Reading ....................................................................................................................23



4/23

ILM 2007 Provisioning Concepts

The MA Run Cycle

In an ILM implementation, we have a Management Agent (MA) for each connected datasource. 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 theconnector 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 calledprojection). 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:



5/23

Metadirectory

(SQL Server Store)

CS

HR

Metaverse

3

5

1. A new user entry is entered manually into the

HR database.

2. The HR database MA runs in import mode and

discovers the new entry.

A new object is created in

the HR MA connectorspace.

3. The HR MA runs in

synchronization mode, and as it is configured

to project new connectors into the

Metaverse, a new

Metaverse object is

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 ScenariosAnother 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 ProvisioningIt 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



6/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 ExtensionsRules 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 AgentA Management Agent rules extension is applied at various points during a synchronization

run. Each MA has (at most) one rules extension. MA rules include:



7/23

Connector filter rules

Join rules

Projection rules

Attribute flow rules

Deprovisioning rules

MetaverseA 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.



8/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 useVisual 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



9/23

As MVEntry) As Boolean Implements IMVSynchronization.ShouldDeleteFromMV

' TODO: Add MV deletion code here

Throw New EntryPointNotImplementedException()

End Function

End Class

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

IMVSynchronization.InitializeThe 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.TerminateThe 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 obviousthat 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.ProvisionThe 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



10/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.ShouldDeleteFromMVThis 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 ProvisioningProvisioning 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 targetsystem is provisioned with an object (account, record or whatever).



11/23

Metadirectory

(SQL Server Store)

CS

HR

AD

Metaverse

1

2

79

8

Provision Method

Dim Target MA As Conn...MA = mventry.Connect..

csentry = MA.StartNew...

csentry.DN = [Generat...

csentry(unicodePWd)...

3

4

5

6

10

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 itis 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:

csentry.DN = [Generated DN] ' suitable for an LDAP directory like AD



12/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 ScenariosThis 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 SystemIn 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.



13/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 _


'

' 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)




14/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.



15/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 coursethe 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 DirectoryTo 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



16/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

[email protected], then some kind of logon generator is going to beneeded, 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 anew connector in the AD MA connector space, ready for export:

Public Sub Provision(ByVal mventry As MVEntry) Implements _


' 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



17/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


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



18/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 anUnconfirmed 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 OUsIn 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 toActive Directory, but once this pipe-work is in place, attributes can flow from AD into the

Metaverse and be used elsewhere.



19/23

DeprovisioningDeprovisioning 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 theCS 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 Metaverseobject 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



20/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 ofthe 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.



21/23

ConclusionThe 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 iscreate 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.



22/23

GlossaryAD Active DirectoryADAM Active Directory Application Mode aka AD Lite (see AD LDS)

AD LDS Active Directory Lightweight Directory Services (see ADAM)API Application Programming InterfaceConnector Space A staging area in the ILM database used by management

agents to move data into and out of a connected data sourceCRM Customer Relationship ManagementDCOM Distributed Component Object ModelDLL Dynamic Linked LibraryERP Enterprise Resource PlanningFIM Forefront Identity Manager (next version of MSs IDA Platform)GAL Global Address ListGUI Graphical User InterfaceHR Human Resources

IDA Identity and Access ManagementILM Identity Lifecycle Manager (current version of MSs IDA

Platform)LDAP Lightweight Directory Access Protocol (RFC 1777)LDIF LDAP Data Interchange FormatHTTP Hypertext Transfer ProtocolMetaverse A set of tables in the ILM database that contain the integrated

identity data from multiple connected sourcesMMS Microsoft Metadirectory Services (the original version of MSs

IDA Platform)ILM Microsoft Identity Integration Server (the previous version of

MSs IDA Platform)

NDS Novell Directory ServicesNOS Network Operating SystemOU Organizational UnitPABX Private Automatic Branch Exchange (a telephone switch)PKI Public Key InfrastructureRDBMS Relational Database Management SystemROI Return on InvestmentSQL Structured Query LanguageWMI Windows Management Instrumentation (a standard interface

for querying and controlling IT components)XML Extensible Mark-up Language (and standard for exchanging

rich data)

X.500 ISO Standard for Global Directory Services



23/23

Further ReadingOxford Computer Group: http:/www.oxfordcomputergroup.comMicrosoft ILM Web Site: http://www.microsoft.com/ilm

Digital ID World: Electronic ID website http://www.digitalidworld.comBurton Group: IDA analysts and consultants http://www.burtongroup.com

LDAPZone: Resource site for directory technology

http://www.ldapzone.com

provisioning with ilm 2007 090908

Documents