openldap-technical December 2015

openldap-technical@openldap.org

53 participants
66 discussions

Strange LDAP searches for time, IP address and system users
by MI 03 Dec '15

03 Dec '15

I see very strange searches in my slapd.log, and wonder what I my have misconfigured. On every SSH connection (with ssh key, not password) : Search for the TTY: slapd[3183]: conn=1000 op=307 SRCH base="dc=mydomain,dc=lan" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=pts/2))" slapd[3183]: conn=1000 op=307 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass For the date: slapd[3183]: conn=1000 op=308 SRCH base="dc=mydomain,dc=lan" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=2015-12-03))" The time: slapd[3183]: conn=1000 op=309 SRCH base="dc=mydomain,dc=lan" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=16:28))" The IP: slapd[3183]: conn=1000 op=310 SRCH base="dc=mydomain,dc=lan" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=\28192.168.99.206\29))" (But I don't see "uid=root" when logging in over SSH with a key.) I wouldn't expect to see a search for "root", since it's a system account, and I use a key, so I would expect LDAP to be completely out of the picture. However, I do see many searches in the logs for other system accounts: filter="(&(objectClass=posixAccount)(uid=www-data))" filter="(&(objectClass=posixAccount)(uid=man))" filter="(&(objectClass=posixAccount)(uid=root))" filter="(&(objectClass=posixAccount)(uid=postfix))" filter="(&(objectClass=posixAccount)(uid=debian-spamd))" filter="(&(objectClass=posixAccount)(uid=amavis))" filter="(&(objectClass=posixAccount)(uid=\2A))" ... Most seem to be triggered by the standard system cron jobs or service restarts etc. The system is Debian 8.2 "Jessie". The following packages related to ldap or pam are installed: ldap-utils 2.4.40+dfsg-1+deb8u1 libaprutil1-ldap:amd64 1.5.4-1 libldap-2.4-2:amd64 2.4.40+dfsg-1+deb8u1 libnss-ldap:amd64 265-3+b1 libpam0g:amd64 1.1.8-3.1 libpam-ldap:amd64 184-8.7+b1 libpam-modules:amd64 1.1.8-3.1 libpam-modules-bin 1.1.8-3.1 libpam-runtime 1.1.8-3.1 nscd 2.19-18+deb8u1 slapd 2.4.40+dfsg-1+deb8u1 At this point, it's difficult for me to know what may be relevant, so I'm afraid I have to paste a lot of stuff here in the hope that it includes some clue for someone... # egrep 'cache|check' /etc/nscd.conf enable-cache passwd yes check-files passwd yes enable-cache group yes check-files group yes enable-cache hosts yes check-files hosts yes enable-cache services yes check-files services yes enable-cache netgroup yes check-files netgroup yes # grep ldap /etc/nsswitch.conf passwd: compat ldap group: compat ldap shadow: compat ldap # listconf /etc/pam_ldap.conf host 127.0.0.1 base dc=mydomain,dc=lan ldap_version 3 rootbinddn cn=admin,dc=mydomain,dc=lan pam_password crypt # listconf /etc/pam.d/common-auth auth [success=2 default=ignore] pam_unix.so nullok_secure auth [success=1 default=ignore] pam_ldap.so use_first_pass auth requisite pam_deny.so auth required pam_permit.so # listconf /etc/pam.d/common-account account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so account [success=1 default=ignore] pam_ldap.so account requisite pam_deny.so account required pam_permit.so # listconf /etc/pam.d/common-password password [success=2 default=ignore] pam_unix.so obscure sha512 password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass password requisite pam_deny.so password required pam_permit.so # listconf /etc/pam.d/common-session session [default=1] pam_permit.so session requisite pam_deny.so session required pam_permit.so session required pam_unix.so session optional pam_ldap.so My LDAP olcLogLevel is "filter stats sync". Please let me know if the other lines of that log may be useful, or if other log levels should be enabled (I tried, but didn't notice anything interesting). Well, if you have read so far, now is the time to tell me that this is all useless and that I should have posted that other essential config file which I missed ... :-) Thanks for any help in solving this mystery, MI

1 0

RE: RE24 testing call #3 (2.4.43) LMDB RE0.9 testing call #3 (0.9.17)
by Sergio NNX 02 Dec '15

02 Dec '15

> What git revision of LMDB did you test? The last tag from git repository, 0.9.16 Thanks. > Subject: Re: RE24 testing call #3 (2.4.43) LMDB RE0.9 testing call #3 (0.9.17) > To: sfhacker(a)hotmail.com > From: hyc(a)symas.com > Date: Wed, 25 Nov 2015 13:02:44 +0000 > > Sergio NNX wrote: > > Ciao, > > > > We are testing the latest version of Cyrus SASL against LMDB (on Windows, > > built from source) and when we run the testsuite app, we get a runtime > > exception shown below: > > Please use the -technical mailing list for LMDB discussions. > > > > > ... > > ... > > Testing sasl_listmech()... ok > > Testing serverstart... All memory accounted for! > > ok > > Testing client-first/no-server-last correctly... > > SRP --> start > > > > Program received signal SIGSEGV, Segmentation fault. > > 0x00000000 in ?? () > > (gdb) bt > > #0 0x00000000 in ?? () > > #1 0x00432a4d in mdb_node_search (mc=mc@entry=0x289608, > > key=key@entry=0x289850, exactp=exactp@entry=0x289604) at mdb.c:4943 > > #2 0x004361bc in mdb_cursor_set (mc=mc@entry=0x289608, > > key=key@entry=0x289850, data=data@entry=0x289858, op=op@entry=MDB_SET, > > exactp=exactp@entry=0x289604) at mdb.c:5725 > > #3 0x0043667c in mdb_get (txn=0x35c7b0, dbi=1, key=0x289850, data=0x289858) > > at mdb.c:5391 > > #4 0x00431a55 in _sasldb_getdata () > > #5 0x0042fda3 in sasldb_auxprop_lookup () > > #6 0x004119f7 in _sasl_auxprop_lookup () > > #7 0x00413a6c in _sasl_canon_user_lookup () > > #8 0x0042ea7e in srp_server_mech_step () > > #9 0x0040cddd in sasl_server_step () > > #10 0x0040d361 in sasl_server_start () > > #11 0x0040458f in doauth () > > #12 0x004060d6 in test_clientfirst () > > #13 0x00406405 in foreach_mechanism () > > #14 0x00733d1f in main () > > (gdb) > > > > > > Building SASL against Berkeley DB does not show the same issue. > > > > Any pointers will be greatly appreciated. > > > > Thanks. > > > > Sergio.

2 2

memberOf-overlay and custom schema (slapd.logs attched)
by Dora Paula 02 Dec '15

02 Dec '15

Hi, I want to have some kind of dn-based association between two custom entries (e.g. account<--dn-->device). Therefore I use a combination of the memberOf- and refint overlay (configuration inspired by test057). I use a custom schema: An auxiliary objectClass called "association". It has only one may-attribute called "associate". The custom 'memberOf'-Attribute is called "associationOf", which is a may-attribute of the objectClass "myAccount" (derived from account): OpenLDAP Version: git OPENLDAP_REL_ENG_2_4 #example.com.schema # attributeType ( 1.3.6.1.4.1.9999999.10.1.1 NAME 'associate' DESC 'an associate' SUP distinguishedName ) attributeType ( 1.3.6.1.4.1.9999999.10.1.2 NAME 'associateOf' DESC 'associate of' SUP distinguishedName ) objectClass ( 1.3.6.1.4.1.9999999.10.2.1 NAME 'association' DESC 'association' SUP top AUXILIARY MAY ( associate ) ) objectClass ( 1.3.6.1.4.1.9999999.10.2.2 NAME 'myAccount' DESC 'my account' SUP account STRUCTURAL MAY ( associateOf ) ) #slapd.conf # include /opt/slapd_example.com/etc/openldap/schema/core.schema include /opt/slapd_example.com/etc/openldap/schema/cosine.schema include /opt/slapd_example.com/etc/openldap/schema/ppolicy.schema include /opt/slapd_example.com/etc/example.com.schema pidfile /opt/slapd_example.com/var/run/slapd.pid argsfile /opt/slapd_example.com/var/run/slapd.args loglevel none password-hash {CLEARTEXT} attributeOptions lang- access to dn.base="" by * read access to dn.base="cn=Subschema" by * read database config rootdn "cn=admin,dc=example,dc=com" database mdb suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw "admin" directory /opt/slapd_example.com/var/openldap-data index objectClass,cn,ou,o,dc eq add_content_acl on overlay memberof memberof-group-oc association memberof-member-ad associate memberof-memberof-ad associateOf memberof-dangling ignore memberof-refint FALSE memberof-dn olcOverlay={1}memberof,olcDatabase={2}mdb,cn=config overlay refint refint_attributes associate associateOf refint_nothing olcOverlay={0}refint,olcDatabase={2}mdb,cn=config refint_modifiersname olcOverlay={0}refint,olcDatabase={2}mdb,cn=config #After starting the server, first I add a custom account: # cat << EOF | ldapmodify -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin dn: uid=myAccount,dc=example,dc=com changetype: add objectClass: top objectClass: myAccount uid: myAccount EOF #Then I add a naked device: # cat << EOF | ldapmodify -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin dn: cn=device,dc=example,dc=com changetype: add objectClass: top objectClass: device cn: device EOF Now I try to associate them using a single modify operation (adding the aux-objectClass association and the associate attribute). This approach fails, that means: The operation passes without error, but the account's associationOf attribute isn't added. #This modify operation seems to be ignored by memberOf-overlay: # cat << EOF | ldapmodify -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin dn: cn=device,dc=example,dc=com changetype: modify add: objectClass objectClass: association - add: associate associate: uid=myAccount,dc=example,dc=com - EOF #slapd-log (loglevel -1), see attached all-inclusive-modify.log #Checking the results: # ldapsearch -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin -b "dc=example,dc=com" -s one '(objectClass=*)' # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope oneLevel # filter: (objectClass=*) # requesting: ALL # # device, example.com dn: cn=device,dc=example,dc=com objectClass: top objectClass: device objectClass: association cn: device associate: uid=myAccount,dc=example,dc=com # myAccount, example.com dn: uid=myAccount,dc=example,dc=com objectClass: top objectClass: myAccount uid: myAccount # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 The second approach (resetting the device and myAccount entry and split the above modify operation into two operations works fine. Details see here: #Splitting the previous modify operation into two works fine: # cat << EOF | ldapmodify -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin dn: cn=device,dc=example,dc=com changetype: modify add: objectClass objectClass: association EOF cat << EOF | ldapmodify -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin dn: cn=device,dc=example,dc=com changetype: modify add: associate associate: uid=myAccount,dc=example,dc=com EOF #slapd-log (loglevel -1), see attached split-modify.log #Checking the results: # ldapsearch -x -H "ldap://localhost:2389/" -D "cn=admin,dc=example,dc=com" -w admin -b "dc=example,dc=com" -s one '(objectClass=*)' # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope oneLevel # filter: (objectClass=*) # requesting: ALL # # device, example.com dn: cn=device,dc=example,dc=com objectClass: top objectClass: device objectClass: association cn: device associate: uid=myAccount,dc=example,dc=com # myAccount, example.com dn: uid=myAccount,dc=example,dc=com objectClass: top objectClass: myAccount uid: myAccount associateOf: cn=device,dc=example,dc=com # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 Long story, short question: Is this the intended behaviour? If not is it caused by a misconfiguration or a bug? Thank you very much for your help! Best regards Dora

2 1

OpenLDAP 2.4.43 packages for RedHat/CentOS
by Clément OUDOT 02 Dec '15

02 Dec '15

Hi all, you can find RPM packages for OpenLDAP 2.4.43 on LTB project : http://ltb-project.org/wiki/download?&#packages_for_red_hatcentos Debian packages should be available soon. -- Clément OUDOT Consultant en logiciels libres, Expert infrastructure et sécurité Savoir-faire Linux

1 0

updated my openSUSE packages (was: OpenLDAP 2.4.43 available)
by Michael Ströder 01 Dec '15

01 Dec '15

OpenLDAP Project wrote: > OpenLDAP 2.4.43 is now available for download as detailed on our download page: > > http://www.openldap.org/software/download/ Thanks to OpenLDAP team for the new release. I've updated my private openSUSE packages to this release. The OBS source: https://build.opensuse.org/package/show/home:stroeder:branches:network:ldap… Repos for various SUSE versions: http://download.opensuse.org/repositories/home:/stroeder:/branches:/network… Please test. Ciao, Michael.

2 2

OpenLdap Clear-text Password in Debug Mode
by Rich Alford 01 Dec '15

01 Dec '15

Hi All: I'm not sure if this issue results from my ignorance of OpenLdap, or it's not capable of resolving. Regardless, any direction you can provide would be greatly appreciated: I have a basic OpenLdap installation with TLS encryption. Passwords are hashed in the ldap directory. The user password travels from client to server encrypted as it should, then gets unencrypted by slapd, and IF IN DEBUG MODE gets displayed in *clear-text*. Theoretically, the password should be hashed on the client, sent across the network, to be compared against the hashed passwords in the database. What am I missing?? Thank you, Rich

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2015