Bug 1335194 - ldap user login attempt kills slapd service
Summary: ldap user login attempt kills slapd service
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openldap
Version: 7.2
Hardware: x86_64
OS: Linux
low
high
Target Milestone: rc
: ---
Assignee: Matus Honek
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-11 14:13 UTC by Liz Real
Modified: 2019-12-16 05:46 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-01 16:00:31 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Liz Real 2016-05-11 14:13:49 UTC
Description of problem:
I have been troubleshooting this problem for a while and can’t figure out why everytime I try to login to an ldap client with a test user account the slapd service on only one of my ldap servers gets killed.

I reached out to the openldap technical group and they suggested i file this with you as a bug: "as OpenLDAP distributed with RHEL uses NSS for crypto (which is
deprecated by OpenLDAP upstream community) please contact Red Hat
customer support with the issue."

Version-Release number of selected component (if applicable):
LDAPSERVERS: I have two ldap servers running RHEL7.2 and openldap 2.4.40. Both servers are configured with multi-master replication. Ldaps is enabled and a ppolicy applied.

LDAPCLIENT: My ldap client is running RHEL7.2 as well, sssd 1.13.0, and openldap client 2.4.40.

How reproducible:
Every time.

Steps to Reproduce:
1. login with user account (realtest) to ldapclient with correct password
2. ldapclient /var/log/secure logs authentication failure errors
3. ldapserver /var/log/secure logs slapd.service entered failed state
4. unsuccessful login

Actual results:
unsuccessful login to ldapclient and ldapserver slapd service is killed

Expected results:
Successful login to ldapclient and ldapserver slapd service unaffected and running nominally.

Additional info:
Both getent and ldapsearch return the expected information when ran on the ldap client:
ldapclient ~]# getent passwd realtest
realtest:*:1004:312:Liz RealTest:/home/real:/bin/tcsh

ldapclient ~]# ldapsearch -x -s sub -b 'ou=People,dc=cluster,dc=sec312' '(uid=realtest)'
# extended LDIF
#
# LDAPv3
# base <ou=People,dc=cluster,dc=sec312> with scope subtree
# filter: (uid=realtest)
# requesting: ALL
#

# realtest, People, cluster.sec312
dn: uid=realtest,ou=People,dc=cluster,dc=sec312
gidNumber: 312
objectClass: account
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
uid: realtest
loginShell: /bin/tcsh
homeDirectory: /home/real
cn: Liz RealTest
uidNumber: 1004

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

LDAP SERVER /VAR/LOG/SECURE:
serverA journal: Suppressed 19192 messages from /system.slice/slapd.service
serverA journal: Suppressed 8449 messages from /system.slice/slapd.service
serverA systemd: slapd.service: main process exited, code=killed, status=6/ABRT
serverA systemd: Unit slapd.service entered failed state.
serverA systemd: slapd.service failed.

LDAP CLIENT  /VAR/LOG/SECURE:
ldapclient sshd[122938]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=node12.cluster.sec312 user=realtest
ldapclient sshd[122938]: pam_sss(sshd:auth): received for user realtest: 7 (Authentication failure)
ldapclient sshd[122938]: pam_ldap(sshd:auth): Authentication failure; user=realtest
ldapclient sshd[122936]: error: PAM: Authentication failure for realtest from node12.cluster.sec312

ATTEMPT TO SSH AS TEST USER TO LDAP CLIENT:
% ssh -v realtest@ldapclient
OpenSSH_6.6.1, OpenSSL 1.0.1e-fips 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 60: Applying options for *
debug1: Connecting to ldapclient [] port 22.
debug1: Connection established.
debug1: could not open key file '/etc/ssh/ssh_host_key': Permission denied
debug1: could not open key file '/etc/ssh/ssh_host_dsa_key': Permission denied
debug1: could not open key file '/etc/ssh/ssh_host_ecdsa_key': Permission denied
debug1: could not open key file '/etc/ssh/ssh_host_rsa_key': Permission denied
debug1: could not open key file '/etc/ssh/ssh_host_ed25519_key': Permission denied
debug1: could not open key file '/etc/ssh/ssh_host_dsa_key': Permission denied
debug1: could not open key file '/etc/ssh/ssh_host_ecdsa_key': Permission denied
debug1: could not open key file '/etc/ssh/ssh_host_rsa_key': Permission denied
debug1: could not open key file '/etc/ssh/ssh_host_ed25519_key': Permission denied
debug1: identity file /home/real/.ssh/id_rsa type -1
debug1: identity file /home/real/.ssh/id_rsa-cert type -1
debug1: identity file /home/real/.ssh/id_dsa type -1
debug1: identity file /home/real/.ssh/id_dsa-cert type -1
debug1: identity file /home/real/.ssh/id_ecdsa type -1
debug1: identity file /home/real/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/real/.ssh/id_ed25519 type -1
debug1: identity file /home/real/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
debug1: kex: curve25519-sha256@libssh.org need=16 dh_need=16
debug1: kex: curve25519-sha256@libssh.org need=16 dh_need=16
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 14:c5:c2:60:29:ce:99:aa:67:41:a6:6a:11:2c:ca:86
debug1: Host 'ldapclient' is known and matches the ECDSA host key.
debug1: Found key in /home/real/.ssh/known_hosts:22
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive,hostbased
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Next authentication method: hostbased
debug1: No more client hostkeys for hostbased authentication.
debug1: Next authentication method: publickey
debug1: Trying private key: /home/real/.ssh/id_rsa
debug1: Trying private key: /home/real/.ssh/id_dsa
debug1: Trying private key: /home/real/.ssh/id_ecdsa
debug1: Trying private key: /home/real/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password: 
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive,host based

Comment 1 Matus Honek 2016-05-11 15:09:57 UTC
Hello,

(In reply to Liz Real from comment #0)
> I reached out to the openldap technical group and they suggested i file this
> with you as a bug: "as OpenLDAP distributed with RHEL uses NSS for crypto
> (which is
> deprecated by OpenLDAP upstream community) please contact Red Hat
> customer support with the issue."

it was actually me who responded to you with the suggestion. Anyway, as I suggested in the e-mail, you should contact our customer support [1] where, as a subscribed customer, you should have an access to. They are much more able to help you in this stage.

On the contents of the description: as I suggested in the e-mail, too, you should supply full logs and configs (aka SOS report) - our support would help you with these. From the description you supplied it is not even clear whether the issue is in the openldap itself (for me, it seems like a configuration issue, but that is just a guess).

Please, consider contacting our support and, being related, let them know about this bugzilla filed bug. Once again, thank you for your understanding.

[1] https://access.redhat.com/

Comment 4 Matus Honek 2016-06-16 13:27:54 UTC
Related upstream thread: http://www.openldap.org/lists/openldap-technical/201605/msg00036.html

slapd crashes in ppolicy module on assert at ppolicy:870 in ctrls_cleanup:
assert( rs->sr_ctrls != NULL );

Seems to be the same as (which has not been much developed back then):
http://www.openldap.org/its/index.cgi/Incoming?id=7384

Comment 8 Nathan Kinder 2016-12-01 16:00:31 UTC
This turned out to be a configuration issue.  Closing this out as NOTABUG.


Note You need to log in before you can comment on or make changes to this bug.