openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

RE: OPENLDAP 2.4.32 INSTALLATION TEST ERRORS
by Quanah Gibson-Mount 10 Sep '12

10 Sep '12

--On Friday, September 07, 2012 4:16 PM -0400 "Borresen, John - 0442 - MITLL" <john.borresen(a)ll.mit.edu> wrote: > Thanks, Quanah; > > I just noticed that memberof is set to yes and refint is set to mod. I > could try both as yes, and see if it happens that way, too. That would be worth a test, thanks. Your configure is awfully odd. Why such a mix of modules and built in? I'd just do everything modular myself. --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 2

Failing syncrepl connections because of an older contextCSN on the master
by Ivan Nejgebauer 10 Sep '12

10 Sep '12

OpenLDAP version(s): 2.4.32 and recent git master (54a111907b48900e1ce5de12a9d87818a334423d) OS: CentOS 5, 32-bit In a master/slave delta-syncrepl configuration, syncrepl connections from the fully synchronized and restarted slave to the freshly loaded master will fail because the master uses an earlier contextCSN. This state persists until the first modification on the master, when the contextCSN will become newer than the consumer's, whose next syncrepl retry will then succeed. Details (master and slave configurations are attached to this message): The master is freshly loaded with the following LDIF: dn: dc=example,dc=com objectClass: locality objectClass: dcObject dc: example dn: ou=People,dc=example,dc=com objectClass: organizationalUnit ou: People When the master is started, there is only one entry in cn=accesslog: dn: cn=accesslog objectClass: auditContainer cn: accesslog structuralObjectClass: auditContainer entryDN: cn=accesslog subschemaSubentry: cn=Subschema contextCSN: 20120910091205.088888Z#000000#000#000000 hasSubordinates: FALSE The root entry of the main database looks like this: dn: dc=example,dc=com objectClass: locality objectClass: dcObject dc: example structuralObjectClass: locality entryUUID: 921f3734-24fc-4efa-ac52-10aa4d293332 creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20120910090757Z entryCSN: 20120910090757.483217Z#000000#000#000000 modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20120910090757Z entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema auditContext: cn=accesslog contextCSN: 20120910091205.089003Z#000000#000#000000 hasSubordinates: TRUE When the slave server (with an empty database) is started, it connects to the master and synchronizes. Their synchronization dialog, captured with -d sync, looks like this: (master) 504db377 syncprov_search_response: cookie=rid=000,csn=20120910091205.089003Z#000000#000#000000 504db377 syncprov_search_response: cookie=rid=000,csn=20120910091205.088888Z#000000#000#000000 (slave) 504db370 syncrepl_message_to_entry: rid=000 DN: dc=example,dc=com, UUID: 921f3734-24fc-4efa-ac52-10aa4d293332 504db370 syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 504db370 syncrepl_entry: rid=000 inserted UUID 921f3734-24fc-4efa-ac52-10aa4d293332 504db370 syncrepl_entry: rid=000 be_search (32) 504db370 syncrepl_entry: rid=000 dc=example,dc=com 504db370 syncrepl_entry: rid=000 be_add dc=example,dc=com (0) 504db370 syncrepl_message_to_entry: rid=000 DN: ou=People,dc=example,dc=com, UUID: 08fe53fb-724a-4eca-a57e-3c271d99dd7e 504db370 syncrepl_entry: rid=000 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) 504db370 syncrepl_entry: rid=000 inserted UUID 08fe53fb-724a-4eca-a57e-3c271d99dd7e 504db370 syncrepl_entry: rid=000 be_search (0) 504db370 syncrepl_entry: rid=000 ou=People,dc=example,dc=com 504db370 syncrepl_entry: rid=000 be_add ou=People,dc=example,dc=com (0) 504db370 do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT 504db370 do_syncrep2: rid=000 cookie=rid=000,csn=20120910091205.089003Z#000000#000#000000 504db370 slap_queue_csn: queing 0x836dcf8 20120910091205.089003Z#000000#000#000000 504db370 slap_graduate_commit_csn: removing 0x8371328 20120910091205.089003Z#000000#000#000000 504db370 do_syncrep2: rid=000 LDAP_RES_INTERMEDIATE - REFRESH_DELETE 504db370 do_syncrep2: rid=000 cookie=rid=000,csn=20120910091205.088888Z#000000#000#000000 The master sends the cookie with the contextCSN belonging to cn=accesslog. If the slave is now restarted, what happens is this: 504db38d do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT 504db38d do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform 504db38d do_syncrep2: rid=000 (53) Server is unwilling to perform 504db38d do_syncrepl: rid=000 rc -2 retrying The slave sends csn=20120910091205.089003Z#000000#000#000000, but the master uses csn=20120910091205.088888Z#000000#000#000000. When the master is subsequently modified, it will use a newer contextCSN, and the slave's next retry will succeed. Is this worthy of an ITS, since the situation is unlikely to occur in practice, and will correct itself, only leaving the slave out of sync for the duration of the retry interval? i. include ../servers/slapd/schema/core.schema argsfile master/run/slapd.args pidfile master/run/slapd.pid database mdb suffix cn=accesslog directory master/accesslog index entryCSN,objectClass,reqEnd,reqResult,reqStart eq overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE database mdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret maxsize 256000000 directory master/main index objectClass eq index entryCSN,entryUUID eq overlay syncprov syncprov-checkpoint 1000 60 overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 07+00:00 01+00:00 include ../servers/slapd/schema/core.schema argsfile replica/run/slapd.args pidfile replica/run/slapd.pid database mdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret maxsize 256000000 directory replica/main index objectClass eq index entryUUID eq syncrepl rid=0 provider=ldap://localhost:6389/ bindmethod=simple binddn="cn=Manager,dc=example,dc=com" credentials=secret searchbase="dc=example,dc=com" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="60 +" syncdata=accesslog updateref "ldap://localhost:6389"

1 0

Object class violation/assertion when adding dynamic chaining configuration
by Ivan Nejgebauer 10 Sep '12

10 Sep '12

OpenLDAP version(s): 2.4.32 and recent git master (54a111907b48900e1ce5de12a9d87818a334423d) OS: CentOS 5, 32-bit While preparing the test cases for ITS#7381 (q.v.) I encountered two issues when trying to add an instance of olcLDAPConfig below the chaining overlay entry. If the instance entry looks like this... dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap ...adding the entry (with ldapadd) fails with Error 65 (Object class violation). The server logs the following: 504717ff slapd-chain: subsequent underlying database "olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config" must contain attribute "olcDbURI". 504717ff conn=1000 op=2: config_add_internal: DN="olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config" no structural objectClass add function Note that converting a minimal chaining configuration with slaptest generates an olcLDAPConfig entry without an olcDbURI, and that olcDbURI is not listed as a MUST attribute for olcLDAPConfig. Furthermore, if I try to add an olcLDAPConfig entry with an empty olcDbURI... dn: olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbURI: "" ...it triggers an assertion: slapd: chain.c:224: ldap_chain_uri_cmp: Assertion `li2->li_bvuri != ((void *)0)' failed. Should I file an ITS for those two issues (or maybe two separate ITSs), or is this a "don't do that" scenario? i.

1 0

Roles in OpenLDAP with back-sql
by David Rose 08 Sep '12

08 Sep '12

Hi everyone, Is anybody know if it's possible to define roles in OpenLDAP using back-sql? Here's the thing, we need to prevent some of our users to see "everything". We need to filter results for some groups of users. But we need these rules in the database (Postgres) to be able to change them dynamically. Problem is that, currently, when a user send a search query, OpenLDAP does not include in any way the DN of the user who made the query. As a result we have trouble creating scopes by user/group. Thanks

3 3

OPENLDAP 2.4.32 INSTALLATION TEST ERRORS
by Borresen, John - 0442 - MITLL 07 Sep '12

07 Sep '12

All, Any help would be great in resolving the following. I am installing, as the subject states, OpenLDAP_2.4.32 on a CentOS 5.8 x86_64 bit machine(VM). When running the 'make test', it runs for about 30-minutes (it seems) then it bombs out with the following error: >>>>> Starting test057-memberof-refint for hdb... running defines.sh Starting slapd on TCP/IP port 9011... Running ldapadd to build slapd config database... ldapadd failed (21)! >>>>> test057-memberof-refint failed for hdb (exit 21) make[2]: *** [hdb-mod] Error 21 make[2]: Leaving directory `/root/downloads/openldap-2.4.32/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/root/downloads/openldap-2.4.32/tests' make: *** [test] Error 2 Looking in the testrun directory for any clues, I find: Test.out: # cat test.out ldap_add: Invalid syntax (21) additional info: objectClass: value #1 invalid per syntax adding new entry "olcDatabase={1}hdb,cn=config" adding new entry "olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config" adding new entry "olcOverlay={1}refint,olcDatabase={1}hdb,cn=config" Then, in the slapd.1.log file: 504a441d conn=1001 op=2 do_add ber_scanf fmt ({m) ber: 504a441d conn=1001 op=2 do_add: dn (olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config) ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt (}) ber: 504a441d >>> dnPrettyNormal: <olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config> => ldap_bv2dn(olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config,0) <= ldap_bv2dn(olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config)=0 504a441d <<< dnPrettyNormal: <olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config>, <olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config> 504a441d conn=1001 op=2 ADD dn="olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config" 504a441d oc_check_required entry (olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config), objectClass "olcMemberOf" 504a441d oc_check_allowed type "objectClass" 504a441d oc_check_allowed type "olcOverlay" 504a441d oc_check_allowed type "olcMemberOfRefInt" 504a441d oc_check_allowed type "olcMemberOfGroupOC" 504a441d oc_check_allowed type "olcMemberOfMemberAD" 504a441d oc_check_allowed type "olcMemberOfMemberOfAD" 504a441d oc_check_allowed type "structuralObjectClass" 504a441d slap_queue_csn: queing 0x4362d690 20120907185941.705554Z#000000#000#000000 504a441d ldif_back_add: "olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config" 504a441d oc_check_required entry (olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config), objectClass "olcMemberOf" 504a441d oc_check_allowed type "objectClass" 504a441d oc_check_allowed type "olcOverlay" 504a441d oc_check_allowed type "olcMemberOfRefInt" 504a441d oc_check_allowed type "olcMemberOfGroupOC" 504a441d oc_check_allowed type "olcMemberOfMemberAD" 504a441d oc_check_allowed type "olcMemberOfMemberOfAD" 504a441d oc_check_allowed type "structuralObjectClass" 504a441d oc_check_allowed type "entryUUID" 504a441d oc_check_allowed type "creatorsName" 504a441d oc_check_allowed type "createTimestamp" 504a441d oc_check_allowed type "entryCSN" 504a441d oc_check_allowed type "modifiersName" 504a441d oc_check_allowed type "modifyTimestamp" 504a441d ldif_read_file: entry file exists: "/root/downloads/openldap-2.4.32/tests/testrun/confdir/cn=config/olcDatabase ={1}hdb.ldif" 504a441d ldif_write_entry: wrote entry "olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config" 504a441d ldif_back_add: err: 0 text: 504a441d send_ldap_result: conn=1001 op=2 p=3 504a441d send_ldap_result: err=0 matched="" text="" 504a441d send_ldap_result: conn=1001 op=2 p=3 504a441d send_ldap_result: err=0 matched="" text="" 504a441d send_ldap_response: msgid=3 tag=105 err=0 ber_flush2: 14 bytes to sd 8 504a441d conn=1001 op=2 RESULT tag=105 err=0 text= 504a441d slap_graduate_commit_csn: removing 0x51f0320 20120907185941.705554Z#000000#000#000000 504a441d connection_get(8) 504a441d connection_get(8): got connid=1001 504a441d connection_read(8): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 180 contents: 504a441d op tag 0x68, time 1347044381 ber_get_next 504a441d conn=1001 op=3 do_add ber_scanf fmt ({m) ber: 504a441d conn=1001 op=3 do_add: dn (olcOverlay={1}refint,olcDatabase={1}hdb,cn=config) ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt (}) ber: 504a441d >>> dnPrettyNormal: <olcOverlay={1}refint,olcDatabase={1}hdb,cn=config> => ldap_bv2dn(olcOverlay={1}refint,olcDatabase={1}hdb,cn=config,0) <= ldap_bv2dn(olcOverlay={1}refint,olcDatabase={1}hdb,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcOverlay={1}refint,olcDatabase={1}hdb,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcOverlay={1}refint,olcDatabase={1}hdb,cn=config)=0 504a441d <<< dnPrettyNormal: <olcOverlay={1}refint,olcDatabase={1}hdb,cn=config>, <olcOverlay={1}refint,olcDatabase={1}hdb,cn=config> 504a441d conn=1001 op=3 ADD dn="olcOverlay={1}refint,olcDatabase={1}hdb,cn=config" 504a441d send_ldap_result: conn=1001 op=3 p=3 504a441d send_ldap_result: err=21 matched="" text="objectClass: value #1 invalid per syntax" 504a441d send_ldap_response: msgid=4 tag=105 err=21 ber_flush2: 54 bytes to sd 8 504a441d conn=1001 op=3 RESULT tag=105 err=21 text=objectClass: value #1 invalid per syntax 504a441d connection_get(8) 504a441d connection_get(8): got connid=1001 504a441d connection_read(8): checking for input on id=1001 ber_get_next ber_get_next: tag 0x30 len 5 contents: 504a441d op tag 0x42, time 1347044381 ber_get_next 504a441d ber_get_next on fd 8 failed errno=0 (Success) 504a441d conn=1001 op=4 do_unbind 504a441d conn=1001 op=4 UNBIND 504a441d connection_close: conn=1001 sd=8 504a441d conn=1001 fd=8 closed 504a441d daemon: shutdown requested and initiated. 504a441d slapd shutdown: waiting for 0 operations/tasks to finish 504a441d slapd shutdown: initiated 504a441d ====> bdb_cache_release_all 504a441d slapd destroy: freeing system resources. 504a441d slapd stopped. Dave Borresen Solaris/Linux Systems Administrator Surveillance Systems Group (Group 42) MIT Lincoln Laboratory 244 Wood Street Lexington, MA 02420 P: 781-981-2954 F: 781-981-5344 john.borresen(a)ll.mit.edu

2 2

Re: Roles in OpenLDAP with back-sql
by Dan White 07 Sep '12

07 Sep '12

(CCing the list) On 09/07/12 17:02 +0200, David Rose wrote: >On 09/07/2012 04:17 PM, Dan White wrote: >> On 09/07/12 15:59 +0200, David Rose wrote: >>> Hi everyone, >>> >>> Is anybody know if it's possible to define roles in OpenLDAP using >>> back-sql? >>> >>> Here's the thing, we need to prevent some of our users to see >>> "everything". We need to filter results for some groups of users. But >>> we need these rules in the database (Postgres) to be able to change >>> them dynamically. >> >> Consider using the dynamic slapd-config backend instead. See chapters 5 >> and 8 of the OpenLDAP Administrator's Guide. > >We have a WebApp that stores all its data in Pg and we'd like to access >it using LDAP without having to replicate the database. And AFAIK >slapd-config and back-sql aren't compatible. I don't know. >>> Problem is that, currently, when a user send a search query, OpenLDAP >>> does not include in any way the DN of the user who made the query. >> >> That seems counterintuitive. Are your users binding anonymously? If so, >> don't do that. > >None of our users are bind anonymously. They're logged in, LDAP knows >who's logged in, but doesn't tell Pg when a search query is passed. How do they 'log in'. Do they bind using user credentials directly to the LDAP server, or do they log in to a website? If the latter, then see if your webapp supporting binding *using the user's credentials* when querying the ldap server. Or see if it supports binding with an authz identity matching the user. -- Dan White

2 2

TLS error - TLS accept failure error=1
by cbulist 06 Sep '12

06 Sep '12

Hi, I have problem configuring TLS in my server (2.4.23). I got the error TLS accept failure error=1 when a client tries to log in using ssh. But if I do a ldapsearch from the client machine to the server I don't have problem and I get the answer from the server: ldapsearch -x -H ldaps://serverldap -D "cn=Manager,dc=sample,dc=com" -W -b "dc=sample,dc=com" 'uid=user1' These are my config files: The client ldap.conf: URI ldaps://serverldap BASE dc=sample,dc=com TLS_CACERT /etc/openldap/cacerts/server.pem The server slapd.conf TLSCACertificateFile /etc/openldap/certs/server.pem TLSCertificateFile /etc/openldap/certs/server.pem TLSCertificateKeyFile /etc/openldap/certs/server.pem The /etc/sysconfig/ldap.conf SLAPD_LDAPS=yes Any help? Thanks!

1 0

Editing the olcAccess
by S, Mohan (GE Energy) 06 Sep '12

06 Sep '12

Hi, I've configured olcAccess for my bdb database and I can't able to modify that using ldapmodify. I tried deleting that : ldapmodify -x -h xxx.example.org -D "cn=replicator,ou=admins,dc=example,dc=org" -w secret -f delete.ldif No error cat delete.ldif changetype: modify delete: olcAccess olcAccess: {0} olcAccess: {1} ldapmodify -x -h xxx.example.org -D "cn=replicator,ou=admins,dc=example,dc=org" -w secret -f add.ldif No error cat add.ldif changetype: modify add: olcAccess olcAccess: to attrs=userPassword by self write by anonymous auth by dn.children="ou=admins,dc=example,dc=org" write by * none olcAccess: to * by self write by dn.children="ou=admins,dc=example,dc=org" write by * read olcAccess: to * by self write by dn.children="ou=melbourne,dc=example,dc=org" write by * read my ldapsearch -xLLL -b cn=config -D cn=admin,cn=config -W olcDatabase={1}bdb returns old olcaccess. New access are not getting reflected. Can anyone guide my how to add/edit olcaccess? Can anyone please help me ... Thanks, Mohan

2 1

RE: Editing the olcAccess
by S, Mohan (GE Energy) 06 Sep '12

06 Sep '12

I could able to do this.. I missed the line in my ldif file dn: olcDatabase={2}bdb,cn=config. Apologize Regards, Mohan From: S, Mohan (GE Energy) Sent: Thursday, September 06, 2012 8:26 PM To: openldap-technical(a)openldap.org Subject: Editing the olcAccess Hi, I've configured olcAccess for my bdb database and I can't able to modify that using ldapmodify. I tried deleting that : ldapmodify -x -h xxx.example.org -D "cn=replicator,ou=admins,dc=example,dc=org" -w secret -f delete.ldif No error cat delete.ldif changetype: modify delete: olcAccess olcAccess: {0} olcAccess: {1} ldapmodify -x -h xxx.example.org -D "cn=replicator,ou=admins,dc=example,dc=org" -w secret -f add.ldif No error cat add.ldif changetype: modify add: olcAccess olcAccess: to attrs=userPassword by self write by anonymous auth by dn.children="ou=admins,dc=example,dc=org" write by * none olcAccess: to * by self write by dn.children="ou=admins,dc=example,dc=org" write by * read olcAccess: to * by self write by dn.children="ou=melbourne,dc=example,dc=org" write by * read my ldapsearch -xLLL -b cn=config -D cn=admin,cn=config -W olcDatabase={1}bdb returns old olcaccess. New access are not getting reflected. Can anyone guide my how to add/edit olcaccess? Can anyone please help me ... Thanks, Mohan

1 0

ACL (Regex) help needed
by Denny Schierz 06 Sep '12

06 Sep '12

hi, I have the following structure: cn=foobar,ou=aliases,dc=domain1,ou=mail,ou=services,ou=department,dc=domain,dc=foo cn=foobar1,ou=aliases,dc=domain2,ou=mail,ou=services,ou=department,dc=domain,dc=foo cn=foobar2,ou=aliases,dc=domain2,ou=mail,ou=services,ou=department,dc=domain,dc=foo cn=foobar likes like: dn: foobar,ou=aliases,dc=domain1,ou=mail,ou=services,ou=department,dc=domain,dc=foo objectClass: inetLocalMailRecipient objectClass: person objectClass: top cn: admin sn: admin description: added_by_dekanat mailLocalAddress: sysop(a)department.domain.foo mailRoutingAddress: foobar(a)department.domain.foo At the moment I have one role "mail" that has access to: dn.sub="ou=mail,ou=services,ou=department,dc=domain,dc=foo" read it works as expected, the mailserver can read all entries. Now I want to create a role, who has permissions to delete/add/modify all entries below ou=aliases, from all domains (dc=domain,ou=mail...), but only, if "description: <string>" is found (for delete/modify only, but not for add). Is that possible? Otherwise, how does it look, if I throw the idea with "only if" ? cu denny

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