The Remote Loader
Creating a DriverSet
Configuring the DriverSet
Remote Loader Installation
Lately it seems there have been a bunch of new people getting started with IDM, especially with the Microsoft Active Directory (MAD) driver, who need to have a quick explanation of what all the settings are for and how they will affect operation of a MAD driver. While I’ve never been accused of being quick or brief in my explanations I’m going to try to present something outside the documentation that is possibly useful to people who understand what they read which is written like I write. Those people may be few and far between, and are possibly in state hospitals, but in case some of you are evading the white-coat-clad officials like myself, here we go.
First, as a couple of brief reminders about the nature of Information Technology (IT – yes I’m trying to go from the ground up) and this product, you had better be in a test environment. Blah blah blah, Novell doesn’t take responsibility for your irresponsibility, blah blah blah. Okay, that’s through – and I assume you know enough to not play with unknowns in the bread and butter environment of your company. Also, Novell Identity Manager (IDM) is a bit of a fun product to support because so much of support is not working with Novell products. In this case, we need to have some knowledge of the MAD environment, which I’m assuming you have. If you are a super-rockstar MAD administrator, that’s great for you and will help you understand what is going on. In fact, you’ll probably know more than me by the time you have this set up. Some functionality like Signing and Sealing have not been adequately explained to me, so I’m going to avoid them. Others, such as RPC, are a nightmare, and we’ll take for granted it is all enabled and working in your system. Other nuances like Remote Registry should be enabled for maximum comfort during part of this deployment but are not required for things to work, as long as you are decent in MAD.
Finally, this AppNote will focus on the “best” way to implement this driver to maximize performance, security, and ease of deployment. In a world where things are set up properly and simply, this driver can be deployed in 10-15 minutes, including getting the SSL stuff working between the driver and the Remote Loader (RL). Take out that component, and it should take five minutes if you know what you’re doing. We’re going to take a lot longer, but mostly because of my own verbosity as I mentioned earlier. So let’s dive in.
Because it would waste a lot of space and be redundant, I’m not going to go over the quirks of getting iManager set up for this. I think I’ll write another post before too long (or maybe before I post this one’ who knows) on how to setup a Mobile/Workstation instance of iManager specifically for IDM’s purposes. This is very easy, and people ask about it a lot.
Setting that all up is something you should become familiar with, especially as you are changing versions from 2.x to 3.0.x to 3.5.x, since some functionality of the plugins does not work across versions. Having multiple iManager instances makes this a non-issue and, since they’re all local to your workstation, nobody cares about having to upgrade the servers while doing IDM stuff, which is often a critical component of your infrastructure. After all, why have the worry of changing one system’s administration piece during the upgrade of that system, all at the same time? I don’t have the health for stress like that, and assume you’re in the same boat.
As a note about my environment, I’ll be using SLES 10 with eDirectory 8.8.x and iManager 2.6 SP3. IDM 3.5 is on the server, and the plug-ins are already installed in my Mobile/Workstation version of iManager. This is the easiest setup I know of, and I would recommend you have your own. I say it is the easiest and, though I am a Linux user full-time, I really think this presents the fewest headaches of the platforms available (possibly followed by NetWare).
Because of this setup I can download all my media directly to my workstation or my server and get them installed without having to leave the comfort of my bed – which is important to me. Any ISOs can be mounted without burning media (the servers are ten miles away and it’s midnight, so I’m not going to go to them for sure). Any other files can be transferred via scp, which is “secure copy” and works over the SSH protocol (which is installed and running on almost every OS I’ve ever used, except Windows, by default). For those of you working with virtual machines of some sort, you can probably enjoy the same volume-mounting benefits. I would encourage you to do so, for reasons beginning with “verifying burned CD integrity is harder and slower than verifying the ISOs used to burn them” and continuing through “burning CDs for one installation is a waste of plastic and money and isn’t helping the environment.”
Do what you like, but I’m lazy by nature, and having this be as easy as possible is good for me. No matter which platform you use, the install should look almost identical, and the steps the same as what I’ll be using – except for which files are run to start the installations. See the documentation for differences, as they are likely to be more up-to-date and possibly more complete.
So first, the basics of getting the media started with http://download.novell.com/, which is where all Novell stuff is housed.
1. Go to download.novell.com/
2. Choose Identity Manager from the drop-down and click ‘Search’. This will take you to everything Novell-ish that is related to Identity Manager, including the installation media and IDM plugins.
If you don’t have the IDM plugins in iManager 2.6, you can also download them directly into iManager, from within iManager. There is documentation on using this new feature of 2.6, and it’s beyond the scope of all this – so find other blogs or read the docs. It’s also a well-covered process in the Novell support forums, which are available online for free to all.
For this example I’ll download the DVD ISO, because I may use it all at some point in time. Most people doing this install will probably be able to stick with the ‘Identity_Manager_3_5_Linux_NW_Win.iso’ file, which has the engine and RL installations for Linux, NetWare and Windows.
3. No matter what you use, download it and get it into your server either mounted or burned to a CD/DVD.
If you are licensed for Open Enterprise Server (OES) whether it be NetWare or Linux, or if you have Zen 7+ (as of the time of this writing), you are entitled to the ‘Bundle Edition’ of IDM, which is a good thing for you. The MAD, NT, and eDirectory drivers all come for free with this package (instance-based licensing), so you can have it and use it for as many users as you want for free. Credentials still come from Novell, but they are provided since you are licensed via OES or ZEN. Also, if you have an older version of the Bundle Edition, you get newer ones by default (probably as long as you still have OES). Once the media are in there, we can proceed fairly simply.
To quickly review some terminology, we have:
- An “engine”, which is where the IDM engine is running and is where eDirectory is
- A Remote Loader, which is often used and is recommended when possible for a couple of reasons …
The Remote Loader
First, this installation will put the RL on a Domain Controller (DC) in the MAD environment. With this plan, having eDirectory, IDM, and a DC all together means an over-worked box. The RL lets us leave eDirectory and IDM somewhere else on a happier box (my Linux server in this case) and keeps the utilization of the DC to a minimum, which is good for it.
The Remote Loader is simply a bare-bones extension of the engine and loads the driver shim (regularly referred-to as the “driver”). The driver shim is the interface to the application (in this case, MAD). The engine will establish a Secure Socket Layer (SSL) connection between itself and the RL, because we are transferring information that is important and probably sensitive. The RL will receive data via this connection and, via the loaded driver, send it on to the application. The RL will also use the driver to receive new data from the application when applicable for bidirectional communication. (That’s what I’ll be setting up here as well, since it is a common implementation and is just a checkbox to change.)
Besides reducing the workload of the server running the engine and eDirectory, the RL also saves a lot of pain and suffering, should the driver shim have a problem or bug that is not handled. Instead of dying and taking eDirectory with it (since the engine is a module of eDirectory and, without the RL, it loads the shim as part of itself) the RL can live or die all day long, and eDirectory won’t care. Failures of this type on the part of shipping drivers isn’t a big problem. But it’s entirely possibly to develop your own unsupported drivers, and doing so as part of the engine would not be advised.
Another bit of terminology to be aware of is the “driver configuration”, which is often called the “driver” as well – but should not be, since it is just the configuration for the connection to the application. Most of the settings in this configuration apply to the engine, though some affect the operation of the driver shim. This configuration is stored in eDirectory and can be exported via iManager or Designer at any point in time. It is purely XML, so it’s easy to save forever, modify on your own, or send to others for review/sharing. When you have a working, happy driver configuration you should ALWAYS have an export of it saved away somewhere safe just in case – without it, you get to recreate this config (depending on customization you have inserted, this could be painless or heartbreaking).
The initial driver configuration comes from a “preconfig” shipped with IDM that is importable via iManager. It also comes with IDM’s Designer product. It is with the IDM 3.5 MAD driver preconfig that we will build this example. Preconfigs come with default rules that make sense getting you going. We’ll skim over their details, but especially for the AD driver, the rules usually get you going out of the box. Still, every environment is different – which is why you are in a test environment right now.
So, going to my iManager installation and looking in my directory I have created the following container for IDM in eDirectory:
Underneath this container, I will create a DriverSet, which is a special container built for holding drivers and other IDM objects. For those who have been using eDirectory since its inception, this may not look like a “normal” environment – and that’s fine. I build my trees differently from many others, because it simplifies things significantly. I’m sure I’ll write about it at length someday. In the meantime, if some of you have a native LDAP background, it probably looks familiar. A ‘DC’ is an administrative domain and is just a container that can go anywhere and be anything. It’s basically just for dividing up the tree and does a particularly good job for IDM and me.
Another environment note for me is that my administrative user and server are, respectively, at the following locations:
The double-name for the server is because each server has its own DC to contain all of its objects. This is really nice when it comes time to give each server a copy of itself, without having 100 replicas of a given partition floating around. Anyway, just be aware of it.
On my Linux box, I have downloaded all of my various installation files to my user’s home directory in a ‘dnlds’ directory, which works out to be:
For example, the IDM 3.5 installation ISO is in /home/aburgemeister/dnlds/idm35, and eDirectory is in /home/aburgemeister/dnlds/edir88sp1. While the ISO is physically in that location, I also go ahead and mount it there because it’s easy and keeps me from losing files or having to remember a million mountpoints. The following command does the job:
mount -o loop /home/aburgemeister/dnlds/idm35/Identity_Manager_3_5_DVD.iso /home/aburgemeister/dnlds/idm35
So this means my “DVD” is completely available to me in the same location it was downloaded to, and the original ISO is sort of hidden behind the new mountpoint. This is, if nothing else, a great way to play tricks on your friends with diskspace utilization.
To start the installation, run the ‘./install.bin’ file at the root of the DVD. Those of you on Windows, run the ‘nt/install.exe’ file if it hasn’t started for you (and if it did, you really should disable Autorun). Those on NetWare, go into nwconfig and choose to install a new product and point to the DVD’s volume or extracted contents’ directory, followed by ‘\nw\nisetup.ips’. The installation can also be started from the GUI by choosing the ‘product.ni’ file in the same\nw’ directory. Either way, for those on Windows and NetWare, you will be given a GUI installation. Those on Linux using the GUI will also have a GUI installation, but the *nix platforms that are starting this from a command-line will receive a command-line installer. Because I’m ten miles away, I definitely prefer the command-line – it’s much faster than any GUI, regardless of potential compression or optimization possible on the source and destination sides.
As the installer begins, keep in mind that this is still the engine component. It should be done on the machine running the eDirectory instance holding all the users, groups, etc., that you want synchronized. We’ll do the Remote Loader installation later on a Windows server.
The first prompt during the installation is for language, and I’m guessing you can figure that part out. The next few screens (at the console) are for the End User License Agreement (EULA), which I’ll click through, since I’ve already agreed to it a few times before. In all actuality, this time I forgot to become ‘root’ – but that’s a good thing for me to note, in case you have this issue as well. If you are presented with a screen saying you are not ‘root’, this is an indication that you should become ‘root’ on the system. NetWare people won’t have this issue (if you’re at the console, you’re good enough) and Windows people should be Administrator-equivalent to do this install. Just for completeness, here’s my error:
User cannot Install ''''''- User does not have sufficient rights to install' Login as root to install Identity Manager
So let me catch up now, after going in as the ‘root’ user and getting back to my directory:
su - cd /home/aburgemeister/dnlds/idm35
For those of you using eDirectory 8.8.x as well, be sure you have run ndspath to get the environment set properly for eDirectory and IDM on the server. TID 10100008 covers this in a related issue and will get you close. If nothing else, the following should work:
. /opt/novell/eDirectory/bin/ndspath #notice the space between the dot and the path to the command
This implies you are using the root-based eDirectory installation. Currently that is required, so if you are using a non-root install of eDirectory (you are probably not) you’ll need to change that. In the future this could be different, but I have no idea when that may come to fruition.
So now we’re past the first-child-requiring EULA (yes, it’s a joke’ – I’m not a serious person while awake or breathing) and we’re being prompted to choose what to install. I’ll do the bare minimum so you know what that is for you in this case. It’s fine to install the extras, as it is just libraries and driver shims. Because only the one you configure will be used, do not panic if you have “extra” – just be sure to have the minimum. To do this, choose option 4 – Customize the Installation. At this point I’ll leave on Metadirectory Engine (option 1) only by deselecting all other options with the following line (GUI users just uncheck the boxes, or leave them to have them all installed):
There are some options in there I’d like to cover here briefly, as they are probably important to some of you. If you have a server-based installation of iManager, on this same server the options 19 and 20 are interesting. The first one mentions ‘Plug-Ins’ – the binary files that let iManager know how to work with IDM in your environment. The second one labeled ‘Identity Manager Driver Configuration’ refers to those preconfigs I mentioned earlier. Without them setting up a new MAD will be interesting; so for those of you on 3.5, I’ll attach one to this article so you don’t need to do the full install. If you have iManager on this server with eDirectory, or if you do this same “install” on another server, you can choose the component(s) (even without the engine installation) to have those available to you directly from the media. This makes the setup go a bit easier and makes it feel more integrated, but it doesn’t work well with Mobile iManager. I guess this may be a good point to put in a plug for Designer (2.0+ for IDM 3.5), which comes with these configurations built in by default.
So you’ve deselected everything except the engine (optionally adding plugins and preconfigs). Now you’ll be prompted for administrative credentials for your eDirectory environment. If the installer detects eDirectory is not running on this server, that will need to be fixed.
1. Enter the user’s DN in LDAP format (as I showed it above) along with the password.
A final summary is shown, and now the installation will take place. At the end of the installation, a screen pops up saying all went well (we hope, anyway).
2. If you installed the iManager Plug-Ins (option 19), you need to restart your application server (Tomcat). A similar restart of Mobile iManager was required after adding the plugins, but this installer would not have done anything along those lines for the Mobile version.
At this point we have installed the engine as a module of eDirectory. We should have plug-ins in some version of iManager that can reach the tree via TCP/IP, and we have a preconfig (attached to this AppNote or in Designer, if nowhere else).
Creating a DriverSet
The next step is to create a DriverSet. As a note for those on the console of a server, we’re done with that for now, and you should be back on your workstation.
1. Log in to iManager, and you’ll see a screen like the one below. The important things to note are that you have the ‘Identity Manager’, ‘Identity Manager Utilities’, and ‘Passwords’ roles present.
2. Click on Identity Manager.
3. Click on Identity Manager Overview.
4. Click the ‘Search’ button to search the entire tree for a DriverSet.
5. Assuming you don’t have one, choose the option to create one.
6. Name it whatever you want; I’m going to name mine “DefaultDrvrSet35” because it actually exists in my tree already and does other things for me. This makes the full context of this DriverSet as follows:
7. Choose a server to associate this DriverSet to. That server should be the one you installed the IDM software on in the previous step.
Note: I chose not to partition the DriverSet and ignored the prompt; you can go either way, as long as you treat a DriverSet like any other partition and always have at least three replicas of it or its parent containers.
Configuring the DriverSet
After you have created the DriverSet, you will be prompted with a screen that may have a drop-down box with driver configuration options. For those of you using Mobile that box will be greyed out. For those using an installed version of iManager who installed the Driver Configurations you’ll have a long box with a lot of options.
1. Choose Active Directory (the top one as I recall) and continue.
2. If you downloaded the preconfig from this AppNote, be sure it’s extracted (if it was compressed) and is just plain XML when you view it.
3. Choose to “Import a configuration from the client (.XML file)” and browse to your XML preconfig. Mine is at the following location:
Continue to the next screen – this is where we get into the good stuff.
4. First things first with any directory object creation – give it a name.
I’m going to be using “testmad0” since it’s a test driver just for you, that I’ll be getting rid of in a few hours – but you should call it something that makes sense to you. This name needs to be unique to this DriverSet; otherwise, it can be almost anything. I would advise against making it overly long or complex but rather something to remind you of its purpose. Many drivers are named for their Subscriber channel (the channel that sends data rather than receives it), so it could be named “vaultToMAD” or “eDirToMAD” or something along those lines.
The next option to configure is very important and is called ‘Authentication Method’.
5. Choose Negotiate, as it is by far the best way to go.
This method uses Microsoft authentication (Kerberos or NTLM chosen by default) to authenticate to MAD. This means it should be a simple setup, a trusted setup, and a setup with the fewest points of failure (not using excessive boxes or connections to get into MAD). The documentation covers this setting in more detail but, for the most part, you should always use Negotiate. There are exceptions, but using Simple is a lot harder to set up. It is a connection made for Simple functions and lacks some abilities, but it can be used in more cases. For 99.99% of the environments out there it is not appropriate, though, because it lacks certain key functionality.
The next field is also vastly important and often misunderstood. It is called the Authentication ID and is the username of an entity in MAD that has rights to do all kinds of things, including changing users’ passwords, creating and deleting users, modifying groups, etc. Anything you want the driver to do, this user needs to be able to do in this domain. Its format should also be noted; the preconfig and iManager screens show you how to format it.
6. Because you chose Negotiate above, specify either “Administrator” or “domainName/Administrator” for your Authentication ID.
Do NOT try to put in an e-mail address, ever, as it is just wrong. Also, do not in this case try to use an LDAP DN as we are not doing anything related to a ‘Simple’ bind. The screen shows examples so be sure to read and follow them.
The next screen is simply the password for the user listed above.
7. Enter the password twice and be sure it’s the same both times. This should be obvious, of course.
The next field is also a bone of contention for many – it’s called the Authentication Context. What this wants is connection information to a server that can be authenticated against in MAD. The examples on the screen show a DNS name, an IP address, or ‘blank’.
8. In our case, leave the Authentication Context blank.
This is the server (DC) in MAD which would be accessed for authentication of the user mentioned in the previous paragraphs. If we were not on a DC we would need to fill these in. But because we’re using the best configuration possible with the RL on a DC, this is not needed, and leaving it blank is correct. If you were using Negotiate at any time when the driver was on a member server, you would be required to enter the DNS name of the DC and not just the IP address. If you are using just an IP address, you had better be using Simple – and then you’re in an entirely different example. In all cases where you do have a value, be sure it’s just a DNS name or IP address. Do not include other protocol stuff such as “ldap://” etc., since it is not valid at all for this field and will cause errors.
Now we start getting into more MAD-specific stuff. The first option is the name of the MAD domain managed by this driver.
9. Specify the MAD domain in LDAP format, like the following:
dc=mydomain,dc=com or dc=local
10. With this done, specify the next option exactly the same but in DNS format, like the following:
Usually these two options match each other closely, except for syntax. These are critical for the driver to work, so be sure they are correct. The domain in use can usually be found quickly via the Properties page, available by right-clicking My Computer or going to System information. Also, if you open “Active Directory Users and Computers” from the Programs menu, the domain usually shows up at the top of the screen with the MAD environment’s structure.
11. The next option is the password timeout – five minutes is usually fine.
The next option is ‘Local’ or ‘Remote’ depending on where the driver (shim) is going to be run.
12. Choose Remote, though you could do otherwise if (and only if) the engine and eDirectory are running on a Windows box. In that case, the installation of IDM should have included the driver earlier.
The next page asks about the Remote Loader configuration. This is where we tell the engine how to find the RL (which we’ll install on a DC before too long).
12. In the first field, enter the IP address or DNS name of the box running the Remote Loader.
13. In the next field, leave the default port as 8090. Later we’ll see that these are joined with some other text to create the following line in the driver configuration:
14. Fill in the Driver Object and Remote Loader passwords.
These passwords can be literally anything – they can be as complex or as simple as possible, but you really should keep them safe. The Driver Object and Remote Loader passwords are meant to have the engine and RL authenticate to each other. This helps ensure that you are only sending data to or from a device that you know is configured by you, and not by Joe down the hall trying to intercept passwords. These can be changed on both the engine and RL sides at any time, but whenever one side is changed, the other must be changed to match. There is no complexity rule on these possible, but as the administrator you can make it as hard as desired. Making it fairly complex is a good idea once you’re in production. In the meantime, I’ll use ‘novell’ for both passwords (all four fields).
15. Click Next.
The screen asks you about a “Base container in eDirectory”. Its description says this is where objects that come from MAD will be synchronized-to and objects from eDirectory will be allowed-from. I’ve created a special container in my tree just for this at the following location:
In this case the format desired for the field is just the Full Distinguished Name as follows:
In my example, I’m opting to do Flat placement because it is simple and it makes MAD people happy, since they don’t need to worry about creating special containers.
16. In this drop-down, choose the Flat option.
Note that the default is Mirrored. This means that, by default, hierarchies in MAD will be preserved as objects come into eDirectory. Publisher Placement refers to the placement of objects as they come into eDirectory (Publisher channel).
The next option is the base container in MAD to which users will be synchronized. If you are not fairly familiar with MAD, this could be a bit tricky. The example shown is ‘CN=Users,DC=MyDomain,DC=com’ which means the default Users area of MAD.
It should be noted and stressed that this pseudo-container has a CN naming attribute because it is not a true Organizational Unit (OU). For this reason, you cannot create objects that are not users or groups underneath it. If you choose the base location in MAD for objects to synchronize-to as ‘OU=Users,DC=MyDomain,DC=com’ it will not work. Similarly, if you create a new Users container somewhere else in the MAD environment and try to refer to it as CN=Users, you will be wrong. Anything you create will almost definitely be an OU, and the defaults are largely OUs and CNs.
17. Because we’re going for an easy setup, just use the default here:
This setting has to do with Subscriber (eDirectory to application) placement and in this case I’ll choose ‘Flat’ also. Note that if you choose to synchronize to CN=Users, which is not a true OU, you will not be able to do Mirrored, because the Users area cannot hold non-User/Group objects. Had we chosen to put objects under OU=IDMSyncLocation,DC=testad0domain,DC=com we could do Mirrored easily enough by changing the drop-down option.
18. To configure the data flow show off everything maximally, leave the default of Bi-Directional.
19. Leave the ‘Password Failure Notification User’ is not important at this point since I don’t need to have a user from whom password notifications originate so leave this blank.
20. Set Configure Entitlements to “No”. This is advisable until you’re somewhat familiar with Entitlements.
Now we’re starting to get into some advanced things. If you have Exchange 2000 or 2003 you may enjoy some of the next settings, but I don’t have those, so I’ll disable some of them. ‘Exchange Policy’ is now set to ‘None’ for me.
21. To synchronize group memberships, leave the next option at the default.
This option says that group memberships will be synchronized if groups are being synchronized (they are by default). This is probably something you want and is a neat feature when it works in your environment.
The next screen talks about naming of objects in MAD, related to their eDirectory counterparts. We could do this stuff manually, but for the purposes of this introduction,
22. Leave the default at ‘Accept’.
The next screen talks about managing the MAD login name. I have grown to enjoy the “Follow Identity Vault name” option. It creates a user’s information in MAD based on the user’s username and a domain-specific string I specify in the driver configuration. This is so users created via the IDM driver all have consistent names which are complete and ready to be used.
The last screen we reach before the summary asks us about rights the driver should have as well as the exceptions to the driver’s synchronization. This is fairly straightforward, but I’ll cover it a little. For the driver to do almost anything in the engine (eDirectory side of things), it must have rights. Without rights it cannot synchronize changes from the application (MAD in this case), and often it can’t even read changes happening in eDirectory to synchronize over to the application. Without rights, this driver is fairly harmless. With that said, once we give the driver rights to the tree, it will likely become very powerful. In order to synchronize user creations, deletions, and password changes (among many other things), the driver must be given the ability to do this.
Because of security concerns regarding users who are seldom used by administrators, I always use Organizational Roles when setting up any driver in IDM. The reason for this is that you cannot login as an Organizational Role, though an Org Role is just as valid as anything else when it comes to security equivalence. Creating an Org Role with rights to do whatever this driver will do lets the driver do its job. If you have somebody malicious trying to find the user, with all this power to log in as that user and do their own changes, they will be frustrated by a lack of any ability to log in. It’s impossible to log in as an object of type Organizational Role, so there’s no need to worry about passwords on it, or even being silly and ‘hiding’ the object somewhere in the tree. For this case, I’ll create one with the following name and specify it as my security equivalence in the driver object:
I name these and put them in the same container with all my other IDM service-related stuff, because it keeps my tree neat. This also guarantees that any server running the DriverSet is likely to have the security information handy to prevent tree walking unnecessarily. The role’s name resembles the driver’s and driverset’s name. This is on purpose, in case I have multiple drivers with the same name in multiple driversets (this happens because I do a lot of testing). Because of the layout of my tree, this object only has administrative rights to this driver’s portion of the tree (meaning the OU=testad0,O=suse,O=org portion of the tree). There is no reason to worry about somebody taking over this account and owning my tree. That’s because, despite this object’s power in the tree, it doesn’t have the ability to change itself or much of the tree above its one context. Defense in Depth is always a good concept to practice, just in case you forget something at some point in time.
The next field below Security Equivalence deals with Excluded Users and other objects that should not be synchronized by the driver. Even though my admin user is not eligible for synchronization by this driver (it is in a completely separate part of the tree), I always add my administrative roles in here, just in case something changes and I forget to exclude these roles at that point. What this specifically does is creates an association for these objects (users, groups, containers, etc.) that is explicitly disabled. Any attempt to change the object from eDirectory or from the application is blocked. Imagine, if you will, what many others have done in their environments. They set up a system (not always in a test environment) and gave the driver full rights to the entire tree. They then synchronize everybody over to their application and see it working. After doing a little dance they decide to start over and do more tests but not before deleting the objects from the application. When the synchronization of those “delete” events comes back to eDirectory, the poor unfortunate admin user is included in the brutal carnage caused by the administrator. They are left without control of the tree, all because of a simple thing like synchronizing the admin of the tree. As a general rule, do not synchronize administrative roles – it is just asking for trouble. On another note, it is always good to have a backup admin of your tree, though that doesn’t help if you synchronized and deleted it like the original.
23. Click Next and then Finish to import the driver to your DriverSet. The testad0 driver shows up in the upper-right hand corner of the screenshot:
Notice the little red circle with a white line across it. This means the driver is stopped. Now compare the little squiggly arrows in the lower-right hand corner of this driver with the one below, which also has a red/white circle on it. The testad0 driver is set to Manual start, while the one below it is set to Disabled. The third option for starting is Auto-Start, and it appears with a lightning bolt across that lower squiggly-line section of the driver configuration in eDirectory.
So as a quick recap of what we’ve done so far, a few steps are out of the way. First, the engine software is installed on the eDirectory server. We have iManager working with the plug-ins, and the MAD driver configuration has been imported to the DriverSet. If we were to start the driver right now, it would sit there and run and try to connect to the Remote Loader forever. With that in mind, let’s get the Remote Loader configured, and then we’ll try starting the driver.
Remote Loader Installation
The first step to getting a Remote Loader going is to install it.
1. On a windows server (W2K, W2K3, etc.), put the CD/DVD into the drive or copy the extracted installation files to the box.
2. Run the ‘./nt/install.exe’ file and start the installation, similar to how it was described above.
3. This time, instead of deselecting all of the stuff except the Engine, deselect everything except the Remote Loader Service and Active Directory driver.
The RL must be there to connect to the Engine and receive/send instructions. The driver (shim) must be there to convert those instructions to/from the application. This installation should be a fairly quick and painless process.
It should probably be noted now that we’re definitely working on a Windows box, due to some limitations of RDP. First, if you are on Windows 2000, you cannot use RDP for everything, as it has limitations regarding some secure components of the system. This installation may work, but certain access to the Registry as well as configuring various components of MAD, the password filters (which we’ll come to shortly), and eDirectory (in windows) cannot be done via RDP. For those on Windows 2003+, you can use the command that follows to connect to the local console session to do work there that was not possible in Windows 2000:
After the RL installation, you should have an icon on the desktop named Identity Manager Remote Loader Console, as I recall. It will have a yin-yang icon, like other parts of IDM, and be on the user’s desktop by default.
4. Run that shortcut to load the RL console, which is an interface to help you create RL configurations quickly and easily in Windows.
5. Click Add to add a new session. Section 3.3 of the current documentation covers this rather well with screenshots galore.
A few of the settings follow. First is the description, which is really the title in the RL console you’ll see as you administer this connection.
6. Choose a description wisely, possibly named the same as the driver configuration in eDirectory.
The next field in the RL is the “driver”, which means the driver shim.
7. In this case, use “addriver.dll” – that is the shim to interface with MAD.
8. Leave the config file at the default, as it is automatically filled in as you create the driver description.
The IP address(es) for the connection are up to you:
9. Use a single IP address (if multiples on the system) or listen on all IPs for a connection from the engine.
The connection port here must match the port entered for the Remote Loader in the driver configuration stored in eDirectory, and 8090 is still the default. The Command Port is something that must be unique on the localhost interface. It does not ever connect to anything else or allow anything to connect directly to it. For this reason it must be unique on this box.
The next few fields should remind you of the similarly-named fields in the eDirectory configuration of the IDM drivers. The driver object password here must match with the driver object password in eDirectory. The Remote Loader password here should also match the counterparts in eDirectory. As a reminder I used ‘novell’ for both fields previously.
The last section we MUST configure here is the Remote Loader’s SSL certificate between itself and the engine. Section 3.2 in the Identity Manager documentation talks about how to set up a certificate. For the most part it is trivial, but it does take up some time. The certificate’s name needs to be specified in eDirectory on the Remote Loader line after the “hostname=blah port=8090” part. The last parameter should be “kmo=shortNameOfCertificate”. For a certificate named “testad0 ” idm0lin-1a.idm0lin-1a.server.system, the short name required would just be “testad0”. Section 3.4 of the IDM documentation covers the last bit of configuring done between the engine and the RL.
So now at this point you should be able to start your RL instance.
10. At the prompt to run this process as a service, choose Yes. I would also choose to start it automatically as a service on the Windows box.
11. Once this is done, start the driver on the engine side to see if it will connect.
12. Click on the yin-yang icon to see a list of options of what to do with this driver.
13. Choose ‘Start Driver’. At this point it should start and stay running and, with a little luck, passwords will even synchronize.
In regards to password synchronization, a couple of settings are required in eDirectory. First, you must have a Universal Password policy to use the Password Synchronization 2.0 (the default) functionality. Setting one up is trivial. The basic steps in iManager include:
- Password Policies
- Name and settings
- Assignments (Login Policy.Security or, in your case possibly just testad0.suse.org)
1. Log in with the user via an NMAS-enabled client. You can also have their password changed to populate the Universal password for synchronization in the future.
2. The quickest way to test the connection is to create a user in the base contexts on either side to see if it works by flowing to the other side.
If this works, great. If not, you need to troubleshoot it by reading the error messages found in a trace (currently, TID 10098620 will help).
One more component left to be set up is the password filters in MAD.
3. On the box with the shim installed, find the Control Panel applet named something like “Identity Manager PassSync”. This is an applet to simplify the installation of the filters on various DCs in the MAD environment.
4. Launch this applet to see a dialog about whether or not this server is running the driver.
5. Reply “Yes”, because the driver shim is on here. You will also be prompted to enter the domain name probably from a drop-down box and, optionally, a server name.
6. Leave the optional field blank and choose the appropriate domain from the drop-down.
7. On the resulting screen, select your domain and click ‘Filters’. In this window you can select all of the DCs in the domain and install the filters as well as reboot them. Once that’s done and they are rebooted (required) they should all forward password changes to the Remote Loader box.
Note that when setting this up, every DC from which a password may originate must have the filter installed, Windows will then require a reboot. Until this is done, the filters may be installed, but no passwords on that DC will be captured and sent to eDirectory. However, passwords should be able to go the other way (eDirectory to MAD).
So now we’ve gone through the entire configuration of a MAD driver to our eDirectory tree. No troubleshooting has been done at this point in case there were problems, but for the most part this should cover all the steps. This is the long, drawn-out version for sure – so hopefully most of it made sense reading the documentation and IDM prompts. Once you know the settings, an explanation will not be required to get going.
I hope that helps – good luck!