I'm used to the behaviour of the NDS password, where when I create an
account and set its initial password, it starts out as expired so that
the user is forced to change it.

Then I implimented Universal Password, which doesn't work this way. The
initial password is set, and the expiration is set to the UP policy
value of (pwd last set time) + (pwd expiration interval time), so that
the user is _not_ initially forced to change it.

Wanting to have things the way they were before, it looks like this
works:

<rule>
<description>Create Default Password</description>
<conditions>
<and>
<if-class-name op="equal">User</if-class-name>
</and>
</conditions>
<actions>
<do-set-dest-password>
<arg-string>
<token-attr name="Surname"/>
</arg-string>
</do-set-dest-password>
<do-set-dest-attr-value name="Password Expiration Time" when="after">
<arg-value type="time">
<token-time format="!CTIME" tz="UTC"/>
</arg-value>
</do-set-dest-attr-value>
</actions>
</rule>

So long as I use when="after" on the do-set-dest-attr-value, it looks
like the object gets created, then the password gets set, then the
Password Expiration Time gets overwritten with the value specified
(right now).

But is this order of operation and timing garaunteed to work, or am I
just getting lucky here? If I'm understanding the whole UP / NMAS thing
right, then IDM creates the object, then hands the password off to NMAS
which does the UP / DP / etc. stuff with it based on its policies. Does
IDM wait for NMAS to be done before carrying on with the next operation,
which is my Password Expiration Time, or can IDM hand off the password
to NMAS then continue processing immediately?


---------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu

I'm tired of receiving rubbish in my mailbox, so the E-mail address is
munged to foil the junkmail bots. Humans will figure it out on their own.