openldap-technical July 2009

openldap-technical@openldap.org

68 participants
73 discussions

Problem with unusual tree structure ...
by Garry Glendown 10 Jul '09

10 Jul '09

Hi, I'm trying to authenticate users against an LDAP database ... now, I already have that running on several servers that use the "normal" tree setup, something like "cn=username,ou=somebranch,ou=domain,ou=tld", with a search_base of ou=domain,ou=tld. The place I'm trying to configure it for now is using a - AFAICT - rather unusal schema, as they have a tree that uses multiple top level o=, and start underneath there, so there may by user entries like cn=user1,ou=USERS,o=branch1 and cn=user2,ou=USERS,o=branch2 (historically, ldap trees from several locations were just merged together, which led to this) How can I get SASL to search in such a configuration? I already tried a "ou=USERS,o=*" syntax, which I didn't expect to work (and it didn't) Also, I know that saslauthd or other apps will need to check the resulting username/pw, so I tried binding with the DN and PW of an account, resulting in a "Confidentiality required" ... using ldaps:// notation didn't work, as the remote server (Novell eDirectory) probably isn't configured for that, and -Z for TLS also fails with ldap_start_tls: Server is unavailable (52) additional info: TLS services are not available >From what I can find, the message should come up if the server is configured for requiring secure queries, but then I would expect it to also be configured to SUPPORT either one of the methods ... Help appreciated, -garry

1 0

Multi master topology.
by Alejandro Leyva 10 Jul '09

10 Jul '09

Hi all. We are implementing a solution with multi master LDAP, we have 11 instances at different locations, and maybe we will grow to 21 or 31 instances before the end of the year, expecting to hold something like 200,000 or 300,000 user entries. What topology would be the best? Right now each server synch to all the other servers, is it possible to configure each server to synch only to a central LDAP? is it convenient? Thanks in advance.

1 0

bindmethod and credentials in slurpd replication.
by Sai 10 Jul '09

10 Jul '09

Hi All - Our server team does not want to update our openldap version beyond 2.2 because redhat supports 2.2 as the latest and greatest for RHEL4. So I am trying to configure slurpd replication for them. I got the replication to work. But when defining "replica", I got the following questions. 1) For credentials, can I use hashed password like for rootpw 2) If we could use hashed password, what should the bindmethod be? replica uri=<URL> binddn=<Bind DN> bindmethod=simple --> ??? credentials=XXXXXXXXX Thanks in advance. -Sai

3 5

ldapmodify is modifying my code
by Darryl Moore 10 Jul '09

10 Jul '09

HELP I've been able to replace nis.schema with rfc2307bis.schema so that I can have groups with both member and memberUID attributes. when I try using ldapmodify to add members to the group such as: echo "dn: cn=newgrou1,ou=Groups,dc=moores,dc=ca changetype: modify add: memberUid memberUid: newuser1 replace: member member: uid=newuser1,ou=People,dc=moores,dc=ca" | /usr/bin/ldapmodify -v -y /etc/ldap.secret -D cn=admin,dc=moores,dc=ca -xH ldap://localhost it returns the following error message: ldap_initialize( ldap://localhost:389/??base ) modifying entry "cn=newgrou1,ou=Groups,dc=moores,dc=ca changetype: modify add: memberUid memberUid: newuser1 replace: member member: uid=newuser1,ou=People,dc=moores,dc=ca" ldap_modify: No such object (32) matched DN: ou=People,dc=moores,dc=ca The group and the user both exist. What is most interesting is that ldapmodify appears to modify my request because slapd itself gives this message: hdb_referrals: tag=102 target="cn=newgrou1,ou=Groups,dc=moores,dc=ca changetype: modify add: memberUid memberUid: newuser1 replace: member member: uid\3Dnewuser1,ou=People,dc=moores,dc=ca" matched="ou=People,dc=moores,dc=ca" bdb_dn2entry("cn=newgrou1,ou=groups,dc=moores,dc=ca changetype: modify add: memberuid memberuid: newuser1 replace: member member: uid\3Dnewuser1,ou=people,dc=moores,dc=ca") => hdb_dn2id("dc=ca changetype: modify add: memberuid memberuid: newuser1 replace: member member: uid\3Dnewuser1,ou=people,dc=moores,dc=ca") <= hdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) notice that the "uid=newuser" part of my request has been changed to "uid\3Dnewuser". I've tried a number of different combinations and it appears to me that the first '=' is always replace with \3D and then the silly thing tries to look up that element, and low and behold it does not exist. If I can make this work, then I think I will have group permissions for unix groups working on LDAP. Does anybody have any idea why ldapmodify would be doing this??????

3 6

integrate motd on openldap
by Alejandro Feijoo Fraga 10 Jul '09

10 Jul '09

Hi. i have a large number of users... from diferent language (spanish,english,etc...) all under the same ldap directory and i need change de /etc/motd if user speak spanish or english. I not found info if ldap can do that, i think put a new entry at ldap (like lenguage:es/en/ga/..) and de /etc/bashrc or similar make a if and compare that entry... any diferent idea? or any method more easy? thanks!

2 1

Re: slapd + tls problem
by Alessandro Baggi 10 Jul '09

10 Jul '09

Gavin Henry wrote: > > # openssl req -newkey rsa:1024 -nodes -keyout key.pem -out > >> newreq.pem /*for server/client certificate building and >> sing*/ >> # /usr/lib/ssl/misc/CA.pl -sign >> >> I've tried using only openssl with slapd and all work very good, but not >> with GnuTLS. My system is Debian Lenny. >> >> > > What version of OpenLDAP? > > > Hi there. The problem was solved. It works fine with tls, the problem was that TLS works on port 389 not 636 (ldaps). This is the first time for me to use openldap with gnutls support. With OpenSSL works very good. Then, there was an configuration mismatch. Thanks

1 0

Query several LDAP servers
by tmp123＠menta.net 10 Jul '09

10 Jul '09

Hello, Please, are you so kind of provide me a hint about how to configure or develop the following feature?: A proxy LDAP, like the ones with slapd-ldap, must forward all received queries to a LDAP server1. If this server contains the requested item, the answer is send backward and handling stops. If the server doesn't contains the requested item, the query must be sent to a second LDAP server2. In the worst case, a maximum of 5 different servers should be queried in sequence. Initially, any server can contain any item. Nowadays, there are no tree estructure. Thanks a lot.

1 0

Solaris LDAP Mapping
by Matthew.GARRETT＠external.total.com 09 Jul '09

09 Jul '09

Folks I hope this is the right list for this. I am trying to get our Solaris Machine use LDAP for automounts. Under Solaris the file I would normally change is /var/ldap/ldap_client_file for Solaris using Ldap Version 2.0 But I am not 100% sure what I need to get LDAP automount to work. The OpenLdap Server has the following entries dn: ou=auto.apps,dc=unix,dc=total objectClass: top objectClass: automountMap ou: auto.apps A typical Map entry is dn: cn=acrobat,ou=auto.apps,dc=unix,dc=total objectClass: automount cn: acrobat automountInformation: uk-abz-vgl:/apps/acrobat Can anybody suggest suitable entries for the above ? Thanks Matthew Registered in England and Wales No.811900 Registered Office 33 Cavendish Square, London W1G 0PW This e-mail and any attachments are intended only for the person or entity to whom it is addressed and may contain confidential or privileged information. If you are not the addressee, any disclosure, reproduction, copying, distribution, or use of this communication is strictly prohibited. If you are not the intended recipient or person responsible for delivering this message to the named addressee, please notify us immediately and delete this e-mail. It is the responsibility of the addressee to scan this email and any attachments for computer viruses or other defects. The sender does not accept liability for any loss or damage of any nature, however caused, which may result directly or indirectly from this email or any file attached.

2 1

replicating cn=config
by Matthew Edlefsen 09 Jul '09

09 Jul '09

Hi, I've been trying to use syncrepl to replicate my cn=config tree and have been running into some issues. After running into a number of things not working I completely stripped everything down and attempted to follow test049 by building it from scratch. I've gotten it to work by running two instances of slapd on the same machine, on both machines, but I still can't get it to work between the two machines. System info Provider: FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Sat Nov 15 18:38:32 EST 2008 OpenLDAP 2.4.16 Consumer: FreeBSD 7.2-STABLE FreeBSD 7.2-STABLE #1: Mon Jun 1 12:29:14 EDT 2009 OpenLDAP 2.4.16 My process is this: First I create slapd.d directories for both servers and populate them with a basic config mkdir slapd.d slapadd -n 0 -F slapd.d <<END dn: cn=config objectClass: olcGlobal cn: config olcLogLevel: Trace olcLogLevel: Config olcLogLevel: Stats olcLogLevel: Sync olcLogLevel: Args olcLogLevel: Conns dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcRootDN: $MANAGER olcRootPW: $CONFIGPW olcDatabase: {0}config dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov END chown -R ldap:ldap slapd.d Then I launch slapd with: /usr/local/libexec/slapd -h $URI -u ldap -g ldap on both machines. At this point I can do ldapsearch on both servers and get back the correct results. I then do: ldapmodify -D "$MANAGER" -x -w "$CONFIGPW" <<END dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncRepl: rid=001 provider=$PROVIDER_URI binddn="$MANAGER" bindmethod=simple credentials=$CONFIGPW searchbase="cn=config" type=refreshAndPersist retry="3 5 300 5" timeout=3 - add: olcUpdateRef olcUpdateRef: $PROVIDER_URI END At this point I start logging the same error over and over. Here are the log messages I get: Consumer: Jun 3 19:55:35 jet slapd[51003]: =>do_syncrepl rid=001 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrep2 rid=001 Jun 3 19:55:35 jet slapd[51003]: connection_get(7) Jun 3 19:55:35 jet slapd[51003]: connection_get(7): got connid=0 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrepl rid=001 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrep2 rid=001 Jun 3 19:55:35 jet slapd[51003]: >>> dnPrettyNormal: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPrettyNormal: <cn=config>, <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=subschema> Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 3 19:55:35 jet slapd[51003]: dn_callback : entries have identical CSN cn=config 20090603203325.264042Z#000000#000#000000 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: conn=-1 op=0 p=0 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: err=0 matched="" text="" Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 be_search (0) Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 cn=config Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 entry unchanged, ignored (cn=config) Jun 3 19:55:35 jet slapd[51003]: connection_get(7) Jun 3 19:55:35 jet slapd[51003]: connection_get(7): got connid=0 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrepl rid=001 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrep2 rid=001 Jun 3 19:55:35 jet slapd[51003]: connection_get(7) Jun 3 19:55:35 jet slapd[51003]: connection_get(7): got connid=0 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrepl rid=001 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrep2 rid=001 Jun 3 19:55:35 jet slapd[51003]: connection_get(7) Jun 3 19:55:35 jet slapd[51003]: connection_get(7): got connid=0 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrepl rid=001 Jun 3 19:55:35 jet slapd[51003]: =>do_syncrep2 rid=001 Jun 3 19:55:35 jet slapd[51003]: >>> dnPrettyNormal: <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPrettyNormal: <cn=schema,cn=config>, <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=schema,cn=config> Jun 3 19:55:35 jet slapd[51003]: >>> dnPretty: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: <<< dnPretty: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: >>> dnNormalize: <cn=Subschema> Jun 3 19:55:35 jet slapd[51003]: <<< dnNormalize: <cn=subschema> Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: conn=-1 op=0 p=0 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: err=0 matched="" text="" Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 be_search (0) Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 cn=schema,cn=config Jun 3 19:55:35 jet slapd[51003]: conn=-1 op=0: config_add_internal: DN="cn=schema,cn=config" already exists Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: conn=-1 op=0 p=0 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: err=68 matched="" text="" Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 be_add cn=schema,cn=config (68) Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: conn=-1 op=0 p=0 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: err=0 matched="" text="" Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: conn=-1 op=0 p=0 Jun 3 19:55:35 jet slapd[51003]: send_ldap_result: err=1 matched="" text="" Jun 3 19:55:35 jet slapd[51003]: null_callback : error code 0x1 Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 be_modify cn=schema,cn=config (1) Jun 3 19:55:35 jet slapd[51003]: syncrepl_entry: rid=001 be_modify failed (1) Jun 3 19:55:35 jet slapd[51003]: connection_get(7) Jun 3 19:55:35 jet slapd[51003]: connection_get(7): got connid=0 Jun 3 19:55:35 jet slapd[51003]: do_syncrepl: rid=001 rc 1 retrying (4 retries left) Provider: Jun 3 17:02:36 rock slapd[75268]: slap_listener_activate(6): Jun 3 17:02:36 rock slapd[75268]: >>> slap_listener($PROV_URI) Jun 3 17:02:36 rock slapd[75268]: conn=391 fd=8 ACCEPT from IP=$CONS_IP:56003 (IP=$PROV_IP:389) Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_read(8): checking for input on id=391 Jun 3 17:02:36 rock slapd[75268]: conn=391 op=0 do_bind Jun 3 17:02:36 rock slapd[75268]: >>> dnPrettyNormal: <cn=manager,cn=config> Jun 3 17:02:36 rock slapd[75268]: <<< dnPrettyNormal: <cn=manager,cn=config>, <cn=manager,cn=config> Jun 3 17:02:36 rock slapd[75268]: conn=391 op=0 BIND dn="cn=manager,cn=config" method=128 Jun 3 17:02:36 rock slapd[75268]: do_bind: version=3 dn="cn=manager,cn=config" method=128 Jun 3 17:02:36 rock slapd[75268]: conn=391 op=0 BIND dn="cn=manager,cn=config" mech=SIMPLE ssf=0 Jun 3 17:02:36 rock slapd[75268]: do_bind: v3 bind: "cn=manager,cn=config" to "cn=manager,cn=config" Jun 3 17:02:36 rock slapd[75268]: send_ldap_result: conn=391 op=0 p=3 Jun 3 17:02:36 rock slapd[75268]: send_ldap_response: msgid=1 tag=97 err=0 Jun 3 17:02:36 rock slapd[75268]: conn=391 op=0 RESULT tag=97 err=0 text= Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_read(8): checking for input on id=391 Jun 3 17:02:36 rock slapd[75268]: conn=391 op=1 do_search Jun 3 17:02:36 rock slapd[75268]: >>> dnPrettyNormal: <cn=config> Jun 3 17:02:36 rock slapd[75268]: <<< dnPrettyNormal: <cn=config>, <cn=config> Jun 3 17:02:36 rock slapd[75268]: => get_ctrls Jun 3 17:02:36 rock slapd[75268]: => get_ctrls: oid="1.3.6.1.4.1.4203.1.9.1.1" (noncritical) Jun 3 17:02:36 rock slapd[75268]: => get_ctrls: oid="2.16.840.1.113730.3.4.2" (critical) Jun 3 17:02:36 rock slapd[75268]: <= get_ctrls: n=2 rc=0 err="" Jun 3 17:02:36 rock slapd[75268]: conn=391 op=1 SRCH base="cn=config" scope=2 deref=0 filter="(objectClass=*)" Jun 3 17:02:36 rock slapd[75268]: conn=391 op=1 SRCH attr=* + Jun 3 17:02:36 rock slapd[75268]: send_ldap_result: conn=391 op=1 p=3 Jun 3 17:02:36 rock last message repeated 2 times Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn=config" Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn=schema,cn=config" Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_write(8): waking output for id=391 Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn={0}core,cn=schema,cn=config" Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_write(8): waking output for id=391 Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn={1}cosine,cn=schema,cn=config" Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_write(8): waking output for id=391 Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn={2}inetorgperson,cn=schema,cn=config" Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="cn={3}nis,cn=schema,cn=config" Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="olcDatabase={-1}frontend,cn=config" Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="olcDatabase={0}config,cn=config" Jun 3 17:02:36 rock slapd[75/: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: => send_search_entry: conn 391 dn="olcOverlay={0}syncprov,olcDatabase={0}config,cn=config" Jun 3 17:02:36 rock slapd[75268]: <= send_search_entry: conn 391 exit. Jun 3 17:02:36 rock slapd[75268]: send_ldap_result: conn=391 op=1 p=3 Jun 3 17:02:36 rock slapd[75268]: send_ldap_intermediate: err=0 oid=1.3.6.1.4.1.4203.1.9.1.4 len=56 Jun 3 17:02:36 rock slapd[75268]: send_ldap_response: msgid=2 tag=121 err=0 Jun 3 17:02:36 rock slapd[75268]: connection_get(8): got connid=391 Jun 3 17:02:36 rock slapd[75268]: connection_read(8): checking for input on id=391 Jun 3 17:02:36 rock slapd[75268]: ber_get_next on fd 8 failed errno=0 (Undefined error: 0) Jun 3 17:02:36 rock slapd[75268]: conn=391 op=2 do_unbind Jun 3 17:02:36 rock slapd[75268]: conn=391 op=2 UNBIND Jun 3 17:02:36 rock slapd[75268]: connection_close: conn=391 sd=8 Jun 3 17:02:36 rock slapd[75268]: conn=391 fd=8 closed As I said it works perfectly if it's two slapd instances on the same machine on different ports. The machines can talk to each other and can both ldapsearch the other one. Also the firewall is reporting no blocks. If anybody has seen this before or has some insight into what the problem might be it would be very much apprectiated. Thank you in advance, Matt Edlefsen Earlham College

2 1

LDAP Access controls
by Darryl Moore 09 Jul '09

09 Jul '09

Hi all, I've installed a LDAP server on my network against which all my users can authenticate. They can even change their passwords via GUI or CLI without any issue. What I am trying to do now is allow each one of them to have an address book in their subtree. I created a subtree in each authentication relm that looks like this ou=Contacts,uid=user,ou=People,dc=domain,dc=ca Their is no problem with the rootdn adding entries below this, but I am unable to get the user to be able to. In fact I can't seem to allow the user to write anywhere. Even with the lone access rule: access to * by * write in the /etc/ldap/ldap.conf file (and yes I restart slapd everytime I change this file) I beleive the correct access rule for what I want is: access to dn.children="ou=People,dc=domain,dc=ca" by self write but that doesn't work either and I figured I'd ruduce the number of unknowns by trying to give global write permission first. A commandline test to create an entry yields this result: darryl@bison:~$ ldapadd -w ${NETPASS} -x -D "uid=darryl,ou=People,dc=domain,dc=ca" -f ~/tmp adding new entry "cn=test_test1,ou=Contacts,uid=darryl,ou=People,dc=domain,dc=ca" ldap_add: Insufficient access (50) additional info: no write access to parent ~/tmp looks like this: dn: cn=test_test1,ou=Contacts,uid=darryl,ou=People,dc=domain,dc=ca cn: test_test1 objectClass: inetOrgPerson sn: testestestets It's not an authentication issue because if NETPASS is wrong it returns: ldap_bind: Invalid credentials (49) Anyone have any ideas? There must be somthing simple I am missing, but I'm stumped! cheers, darryl

2 8

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical July 2009