Require Unique Password Setting is not Working.


We are running IDM v4.x with Edir v8.8.sp5. We are also using iManager
v2.7. Our IDM vault is Edirectory and it syncs to Active Directory and
Google.

We have all our standard users in a USERS OU. Our Administrative and
Non-Person accounts are in separate OU's (TNSAdmins and NonPerson,
respectively). The Standard and NonPerson user OU's have the following
password policy assigned--> 274

The Administrative users' OU does not have any password policy
assigned.

When I try to change a standard or NonPerson user account's password to
something they have already used, iManager allows me to do it. For the
Administrative users, it does not allow me to do it.

I believe I have the setting correct. Specifically "Require unique
passwords" and "Enable Universal Password", however the unique password
setting is not being enforced.

What am I doing wrong?

Also, what are the default password policy settings when a user account
does not have a Password Policy assigned?


----------------------------------------------------------------------
|Filename: password policy.JPG |
|Download: https://forums.netiq.com/attachment.php?attachmentid=274 |
----------------------------------------------------------------------

--
wanman
------------------------------------------------------------------------
wanman's Profile: https://forums.netiq.com/member.php?userid=8371
View this thread: https://forums.netiq.com/showthread.php?t=53279

Tags:

  • On 04/07/2015 01:34 PM, wanman wrote:
    >
    > We are running IDM v4.x with Edir v8.8.sp5. We are also using iManager
    > v2.7. Our IDM vault is Edirectory and it syncs to Active Directory and
    > Google.
    >
    > We have all our standard users in a USERS OU. Our Administrative and
    > Non-Person accounts are in separate OU's (TNSAdmins and NonPerson,
    > respectively). The Standard and NonPerson user OU's have the following
    > password policy assigned--> 274


    I'm not sure what '274' means.

    > The Administrative users' OU does not have any password policy
    > assigned.


    If you do not apply a policy somehow, then Universal Password (UP) is not
    in use. To see if this is the case, use the iManager: Password: "View
    Policy Assignments' task to point to a user in the container and see if
    iManager identifies any policy as being applicable for that user.

    > When I try to change a standard or NonPerson user account's password to
    > something they have already used, iManager allows me to do it. For the
    > Administrative users, it does not allow me to do it.


    You are, presumably, an eDirectory administrator. As a result, UP does
    not make YOU follow the password history rules. The reason is that YOU
    should never know whether or not a user has used a given password in the
    past, as that lets you know passwords they may use in other places, giving
    you the ability to impersonate them in those other systems (banks, hR,
    etc.). Also, as admins are often helpdesk folks, sometimes a
    commonly-reset value (which is a terrible thing) gets up getting set on a
    forgetful user over and over. In all cases (by default) when an
    administrator resets a user's password, it is immediately expired
    requiring the user to change it to a value that they, alone, know,
    negating the problems of the second situation I mentioned above.

    > I believe I have the setting correct. Specifically "Require unique
    > passwords" and "Enable Universal Password", however the unique password
    > setting is not being enforced.


    True; see above. It is only NOT enforced because you are an
    administrator. If the user tries to change their password to a previous
    value, it should prevent that.

    > What am I doing wrong?


    Misunderstanding, that is all.

    > Also, what are the default password policy settings when a user account
    > does not have a Password Policy assigned?


    If you do not apply UP, then you fall back on the NDS Password scheme,
    which is set on a per-user basis.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...
  • On 04/07/2015 01:34 PM, wanman wrote:
    >
    > We are running IDM v4.x with Edir v8.8.sp5. We are also using iManager
    > v2.7. Our IDM vault is Edirectory and it syncs to Active Directory and
    > Google.
    >
    > We have all our standard users in a USERS OU. Our Administrative and
    > Non-Person accounts are in separate OU's (TNSAdmins and NonPerson,
    > respectively). The Standard and NonPerson user OU's have the following
    > password policy assigned--> 274


    I'm not sure what '274' means.

    > The Administrative users' OU does not have any password policy
    > assigned.


    If you do not apply a policy somehow, then Universal Password (UP) is not
    in use. To see if this is the case, use the iManager: Password: "View
    Policy Assignments' task to point to a user in the container and see if
    iManager identifies any policy as being applicable for that user.

    > When I try to change a standard or NonPerson user account's password to
    > something they have already used, iManager allows me to do it. For the
    > Administrative users, it does not allow me to do it.


    You are, presumably, an eDirectory administrator. As a result, UP does
    not make YOU follow the password history rules. The reason is that YOU
    should never know whether or not a user has used a given password in the
    past, as that lets you know passwords they may use in other places, giving
    you the ability to impersonate them in those other systems (banks, hR,
    etc.). Also, as admins are often helpdesk folks, sometimes a
    commonly-reset value (which is a terrible thing) gets up getting set on a
    forgetful user over and over. In all cases (by default) when an
    administrator resets a user's password, it is immediately expired
    requiring the user to change it to a value that they, alone, know,
    negating the problems of the second situation I mentioned above.

    > I believe I have the setting correct. Specifically "Require unique
    > passwords" and "Enable Universal Password", however the unique password
    > setting is not being enforced.


    True; see above. It is only NOT enforced because you are an
    administrator. If the user tries to change their password to a previous
    value, it should prevent that.

    > What am I doing wrong?


    Misunderstanding, that is all.

    > Also, what are the default password policy settings when a user account
    > does not have a Password Policy assigned?


    If you do not apply UP, then you fall back on the NDS Password scheme,
    which is set on a per-user basis.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...
  • On 04/07/2015 01:34 PM, wanman wrote:
    >
    > We are running IDM v4.x with Edir v8.8.sp5. We are also using iManager
    > v2.7. Our IDM vault is Edirectory and it syncs to Active Directory and
    > Google.
    >
    > We have all our standard users in a USERS OU. Our Administrative and
    > Non-Person accounts are in separate OU's (TNSAdmins and NonPerson,
    > respectively). The Standard and NonPerson user OU's have the following
    > password policy assigned--> 274


    I'm not sure what '274' means.

    > The Administrative users' OU does not have any password policy
    > assigned.


    If you do not apply a policy somehow, then Universal Password (UP) is not
    in use. To see if this is the case, use the iManager: Password: "View
    Policy Assignments' task to point to a user in the container and see if
    iManager identifies any policy as being applicable for that user.

    > When I try to change a standard or NonPerson user account's password to
    > something they have already used, iManager allows me to do it. For the
    > Administrative users, it does not allow me to do it.


    You are, presumably, an eDirectory administrator. As a result, UP does
    not make YOU follow the password history rules. The reason is that YOU
    should never know whether or not a user has used a given password in the
    past, as that lets you know passwords they may use in other places, giving
    you the ability to impersonate them in those other systems (banks, hR,
    etc.). Also, as admins are often helpdesk folks, sometimes a
    commonly-reset value (which is a terrible thing) gets up getting set on a
    forgetful user over and over. In all cases (by default) when an
    administrator resets a user's password, it is immediately expired
    requiring the user to change it to a value that they, alone, know,
    negating the problems of the second situation I mentioned above.

    > I believe I have the setting correct. Specifically "Require unique
    > passwords" and "Enable Universal Password", however the unique password
    > setting is not being enforced.


    True; see above. It is only NOT enforced because you are an
    administrator. If the user tries to change their password to a previous
    value, it should prevent that.

    > What am I doing wrong?


    Misunderstanding, that is all.

    > Also, what are the default password policy settings when a user account
    > does not have a Password Policy assigned?


    If you do not apply UP, then you fall back on the NDS Password scheme,
    which is set on a per-user basis.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...

  • The --> 274 is supposed to show the attached screenshot of my password
    policy setting. Not sure why its displaying "274" instead. I attached
    it again in this reply. 275

    \"IF YOU DO NOT APPLY A POLICY SOMEHOW, THEN UNIVERSAL PASSWORD (UP) IS
    NOT
    IN USE. TO SEE IF THIS IS THE CASE, USE THE IMANAGER: PASSWORD: \"VIEW
    POLICY ASSIGNMENTS' TASK TO POINT TO A USER IN THE CONTAINER AND SEE IF
    IMANAGER IDENTIFIES ANY POLICY AS BEING APPLICABLE FOR THAT USER.\"

    I should've explained further. We do not want a password policy for the
    administrative users. So this is by our design. I was just including
    this to show the difference between the Administrative OU and the
    Standard and NonPerson users OU. Please note...When logged into
    iManager with my administrative account, I *cant* reset an
    administrative user to an already used password, but I *can* reset a
    standard or nonperson user to an already used password. I would like
    the behavior to be the reverse.

    \"YOU ARE, PRESUMABLY, AN EDIRECTORY ADMINISTRATOR. AS A RESULT, UP
    DOES
    NOT MAKE YOU FOLLOW THE PASSWORD HISTORY RULES. THE REASON IS THAT YOU
    SHOULD NEVER KNOW WHETHER OR NOT A USER HAS USED A GIVEN PASSWORD IN
    THE
    PAST, AS THAT LETS YOU KNOW PASSWORDS THEY MAY USE IN OTHER PLACES,
    GIVING
    YOU THE ABILITY TO IMPERSONATE THEM IN THOSE OTHER SYSTEMS (BANKS, HR,
    ETC.). ALSO, AS ADMINS ARE OFTEN HELPDESK FOLKS, SOMETIMES A
    COMMONLY-RESET VALUE (WHICH IS A TERRIBLE THING) GETS UP GETTING SET ON
    A
    FORGETFUL USER OVER AND OVER. IN ALL CASES (BY DEFAULT) WHEN AN
    ADMINISTRATOR RESETS A USER'S PASSWORD, IT IS IMMEDIATELY EXPIRED
    REQUIRING THE USER TO CHANGE IT TO A VALUE THAT THEY, ALONE, KNOW,
    NEGATING THE PROBLEMS OF THE SECOND SITUATION I MENTIONED ABOVE.\"


    Again, I probably didn't explain my issue properly. I don't want a
    standard or nonperson user to be able to reset their password to an
    already used password. Our policy is set to "Require unique passwords"
    but a user is still able to reset their password to an already used
    password. I don't see this behavior with our administrative users who
    do not have a password policy set. I understand about the auto
    expiration and that is fine and how we have it setup.

    \"TRUE; SEE ABOVE. IT IS ONLY NOT ENFORCED BECAUSE YOU ARE AN
    ADMINISTRATOR. IF THE USER TRIES TO CHANGE THEIR PASSWORD TO A PREVIOUS
    VALUE, IT SHOULD PREVENT THAT\"

    I don't agree because as an administrator I cant reset an administrative
    account to an already used password but I can do this with a standard or
    non person user account. I have been testing this with test accounts
    which is why I keep referring to myself as resetting user and nonperson
    passwords. However, it was the users that actually informed us that
    this is the case.

    Hopefully this gives you a better picture of my issue.

    Something is very wrong because my password policy has "Require Unique
    passwords" enabled, but its not being enforced for the users attempting
    to change their own password or the admins trying to change the password
    for them. The only place (OU) it is enforced is the administrative OU,
    which by the way does not have any password policies assigned to it (but
    I do manually check the "Require Unique Password" setting before
    changing the password). The users definitely have the policy assigned.
    I checked with the "View Policy Assignments" task.

    Thanks for your help.


    ----------------------------------------------------------------------
    |Filename: password policy.JPG |
    |Download: https://forums.netiq.com/attachment.php?attachmentid=275 |
    ----------------------------------------------------------------------

    --
    wanman
    ------------------------------------------------------------------------
    wanman's Profile: https://forums.netiq.com/member.php?userid=8371
    View this thread: https://forums.netiq.com/showthread.php?t=53279

  • How, specifically, with lots of details, do your admins and your users try
    to change passwords? If you apply a UP policy to a user (however you do
    it) and then the user logs in with something that is not NMAS-enabled and
    changes their password, then NMAS rules are not applied. This can happen
    with things like the Novell Client if you change the defaults (to remove
    or disable the NMAS client), or when passwords are changed via very, very
    old Novell clients (something prior to XP), or maybe using other odd
    clients that do not understand NMAS properly (Kanaka? or things that use
    it like Macs), or very old servers (ancient NetWare services), etc.

    If you want to see if NMAS is really applied, the best, most-conclusive
    way is to get an ndstrace from the server that is receiving the password
    change.


    ndstrace
    set dstrace=nodebug
    dstrace time tags auth nmas
    dstrace file on
    set dstrace=*r
    #perform testing here, like password changes
    dstrace file off
    quit


    Post the ndstrace.log file generated (by default under
    /var/opt/novell/eDirectory/log/ndstrace.log on your server) somewhere
    (here if it fits, or elsewhere like pastebin/SUSEPaste and then link to it
    from here).

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...

  • ab;256127 Wrote:
    > How, specifically, with lots of details, do your admins and your users
    > try
    > to change passwords? If you apply a UP policy to a user (however you
    > do
    > it) and then the user logs in with something that is not NMAS-enabled
    > and
    > changes their password, then NMAS rules are not applied. This can
    > happen
    > with things like the Novell Client if you change the defaults (to
    > remove
    > or disable the NMAS client), or when passwords are changed via very,
    > very
    > old Novell clients (something prior to XP), or maybe using other odd
    > clients that do not understand NMAS properly (Kanaka? or things that
    > use
    > it like Macs), or very old servers (ancient NetWare services), etc.
    >
    > If you want to see if NMAS is really applied, the best, most-conclusive
    > way is to get an ndstrace from the server that is receiving the
    > password
    > change.
    >
    > >

    Code:
    --------------------
    > >

    > ndstrace
    > set dstrace=nodebug
    > dstrace time tags auth nmas
    > dstrace file on
    > set dstrace=*r
    > #perform testing here, like password changes
    > dstrace file off
    > quit
    >

    --------------------
    > >

    >
    > Post the ndstrace.log file generated (by default under
    > /var/opt/novell/eDirectory/log/ndstrace.log on your server) somewhere
    > (here if it fits, or elsewhere like pastebin/SUSEPaste and then link
    > to it
    > from here).
    >
    > --
    > Good luck.
    >
    > If you find this post helpful and are logged into the web interface,
    > show your appreciation and click on the star below...


    Some background on our implementation of Edirectory.

    We used to be a Novell shop running Netware, iprint, zenworks, and IDM.
    We migrated to Active Directory and kept only IDM. All of our Novell
    software was removed from our workstations. Late last year we migrated
    from IDM v3.x to IDM v4.x. We did not migrate our original Edirectory
    tree, we built a new Edirectory tree for our IDM v4.x implementation
    (Running on Red Hat 6). We then used IDM to perform and edirectory to
    edirectory sync of our users and groups. That was the last piece of our
    migration.

    We always had a password change page to allow users to change their
    passwords. Our web admins built this password change page for us using
    a perl script. The perl script uses ldap to push the password changes
    to edirectory. Users never changed their passwords from the Novell
    client, or any other method other than the Password change page. Only
    Admins (Helpdesk) change passwords for users when issues arise (using
    iManager). Using this method we never had a problem with "Require
    Unique Passwords" not working. Our password change page was updated to
    point to the new Edirectory tree.

    You mentioned NMAS is important to password changes. Is this only for
    the workstations, or does our IDM/Edirectory Server also need Nmas
    installed? Ill try the dstrace you recommended and reply back with
    that.

    Please note. Once I heard of this issue, I started testing with
    iManager. I am changing the passwords of some test accounts in order to
    see the behavior. When I change a password for a user account that does
    not have a password policy associated (I checked with the "view policy
    assignments" option), I can check the box for "Require Unique Password"
    and it works. When I change a password for a user account that has a
    password policy associated (we only have 1 password policy) the "Require
    Unique Password" setting does not work (no matter if I check or uncheck
    the box). This behavior seems to indicate that I have an incorrect
    setting somewhere in my policy because it works if a password policy is
    not associated. The correct setting seems to be assigned when no
    password policy is associated. This is why I would like to know what
    the default password policy settings are so I can compare. This
    behavior also seems to indicate the the necessary modules (ex. NMAS) are
    in place because the "require unique password" setting does work when no
    password policy is assigned.


    --
    wanman
    ------------------------------------------------------------------------
    wanman's Profile: https://forums.netiq.com/member.php?userid=8371
    View this thread: https://forums.netiq.com/showthread.php?t=53279

  • On 04/08/2015 06:54 AM, wanman wrote:
    >
    > We used to be a Novell shop running Netware, iprint, zenworks, and IDM.
    > We migrated to Active Directory and kept only IDM. All of our Novell
    > software was removed from our workstations. Late last year we migrated
    > from IDM v3.x to IDM v4.x. We did not migrate our original Edirectory
    > tree, we built a new Edirectory tree for our IDM v4.x implementation
    > (Running on Red Hat 6). We then used IDM to perform and edirectory to
    > edirectory sync of our users and groups. That was the last piece of our
    > migration.
    >
    > We always had a password change page to allow users to change their
    > passwords. Our web admins built this password change page for us using
    > a perl script. The perl script uses ldap to push the password changes
    > to edirectory. Users never changed their passwords from the Novell


    It may be useful to see exactly how this Perl script sends those LDAP
    commands. Within LDAP there are basically two ways to change a user's
    password, either by specifying the old password to be deleted (which
    implies that you know the old password, which implies that you are the
    user, thus a user-bsaed password change) or by just replacing the old
    value with the new value (implying you do not have the old password,
    implying you are an admin). If the code they wrote does not try to delete
    the old password before it sets the new password, then that code is
    effectively changing the password as the admin, even though a user (or
    other HTTP-based client from wherever) may be using it. If that is the
    case, then password history would NOT apply, as you are seeing.

    > client, or any other method other than the Password change page. Only
    > Admins (Helpdesk) change passwords for users when issues arise (using
    > iManager). Using this method we never had a problem with "Require
    > Unique Passwords" not working. Our password change page was updated to
    > point to the new Edirectory tree.
    >
    > You mentioned NMAS is important to password changes. Is this only for
    > the workstations, or does our IDM/Edirectory Server also need Nmas
    > installed? Ill try the dstrace you recommended and reply back with
    > that.


    eDirectory comes with NMAS, and has for a very long time; you do not have
    an option of not having it, and removing it somehow would be very bad.
    This is a last thing to check, probably, after making sure your server are
    powered on (it's about as certain). Good question, though.

    > Please note. Once I heard of this issue, I started testing with
    > iManager. I am changing the passwords of some test accounts in order to
    > see the behavior. When I change a password for a user account that does
    > not have a password policy associated (I checked with the "view policy
    > assignments" option), I can check the box for "Require Unique Password"
    > and it works. When I change a password for a user account that has a
    > password policy associated (we only have 1 password policy) the "Require
    > Unique Password" setting does not work (no matter if I check or uncheck
    > the box). This behavior seems to indicate that I have an incorrect


    Just to be clear, when you are setting the Universal Password (UP) you
    should be doing so via iManager: Passwords: Set Universal Password. Is
    that how you are doing it? Your description makes me think you may be
    going to the user directly, which may be accessing the default (non-UP)
    calls for password changes. I think it SHOULD do UP from there, but I do
    not know that it does, where with the 'Set Universal Password' task I know
    it will do UP, and only UP, and it does not have options there for you to
    set the password requirement.

    > setting somewhere in my policy because it works if a password policy is
    > not associated. The correct setting seems to be assigned when no


    I finally managed to see your screenshot and now I think I may see a
    problem. With password history in Universal Password (in your policy)
    there are options about how many days, or how many passwords, to keep in
    history. In your case I do not see those settings in the summary view.
    If you go to the main configuration page for your policy do you have those
    set? See the documentation here for the page to which I am referring:

    https://www.netiq.com/documentation/password_management33/pwm_administration/data/an4bun5.html


    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...

  • I just wanted to post the dstraces that I just did using the steps you
    posted. I'll look through your reply, check the settings you noted and
    get back to you. Thanks again.

    Here is the ndstrace.log when I change the password of a user with a
    password policy assigned: (This lets me set a password that was already
    used)

    952092416 NMAS: [2015/04/08 11:10:06.935] NMAS Audit with Audit PA not
    installed
    952092416 NMAS: [2015/04/08 11:10:06.935] NMAS Audit with XDAS not
    installed
    952092416 NMAS: [2015/04/08 11:10:06.935] Successful get distribution
    password for agrab705.users.idm_tree
    942253824 NMAS: [2015/04/08 11:10:06.953] NMAS Audit with Audit PA not
    installed
    942253824 NMAS: [2015/04/08 11:10:06.953] NMAS Audit with XDAS not
    installed
    942253824 NMAS: [2015/04/08 11:10:06.953] Successful get distribution
    password for agrab705.users.idm_tree
    976062208 NMAS: [2015/04/08 11:10:14.277] NMAS Audit with Audit PA not
    installed
    976062208 NMAS: [2015/04/08 11:10:14.277] NMAS Audit with XDAS not
    installed
    976062208 NMAS: [2015/04/08 11:10:14.284] Successful set password for
    CN=agrab705.OU=Users.O=IDM_tree
    952092416 NMAS: [2015/04/08 11:10:14.356] NMAS Audit with Audit PA not
    installed
    952092416 NMAS: [2015/04/08 11:10:14.356] NMAS Audit with XDAS not
    installed
    952092416 NMAS: [2015/04/08 11:10:14.356] Successful get distribution
    password for agrab705.users.idm_tree
    942253824 NMAS: [2015/04/08 11:10:14.373] NMAS Audit with Audit PA not
    installed
    942253824 NMAS: [2015/04/08 11:10:14.373] NMAS Audit with XDAS not
    installed
    942253824 NMAS: [2015/04/08 11:10:14.373] Successful get distribution
    password for agrab705.users.idm_tree


    Here is the ndstrace.log when I change the password of a user that does
    not have a password policy assigned: (This does not lets me set a
    password that was already used - and is the behavior we want)

    1055807232 NMAS: [2015/04/08 11:27:13.355] NMAS Audit with Audit PA not
    installed
    1055807232 NMAS: [2015/04/08 11:27:13.355] NMAS Audit with XDAS not
    installed

    In this case I get the error:
    The set password request failed
    The password has been used previously.


    --
    wanman
    ------------------------------------------------------------------------
    wanman's Profile: https://forums.netiq.com/member.php?userid=8371
    View this thread: https://forums.netiq.com/showthread.php?t=53279


  • IT MAY BE USEFUL TO SEE EXACTLY HOW THIS PERL SCRIPT SENDS THOSE LDAP
    COMMANDS. WITHIN LDAP THERE ARE BASICALLY TWO WAYS TO CHANGE A USER'S
    PASSWORD, EITHER BY SPECIFYING THE OLD PASSWORD TO BE DELETED (WHICH
    IMPLIES THAT YOU KNOW THE OLD PASSWORD, WHICH IMPLIES THAT YOU ARE THE
    USER, THUS A USER-BSAED PASSWORD CHANGE) OR BY JUST REPLACING THE OLD
    VALUE WITH THE NEW VALUE (IMPLYING YOU DO NOT HAVE THE OLD PASSWORD,
    IMPLYING YOU ARE AN ADMIN). IF THE CODE THEY WROTE DOES NOT TRY TO
    DELETE
    THE OLD PASSWORD BEFORE IT SETS THE NEW PASSWORD, THEN THAT CODE IS
    EFFECTIVELY CHANGING THE PASSWORD AS THE ADMIN, EVEN THOUGH A USER (OR
    OTHER HTTP-BASED CLIENT FROM WHEREVER) MAY BE USING IT. IF THAT IS THE
    CASE, THEN PASSWORD HISTORY WOULD NOT APPLY, AS YOU ARE SEEING.

    The perl module that changes the password is listed below:
    sub eDirPassSet {
    my $id = $_[0];
    my $pass1 = $_[1];
    my $errorMessage;
    my %result;

    my ( $currY, $currM, $currD, $hr, $min, $sec, $doy, $dow, $dst ) =
    System_Clock();

    my ( $year, $month, $day ) = Add_Delta_Days( $currY, $currM, $currD,
    180 );

    print LOG "eDirPassSet($id, xxxxxxxx)\n";

    if ( $month < 10 ) {
    $month = "0" . "$month";
    }
    if ( $day < 10 ) {
    $day = "0" . "$day";
    }
    if ( $hr < 10 ) {
    $hr = "0" . "$hr";
    }
    if ( $min < 10 ) {
    $min = "0" . "$min";
    }
    if ( $sec < 10 ) {
    $sec = "0" . "$sec";
    }

    # my $newExpirationDate = "$year" . "$month" . "$day" . "000000Z";
    my $newExpirationDate = "$year" . "$month" . "$day" . "$hr" . "$min"
    .. "$sec" . "Z";
    print LOG "new expiration date after formatting is
    $newExpirationDate\n";

    my $searchstring = "(
  • Good information; the result is as explained earlier; this is changing the
    user's password as an administrator (vs. as the user themselves) which
    causes the password history to be ignored. If you want this to be changed
    as a user, you need to have the operation delete the old password and add
    the new password in one step, as shown below, which implies that the
    application somehow gets the user's current/old password (usually by
    prompting them for the current password):


    dn: cn=user,ou=context,o=goes,dc=here
    changetype: modify
    delete: userPassword
    userPassword: currentValueGoesHere
    -
    add: userPassword
    userPassword: newPasswordGoesHere



    You can use the example above, with valid DNs/passwords, to verify the
    setup works as I have described using something like ldapmodify, Apache
    Directory Studio, or another valid LDAP client.

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...