Home

Results 1 to 4 of 4

Thread: move user after first password reset

Hybrid View

  1. #1
    Join Date
    Apr 2009
    Posts
    32

    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


  2. #2
    Join Date
    Jan 2009
    Location
    Stavanger, Norway
    Posts
    1,729

    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.

  3. #3
    Join Date
    Jan 2009
    Location
    Stavanger, Norway
    Posts
    1,729

    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.

  4. #4

    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.


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •