openldap-technical

openldap-technical@openldap.org

9 participants
9876 discussions

setting max ssf with ldap_set_option
by Ken Dreyer 19 Aug '11

19 Aug '11

I have a small LDAP utility (msktutil) that talks to Active Directory using GSSAPI over TLS. I'm trying to set the SASL parameter "maxssf" to "0" in the code. I've found that in a recent version of OpenLDAP (2.4.24), modifying LDAP_OPT_X_SASL_SSF_MAX with ldap_set_option() has no effect. The basic code is sasl_ssf_t max_ssf = 0; printf( "setting max ssf to %d\n", max_ssf ); ldap_set_option(ld, LDAP_OPT_X_SASL_SSF_MAX, &max_ssf) Subsequent ldap_get_option() calls show that the value is not changing, as does the output when I bind with ldap_sasl_interactive_bind_s(). I would at the very least expect ldap_set_option() to return something other than LDAP_OPT_SUCCESS here. Am I hitting a bug in OpenLDAP, or am I really off track ? :) I've attached a small test case (gcc -o test test.c -lldap -llber). This works as I expect in both 2.3.43 and 2.4.23, and fails in 2.4.24. RHEL5: openldap-2.3.43-12.el5_6.7 ./test LDAP_OPT_X_SASL_SSF_MAX before setting = 2147483647 setting max ssf to 0 LDAP_OPT_X_SASL_SSF_MAX after setting = 0 RHEL6: openldap-2.4.23-15.el6_1.1.x86_64 ./test LDAP_OPT_X_SASL_SSF_MAX before setting = 2147483647 setting max ssf to 0 LDAP_OPT_X_SASL_SSF_MAX after setting = 0 Fedora 15: openldap-2.4.24-3.fc15.i686 ./test LDAP_OPT_X_SASL_SSF_MAX before setting = 2147483647 setting max ssf to 0 LDAP_OPT_X_SASL_SSF_MAX after setting = 2147483647

3 3

Re: Server Hangs
by Quanah Gibson-Mount 19 Aug '11

19 Aug '11

--On Tuesday, August 16, 2011 3:51 PM -0700 David Engeset <davidke(a)whidbey.net> wrote: > Below is how I generally configure BDB and OpenLDAP for normal > operational use. > I configured BDB with no parameters for all versions from 4.2 to > 5.1, so I ran: > > ../dist/configure > make&& make install For building BDB on *nix systems, you should specify: --enable-posixmutexes --with-mutex=POSIX/pthreads > For the debugging I did the following for BDB: > > env CFLAGS=-O2 ../dist/configure --enable-debug You need to use "-g" as I stated previously. CFLAGS="-g -O2 -fPIC" are the flags I pass to BDB. What we are looking for is the gcc debugging symbols. The --enable-debug flag looks like it does some internal debugging stuff in the BDB code which isn't really what we're asking for. > make&& make install > > For OpenLDAP: > > export LD_LIBRARY_PATH="/usr/local/BerkeleyDB.4.8/lib" > env CPPFLAGS="-I/usr/local/BerkeleyDB.4.8/include" CFLAGS="-g -O0" \ > LDFLAGS="-L/usr/local/BerkeleyDB.4.8/lib" ./configure --enable-wrappers \ > --enable-crypt --with-cyrus-sasl --with-tls --enable-debug > make depend&& make&& make install STRIP='' This looks good. Can you please re-generate your stack trace with a correctly build BDB behind openldap? Thanks! --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

3 5

Replication with cn=config
by Nocturn 18 Aug '11

18 Aug '11

I'm trying to set up repliction with OpenLDAP on SL:RHEL 6.1. OpenLDAP is by default configured with cn=config, but the replication documentation is still in the old slapd.conf format. Can anyone point me out how to get this up and running with cn=config? Thanks

3 3

migrating contents from openldap-2.1 to openldap-2.3.37
by Michael Kershaw 18 Aug '11

18 Aug '11

All, I've currently been tasked with migrating the contents of a contained ldap environment running openldap-2.1 to a new development server running sles11 with openldap-2.3.37. I've begun to populate the new environment, but have hit an "Invalid DN syntax" error that I'm not quite sure how to get around yet. I'm new to ldap from a server point of view, so I'm learning as I chug through this. This piece is what's in the existing 2.1: dn: group-name=EDI Technician,ou=group,ou=edi,dc=coat,dc=com objectClass: group-roles group-name: EDI Technician roles: EDI Technician And when I go to add: ldapadd -x -W -D "cn=edi_admin,ou=edi,dc=coat,dc=com" -f ./edi-tech_roles.ldif Enter LDAP Password: adding new entry "group-name=EDI Technician,ou=group,ou=edi,dc=coat,dc=com" ldap_add: Invalid DN syntax (34) additional info: invalid DN Is it the "group-name" that's no longer valid syntax? If so, is there an equivalent? Any help is appreciated! Mike

4 3

LDAP Stopping Frequently
by Nishant Goli -X (ngoli - Exobase Corporation at Cisco) 18 Aug '11

18 Aug '11

Hi Team, I have set up Open LDAP with Oracle as backend DB using back sql. Everything was running fine until recently. LDAP started going down frequently with the following line in the log. slapd: entry-id.c:867: backsql_get_attr_vals: Assertion `j < oldcount + count' failed and then the process goes down. Any help in troubleshooting this issue is greatly appreciated. Thanks Nishant

1 0

synchronizing ppolicy across different suffixes
by Tyler Gates 18 Aug '11

18 Aug '11

Is it possible to synchronize the same ppolicy across different suffixes on the same server? I would have thought referrals would take care of this and they to an extent but when the suffix that doesn't actually contain the policy entry gets a lockout request from failed attempts, pwdAccountLockedTime gets recorded on the same suffix from where it was originating -not the one being referenced. In the manual it states that ppolicy_forward_updates should take care of this but it requires updateref and the chain overlay (which must be setup under back_ldap) in order to work. The problem is when I setup back_ldap and point its database to the original policy entry, it complains that a previous database declaration has already claimed it -which is true because I have the database containing that policy entry on the same machine. Is there a way to do this or am I going about this wrong? Thanks, Tyler

1 0

DIT structure advice
by Olivier 18 Aug '11

18 Aug '11

Hi, My primary goal with an openldap directory is to store information to manage people authentification and autorisation to resources on my local network. But I also feel this directory to be a cool opportunity to maintain a registry that would include administrative information such as telephone number. Here is the DIT structure that I plan to deploy to to do that. If anyone has a comment or advice I would be grateful ! Summary : | ----------------------------- | STAFF=organizationalUnit | ----------------------------- _____| | | | | | | | | -> [ one entry per employee ] | | ------------------------- | John Doe=inetOrgPerson | -> [administrative data such as tel number] ------------------------- | ------------------ | doe=posixAccount | -> [ uid, password on so on ] ------------------ LDIF : Staff is a branch of people : # Entry 1: ou=staff,ou=people,dc=example,dc=fr dn: ou=staff,ou=people,dc=example,dc=fr objectclass: organizationalUnit objectclass: top ou: staff that contains as many inetOrgPerson as I have people in staff (here are recorded administrative data such as telephone number and so on) : # Entry 12: uid=doe,ou=staff,ou=people,dc=example,dc=fr dn: sn=doe,ou=staff,ou=people,dc=example,dc=fr sn: doe cn: john doe objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson Each "inetOrgPerson" may also have a "posixAccount" child that record information usable to access resources : dn: uid=doe,sn=doe,ou=staff,ou=people,dc=example,dc=fr cn: john doe gidnumber: 1800 homedirectory: /home/doe loginshell: /bin/tcsh objectclass: account objectclass: posixAccount objectclass: top objectclass: shadowAccount uid: doe uidnumber: 510 userpassword: {SSHA}*********************** --- Olivier

4 4

Server Hangs
by David Engeset 17 Aug '11

17 Aug '11

I upgraded and updated four of our OpenLDAP servers that we have back in May to run the latest stable version of OpenLDAP (2.4.23) along with BDB (4.8.30). Everything was running with no issues until a little over a month later one of the servers slapd processes hung, the only way I could restart the process was to use kill -9, all other kill options failed. Over the next month and a half the issue reoccurred on the same server and occurred on two of the other servers. There was nothing in the logs to indicate an issue with running out of file descriptors, dead locks or anything else. I set out to see if I could recreate the issue and I found if I had around 20000 entries, which our database is roughly around 21000, and ran a script to randomly query, one a time, the entries in the database and then run another script that added 1000 entries, one at a time, then deleted them in reverse order, one at a time, and will continue to do so infinitely. When I ran the two scripts simultaneously they would hang after 3 to 16 deletes were completed. I attempted to use the latest version of OpenLDAP (2.4.26) to see if any of the bug fixes in it would help and I still get the same results, I even tried to run it with all of the supported versions of BDB, 4.4, 4.5, 4.6, 4.7, 5.0 and 5.1 with the same results. I ran it with full logging on and I was not able to find any thing that pointed to the problem. We have been running OpenLDAP 2.2 and 2.3 for years (many servers without any restarting of slapd for over a year) without any lockups, so I decided to test with OpenLDAP 2.3.43 with BDB 4.2.52 (with patches) and loaded the same exact database and the same exact tests and it runs literally for hours with no issues. I attempted to upgrade the version of BDB to 4.4 and I started to experience the hanging again, so it appears to be a BDB issue. I searched for related issues with no success and considering that others are running 2.4 with newer versions of BDB for a couple of years now I find it odd that I am running into this issue on my first use of 2.4. I tested all of this on CentOS 5.4, 5.6 and Fedora 17 with the same results. Does anyone have any ideas or suggestions on what I can try to do to fix this issue? Below are some of the configs I am using on my last attempts to resolve the issue: DB_CONFIG: set_cachesize 0 536870912 1 set_lg_regionmax 10485760 set_lg_max 104857600 set_lg_bsize 2097152 set_lg_dir /var/log/bdb set_tmp_dir /var/log/bdb # This one I added recently to see if it might help. set_lk_detect DB_LOCK_DEFAULT slapd.conf: include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/misc.schema include /usr/local/etc/openldap/schema/inetorgperson.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args conn_max_pending 1000 database bdb cachesize 20000 suffix "dc=example,dc=net" checkpoint 5120 30 rootdn "cn=Manager,dc=example,dc=net" rootpw secrect directory /usr/local/var/openldap-data # Indices to maintain index default pres,eq index cn,uid #index WhidNetCustID,CustID,ID index sn pres,eq,sub index objectClass eq index uidNumber eq index gidNumber eq index memberUid eq # database access control definitions access to attrs=userPassword by self write by anonymous auth by dn="cn=Admin,dc=example,dc=net" write by * none access to * by self write by dn="cn=Admin,dc=example,dc=net" write by * read I can send out the LDIF I am using and the perl scripts that I run to break it for anyone who is interested. Thank you, -- David Whidbey Telecom Internet and Broadband Software Engineer

4 4

How to design an architecture of OpenLDAP for satisfy our needs?
by ma hao (163) 17 Aug '11

17 Aug '11

Hi all, We got a problem about our authentication architecture. Here is our situation: We are using two parts for user authentication, which both are openldap service. One is password OpenLDAP service on remote server. One is groups information OpenLDAP service, which also is user's permission info, on local server. In fact we could not get the user password in our local Openldap, pasword information stored in remote openldap which could not get our local group inforamtion. Do you have any idea to make our local OpenLDAP using remote OpenLDAP authorize the password and using local OpenLDAP supply groups information? Best Regards Ma Hao

2 1

seg fault with TLS syncrepl ?
by Olivier 17 Aug '11

17 Aug '11

My N-WAY replication works properly with a "bindmethod=simple". However, I don't like keeping a password in clear in a configuration file, then I tryed this : On server "ldap-master1.example.fr" : TLSVerifyClient allow syncrepl rid=101 provider=ldap://ldap-master2.example.fr:389 searchbase="dc=example,dc=fr" schemachecking=on type=refreshOnly interval=00:00:01:00 retry="10 +" bindmethod=sasl saslmech=EXTERNAL starttls=critical tls_cert=/etc/openldap/cacerts/master1/server.crt tls_key=/etc/openldap/cacerts/master1/server.key tls_cacert=/etc/openldap/cacerts/CA.crt tls_reqcert=demand On server "ldap-master2.example.fr" : TLSVerifyClient allow syncrepl rid=201 provider=ldap://ldap-master1.example.fr:389 searchbase="dc=example,dc=fr" schemachecking=on type=refreshOnly interval=00:00:01:00 retry="10 +" bindmethod=sasl saslmech=EXTERNAL starttls=critical tls_cert=/etc/openldap/cacerts/master2/server.crt tls_key=/etc/openldap/cacerts/master2/server.key tls_cacert=/etc/openldap/cacerts/CA.crt I get a segmentation fault : ldap-master1 #$ /usr/sbin/slapd -h ldap:/// -u ldap -d256 @(#) $OpenLDAP: slapd 2.4.23 (Apr 12 2011 19:26:36) $ mockbuild@x86-001.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd bdb_monitor_db_open: monitoring disabled; configure monitor database to enable <= bdb_inequality_candidates: (entryCSN) not indexed slapd starting slap_client_connect: URI=ldap://ldap-master2.example.fr:389 Error, ldap_start_tls failed (-1) do_syncrepl: rid=101 rc -1 retrying conn=1000 fd=12 ACCEPT from IP=10.1.92.25:47353 (IP=0.0.0.0:389) conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=1000 op=0 STARTTLS conn=1000 op=0 RESULT oid= err=0 text= conn=1000 fd=12 TLS established tls_ssf=256 ssf=256 conn=1000 op=1 BIND dn="" method=163 conn=1000 op=1 BIND authcid="email=max(a)example.fr,cn=ldap-master2.example.fr,ou=ldap,o=example,l=somewhere,st=france,c=fr" authzid="email=max(a)example.fr,cn=ldap-master2.example.fr,ou=ldap,o=example,l=somewhere,st=france,c=fr" conn=1000 op=1 BIND dn="email=max(a)example.fr,cn=ldap-master2.example.fr,ou=ldap,o=example,l=somewhere,st=france,c=fr" mech=EXTERNAL sasl_ssf=0 ssf=256 conn=1000 op=1 RESULT tag=97 err=0 text= conn=1000 op=2 SRCH base="dc=example,dc=fr" scope=2 deref=0 filter="(objectClass=*)" conn=1000 op=2 SRCH attr=* + conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= conn=1000 op=3 UNBIND conn=1000 fd=12 closed Erreur de segmentation The segfault happened when the second server tried to sync with the first one : [root@ldap-master2 cacerts]# /usr/sbin/slapd -h ldap:/// -u ldap -d256 @(#) $OpenLDAP: slapd 2.4.23 (Apr 12 2011 19:26:36) $ mockbuild@x86-001.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/build-servers/servers/slapd bdb_monitor_db_open: monitoring disabled; configure monitor database to enable slapd starting conn=1000 fd=12 ACCEPT from IP=10.1.92.24:55208 (IP=0.0.0.0:389) conn=1000 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=1000 op=0 STARTTLS conn=1000 op=0 RESULT oid= err=0 text= TLS: error: accept - force handshake failure: errno 2 - moznss error -5938 TLS: can't accept: TLS error -5938:Encountered end of file. conn=1000 fd=12 closed (TLS negotiation failure) ^C daemon: shutdown requested and initiated. slapd shutdown: waiting for 0 operations/tasks to finish slapd stopped. Any idea ? NOTE : if I start the daemon on ldap-master2, that's ldap-master2 that produce the seg fault. --- Olivier

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical