Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Anonymous_User Absent Member.
Absent Member.
1288 views

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

Labels (1)
0 Likes
10 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Require Unique Password Setting is not Working.

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...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Require Unique Password Setting is not Working.


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

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Require Unique Password Setting is not Working.

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...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Require Unique Password Setting is not Working.


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

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Require Unique Password Setting is not Working.

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...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Require Unique Password Setting is not Working.


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

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Require Unique Password Setting is not Working.


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 = "(&(objectclass=user)(cn=$id))";
my $attnames = [ "dn", "lockedByIntruder" ];
my $count = 0;

# Connect to the server
my $ldap = "";
until ( $ldap = Net::LDAP->new( $EDIRHOST, port => $PORT ) ) {
if ( ++$count > LDAP_RETRIES ) {
$errorMessage =
"Could not connect to the directory. Service unavailable. Try again
later, or contact the IT Service Desk.";
ajaxError( 3, $errorMessage );
croak($errorMessage);
}

$count++;
sleep 1;
}

my $r = "";
$r = $ldap->bind( $EDIRADMIN, password => $EDIRCODE, version => 3
);
$errorMessage =
"Could not bind to the directory. Service unavailable. Try again later,
or contact the IT Service Desk."
if $r->code;
ajaxError( 3, $errorMessage ) if $r->code;
croak($errorMessage) if $r->code;

$r = $ldap->search(
base => $EDIRBASEDN,
scope => 'sub',
filter => $searchstring,
attrs => $attnames
);

foreach my $entry ( $r->entries ) {
print LOG "Processing dn: " . $entry->dn . "\n";
my $changeCN = $entry->dn;
my $locked = "No_Attribute_present";
$locked = $entry->get_value('lockedByIntruder')
if ( $entry->get_value('lockedByIntruder') );
print LOG
"changeCN $changeCN locked status $locked submitted via
process 5\n";
my $altSuccess = 0;

if ( $locked eq "TRUE" ) {
$r =
$ldap->modify( "$changeCN",
add => { userPassword => ["$pass1"] } );
$errorMessage =
"You may not reuse any of your last seven passwords. Please choose
another password."
if $r->code;
ajaxError( 3, $errorMessage ) if $r->code;
croak($errorMessage) if $r->code;

$r = $ldap->modify( "$changeCN",
replace => { passwordExpirationTime =>
["$newExpirationDate"] }
);
$errorMessage =
"Internal directory error. Please contact the IT Service
Desk."
if $r->code;
ajaxError( 3, $errorMessage ) if $r->code;
croak($errorMessage) if $r->code;

$r =
$ldap->modify( "$changeCN",
replace => { lockedByIntruder => ["FALSE"] } );
$errorMessage =
"Internal directory error. Please contact the IT Service
Desk."
if $r->code;
ajaxError( 3, $errorMessage ) if $r->code;
croak($errorMessage) if $r->code;

$altSuccess = 1;
print LOG
"Changed password for LOCKED account $changeCN
successfully\n";
}
else {
$r =
$ldap->modify( "$changeCN",
add => { userPassword => ["$pass1"] } );
$errorMessage =
"You may not reuse any of your last seven passwords. Please choose
another password."
if $r->code;
ajaxError( 3, $errorMessage ) if $r->code;
croak($errorMessage) if $r->code;

$r = $ldap->modify( "$changeCN",
replace => { passwordExpirationTime =>
["$newExpirationDate"] }
);
$errorMessage =
"Internal directory error. Please contact the IT Service Desk."
if $r->code;
ajaxError( 3, $errorMessage ) if $r->code;
croak($errorMessage) if $r->code;

print LOG "Password change for $changeCN successful.\n";
}
}

$ldap->unbind;
}
Please note. 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). Basically this does work, but only when there is not password
policy assigned.

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.


No I am not using "iManager: Passwords: Set Universal Password" to set
the password. I use "iManager: Modify User: Restrictions: Set
Password". So you are correct that I am going to the user directly to
set the password. I think this method does set the UP because this has
always worked for us (including the "Require Unique Password" setting).
I tested your method ("iManager: Passwords: Set Universal Password") and
I get the same results. Even though "Require Unique Passwords" is set
to "True", I can still set the same password over and over without
error.


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:


I do have those settings configured. I have it set to "Require unique
passwords: Remove password from history list when the list is full:
History list size: 7 passwords". I attached a screenshot for your
reference.

278

I also tried creating a new password policy in case there is some
corruption in our current policy, but I got the same results.

Let me know what you think. Thanks.


+----------------------------------------------------------------------+
|Filename: edirppolicy.png |
|Download: https://forums.netiq.com/attachment.php?attachmentid=278 |
+----------------------------------------------------------------------+

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

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Require Unique Password Setting is not Working.

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...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Require Unique Password Setting is not Working.


ab;256351 Wrote:
> 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):
>


I understand your point however, why is the "Require unique password"
setting respected when I (as an admin user) change the password of a
user who does not have a password policy assigned? Why is the password
history not being ignored in this case?

The only time that "Require unique password" is not respected is when a
password policy is assigned to a user account (password policy shown in
the screenshots).

In addition, we didn't have any issues with "Require unique passwords"
until we migrated over to the new Edirectory tree (both the old and new
edirectory tree are v8.8sp5). In the old Edirectory tree, users were
changing their own passwords and Admins were changing other user's
passwords with the "Require unique password" setting working as it
should (the password history was not being ignored for Admins). I'm
pretty sure we broke something, but I can't seem to figure out what it
is.

Any thoughts?


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

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Require Unique Password Setting is not Working.

On 04/13/2015 09:04 AM, wanman wrote:
>
> I understand your point however, why is the "Require unique password"
> setting respected when I (as an admin user) change the password of a
> user who does not have a password policy assigned? Why is the password
> history not being ignored in this case?


If you do not have a password policy assigned then are presumably using
the NDS Password method, which has different (older) rules. Because the
password is not something that the system can determine from its stored
hash, the logic is simpler, even if less-wonderful from a security
perspective.

> The only time that "Require unique password" is not respected is when a
> password policy is assigned to a user account (password policy shown in
> the screenshots).


Yes, because Universal Password (UP) is governing things.

> In addition, we didn't have any issues with "Require unique passwords"
> until we migrated over to the new Edirectory tree (both the old and new
> edirectory tree are v8.8sp5). In the old Edirectory tree, users were
> changing their own passwords and Admins were changing other user's
> passwords with the "Require unique password" setting working as it
> should (the password history was not being ignored for Admins). I'm
> pretty sure we broke something, but I can't seem to figure out what it
> is.


If in your old tree you were not using UP for whatever reason then that
would explain things, as the admin-reset of password via LDAP would have
worked just like your admin-reset via iManager does not, via NDS Password
rules.

It may be worth noting that the password history functionality with NDS
Password is not perfect whenever an admin resets things. If you reset the
password on serverA, which is where the user's password was first set,
history of all time will be preserved. The user cannot use passwords from
prior to the admin reset, as you would expect ("password history" should
be irrespective of replicas where changes actually happen). If you
perform the admin reset on another replica, though, then the old history
is lost. Oops.... oversight of how the admin reset works in old NDS
Password stuff. Anyway, just a caveat. If you want password history to
work properly then you need to use Universal Password. If you want admins
to follow a user's password history, well, that's just odd. Why would
that be, if you do not mind sharing?

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
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.