openldap-software

openldap-software@openldap.org

2719 discussions

Re: entryDN attribute
by Brandon McCombs 20 Feb '07

20 Feb '07

Kurt Zeilenga wrote: > On Feb 20, 2007, at 3:26 PM, Brandon McCombs wrote: >> I want to use the entryDN attribute as a unique identifier. Is there >> any particular reason why I can't read this attribute using >> openldap.org's server? It won't return in searches I do. > > % ldapsearch -LLL -H ldap://ldap.openldap.org -x -b > 'dc=openldap,dc=org' -s base entryDN > dn: dc=OpenLDAP,dc=Org > entryDN: dc=OpenLDAP,dc=Org > Thanks. I was able to fix my problem.

1 0

RE: entryDN attribute
by Srilakshmanan, Kumuthiny 20 Feb '07

20 Feb '07

1.What is your search criteria? 2.Is there any data in the LDAP that much search criteria? -----Original Message----- From: openldap-software-bounces+kumuthiny.srilakshmanan=auspost.com.au(a)OpenLDAP.or g [mailto:openldap-software-bounces+kumuthiny.srilakshmanan=auspost.com.au@Ope nLDAP.org] On Behalf Of Brandon McCombs Sent: Wednesday, 21 February 2007 10:26 AM To: openldap-software(a)openldap.org Subject: entryDN attribute I want to use the entryDN attribute as a unique identifier. Is there any particular reason why I can't read this attribute using openldap.org's server? It won't return in searches I do. thanks Australia Post is committed to providing our customers with excellent service. If we can assist you in any way please telephone 13 13 18 or visit our website. The information contained in this e-mail communication may be proprietary, confidential or legally professionally privileged. It is intended exclusively for the individual or entity to which it is addressed. You should only read, disclose, re-transmit, copy, distribute, act in reliance on or commercialise the information if you are authorised to do so. Australia Post does not represent, warrant or guarantee the integrity of this e-mail communication has been maintained nor that the communication is free of errors, virus or interference. If you are not the addressee or intended recipient please notify us by replying direct to the sender and then destroy any electronic or paper copy of this message. Any views expressed in this e-mail communication are taken to be those of the individual sender, except where the sender specifically attributes those views to Australia Post and is authorised to do so.

1 0

AW: AW: slapcat hangs without error message
by Voigtlaender＠hansenet.com 20 Feb '07

20 Feb '07

I did recover all my data from a backup. Then I did a slapcat without slapd running twice a day, just for paranoia reasons. It did work on the first day for the first two slapcats, but on the second day slapcat hung again. Is my database corrupt again ? What is happening here ? We did use ldbm before, and had never any problems like this. Should I go back to ldbm instead of bdb ? Marcella -----Ursprüngliche Nachricht----- Von: Adam Pordzik [mailto:ap@d-dt.de] Gesendet: Thursday, February 15, 2007 3:39 AM An: Voigtländer, Marcella HTK Cc: richton(a)nbcs.rutgers.edu; openldap-software(a)openldap.org Betreff: Re: AW: slapcat hangs without error message Voigtlaender(a)hansenet.com wrote: > It seems you are right. I did try db_recover, after that slapcat runs, > but the data is not complete. bdb specific. > Furthermore my slapd doesn't start anymore after the recover. Is there > anything else I could try to get my data ? > Is everything chown'ed properly after dbrecovery? I assume, slapd runs as another user. A --

4 6

Error at make : libdb-4.3.so: could not read symbols: File in wrong format
by Raphael Berlamont 20 Feb '07

20 Feb '07

Hello list, I'm trying to compile openldap v2.3.31 (same happens with v2.3.34), on a FC6 _EMT64_ (I don't have the problem on a i386). At the make step, I have the following error : ------8<------------- /bin/sh ../..//libtool --mode=link cc -static -g -O2 -o slapd main.o globals.o bconfig.o config.o daemon.o connection.o search.o filter.o add.o cr.o attr.o entry.o backend.o backends.o result.o operation.o dn.o compare.o modify.o delete.o modrdn.o ch_malloc.o value.o ava.o bind.o unbind.o abandon.o filterentry.o phonetic.o acl.o str2filter.o aclparse.o init.o user.o repl.o lock.o controls.o extended.o kerberos.o passwd.o schema.o schema_check.o schema_init.o schema_prep.o schemaparse.o ad.o at.o mr.o syntax.o oc.o saslauthz.o oidm.o starttls.o index.o sets.o referral.o root_dse.o sasl.o module.o mra.o mods.o sl_malloc.o zn_malloc.o limits.o operational.o matchedValues.o cancel.o syncrepl.o backglue.o backover.o ctxcsn.o ldapsync.o frontend.o slapadd.o slapcat.o slapcommon.o slapdn.o slapindex.o slappasswd.o slaptest.o slapauth.o slapacl.o component.o aci.o alock.o version.o libbackends.a liboverlays.a ../../libraries/liblunicode/liblunicode.a ../../libraries/librewrite/librewrite.a ../../libraries/liblutil/liblutil.a ../../libraries/libldap_r/libldap_r.la ../../libraries/liblber/liblber.la -ldb-4.3 -lsasl2 -lssl -lcrypto -lresolv -pthread \ cc -g -O2 -o slapd main.o globals.o bconfig.o config.o daemon.o connection.o search.o filter.o add.o cr.o attr.o entry.o backend.o backends.o result.o operation.o dn.o compare.o modify.o delete.o modrdn.o ch_malloc.o value.o ava.o bind.o unbind.o abandon.o filterentry.o phonetic.o acl.o str2filter.o aclparse.o init.o user.o repl.o lock.o controls.o extended.o kerberos.o passwd.o schema.o schema_check.o schema_init.o schema_prep.o schemaparse.o ad.o at.o mr.o syntax.o oc.o saslauthz.o oidm.o starttls.o index.o sets.o referral.o root_dse.o sasl.o module.o mra.o mods.o sl_malloc.o zn_malloc.o limits.o operational.o matchedValues.o cancel.o syncrepl.o backglue.o backover.o ctxcsn.o ldapsync.o frontend.o slapadd.o slapcat.o slapcommon.o slapdn.o slapindex.o slappasswd.o slaptest.o slapauth.o slapacl.o component.o aci.o alock.o version.o -pthread libbackends.a liboverlays.a ../../libraries/liblunicode/liblunicode.a ../../libraries/librewrite/librewrite.a ../../libraries/liblutil/liblutil.a ../../libraries/libldap_r/.libs/libldap_r.a /home/raphux/utils/openldap/openldap-2.3.31/libraries/liblber/.libs/liblber.a ../../libraries/liblber/.libs/liblber.a /usr/lib/libdb-4.3.so -lpthread -lsasl2 -lssl -lcrypto -lresolv -pthread /usr/lib/libdb-4.3.so: could not read symbols: File in wrong format collect2: ld returned 1 exit status make[2]: *** [slapd] Error 1 make[2]: Leaving directory `/home/raphux/utils/openldap/openldap-2.3.31/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/raphux/utils/openldap/openldap-2.3.31/servers' make: *** [all-common] Error 1 [raphux@rt-preprod openldap-2.3.31]$ ------8<------------- I googlised a little, and try to add --includedir=/lib64/ to the configure step, but it doesn't change anything. I did the following thing that made the make working : - removed the /usr/lib/libdb-4.3.so symbolic link to /lib/libdb-4.3.so - recreate a link to /lib64/libdb-4.3.so Now compilation works, but I'm afraid that my system may be unstable, because a lot of installed software uses that library, and may have been compiled with the 32bits version. Is there a way to force the build of openldap to use /lib64/libdb-4.3.so instead of /usr/lib/libdb-4.3.so? For info purpose : -------8<---------- /usr/lib/libdb-4.3.so -> ../../lib/libdb-4.3.so /lib/libdb-4.3.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.20, stripped /lib64/libdb-4.3.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), for GNU/Linux 2.4.20, stripped -------8<---------- Regards, -- Raph.

4 3

SSL/TLS Inquiry
by Steve Finkelstein 19 Feb '07

19 Feb '07

Hi all, Apologies for not grasping some rudimentary TLS/SSL concepts with the LDAP protocol, but I have a basic question. I've configured my OpenLDAP server and have successfully been able to use the posixAccount objectClass to have a user login with pam_ldap over SSH on a client server. However, on the same token, when I try from the client server below to conduct and ldap search, I receive an error: [root@bar cacerts]# ldapsearch -x -h "ldap.domain.com" -p 636 -v ldap_start_tls: Can't contact LDAP server (-1) ldap_bind: Can't contact LDAP server (-1) On the server's log file: Feb 18 23:03:11 firewall slapd[4775]: conn=3 fd=12 ACCEPT from IP=10.0.0.5:1072 (IP=0.0.0.0:636) Feb 18 23:03:11 firewall slapd[4775]: conn=3 fd=12 closed (TLS negotiation failure) Clearly SSL/TLS is not properly negotiating here, but that's something I need to figure out in a few. My real question here is, when I established an ssh connection with my client server and the client server grabbed the credentials from LDAP server, does the above inadvertently imply that the packets were not negotiated via SSL/TLS? I was only testing ldapsearch to ensure that I have anonymous searches disabled, but the concern that I'm working without encryption spiked my curiosity if my logins are going unencrypted also because that's something I'd ultimately need to address. Thanks much for any knowledge anyone can pass along! - Steve

2 2

Another ACL question about set usage
by manu＠netbsd.org 17 Feb '07

17 Feb '07

Hello sets ACL are definitvely hard to work with. But perhaps my schema is just plain wrong. Any hint (how to build the ACL or how to redesign the schema) is welcome. Here is the problem: A) The schema I have three clases:, ou, person, mailAddress 1) persons are children of ou. They have three interesting attribute: ou: the ou they belong to mail: the mail addresses they receive mail from (multivalued) uid: the person's acount login A person's DN is like uid=jdoe,ou=sales,dc=example,dc=net 2) mailAddress holds a bunch of parameters about a mail address. It has a mail attribute. A mailAddress DN is like mail=John.Doe(a)example.net,dc=example,dc=net mailAddress are not children of ou, since several persons of different ou may receive mail through the same address. 3) ou have two interesting attrbiutes: ou: the unit name manager: DN of persons acting as managers (multivalued) An ou DN is like ou=sales,dc=example,dc=net B) The goals 1) a person must be able to modify a mailAddress when it receives mail from this address. This is done by an ACL clause like this (obtained from this mailing list) by set.exact="this/mail & user/mail" write It works very well. That goal is fullfilled. 2) a user listed as a manager for an ou must be able to modify the persons within the ou. I've came to the following: access to dn.regex="uid=.+,ou=(.+),dc=example,dc=net$" by set.expand="[ou=$1,dc=example,dc=net]/manager* & user" write That works, though it seems to be very poor on the performance front. I tried something more simplier, such as: by set.exact="this/ou/manager & user" or that way: by set.exact="(this/ou+[,dc=example,dc=net])/manager & user" but it does not work, I have no idea why. I'm very curious to learn what's wrong here. 3) The trickiest part, for which I have no solution: a user listed as a manager for an ou must be able to modify the mailAddress that a user he can modify could modify. I can try to rephrase this a bit better. If I have the following (mailAddress, person, ou) triplet dn: mail=W,dc=example,dc=net dn: uid=X,ou=Y,dc=example.dc=net mail: W dn: ou=Y,dc=example,dc=net manager: Z I want user Z to be able to modify mailAddress W Here is an attempt that does not work by set.exact=" ([uid=*,ou=] + ([manager=] + user)/ou*) + [,dc=example,dc=net])/mail & this/mail" write I also attempted various tricks with ldap:/// lookups, but no luck. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

3 5

Authenticating via relaying - binding questions
by Douglas B. Jones 17 Feb '07

17 Feb '07

ldap version: openldap-2.3.33 If I have a relay set up from server A to server B via: A: database ldap suffix "" uri ldap://B:389/ lastmod off B: database relay suffix "o=gpc,c=us" relay "dc=new,dc=gpc,dc=edu" message This works fine for searches. When someone binds via uid=user,o=gpc,c=us it fails with 49 - invalid credentials. The bind dn in the B server logs is: uid=user,o=gpc,c=us when I would want it to translate to uid=user,dc=new,dc=gpc,dc=edu. I do not see, so far, in the doc. where this is discussed. My guess is that I am missing something in front of me again, but I am not sure. Thanks for any help.

2 2

objectClass in entry attribute order
by Donn Cave 16 Feb '07

16 Feb '07

I find that if I `replace' the values of objectClass, its order moves to the end of the attribute list -- like, $ ldapsearch ... dn: ... objectClass: top attributeOne: ... $ ldapmodify dn: ... changetype: modify replace: objectClass objectClass: top $ ldapsearch ... dn: ... attributeOne: ... objectClass: top I don't that I have ever seen objectClass appear anywhere but at the top of the entry, before this. Evidently it isn't a serious problem - these entries are still retrievable, modifiable and slapadd works on them. I personally would prefer to avoid it anyway, but I'm not the one who's been doing it. Anyone know of undesirable consequences if objectClass moves to a location other than the first attribute? thanks! Donn Cave, donn(a)u.washington.edu

4 3

ACIs and OL 2.3
by Turbo Fredriksson 16 Feb '07

16 Feb '07

I got my 2.3.32 compiled and working on saturday, and I've been playing with it since. One thing that I stumbled on was the ACI's. I make heavy usage of that (ever since 2.0 - as a third party patch I think - or early 2.1 at least). But my database from 2.2 didn't want to load because of OpenLDAPaci problems... This is what my aci looks like on the root object: ----- s n i p ----- OpenLDAPaci: 0#entry#grant;r,s,c;objectClass,userReference,[entry]#public# OpenLDAPaci: 1#entry#grant;r,s,c;useControls,useEzmlm,useBind9,useWebSrv,autoR eload,allowServerChange,whoAreWe,language,hostMaster,ezmlmBinaryPath,krb5Real mName,krb5AdminServer,krb5PrincipalName,krb5AdminKeytab,krb5AdminCommandPath, controlBaseDn,ezmlmAdministrator,controlsAdministrator,useACI#users# OpenLDAPaci: 2#entry#grant;w,r,s,c,x;[all]#access-id#uid=turbo,ou=People,o=Fre driksson,c=SE ----- s n i p ----- This is aparently not allowed, in many ways! You can't seem to 'stack' the attributes any more. Well, since I don't have 'Net access in my apartment in Lisbon, I had to figure this out by trial and error. I ended up with something like this: ----- s n i p ----- OpenLDAPaci: 0#entry#grant;r,s,c;objectClass#public# OpenLDAPaci: 1#entry#grant;r,s,c;userReference#public# OpenLDAPaci: 2#entry#grant;r,s,c;[entry]#public# OpenLDAPaci: 3#entry#grant;r,s,c;useControls#users# OpenLDAPaci: 4#entry#grant;r,s,c;useEzmlm#users# OpenLDAPaci: 5#entry#grant;r,s,c;useBind9#users# OpenLDAPaci: 6#entry#grant;r,s,c;useWebSrv#users# OpenLDAPaci: 7#entry#grant;r,s,c;autoReload#users# OpenLDAPaci: 8#entry#grant;r,s,c;allowServerChange#users# OpenLDAPaci: 9#entry#grant;r,s,c;whoAreWe#users# OpenLDAPaci: 10#entry#grant;r,s,c;language#users# OpenLDAPaci: 11#entry#grant;r,s,c;hostMaster#users# OpenLDAPaci: 12#entry#grant;r,s,c;ezmlmBinaryPath#users# OpenLDAPaci: 13#entry#grant;r,s,c;krb5RealmName#users# OpenLDAPaci: 14#entry#grant;r,s,c;krb5AdminServer#users# OpenLDAPaci: 15#entry#grant;r,s,c;krb5PrincipalName#users# OpenLDAPaci: 16#entry#grant;r,s,c;krb5AdminKeytab#users# OpenLDAPaci: 17#entry#grant;r,s,c;krb5AdminCommandPath#users# OpenLDAPaci: 18#entry#grant;r,s,c;controlBaseDn#users# OpenLDAPaci: 19#entry#grant;r,s,c;ezmlmAdministrator#users# OpenLDAPaci: 20#entry#grant;r,s,c;controlsAdministrator#users# OpenLDAPaci: 21#entry#grant;r,s,c;useACI#users# OpenLDAPaci: 22#entry#grant;w,r,s,c,x;[all]#access-id#uid=turbo,ou=People,o=Fre driksson,c=SE ----- s n i p ----- which is much uglier... But still, and this is a reall show stopper - have not been able to work around this, this don't seemed to work propperly either! It's the OID 2 that's problem here. The '[entry]' isn't allowed and I can't seem to find it in the code either. The check for it any way - all the code say is: could be "[all]" or an attribute description This means that i can't don't have enough access for _creating_ an object, only to _modify_ an existing one... Creating a simple object like this: ----- s n i p ----- dn: o=phpQLAdmin_Branch_Test,c=se objectclass: top objectclass: organization o: phpQLAdmin_Branch_Test openldapaci: 0#entry#grant;w,r,s,c;[all]#access-id#uid=turbo,ou=people,o=fredriksson,c=se ----- s n i p ----- Fails because of: ----- s n i p ----- adding new entry "o=phpQLAdmin_Branch_Test,c=se" ldap_add: Insufficient access (50) additional info: no write access to entry ----- s n i p ----- Adding the line: ----- s n i p ----- openldapaci: 1#entry#grant;w,r,s,c;[entry]#access-id#uid=turbo,ou=people,o=fredriksson,c=se ----- s n i p ----- Will only give me: ----- s n i p ----- ldap_add: Invalid syntax (21) additional info: openldapaci: value #1 invalid per syntax ----- s n i p ----- So... Is there a document that describes the _changes_ to previous workings of OpenLDAPaci? Or exactly how it's supposed to work now? Also, is my initial findings that there now have to be one attribute per 'line' true? Seems very .. complicated ways of doing it... ?

9 31

Re: ACIs and OL 2.3
by Piotr Wadas 14 Feb '07

14 Feb '07

> I think this is the very important part here -- deprecated and discouraged. > I'd argue that long term, ACI support should be removed entirely (perhaps for > 2.5?). The entire concept of ACI's is broken. > Is it really so bad? I mean, I actually don't now, you're probably right if you say so, anyway I'd really regret such feature to be discontinued. I was testing it very long ago, and, nevertheless its complexity and its experimental flavour, the concept itself was very exciting. I was hoping someday this will be implemented in tested/documented and stable version. Dynamic ACL would be probably really useful thing. Anyway the actual implementation is another point, maybe ACI's is not really best of possible, I don't know. Commercial directory service implementation does have such feature or not? I bet they have. Maybe some concept based on special-kind db like cn=config, or cn=Monitor should do the work better than keeping dynacl with the entries themselves? Actually, regarding - conceptually - unix/posix standard, if we compare ldap entries simply to a "virtual files" (note the "file" original meaning), isn't it somekind of "dynamic acl", the way classic Unix file priviledges are stored? there are some bits describing priviledges and ownerships, which are actually stored _with_ files, aren't they? Imagine that someone could say, that "the entire priviledges and ownerships concept in Unix is broken", wouldn't that sound a little bit em. weird? :) Of course, there are concept limitations we all know, and there are better or worse workarounds for them, actually hundreds of extended acl things for various local and network filesystems, anyway, despite limitations, what could do the work better than such (actually simple in its basics) concept ? Back to the ACIs - is it to be discontinued, because people like me didn't test it enough, and didn't provide enough of feedback? :) This would make me sad :/ Regards, Piotr

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software