The new Multi Domain Active Directory driver is a clever new approach to drivers in general yet reusing the hard work and maturity developed in the classic Active Directory driver.
In part 1 of this series I discussed the driver creation method, since this time it matters how you do it. (Drag it from the palette not from Right click, Add New Driver).
Looking at the driver configuration options I discussed previously the first sub tab of Driver Options. The second sub tab is Subscriber options, The first major new thing you will see if a Domain Connections block of settings.
This is a structured GCV with two items, Connection DN, which is where you point to the Connection object that the driver import asked you the define earlier. There you set the username, hostname, base DN, LDAP name of the connection and this was stored in a Connection object. You can modify existing values and add new ones by right clicking on the driver ICON, not the line, and there is a Multi Domain Active Directory configuration item. If you created the driver by using the Right click on driver set, new driver approach this will be missing. Very annoying. I know of no way to get it other than to delete and recreate the driver. If you give it the same name, and then compare you should be fine to pick up any edits made in the tree.
The Configuration editor opens a new tab in Designer, where you can add a Forest, which gets 4 parameters. Forest Short Name, Global Catalog Server, User, and Password. There is a tick box for Secure connection.
The problem with testing this, is that it expects a live system to connect too and for reading information back. This is understandable but somewhat contrary to the Designer offline design approach. However, since I am such a nice guy, I connected to a live system, defined a connection object and pushed it out to a tree, and here is what it looks like:
You create a DirXML-Resource object whose DirXML-ContentType is: application/vnd.novell.dirxml.mdadConfiguredForestCache-ext xml
This is the go to way to add new things to IDM drivers, use a Resource object with a specific Content Type so as to trigger loading the proper editor in Designer. Under the covers it is all text of some kind. Perhaps XML, perhaps something else.
Once you do, you get two screens or views, first shows the Forest level connection:
This shows you the user configured to connect to the forest using an LDAP DN name. I assume this is getting the info via the Global Catalog Server, whose connection information was part of the setup. Then retrieving the available domains to support. In my case, I have a single test domain as the entirety of the forest.
For each Domain you select at the forest level, you see a child entry in the tree view on the left. Each domain page looks as follows:
Now you have some more options and see the user name in domain\username format, the Wait period, Domain Controllers, and Exchange MDB's. The Wait period is how long the system should wait if a DC is not responding. This is a level of fault tolerance that is new to this driver. Before, your Remote Loader server needed to talk to a DC and only one DC. Here the agents support talking to more than one DC and failing over when the first is down. The Domain Controllers and Exchange MDB's are there to connect the in scope components. If you had 10 DC's you could probably select only 2, perhaps one in the main data center and one in the backup data center.
At the bottom there are trace settings, in terms of filename, size, and trace level. This is because the parent shim, which is .NET based, so runs as a .NET Remote Loader, and has its own trace file. But when it passes an event to an agent, then it calls the ADDriver.dll functionality and it would be nice to have trace of that as well. Well what do you know, they support that too! Well done.
You can see a similar approach, in how the fanout JDBC driver works in terms of storing configuration information in DirXML-Resource objects for tracking the various databases in scope.
Earlier I noted that you need to drag and drop the MDAD icon from the palette onto the workspace to get the Domain Configuration Editor added. After the driver is created, the menu item to edit the configurations is available from the node at the end of the line, the driver icon itself, not the usual location, on the driver line. In fact if you click on the driver icon, there is a Driver menu that shows you basically the menu items from the driver line. Which can be helpful to know.
When you go to the driver line and edit Properties, then select the side tab Driver Configuration, then the sub tab Driver Parameters, what you see starts to look a lot like a standard Active Directory driver. This is because these settings are still going to be passed through to an instance of the ADDriver.dll, but first they will go to the MDAD Shim, which is mostly a JMS queue to start with, and then a .NET application to distribute commands to the various Domain Controllers.
The Driver Options tab page of settings look just like the standard AD driver settings. The Authentication options should be familiar with the Negotiate Authentication method looking like an option, but in the build I am working with, Simple, the usual other choice, has been removed. Sign and Seal are still here, as well as the SSL option to the DC. This is the SSL that confuses people. When using Simple authentication, it is basically an LDAP session and if you wish to handle passwords you need that secured. The SSL from Engine to Remote Loader is handled by the way you define your remote loader. Did you add a kmo="SSL CertificateDNS" style bit? Then on the other end, did you specify the public key file to validate the connection against? (Should hold the public key of whatever signed that certificate. The CA, a self signed cert, whatever you used). However SSL from the RL to AD, when talking to a DC is controlled here.
The tricky bit is that Active Directory has to have a certificate installed on the AD side, to allow LDAP over SSL/TLS communications. This often means installing a CA on the AD side, which some admins have been loathe to do, since if they are going to do a CA they want to plan it and do it the enterprise way, which usually means taking a long time to do anything.
The Access options are the same as the AD driver, with a timeout for password sync (how long to cache on a down RL, and still send to AD when it returns), for DC Password TTL (How long to cache on a DC to send to an RL, before discarding), and the Search Domain Scope option.
The Advanced options are the same, the ones that used to be hidden, maddeningly enough.
Here we have a new one, right at the top, Domain Connection Options. This is a structured GCV style with two components, a DN of a connection object (as defined earlier in the MDAD Domain configuration tool) and a password. This way you can set a password for connecting to each of those domains you configured, in a secure manner. Alas it means you have to manage the domains in two places, which is less than great.
What I found interesting is that when I wrote about structured GCVs, I never considered what would happen if one of the component GCVs that made up the structured GCV would be a password-ref type. Read more about these awesome constructs here: Structured Global Configuration Values in IDM
When you make a structured GCV there is no counter. That is, each instance is ordered the way you entered it, which is fine, but limiting since you cannot simply ask for the third instance. If you treat the GCV as a string, you get a string representation using all the specified delimiters, but if you treat it as a nodeset you get the XML mostly intact from the definition. In that case, you could use XPATH to get the third instance node if you needed it.
However, here we need to tie a specific password, which likely differs from all the others, to a specific domain definition object. We want the password stored securely in a Named Password, but each one of those needs a unique name, which in a structured GCV does not normally do. However it seems like someone in Engineering thought about this issue, and as you create an instance of the structured GCV you get a named password (conn.passw_1) with an instance number.
This is interesting and means that reordering such a structured GCV by hand would be a bad idea to do, whereas in most other cases, the position of the <instance> node would not really matter. I like when you get to see a clever use of existing functionality that is not really explained anywhere and can learn something from it.
Next up in the settings is Queue Encryption password which is used to encrypt the messages sent via JMS to the agents. This too is a Named Password, referenced in a configuration setting with the GCV syntax type (same syntax in Configuration and in GCVs) of password-ref.
The last setting in the Subscriber options is the Exchange Options, where you can entirely disable the Exchange functionality. but if you enable it, you get some control over moves and deletes. This allows you block moves or deletes, which can be helpful, especially in cases where you use the 'defer' homeMDB magic value to do load balancing.
Publisher Settings are pretty boring with just the Heartbeat and polling interval set here.
Global Configuration Values:
The set of GCV objects for this one, depend of course on the packages you add. The Password Synchronization package includes a set that is pretty much standard for all drivers, so nothing worth talking about there.
I chose to skip Account Tracking, since I still have a strong desire to review that as a standalone set of packages, outside of any particular driver type.
Managed System Info has not changed (as far as I know) since I wrote a series about the MSG and DCS drivers here:
But basically the DCS (Data Collection Service) driver is there to send data on events to the Reporting database (Which is a baby Sentinel instance), and the MSG driver is there to allow Reporting to query into the Identity system. It exposes a REST endpoint for Reporting to use. The info we configure in this GCV is basically to allow pretty information to be shown in reports about any particular driver. Some of it is strange, and dynamically generated by some policy code in the packages. That is, on startup, a policy reads the current XML of the GCV object, and then adds info or modifies info then writes it back to the GCV object. A very strange approach. Some of it makes sense since some of it is 'hard' to convince someone to type in and is available to the driver easily.
Anyway that is about it for now, next up, finish the GCVs and get on to some real policy stuff.