September 2012 - openldap-technical

by Frank Swasey

I'm experimenting with mdb to replace hdb on my test/development set of servers. I've built 2.4.32 and the server is running RHEL 6.3. This morning, I got a confusing error. Attempting to perform a deletion of a member from a groupOfNames, the following was recorded in syslog: mdb_id2entry_put: mdb_put failed: No space left on device(28) "cn=GroupNameNotImportant,ou=groups,dc=uvm,dc=edu" and ldapmodify returned: modifying entry "cn=GroupNameNotImportant,ou=Groups,dc=uvm,dc=edu" ldap_modify: Other (e.g., implementation specific) error (80) additional info: entry update failed However, free shows memory left, df shows filesystem space left (in fact, it is only 22% used) and data.mdb is -rw------- 1 ldap ldap 1547292672 Sep 8 06:22 data.mdb while the maxsize parameter is set to: maxsize 85899345920 So, I am confused about which device mdb is telling me is out of space. What have I missed? -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

10 years, 9 months

4
5
0 / 0

OpenLdap Proxy with CentOS 6.3

by GERF

Hello all, I have been working with this project for a straight two weeks and i feel lost or stuck. The goal is to query Windows AD from the linux box located in the DMZ So, in my virtual lab I have the following: Windows AD with ip 172.16.5.16 ldap1.gerf02.local CentOS 6.3 with ip 172.16.5.32 upildap01.gerf02.local So, my configuration files are as follows: -*-*-*-*-*-*-*-*-*/etc/openldap/ldap.conf:-*-*-*-*-*-*-*-*-*-* BASE dc=gerf02,dc=local URI ldap://172.16.5.16 ldap://172.16.5.16:636 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never #TLS_CACERTDIR /etc/openldap/certs TLS_CACERTDIR /etc/pki/tls/certs/stratus_cert.pem *-*--**-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* *-*-*-*-*-*-**-*-*-*-/etc/sysconfig/ldap-*-*-*-*-*-*-*-*-*-*-*-*-*-* SLAPD_LDAP=yes SLAPD_LDAPI=yes SLAPD_LDAPS=yes -**-*-**-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-**-*-*-* -*-*-*-*-*-*-*-*-**-*/etc/openldap/slapd.d/cn=config/olcDatabase={2}bdb.ldif-*-*-*-*-*-*-*-*-*-*-*-*** dn: olcDatabase={2}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {2}bdb olcSuffix: dc=gerf02,dc=local olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Ldap Bind Account,dc=gerf02,dc=local olcSyncUseSubentry: FALSE olcMonitoring: TRUE olcDbDirectory: /var/lib/ldap olcDbCacheSize: 1000 olcDbCheckpoint: 1024 15 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass pres,eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: gidNumber pres,eq olcDbIndex: ou pres,eq,sub olcDbIndex: loginShell pres,eq olcDbIndex: mail pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbIndex: memberUid pres,eq,sub olcDbIndex: nisMapName pres,eq,sub olcDbIndex: nisMapEntry pres,eq,sub olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 structuralObjectClass: olcBdbConfig entryUUID: 0a5111d8-8f04-1031-8728-33c9f43311c7 creatorsName: cn=config createTimestamp: 20120909195524Z entryCSN: 20120909195524.946151Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20120909195524Z olcRootPW: {SSHA}2LzGLoDUm/iPav9Ijm/nLfAtxn9WndvP olcTLSCertificateFile: /etc/pki/tls/certs/stratus_cert.pem olcTLSCertificateKeyFile: /etc/pki/tls/certs/stratus_key.pem -**--**-*-*--*-*-*-**-*-*-*-*--*-*-*-**-*-**-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-***-** -**-*-*-*-*-*-*-*-**-/etc/openldap/slapd.d/cn=config/olcDatabase={1}monitor.ldif-*-*-*-*-*-*-*-***-*-* dn: olcDatabase={1}monitor objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=externa l,cn=auth" read by dn.base="cn=Ldap Bind Account,dc=gerf02,dc=local" read by * break olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 0a5108dc-8f04-1031-8727-33c9f43311c7 creatorsName: cn=config createTimestamp: 20120909195524Z entryCSN: 20120909195524.946151Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20120909195524Z -**--**-*-*--*-*-*-**-*-*-*-*--*-*-*-**-*-**-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-***-**-*-*---*-*-** So, when I execute the following, I get this message ldapsearch -x -b dc=gerf02,dc=local -D cn=Ldap Bind Account,dc=gerf02,dc=local -W Enter LDAP Password: ldap_bind: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1 Thanks for your help, G

10 years, 9 months

2
3
0 / 0

Re: Execute a Filter and get the boolean status true/false

by Puneet Khunteta

Hello, Basically i need the count how many SearchResultEntry responses you get from ldap_search_s(). Note : Pardon, i have mistakenly typed "ldap_search()" instead of "ldap_search_s() "true/false for the particular filter" means following : 1.) If execute a filter , respond with >0 entry ---> true 2.) If execute a filter , respond with = 0 entry --> false. Note : i have nothing to do with the attributes for the corresponding entries return for the search. So i am looking for a optimized way here which just let me know if any entry is available or not for particular filter. Regards, PKHUN On Wed, Sep 5, 2012 at 11:17 PM, Pierangelo Masarati < pierangelo.masarati(a)polimi.it> wrote: > > > Hello, > > > > I am facing an issue to get the result of a filter. > > > > Currently i have used the ldap_search () function to see whether AD has > > some entity corresponding to particular filter execution. > > But i am not able to find the function which returns the number of > entity > > for the particular filter execution. > > Please help me to get the correct function which return the number of > > entity for the particular filter execution and what pre-requesties it > has. > > You need to count how many SearchResultEntry responses you get from > ldap_search(). Or, if slapd is configured to use the "noopsrch" module, > which implements the "noopsrch" control > <http://www.openldap.org/faq/data/cache/1509.html>, you get no results but > a control response that indicates, among other things, how many entries > would be returned by that search. I'm not sure what you mean by > "pre-requesties". > > > If possible, please suggest function which just return true/false for the > > particular filter. > > Please specify what "true/false for the particular filter" means. > > p. > > -- > Pierangelo Masarati > Associate Professor > Dipartimento di Ingegneria Aerospaziale > Politecnico di Milano > >

10 years, 9 months

3
9
0 / 0

RE: OPENLDAP 2.4.32 INSTALLATION TEST ERRORS

by Quanah Gibson-Mount

--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

10 years, 9 months

3
2
0 / 0

Failing syncrepl connections because of an older contextCSN on the master

by Ivan Nejgebauer

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"

10 years, 9 months

1
0
0 / 0

Object class violation/assertion when adding dynamic chaining configuration

by Ivan Nejgebauer

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.

10 years, 9 months

1
0
0 / 0

Roles in OpenLDAP with back-sql

by David Rose

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

10 years, 9 months

3
3
0 / 0

OPENLDAP 2.4.32 INSTALLATION TEST ERRORS

by Borresen, John - 0442 - MITLL

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

10 years, 9 months

2
2
0 / 0

Re: Roles in OpenLDAP with back-sql

by Dan White

(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

10 years, 9 months

2
2
0 / 0

TLS error - TLS accept failure error=1

by cbulist

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!

10 years, 9 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical September 2012