This tip has to do with password syncing and creation of user object in an eDirectory tree, with AD being authoritative.
Here's what is happening:
The creation of the user object is authorized on the eDir tree, if the Surname and employee ID attributes are assigned to the AD user object. If the required attributes are not available, the initial <add> event, along with the initial password payload, is vetoed/lost.
When a new user is added to AD, a password is assigned but an employeeID may not be. This is will create an “add” event to be created in IDM, with all the relevant attributes and the initial password from AD in the add event.
But there is a problem: the employee ID may not be available in the initial add event. Because of this, IDM’s requirement of employeeID being available on a new user add is not met. The add event is then discarded, along with the initial password, and the corresponding eDir user object is not created.
Now, if an employeeID is assigned later to the AD user object, the event is trapped as a modify event to an existing AD object and sent to IDM as a modify event. As the modify event is processed by IDM, IDM determines that the modify is being requested on an eDir user object that doesn’t exist (remember the discarded "add" event?). When a modify event is detected on an eDir object that doesn't exist, IDM transforms the event from a modify to a "synthetic add" and reads all accessible data from the AD user object to compile a valid “add” event. The synthetic add event is properly performed by IDM and the user is created in eDir with one problem – the eDir password is wrong since it can’t retrieve it from AD.
Passwords are synced by using IDM “password filters” (DLLs). AD password additions and changes are “captured” with these “password filters” prior to being encrypted and store in AD. These “captured” AD passwords are sent to the IDM driver to process and sync to the corresponding eDir user object. IDM cannot read the AD password once it is processed and stored in AD.
The inability to read and reverse-engineer passwords from AD's datastore and add it to the synthetic add event, causes issues. Because the user's password is not available in the synthetic add event, IDM reverts to a policy stating that if a password is not available when the add user event is submitted, a default password of the user's Surname is assigned. So, when the user is finally added to eDir, the passwords are out of sync. Only when the user (or admin) with a corresponding eDirectory user account changes his AD password, is the password then sent to IDM to sync to the user’s corresponding eDirectory account.
1. Alter the IDM creation policy so that when a new user is submitted to IDM (to create the corresponding eDir user object), only the Surname is required (remove employeeID requirement).
2. Create a new persistent policy that states that if an employeeID is not available, place the User object into an "inactive" OU in the eDirectory tree.
Doing this will allow the creation of the eDir user object, along with the initial AD password, when the AD add user object is performed. Once the employeeID is assigned, a move operation will be initiated that will place the user object into the proper OU.
Note - Be sure to check whether storing user objects in eDirectory might cause licensing issues.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.