Some tasks seem like they should be difficult to implement, but are in fact beautifully simple; while others tangle you up in complications for no apparently good reason. In my MIIS experience I’ve had far more trouble than seems right with Description fields.
What I’m talking about here are the types of free-text comment fields to be found attached to objects in various, popular directories. In a manually administered directory these are likely to contain a hodge-podge of content, depending on who created the object. Helpful things like “Created for Jim – don’t delete ever!” on an account that hasn’t been accessed in five years…
Now what I’d like to see in these fields is a creation and modification history. People can be nervous about IdM and visibility of the system is an important part of the inevitable publicity project you never planned to have.
It would be a fine thing if MIIS could update the field every time it makes a change. And then if you have to put up with some amount of directory-end, by-hand management as well <<shudder>> you can recommend to those permissioned people ever so nicely and ever so many times that they should update the field as well.
In my imaginary ideal world, a user object may end up with a Description field (or /Info/Notes/Comment field) like this (most recent at the top just because I like it that way):
Disabled by MIIS on 04/01/2007 09:10:18
Surname changed by MIIS from “Laing” to “Evans” 27/02/2007 10:11:23
Telephone changed by MIIS from “4567” to “7891” 19/10/2006 14:45:02
Mail quota increased to 250MB by jimq on Feb 3 2006
Created by MIIS on 10/09/2005 15:12:56
MVExtension activities are pretty easy to get into a Description field. When you’re setting the initial attributes of a new object it’s no difficulty to add:
csentry(“description”).Value = “Created by MIIS on ” & Now()
Another possible MVExtension change is an object rename. For this you would set a Utils.TransactionProperties, such as:
If Not newDN = Nothing Then Â
Utils.TransactionProperties(“OldName”) = csentry.DN.ToString
csentry.DN = newDN
End If
Then in your MAExtension, in a Export Flow Rule for the description field:
If Not Utils.TransactionProperties(“OldName”) Is Nothing Then
csentry(“description”).Value = “Renamed by MIIS from ” & _
Utils.TransactionProperties(“OldName”) & _
” to ” csentry.DN.ToString & ” ” & Now() & ControlChars.NewLine & _
csentry(“description”).Value
End If
What I found a lot more difficult, though, was an attribute change. The logical thing to try is again a Utils.TransactionProperties – BUT it doesn’t always work because you can’t predict what order MIIS will process the attributes!
Say I write an Export Flow Rule for the telephoneNumber attribute and set a Utils.TransactionProperties if it changes:- if MIIS processes the description field before the telephoneNumber field it won’t know it’s going to change. And hence the description is not updated.
I’m afraid this is a post where I say I have no good solution to this problem. I have a fudge that could be used for a critical attribute – but it’s not going to lend itself to widespread application, because, basically, it would slow things down too much.
One such critcal attribute I encountered was rfc822MailMember on nisMailAliases objects in LDAP, where forwarding addresses for mail aliases are held. It was considered particularly important that any changes were well documented, particularly as this was also a manually managed environment (arrgh).
My so-called solution was to write details into a text file as part of the export flow rule for rfc822MailMember. An export flow rule for Description would then check the text file to see if there was anything relevant to this object. It means that the Description field is updated on the Export after the one which changed the rfc822MailMember. The exportDescription code must run for each export (this is done by giving it no input values), and the exports are slowed down by all the reading from and writing to the text file that must go on.
For code snippets of this inelegant solution see here.
Hopefully one day I’ll come up with a better approach. If anyone has any suggestions please let me know!
