Knowledge Partner
Knowledge Partner
777 views

NMAS Universal Pass Policy - History list/age question

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
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). 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.

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

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)?--Actually no, this does NOT work. NMAS keeps re-setting the date to "now", so that's not even an option.

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)?

I've got a "sorta" workaround by using SSPR, provided the user has used SSPR to answer their challenge/response questions (won't work if you use the Novell Client to answer your challenge/response questions for some reason) - in that, SSPR "forgotten password" seems to bypass the 24 hour setting. Novell Client, however, will adhere to that.
Labels (1)
0 Likes
4 Replies
Knowledge Partner
Knowledge Partner

Re: NMAS Universal Pass Policy - History list/age question

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.

https://xkcd.com/936/

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.

https://www.riskcontrolstrategies.com/2018/01/08/new-nist-guidelines-wrong/

> 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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: NMAS Universal Pass Policy - History list/age question

ab;2493143 wrote:
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.

https://xkcd.com/936/

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.

https://www.riskcontrolstrategies.com/2018/01/08/new-nist-guidelines-wrong/

> 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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: NMAS Universal Pass Policy - History list/age question

On 01/04/2019 09:54 AM, kjhurni wrote:
>
> 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.


I think the most-likely reason is that SSPR can run as an admin when doing
these changes, where the Novell Client only knows the user's own
credentials so it can only ever act as 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.
0 Likes
Knowledge Partner
Knowledge Partner

Re: NMAS Universal Pass Policy - History list/age question

ab;2493178 wrote:
On 01/04/2019 09:54 AM, kjhurni wrote:
>
> 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.


I think the most-likely reason is that SSPR can run as an admin when doing
these changes, where the Novell Client only knows the user's own
credentials so it can only ever act as 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.


Interesting. It may be that way.
Although when I enabled debug logging to figure out why SSPR won't read NMAS challenge/response when the answers are filled in with the Novell Client (vs. using SSPR to answer the original questions), the debug logs showed it would authenticate (or attempt to do so) as the actual user, vs. Admin/proxy account.
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.