I am running IDM 4.0.1. Users are being created with a BEIS driver. The
BEIS driver sets the user's initial password via policy. From trace files
it appears to do these two things in separate steps: 1) create the user 2)
set the password. I have the driver configured to place new student users
being created in a separate container (initial). I am using the
ChallengeSet driver from Cool Solutions to pre-populate those user's
challenge questions and responses. I would like to trigger a move for these
users after they reset their password the first time after being created.
I discovered that the pwdChangedTime would probably be the best way to
trigger the move. I created a Loopback driver that does the following:
1. operation not equal add
2. operation equal modify (*I discovered that change password events were
seen as modify)
3. source DN in container Initial
4. operational attribute pwdChangedTime changing
Then this is were I was having problems due to the way the BEIS driver was
creating the user then in a separate event setting the password. This was
causing an immediate move since the policy was initiating a separate event
to set the password. So I decided that I would add one more condition to
check an attribute that is set after the user is created. For testing I
simply chose 'spouse' equal "Created". So I tried to set a rule in the
Loopback driver on user adds to set this attribute (thinking that the
setting of the default password by the BEIS driver would have happened).
The Loopback driver kept giving me errors saying "no destination dn found"
so I keep trying to find a way to accomplish this. I tried adding a rule
just after the setting of the Default Password in the BEIS driver to set
this attribute, but this was still setting it immediately so that by the
time the loopback driver saw the pwdChangedTime, the Flag attribute was
already set to the value.
Any suggestions on how to ignore the initial password set by the policy but
trigger on the next password change?
Thanks for any and all help,