Quote Originally Posted by ab View Post
On 01/03/2019 01:44 PM, kjhurni wrote:
> I'm assuming this is working as designed, but just wanted to make sure:
> UP Policy is set to use MS 2008 Complexity
> Require unique passwords
> Remove passwords when list is full. History list size: 13
> Number of days before pass can be changed: 1

I personally think a minimum number of days causes more pain than it fixes
when you are already using password history. If users reusing passwords
is really a problem, just make the history something like 50 and then, if
they really reset their password that many times to work around the
system, you should probably show them the door. Even at thirteen (13)
passwords they're going to waste thirty (30) minutes just working around
the security.

> Number of days before pass expires: 90
> Now, user either can't/won't use the Forgotten Password (see my post in
> the SSPR forum for issues we're having), so calls the helpdesk.
> Helpdesk manually changes his password, which of course, expires the
> password.
> User logs in with new password and is prompted to change their
> password.
> User changes their password.
> Next day (within 24 hours), user forgets again (yeup).

I'm curious if you, like myself, ever try to figure out the cost (in
company's payment of your time) for working around one user's lack of
ability to do this properly. If so, you may find it time to help them
learn to remember a password by helping them come up with one that meets
requirements but is easy to remember.


If your policies prevent strong passwords according to the old way of
thinking (lots of complexity, less focus on length), then perhaps fix
that. NIST (and others they have poorly influenced) came around a year or
two ago, finally admitting their mistake in a drive toward complexity
without considering the human factor.


> Doesn't/can't/won't use the Forgotten Password (although it wouldn't
> work anyway in my testing--at least with the latest Novell Cliient).
> Calls helpdesk to have his password reset/changed.

A Challenge/Response is still a login, so password requirements still
apply unless the application (SSPR may do this where the Novell/OES client
will not) does the password change as a preconfigured admin.

> Helpdesk does that. Which expires the password.
> User logs in and is prompted to change password, but can't because:

Does your Universal Password (UP) policy include grace logins? More than
a few?

> BTW, same would happen if user tried to use (successfully) the Forgotten
> Password and correctly answered their challenge/response questions,
> because 1 day hasn't passed. --At least if using the Novell client.
> Seems that SSPR bypasses (at least in my testing with our version) this
> magical loophole, but only on a Forgotten Password.
> Q1: I'm assuming the 1 day time for the UP setting hasn't been met yet
> (SSPR doesn't tell me why the password can't be changed, just that it
> doesn't match the requirements)?

Turn up logging, or if you are using NMAS on the backend for challenge
response as I presume you are since the Novell/OES client can also do it,
then check the eDirectory trace via ndstrace with +TIME +TAGS +AUTH +NMAS
and hopefully you'll see a nice clean error in the -16xx or -16xxx range
with a definition we all understand.

> Q2: Only "workarounds" I've found would be to manually increase his
> expiration date of the password by 1 day so user could login with "temp"
> password until the 24 hours has lapsed?
> Any other workarounds (short of abusing the user)?

Disabusing the user. :-)

Good luck.

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

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
I'll try to turn up the logging and see what it shows.
Novell Client will report NMASUserInvalid

Oh, and aparently my edit didn't make it through to the NNTP feed in time:
Workaround by increasing the expiration date of password doesn't work since, upon login, the system resets it since it apparently knows someone other than the user changed it. I guess it makes sense.

Unfortunately I'm just the implementer and the geniuses that run the place now don't listen to anyone/anything/reason.

So the *only* fix I could come up with was that I re-assigned the user to a different password policy, logged in as the user, changed the password (to something that would match the regular/default policy), then re-assigned the user back and they were able to login and not prompted to change their password. I told them they'd have to wait 24 hours before they could change it.

I'm more puzzled as to why SSPR has different behavior vs. NOvell client on a lot of things, but nobody ever responded, and unfortunately I can't open SR's, so I've just documented what works/doesn't and when/where.