RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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:
Embargoed:

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 none
debug1: kex: client->server aes128-ctr hmac-md5-etm none
debug1: kex: curve25519-sha256 need=16 dh_need=16
debug1: kex: curve25519-sha256 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.