(ITS#7596) OpenLDAP returning incorrect value for "graceAuthNsRemaining"

[nzipsi@gmail.com]

Full_Name: Andrew Thorburn
Version: 2.4.35
OS: N/A
URL: 
Submission from: (NULL) (203.97.178.157)


The problem is very simple: According to the Behera Password Policy Draft
(http://tools.ietf.org/html/draft-behera-ldap-password-policy-10), the attribute
graceAuthNsRemaining should be set to the number of grace authentications
remaining.

However, with the following policy extract:

pwdMaxAge: 1
pwdMustChange: TRUE
pwdAllowUserChange: TRUE
pwdSafeModify: TRUE
pwdGraceAuthNLimit: 2

Running ldapwhoami results in the following:

ldap_bind: Success (0) (Password expired, 2 grace logins remain)
dn:uid=ANDREWT,ou=People,dc=example,dc=com

That is not correct - there is only a single grace login remaining. I have used
up one of the two grace logins provided by binding to OpenLDAP to execute the
ldapwhoami command.

Executing the same command twice more results in the following:

$ ldapwhoami -h remotehost -e ppolicy -D uid=ANDREWT,ou=People,dc=example,dc=com
-w andrew10
ldap_bind: Success (0) (Password expired, 1 grace logins remain)
dn:uid=ANDREWT,ou=People,dc=example,dc=com

$ ldapwhoami -h remotehost -e ppolicy -D uid=ANDREWT,ou=People,dc=example,dc=com
-w andrew10
ldap_bind: Invalid credentials (49); Password expired

Whereas I would have assumed, both from the message returned and from the
language in the draft, that the first invocation would have said "(Password
expired, 1 grace logins remain)", followed by then denying access for the next
two invocations. Well, actually, what I would *expect* to happen is the first
would return "1 remains", the second "0 remain" and the third would deny access,
but the draft policy is pretty explicit, IMO, that the former is what should
happen (which is daft).

Now, according to the spec:

"If there are remaining grace authentications as per Section 7.4, the
server adds a new value with the current time in pwdGraceUseTime.
Then it sends to the client a response with an appropriate successful
resultCode (i.e. success (0), compareTrue (6), etc.), and includes
the passwordPolicyResponse in the controls field of the response
message with the warning: graceAuthNsRemaining choice set to the
number of grace authentications left."

This suggests, at least to me, that a new value should be added to
pwdGraceUseTime *before* calculating the number of remaining grace logins.
Admittedly, that wouldn't actually fix the issue, as it would result in the
final grace login failing. Oops.

This looks a lot like a bug to me, but at the same time, it also seems to be
trying to adhere to the letter of the policy while also doing what is expected
(e.g. if pwdGraceAuthNLimit is 1, I should be able to login once, while
according to the letter of the policy pwdGraceAuthNLimit: 1 ==
pwdGraceAuthNLimit: 0...)

The simplest fix, at least that I can see, would be to add the statement
"ngut--;" at some point after the statement

		if (ngut < 1) {
			ppb->pErr = PP_passwordExpired;
			rs->sr_err = LDAP_INVALID_CREDENTIALS;
			goto done;
		}

e.g.

		if (ngut < 1) {
			ppb->pErr = PP_passwordExpired;
			rs->sr_err = LDAP_INVALID_CREDENTIALS;
			goto done;
		}

		ngut--;

Or perhaps after we've created the grace user time attribute modification.

This would be done to account for the fact that we are, right now, using up a
single one of the pwdGraceUseTime values, and that once we're done, ngut should
indeed be one less than it currently is - there will be (ngut - 1) grace logins
*remaining* after this method invocation finishes.

This may seem like a really small thing, but it's causing problems for me...