Adding PCNS to an ECMA2.0

One of my favourite tools that comes with working at Oxford Computer Group is an ECMA2 called the “delta generator” – at it’s simplest it’s a faster version of the FIM SQL management agent, but it’s got a few extra tricks up its sleeve that make it an common tool to reach for whenever I’m working on a project.

This time, I’ve been asked to add a password hash to an existing SQL database and to treat the connector as a PCNS target.

Initially I thought it wouldn’t be a problem until I got into FIM to configure myself a Password extension and was faced with the Extensions page of the MA Properties:


As you can see, I’ve checked the ‘Enable Password Management’ box however this has defaulted to the delta generator DLL rather than allowing me to insert my own code.

Usually this wouldn’t be a problem – most of the time I’ve either built the ECMA2 myself or its source is part of the project, however this is one of our stock tools and creating a custom version would cause no end of downstream issues – especially as this tool sometimes crops up several times on the same FIM configuration and I really don’t want to have a password extension for one part of the project cropping up on management agents for other systems – or the overhead of trying to manage any future updates to delta generator back into the new connector.

In order to work around this, I built myself a brand new ECMA2 and added a reference to the original delta generator – the interfaces call for public methods and no parameters on the constructor so in theory it should be fairly simple to create my own instance of the delta generator within my ECMA and pass parameters back and forth between FIM and the underlying code as follows:

From here, I added the core interfaces one at a time, passing in any parameters and returning any values from the delta generator back out to FIM – for example, the CallExport interface is implemented as follows:

Working back from the interfaces exposed from the original Management Agent, it should be relatively simple to stand up matching interfaces on the Wrapper MA and fill in the blanks in the same manner as above – passing the values back and forth between the FIM and the core DLL.

Once this was working (and tested) I added the IMAExtensible2Password interface (this one isn’t automatically provided by the template generator for some reason) and started to implement the new Password Extension methods.

While these are a major improvement over the original Password Extension as you can access the same set of configuration parameters used by the hosting Management Agent, it quickly became obvious that I was missing a key detail that was unique to the Password Extension – the name of the certificate to use for encryption and signing.

Fortunately as well as wrapping up the existing DLL, because the Parameters are passed back from the original delta generator via our wrapper, it is possible to inject additional items – as far as FIM is concerned, it is still retrieving a legitimate collection of parameters to query the user for.

Once compiled and built, this wrapper can now be dropped into place within the Management Agent in place of the delta generator and refreshing it’s interfaces brings the new Password capabilities into play:


This time, visiting the Configure Extensions page and enabling password management still refers back to the ECMA2 DLL however this time, the correct Password Extension is in place to be able to perform the required updates:


This entry was posted in Certificate, ECMA 2.0, FIM, Snippets and tagged , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *