Re: (ITS#7580) autogroup module blowing slapd when using a labeledURI without attribute specification ?
by breuil＠craig.fr
Re,
and here are more details w/ backtrace after installing slapd-dbg :
517f9323 bdb_modify_internal: 0x000002fd: cn=g1,ou=groups,dc=example,dc=org
Breakpoint 1, modify_add_values (e=e@entry=0x7ffff0f507e0,
mod=mod@entry=0x7ffff87da880, permissive=1,
text=text@entry=0x7ffff0f50c50, textbuf=textbuf@entry=0x7ffff0f50830
"\030", textlen=textlen@entry=256) at ../../../../servers/slapd/mods.c:41
41 in ../../../../servers/slapd/mods.c
(gdb) p *mod
$10 = {sm_desc = 0x7ffff832bb20, sm_values = 0x7ffff8765760, sm_nvalues
= 0x7ffff87da8c0, sm_numvals = 1, sm_op = 0, sm_flags = 1, sm_type =
{bv_len = 6, bv_val = 0x7ffff82ee5c0 "member"}}
(gdb) p *(mod->sm_values)
$11 = {bv_len = 0, bv_val = 0x0}
(gdb) bt
#0 modify_add_values (e=e@entry=0x7ffff0f507e0,
mod=mod@entry=0x7ffff87da880, permissive=1,
text=text@entry=0x7ffff0f50c50, textbuf=textbuf@entry=0x7ffff0f50830
"\030", textlen=textlen@entry=256) at ../../../../servers/slapd/mods.c:41
#1 0x00007ffff32110fb in hdb_modify_internal
(op=op@entry=0x7ffff0f50ca0, tid=0x7ffff82db2d0, modlist=<optimized
out>, e=e@entry=0x7ffff0f507e0, text=text@entry=0x7ffff0f50c50,
textbuf=textbuf@entry=0x7ffff0f50830 "\030", textlen=textlen@entry=256)
at modify.c:137
#2 0x00007ffff3211df3 in hdb_modify (op=0x7ffff0f50ca0,
rs=0x7ffff0f50c30) at modify.c:638
#3 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff0f50ca0,
rs=0x7ffff0f50c30, which=op_modify, oi=0x7ffff8325c90, on=0x0) at
../../../../servers/slapd/backover.c:671
#4 0x00007ffff7f8031b in over_op_func (op=0x7ffff0f50ca0, rs=<optimized
out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723
#5 0x00007ffff2be53e7 in autogroup_add_members_from_filter
(op=op@entry=0x7ffff82da400, e=<optimized out>, age=0x7ffff82f8ef0,
agf=agf@entry=0x7ffff87daea0, modify=modify@entry=1) at autogroup.c:519
#6 0x00007ffff2be5b00 in autogroup_add_group
(op=op@entry=0x7ffff82da400, agi=agi@entry=0x7ffff832b8c0,
agd=agd@entry=0x7ffff832b910, e=0x7ffff8503b98, e@entry=0x0,
ndn=ndn@entry=0x7ffff82da438, scan=scan@entry=1, modify=modify@entry=1)
at autogroup.c:667
#7 0x00007ffff2be6c91 in autogroup_response (op=0x7ffff82da400,
rs=<optimized out>) at autogroup.c:1213
#8 0x00007ffff7f7f598 in over_back_response (op=0x7ffff82da400,
rs=0x7ffff0f52a50) at ../../../../servers/slapd/backover.c:237
#9 0x00007ffff7f227d6 in slap_response_play
(op=op@entry=0x7ffff82da400, rs=rs@entry=0x7ffff0f52a50) at
../../../../servers/slapd/result.c:507
#10 0x00007ffff7f22d6e in send_ldap_response
(op=op@entry=0x7ffff82da400, rs=rs@entry=0x7ffff0f52a50) at
../../../../servers/slapd/result.c:582
#11 0x00007ffff7f23816 in slap_send_ldap_result (op=0x7ffff82da400,
rs=0x7ffff0f52a50) at ../../../../servers/slapd/result.c:860
#12 0x00007ffff3211e67 in hdb_modify (op=0x7ffff82da400,
rs=0x7ffff0f52a50) at modify.c:749
#13 0x00007ffff7f801c6 in overlay_op_walk (op=op@entry=0x7ffff82da400,
rs=0x7ffff0f52a50, which=op_modify, oi=0x7ffff8325c90, on=0x0) at
../../../../servers/slapd/backover.c:671
#14 0x00007ffff7f8031b in over_op_func (op=0x7ffff82da400, rs=<optimized
out>, which=<optimized out>) at ../../../../servers/slapd/backover.c:723
#15 0x00007ffff7f2a569 in fe_op_modify (op=0x7ffff82da400,
rs=0x7ffff0f52a50) at ../../../../servers/slapd/modify.c:303
#16 0x00007ffff7f2c42d in do_modify (op=0x7ffff82da400,
rs=0x7ffff0f52a50) at ../../../../servers/slapd/modify.c:177
#17 0x00007ffff7f12961 in connection_operation
(ctx=ctx@entry=0x7ffff0f52ba0, arg_v=arg_v@entry=0x7ffff82da400) at
../../../../servers/slapd/connection.c:1150
#18 0x00007ffff7f12c84 in connection_read_thread (ctx=0x7ffff0f52ba0,
argv=<optimized out>) at ../../../../servers/slapd/connection.c:1286
So sm_values looks empty at that point...
Note that i've also tried with the default groupOfNames/member objects,
instead of posixGroup/memberOf. Same symptoms.
--
Landry Breuil
10 years, 4 months
(ITS#7580) autogroup module blowing slapd when using a labeledURI without attribute specification ?
by breuil＠craig.fr
Full_Name: Landry Breuil
Version: 2.4.31
OS: Debian sid
URL:
Submission from: (NULL) (194.214.164.50)
using slapd 2.4.31 on debian sid (with cn=config), i have an abort
triggered by the following configuration :
I'm using autogroup module/overlay to automatically generate posixGroup
objects from various filters on my ou=people branch :
dn: cn=SV_REVIEWER,ou=groups,dc=example,dc=org
objectClass: labeledURIObject
objectClass: posixGroup
gidNumber: 10
labeledURI:
ldap:///ou=people,dc=example,dc=org?uid?one?(&(objectClass=inetOrgPerson)(o=myorg))
So far, that works fine. Problem is, with that configuration i'm getting
memberUid values containing only uid attributes. Now that i want to use
memberOf overlay to get the reverse membership, i realize that i need my
posixGroup to have DN-valued memberUid attrs.
I tried using a labeledURI specifying that i want a DN returned :
labeledURI: ldap:///ou=people,dc=example,dc=org?dn?one?(&(objectClass=inetOrgPerson)(o=myorg))
This errors out in autogroup_add_group after parsing the filter with :
517e6bc0 autogroup_add_group: unable to find AttributeDescription "dn".
That, i can understand - a dn is not an attribute per se.
Tried using a labeledURI without attr specification (as, from what i
understand unless mistaken, should return the object, or its dn ?)
labeledURI: ldap:///ou=people,dc=example,dc=org??one?(&(objectClass=inetOrgPerson)(o=myorg))
But this results in the following assertion (w/ debug trace) :
517e70d5 ==> autogroup_add_group <cn=SV_REVIEWER,ou=groups,dc=example,dc=org>
ldap_url_parse_ext(ldap:///ou=people,dc=example,dc=org??one?(&(objectClass=inetOrgPerson)(o=myorg)))
517e70d5 >>> dnPrettyNormal: <ou=people,dc=example,dc=org>
517e70d5 <<< dnPrettyNormal: <ou=people,dc=example,dc=org>,
<ou=people,dc=example,dc=org>
put_filter: "(&(objectClass=inetOrgPerson)(o=myorg))"
put_filter: AND
put_filter_list "(objectClass=inetOrgPerson)(o=myorg)"
put_filter: "(objectClass=inetOrgPerson)"
put_filter: simple
put_simple_filter: "objectClass=inetOrgPerson"
put_filter: "(o=myorg)"
put_filter: simple
put_simple_filter: "o=myorg"
ber_scanf fmt ({mm}) ber:
ber_scanf fmt ({mm}) ber:
517e70d5 ==> autogroup_add_members_from_filter
<cn=SV_REVIEWER,ou=groups,dc=example,dc=org>
517e70d5 => hdb_search
517e70d5 bdb_dn2entry("ou=people,dc=example,dc=org")
517e70d5 search_candidates: base="ou=people,dc=example,dc=org" (0x00000005)
scope=1
517e70d5 => hdb_dn2idl("ou=people,dc=example,dc=org")
517e70d5 => bdb_equality_candidates (objectClass)
517e70d5 => key_read
517e70d5 <= bdb_index_read: failed (-30987)
517e70d5 <= bdb_equality_candidates: id=0, first=0, last=0
517e70d5 => bdb_equality_candidates (objectClass)
517e70d5 => key_read
517e70d5 <= bdb_index_read 738 candidates
517e70d5 <= bdb_equality_candidates: id=738, first=6, last=763
517e70d5 => bdb_equality_candidates (o)
517e70d5 <= bdb_equality_candidates: (o) not indexed
517e70d5 bdb_search_candidates: id=437 first=6 last=763
517e70d5 ==> autogroup_member_search_modify_cb
<uid=user1,ou=people,dc=example,dc=org>
517e70d5 ==> autogroup_member_search_modify_cb
<uid=user2,ou=people,dc=example,dc=org>
517e70d5 hdb_search: 288 does not match filter
....
517e70d5 hdb_search: 762 does not match filter
517e70d5 hdb_search: 763 does not match filter
517e70d5 send_ldap_result: conn=1000 op=8 p=3
517e70d5 bdb_dn2entry("cn=sv_reviewer,ou=groups,dc=example,dc=org")
517e70d5 bdb_entry_get: rc=0
517e70d5 bdb_dn2entry("cn=sv_reviewer,ou=groups,dc=example,dc=org")
517e70d5 bdb_modify_internal: 0x000002e0:
cn=SV_REVIEWER,ou=groups,dc=example,dc=org
slapd: ../../../../servers/slapd/mods.c:64: modify_add_values: Assertion
`mod->sm_numvals == i' failed.
How can i achieve the desired setup ? Fix autogroup to allow asking for
a dn, or try to see why slapd blows in modify_add_values when not asking
for a specific attribute ?
10 years, 4 months
Re: (ITS#7579) back-sql does not update DIT when DB is updated
by masarati＠aero.polimi.it
On 04/29/2013 02:33 PM, mail(a)benjamin-behringer.de wrote:
> Full_Name: Benjamin Behringer
> Version: 2.4.35
> OS: Ubuntu 12.04 64bit
> URL:
> Submission from: (NULL) (2001:7c0:409:8eaa:cb:7a6a:91f0:f867)
>
>
> Hi,
>
> I'm using OpenLDAP and back-sql to make the information, stored in a MySQL
> Database, available over LDAP (for Authentication purposes). Unfortunately, when
> I insert or update an entry in the Database, the DIT is not updated. In
> contrast, a delete on the ldap_entries table will cause slapd to reflect the DB
> change in the DIT. The issue only occurs, when the DIT has already been loaded,
> and the subtree you will make the change to has already been read at least once.
> If you restart slapd, the changes are reflected.
>
> Software Versions:
>
> Distribution: Ubuntu 12.04 64bit
> MySQL: 5.5.31-0ubuntu0.12.04.1
> OpenLDAP: 2.4.35
> libmyodbc: 5.2.4
> unixodbc: 2.3.0-2ubuntu1
>
> Here are
>
> a sample configuration file:
> http://pastebin.de/34104
>
> odbc config files:
> http://pastebin.de/34103
>
> sample db script:
> http://pastebin.de/34101
>
> and insert script:
> http://pastebin.de/34102
>
> Is there a patch, workaround, anything?
There is no caching of the contents of ldap_entries in back-sql; maybe
some caching at the odbc level?
p.
--
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano
10 years, 4 months
(ITS#7579) back-sql does not update DIT when DB is updated
by mail＠benjamin-behringer.de
Full_Name: Benjamin Behringer
Version: 2.4.35
OS: Ubuntu 12.04 64bit
URL:
Submission from: (NULL) (2001:7c0:409:8eaa:cb:7a6a:91f0:f867)
Hi,
I'm using OpenLDAP and back-sql to make the information, stored in a MySQL
Database, available over LDAP (for Authentication purposes). Unfortunately, when
I insert or update an entry in the Database, the DIT is not updated. In
contrast, a delete on the ldap_entries table will cause slapd to reflect the DB
change in the DIT. The issue only occurs, when the DIT has already been loaded,
and the subtree you will make the change to has already been read at least once.
If you restart slapd, the changes are reflected.
Software Versions:
Distribution: Ubuntu 12.04 64bit
MySQL: 5.5.31-0ubuntu0.12.04.1
OpenLDAP: 2.4.35
libmyodbc: 5.2.4
unixodbc: 2.3.0-2ubuntu1
Here are
a sample configuration file:
http://pastebin.de/34104
odbc config files:
http://pastebin.de/34103
sample db script:
http://pastebin.de/34101
and insert script:
http://pastebin.de/34102
Is there a patch, workaround, anything?
Regards
10 years, 4 months
Re: (ITS#7577) hdb and mdb derefere aliases differently
by hyc＠symas.com
juergen.sprenger(a)swisscom.com wrote:
> Full_Name: Juergen Sprenger
> Version: 2.4.35
> OS: Gentoo Base System release 2.1, Kernel 3.7.10
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (193.5.238.18)
>
>
> mdb dereference aliases problem.
A fix for this is now in git master, please test, thanks. commit
fb537d747c6fd43e08986e99b1fe7781660feaf3
>
> I use aliases to keep information about a person who has multiple accounts
> consistent over all accounts and avoid redundancy, example:
>
> dn: uid=joe,ou=Account,dc=its,dc=scom
> objectClass: alias
> objectClass: extensibleObject
> uid: joe
> aliasedObjectName: uid=joe,ou=Person,dc=its,dc=scom
> structuralObjectClass: alias
>
> When using hdb as backend for slapd everything works fine, and user are
> authenticated properly:
> # running 'getent passwd' with hdb backend:
> Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND
> dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128
> Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND
> dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0
> Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 RESULT tag=97 err=0
> text=
> Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH
> base="ou=account,dc=its,dc=scom" scope=1 deref=3
> filter="(objectClass=posixAccount)"
> Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH attr=uid
> userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos
> description objectClass
> Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SEARCH RESULT tag=101
> err=0 nentries=656 text=
> Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 fd=13 closed (connection
> lost)
>
> When using mdb as backend with same directory content, users are no longer
> authenticated, search returns nentries=0:
>
> # running 'getent passwd' with mdb backend:
> Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND
> dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128
> Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND
> dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0
> Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 RESULT tag=97 err=0
> text=
> Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH
> base="ou=account,dc=its,dc=scom" scope=1 deref=3
> filter="(objectClass=posixAccount)"
> Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH attr=uid
> userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos
> description objectClass
> Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SEARCH RESULT tag=101
> err=0 text=
> Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 fd=13 closed (connection
> lost)
>
> Both setups have identical md5sum of slapcat output, so directory content can be
> assumed identical in my opinion.
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 4 months
Re: (ITS#7567) Alias dereferencing slowness
by hyc＠symas.com
luca.scamoni(a)gruppopa.it wrote:
> Full_Name: Luca Scamoni
> Version: 2.4.35
> OS: Linux
> URL: ftp://www.sys-net.it/alias-deref-ITS2.tar.gz
> Submission from: (NULL) (78.134.117.13)
>
>
> Investigating alias dereferencing slowness on a customer production system I
> came upon a suspect behaviour with back-hdb/bdb.
> It seems that slapd, when dereferencing, instead of looking for the exact
> aliased DN, starts scanning more entries than needed (at least this is what I
> can tell looking to the logs set to log anything)
> On the customer system, with over 700,000 entries, the time taken to perform a
> simple search with alias dereferencing for a single entry, takes as much as
> performing a full ldapsearch of the entire ldap tree.
> To reproduce I created a small testcase (that I can't upload because there's no
> space left on ftp.openldap.org/incoming). The test case contains also the log
> and the operations performed on test data to show the issue.
> I tested with openldap 2.4.23, 2.4.31 and 2.4.35. The issue is present in all
> versions but seems to manifest itself only with back-bdb/hdb. Back-mdb seems not
> to show the issue (even looking at the logs) but right now, moving to back-mdb
> is not something the customer is ready to take.
I would not recommend switching to back-mdb at this time, see ITS#7577. Alias
dereferencing is broken in a few cases in back-mdb.
Meanwhile, in back-bdb/hdb, it also depends on whether you're searching with
Deref set to Finding, Searching or Always. Deref/Finding works in all 3
backends (bdb/hdb/mdb). (Deref/Searching in back-mdb was mainly broken by the
patches in ITS#7473.)
When Deref is set to Searching/Always, the backend must find every alias
within the target search scope and dereference them. This deref can
potentially expand the scope of the search, e.g. if the alias points to a
completely different subtree. If you have a lot of aliases in the tree, this
is likely going to be very slow.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
10 years, 4 months
(ITS#7578) delta-sync multimaster replication issue
by afrunning＠gmail.com
Full_Name: Al F
Version: 2.4.35
OS: Redhat 6.4 - x64
URL: https://dl.dropboxusercontent.com/u/982376/its/al-f-130426.zip
Submission from: (NULL) (74.123.146.10)
Hi, I have a multimaster system utilizing delta-sync for replication. The
system is utilizing mdb for both the user and the accesslog data. I have
ppolicy & memberof overlays enabled as well. all of my writes are directed at a
single server using a load balancer. I have found that when a user has a
pwdFailureTime attribute set on their entry, if an administrator resets the
password, "null_callback : error code 0x10" is produced in the log on the
secondary system and the secondary system goes into refresh mode.
The mentioned zip file contains most of my configuration as well a portion of
the log when the issue occurred. The log was generated during a failure with
-d-1 to slapd. I have a lot more log from before and after the issue however it
is littered with sensitive data, so I didn't want to redact it unless
necessary.
Please let me know what else I can do to help.
Regards,
Al
10 years, 5 months
Re: ITS#7552
by Matthew.Monaco＠colorado.edu
This is a multi-part message in MIME format.
--------------010002070300090900000609
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Caching queries with * attributes broken (compiled from 260fd69, RE24 HEAD).
This works:
ldapsearch -x -b ou=users,dc=cs,dc=colorado,dc=edu \
'(&(objectClass=posixAccount)(uid=matt)'
This does not:
ldapsearch -x -b ou=users,dc=cs,dc=colorado,dc=edu \
'(&(objectClass=posixAccount)(uid=matt)' uid
I also have a problem where the attribute set is set to (nssov_passwd_byname):
uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos
description objectClass
For this, nssov does not work (I see cacheable, but the query never gets
cached). However, this does work:
ldapsearch -x -b ou=users,dc=cs,dc=colorado,dc=edu \
'(&(objectClass=posixAccount)(uid=matt)' uid
(Also, test020 passes)
--------------010002070300090900000609
Content-Type: text/plain; charset=UTF-8;
name="slapd-master.conf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="slapd-master.conf"
########
##
## CSEL
##
##
# Modules
#modulepath /usr/lib/ldap
moduleload back_mdb.so
moduleload nssov.so
##
# Schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/ldapns.schema
##
# System
pidfile /run/slapd/slapd.pid
argsfile /run/slapd/slapd.args
loglevel 256
sizelimit 5000
TLSCACertificateFile /etc/openldap/ldap-csel-ca.crt
TLSCertificateFile /etc/openldap/ldap-csel.crt
TLSCertificateKeyFile /etc/openldap/ldap-csel.key
##
# ACLs
access to attrs=userPassword
by set="[cn=administrators,ou=groups,dc=cs,dc=colorado,dc=edu]/memberUid & user/uid" manage
by self =xw
by anonymous auth
by * none
#access to dn.children="ou=users,dc=cs,dc=colorado,dc=edu"
# by set="[cn=administrators,ou=groups,dc=cs,dc=colorado,dc=edu]/memberUid & user/uid" manage
# by self read
# by * none
#access to dn.children="ou=groups,dc=cs,dc=colorado,dc=edu" attrs=memberUid
# by set="[cn=administrators,ou=groups,dc=cs,dc=colorado,dc=edu]/memberUid & user/uid" manage
# by users search
# by * none
access to *
by set="[cn=administrators,ou=groups,dc=cs,dc=colorado,dc=edu]/memberUid & user/uid" manage
by users read
by * read
##
# Backend (mdb)
database mdb
directory /var/lib/openldap/csel.mdb
maxsize 1073741824
suffix dc=cs,dc=colorado,dc=edu
index default eq
index objectClass
index cn
index uid
index uidNumber
index gidNumber
index memberUid
index uniqueMember
index entryCSN
##
# Overlay (nssov)
overlay nssov
nssov-ssd passwd ldap:///ou=users,dc=cs,dc=colorado,dc=edu??one
nssov-ssd shadow ldap:///ou=users,dc=cs,dc=colorado,dc=edu??one
nssov-ssd group ldap:///ou=groups,dc=cs,dc=colorado,dc=edu??one
nssov-ssd hosts ldap:///ou=hosts,dc=cs,dc=colorado,dc=edu??one
--------------010002070300090900000609
Content-Type: text/plain; charset=UTF-8;
name="slapd-client.conf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="slapd-client.conf"
#######
##
## CSEL
##
##
# Modules
moduleload back_ldap.so
moduleload back_mdb.so
moduleload pcache.so
moduleload nssov.so
##
# Schema
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/ldapns.schema
##
# System
pidfile /run/slapd/slapd.pid
argsfile /run/slapd/slapd.args
sizelimit 10000
##
# Backend (ldap)
database ldap
uri ldaps://xxx.colorado.edu/
tls ldaps tls_reqcert=allow
suffix dc=cs,dc=colorado,dc=edu
rootdn cn=pcache,ou=sys,dc=cs,dc=colorado,dc=edu
##
# Overlay (proxy cache)
overlay pcache
pcache mdb 10000 1 256 120
pcacheOffline TRUE
directory /var/lib/openldap/pcache.mdb
maxsize 67108864
index default eq
index objectClass
index cn
index uid
index uidNumber
index gidNumber
index memberUid
index uniqueMember
pcacheAttrset 0 *
pcacheTemplate (&(objectClass=)(uid=)) 0 3600
##
# Overlay (nssov)
overlay nssov
nssov-ssd passwd ldap:///ou=users,dc=cs,dc=colorado,dc=edu??one
nssov-ssd shadow ldap:///ou=users,dc=cs,dc=colorado,dc=edu??one
nssov-ssd group ldap:///ou=groups,dc=cs,dc=colorado,dc=edu??one
nssov-ssd hosts ldap:///ou=hosts,dc=cs,dc=colorado,dc=edu??one
--------------010002070300090900000609--
10 years, 5 months
(ITS#7577) hdb and mdb derefere aliases differently
by juergen.sprenger＠swisscom.com
Full_Name: Juergen Sprenger
Version: 2.4.35
OS: Gentoo Base System release 2.1, Kernel 3.7.10
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (193.5.238.18)
mdb dereference aliases problem.
I use aliases to keep information about a person who has multiple accounts
consistent over all accounts and avoid redundancy, example:
dn: uid=joe,ou=Account,dc=its,dc=scom
objectClass: alias
objectClass: extensibleObject
uid: joe
aliasedObjectName: uid=joe,ou=Person,dc=its,dc=scom
structuralObjectClass: alias
When using hdb as backend for slapd everything works fine, and user are
authenticated properly:
# running 'getent passwd' with hdb backend:
Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND
dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128
Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 BIND
dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0
Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=0 RESULT tag=97 err=0
text=
Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH
base="ou=account,dc=its,dc=scom" scope=1 deref=3
filter="(objectClass=posixAccount)"
Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SRCH attr=uid
userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos
description objectClass
Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 op=1 SEARCH RESULT tag=101
err=0 nentries=656 text=
Apr 24 09:53:54 openldap-dev slapd[19240]: conn=1000 fd=13 closed (connection
lost)
When using mdb as backend with same directory content, users are no longer
authenticated, search returns nentries=0:
# running 'getent passwd' with mdb backend:
Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND
dn="cn=itsAgent,ou=customerAgent,dc=scom" method=128
Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 BIND
dn="cn=itsAgent,ou=customerAgent,dc=scom" mech=SIMPLE ssf=0
Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=0 RESULT tag=97 err=0
text=
Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH
base="ou=account,dc=its,dc=scom" scope=1 deref=3
filter="(objectClass=posixAccount)"
Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SRCH attr=uid
userPassword uidNumber gidNumber cn homeDirectory x-LinuxLoginShell gecos
description objectClass
Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 op=1 SEARCH RESULT tag=101
err=0 text=
Apr 24 10:00:17 openldap-dev slapd[19300]: conn=1002 fd=13 closed (connection
lost)
Both setups have identical md5sum of slapcat output, so directory content can be
assumed identical in my opinion.
10 years, 5 months
Re: (ITS#7575) Fixed send_cli_cred on platforms that do not support such functions
by tedcheng＠symas.com
--Apple-Mail-2--242372278
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
On Apr 14, 2013, at 6:39 AM, Hallvard Breien Furuseth wrote:
>=20
> You can instead look for a mechanism with built-in credential passing,
> apparently like Solaris "doors". =20
The sample client-server programs, see link below, show an experiment on =
Solaris 8 that server creates and listens to door calls, while client =
invokes them. When client invokes a door_call, server gets the euid and =
egid, among others, of the client:
https://dl.dropboxusercontent.com/u/94235048/door_call.tgz
http://docs.oracle.com/cd/E18752_01/html/816-5171/door-call-3door.html
# ./server
successfully created a door
euid (101) egid (1) ruid (101) rgid (1) pid (8947)
$ id
uid=3D101(tedcheng) gid=3D1(other)
$ ./client
pid (8947): door_call succeeded
There is the situation in which we are sending/getting client =
credentials from a door call through say /tmp/door, while service =
requests, such as nssov/nslcd (nss-pam-ldapd), through a separate Unix =
domain socket. There is therefore the need to tie client credentials =
with their respective (name) service requests; "doors" implements its =
own threading support. The work to integrate doors for client credential =
support into a server with threading support, such as slapd, may get =
complicated fast.
"Doors" does not seem to be a feasible solution for sending client =
credentials in a context such as nssov/slapd.
> Or look at what some other well-tested
> and portable package does and suggest we steal its code.=20
>=20
This may be the only option, if there exists one, for older-system =
support (Solaris 8).
Ted C. Cheng
Symas Corporation
--Apple-Mail-2--242372278
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=us-ascii
<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><div>On Apr 14, 2013, at 6:39 AM, Hallvard Breien Furuseth =
wrote:</div><blockquote type=3D"cite"><div><font =
class=3D"Apple-style-span" color=3D"#000000"><br></font>You can instead =
look for a mechanism with built-in credential passing,<br>apparently =
like Solaris "doors". =
</div></blockquote><div><br></div><div><div>The =
sample client-server programs, see link below, show an experiment =
on Solaris 8 that server creates and listens to door calls, while client =
invokes them. When client invokes a door_call, server gets the euid and =
egid, among others, of the client:</div><div><br></div><div><a =
href=3D"https://dl.dropboxusercontent.com/u/94235048/door_call.tgz">https:=
//dl.dropboxusercontent.com/u/94235048/door_call.tgz</a></div><div><br></d=
iv><div><a =
href=3D"http://docs.oracle.com/cd/E18752_01/html/816-5171/door-call-3door.=
html">http://docs.oracle.com/cd/E18752_01/html/816-5171/door-call-3door.ht=
ml</a></div><div><br></div><div># ./server<br>successfully created a =
door<br>euid (101) egid (1) ruid (101) rgid (1) pid (8947)<br><br>$ =
id<br>uid=3D101(tedcheng) gid=3D1(other)<br>$ ./client<br>pid (8947): =
door_call succeeded</div><div><br></div><div>There is the situation =
in which we are sending/getting client credentials from a door call =
through say /tmp/door, while service requests, such as nssov/nslcd =
(nss-pam-ldapd), through a separate Unix domain socket. There is =
therefore the need to tie client credentials with their respective =
(name) service requests; "doors" implements its own threading =
support. The work to integrate doors for client credential support into =
a server with threading support, such as slapd, may get complicated =
fast.</div><div><br></div><div>"Doors" does not seem to be a feasible =
solution for sending client credentials in a context such as =
nssov/slapd.</div></div><br><blockquote type=3D"cite"><div>Or look at =
what some other well-tested<br>and portable package does and suggest we =
steal its code. <font class=3D"Apple-style-span" =
color=3D"#006312"><br></font></div></blockquote><blockquote =
type=3D"cite"><div><br></div></blockquote><br></div><div>This may be the =
only option, if there exists one, for older-system support (Solaris =
8).</div><div><br></div><div><br></div><div><div>Ted C. =
Cheng</div><div>Symas =
Corporation</div></div><div><br></div><div><br></div></body></html>=
--Apple-Mail-2--242372278--
10 years, 5 months