openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

Grant access to a group
by Onno van der Straaten 23 Jan '13

23 Jan '13

Hi, I would like to grant access to a group in my directory. Granting access to user is straightforward and works, for example access to attrs=myAttribute by dn="cn=User,dc=mydomain,dc=com" write by anonymous auth by users read by * none Now I'm trying to do the same using a group for example access to attrs=myAttribute by group/groupOfUniqueNames/uniqueMember="cn=ldap-admins,dc=groups,dc=mydomain,dc=com" write by anonymous auth by users read by * none I can't get this to work. I tried by group and by group.exact, these also don't work. From the documentation I understand that by group assumes objectClass 'groupOfNames' and attribute 'member' I used groupOfUniqueNames and uniqueMember so the configuration ended up as above. Is is possible to grant access to the directory in such a way? To a group? How? Best Regards, Onno

1 0

bug on dynamic configuration with back-sql
by Benin Technologies 22 Jan '13

22 Jan '13

Hi, I'm on Debian 6 / OpenLDAP 2.4.33 with back-sql. According to http://www.openldap.org/software/release/changes.html, back-sql supports dynamic config as of version 2.4.27. So I converted slapd.conf to slapd.d, conversion went well. However, when I start slapd, I get the following message : # /usr/local/libexec/slapd -u openldap -g openldap -d -1 ....... 50ff3f0a <<< dnPrettyNormal: <cn=root,dc=example,dc=com>, <cn=root,dc=example,dc=com> 50ff3f0a olcSqlInsEntryStmt: value #0: <olcSqlInsEntryStmt> extra cruft after <SQL expression>. 50ff3f0a config error processing olcDatabase={1}sql,cn=config: <olcSqlInsEntryStmt> *extra cruft after <SQL expression>* 50ff3f0a send_ldap_result: conn=-1 op=0 p=0 50ff3f0a send_ldap_result: err=19 matched="" text="" 50ff3f0a slapd destroy: freeing system resources. 50ff3f0a slapd stopped. 50ff3f0a connections_destroy: nothing to destroy. I took a look into olcDatabase={1}sql.ldif, and I saw that olcSqlInsEntryStmt was splitted on two lines : olcSqlInsEntryStmt: insert into ldap_entries (id,dn,oc_map_id,parent,keyval) v alues ((select max(id)+1 from ldap_entries),?,?,?,?) I tries to put everything on the same line, like : olcSqlInsEntryStmt: insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from ldap_entries),?,?,?,?) But the error persists. If I comment that line, the server starts fine # olcSqlInsEntryStmt: insert into ldap_entries (id,dn,oc_map_id,parent,keyval) values ((select max(id)+1 from ldap_entries),?,?,?,?)

1 0

slapcat output is truncated every now and then
by Balint Reczey 22 Jan '13

22 Jan '13

Dear Members of OpenLDAP Technical List, Could you please help in finding and explanation and potentially a fix for the bug reported at [1]? It seems it has been found often enough by Elmar as well to write a workaround [2]. Thanks, Balint [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673038 [2] https://github.com/elmar/ldap-git-backup/blob/master/README.mdown#safe-ldif On 06/19/2012 06:27 PM, Quanah Gibson-Mount wrote: > --On Tuesday, June 19, 2012 2:25 PM +0200 Axel Beckert > <abe(a)debian.org> wrote: > >> Hi Steve, >> >> Steve Langasek wrote: >>> > According to the slapcat man page it should be "always safe to run >>> > slapcat with the slapd-bdb(5) ... backends" even if slapd runs. We do >>> > use a BDB backend. >>> >>> Note that the HDB backend is the one recommended upstream and the >>> Debian >>> default. >> >> Well, yeah, that system has been dist-upgraded from at least Etch. >> IIRC it started at some time when BDB was still the default. >> >> I wrote that -- according to our backups -- this happened already with >> Lenny's slapd. But with Lenny it seemed to have happened less often >> (which is why we noticed it only recently). > > Personally, I would advise you to ask a question about this on > openldap-technical(a)openldap.org. I asked Howard about it, and he had > a ready answer as to why you were seeing this, but I forget what it > is. In any case, this is not a debian specific openldap bug. > > --Quanah > ...

2 1

Re: Replication not working
by anil beniwal 22 Jan '13

22 Jan '13

> > I will be highly thankful to you, if you can help me out in below issue. > > We have three servers on rhel 6.3, 16 vcpu and 32G RAM , openldap 2.4.33 > with mdb db of 200G > > We are facing replication issue on our servers, otherwise servers are good > with login and user registration from website.(doing on one server only as > of now) > > We imported data on one server mmam01 and copied it to other 2 servers. > After some time we got big diff b/w db size of mmam01 and other two servers. > Then exported data and restored it on other two servers. > > i tried adding a user and i got replicated to other two servers, but after > some time, new users stop getting replicated to other servers. > > initial replication status after some 30 min > > Even when i tried with blank db it initally started and then stopped. i got errors like dn_callback : entries have identical CSN syncrepl_entry: rid=111 entry unchanged, ignored > Sat Jan 12 12:40:41 EST 2013 > > DR-SJ > contextCSN: 20130101132757.303803Z#000000#000#000000 > contextCSN: 20130111144013.926562Z#000000#001#000000 > contextCSN: 20130112174023.266193Z#000000#002#000000 > DC-mmam01 > contextCSN: 20130101132757.303803Z#000000#000#000000 > contextCSN: 20130112174006.314483Z#000000#001#000000 > contextCSN: 20130112174023.266193Z#000000#002#000000 > DC-mmam04 > contextCSN: 20130101132757.303803Z#000000#000#000000 > contextCSN: 20130111144013.926562Z#000000#001#000000 > contextCSN: 20130112174023.266193Z#000000#002#000000 > > After 2 hours > > DR-SJ > contextCSN: 20130101132757.303803Z#000000#000#000000 > contextCSN: 20130111144013.926562Z#000000#001#000000 > contextCSN: 20130112174023.266193Z#000000#002#000000 > contextCSN: 20130112175710.938307Z#000000#003#000000 > DC-mmam01 > contextCSN: 20130101132757.303803Z#000000#000#000000 > contextCSN: 20130112193219.242546Z#000000#001#000000 > contextCSN: 20130112174023.266193Z#000000#002#000000 > contextCSN: 20130112175710.938307Z#000000#003#000000 > DC-mmam04 > contextCSN: 20130101132757.303803Z#000000#000#000000 > contextCSN: 20130111144013.926562Z#000000#001#000000 > contextCSN: 20130112174023.266193Z#000000#002#000000 > contextCSN: 20130112175710.938307Z#000000#003#000000 > > My ldap.conf file is(same on all server) , we have host-ip mapping in > /etc/hosts file > > BASE dc=example, dc=com > URI ldap://mmam01.com ldaps://mmam01.com ldap://mmam04.com ldaps:// > mmam04.com ldap://sjam01.com ldaps://sjam01.com > TLS_REQCERT demand > TLS_CACERT /etc/openldap/cacerts/cacert.pem > > slapd.conf file(from mmam01) > > include /etc/openldap/schema/core.schema > include /etc/openldap/schema/cosine.schema > include /etc/openldap/schema/nis.schema > include /etc/openldap/schema/inetorgperson.schema > include /etc/openldap/schema/openldap.schema > include /etc/openldap/schema/dyngroup.schema > include /etc/openldap/schema/ppolicy.schema > include /etc/openldap/schema2/channelIdentifier.schema > include /etc/openldap/schema2/platform.schema > include /etc/openldap/schema2/extendedProfileKey.schema > include /etc/openldap/schema2/extendedProfileValue.schema > include /etc/openldap/schema2/behaviorKey.schema > include /etc/openldap/schema2/behaviorValue.schema > include /etc/openldap/schema2/questionAnswer.schema > include /etc/openldap/schema2/extendedTop.schema > include /etc/openldap/schema2/counter.schema > serverid 1 > TLSCipherSuite HIGH:MEDIUM:+SSLv3 > TLSCACertificateFile /etc/openldap/cacerts/cacert.pem > TLSCertificateFile /etc/openldap/cacerts/mmam01.crt > TLSCertificateKeyFile /etc/openldap/cacerts/mmam01.key > TLSVerifyClient never > pidfile /var/symas/run/slapd.pid > argsfile /var/symas/run/slapd.args > loglevel sync stats > idletimeout 30 > writetimeout 30 > modulepath /etc/openldap/lib64/openldap > moduleload back_mdb.la > moduleload ppolicy.la > moduleload unique.la > moduleload syncprov.la > database mdb > suffix "dc=example,dc=com" > directory /openldap/var/data > access to attrs=userPassword > by self write > by anonymous auth > by * break > > access to * > by > group/groupOfUniqueNames/uniqueMember.exact="cn=PWrite,ou=bGroup,dc=example,dc=com" > manage > by > group/groupOfUniqueNames/uniqueMember.exact="cn=PRead,ou=bGroup,dc=example,dc=com" > read > by * break > access to * > by self write > by anonymous auth > by * read > rootdn "cn=Manager,dc=example,dc=com" > rootpw {SSHA}dXDESQeFjSoa/A1HfJ2TAzYf4DrSYWY > index > mail,uid,postalCode,smail,channelType,channelValue,answer,behavName,objectclass,type > eq > index givenName,sn,city,cn,extName sub > index displayName approx > index entryCSN,entryUUID eq > checkpoint 128 15 > maxsize 274877906944 > syncrepl rid=111 > provider=ldap://sjam01.com > binddn="cn=Manager,dc=example,dc=com" > bindmethod=simple > credentials=0m2013 > tls_cacert=/etc/openldap/cacerts/cacert.pem > searchbase="dc=example,dc=com" > type=refreshAndPersist > retry="5 5 60 +" > network-timeout=10 > timeout=10 > syncrepl rid=222 > provider=ldap://mmam04.com > binddn="cn=Manager,dc=example,dc=com" > bindmethod=simple > credentials=0m2013 > tls_cacert=/etc/openldap/cacerts/cacert.pem > searchbase="dc=example,dc=com" > type=refreshAndPersist > retry="5 5 60 +" > network-timeout=10 > timeout=10 > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > mirrormode true > overlay unique > unique_attributes mail > overlay ppolicy > ppolicy_default "cn=default,ou=pwdPolicy,dc=example,dc=com" > ppolicy_use_lockout > > logs > > DR-sj > > Jan 12 14:51:28 sjprodam01 slapd[25165]: do_syncrep2: rid=111 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > Jan 12 14:51:28 sjprodam01 slapd[25165]: do_syncrep2: rid=111 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > Jan 12 14:51:28 sjprodam01 slapd[25165]: do_syncrep2: rid=111 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > Jan 12 14:51:28 sjprodam01 slapd[25165]: do_syncrep2: rid=111 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > Jan 12 14:51:28 sjprodam01 slapd[25165]: do_syncrep2: rid=111 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > > mmam04 > > Jan 12 14:53:24 mmprodam04 slapd[14108]: do_syncrep2: rid=222 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > Jan 12 14:53:24 mmprodam04 slapd[14108]: do_syncrep2: rid=222 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > Jan 12 14:53:25 mmprodam04 slapd[14108]: do_syncrep2: rid=222 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > Jan 12 14:53:25 mmprodam04 slapd[14108]: do_syncrep2: rid=222 > LDAP_RES_INTERMEDIATE - SYNC_ID_SET > > mmam01 > Users are add on this server > > > Jan 12 14:53:26 mmprodam01 slapd[24380]: slap_queue_csn: queing > 0x7f55dd4fa120 20130112195326.941804Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=291 RESULT tag=105 > err=0 text= > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_graduate_commit_csn: > removing 0x7f55d010ee30 20130112195326.941804Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=292 MOD > dn="extName=PIT,cn=entitlements,cn=extendedProfile,uid=6a9ddf85-1072-48b4-9f09-10f032c8f05e,ou=endUsers,dc=example,dc=com" > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=292 MOD attr=extValue > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_queue_csn: queing > 0x7f55deffc210 20130112195327.100182Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=292 RESULT tag=103 > err=0 text= > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_graduate_commit_csn: > removing 0x7f55d8392770 20130112195327.100182Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=293 MOD > dn="extName=RVW,cn=entitlements,cn=extendedProfile,uid=6a9ddf85-1072-48b4-9f09-10f032c8f05e,ou=endUsers,dc=example,dc=com" > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=293 MOD attr=extValue > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_queue_csn: queing > 0x7f560a22e210 20130112195327.103686Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=293 RESULT tag=103 > err=0 text= > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_graduate_commit_csn: > removing 0x7f55fc6f35e0 20130112195327.103686Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=294 MOD > dn="extName=ICA,cn=entitlements,cn=extendedProfile,uid=6a9ddf85-1072-48b4-9f09-10f032c8f05e,ou=endUsers,dc=example,dc=com" > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=294 MOD attr=extValue > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_queue_csn: queing > 0x7f55f3ffd210 20130112195327.107815Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=294 MOD attr=extValue > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_queue_csn: queing > 0x7f55f3ffd210 20130112195327.107815Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=294 RESULT tag=103 > err=0 text= > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_graduate_commit_csn: > removing 0x7f55e87ae550 20130112195327.107815Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=295 MOD > dn="extName=RVP,cn=entitlements,cn=extendedProfile,uid=6a9ddf85-1072-48b4-9f09-10f032c8f05e,ou=endUsers,dc=example,dc=com" > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=295 MOD attr=extValue > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_queue_csn: queing > 0x7f55f0cf8210 20130112195327.112994Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=295 RESULT tag=103 > err=0 text= > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_graduate_commit_csn: > removing 0x7f55e4618780 20130112195327.112994Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=296 MOD > dn="extName=RAD,cn=entitlements,cn=extendedProfile,uid=6a9ddf85-1072-48b4-9f09-10f032c8f05e,ou=endUsers,dc=example,dc=com" > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=296 MOD attr=extValue > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_queue_csn: queing > 0x7f55dd4f9210 20130112195327.117321Z#000000#001#000000 > Jan 12 14:53:27 mmprodam01 slapd[24380]: conn=8516 op=296 RESULT tag=103 > err=0 text= > Jan 12 14:53:27 mmprodam01 slapd[24380]: slap_graduate_commit_csn: > removing 0x7f55d0001490 20130112195327.117321Z#000000#001#000000 > > > I have tried adding users and changing passwords one by one, it doesn't > work. > I can search old entries from one server to other server. > > -- Thanks&Regards Anil Beniwal +919891695048

3 6

about Too many executing
by rodrigo tavares 22 Jan '13

22 Jan '13

Hello ! I'm see my logs, many messagens come: deferring operation: too many executing. Search in Google, I found informations, about message. First: "too many executing" is undesirable. Second: It means there are too many operations active on the given connection, so mais operations on that connection will be queued until some of the active operations complete. It is cause some problem for the sytem, memory or slapd ? Thanks: Rodrigo

2 1

How to get all attributes of a entry
by ctosgh 22 Jan '13

22 Jan '13

Hi, All I enabled memberOf overlay feature. Now I can get memberOf back with ldapsarch. ldapsearch -x -D "cn=admin,dc=xxx,dc=xxx" -b "dc=xxx,dc=xxx" -w xxx -H "ldap://10.139.36.7:389" "cn=user2" "memberOf" However, with above command other attributes, such as cn and sn, can't be retrieved back... As manual said, memberOf is a opertional attribute so that you should require it explicitly.. Is there a way that I can retrieve all other attributes in addition to memberOf? Thanks, Jacky

2 2

Microsoft Outlook (2011) jpegPhoto and thumbnailPhoto Suffixed With ';binary'
by Eren Türkay 22 Jan '13

22 Jan '13

Hello, I am testing my tree with outlook 2011 (for mac) to see if everything works expected. When I search a contact in address book, photo of the user is not shown. I searched the problem and learned that outlook uses thumbnailPhoto attribute for photos. Then, I created an outlook compatibility schema that includes thumbnailPhoto attribute. However, photos still not shown, at which time I started investigating the problem. I debugged the problem using the network analyzer and realized that Outlook 2011 requests awkward attribute names suffixed with the word ';binary'. When searching, it requests these attributes below along with standard ones: - userSMIMECertificate;binary - userCertificate;binary - thumbnailPhoto;binary - jpegPhoto;binary Since these attributes are not present in my tree (though I have 'normal' ones without a suffix), they are not sent to outlook client so photos are not shown. I, then, tried to change my compatibility schema to use 'thumbnailPhoto;binary', but I got an error stating that the attribute name is not valid. OpenLDAP does not seem to accept ';' character in attribute names. Probably, AD accepts ';' character in attribute names and outlook 2011 works with AD. Apart from not seeing photos, you cannot send encrypted e-mail using outlook because you cannot send a user certificate with openldap (';binary' suffix). So, if you try to use current openldap with outlook, you will miss 2 features, encryption on photos. I'm not sure if ';binary' suffix is done on purpose to make other LDAP servers work with outlook harder. Is there any workaround for it? Being able to include ';' in attribute name will probably fix the problem but I don't know if ';' is acceptable in LDAP standard. Regards, Eren -- . 73! DE TA1AET http://linkedin.com/in/erenturkay

2 1

Re: slapd segfaults with mdb
by Meike Stone 22 Jan '13

22 Jan '13

> File an ITS (http://www.openldap.org/its/) with a full backtrace of all > threads from gdb. => #7496 Thanks

1 0

Continuous mode (ldapmodify -c) not working
by Ori Bani 21 Jan '13

21 Jan '13

Am I doing something wrong? Here is an example: $ ldapmodify -c -x -D 'cn=config' -W Enter LDAP Password: <password> dn: olcDatabase={0}config,cn=config changetype: modify delete: olcSizeLimit - modifying entry "olcDatabase={0}config,cn=config" ldap_modify: No such attribute (16) additional info: modify/delete: olcSizeLimit: no such attribute

2 12

slapd segfaults with mdb
by Meike Stone 21 Jan '13

21 Jan '13

Hello, I play a little with the mdb on a test machine, and imported our db from production system. (about 1,500,000 entires, 2,5GByte ldif from slapcat) I took the slapd source from git today, and because of segmentation fault, I compiled slapd with debugging symbols. My configuration is simple: -------------------------------------------- include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/yast.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/my_ldap_attributes.schema include /etc/openldap/schema/my_ldap_ObjectClasses.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args sizelimit -1 timelimit 300 disallow bind_anon require authc gentlehup on tool-threads 4 serverID 001 ############################ # mdb database definitions ############################ database mdb suffix "ou=root" rootdn "cn=admin,ou=root" rootpw password directory /var/lib/ldap/ldap.mdb loglevel 256 maxsize 10737418240 envflags writemap,nometasync index objectClass,entryUUID,entryCSN eq index cn eq,sub . . . some other own indexes here -------------------------------------------- I started my search via: /tmp/ol/usr/local/bin/ldapsearch -x -h localhost -w password -D cn=admin,ou=root -b'ou=root' '(objectClass=*)' >/dev/null and got in the syslog folloing meassge: Jan 21 17:50:31 debld02 kernel: [348860.053152] slapd[19394]: segfault at 7f760f974ce8 ip 000000000053bea1 sp 00007f738b10a650 error 4 in slapd [400000+227000] Because of this, I configured the kernel to core dump: sysctl -w kernel.core_pattern=/tmp/core sysctl -w kernel.core_uses_pid=1 sysctl -w kernel.suid_dumpable=2 ulimit -c unlimited ulimit -v unlimited and got the result via: ~# gdb /tmp/ol/usr/local/libexec/slapd /tmp/core.19386 Core was generated by `/tmp/buildforopenldaptechnical/usr/local/libexec/slapd -h ldap:/// -f /etc/op'. Program terminated with signal 11, Segmentation fault. #0 0x000000000053bea1 in mdb_entry_decode (op=0xc3a020, data=0x7f738b10a770, e=0x7f738b11a828) at id2entry.c:666 666 a->a_desc = mdb->mi_ads[*lp++]; (gdb) How can I solve this? Btw.: This error is repeatable and I saw the same error with the release OL2.4.33. Thanks Meike

2 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