With the release of NetIQ Identity Manager 4.5 SP2 (known as 4.5.2) at least one new driver was added to the product. Some of the Readmes suggest that the REST driver was added in this release as well, but really that came before SP2. The real new driver is the Multi Domain Active Directory Driver (MDAD). (Though if you look through the palette in Designer 4.5.2 you will see references to the AZURE, Service Now, and SAP GRC Access Control drivers which are not yet released).

This driver is designed to resolve some of the major issues with the current Active Directory driver, but also to add major new functionality. This driver is interesting as it adds the concepts of Agents, which are like Remote Loaders, but are sort of different. The main driver for this is actually a JMS (Java Message System) Queue instance (Active MQ I think) that takes the XDS and requests that come to the shim and kick it off to the appropriate Agent to make the needed calls to the proper Active Directory (AD) domain.

The remote loader itself for this driver is a .NET remote loader, so it has to run on a Windows server, as did the previous drivers Remote Loader instance. However, the ADDriver.dll file is not replaced by this driver, rather when an Agent receives a command to do some AD related task (query, add, modify, delete, rename, etc) it uses the ADDriver.dll functions to implement them and return the data over the JMS Queue.

This is sort of a fanout driver in that way, but sort of not. In the true sense of a fan out driver, the same account ought to be pushed out identically to multiple systems, whereas the fan out here is more about supporting all the domains in an AD Forest without requiring an individual driver per domain. The previous AD driver could only talk to a single domain at a time. This driver talks to one domain at a time, but the one driver can swap between those domains. Almost like old fashioned co-operative multi tasking from the Windows 3.1 days. (I actually had an Amiga so I learned to love preemptive multi tasking at a young age).

Of course since there can be multiple agents, each managing one to many domains, that analogy falls apart, but I guess if you extend it to multiprocessing it sort of still works.

Regardless, along the way you get some new benefits that you can do some levels of failover, so it is not a single driver to a single RL to a single DC, instead the Agents have a bit more intelligence and can handle some failover. I need to investigate exactly how much as part of this series.

As you can see, this is a pretty major enhancement of the driver and the changes are looking pretty good. Do remember this is the first release, so no doubt there will be some issues that come up. But the nice thing is they are reusing the ADDriver.dll functionality so that basic code is all mature and stable.

The most visibly different thing about this driver is how you instantiate one in Designer. You actually MUST use the Palette and drop in the Multi Domain AD driver icon from the Directory section. If you do as I normally do and right mouse click on the Driver Set and select New Driver, then select the base package for the MDAD driver, there is a menu setting on the driver that will be missing that is important. If you do it the right way (drag and drop from the palette) then the MDAD driver icon itself gets an extra menu item. If you just add the base packages from the New Driver menu you do not get it, and I am not sure there is a way to 'convert' it over, short of deleting, reading it, and putting back your work (Which if you used packages ought not to be a big deal).

When I add my driver that way, I get a Package to select prompt that has only the MDAD, on the next page of the Wizard I am going to skip the Account Tracking, Managed System Information, and Audit Entitlements packages since they are usually pretty much the same, and pretty boring to work through. That leaves me with the following packages and versioning:

Multi Domain Active Directory Default Configuration	1.00.0.20150919150511
Password Synchronization Common				2.00.0.20140425111317
Multi Domain Active Directory Password Synchronization	1.00.0.20150224145435
Multi Domain Active Directory Entitlements
	and Exchange Mailbox Support			1.00.0.20150929181914

Thus the rest of this series will be focused on these versions, if new releases come out, I will be able to use the Compare Packages functionality to see what has changed and report back on those. (Which reminds me, I should go look at my other series's on Walk throughs and see if any need that kind of an update.)

It pulls in Common Settings Advanced, a driver set package, since it has PCRS (Permissions Collection and Reconciliation Services) code which will make Resources based on data in AD.

You do not get a choice to run this local, it has to run in a Remote Loader so the usual information. You get noted in a Package Prompt that this needs the IDM engine 4.5 with patch 2, and Designer 4.5.2 to use this driver. The Designer 4.5.2 requirement is because of the Designer plugin for the new option for managing the domains for this driver. The engine 4.5.2 I am curious as to why. Generally when there is a requirement for a specific engine revision it is because of a specific feature added in the engine.

For example, the addition of Startup and Shutdown policies was needed for PCRS since they moved the initialization code to the Startup policy. This functionality was added in the 4.02 Patch 4 engine update. Some shims that use State databases needed the latest JDBM library (which was renamed to MapDB by the project owners) and so later shims have a requirement for a specific engine patch where MapDB had replaced JDBM. I do not yet have any information on what the engine change in 4.5.2 that is required by this shim, but am curious if anyone happens to know. Sometimes it is a simple bug fix required to make it work and not a big deal. If you know what the fix is, please leave a comment.

I mentioned in the articles I did on the Oracle EBS drivers, that the way they show the warning is by using a Package Prompt for a GCV object that has just <header> nodes. Which is why it looks so 'funny' when displayed. I stand by my statement that they should add a construct for better display of text in a Package Prompt.

I have the Entitlements package and they all include PCRS now, so the next package prompt is for Entitlement Name to CSV File Mappings. I do not have any to add at this time.

Next prompt is Synchronization Settings, and Name Mapping Policy. Under Synchronization Settings there is a Configure Domains GCV, that is a structured GCV. This means you can have multiple 'instances' of a set of GCV pieces. This is a super useful thing they added in IDM 3.6.1.

Each instance has the components of:

     Domain DNS Name (domain.com)
     Domain Container (IDV container (backslash) to mirror this domain to)
     Active Directory User Container (ou=Users,dc=domain,dc=com)
     Subscriber Channel Placement Type (Mirrored/Flat)
     Publisher Channel Placement Type (Mirrored/Flat)

This should remind you of the main settings for a single AD driver in the past. You need the domain.com aspect of the AD Domain. This is used for UPN (userPrincipalName) generation. AD User Container is where to scope events in the domain, like in a normal AD driver. Sub and Pub channel placement types, is for flat or mirrored placement. That is, you can have the structure of the AD mimic the structure of the Identity Vault.

Alas, there is no option for I call Hybrid mode, that we have deployed at a number of customers. In that case we have a structured older tree, often called the File and Print tree, connected via an eDirectory driver (The older two part driver or the newer Bidirectional driver) and it syncs the users and groups to flat containers in the IDV. But along the way it writes the DirXML-ADContext value on the objects. When it is time to send them out the subscriber channel on the Active Directory driver, it uses the DirXML-ADContext for placement. When a move happens in either side, the DirXML-ADContext value is updated passed through to the other structured tree and appropriately moved to the new location. I do think there would be value in NetIQ supporting this kind of a mode, but I have not seen any movement in that direction.

The next section is Name Mapping Policy, which is a hide/show option and due to a known bug in Designer will not 'show' the values. However they are basically the same as the older AD drivers settings, where you can map CN in Active Directory to the eDirectory CN or use the eDir Full Name to be the AD CN. The User Principal Name can be mapped to follow the eDir CN, the eDir email address, the AD email address, or none.

What is interesting is that this policy applies to all domains in the forest, which I guess is ok. If you needed different rules in different domains, you could most likely handle it in custom policy easily enough.

Then we get into the Managed System Info pages, where you identify the system for reporting. Nothing special here. That is the last set of prompts (as well as a Remote Loader configuration page you have no doubt seen many times before).

Lets take a look at the driver configuration now that it is created. The Driver Parameters, Driver Options basically look the same as any other AD driver, with configuration for connection settings (Negotiate, Bind and Seal, etc). What is interesting is that the DC Passwords Time To Live defaults to -1. Which I guess means disable. It has never been clear what the disable a timeout, and immediate timeout settings were for this setting. I would guess from here that 0 means timeout immediatly (do not store) and -1 means never timeout, store until they get processed.

There are two timeout values here, same as in the modern AD driver. The first is Password Sync Timeout, and defaults to 5 minutes. This is how long the Remote Loader server will hold onto passwords if the connection is down. That is, the domain controllers with Password Filter collect a password, forward it over RPC to the RL server and then the RL server tries to send it to the engine. It will try for 5 minutes and then discard it.

This is important for times where you have failed over to a backup Remote Loader and you do not wish to replay old password changes from last week when you fail back to the original RL.

The second setting, which I started with first. DC Passwords Time To Live, is about how long each DC will be configured to hold onto passwords to forward, if the Remote Loader server is down and not receiving them to store and forward. Disabling the timeout is a good default since you usually want the DC to forward the passwords unless it drops off the network for a large period of time.

It has never been entirely clear to me how this information is passed to the remote DCs, but I think during the driver startup, these settings are passed into the RL, and it must then reach out over RPC and either set the Registry key on the remote DC or else ask PWFilter to do it locally (Since it has local permissions).

That is about it for this part, stay tuned for part 2 for more information.