openldap-technical

openldap-technical@openldap.org

22 participants
9803 discussions

authenticating users !
by Alex Samad - Yieldbroker 14 Mar '12

14 Mar '12

Hi I have 2 backend db setup {2}bdb -> suffix: ou=external,dc=xyz,dc=com {3)ldap -> uri ldap://msad.xyz.com, suffix: dc=xyz,dc=com Say I have a user dn: cn=alex samad,cn=users, dc=xyz,dc=com I create an ldap alias record dn: uid=alex.samad(a)xyz.com, ou=external,dc=xyz,dc=com objectclass: top, extensibleObject, alias aliasedObjectName: cn=alex samad,cn=users, dc=xyz,dc=com I try and login with this DN "uid=alex.samad(a)xyz.com, ou=external,dc=xyz,dc=com" and it fails, when I logging with " cn=alex samad,cn=users, dc=xyz,dc=com " it works. So can I presume the authentication code doesn't follow ldap alias ? Alex

1 0

how to delete backend DB
by Alex Samad - Yieldbroker 14 Mar '12

14 Mar '12

Hi I am trying to delete a backend DB Currently have dn: olcDatabase={-1}frontend,cn=config dn: olcDatabase={0}config,cn=config dn: olcDatabase={1}monitor,cn=config dn: olcDatabase={2}bdb,cn=config I would like to delete olcDatabase={2}bdb,cn=config I tried ldapdelete -v "olcDatabase={2}bdb,cn=config" note- I have ~/.ldaprc setup with URI & SAS_MECH slapd will not let me do it ? I know I can shut down slapd and remove the file. But I am wondering if there is a "proper" way to do it Thanks Alex

2 3

problem about smooth migration from files to ldap
by huwenfeng 14 Mar '12

14 Mar '12

Hi all: I got a non-technical problem here. I have managed to solved the problem of using OpenLDAP to store user and group infomation and successfully logined into Linux Servers using OpenLDAP. In the Linux Server, i got LOCAL groups named like `devel` and `www`, and LOCAL users belong to these groups. Through the /etc/sudoers file, I give different groups with different privileges. In the OpenLDAP database, i defined my own `devel` and `www` groups. and users in OpenLDAP belongs to their corresponding groups. The problem is , if i add ldap into /etc/nsswitch.conf, then only the first pair of (users/groups) get the right privileges from /etc/sudoers. That means, if I put `ldap` before `files`, only the users login through OpenLDAP can use the privileges defined in /etc/sudoers. But if I put `files` before `ldap` in /etc/nsswitch.conf, then only Local (users/groups) pair got the privileges from /etc/sudoer2. I got a bad solution here: give different names to groups from OpenLDAP, and define new privileges in /etc/sudoers for these groups. and after migration, delete the old local groups and old sudo privileges. But this seems to be not that good a solution. I wonder, what might be the best or right way to migrate from (local user/group) to (ldap user/group) smoothly. Any clue or advice will be greatly appreciated. Thank you In advance.

3 3

OPENLDAP SYNCREPL
by Borresen, John - 0442 - MITLL 13 Mar '12

13 Mar '12

All, I've read and re-read (not to mentioned googled) configuring SyncRepl in OpenLDAP dynamic configuration (cn=config)--v2.4.23. Missing something somewhere. Current logging is set to "256" on both Provider and Consumer. On my Master/Provider LDAP server seeing the following: slapd shutdown: waiting for 0 operations/tasks to finish slapd shutdown: initiated bdb_modify: dc=group42,dc=ldap bdb_dn2entry("dc=group42,dc=ldap") bdb_modify_internal: 0x00000001: dc=group42,dc=ldap bdb_modify_internal: replace contextCSN => entry_encode(0x00000001): dc=group42,dc=ldap <= entry_encode(0x00000001): dc=group42,dc=ldap bdb_modify: updated id=00000001 dn="dc=group42,dc=ldap" send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" ====> bdb_cache_release_all ====> bdb_cache_release_all slapd destroy: freeing system resources. On my Consumer/Slave Server I am seeing the following: slapd destroy: freeing system resources. syncinfo_free: rid=001 slapd stopped. tail: /var/log/slapd: file truncated do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying do_syncrep2: rid=001 got search entry without Sync State control do_syncrepl: rid=001 rc -1 retrying >From my readings, I understand that the "Sync State Control" error normally indicates that my provider is not set up correctly. As far as I can tell, my modules are correctly loaded and the overlays are loaded to the appropriate database (my case, bdb) to be replicated. The following is from the Provider/Master LDAP Server: My olcDatabase-{1}bdb.ldif (truncated): # more olcDatabase={1}bdb.ldif dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcSuffix: dc=group42,dc=ldap olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=ldapadmin,dc=group42,dc=ldap olcRootPW:: ******* olcSyncUseSubentry: FALSE olcMonitoring: TRUE olcDbDirectory: /var/lib/ldap_db/openldap-data olcDbCacheSize: 1000 ... olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass eq olcDbIndex: sn eq,sub olcDbIndex: mail eq,sub olcDbIndex: departmentNumber eq olcDbIndex: cn,uid eq,sub olcDbIndex: uidNumber eq olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: ipHostNumber eq olcDbIndex: gidNumber,memberUID eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: 101e6d86-dd1c-4eaa-a26e-d7e201a727f8 creatorsName: cn=config createTimestamp: 20111219143532Z olcDbSearchStack: 32 olcAccess: {0} to attrs=userPassword,shadowLastChange by self write by anonymo us auth by * none olcAccess: {1} to * by * read olcDatabase: {1}bdb entryCSN: 20120313143637.046410Z#000000#001#000000 modifiersName: cn=config modifyTimestamp: 20120313143637Z # ll olcDatabase={1}bdb total 16 -rw------- 1 ldap ldap 453 Mar 12 10:50 olcOverlay={0}syncprov.ldif -rw------- 1 ldap ldap 505 Feb 29 11:16 olcOverlay={1}accesslog.ldif The olcOverlay={0}syncrpov.ldif # more olcDatabase={1}bdb/olcOverlay={0}syncprov.ldif dn: olcOverlay={0}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE structuralObjectClass: olcSyncProvConfig entryUUID: 8572b589-f594-44a6-91fe-0de741afbcca creatorsName: cn=admin,cn=config createTimestamp: 20120224171809Z olcSpReloadHint: TRUE olcSpCheckpoint: 1000 60 entryCSN: 20120312145000.123929Z#000000#001#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20120312145000Z The olcOverlay={1}accesslog.ldif: # more olcDatabase={1}bdb/olcOverlay={1}accesslog.ldif dn: olcOverlay={1}accesslog objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE structuralObjectClass: olcAccessLogConfig entryUUID: eea1e438-6385-4660-807b-bb270eb4843a creatorsName: cn=admin,cn=config createTimestamp: 20120229161649Z entryCSN: 20120229161649.880441Z#000000#000#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20120229161649Z ***The following is on the Consumer/Slave Server*** The olcDatabase={2}bdb.ldif (truncated): # more olcDatabase={2}bdb.ldif dn: olcDatabase={2}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcSuffix: dc=group42,dc=ldap olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=ldapadmin,dc=group42,dc=ldap olcRootPW:: ********* olcMonitoring: TRUE olcDbDirectory: /var/lib/ldap_db/openldap-data olcDbCacheSize: 1000 ... olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass eq olcDbIndex: cn,uid eq,sub olcDbIndex: sn eq,sub olcDbIndex: mail eq,sub olcDbIndex: departmentNumber eq olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcAccess: {0} to attrs=userPassword,shadowLastChange by self write by anonymo us auth by * none olcAccess: {1} to * by * read olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: e6971058-e0f0-4160-aaca-a18b24d22008 creatorsName: cn=config createTimestamp: 20120229205835Z olcDatabase: {2}bdb olcUpdateRef: ldaps://gp42-admin2.group42.ldap:636 olcMirrorMode: TRUE olcSyncrepl: {0}rid=1 provider=ldaps://gp42-admin2.group42.ldap:636 bindmethod =simple binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=******* interva l=01:00:00:00 searchbase="dc=group42,dc=ldap" logbase="cn=accesslog" schemach ecking=on type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs= "*,+" syncdata=accesslog starttls=no tls_cacertdir=/usr/local/openldap-2.4.23 /etc/openldap/cacerts entryCSN: 20120313150609.224840Z#000000#000#000000 modifiersName: cn=admin,cn=config modifyTimestamp: 20120313150609Z Not sure what I am missing, nor where I am missing it. Any assistance would be helpful. Dave Borresen Solaris/Linux Systems Administrator Surveillance Systems Group MIT Lincoln Laboratory 244 Wood Street Lexington, MA 02420 P: 781-981-2954 F: 781-981-5344 john.borresen(a)ll.mit.edu

3 6

Re: olcTLSVerifyClient: demand not taking effect
by Peter Wood 13 Mar '12

13 Mar '12

On Mon, Mar 12, 2012 at 9:41 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Monday, March 12, 2012 6:52 PM -0700 Peter Wood < > peterwood.sd(a)gmail.com> wrote: > > Hi, >> >> >> I setup openldap-2.4.23 server >> > > Why? I'd suggest you start with the current release, 2.4.30. You may > also want to look at <http://www.openldap.org/its/**index.cgi/?findid=7197<http://www.openldap.org/its/index.cgi/?findid=7197> > > > > That's the openldap version in centos6.2 repo. In production I try to stick with stock versions. Also I tried all variations of olcTLSVerifyClient: [demand|hard|true] with the same result. I don't think StartTLS is enabled. I'm wondering if just setting olcTLSCACertificateFile, olcTLSCertificateFile and olcTLSCertificateKeyFile is enough to get StartTLS enabled. It's very frustrating. I'd hate to go to ldaps just because I can't get StartTLS working. Is there anything else I have to set on the server to get StartTLS working? Thanks Peter

6 6

RE: OPENLDAP SYNCREPL
by Quanah Gibson-Mount 13 Mar '12

13 Mar '12

--On Tuesday, March 13, 2012 2:36 PM -0400 "Borresen, John - 0442 - MITLL" <john.borresen(a)ll.mit.edu> wrote: > Thanks, Howard; You are clearly missing the syncprov overlay on the accesslog DB, as I already stated. If you fix that, you'll get a lot further. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: OPENLDAP SYNCREPL
by Quanah Gibson-Mount 13 Mar '12

13 Mar '12

--On Tuesday, March 13, 2012 1:12 PM -0400 "Borresen, John - 0442 - MITLL" <john.borresen(a)ll.mit.edu> wrote: > Thanks, Quanah; > > As requested: > > cn=config]# ll > total 140 > -rw------- 1 ldap ldap 398 Jan 24 11:28 cn=module{0}.ldif > -rw------- 1 ldap ldap 398 Feb 8 14:02 cn=module{1}.ldif > -rw------- 1 ldap ldap 397 Feb 21 09:06 cn=module{2}.ldif > -rw------- 1 ldap ldap 399 Feb 24 12:32 cn=module{3}.ldif You really don't need 4 separate files. ;) Use my cn=module{0}.ldif as a template for fixing yours. ;) I would also note that you're using delta-syncrepl, not syncrepl, and you failed to provide any of the configuration for the accesslog DB on the provider. My guess is that is the actual source of the error you are encountering. I.e., my guess is that you never loaded the syncprov overlay on the master's accesslog DB, which is also required. Here's an example configuration from my master's cn=accesslog configuration for the syncprov overlay there. Note that they *do* differ between your primary DB and your accesslog DB. root@zre-ldap002:/opt/zimbra/data/ldap/config/cn=config# ls olcDatabase\=\{2\}mdb olcOverlay={0}syncprov.ldif root@zre-ldap002:/opt/zimbra/data/ldap/config/cn=config# cat olcDatabase\=\{2\}mdb/olcOverlay\=\{0\}syncprov.ldif # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 fd177258 dn: olcOverlay={0}syncprov objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE structuralObjectClass: olcSyncProvConfig entryUUID: e97228d0-edf0-1030-98ed-dbd1519e60e2 creatorsName: cn=config createTimestamp: 20120217202252Z entryCSN: 20120217202252.161808Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20120217202252Z --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re-binding to a failed connection segfaults
by Jan Synacek 13 Mar '12

13 Mar '12

Hi list, I've created a small reproducer, that calls ldap_sasl_interactive_bind_s after it has been called once and failed, which causes a segfault. I've traced this bug with gdb: $ gdb ./reproducer GNU gdb (GDB) Fedora (7.3.50.20110722-10.fc16) Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/jsynacek/work/bz784989-openldap-rebinding/reproducer...done. (gdb) r Starting program: /home/jsynacek/work/bz784989-openldap-rebinding/reproducer [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". ldap_sasl_interactive_bind: user selected: GSSAPI ldap_int_sasl_bind: GSSAPI ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:636 ldap_new_socket: 7 ldap_prepare_socket: 7 ldap_connect_to_host: Trying ::1 636 ldap_pvt_connect: fd: 7 tm: -1 async: 0 TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory TLS: error: connect - force handshake failure: errno 21 - moznss error -5938 TLS: can't connect: TLS error -5938:Encountered end of file. ldap_msgfree ldap_err2string bind failed: Can't contact LDAP server, retrying for fun and profit! ldap_sasl_interactive_bind: user selected: GSSAPI ldap_int_sasl_bind: GSSAPI Program received signal SIGSEGV, Segmentation fault. ldap_int_sasl_bind (ld=0x603130, dn=0x0, mechs=0x401a30 "GSSAPI", sctrls=0x0, cctrls=0x0, flags=1, interact=0x401660 <lutil_sasl_interact>, defaults=0x60cae0, result=0x0, rmech=0x7fffffffd878, msgid=0x7fffffffd88c) at ../../../libraries/libldap/cyrus.c:444 444 oldctx = ld->ld_defconn->lconn_sasl_authctx; (gdb) p ld->ldc->ldc_defconn $1 = (LDAPConn *) 0x0 If you set slapd to use TLS certs (uncomment the 'TLS*' lines in the config), there is no segfault. Reproducer and cn=config.ldif attached. Original bugreport: https://bugzilla.redhat.com/show_bug.cgi?id=784989 Regards, -- Jan Synacek BaseOS team Brno

2 1

olcTLSVerifyClient: demand not taking effect
by Peter Wood 13 Mar '12

13 Mar '12

Hi, I setup openldap-2.4.23 server on centos6.2 using cn=config. The server itself doesn't authenticate through ldap. Network clients are able to authenticate but the network traffic is unencrypted. Next step is to configure SSL/TLS. I was reading multiple sources of documentation, trying to understand what I'm doing not just follow instructions. I created a CA, generated certificate for the server and setup these in cn=config: olcTLSCACertificateFile: /etc/openldap/cacerts/CA.crt olcTLSCertificateFile: /etc/pki/tls/certs/ldapserver.crt olcTLSCertificateKeyFile: /etc/pki/tls/private/ldapserver-nopass.key olcTLSVerifyClient: demand I was expecting that after slapd restart clients will not being able to authenticate but they still can and the traffic is still unencrypted. On the server if I run tcpdump I can clearly see usernames and passwords. Service slapd is running as user ldap and I made sure the user has read access to all cert files and private keys. I enabled logging level "olcLogLevel: stats" but I don't see any errors in the log file. Shouldn't "olcTLSVerifyClient: demand" drop the connection if the client doesn't provide valid certificate? Thank you for any pointers. -- Peter

2 1

Dynamic to Static LDAP
by Gaurav Gugnani 13 Mar '12

13 Mar '12

Hello All, We are using openldap 2.4 in our systems with berkley DB as a backend. Now, in current scenario we are using static LDAP i.e. /etc/openldap/slapd.conf and whenever we want to change any configuration parameter then we need to re-start LDAP. So, we decided to switch to dynamic LDAP i.e. using cn=config. So, *my Q's is:* I made my system running on dynamic LDAP like from past 2 months and in this span of time i implemented several changes. Now, suppose today i plan to again move back to use static configuration - Will i able to save all my changes what i did in all this time? OR All changes made are lost? If Lost - Is there any way to retrieve the changes which i made? Please suggest. Thanks and Regards, Gaurav Gugnani

4 5

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical