Identity Manager FAQ
This is a living document that can be updated by anybody who is has answers that others might find useful.
- 1 General
- 2 Password Synchronization
- 3 eDir Driver
- 4 AD Driver
- 4.1 Q: Why can't I get the AD driver to create Users in AD?
- 4.2 Q: How can I stop my AD users from being created as disabled?
- 4.3 Q: When I create a User in eDirectory from a template that has group memberships assigned, why doesn't the corresponding AD User get assigned membership in the associated AD groups?
Q: How can I figure out why my driver isn't working?
A: The best place to start to figure out why you driver isn't doing what you think it should be doing is to figure out what it is doing. The way to tell what it is doing is by using trace. You can learn how to use trace using TID10065332.
Q: How do I trace driver activity?
Q: What do the different trace levels mean?
0 - Only event status messages.
1 - Adds basic processing messages.
2 - Adds XML documents that are passed between the engine and drivers.
3 - Adds detailed policy execution and XML documents after policy execution.
4 - Adds more details about events coming from eDirectory.
Some drivers add additional messages for successively higher trace levels, but there is no general meaning assigned to trace levels higher than four.
Q: Beyond tracing, how can I execute tests against IDM drivers?
- See IDMunit.
Q: How do I insert line breaks into email sent from Policy Builder?
A: There are several ways of accomplishing this:
- In IDM 3.5 you can use the Character token to insert any character based on it's Unicode code point value. New lines are represented differently on different platforms, but it is usually either line feed (10) or carriage return (13) followed by line feed.
<do-send-email server="my.email.server" type="text"> <arg-string name="to"> <token-text>email@example.com</token-text> </arg-string> <arg-string name="subject"> <token-text>Multi line email example</token-text> </arg-string> <arg-string name="message"> <token-text>Line 1</token-text> <token-char value="10"/> <token-text>Line 2</token-text> </arg-string> </do-send-email>
- Use the XPath token with an extension function call to java.lang.System.getProperty("line.separator"). Note that depending on the platform IDM is running on, this will return different things.
<policy xmlns:jsystem="http://www.novell.com/nxsl/java/java.lang.System"> <rule> <description>Send multiline email</description> <conditions/> <actions> <do-send-email server="my.email.server" type="text"> <arg-string name="to"> <token-text>firstname.lastname@example.org</token-text> </arg-string> <arg-string name="subject"> <token-text>Multi line email example</token-text> </arg-string> <arg-string name="message"> <token-text>Line 1</token-text> <token-xpath expression="jsystem:getProperty('line.separator')"/> <token-text>Line 2</token-text> </arg-string> </do-send-email> </actions> </rule> </policy>
- Write your own Java extension function that return the character sequence you want to use as the line separator and call it from the XPath token.
- If you use Designer, the Text token uses a multi-line text field, which means you can hit the enter key to insert a line feed. Note, however, that if you ever edit that token in iManager the line feed will be removed by the single line edit field used there.
- Use email templates.
- Send email as HTML instead of text and use the standard HTML tags for formatting.
Q: Why am I getting the error "Code(-9065) Unable to determine value of attribute nspmDistributionPassword ...?"
A: There are a few known causes for this error.
- You haven't granted the driver sufficient rights. Reading nspmDistributionPassword requires that the driver object have supervisor rights to the User.
- The password policy assigned to the user doesn't have the "Allow user agent to retrieve password" feature enabled.
- The Identity Manager server holds a filtered replica of the partition containing the User and you are using a version of NMAS older than 3.1 (older versions of NMAS do not work on filtered replicas).
Q: How does the eDirectory Driver work?
A: The eDirectory driver is unique in that it requires TWO drivers to work - one in each tree. IDM must be installed on a server in each eDirectory. Each eDir driver has its own subscriber and publisher channel. From here it can get confusing as the terminology sometimes changes. Remember that the subscriber channel of one driver connects to the publisher channel of the other and vice versa. Essentially, the job of each driver is to publish and subscribe to XML data for its OWN Indentity Store.
Q: I've setup the eDirectory drivers, but no data is coming across. Why?
A: There could be a couple of reasons. Usually, with the eDirectory driver, replication doesn't occur because of one of the following reasons:
- One or both of the drivers have not been started. Check iManager status for BOTH drivers and also check the driver trace.
- The drivers aren't communicating with each other. Check configuration and dstrace. Each driver should have the correct IP address and port of the other driver.
- Check that the publisher and subscriber information for each driver is effectively the reverse of the other.
- Check that the "full name", "first name" and "last name" fields are populated. Users without these fields populated will not be replicated.
- Users will not be replicated unless a change is made or the 'migrate' button is used to perform a first time migration.
Q: Why can't I get the AD driver to create Users in AD?
A: The default AD driver configuration uses Full Name to populate several attributes and to generate the DN of the AD User object. If Full Name has not been populated then the Subscriber Creation policy will prevent the AD User from being created. Possible ways to get around this if your eDirectory Users don't have Full Name populated are:
- Change the rule in your Subscriber Creation Policy that requires Full Name to require Surname and Given Name instead. Add a set default attribute action that sets the default value of Full Name to a value constructed from the Surname and Given Name and writes that value back to eDirectory.
- Remove the rule in your Subscriber Creation Policy that requires Full Name. Edit all of the policies that rely on Full Name and change them to rely on something else. Before using this option, note that the reason Full Name is used in the default configuration is because it is needed to emulate the standard naming conventions used when creating users in AD via MMC.
Q: How can I stop my AD users from being created as disabled?
A: AD users are created as disabled if they are created without a password or with a password that does not meet AD's password complexity requirements. Depending on your needs, any one of the following should solve the problem:
- Add a rule to the Subscriber Creation Policy that requires nspmDistributionPassword to be available before the AD user can be created. Make sure that your eDirectory password policy requirements guarantee a password that will meet AD's complexity rules.
- Change the default password generation rule found in in the Subscriber Command Transformation Policy named "Password(Sub)-Default Password Policy" so that it generates a default password that meets AD's complexity requirements.
- Disable AD's complexity requirements.
Q: When I create a User in eDirectory from a template that has group memberships assigned, why doesn't the corresponding AD User get assigned membership in the associated AD groups?
A: Group membership in AD is controlled exclusively on the Group Object, whereas in eDirectory group membership is written to both the Group and User objects. Normally syncronizing the Member attribute of the Group object will allow you to synchronize group membership, but on initial User creation the Member attribute usually tries to synchronize to the Group before the User has been created in AD and therefore will fail (with a warning). You can cause the Member attribute to be updated on the group after the AD user has been created by adding AD Add Groups Policy to the Subscriber Command Transformation of your AD driver.
Note: The default AD configuration that ships with IDM 3.5 and greater ships with policies that take care of this issue.