A way to detect final grace login?

[mwat...@mitre.org]

When a user's password has expired and they're on their final grace login the server will spit out a warning like this (captured from perl's Net::LDAP):

$VAR1 = bless( {
                 'raw' => undef,
                 'type' => '1.3.6.1.4.1.42.2.27.8.5.1',
                 'value' => '0♣�♥�☺ ',
                 'asn' => {
                            'warning' => {
                                           'graceAuthNsRemaining' => 0
                                         }
                          }
               }, 'Net::LDAP::Control::PasswordPolicy' );

Ldaptive doesn't seem to have a way to convey this state, however. In this case both timeBeforeExpiration and graceAuthNsRemaining are zero, but the zeros are a legitimate warning that the next login will fail. (Since Ldaptive has those values default to zero whether receiving a password policy notice or not)

Because graceAuthNsRemaining defaults to zero there doesn't seem to be a a way to check whether it was actually supplied by the server or not.

Here are logs comparing different use cases:
normal.txt - User isn't within ads-pwdexpirewarning
expires-soon.txt - User is within ads-pwdexpirewarning
expired-with-grace.txt - Password age is over ads-pwdmaxage, ads-pwdgraceauthnlimit is one and this is first login post-expiration (a diff of this with normal.txt is identical, which shouldn't be the case. With other clients you'll see the warning)
expired-no-grace.txt - Login attempt directly after above

Here's the ApacheDS password policy we're using:

ads-pwdcheckquality: 2
ads-pwdexpirewarning: 1209600
ads-pwdfailurecountinterval: 900
ads-pwdgraceauthnlimit: 1
ads-pwdgraceexpire: 0
ads-pwdinhistory: 12
ads-pwdlockout: TRUE
ads-pwdlockoutduration: 900
ads-pwdmaxage: 15552000
ads-pwdmaxfailure: 8
ads-pwdminage: 86400
ads-pwdminlength: 8
ads-pwdmustchange: TRUE

I'm happy to write a patch for it, but I can't see a clear solution. Or I could be missing something obvious somewhere.

Any thoughts on a proper solution?

-Marcus

[dfisher]

This may be a bug, as the control definition clearly allows the value 0 for both of those fields.

However, your server appears to be violating sections 8.1.2.3.2[1] and 8.1.2.4[1] which indicate to me that those states should never be returned from the server.

(Unless I'm misreading the RFC...)

--Daniel Fisher

[1] https://tools.ietf.org/html/draft-behera-ldap-password-policy-10

[Watkins, Marcus]

I think I see where I can be interpreted differently. This is ApacheDS’s behavior:

 

Before the authentication request the users’s password is expired, but has 1 grace authentication remaining (say, for example, they hadn’t logged in for years). It allows the auth, but that auth consumes the 1 grace authentication, so the response notes that there are zero grace authentications remaining. The client then should force a password change flow. (This is apacheDS’s current behavior and what we see if we use apache’s ldap api). If another auth is attempted after this, only then 8.1.2.3.2 would apply (and it does) sending an invalidCredentials back.

 

I think what you’re suggesting is that the bind should respond with a 1 for graceAuthNsRemaining on that initial bind, but I don’t agree since the bind *was* the last grace authentication, so there are now none remaining and a zero seems like the proper value to respond with.

 

But either way you interpret, really, there’s still a problem that it’s not possible to see whether the server actually responded with a zero for graceAuthNsRemaining since the value in the api value defaults to zero and there’s no api method to determine whether that value is just the default or was actually supplied by the server.

 

-Marcus

--
You received this message because you are subscribed to a topic in the Google Groups "ldaptive" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ldaptive/nzj62B_Z2js/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ldaptive+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Fisher]

I agree, I've filed this issue to track:

https://github.com/vt-middleware/ldaptive/issues/131

--Daniel Fisher

You received this message because you are subscribed to the Google Groups "ldaptive" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ldaptive+u...@googlegroups.com.