Correction, my openldap version is 2.4.45(typo'ed in previous post).
On Wed, Dec 13, 2017 at 11:23 AM Scott Koch scottkoch@gmail.com wrote:
This is an RPM of openldap I built from the latest upstream source. This slapd server is running on RHEL 7.4 x86_64.
Error message: 2017-12-13T00:13:34.944152-05:00 ldap1.example.com kernel: slapd[983]: segfault at 766f6730 ip 00007f0272e2549b sp 00007f02017f55b8 error 4 in libc-2.17.so[7f0272ce8000+1b8000]
We have seen 15 or so instances of this issue and in all cases the last LDAP operations follow the same pattern where there is an ABANDON and UNBIND, then there is a SRCH operation. See log output below of full connection for the client that performs the last operation.
Let me know if there is any other information I can provide to help troubleshoot this problem.
Thanks in advance for the help! -Scott
2017-12-13T00:13:03.560693-05:00 ldap1.example.com slapd[26514]: conn=873638 fd=105 ACCEPT from IP=10.0.4.37:48520 (IP=0.0.0.0:389)
2017-12-13T00:13:03.560869-05:00 ldap1.example.com slapd[26514]: conn=873638 op=0 EXT oid=1.3.6.1.4.1.1466.20037
2017-12-13T00:13:03.561012-05:00 ldap1.example.com slapd[26514]: conn=873638 op=0 STARTTLS
2017-12-13T00:13:03.561211-05:00 ldap1.example.com slapd[26514]: conn=873638 op=0 RESULT oid= err=0 text=
2017-12-13T00:13:03.569367-05:00 ldap1.example.com slapd[26514]: conn=873638 fd=105 TLS established tls_ssf=256 ssf=256
2017-12-13T00:13:03.569853-05:00 ldap1.example.com slapd[26514]: conn=873638 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
2017-12-13T00:13:03.570014-05:00 ldap1.example.com slapd[26514]: conn=873638 op=1 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms domainControllerFunctionality defaultNamingContext lastUSN highestCommittedUSN
2017-12-13T00:13:03.570215-05:00 ldap1.example.com slapd[26514]: conn=873638 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
2017-12-13T00:13:03.571953-05:00 ldap1.example.com slapd[26514]: conn=873638 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(?objectClass=sudoRole)(|(!(?sudoHost=*))(?sudoHost=ALL)(?sudoHost= node1713.example.com)(?sudoHost=node1713)(?sudoHost=10.0.4.37)(?sudoHost= 10.134.0.0/18)(?sudoHost=ffff::ffff:ffff:fff:ffff)(?sudoHost=fe80::/64)(?sudoHost=+*)(|(?sudoHost=*\5C*)(?sudoHost=*?*)(?sudoHost=*\2A*)(?sudoHost=*[*]*))) http://10.134.0.0/18)(?sudoHost=ffff::ffff:ffff:fff:ffff)(?sudoHost=fe80::/64)(?sudoHost=+*)(%7C(?sudoHost=*%5C5C*)(?sudoHost=*?*)(?sudoHost=*%5C2A*)(?sudoHost=*[*]*))) )"
2017-12-13T00:13:03.572214-05:00 ldap1.example.com slapd[26514]: conn=873638 op=2 SRCH attr=objectClass cn sudoCommand sudoHost sudoUser sudoOption sudoRunAs sudoRunAsUser sudoRunAsGroup sudoNotBefore sudoNotAfter sudoOrder modifyTimestamp
2017-12-13T00:13:03.573488-05:00 ldap1.example.com slapd[26514]: conn=873638 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text=
2017-12-13T00:13:34.943439-05:00 ldap1.example.com slapd[26514]: conn=873638 op=4 ABANDON msg=4
2017-12-13T00:13:34.943694-05:00 ldap1.example.com slapd[26514]: conn=873638 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(uid=ntp)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))"
2017-12-13T00:13:34.943885-05:00 ldap1.example.com slapd[26514]: conn=873638 op=5 UNBIND
2017-12-13T00:13:34.944092-05:00 ldap1.example.com slapd[26514]: conn=873638 op=3 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap sshPublicKey mail
Scott Koch wrote:
We have seen 15 or so instances of this issue and in all cases the last LDAP operations follow the same pattern where there is an ABANDON and UNBIND, then there is a SRCH operation. See log output below of full connection for the client that performs the last operation.
Of course slapd should not crash but...
http://ldap1.example.com slapd[26514]: conn=873638 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(?objectClass=sudoRole)(|(!(?sudoHost=*))(?sudoHost=ALL)(?sudoHost=node1713.example.com
^ ^ ^ ...the question mark before 'sudoHost' indicates that the sudo-ldap schema is missing on this particular slapd instance (specifically attribute type 'sudoHost' unknown).
In former times I've also experienced a provider crashing in case the consumer did not have the same schema yet.
Ciao, Michael.
openldap-technical@openldap.org