• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 984
  • Last Modified:

Novell Identity Manager 3.5 some users do not sync to AD from EDIR

Novell, Identity manager 3.5. AD Connector/Driver. We have exisitng users in EDIR that we want to migrate to AD. Using the migrate option form within Imanager Identlty management dirver, only the groups were migrated , despite selecting the whole container.

However, EDirectory sync to AD works for users created in, or modified by, Imanager. When we create they by Console 1 they don't sync and or are not created in AD. If we change a user who was created in console one with Imanager, using password change from NMAS option, then the user will be created or synced in AD as required.

I think this is related to NMAS or Universal password or something, but I need to find out what the differences are, as there are about 22000 user ID's and it is impractical to manually change all their passwords in this manner. Universal password policy is assigned to the container with the user ID's we are testing.

Any suggestions anyone??
0
mattpaulin
Asked:
mattpaulin
1 Solution
 
alextoftCommented:
Yes, this sounds Universal Password related. ConsoleOne by default won't populate the Universal Password attribute, whereas iManager will. It sounds as if the 3.5 AD driver has a veto rule to reject users with no UP set. The UP is also populated during a successful login from an NMAS enabled Novell Client (v4.9+). Are your users' machines equipped with an upto date client?

I don't have a 3.5 installation to check the driver rules (not upgraded from 3.0 yet), but the rule you're looking for is going to look something like this:

if source attribute nspmPassword unavailable
do veto

Try upping the trace level on your driver to 5, then migrating a user you know does NOT have a UP set. That should make it easy to pick out which policy group the offending rule resides in. You can then disable the rule and users will flow. Just watch out for any password policies on your DC. If your users arrive in AD and don't comply with existing AD password policies, they may have their passwords changed. If you have bi-directional sync, this triggers an event, and that password would then be synced back to eDir. Not funny when that happens!

That said though, is there much point in having users in AD with an incorrect password set? The default AD driver in =<3.0 used to set the password to the user's surname, or alternatively just to "dirxml1". Looks like this behaviour has been changed to simlpy veto the migration. Seems fairly sensible to me!

0
 
mattpaulinAuthor Commented:
Hi Alex, excellent answer, we located and disabled the PW policy you mentioned and  all works! Thanks very much, that heads up was just what we needed.

Cheers
Matt
0
 
jamesromerCommented:
Just to add that Console One if running from a workstation with an nmas client installed will set the universal password.

cheers
0

Featured Post

Get your Disaster Recovery as a Service basics

Disaster Recovery as a Service is one go-to solution that revolutionizes DR planning. Implementing DRaaS could be an efficient process, easily accessible to non-DR experts. Learn about monitoring, testing, executing failovers and failbacks to ensure a "healthy" DR environment.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now