morganginga Absent Member.
Absent Member.
355 views

move user after first password reset

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.

Issues:
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,
-Morgan

Labels (1)
0 Likes
3 Replies
Knowledge Partner
Knowledge Partner

Re: move user after first password reset

On 14.12.2011 22:05, morganginga wrote:
> 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.
>
> Issues:
> 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?


If you ensure that the initial password set by your user source system
is "expired", then you can do a compare on the value of the "Password
Expiration Time" attribute to determine whether the password was set by
the BEIS driver or by the user choosing a new password.

Review your universal password policies, I believe the combination you
need is "require unique passwords" enabled and "Do not expire the user's
password when the administrator sets the password" off. Also, you need
to enable "users must change their password after x days"

Compare the value of "Password Expiration Time" with the current
date/time, if it is higher, then the password has been set by the user
and you should trigger the move of the user to the other OU.

The time format used by "Password Expiration Time" is CTIME.
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Knowledge Partner
Knowledge Partner

Re: move user after first password reset

On 14.12.2011 22:46, Alex McHugh wrote:

> Review your universal password policies, I believe the combination you
> need is "require unique passwords" enabled and "Do not expire the user's
> password when the administrator sets the password" off. Also, you need
> to enable "users must change their password after x days"
>
> Compare the value of "Password Expiration Time" with the current
> date/time, if it is higher, then the password has been set by the user
> and you should trigger the move of the user to the other OU.
>
> The time format used by "Password Expiration Time" is CTIME.


If you don't want to implement "users must change their password after x
days" then when the user changes their password, I believe NMAS will
clear the "Password Expiration Time" attribute. So you can trigger on
that also.
Alex McHugh - Knowledge Partner - Stavanger, Norway
Who are the Knowledge Partners
If you appreciate my comments, please click the Like button.
If I have resolved your issue, please click the Accept as Solution button.
0 Likes
Knowledge Partner
Knowledge Partner

Re: move user after first password reset

On Wed, 14 Dec 2011 21:05:50 +0000, morganginga wrote:

> 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 wouldn't personally do this, but logic akin to this should work:

On your Null (not loopback) driver:

if operation = modify (or modify-password)
and if source dn is in subtree (initial create container)
and if source attribute yourOrgNewlyCreatedAccount is Not Available
and if attribute nspmDistributionPassword is available
set source attribute yourOrgNewlyCreatedAccount = True
veto

if operation = modify (or modify-password)
and if source attribute yourOrgNewlyCreatedAccount is True
and if source dn is not in (wherever)
and if attribute nspmDistributionPassword is available
move source object (@src-dn) to (wherever)
delete source attribute yourOrgNewlyCreatedAccount

This should allow the initial create, then the first password change sets
up the system so that the second password change triggers the object move.


> 1. operation not equal add
> 2. operation equal modify (*I discovered that change password events
> were seen as modify)


Note that these two conditions are mutually exclusive, so one of them is
redundant. If the operation *is* a modify, it *cannot* be an add.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.novell.com

Please post questions in the forums. No support provided via email.

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.