Problem with unusual tree structure ...
by Garry Glendown
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
14 years, 4 months
Multi master topology.
by Alejandro Leyva
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.
14 years, 4 months
bindmethod and credentials in slurpd replication.
by Sai
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
14 years, 4 months
ldapmodify is modifying my code
by Darryl Moore
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??????
14 years, 4 months
integrate motd on openldap
by Alejandro Feijoo Fraga
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!
14 years, 4 months
Re: slapd + tls problem
by Alessandro Baggi
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
14 years, 4 months
Query several LDAP servers
by tmp123＠menta.net
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.
14 years, 4 months
Solaris LDAP Mapping
by Matthew.GARRETT＠external.total.com
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.
14 years, 4 months
replicating cn=config
by Matthew Edlefsen
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
14 years, 4 months
LDAP Access controls
by Darryl Moore
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
14 years, 4 months
