The Active Directory driver in all versions of Identity Manager from 2.0 and up, when we started using DirXML Script instead of XSLT for policies have had a pair of attributes in common. DirXML-ADContext and DirXML-ADAliasName.
These are used to handle the strange circumstance of a rename or move event in Active Directory. The shim cannot tell the difference between a rename or move event. Both cases are actually a modify of the distinguishedName (DN) attribute.
For example: cn=geoffc, ou=Users, dc=acme, dc=com
If this were to change, it would depend where the change occurred to know if this was a move or rename event. If the cn=geoffc part changed, then that is a rename event. If any of the ou=Users, dc=acme, dc=com part changed, then this was a move event, since the parent container for the object is now different, in other words a move event.
You can find the policies that manage this in the Publisher Event Transformation rule set. There have been a number of different shipping default configurations for Identity Manager, so the name of the rule and its exact workings have changed over time. With the advent of IDM 4 and Packages, we should see this stabilize and become more manageable.
The problem with using single valued, simple string attributes for this task is how do you handle a second AD driver in a different domain? Well if the user is only ever in a single domain, that is fine, but if you have worked with IDM then you know that one of the cool things about IDM is how easy it would be to manage users in multiple AD domains, eDirectory, and many other connected services.
If you add a second Active Directory domain to your IDM world, then the values of DirXML-ADAliasName and DirXML-ADContext will be incompatible between drivers and domains.
In the first article in this series Managing multiple Active Directory domains in one IDM system - Part 1 I discussed an approach in general of a plural version of the attributes, using Path syntax.
In the second article in this series Managing multiple Active Directory domains in one IDM system - Part 2 I discussed more of the specific implementation details of making this work. I provided some sample code for making sure you update the attributes correctly.
In the third article in this series Managing multiple Active Directory domains in one IDM system - Part 3 I worked through a good chunk of the Publisher channel rules that need to changed for the DirXML-ADContexts attribute. Still need to do the same for the DirXML-ADAliasNames attribute.
In the fourth article in this series Managing multiple Active Directory domains in one IDM system - Part 4 I worked through the rest of the Publisher channel and started in on the plural DirXML-ADAliasNames that are needed, starting with the Output transform.
In the fifth article in this series Managing multiple Active Directory domains in one IDM system - Part 5 I worked through the Input Transformation rule, and most of the Publisher channel.
As a quick recap, we will use DirXML-ADContexts and DirXML-ADAliasNames (note the plural) as multi valued, path syntax attributes instead of the single valued string equivalents that IDM ships with. In the previous article I showed some sample code on how you might update that attribute. The key is to remember to find the current value associated with this driver, remove it, then add a new value in.
Next up, is to decide WHERE do we need to make these changes? Well the easy way to manage this is to export the driver configuration as an iManager configuration file, open it in a text editor and then search for the various attribute names.
I wanted to use the latest configuration, since the IDM 3.6.1 has several possible configurations. (V4, V5, V6, and with one of the patches V7). However I happen to know that there are a number of bugs fixed in the IDM 4 Package version of the driver. I was starting a new project that needed an Active Directory driver but could not yet use IDM 4 for this project, instead had to use IDM 3.6.1. So I decided to try something funny.
I started a scratchpad Designer project, set up an IDM 4 Identity vault, added the Active Directory packaged driver, with all the options, and then I configured it for the most part.
Next I exported the driver to an iManager configuration file, and edited that, making it work with IDM 3.6.1. I have to find the time to write up that exercise as that was quite interesting to see how Packages have changed some things in the config files.
Then I searched through to find all the locations these attributes are in use. Here are my results, shown for the two different attributes, in case you want to identify them independently.
DirXML-ADContexts plural:
Input Transform:
NOVLADDCFG-itp-SubscriberUserAdd 1 rule
Publisher Channel:
Event Transformation:
NOVLADDCFG-pub-etp-HandleMovesAndRenames 3 rules
Create Policy Set:
NOVLADDCFG-pub-cp 1 rule
Command Transform:
NOVLADDCFG-pub-ctp 2 rules
Subscriber Channel:
Command Transform:
NOVLADENTEX-sub-ctp-EntitlementsImpl 2 rules
NOVLADDCFG-sub-ctp-UserNameMap 1 rule.
DirXML-ADAliasNames:
Filter (done)
Schema Map (done)
Subscriber Channel:
Create Policy Set:
NOVLADDCFG-sub-cp-Users, 1 rule
NOVLADDCFG-sub-cp-Groups 1 rule
Command Transform:
NOVLADENTEX-sub-ctp-EntitlementsImpl 2 or more rules)
Publisher Channel:
Command Transform:
NOVLADDCFG-pub-ctp-UserNameMap 2 rules
NOVLADDCFG-pub-ctp 2 rules
New rules needed:
Input Transform
itp-Convert Plural Attribute
Output Transform
otp-Convert Plural Attribute
On to the Publisher Command Transform for the pub-ctp rule (part of the NOVLADDCFG package) there are two rules that need to be updated named:
set cached context value on merge
remove managed attributes when object disassociated
These two were actually already discussed in part 4 of this series Managing multiple Active Directory domains in one IDM system - Part 4 in regards to the DirXML-ADContexts attribute, but as I tested more and worked through the driver further, I realized I missed the second rule (remove managed attributes when object disassociated), for both DirXML-ADContexts and DirXML-ADAliasNames.
In this case, we have a rule that is intended to handle cleaning up objects in eDirectory. This was watching for a <remove-association> event document to come through. I find this rule interesting, since I have seen many <add-association> events go through in trace, but I cannot for the life of me, ever remember seeing a <remove-association> event in trace. Of course that probably means I just did not look closely enough to have noticed it in the past.
The shipping rule is a simple Clear Destination attribute, for both the singular versions of the attributes, so by now you should be familiar with the basic approach, loop through the Destination Attribute for each of the two plural attributes, then test in each loop if the volume component has the DN of this current driver (using the automatic GCV dirxml.auto.driverdn that always returns the current drivers DN with a leading backslash and the tree name at the beginning), and if this iteration through the loop is for this driver, remove the specific value. Since it is a Structured attribute, you have to be quiet specific and specify the values for all three components, which is easy, as they are all in the current-node variable nodeset, which we get with the XPATH of: $current-node/component[@name="path"] which means, in the current-node variable, look for the node that looks like <component name="path"> and gets the string value from it. This is repeated three times, once for each of the three components of this attribute.
<do-for-each> <arg-node-set> <token-dest-attr name="DirXML-ADAliasNames"> <arg-association> <token-xpath expression="./text()"/> </arg-association> </token-dest-attr> </arg-node-set> <arg-actions> <do-if> <arg-conditions> <and> <if-xpath op="true">$current-node/component[@name='volume']="~dirxml.auto.driverdn~"</if-xpath> </and> </arg-conditions> <arg-actions> <do-remove-dest-attr-value name="DirXML-ADAliasNames" when="before"> <arg-association> <token-xpath expression="./text()"/> </arg-association> <arg-value type="structured"> <arg-component name="nameSpace"> <token-xpath expression='$current-node/component[@name="nameSpace"]'/> </arg-component> <arg-component name="volume"> <token-xpath expression='$current-node/component[@name="volume"]'/> </arg-component> <arg-component name="path"> <token-xpath expression='$current-node/component[@name="path"]'/> </arg-component> </arg-value> </do-remove-dest-attr-value> </arg-actions> <arg-actions/> </do-if> </arg-actions> </do-for-each>
Do the same thing for the DirXML-ADContexts, and use the minor twist, that the way you find the Destination object, is to get the ./text() value via XPATH. This is the same basic approach used in the Input transform rule, NOVLADDCFG-itp-SubscriberUserAdd which operates on the <add-association> event. This is because the document you get has a single string value, the association. So by asking for the text() value of the current context (period) you get the association value. Then you can ask IDM to get you the Destination object, either by DN, which we do not know at this point, or by Association value, which that XPATH just gave us.
Of course, we could have used the Resolve token in either direction to get the DN value from the Association, but this is basically already built into the Destination Attribute token, so why bother with any extra work?
Since we are in the Publisher Command Transform, it is worth noting that the IDM 4 driver packages fix a long standing bug in the older driver configurations regarding Equivalent To Me attribute and group membership. It used to be that the rule: Prevent unassociated users from being removed from groups, came after the Set Equivalent To Me rule, and this meant that some of the users additional reciprocal attributes could get dropped at that point. Also there used to be two rules, one to handle the add case, and one to handle the remove case of group membership, when in fact a simple Clone Operational Attribute was sufficient to handle both cases. I used to just fix this every time I used the AD driver, but now with this setup, I think I will try and use this configuration for IDM 3.6.1 clients, and if I can, make a package of these Plural attribute changes for new IDM 4 clients.
Easy enough to fix, just keep the rule that does the Clone operation attribute in the older configurations and move it below the Prevent unassociated users from being removed from Groups rule, and you have it fixed. Simple error, easy to fix, pain it is not resolved in the latest configs even the V7 config that ships with the latest Active Directory driver patches. This is a bit of a shame, since Novell has decided that Configuration files are like the Pirate Code, more a series of recommendations, and not really supportable. However the good news is that with Packages in IDM 4, they will support Packages. Now as annoying as I find that attitude, I understand some of the background.
With Packages they can help you on the phone, since they can tell you toggle on Factory mode, in which case any changes you might have made in IDM by hand are ignored for the moment, run the test again, and if it works, the issue is in your changes, end of call. But if the shipping code fails, they have a reproducible test to try and work with to generate a fix.
Then as a secondary benefit, when they do realize a configuration error, issuing a new Package update to fix it is quite easy, and if you have been using Designer 4 for any length of time you will see that there have been at least 20 or more package updates since IDM 4 first shipped. At least three times now, I have restarted Designer, been asked if I was interested in checking for Package updates, which being the curious fellow that I am, I did, and new packages were found each time.
Thus if NTS debugs an issue, figures out a solution, a simple patch, that can be made available simply to everyone who wants it, without too much muss of fuss. Thus I quite understand why they are happier supporting Packages and now that they have them, would like to disavow supporting the older configurations. As a Consultant, often called in to help with existing IDM implementations and find issues. (Or called in to develop new drivers and solutions, and invariably find issues in the existing implementation along the way) I understand fully how hard it is to track down an error in driver configurations. Asking the fine folk at NTS to do it, quickly, and affordably is quite hard. Having said that, a couple of guys in NTS (Aaron, Fernando, etc) are really quite good at it, so if you can sneak it past them, they often can find your issue.
Well that wraps up the Publisher channel, now on towards the Subscriber channel, as this series starts to draw to a close. (There is a running race (5K about 3 Miles) through the Lincoln Tunnel between New Jersey and Manhattan. You literally start at the mouth of the south tube, run to the Manhattan side, see the light at the end of the tunnel (literally) take 10 steps into Manhattan day light, then turns around to run back to New Jersey. Thus I have literally seen the light at the end of the tunnel in this context).
We have three policy objects in the Subscriber channel, two in the Create policy set and one in the Command Transform.
Starting with the Create Policy set, we have the policy object sub-cp-Users which is part of the NOVLADDCFG package. Here there is a rule called "Map CN to Active Directory user logon name" which sets the destination attribute, DirXML-ADAliasName (aiming at the User Principle Name in Active Directory) and then also sets it back in the source (eDirectory).
Both these need to be modified, and in fact, because we decided to 'flatten' the DirXML-ADAliasNames in the Output transform, as we send it to the destination directory, we still need to send it with all three components. To be fair, I did not test to see what would happen if you sent it as just a simple string attribute, I wonder if the reformat operational attribute token would touch it? Easy enough to test, fire up Simulator in Designer, and lets see. As a refresher in the output transform rule (discussed in part 4 of this series) we do strip by XPATH the <component> nodes for the DN, which would not be affected by the absence of them, however, it is the reformat operational attribute that would start to get us into trouble, as it will take the value of an XPATH statement, $current-value/component[@name="path"]/text() which will be empty when the node is not there, therefore you would loose the data.
In this case it is pretty easy to 'thicken' up the attribute, since we just set the nameSpace component to the CTIME value for right now, using the Time token, the volume component with the DN value of the current driver from the GCV and the path component with the actual string value we would otherwise have sent before.
Basically we do the same thing for the Source Attribute, however, we need to first as always, check and see if there is an existing value, and if there is remove it, before adding a new one.
Code is the same basic example as used before. Nothing new to see here. The only point of interest is that this rule is only used if the UserNameMap GCV is set to edir-name-auth which means that User Principle Name is mapped to follow changes in the CN of the user. You could have been using the model where the User Principle Name is mapped to eDirectory email address or Active Directory email address, in which case this is all non-relevant. But it is nice to have the driver completely converted, instead of just for one specific use case.
Next up is the Policy object sub-cp-Groups which is part of the NOVLADDCFG package. There is a single rule here, named "Send DirXML-ADAliasName to AD when a Group is being created" which is actually interesting as I just re-read the full comments in the rule, and learned something new. The Comments in the Rule says:
"Since DirXML-ADAliasName is mapped to sAMAccountName in the smp policy, this will populate the pre-windows 2000 logon name in AD with the object name in eDirectory. Since Windows 2000 is no longer supported by Microsoft, this policy won't trim the value to 20 characters like it was required to work with that OS."
First off, it is worth mentioning that Groups in Active Directory have the DirXML-ADAliasName attribute (Singular) mapped to the sAMAccountName attribute in Active Directory. Usually, these values need to conform to the NetBIOS name convention which disallows certain characters and specifies the length of 20 characters maximum. But reading this comment I see that the subtring to 20 characters limit is removed, for the reasons given above. Interesting. Of course, we still have clients running Active Directory on Windows 2000, so that is not a great help for me, right now. I think this should have been a GCV controlled function to give the administrator the choice here.
Even having said that, I find the notion of using DirXML-ADAliasName mapped to two different things, depending on the object class to be a bit confusing and makes for a harder to understand driver. This brings up an interesting question of what to do for a Group object. Should we use the same notional plural attribute for a Group, or should we just let it map to CN and not worry about it.
The thing is, that here, we will not be having different CN values in different systems, so the need to actually make this a plural attribute for a group probably does not quite apply. I will have to think about this one, but for now, I am going to leave it alone, and not make any changes to how Groups are handled, since it does not seem like it would be necessary.
I do see a distinct lack of testing for uniqueness, however. It turns out that in Active Directory, sAMAccountName has to be unique across the entire domain, and that means between Users, Groups, and Domains. Thus this rule that escapes the source-name really ought to be double checking for uniqueness in Active Directory. If you send in a non-unique name, you get back a basically random name generated as I recall. This is probably NOT the sort of thing you would want.
This is actually a fairly painful issue when it comes to mirroring an eDirectory tree, where you very likely may have repetitive group names all over your tree. For example, every container might still have an Everyone group, if you followed the old practice from the days of Bindery! If you try and import this to Active Directory, the first one will work, the rest will be problematic.
Additionally this does not set the source value of DirXML-ADAliasName on the Group object either. I think I will try and talk to someone who works on this rule to see if they have considered these issues, and see what we can do.
Well that's about it for now. Down to one last rule left in the Subscriber channel and we can close out this series.