openldap-technical

openldap-technical@openldap.org

9897 discussions

slapd deferring operation?
by Aleksander Dzierżanowski 29 Oct '13

29 Oct '13

Hi. I’m trying to migrate small other vendor LDAP server to OpenLDAP. I've created test environment with 3 multimaster OpenLDAP instances - version 2.4.36. Below is some strange behavior of slapd while I was adding few hunderd of accounts from ldif file using ‚ldapadd’ command from remote host. […] conn=1015 op=440 ADD dn=„uid=XXX,ou=People,ou=developers,o=test" conn=1015 op=440 RESULT tag=105 err=0 text= connection_input: conn=1015 deferring operation: too many executing conn=1015 op=441 ADD dn=„uid=YYY,ou=People,ou=developers,o=test" conn=1015 op=441 RESULT tag=105 err=0 text= […] My question is what does mean 'deferring operation’ - as you can see result is OK (err=0) so nothing was really deferred. Database is really small - few hundred entries, and server is not used at all by any other machine. I was using rootdn user which I suppose does not have any limits for search/add/mod operations? Is it some configuration issue? I also observe the same ‚deferring’ info in log file when there is only a single host client connected to this LDAP server - RedHat/CentOS with configured sssd. They are not so often but appear regularly. — Olo

3 2

use openssl or moznss for more than TLS?
by Steve Eckmann 28 Oct '13

28 Oct '13

We need a FIPS-validated SHA512 for password storage. The pw-sha2 module provides SHA512 but isn't FIPS-validated. I see that I can use openssl or moznss in FIPS mode to get TLS, but I don't see how to get to either of those library's crypto functions from openldap. Is it possible? Thanks. Steve

6 8

Migrating to N-Way Master
by Peter Sprokkelenburg 28 Oct '13

28 Oct '13

Currently have a provider / consumer setup in one datacenter. Looking to expand to other datacentre and would like better redundancy. Running version 2.4.28. What's the best way to change from provider / consumer to n-way master? Down time is an option. Can the current replication be stopped, reconfigured and then started again? ---- Peter

3 16

Can multiple threads use the same MDB transaction?
by Petri Huovinen＠ 24 Oct '13

24 Oct '13

Hi, Can multiple threads access to the same MDB transaction and issue read-only calls between opening and closing the MDB_cursors? More detail, we would like to use MDB_NOTLS flag when opening the MDB environments, start read-only transaction in a single thread. Then we would like to use this transaction in the multiple threads simultaneously (opening cursors, reading, closing cursors). Only after these operations are finalized we would then commit the transaction in a single thread. The same question applies to the read-write transaction. The only differences would be that MDB_NOTLS flag is not relevant and that we would anyway serialize the update operations and would not allow parallel read operations and update operations. Does MDB support the above scenario? If not, what is the reason? Thanks, Petri Huovinen

1 0

slapd-ldap and Multiple URIs: Dealing with hosts that are down
by Jesus Jr M Salvo 24 Oct '13

24 Oct '13

Using the meta backend, I have specified a list of LDAP URIs. I am testing what happens if the first URI becomes unresponsive ( e.g. The host was shutdown, etc. ). So I deliberately put in a bogus URI as the first URI that I know will not respond ( TCP SYN would be sent out by OpenLDAP, but no TCP ACK coming back ): ##################### backend meta database meta access to * by * read suffix "dc=ldapproxy,dc=local" uri ldap://10.10.10.10/dc=aas,dc=priv,dc=ldapproxy,dc=local ldap://aassydc02.aas.priv/ suffixmassage "dc=aas,dc=priv,dc=ldapproxy,dc=local" "dc=aas,dc=priv" chase-referrals no lastmod off protocol-version 3 timeout 10 ##################### With the above timeout setting, I was hoping that after 10 seconds, OpenLDAP will try the next URI it the first URI did not respond ... but it did not as per tshark capture below. What setting do I need to accomplish what I need ? 0.000000 127.0.0.1 -> 127.0.0.1 TCP 76 50649 > ldap [SYN] Seq=0 Win=32792 Len=0 MSS=16396 SACK_PERM=1 TSval=133287492 TSecr=0 WS=128 0.000021 127.0.0.1 -> 127.0.0.1 TCP 76 ldap > 50649 [SYN, ACK] Seq=0 Ack=1 Win=32768 Len=0 MSS=16396 SACK_PERM=1 TSval=133287492 TSecr=133287492 WS=128 0.000035 127.0.0.1 -> 127.0.0.1 TCP 68 50649 > ldap [ACK] Seq=1 Ack=1 Win=32896 Len=0 TSval=133287492 TSecr=133287492 0.000090 127.0.0.1 -> 127.0.0.1 LDAP 118 bindRequest(1) "cn=admin,dc=ldapproxy,dc=local" simple 0.000102 127.0.0.1 -> 127.0.0.1 TCP 68 ldap > 50649 [ACK] Seq=1 Ack=51 Win=32768 Len=0 TSval=133287492 TSecr=133287492 0.000829 127.0.0.1 -> 127.0.0.1 LDAP 82 bindResponse(1) success 0.000856 127.0.0.1 -> 127.0.0.1 TCP 68 50649 > ldap [ACK] Seq=51 Ack=15 Win=32896 Len=0 TSval=133287493 TSecr=133287493 0.000909 127.0.0.1 -> 127.0.0.1 LDAP 158 searchRequest(2) "DC=ldapproxy,DC=local" wholeSubtree 0.001196 172.21.17.193 -> 10.10.10.10 TCP 76 58293 > ldap [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133287493 TSecr=0 WS=128 0.040403 127.0.0.1 -> 127.0.0.1 TCP 68 ldap > 50649 [ACK] Seq=15 Ack=141 Win=32768 Len=0 TSval=133287503 TSecr=133287493 1.001055 172.21.17.193 -> 10.10.10.10 TCP 76 58293 > ldap [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133287743 TSecr=0 WS=128 3.006852 172.21.17.193 -> 10.10.10.10 TCP 76 58293 > ldap [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133288244 TSecr=0 WS=128 7.013361 172.21.17.193 -> 10.10.10.10 TCP 76 58293 > ldap [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133289246 TSecr=0 WS=128 15.020550 172.21.17.193 -> 10.10.10.10 TCP 76 58293 > ldap [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133291248 TSecr=0 WS=128 31.052492 172.21.17.193 -> 10.10.10.10 TCP 76 58293 > ldap [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133295256 TSecr=0 WS=128 60.063874 172.21.17.193 -> 10.10.10.10 TCP 76 58295 > ldap [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133302508 TSecr=0 WS=128 61.060500 172.21.17.193 -> 10.10.10.10 TCP 76 58295 > ldap [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133302758 TSecr=0 WS=128 63.065447 172.21.17.193 -> 10.10.10.10 TCP 76 58295 > ldap [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=133303259 TSecr=0 WS=128

3 4

Syncrepl with subordinate databases
by Robert Minsk 24 Oct '13

24 Oct '13

I have multiple sites that I am trying to sync up to a global server. Each site is configured (striped down) as: ############################################################################ # mdb database for o=chi01,ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "o=chi01,ou=studios,dc=methodstudios,dc=net" # Save the time that the entry gets modified lastmod on # Subordinate of the ou=studios,dc=methodstudios,dc=net database below subordinate advertise overlay syncprov syncprov-reloadhint TRUE syncprov-checkpoint 100 5 ############################################################################ # mdb database for ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "ou=studios,dc=methodstudios,dc=net" The above is my configuration for Chicago. I have similar ones for New York (ny01) and Los Angeles (la01) On my global server I am trying to use sync replication to clone each site. The global server is configured (striped down) as: ############################################################################ # mdb database for o=global,ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "o=global,ou=studios,dc=methodstudios,dc=net" # Save the time that the entry gets modified lastmod on # Subordinate of the ou=studios,dc=methodstudios,dc=net database below subordinate advertise overlay syncprov syncprov-reloadhint TRUE syncprov-checkpoint 100 5 ############################################################################ # mdb database for o=chi01,ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "o=chi01,ou=studios,dc=methodstudios,dc=net" # Subordinate of the ou=studios,dc=methodstudios,dc=net database below subordinate advertise syncrepl rid=1 provider=ldap://chi01.methodstudios.com type=refreshOnly retry="60 10 300 +" interval=00:00:10:00 searchbase="o=chi01,ou=studios,dc=methodstudios,dc=net" bindmethod=simple starttls=yes binddn="****" credentials=**** schemachecking=off ############################################################################ # mdb database for o=ny01,ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "o=ny01,ou=studios,dc=methodstudios,dc=net" # Subordinate of the ou=studios,dc=methodstudios,dc=net database below subordinate advertise syncrepl rid=2 provider=ldap://ny01.methodstudios.com type=refreshOnly retry="60 10 300 +" interval=00:00:10:00 searchbase="o=ny01,ou=studios,dc=methodstudios,dc=net" bindmethod=simple starttls=yes binddn="****" credentials=**** schemachecking=off ############################################################################ # mdb database for ou=studios,dc=methodstudios,dc=net ############################################################################ database mdb suffix "ou=studios,dc=methodstudios,dc=net" overlay glue overlay syncprov syncprov-reloadhint TRUE syncprov-checkpoint 100 5 Now that I have the configuration out of the way. Syncrepl on the global server is failing on chi01. The chi01 server syslog has Oct 23 18:41:35 boote01-chi01 slapd[19324]: conn=1000 op=2 SRCH base="o=chi01,ou=studios,dc=methodstudios,dc=net" scope=2 deref=0 filter="(objectClass=*)" Oct 23 18:41:35 boote01-chi01 slapd[19324]: conn=1000 op=2 SRCH attr=* + Oct 23 18:41:35 boote01-chi01 slapd[19324]: conn=1000 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Oct 23 18:41:35 boote01-chi01 slapd[19324]: conn=1000 op=3 UNBIND Looking at the ny01 server (ldapsearch -x -h ny01 -b o=ny01,ou=studios,dc=methodstudios,dc=net -s base +) where syncrepl is working # ny01, studios, methodstudios.net dn: o=ny01,ou=studios,dc=methodstudios,dc=net structuralObjectClass: organization entryUUID: 257c5408-717c-1032-9b24-31eddc101779 creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net createTimestamp: 20130625004432Z entryCSN: 20130625004432.932104Z#000000#000#000000 modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net modifyTimestamp: 20130625004432Z contextCSN: 20131023210335.999443Z#000000#000#000000 entryDN: o=ny01,ou=studios,dc=methodstudios,dc=net subschemaSubentry: cn=Subschema hasSubordinates: TRUE Looking at the global server (ldapsearch -x -h global -b o=ny01,ou=studios,dc=methodstudios,dc=net -s base +): # ny01, studios, methodstudios.net dn: o=ny01,ou=studios,dc=methodstudios,dc=net structuralObjectClass: organization entryUUID: ccbe6442-d084-1032-8149-e14ce02952dd creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net createTimestamp: 20131023231549Z entryCSN: 20131023231549.982220Z#000000#000#000000 modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net modifyTimestamp: 20131023231549Z entryDN: o=ny01,ou=studios,dc=methodstudios,dc=net subschemaSubentry: cn=Subschema hasSubordinates: FALSE Notice no contextCSN. Looking at the chi01 server (ldapsearch -x -h chi01 -b o=chi01,ou=studios,dc=methodstudios,dc=net -s base +): # chi01, studios, methodstudios.net dn: o=chi01,ou=studios,dc=methodstudios,dc=net structuralObjectClass: organization entryUUID: 4b4f63f6-81bb-1032-97d3-7d320a684bf1 creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net createTimestamp: 20130715165653Z entryCSN: 20130715165653.289427Z#000000#000#000000 modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net modifyTimestamp: 20130715165653Z contextCSN: 20131018000127.430328Z#000000#000#000000 entryDN: o=chi01,ou=studios,dc=methodstudios,dc=net subschemaSubentry: cn=Subschema hasSubordinates: TRUE Looking at the global server (ldapsearch -x -h global -b o=chi01,ou=studios,dc=methodstudios,dc=net -s base +): # chi01, studios, methodstudios.net dn: o=chi01,ou=studios,dc=methodstudios,dc=net structuralObjectClass: organization entryUUID: cc675698-d084-1032-8eb1-f1b765ca1756 creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net createTimestamp: 20131023231549Z entryCSN: 20131023231549.411641Z#000000#000#000000 modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net modifyTimestamp: 20131023231549Z entryDN: o=chi01,ou=studios,dc=methodstudios,dc=net subschemaSubentry: cn=Subschema hasSubordinates: FALSE Notice no contextCSN. Looking at the global server root of the glued database (ldapsearch -x -h global -b ou=studios,dc=methodstudios,dc=net -s base +): # studios, methodstudios.net dn: ou=studios,dc=methodstudios,dc=net structuralObjectClass: organizationalUnit entryUUID: cc769b12-d084-1032-86fe-a1b1821abdab creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net createTimestamp: 20131023231549Z entryCSN: 20131023231549.511823Z#000000#000#000000 modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net modifyTimestamp: 20131023231549Z contextCSN: 20131024000524.348070Z#000000#000#000000 entryDN: ou=studios,dc=methodstudios,dc=net subschemaSubentry: cn=Subschema hasSubordinates: FALSE So after all that. Is the syncrepl from chi01 using the contextCSN from the root of the glued database? It seems all the syncrepl from all the sites fail unless they have the latest change. How do you handle syncrepl on glued databases? -- Robert Minsk Systems and Software Engineer WWW.METHODSTUDIOS.COM <http://www.methodstudios.com> 730 Arizona Ave, Santa Monica, CA 90401 O:+1 310 434 6500 <tel:+13104346500> // F:+1 310 434 6501 <tel:+13104346501> Los Angeles <http://www.methodstudios.com/signature/url/los-angeles><http://www.methodstudios.com/signature/url/los-angeles> This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed.

3 6

Re: RE24 testing call (OpenLDAP 2.4.37)
by Marco Pizzoli 24 Oct '13

24 Oct '13

All tests fine even here. Compiled HDB and MDB on RHEL6.4 64bit with gperftool. Regards Marco On Tue, Oct 22, 2013 at 10:27 PM, Quanah Gibson-Mount <quanah(a)zimbra.com>wrote: > If you know how to build OpenLDAP manually, and would like to participate > in testing the next set of code for the 2.4.37 release, please do so. > > Generally, get the code for RE24: > > <http://www.openldap.org/**devel/gitweb.cgi?p=openldap.** > git;a=snapshot;h=refs/heads/**OPENLDAP_REL_ENG_2_4;sf=tgz<http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…> > > > > Configure & build. > > Execute the test suite (via make test) after it is built. > > Thanks! > > --Quanah > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > >

1 0

Re: LDAP: error code 69 - structural object class modification
by Artur Nike 24 Oct '13

24 Oct '13

Thank you for your help. Yes I did, the extension of such objects STRUCTURAL, Auxiliary facilities (including the new attributes.) It works :). Regards Mariusz 2013/10/23 Quanah Gibson-Mount <quanah(a)zimbra.com> > --On Wednesday, October 23, 2013 12:44 PM +0200 Artur Nike < > opalsie(a)gmail.com> wrote: > > > The only thing that works is: >> -export facility to ldif >> -swapping of a new class (which inherits old) >> -Remove the item from the tree, >> -add the ldif (with swapped class) >> >> >> Maybe I do not understand something, ask for help, how to expand objects >> > > An object can only be of one structural type. I.e., you cannot simply > make an apple become an orange. You may wish to look at using an AUXILIARY > objectClass to "add-on" attributes to an existing object. > > --Quanah > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

Re: Re: OpenLDAP 2.3.4 TLS negotiation failure
by Tian Zhiying 23 Oct '13

23 Oct '13

Hi Dieter： Thanks for your quick reply. I have changed 'TLS_REQCERT try' and check the commonName of the host certificate, the common name is LDAP Server hostname "auth.server.com", the following is the query results: [root@auth cacerts]# openssl s_client -connect localhost:636 -showcerts -state -CAfile /etc/openldap/cacerts/cacert.pem CONNECTED(00000003) SSL_connect:before/connect initialization SSL_connect:SSLv2/v3 write client hello A SSL_connect:SSLv3 read server hello A depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=auth.server.com/emailAddress=tianzy(a)server.com verify error:num=18:self signed certificate verify return:1 depth=0 /C=CN/ST=BJ/L=BJ/O=TS/OU=IT/CN=auth.server.com/emailAddress=tianzy(a)server.com verify return:1 SSL_connect:SSLv3 read server certificate A SSL_connect:SSLv3 read server certificate request A SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client certificate A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A SSL_connect:SSLv3 flush data SSL_connect:SSLv3 read finished A Now, the /etc/openldap/ldap.conf file: URI ldap://ldap.server.com/ BASE dc=server,dc=com TLS_CACERT /etc/openldap/cacerts/cacert.pem #SSL ON TLS_REQCERT try But, run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I also get the following error: [root@client cacerts]# ldapsearch -x -H ldap://ldap.server.com -ZZ ldap_start_tls: Connect error (-11) Tian Zhiying From: DieterKlünter Date: 2013-10-23 17:35 To: openldap-technical CC: tianzy1225 Subject: Re: OpenLDAP 2.3.4 TLS negotiation failure Am Wed, 23 Oct 2013 16:47:25 +0800 schrieb "Tian Zhiying" <tianzy1225(a)thundersoft.com>: > Hi > > On the LDAP Server , I run following command is ok: > #ldapsearch -x -H ldap://ldap.server.com -ZZ > #ldapsearch -x -H ldap://ldap.server.com > > But on my client , I run "#ldapsearch -x -H ldap://ldap.server.com", > is ok; Run "#ldapsearch -x -H ldap://ldap.server.com -ZZ" , I get the > following error: [root@client cacerts]# ldapsearch -x -H > ldap://ldap.server.com -ZZ ldap_start_tls: Connect error (-11) > > On LDAP Server log file, I get the following error messages: > Oct 23 16:41:25 auth slapd[4213]: conn=206 fd=24 ACCEPT from > IP=192.168.9.9:45648 (IP=0.0.0.0:389) Oct 23 16:41:25 auth > slapd[4213]: conn=206 op=0 STARTTLS Oct 23 16:41:25 auth slapd[4213]: > conn=206 op=0 RESULT oid= err=0 text= Oct 23 16:41:25 auth > slapd[4213]: conn=206 fd=24 closed (TLS negotiation failure) > > My client ldap configuration: > /etc/openldap/ldap.conf file: > URI ldap://ldap.server.com/ > BASE dc=server,dc=com > TLS_CACERT /etc/openldap/cacerts/ca.crt > SSL ON > TLS_REQCERT demand Set 'TLS_REQCERT try' and check the commonName of the host certificate. SSL ON is not an openldap configuration parameter. The /etc/ldap.conf file is not a openldap client configuration file, but of nss_ldap. > /etc/ldap.conf file: > BASE dc=server,dc=com > URI ldap://ldap.server.com > SSL ON > TLS_CACERT /etc/openldap/cacert/ca.crt > TLS_REQCERT demand > > Any suggestion what cause TLS negotiation failure? -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E

2 2

slapo-nssov and authz2dn
by btb＠bitrate.net 23 Oct '13

23 Oct '13

i'm experimenting with the authz2dn setting for olcnsspam: dn: olcOverlay={7}nssov,olcDatabase={2}mdb,cn=config objectClass: olcConfig objectClass: olcNssOvConfig objectClass: olcOverlayConfig olcOverlay: {7}nssov olcNssMap: group uniquemember member olcNssPam: authz2dn hostservice olcNssPamSession: login olcNssPamSession: sshd it seems to work, but only if i have no olcauthzregexp attributes, and i see no references to cn=<service>+uid=<user>,cn=<hostname>,cn=pam,cn=auth in the slapd log [using -d -1]. if i add an olcauthzregexp [for example: uid=([^,]*),cn=plain,cn=auth uid=$1,ou=people,ou=accounts,dc=example,dc=com, this seems to break nssov, and i'm unable to login [ssh], with pam denying me: Oct 19 19:55:23 dsa1 sshd[30458]: pam_ldap(sshd:account): nslcd authorisation; user=jdoe Oct 19 19:55:23 dsa1 sshd[30458]: pam_ldap(sshd:account): Access denied for this service; user=jdoe Oct 19 19:55:23 dsa1 sshd[30458]: fatal: Access denied for user jdoe by PAM account configuration [preauth] i don't understand why a seemingly unrelated olcauthzregexp is breaking this, but i'm also not confident i'm using authz2dn properly. man 5 slapo-nssov says "If no mapping is found for this authentication DN, then this mapping will be ignored.", but i don't think i understand that clearly. is that saying that failure to find a match via an olcauthzregexp mapping is not considered a failure to find a dn? if i remove authz2dn [and thus use uid2dn] then presence of the above olcauthzregexp value doesn't break nssov. when using -d -1, should i see references to cn=<service>+uid=<user>,cn=<hostname>,cn=pam,cn=auth? what am i doing wrong? thanks -ben

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical