openldap-technical

openldap-technical@openldap.org

11 participants
9877 discussions

Re: delta-sync - ContextCSN on proivder older than consumers
by Yuri Bank 14 Mar '11

14 Mar '11

I'm using the latest stable version: OpenLDAP 2.4.23 ( running on Ubuntu 10.10 ) I've also included the relevant configuration for my Provider and Consumer[s]. Consumer[s] # {1}hdb, config dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=test,dc=com olcAccess: {0}to attrs=userPassword by dn="cn=admin,dc=test,dc=com" write by an onymous auth by self write by group.exact="cn=DCNAS,o=Groups,dc=test,dc=com" w rite by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to dn.base="" by * read olcAccess: {3}to * by dn="cn=admin,dc=test,dc=com" write by group.exact="cn=DCN AS,o=Groups,dc=test,dc=com" write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=test,dc=com olcRootPW: test olcSyncrepl: {0}rid=001 provider=ldap://10.81.255.30 bindmethod=simple binddn= "cn=admin,dc=test,dc=com" credentials=test searchbase="dc=test,dc=com" logba se="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshOnly retry="60 +" interval=00:00:00:30 syncdata =accesslog olcUpdateRef: ldap://10.81.255.30 olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcDbIndex: uid eq olcDbIndex: uidNumber eq olcDbIndex: cn eq olcDbIndex: memberOf eq olcDbIndex: entryUUID eq Provider: # {1}hdb, config dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=test,dc=com olcAccess: {0}to attrs=userPassword by dn="cn=admin,dc=test,dc=com" write by an onymous auth by self write by group.exact="cn=DCNAS,o=Groups,dc=test,dc=com" w rite by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to dn.base="" by * read olcAccess: {3}to * by dn="cn=admin,dc=test,dc=com" write by group.exact="cn=DCN AS,o=Groups,dc=test,dc=com" write by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=test,dc=com olcRootPW: test olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcDbIndex: entryCSN eq olcDbIndex: entryUUID eq olcDbIndex: uid eq olcDbIndex: uidNumber eq olcDbIndex: cn eq olcDbIndex: memberOf eq # {1}syncprov, {1}hdb, config dn: olcOverlay={1}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov olcSpNoPresent: TRUE # {2}accesslog, {1}hdb, config dn: olcOverlay={2}accesslog,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {2}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogPurge: 07+00:00 01+00:00 olcAccessLogSuccess: TRUE # {2}hdb, config dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcRootDN: cn=admin,dc=test,dc=com olcDbIndex: default eq olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart # {0}syncprov, {2}hdb, config dn: olcOverlay={0}syncprov,olcDatabase={2}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE -Yuri On Sun, Mar 13, 2011 at 11:47 AM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > --On Saturday, March 12, 2011 8:59 PM -0800 Yuri Bank <yuribank(a)gmail.com> > wrote: > > >> I've found an interesting issue with delta-sync replication in which the >> > > > The first thing you should always provide is the version of OpenLDAP you > are using. > > --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 >

4 8

execve problem with back-shell
by Michael Smith 14 Mar '11

14 Mar '11

Hello all. I'm working with openLDAP again, after some years' hiatus, and very glad of it. I'm having a problem which I hope somebody's seen before. I'm trying to use back-shell (to avoid relearning Perl) for a quick-and dirty solution to a problem too tedious to describe here. Here's the relevant bits of slapd.conf: -------------- moduleload back_shell.la backend shell database shell suffix "dc=foo,dc=bar,dc=com" rootdn "cn=admin,dc=foo,dc=bar,dc=com" rootpw secretissimum-secretissimorum add /usr/local/bin/backshell.sh bind /usr/local/bin/backshell.sh compare /usr/local/bin/backshell.sh delete /usr/local/bin/backshell.sh modify /usr/local/bin/backshell.sh modrdn /usr/local/bin/backshell.sh search /usr/local/bin/backshell.sh unbind /usr/local/bin/backshell.sh syncrepl rid=123 provider=ldap://127.0.0.1 type=refreshOnly interval=00:00:00:05 searchbase="dc=foo,dc=bar,dc=com" scope=sub bindmethod=simple binddn="uid=mik,ou=Managers,dc=foo,dc=bar,dc=com" credentials="M0$tsecret" ------------- backshell.sh is moronically simple at the moment: ---------------- #!/bin/bash while read LINE do /bin/echo $LINE >>/var/lib/ldap2/replog.txt done echo RESULT ---------------- Commands to execute slapd: ~$ sudo su # /usr/sbin/slapd -d 0x4400 -f /etc/ldap/slapd2.conf -h "ldap://127.0.0.1:3889" -u openldap -g openldap --------------- Varia: ~$ which bash /bin/bash ~$ ls -ld /var/lib/ldap2 drwxr-xr-x 2 openldap openldap 4096 2011-03-04 13:10 /var/lib/ldap2 Debug output from slapd: @(#) $OpenLDAP: slapd 2.4.9 (Jul 30 2010 00:42:11) $ buildd@vernadsky:/build/buildd/openldap2.3-2.4.9/debian/build/servers/slapd WARNING: No dynamic config support for database shell. slapd starting syncrepl_entry: rid=123 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=123 inserted UUID f25a0996-d888-102f-9c2e-559808098a6b execv failed shell: fgets failed: Success (0) str2result () expecting "RESULT" --------------------- ... over and over again. strace says: [pid 19068] execve("/usr/local/bin/backshell.sh", ["/usr/local/bin/backshell.sh"], ["SHELL=/bin/bash", "TERM=xterm", "USER=root", "LS_COLORS=no=00:fi=00:di=01;34:l"..., "SUDO_USER=mike", "SUDO_UID=1001", "USERNAME=root", "PATH=/usr/local/sbin:/usr/local/"..., "MAIL=/var/mail/root", "PWD=/home/mike", "LANG=en_US.UTF-8", "SHLVL=1", "SUDO_COMMAND=/bin/su", "HOME=/root", "LOGNAME=root", "LESSOPEN=| /usr/bin/lesspipe %s", "SUDO_GID=1001", "LESSCLOSE=/usr/bin/lesspipe %s %"..., "_=/usr/sbin/slapd"]) = -1 EACCES (Permission denied) ------------- Doesn't look like it's even able to execute my little program, right? So this may be more a question about the subtleties of execve (and possibly its interactions with sudo?) than about openldap, but if some kind soul can set me on the right path, I'd be most grateful. I've manpaged and googled everything I could think of, and drawn a blank. -- -- Michael J. Smith mjs(a)smithbowen.net

6 11

newbie scenario
by Lumeng Lim 14 Mar '11

14 Mar '11

mind you i've only managed to setup ldap server under ubuntu for now. we have 2 sites to manage and I would like for users( about 250 users total) in both sites that is connected via vpn to be able to login to samba/ldap in HQ are there things to consider before going about just setting up ldap and samba? assuming that samba is going to be used as pdc and fileserver.

2 1

Modified Records Deleted - Multimaster
by John s 13 Mar '11

13 Mar '11

Hi All, I have 2 way ldap multimaster setup . Recently User names are disappeared from two Master servers . Observed that when records are modified at one Master, records are removed from two servers next day . Enabled the logs and found no errors . Let me know during the syncrepl replication is their any chance of modified records being deleted from other Master server ... Thanks in advance for any help . Ldap Version: 2.4 Regards John

2 1

Dynamic modules unloading
by Коновалов Андрей Але ксандрович 13 Mar '11

13 Mar '11

Hello! I have OpenLDAP 2.4.24 built with -enable-dynamic and --enable-modules options So, dynamic modules support is on and my question is: Why can i load module (for example: dn: cn=module{0},cn=config changeType: modify add: olcModuleLoad olcModuleLoad: translucent.la ) But when i'm trying to unload it (because it's not used at all), i cant do this anywhere? dn: cn=module{0},cn=config changeType: modify delete: olcModuleLoad olcModuleLoad: {6}translucent.la # the same with simply olcModuleLoad: translucent.la modifying entry "cn=module{0},cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: cannot delete olcModuleLoad If it is not realised yet, you may consume my question as a feature request :)

2 1

delta-sync - ContextCSN on proivder older than consumers
by Yuri Bank 13 Mar '11

13 Mar '11

I've found an interesting issue with delta-sync replication in which the ContextCSN on my consumers, is higher than the contextCSN on my provider. I believe this is causing some other problems with bringing up brand new consumers. I use the following command to check the ContextCSN on each consumer: Consumer: 1 root@neteng1.oak:/etc/ldap# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" contextCSN dn: dc=test,dc=com SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <dc=test,dc=com> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN dn: dc=test,dc=com # # test.com dn: dc=test,dc=com contextCSN: 20110313041653.752098Z#000000#000#000000 # search result search: 2 result: 0 Success Consumer: 2 ybank@neteng1.iad:~$ ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" contextCSN dn: dc=test,dc=com SASL/EXTERNAL authentication started SASL username: gidNumber=1001+uidNumber=1010,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <dc=test,dc=com> with scope baseObject # filter: (objectclass=*) # requesting: contextCSN dn: dc=test,dc=com # # test.com dn: dc=test,dc=com contextCSN: 20110313041653.752098Z#000000#000#000000 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 So we can see that the two consumers have matching: ContextCSN. 20110313041653.752098Z#000000#000#000000 Lets check the Provider now. Provider: root@neteng0.iad:~# ldapsearch -Y EXTERNAL -H ldapi:/// -s base -b "dc=test,dc=com" ContextCSN dn: dc=test,dc=com SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 # extended LDIF # # LDAPv3 # base <dc=test,dc=com> with scope baseObject # filter: (objectclass=*) # requesting: ContextCSN dn: dc=test,dc=com # # test.com dn: dc=test,dc=com contextCSN: 20110313041653.709140Z#000000#000#000000 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 The providers CSN is smaller: contextCSN: 20110313041653.709140Z#000000#000#000000 Now I will search cn=accesslog on the Provider: These are the last two entries: # 20110313041653.000003Z, accesslog dn: reqStart=20110313041653.000003Z,cn=accesslog objectClass: auditAdd reqStart: 20110313041653.000003Z reqEnd: 20110313041653.000004Z reqType: add reqSession: 34633 reqAuthzID: cn=admin,dc=test,dc=com reqDN: cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com reqResult: 0 reqMod: sn:+ Bank reqMod: userPassword:+ {SASL}banky reqMod: uid:+ banky reqMod: objectClass:+ top reqMod: objectClass:+ person reqMod: objectClass:+ shadowAccount reqMod: structuralObjectClass:+ person reqMod: cn:+ Bank, Yuri(banky) reqMod: entryUUID:+ 78a75ef6-e174-102f-9571-ffecbfef68e5 reqMod: creatorsName:+ cn=admin,dc=test,dc=com reqMod: createTimestamp:+ 20110313041653Z reqMod: entryCSN:+ 20110313041653.709140Z#000000#000#000000 reqMod: modifiersName:+ cn=admin,dc=test,dc=com reqMod: modifyTimestamp:+ 20110313041653Z # 20110313041653.000006Z, accesslog dn: reqStart=20110313041653.000006Z,cn=accesslog objectClass: auditModify reqStart: 20110313041653.000006Z reqEnd: 20110313041653.000007Z reqType: modify reqSession: 34633 reqAuthzID: cn=admin,dc=test,dc=com reqDN: cn=SSLVPN,o=Groups,dc=test,dc=com reqResult: 0 reqMod: member:+ cn=Bank\2C Yuri(banky),o=UserAccounts,dc=test,dc=com reqMod: entryCSN:= 20110313041653.752098Z#000000#000#000000 reqMod: modifiersName:= cn=admin,dc=test,dc=com reqMod: modifyTimestamp:= 20110313041653Z # search result search: 2 result: 0 Success As you can see, the provider is not using the latest entryCSN as its ContextCSN, where as the consumer nodes are. Is this intended? An issue I've experienced with this is when bringing up a brand new consumer. It gets stuck in a loop trying to add that last entry. I'm guessing this has something to do with it using the wrong ConextCSN? - Yuri

2 1

ldapsearch and extended server controls?
by Brian Reichert 11 Mar '11

11 Mar '11

I have a case where I'm trying to replicate some other application's search against Active Directory. A deconstruction of a packet capture of that app's conversation shows it's making use of a control that I don't know how to specify using any combination of ldapsearch(1) or ldap.conf(5). Specifically, I see this coming over the wire as a control on the search: http://msdn.microsoft.com/en-us/library/aa366989%28v=vs.85%29.aspx 1.2.840.113556.1.4.417 LDAP_SERVER_SHOW_DELETED_OID Research shows there lots these sorts of extended control; yay, I learned something new! Is there a way of utilizing these sorts of controls via ldeapsearch? Thanks for any advice you may have... -- Brian Reichert <reichert(a)numachi.com> 55 Crystal Ave. #286 Derry NH 03038-1725 USA BSD admin/developer at large

2 2

Re: LDAP browsers and cn=config
by Gervase Markham 11 Mar '11

11 Mar '11

Hi Torsten, Thanks for your help! On 07/03/11 17:37, Torsten Schlabach (Tascel eG) wrote: > Take a look at the olcAccess attribute values of your cn=config database. > This should tell you who's allowed to read it or not. I did add a value to try and make this work (see below), but perhaps I haven't done all that's necessary. > It depends where your cn=config data comes from, but in many examples you > will find an olcAccess attribute granting write access to a DN called > cn=admin,cn=config. You need to have that object in your cn=config database > then and it should have the password attribute set. > > Post the olcAccess sections of your LDIF here, I think this may help. Here is my olcDatabase={0}config.ldif, with some comments: dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external ,cn=auth manage by * break # This one added by me recently: olcAccess: {0}to * by dn.exact=cn=admin,cn=config manage by * break structuralObjectClass: olcDatabaseConfig entryUUID: 9dfea13e-dd1c-102f-8cc4-2fe95e0d0dbe creatorsName: cn=config createTimestamp: 20110307153755Z entryCSN: 20110307153755.993390Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20110307153755Z # These two added by me recently: oldRootDN: cn=admin,cn=config olcRootPW: config So it looks like I just need to make sure I have the cn=admin,cn=config object in my database. And I think I can probably add it using the magic -Y EXTERNAL method and ldapadd. However, I don't know how to construct it - what objectClass should it have? Gerv

5 9

Simple Bind pass-through to SASL/PLAIN
by Zach Schimke 11 Mar '11

11 Mar '11

Is there any trick to this? I am able to get SASL/PLAIN and SASL/GSSAPI binds to work perfectly with my ldap server. What I want to get working is the authentication pass-through. From what I can gather, it appears that LDAP should be able to authenticate a simple bind, take a look at the userPassword attribute (which contains '{SASL}username@REALM) and perform a SASL/PLAIN from there. We want to avoid maintaining two separate passwords (LDAP and Kerberos V) although some applications (like phpLDAPAdmin, Drupal, etc) do not allow the use of Kerberos natively. /etc/sasl2/slapd.conf (using CentOS): pwcheck_method: saslauthd Here's a snippet of my openldap.log during a simple bind: Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 ACCEPT from IP=149.169.147.254:56106 (IP=0.0.0.0:636) Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 TLS established tls_ssf=256 ssf=256 Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 op=0 BIND dn="cn=test account,ou=people,o=mars" method=128 Mar 3 16:45:49 kdc1 slapd[28132]: send_ldap_result: conn=2009 op=0 p=3 Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 op=0 RESULT tag=97 err=49 text= Mar 3 16:45:49 kdc1 slapd[28132]: connection_closing: readying conn=2009 sd=39 for close Mar 3 16:45:49 kdc1 slapd[28132]: connection_close: conn=2009 sd=-1 Mar 3 16:45:49 kdc1 slapd[28132]: conn=2009 fd=39 closed (connection lost) Anything I should double-check, modify, etc? -- Zach Schimke Mars Space Flight Facility

4 10

php ldap binding problems
by Bram Cymet 11 Mar '11

11 Mar '11

Hi, Has anyone had to problem using php_ldap where the bind to ldap will work find but will unbind right away so any attempt to search the tree fails? If so were you able to fix it? -- Bram Cymet Software Developer Canadian Bank Note Co. Ltd. 613-608-9752

4 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical