Skip to main content

Getting into Microsoft Identity Manager ...




Hmm... Microsoft Identity Manager 2010 is out.. but i really wanted to see how the new version is better then its older versions... i have read lots of documentation about FIM2010 and its declarative programming capabilities, MPRs (Management policy rules), workflows, Sets, Group etc, so before touching the fancy parts, i decided to dig into first how the sync-engine or as it previously called MIIS works before doing hands-on with the fancy FIM2010 and the sharepoint based user portal..

Going back to its earlier version and doing hands-on was necessary for me, since FIM2010 documentation always referred the "Classic-rules" as the more powerful then the declarative rules/programming in FIM2010. So i wanted to experience the power into Microsoft IdM before touching the declarative programming(less-power'd) stuff in FIM2010.


Having already worked with event-based IdM products such as nOvell identity manager, i was excited to work with the state-based systems such as FIM2010.

I downloaded the Microsoft Identity Lifecycle Manager 2007 Feature Pack 1 , which actually was a right enough candidate for me to test. It comes with the two management agents the "Active Directory" and the "Extensible Connectivity"... The Extensible connectivity is the type of Agents(Call-based, File-Based) which should be implemented by yourself(developer) in order to connect to your target systems, it is just bunch of interface to implement.. looked not so horrible...

the other stuff that i downloaded was Visual C# Express Edition 2008. In order to do some coding in C#.... I did since i didn't wanted to mess it with my existing visual studio professional 2009 edition.

I started with a very short and little environment, whic was having only one Active Directory domain (Windows Server 2008) running and one Member server (Windows Server 2003) and nothing else :).. I created two AD management agents which pointed to the same AD but in different oUs(organizationalUnits).. one agent for source and one agent for the target..

Creating the first AD management agent gave me a surprise.. it asked me the four parameters[], {"Forestname", "User name" , "Password", "Domain"}.. Hmm...for MIIS to work with different source /target ADs one must have to open all the AD/Microsoft type of firewalls ports between MIIS and the target/source ADs... Do i really think the firewall guys will like me if i ask them to do this :)..... Novell rocks, since it has this agent-based architecture which actually give you the more flexibility, so i give novell a plus point here..

Well the creation of the AD management agent went very straight away, just some point and clicks and i was finished with source AD MA... (Import)... and the same with the other AD MA as target (Export) ...

Had to create some run profiles for AD agennt(source) and did some synchronization and finally i had some users coming into MV (metaverse)... now the headache started when i couldn't actually see my users provisioned to the target AD management agent.... yes i missed the Provisioning code.. hmm... bingo.. there comes my Visual C# Express Edition.... though writing the provision code was not so difficult, but I found it totally unnecessary / when i compared provisioning and how the Novell provisioning works.... but anyway this is how i ended up with the provisioning code,,



void IMVSynchronization.Provision (MVEntry mventry)
{
ConnectedMA connector_Ad;
CSEntry csentry;
String targetPlacementDN = "OU=Rampson,OU=IDM;OU=ent,DC=miis,DC=local";
String objectRDN = "";
ReferenceValue targetDN;

try {


if (mventry["displayName"].IsPresent && mventry["company"].Value == "Rampson")
{

connector_Ad = mventry.ConnectedMAs["RampsonADExport"];

objectRDN = "CN=" + mventry["displayName"].Value;

targetDN = connector_Ad.EscapeDNComponent(objectRDN).Concat(targetPlacementDN);

if (connector_Ad.Connectors.Count == 0)
{
csentry = connector_Ad.Connectors.StartNewConnector("user");
csentry.DN = targetDN;
csentry["sAMAccountName"].Value = mventry["displayName"].Value.Trim();

csentry.CommitNewConnector();
}
else
{

}
}

}
catch (Exception ex)
{

throw new UnexpectedDataException(ex.Message + " - Exception cought by MIIS");
}

}

well, provisioning was really a headache,, since i found MIIS as black-box, i didn't know what was happening in the background while I was clicking doing sycs, so i was really missing the DSTrace(novell) sort of stuff here.. the only thing that i could see was boring Windows Event Viewer entries which had some Error logs into it.. after reading some stuff on MSDN Testing and Debugging ILM 2007 FP1 Extensions, i went to this logging namespace introduced into my code Microsoft.MetadirectoryServices.Logging; (logging.dll) stuff.. it gave me some help since now i could really log all the provisioning steps into a text file waoo some relief.... I actually didn't like this, it remind me the "Doing debugging in VB Script writers way" :) but anyway my provisioning code ended up with some loggings here.


void IMVSynchronization.Provision (MVEntry mventry)
{
ConnectedMA connector_Ad;
CSEntry csentry;
String targetPlacementDN = "OU=Rampson,OU=IDM;OU=ent,DC=miis,DC=local";
String objectRDN = "";
ReferenceValue targetDN;

try
{
Logging.Log("lets kicks the provisionign.",true,2);

if (mventry["displayName"].IsPresent && mventry["company"].Value == "Rampson")
{
Logging.Log("in the loop", true, 2);
Logging.Log("displayName - " + mventry["displayName"].Value, true, 2);
Logging.Log("company - " + mventry["company"].Value, true, 2);

connector_Ad = mventry.ConnectedMAs["RampsonADExport"];
Logging.Log("passing connector_AD init - " , true, 2);

objectRDN = "CN=" + mventry["displayName"].Value;

Logging.Log("targetDN string - " + connector_Ad.EscapeDNComponent(objectRDN).Concat(targetPlacementDN), true, 2);
targetDN = connector_Ad.EscapeDNComponent(objectRDN).Concat(targetPlacementDN);

Logging.Log("Connector count - " + connector_Ad.Connectors.Count, true, 2);

if (connector_Ad.Connectors.Count == 0)
{
csentry = connector_Ad.Connectors.StartNewConnector("user");
csentry.DN = targetDN;
csentry["sAMAccountName"].Value = mventry["displayName"].Value.Trim();
Logging.Log("csentry DN - " + csentry.DN, true, 2);
csentry.CommitNewConnector();
}
else
{
Logging.Log("nothing ", true, 2);
}
}

}
catch (Exception ex)
{
Logging.Log("commit exception - " + ex.Message, true, 2);
throw new UnexpectedDataException(ex.Message + " - Exception cought by MIIS");
}

}


so after hooking provisioning code into metaverse, i could see my user being provisioned in the target AD connector space , but with errrrrrrrrrors!!!... that is I forgot to do a Import(Stage) run profile on the "target AD" agent in order to sync in oUs from the AD, so that the my pending users can find their parents ..

well finally i could see the provisioned users into the target AD ou.

so long the overall feeling was not so bad.. but obviously one cannot compare MIIS with Novell Identity manager at all.. Novell product is in the enterprise class with this all flexibility , expandability, operations, error handling, and coding, but i found MIIS as the little guy.. just OK for doing small syncs..

My MIIS programming continues with smile :)

Comments

Popular posts from this blog

Experience writing a Java based DirXML Driver

Based on the customer project, I wrote a DirXML driver which provision users through Novell Identity Manager 3.5.1 to their company intranet portal ( A Plone System). The portal exposed the RESTful API interfaces. So I started looking first at the Novell SOAP driver to see if it fit our needs. But while reading the driver documentation i felt it required too much XSLT knowledge + more customization and testing on the driver. And again it used the Apache HttpClient, Which is more a HttpClient rather then it targets to any specific protocol implementation. So If you could build SOAP messages at your own so it would help you in transporting these message back and forth between IDM and Application. The Novell SOAP driver comes up with two built in configurations "SPML and DSML", but in my case none of them were suitable. I had always wished to write my own DirXML driver at my own, so I thought why not just take this opportunity to fulfill my wish and at the same time get s...

NetIQ IDM - Adding operation-data to subscriber command transformaiton custom commands

Recently i had to execute EOL cmdlets using psexecute though new NetIQ azure ad driver, since this operation is fire and forget in nature, i would like to track whole request and response for my own generated commands from subscriber command transofrmaiton policy, so i solved it by following policy: < do-set-dest-attr-value direct = "true" name = "psexecute" > < arg-association > < token-resolve datastore = "src" > < arg-dn > < token-text xml:space = "preserve" > {userref} </ token-text > </ arg-dn > </ token-resolve > </ arg-association > < arg-value type = "string" > < token-local-variable name = "cmdlet" /> </ arg-value > </ do-set-dest-attr-value > < do-append-xml-element expression = "../modify[@direct]" na...