#50529 LDAP server returning controltype in different sequence
Closed: fixed 5 months ago by mreynolds. Opened 5 months ago by mreynolds.

Ticket was cloned from Red Hat Bugzilla: Bug 1724914

Description of problem:

LDAP server returning controltype in different sequence when user password is
expired.

when user password is expired & grace login is available vs grace login are
exhausted, controltype sequence is changed.


bindRequest
Lightweight Directory Access Protocol
    LDAPMessage bindRequest(1)
"uid=atolani,ou=People,dc=gsslab,dc=rdu2,dc=redhat,dc=com" simple
        messageID: 1
        protocolOp: bindRequest (0)
            bindRequest
                version: 3
                name: uid=atolani,ou=People,dc=gsslab,dc=rdu2,dc=redhat,dc=com
                authentication: simple (0)
                    simple: redhat
        [Response In: 2]
        controls: 1 item
            Control
                controlType: 1.3.6.1.4.1.42.2.27.8.5.1 (passwordPolicy)



When grace login are available.

[root@hp-bl465cg8-1 ~]# ldapsearch -x -LLL -h localhost -D
uid=atolani,ou=People,dc=gsslab,dc=rdu2,dc=redhat,dc=com -w redhat -b
uid=atolani,ou=People,dc=gsslab,dc=rdu2,dc=redhat,dc=com "" -e ppolicy
ldap_bind: Success (0) (Password expired, 0 grace logins remain)
dn: uid=atolani,ou=People,dc=gsslab,dc=rdu2,dc=redhat,dc=com

Lightweight Directory Access Protocol
    LDAPMessage bindResponse(1) success
        messageID: 1
        protocolOp: bindResponse (1)
            bindResponse
                resultCode: success (0)
                matchedDN:
                errorMessage:
        [Response To: 1]
        [Time: 0.007859000 seconds]
        controls: 2 items
            Control
                controlType: 1.3.6.1.4.1.42.2.27.8.5.1 (passwordPolicy)
                PasswordPolicyResponseValue
                    warning: graceAuthNsRemaining (1)
                        graceAuthNsRemaining: 1
            Control
                controlType: 2.16.840.1.113730.3.4.4 (Netscape Password Expired
LDAPv3 control)
                controlValue: 30




When grace logins are exhausted.

[root@hp-bl465cg8-1 ~]# ldapsearch -x -LLL -h localhost -D
uid=atolani,ou=People,dc=gsslab,dc=rdu2,dc=redhat,dc=com -w redhat -b
uid=atolani,ou=People,dc=gsslab,dc=rdu2,dc=redhat,dc=com "" -e ppolicy
ldap_bind: Invalid credentials (49); Password expired
additional info: password expired!

Lightweight Directory Access Protocol
    LDAPMessage bindResponse(1) invalidCredentials (password expired!)
        messageID: 1
        protocolOp: bindResponse (1)
            bindResponse
                resultCode: invalidCredentials (49)
                matchedDN:
                errorMessage: password expired!
        [Response To: 11]
        [Time: 0.000980000 seconds]
        controls: 2 items
            Control
                controlType: 2.16.840.1.113730.3.4.4 (Netscape Password Expired
LDAPv3 control)
                controlValue: 30
            Control
                controlType: 1.3.6.1.4.1.42.2.27.8.5.1 (passwordPolicy)
                PasswordPolicyResponseValue
                    error: passwordExpired (0)



You see in controls are swapped

Version-Release number of selected component (if applicable):
RHEL 7.6

How reproducible:
100%

Steps to Reproduce:
1. Add a user in RHDS & setup password policy with maxage.
2. Add grace login in password policy
3. Login as user when password is expired.

Additional info:
Opon Discussing it on idm-tech, Ludwik agreed it could be potential bug.

RFC 4511 says controls should only be combined if the semantics of the
combination is specified, which none of the two controls does.

And the ppoplicy is a requested control and the netscape pw expired control was
not requested, so I would say it would be more correct to return the requested
control first.

Metadata Update from @mreynolds:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1724914

5 months ago

Metadata Update from @mreynolds:
- Issue assigned to mreynolds

5 months ago

Metadata Update from @mreynolds:
- Custom field origin adjusted to None
- Custom field reviewstatus adjusted to None
- Issue set to the milestone: 1.3.10 (was: 0.0 NEEDS_TRIAGE)

5 months ago

Commit 67c7604 relates to this ticket

4b240e9..67c7604 master -> master

9a7aab2..b6df377 389-ds-base-1.4.0 -> 389-ds-base-1.4.0

commit b350d7d --> 1.3.10

Metadata Update from @mreynolds:
- Issue close_status updated to: fixed
- Issue status updated to: Closed (was: Open)

5 months ago

Login to comment on this ticket.

Metadata