slapadd problem
by tjoen
Openldap 2.4.21, patched with openldap-ntlm.diff from evolution
./configure --prefix=/usr --enable-static
Db 4.7.25
./configure --prefix=/usr --enable-compat185 --disable-static
Problem with smbldap-populate:
# smbldap-populate
Populating LDAP directory for domain WORKGROUP
(S-1-5-21-686817777-1585854605-660948164)
(using builtin directory structure)
adding new entry: dc=example,dc=org
adding new entry: ou=People,dc=example,dc=org
adding new entry: ou=Groups,dc=example,dc=org
entry ou=People,dc=example,dc=org already exist.
adding new entry: ou=Idmap,dc=example,dc=org
^C
(hangs)
test1.ldif:
dn: dc=example,dc=org
objectclass: dcObject
objectclass: organization
dc: example
o: Quenya Org Network
description: The Samba-3 Network LDAP Example
test2.ldif:
dn: sambaDomainName=WORKGROUP,dc=example,dc=org
objectclass: top
objectClass: sambaDomain
objectClass: sambaUnixIdPool
sambaDomainName: WORKGROUP
sambaSID: S-1-5-21-686817777-1585854605-660948164
uidNumber: 1000
gidNumber: 1000
sambaNextRid: 1000
# /etc/rc.d/init.d/ldap stop
/var/openldap-data # rm __db.00* alock *.bdb log.0000000001
# slapadd -v -l test1.ldif
added: "dc=example,dc=org" (00000001)
_#################### 100.00% eta none elapsed none
fast!
Closing DB...
# slapadd -v -l test2.ldif
^C
(hangs)
But:
/var/openldap-data # rm __db.00* alock *.bdb log.0000000001
# slapadd -v -l test2.ldif
added: "sambaDomainName=WORKGROUP,dc=example,dc=org" (00000002)
_#################### 100.00% eta none elapsed none
fast!
Closing DB...Error, entries missing!
entry 1: dc=example,dc=org
# slapadd -v -l test1.ldif
added: "dc=example,dc=org" (00000001)
_#################### 100.00% eta none elapsed none
fast!
Closing DB...
Why first test1 then test2 doesn't work? Deadlock?
slapd.conf:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba.schema
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
loglevel 256
idletimeout 30
access to dn.base=""
by self write
by * auth
access to attrs=userPassword
by self write
by * auth
access to attrs=shadowLastChange
by self write
by * read
access to * by * read
by anonymous auth
backend bdb
database bdb
cachesize 10000
suffix "dc=example,dc=org"
checkpoint 1024 5
rootdn "cn=Manager,dc=example,dc=org"
# /usr/sbin/slappasswd -s secret
rootpw {SSHA}Z6Ton189xuv6t+OeUYxcGoLR+nZnh0Z6
directory /var/openldap-data
# Indices to maintain
index objectClass eq
index cn pres,sub,eq
index sn pres,sub,eq
index uid pres,sub,eq
index displayName pres,sub,eq
index uidNumber eq
index gidNumber eq
index memberUid eq
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index default sub
database monitor
access to *
by dn.exact="cn=Manager,dc=example,dc=org
by * none
13 years, 7 months
(ITS#6481) Asssert with acl-sets and referals
by raphael.ouazana＠linagora.com
Full_Name: Raphael Ouazana
Version: HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (213.41.232.151)
When an URI is deferenced and when the server returns referals, an assertion is
triggered in acl_set_cb_gather :
assert( rs->sr_type == REP_RESULT );
It seems that sets don't handle the case where the search response is a
REP_SEARCHREF.
Regards,
Raphaël Ouazana.
13 years, 7 months
Re: ITS#6475
by manu＠netbsd.org
<masarati(a)aero.polimi.it> wrote:
> It allows to configure what SASL auxprop names need the "dontUseCopy"
> approach. The "cmusaslsecretOTP" is set by default, if known through the
> schema.
Seems nice. I hope I'll have time to test this week.
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu(a)netbsd.org
13 years, 7 months
ITS#6480
by masarati＠aero.polimi.it
Your analysis looks correct, but the solution is not:
- If the server does not recognize the control type, determines that
it is not appropriate for the operation, or is otherwise unwilling
to perform the operation with the control, and if the criticality
field is FALSE, the server MUST ignore the control.
Your fix may result in not ignoring the control. A fix is coming.
Thanks, p.
13 years, 7 months
(ITS#6480) Incorrect handling of noncritical LDAP_CONTROL_X_SEARCH_OPTIONS
by alastair.mccormack＠ioko.com
Full_Name: Alastair McCormack
Version: 2.3.43
OS: Red Hat Enterprise Linux Server release 5.4 (Tikanga)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (83.98.0.249)
Proprietary LDAP Client ---LDAPv3---> OpenLDAP 2.3.43
Query: ??sub(objectClass=*)
Client Receives Error 53: "searchOptions contained unrecognized flag"
This works fine when client is pointed at a Windows AD Domain Controller.
Tracing reveals that client is setting:
Control: oid=1.2.840.113556.1.4.1340 = SERVER_SEARCH_FLAG_PHANTOM_ROOT
noncritical
By my novice understanding of the LDAP v3 RFC, the non-critical flag should mean
that the search should not fail if the Control is not supported. However, it
would seem that in controls.c an unknown or unimplemented flag is causing an
exception even if the Control option is non critical.
I have worked around this by creating and applying the following patch (includes
typo fix):
--- /var/tmp/controls.c-ignore-non-crit-search-flags 2010-02-22
15:16:16.000000000 +0000
+++ openldap-2.3.43/servers/slapd/controls.c 2008-04-09 02:12:47.000000000
+0100
@@ -1425,10 +1425,10 @@ static int parseSearchOptions (
: SLAP_CONTROL_NONCRITICAL;
}
- if ( search_flags & ~(LDAP_SEARCH_FLAG_DOMAIN_SCOPE) ) {
+ if ( (search_flags & ~(LDAP_SEARCH_FLAG_DOMAIN_SCOPE)) &&
ctrl->ldctl_iscritical ) {
/* Other search flags not recognised so far,
* including:
- * LDAP_SEARCH_FLAG_PHANTOM_ROOM
+ * LDAP_SEARCH_FLAG_PHANTOM_ROOT
*/
rs->sr_text = "searchOptions contained unrecognized flag";
return LDAP_UNWILLING_TO_PERFORM;
I have very little C knowledge so this was more of a POC rather than a suggested
solution.
Many thanks for a superb application. Keep up the good work :)
Alastair McCormack
13 years, 7 months
Re: (ITS#6479) olcAccess filter does not work
by hellweiss＠gmx.de
That's it, Thank you.
hellweiss
> You need to add (before "olcAccess: {3}") something that allows search
> access to any valid search base. OpenLDAP 2.4 requires search access to
> the entry pseudo-attribute of the search base.
>
> Something like
>
> olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=entry by * read
>
> p.
>
--
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser
13 years, 7 months
ITS#6475
by masarati＠aero.polimi.it
The "easy" fix is here
<ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-02-21-dontusecop...>
I haven't committed it (needs some polishing) because it touches
slapo-chain(5) in a couple of places, and I'd rather be sure it does not
break anything. I won't be able to work at it for a while. It needs some
polishing (SASL attributes that may need dontUseCopy should be at least
configurable and so).
Please test.
13 years, 7 months
Re: (ITS#6479) olcAccess filter does not work
by masarati＠aero.polimi.it
You need to add (before "olcAccess: {3}") something that allows search
access to any valid search base. OpenLDAP 2.4 requires search access to
the entry pseudo-attribute of the search base.
Something like
olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=entry by * read
p.
13 years, 7 months
Re: (ITS#6479) olcAccess filter does not work
by hellweiss＠gmx.de
> >
> > olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=*)
> > attrs=cn,email,entry,objectClass,uid by * read
> >
> > works ok, changing the olcAccess filter to e.g. person
> >
> > olcAccess {3}to dn.subtree="dc=site" filter=(objectclass=person)
> > attrs=cn,email,entry,objectClass,uid by * read
> >
> > gives no results
>
> Given that this is specifically tested by test006, and this test routinely
> passes, and considering how incomplete your report is, I recommend you
> provide a means to easily reproduce the issue (e.g. detailed slapd.conf,
> LDIF data and details about the unsuccessful operation) in order to have
> this issue report processed further.
>
> p.
Hello p.,
so, if I got you right, this 'test006' states, that this must be a
configuration error and I better move on to the support Mailinglist
or somewhere else.
If this should not be the case, here's what i've got:
There's no slapd.conf, it's empty
# {1}hdb, config
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=site
olcRootDN: cn=admin,dc=site
olcRootPW: xxxxxxxxxxxxxxxx
olcDbCacheSize: 10000
olcDbCheckpoint: 1024 5
olcDbIDLcacheSize: 30000
olcDbIndex: objectclass eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: member eq
olcDbIndex: memberUid eq
olcDbIndex: mail eq
olcDbIndex: cn eq,sub
olcDbIndex: displayName eq,sub
olcDbIndex: uid eq,sub
olcDbIndex: sn eq,sub
olcDbIndex: givenName eq,sub
olcAccess: {0}to attrs=userPassword by self write by * auth
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to attrs=userPKCS12 by self read by * none
olcAccess: {3}to dn.subtree="dc=site" filter=(objectclass=inetOrgPerson) attrs
=cn,email,entry,objectClass,uid by * read
olcAccess: {4}to * by * none
I've only access to the test system now, so the dc and objectclass is different.
Here is the only user:
# test, people, site
dn: uid=test,ou=people,dc=site
cn: test test
gidNumber: 100
givenName: test
homeDirectory: /home/test
loginShell: /bin/bash
objectClass: top
objectClass: posixAccount
objectClass: inetOrgPerson
sn: test
uid: test
uidNumber: 1001
If I do an ldapsearch -x -b ou=people,dc=site or as test User
there are no results.
What I want to achieve is Anonymous and User read access only to
inetOrgPerson Entries and special attributes, nothing else. No groupOfNames or device Entries in the subtree.
Regards
Hellweiss
--
NEU: Mit GMX DSL über 1000,- ¿ sparen!
http://portal.gmx.net/de/go/dsl02
13 years, 7 months
