(ITS#6487) Nssov pam_authz authorizedUserService
by crispy＠cluenet.org
Full_Name: Chris Breneman
Version: 2.4.21
OS: Debian Lenny
URL: http://paste.cluenet.org/pastebin.php?dl=2648
Submission from: (NULL) (98.212.227.43)
My organization needs the capability of per-user (instead of per-group) access
control with nssov. Using the method of modifying slapd ACLs to grant or revoke
compare privileges on the authorizedService attribute of the host object is not
scalable with large numbers of users, each of which have individual access.
This patch adds an attribute "authorizedUserService" for use in a host entry.
The attribute is in the form of "UID:SERVICE". If an attribute value for the
user and service exists, access is granted. Otherwise access is denied.
Wildcards in the form of "UID:*", "*:UID", and "*:*" are also supported.
This patch also fixes a minor bug in the pam_authz function. Currently, one of
the values read from NSCLD is used as a string in a Debug statement without
initializing a NULL terminator. The patch extends the lengths of each buffer by
1 and initializes them to 0 so each buffer is always null-terminated and can be
used as a string.
The patch applies to the latest CVS HEAD as of this report, since several
changes have been made in that region of code since 2.4.21.
The patch is at http://paste.cluenet.org/pastebin.php?dl=2648 or
http://paste.cluenet.org/2648
13 years
Re: (ITS#6485) nssov pam_authz fixes
by hyc＠symas.com
crispy(a)cluenet.org wrote:
> Full_Name: Chris Breneman
> Version: 2.4.21
> OS: Debian Lenny
> URL:
> Submission from: (NULL) (98.212.227.43)
>
>
> In pam_authz(), in pam.c, in nssov, there are two problems:
>
> 1. Values in the service buffer are overwritten, and values in several other
> buffers are never stored, preventing authorizedService checking from working.
> 2. pam_authz() fails if nssov is not first used for authentication.
Thanks for reporting these, fixes are in HEAD.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years
Re: (ITS#6433) patch for the sha2 module: hash methods for passwords generation
by hyc＠symas.com
cdelfosse(a)mandriva.com wrote:
> Full_Name: Cédric Delfosse
> Version: HEAD
> OS: Mandriva Linux
> URL: ftp://ftp.openldap.org/incoming/cedric-delfosse-091221.patch
> Submission from: (NULL) (62.212.120.90)
>
>
> Hello,
>
> this patch allows to use the {SHA256}, {SHA384} and {SHA512} password schemes
> (provided by the sha2 module) with LDAP Password Modify Extended Operations.
> This patch contains the required hash methods.
>
> This patch file is derived from OpenLDAP Software. All of the modifications to
> OpenLDAP Software represented in the following patch(es) were developed by
> Mandriva. Mandriva has not assigned rights and/or interest in this work to any
> party. I, Cédric Delfosse am authorized by Mandriva, my employer, to release
> this work under the following terms.
>
> Mandriva hereby place the following modifications to OpenLDAP Software (and only
> these modifications) into the public domain. Hence, these modifications may be
> freely used and/or redistributed for any purpose with or without attribution
> and/or other notice.
>
> Regards,
>
> Cédric
>
Thanks, nice work. Committed in HEAD.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
13 years
(ITS#6486) OpenLDAP Admin Guide Backends Documentation
by ryans＠aweber.com
Full_Name: Ryan Steele
Version: 2.4.18
OS: Ubuntu Server
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (207.106.239.81)
The Admin Guide section on backends is inconsistent in terms of specifying the
moduleload statement, and whether or not it is required for any arbitrary
backend. For example, the documentation on back-ldif explicitly states that it
is not needed:
>You'll notice that when compared to examples below, there is no:
>
> moduleload back_ldif.la
>
>directive. This is because back_ldif is always built in by default as it is
used by
>slapd-config(5), which again is built in by default.
This is in contrast to the monitor backend configuration section where it is
noted as being required:
>You can however set a rootdn and rootpw. The following is all that is needed to
>instantiate a monitor backend:
>
> include ./schema/core.schema
>
> modulepath /usr/local/libexec/openldap
> moduleload back_monitor.la
>
> database monitor
> rootdn "cn=monitoring,cn=Monitor"
> rootpw monitoring
Or, in the back-ldap configuration section, where mention is omitted entirely:
> database ldap
> suffix "dc=suretecsystems,dc=com"
> rootdn "cn=slapd-ldap"
> uri ldap://localhost/ ldap://remotehost ldap://remotehost2
I should note that this ITS is not referring sections in which the configuration
section for a backend is missing entirely (such as back-meta), because IMHO the
lack of information there precludes it from being subject to the aforementioned
ambiguity.
I made sure to check with #openldap on Freenode (2010-03-03, 14:05 EST) before
submitting this ITS, and have made sure to obtain Howard's blessing:
<hyc> go ahead and submit an ITS. I don't think you need to attach a patch.
<hyc> probably we'll just add a bluurb at the top "if your installation uses
dynamic modules, you may need to add the relevant moduleload directives to the
following examples"
<hyc> and leave it at that.
13 years
(ITS#6485) nssov pam_authz fixes
by crispy＠cluenet.org
Full_Name: Chris Breneman
Version: 2.4.21
OS: Debian Lenny
URL:
Submission from: (NULL) (98.212.227.43)
In pam_authz(), in pam.c, in nssov, there are two problems:
1. Values in the service buffer are overwritten, and values in several other
buffers are never stored, preventing authorizedService checking from working.
2. pam_authz() fails if nssov is not first used for authentication.
13 years
(ITS#6484) slapd 2.4.21 + pcache + rwm coredump
by mhardin＠symas.com
Full_Name: Matt Hardin
Version: 2.4.21
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (170.215.92.245)
A naming context that uses back-ldap, slapo-rwm, and slapo-pcache dumps core
when asked to perform an operation.
Configuration snippets:
database ldap
suffix "dc=ad,dc=example,dc=com"
subordinate
rootdn "dc=ad,dc=example,dc=com"
uri "ldaps://ldap01.example.com ldaps://ldap02.example.com"
norefs yes
chase-referrals no
conn-ttl 300
network-timeout 10
use-temporary-conn yes
# Identity assertion: connections authenticated as either of the two identities
# below will connect to AD as the proxy user. Connections authenticated as
# anything else (i.e., AD users) use those credentials for authentication.
idassert-bind bindmethod=simple
binddn="cn=cnsproxy,dc=example,dc=com"
credentials=xxxxxx
mode=legacy
flags=override
idassert-authzFrom "dn.regex:cn=proxy,dc=example,dc=com"
# It is necessary to map a number of objectclass and attribute names to
# various other names that are supported in RFC2307. We also take this
# opportunity to 'lose' certain other attributes that have no place in
# UNIX.
overlay rwm
rwm-normalize-mapped-attrs yes
rwm-suffixmassage "dc=ad,dc=example,dc=com" "dc=example,dc=com"
rwm-map objectClass posixAccount user
rwm-map attribute uid samAccountName
rwm-map attribute "" gecos
[lots of rwm-map statements removed]
# Caching setup
overlay pcache
proxycache hdb 100000 2 10000 50000
proxycachequeries 20000
proxyattrset 0 uid userPassword uidNumber gidNumber cn homeDirectory loginShell
gecos description objectClass memberUid member
proxyattrset 1 *
#
proxytemplate (&(objectClass=)(uid=)) 0 3600 300
proxytemplate (&(objectClass=)(uid=)) 1 3600 300
proxytemplate (&(objectClass=)(uidNumber=)) 0 3600 300
proxytemplate (&(objectClass=)(member=)) 0 3600 300
proxytemplate (&(objectClass=)(|(memberUid=)(member=))) 0 3600 300
proxytemplate (uid=) 0 3600 300
proxytemplate (&(objectClass=)(cn=)) 0 3600 300
proxytemplate (&(objectClass=)(gidNumber=)) 0 3600 300
proxytemplate (objectClass=*) 0 3600 300
#
directory /var/symas/openldap-data/example-pcache
cachesize 10000
idlcachesize 10000
checkpoint 512 600
sizelimit unlimited
index objectClass eq
index cn,sn,uid eq
index uidNumber eq
index gidNumber eq
index memberUid eq
index member eq
index queryid eq
dbconfig set_cachesize 0 536870912 0
dbconfig set_flags DB_LOG_AUTOREMOVE
dbconfig set_lg_max 10485760
dbconfig set_lg_bsize 2097152
Backtrace is as follows:
(gdb) thr apply all bt
Thread 5 (process 19756):
#0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00abc297 in pthread_join () from /lib/tls/libpthread.so.0
#2 0x00608524 in ldap_pvt_thread_join (thread=4294967292,
thread_return=0xfffffffc)
at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/thr_posix.c:197
#3 0x0806f48a in slapd_daemon () at
/home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/daemon.c:2840
#4 0x0805896d in main (argc=7, argv=0xbfe4d694)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/main.c:961
Thread 4 (process 19757):
#0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x0070a1ce in epoll_wait () from /lib/tls/libc.so.6
#2 0x0806e505 in slapd_daemon_task (ptr=0x0)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/daemon.c:2465
#3 0x00abb3cc in start_thread () from /lib/tls/libpthread.so.0
#4 0x00709b4e in clone () from /lib/tls/libc.so.6
Thread 3 (process 19759):
#0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00abdcf6 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/tls/libpthread.so.0
#2 0x00608664 in ldap_pvt_thread_cond_wait (cond=0xfffffffc, mutex=0xfffffffc)
at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/thr_posix.c:277
#3 0x00607822 in ldap_int_thread_pool_wrapper (xpool=0x82c56f0)
at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/tpool.c:672
#4 0x00abb3cc in start_thread () from /lib/tls/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#5 0x00709b4e in clone () from /lib/tls/libc.so.6
Thread 2 (process 19760):
#0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00abdcf6 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/tls/libpthread.so.0
#2 0x00608664 in ldap_pvt_thread_cond_wait (cond=0xfffffffc, mutex=0xfffffffc)
at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/thr_posix.c:277
#3 0x00607822 in ldap_int_thread_pool_wrapper (xpool=0x82c56f0)
at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/tpool.c:672
#4 0x00abb3cc in start_thread () from /lib/tls/libpthread.so.0
#5 0x00709b4e in clone () from /lib/tls/libc.so.6
Thread 1 (process 19758):
#0 0x0083d7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00665825 in raise () from /lib/tls/libc.so.6
#2 0x00667289 in abort () from /lib/tls/libc.so.6
#3 0x0065eda1 in __assert_fail () from /lib/tls/libc.so.6
#4 0x0807bc34 in entry_clean (e=0x835ccdc)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/entry.c:483
#5 0x0807bc52 in entry_free (e=0x835ccdc)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/entry.c:514
#6 0x080da90e in overlay_entry_release_ov (op=0x838b5a0, e=0x835ccdc, rw=0,
on=0x82fcb50)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:439
#7 0x0093aa55 in rwm_send_entry (op=0x838b5a0, rs=0x3a1a100)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/overlays/rwm.c:1508
#8 0x0093b129 in rwm_response (op=0x838b5a0, rs=0x6)
---Type <return> to continue, or q <return> to quit---
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/overlays/rwm.c:1700
#9 0x080da44a in over_back_response (op=0x838b5a0, rs=0x3a1a100)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:237
#10 0x08081be0 in slap_response_play (op=0x838b5a0, rs=0x3a1a100)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/result.c:358
#11 0x0808439b in slap_send_search_entry (op=0x838b5a0, rs=0x3a1a100)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/result.c:843
#12 0x00bd8005 in hdb_search (op=0x838b5a0, rs=0x3a1a100) at search.c:961
#13 0x00a7d495 in pcache_op_search (op=0x838b5a0, rs=0x3a1a100)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/overlays/pcache.c:3029
#14 0x080dad59 in overlay_op_walk (op=0x838b5a0, rs=0x3a1a100, which=op_search,
oi=0x82fca50,
on=0x8303408) at
/home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:659
#15 0x080daebc in over_op_func (op=0x838b5a0, rs=0x3a1a100, which=op_search)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:721
#16 0x080d8f18 in glue_op_search (op=0x838b5a0, rs=0x3a1a100)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backglue.c:457
#17 0x080dad59 in overlay_op_walk (op=0x838b5a0, rs=0x3a1a100, which=op_search,
oi=0x8302778,
on=0x8302878) at
/home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:659
#18 0x080daebc in over_op_func (op=0x838b5a0, rs=0x3a1a100, which=op_search)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/backover.c:721
#19 0x08074b36 in fe_op_search (op=0x838b5a0, rs=0x3a1a100)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/search.c:366
#20 0x08074041 in do_search (op=0x838b5a0, rs=0x3a1a100)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/search.c:217
#21 0x08072205 in connection_operation (ctx=0x3a1a210, arg_v=0x838b5a0)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/connection.c:1109
---Type <return> to continue, or q <return> to quit---
#22 0x08072b54 in connection_read_thread (ctx=0x3a1a210, argv=0x18)
at /home/build/sol-2.4.21.0/sol24x/ldap24/servers/slapd/connection.c:1245
#23 0x006077c6 in ldap_int_thread_pool_wrapper (xpool=0x82c56f0)
at /home/build/sol-2.4.21.0/sol24x/ldap24/libraries/libldap_r/tpool.c:685
#24 0x00abb3cc in start_thread () from /lib/tls/libpthread.so.0
#25 0x00709b4e in clone () from /lib/tls/libc.so.6
(gdb) q
Commentary from debugging session:
the entry in question is owned by pcache's cache DB
and the overlay_entry_release() function
didn't fall into the right release hook
because the pcache overlay didn't provide one
so this has to be fixed by adding a release hook to pcache
not a big deal.
so the fault isn't in rwm this time, it's calling the right API
13 years
Re: (ITS#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by abartlet＠samba.org
--=-wu98lDL/cs9xvAtVkpXf
Content-Type: multipart/mixed; boundary="=-bGZqaJas0lpiam3pf2jA"
--=-bGZqaJas0lpiam3pf2jA
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tue, 2010-03-02 at 15:30 +1100, Andrew Bartlett wrote:
> On Mon, 2009-08-03 at 20:44 +0200, masarati(a)aero.polimi.it wrote:
> > [Resending because I forgot the ITS number in the subject]
> >=20
> > I have a simple prototype that on add/modrdn populates/maintains an
> > attribute (rdnValue) with the distinguished values of the naming
> > attributes of the RDN. While doing this, it also checks for uniqueness=
of
> > the rdnValue value within siblings.
> >=20
> > You can find it here
> > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.=
2.c>
> >=20
> > Please test and comment. I hope it does what intended.
>=20
> I'm starting to look at this now. I'm sorry so many months have past
> since you posted it.
I've now added it into Samba's provision, and using the diff I attach,
against current 'master', I get the attached error.
It seems to be unable to add the base DN. (The very first entry in the
database).
Andrew Bartlett
--=20
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.
--=-bGZqaJas0lpiam3pf2jA
Content-Disposition: attachment; filename="rdnval-use-in-samba.diff"
Content-Transfer-Encoding: base64
Content-Type: text/x-patch; name="rdnval-use-in-samba.diff"; charset="UTF-8"
ZGlmZiAtLWdpdCBhL3NvdXJjZTQvZHNkYi9zYW1kYi9sZGJfbW9kdWxlcy9zYW1iYV9kc2RiLmMg
Yi9zb3VyY2U0L2RzZGIvc2FtZGIvbGRiX21vZHVsZXMvc2FtYmFfZHNkYi5jDQppbmRleCBjOTI5
ZDY1Li5jOGQ1YjkzIDEwMDY0NA0KLS0tIGEvc291cmNlNC9kc2RiL3NhbWRiL2xkYl9tb2R1bGVz
L3NhbWJhX2RzZGIuYw0KKysrIGIvc291cmNlNC9kc2RiL3NhbWRiL2xkYl9tb2R1bGVzL3NhbWJh
X2RzZGIuYw0KQEAgLTE3NSw3ICsxNzUsNiBAQCBzdGF0aWMgaW50IHNhbWJhX2RzZGJfaW5pdChz
dHJ1Y3QgbGRiX21vZHVsZSAqbW9kdWxlKQ0KIAkJCQkJICAgICAiYXNxIiwNCiAJCQkJCSAgICAg
ImV4dGVuZGVkX2RuX3N0b3JlIiwNCiAJCQkJCSAgICAgImV4dGVuZGVkX2RuX2luIiwNCi0JCQkJ
CSAgICAgInJkbl9uYW1lIiwNCiAJCQkJCSAgICAgIm9iamVjdGNsYXNzIiwNCiAJCQkJCSAgICAg
ImRlc2NyaXB0b3IiLA0KIAkJCQkJICAgICAiYWNsIiwNCkBAIC0xOTEsNiArMTkwLDcgQEAgc3Rh
dGljIGludCBzYW1iYV9kc2RiX2luaXQoc3RydWN0IGxkYl9tb2R1bGUgKm1vZHVsZSkNCiAJY29u
c3QgY2hhciAqKmxpbmtfbW9kdWxlczsNCiAJc3RhdGljIGNvbnN0IGNoYXIgKnRkYl9tb2R1bGVz
X2xpc3RbXSA9IHsNCiAJCSJzdWJ0cmVlX2RlbGV0ZSIsDQorCQkicmRuX25hbWUiLA0KIAkJInJl
cGxfbWV0YV9kYXRhIiwNCiAJCSJzdWJ0cmVlX3JlbmFtZSIsDQogCQkibGlua2VkX2F0dHJpYnV0
ZXMiLA0KZGlmZiAtLWdpdCBhL3NvdXJjZTQvZHNkYi9zYW1kYi9sZGJfbW9kdWxlcy9zaW1wbGVf
bGRhcF9tYXAuYyBiL3NvdXJjZTQvZHNkYi9zYW1kYi9sZGJfbW9kdWxlcy9zaW1wbGVfbGRhcF9t
YXAuYw0KaW5kZXggYmY5Y2Q0Zi4uNWVjN2E0YSAxMDA2NDQNCi0tLSBhL3NvdXJjZTQvZHNkYi9z
YW1kYi9sZGJfbW9kdWxlcy9zaW1wbGVfbGRhcF9tYXAuYw0KKysrIGIvc291cmNlNC9kc2RiL3Nh
bWRiL2xkYl9tb2R1bGVzL3NpbXBsZV9sZGFwX21hcC5jDQpAQCAtMjg3LDcgKzI4Nyw3IEBAIHN0
YXRpYyBjb25zdCBzdHJ1Y3QgbGRiX21hcF9hdHRyaWJ1dGUgZW50cnl1dWlkX2F0dHJpYnV0ZXNb
XSA9DQogCQkudHlwZSA9IExEQl9NQVBfUkVOQU1FLA0KIAkJLnUgPSB7DQogCQkJLnJlbmFtZSA9
IHsNCi0JCQkJIC5yZW1vdGVfbmFtZSA9ICJzYW1iYTRSRE4iDQorCQkJCSAucmVtb3RlX25hbWUg
PSAicmRudmFsIg0KIAkJCSB9DQogCQl9DQogCX0sDQpkaWZmIC0tZ2l0IGEvc291cmNlNC9zZXR1
cC9zY2hlbWEtbWFwLW9wZW5sZGFwLTIuMyBiL3NvdXJjZTQvc2V0dXAvc2NoZW1hLW1hcC1vcGVu
bGRhcC0yLjMNCmluZGV4IDBkMzg2NTIuLmFlZDU0MDIgMTAwNjQ0DQotLS0gYS9zb3VyY2U0L3Nl
dHVwL3NjaGVtYS1tYXAtb3BlbmxkYXAtMi4zDQorKysgYi9zb3VyY2U0L3NldHVwL3NjaGVtYS1t
YXAtb3BlbmxkYXAtMi4zDQpAQCAtMTUsNiArMTUsOSBAQCB1aWROdW1iZXINCiBnaWROdW1iZXIN
CiAjVGhlIG1lbWJlck9mIHBsdWdpbiBwcm92aWRlcyB0aGlzIGF0dHJpYnV0ZQ0KIG1lbWJlck9m
DQorIyduYW1lJyBpcyB0aGUgUkROIGluIEFELCBidXQgc29tZXRoaW5nIGVsc2UgaW4gT3BlbkxE
QVAuICBTa2lwIGFuZA0KKyMgdXNlIHRoZSBPcGVuTERBUCBvbmUNCituYW1lDQogI1RoZXNlIGNv
bmZsaWN0IHdpdGggT3BlbkxEQVAgYnVpbHRpbnMNCiBhdHRyaWJ1dGVUeXBlczpzYW1iYTRBdHRy
aWJ1dGVUeXBlcw0KIDIuNS4yMS41OjEuMy42LjEuNC4xLjcxNjUuNC4yNTUuNw0KQEAgLTI0LDgg
KzI3LDYgQEAgb2JqZWN0Q2xhc3NlczpzYW1iYTRPYmplY3RDbGFzc2VzDQogMi41LjIxLjY6MS4z
LjYuMS40LjEuNzE2NS40LjI1NS41DQogc3ViU2NoZW1hOnNhbWJhNFN1YlNjaGVtYQ0KIDIuNS4y
MC4xOjEuMy42LjEuNC4xLjcxNjUuNC4yNTUuNA0KLSMnbmFtZScgaXMgdGhlIFJETiBpbiBBRCwg
YnV0IHNvbWV0aGluZyBlbHNlIGluIE9wZW5MREFQDQotbmFtZTpzYW1iYTRSRE4NCiAjUmVtYXAg
dGhlc2Ugc28gdGhhdCB3ZSBkb24ndCBwdXQgb3BlcmF0aW9uYWwgYXR0cmlidXRlcyBpbiBhIHNj
aGVtYSBNQVkNCiBtb2RpZnlUaW1lU3RhbXA6c2FtYmE0TW9kaWZ5VGltZXN0YW1wDQogMi41LjE4
LjI6MS4zLjYuMS40LjEuNzE2NS40LjI1NS4zDQpkaWZmIC0tZ2l0IGEvc291cmNlNC9zZXR1cC9z
bGFwZC5jb25mIGIvc291cmNlNC9zZXR1cC9zbGFwZC5jb25mDQppbmRleCAwMDc3YTIyLi5lNWZj
ZDA2IDEwMDY0NA0KLS0tIGEvc291cmNlNC9zZXR1cC9zbGFwZC5jb25mDQorKysgYi9zb3VyY2U0
L3NldHVwL3NsYXBkLmNvbmYNCkBAIC00OSw2ICs0OSw3IEBAIGRlZmF1bHRzZWFyY2hiYXNlICR7
RE9NQUlORE59DQogcm9vdGRuIGNuPU1hbmFnZXINCiANCiBvdmVybGF5IGRlcmVmDQorb3Zlcmxh
eSByZG52YWwNCiANCiAke1JFRklOVF9DT05GSUd9DQogDQo=
--=-bGZqaJas0lpiam3pf2jA
Content-Disposition: attachment; filename="rdnval-errors.txt"
Content-Transfer-Encoding: base64
Content-Type: text/plain; name="rdnval-errors.txt"; charset="UTF-8"
PT4gZ2V0X2N0cmxzDQpiZXJfc2NhbmYgZm10ICh7bSkgYmVyOg0KYmVyX2R1bXA6IGJ1Zj0weDE2
MjlmMjAgcHRyPTB4MTYyYTkwMSBlbmQ9MHgxNjJhOTFlIGxlbj0yOQ0KICAwMDAwOiAgMzAgMWIg
MDQgMTkgMzEgMmUgMzMgMmUgIDM2IDJlIDMxIDJlIDM0IDJlIDMxIDJlICAgMC4uLjEuMy42LjEu
NC4xLiAgDQogIDAwMTA6ICAzNCAzMiAzMCAzMyAyZSAzNiAzNiAzNiAgMmUgMzUgMmUgMzEgMzIg
ICAgICAgICAgICA0MjAzLjY2Ni41LjEyICAgICANCj0+IGdldF9jdHJsczogb2lkPSIxLjMuNi4x
LjQuMS40MjAzLjY2Ni41LjEyIiAobm9uY3JpdGljYWwpDQo8PSBnZXRfY3RybHM6IG49MSByYz0w
IGVycj0iIg0KPj4+IGRuUHJldHR5Tm9ybWFsOiA8REM9c2FtYmEsREM9ZXhhbXBsZSxEQz1jb20+
DQo9PiBsZGFwX2J2MmRuKERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tLDApDQo8PSBsZGFwX2J2
MmRuKERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tKT0wIA0KPT4gbGRhcF9kbjJidigyNzIpDQo8
PSBsZGFwX2RuMmJ2KGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tKT0wIA0KPT4gbGRhcF9kbjJi
digyNzIpDQo8PSBsZGFwX2RuMmJ2KGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tKT0wIA0KPDw8
IGRuUHJldHR5Tm9ybWFsOiA8ZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20+LCA8ZGM9c2FtYmEs
ZGM9ZXhhbXBsZSxkYz1jb20+DQpjb25uPTEwMDEgb3A9NSBBREQgZG49ImRjPXNhbWJhLGRjPWV4
YW1wbGUsZGM9Y29tIg0KPj4+IGRuUHJldHR5OiA8Q049RG9tYWluLUROUyxDTj1TY2hlbWEsQ049
Q29uZmlndXJhdGlvbixEQz1zYW1iYSxEQz1leGFtcGxlLERDPWNvbT4NCj0+IGxkYXBfYnYyZG4o
Q049RG9tYWluLUROUyxDTj1TY2hlbWEsQ049Q29uZmlndXJhdGlvbixEQz1zYW1iYSxEQz1leGFt
cGxlLERDPWNvbSwwKQ0KPD0gbGRhcF9idjJkbihDTj1Eb21haW4tRE5TLENOPVNjaGVtYSxDTj1D
b25maWd1cmF0aW9uLERDPXNhbWJhLERDPWV4YW1wbGUsREM9Y29tKT0wIA0KPT4gbGRhcF9kbjJi
digyNzIpDQo8PSBsZGFwX2RuMmJ2KGNuPURvbWFpbi1ETlMsY249U2NoZW1hLGNuPUNvbmZpZ3Vy
YXRpb24sZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20pPTAgDQo8PDwgZG5QcmV0dHk6IDxjbj1E
b21haW4tRE5TLGNuPVNjaGVtYSxjbj1Db25maWd1cmF0aW9uLGRjPXNhbWJhLGRjPWV4YW1wbGUs
ZGM9Y29tPg0KPj4+IGRuTm9ybWFsaXplOiA8Y249RG9tYWluLUROUyxjbj1TY2hlbWEsY249Q29u
ZmlndXJhdGlvbixkYz1zYW1iYSxkYz1leGFtcGxlLGRjPWNvbT4NCj0+IGxkYXBfYnYyZG4oY249
RG9tYWluLUROUyxjbj1TY2hlbWEsY249Q29uZmlndXJhdGlvbixkYz1zYW1iYSxkYz1leGFtcGxl
LGRjPWNvbSwwKQ0KPD0gbGRhcF9idjJkbihjbj1Eb21haW4tRE5TLGNuPVNjaGVtYSxjbj1Db25m
aWd1cmF0aW9uLGRjPXNhbWJhLGRjPWV4YW1wbGUsZGM9Y29tKT0wIA0KPT4gbGRhcF9kbjJidigy
NzIpDQo8PSBsZGFwX2RuMmJ2KGNuPWRvbWFpbi1kbnMsY249c2NoZW1hLGNuPWNvbmZpZ3VyYXRp
b24sZGM9c2FtYmEsZGM9ZXhhbXBsZSxkYz1jb20pPTAgDQo8PDwgZG5Ob3JtYWxpemU6IDxjbj1k
b21haW4tZG5zLGNuPXNjaGVtYSxjbj1jb25maWd1cmF0aW9uLGRjPXNhbWJhLGRjPWV4YW1wbGUs
ZGM9Y29tPg0Kc3RyMmZpbHRlciAiKHJkblZhbHVlPXNhbWJhKSINCnB1dF9maWx0ZXI6ICIocmRu
VmFsdWU9c2FtYmEpIg0KcHV0X2ZpbHRlcjogc2ltcGxlDQpwdXRfc2ltcGxlX2ZpbHRlcjogInJk
blZhbHVlPXNhbWJhIg0KYmVnaW4gZ2V0X2ZpbHRlcg0KRVFVQUxJVFkNCmJlcl9zY2FuZiBmbXQg
KHttbX0pIGJlcjoNCmJlcl9kdW1wOiBidWY9MHg3ZjQ2Y2M4NzgxZjggcHRyPTB4N2Y0NmNjODc4
MWY4IGVuZD0weDdmNDZjYzg3ODIwYiBsZW49MTkNCiAgMDAwMDogIGEzIDExIDA0IDA4IDcyIDY0
IDZlIDU2ICA2MSA2YyA3NSA2NSAwNCAwNSA3MyA2MSAgIC4uLi5yZG5WYWx1ZS4uc2EgIA0KICAw
MDEwOiAgNmQgNjIgNjEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
bWJhICAgICAgICAgICAgICAgDQplbmQgZ2V0X2ZpbHRlciAwDQpzZW5kX2xkYXBfcmVzdWx0OiBj
b25uPTEwMDEgb3A9NSBwPTMNCnNlbmRfbGRhcF9yZXN1bHQ6IGVycj0xMCBtYXRjaGVkPSIiIHRl
eHQ9IiINCnNlbmRfbGRhcF9yZXN1bHQ6IGNvbm49MTAwMSBvcD01IHA9Mw0Kc2VuZF9sZGFwX3Jl
c3VsdDogZXJyPTE5IG1hdGNoZWQ9IiIgdGV4dD0icmRuVmFsdWUgbm90IHVuaXF1ZSB3aXRoaW4g
c2libGluZ3MiDQpzZW5kX2xkYXBfcmVzcG9uc2U6IG1zZ2lkPTYgdGFnPTEwNSBlcnI9MTkNCmJl
cl9mbHVzaDI6IDQ5IGJ5dGVzIHRvIHNkIDIxDQogIDAwMDA6ICAzMCAyZiAwMiAwMSAwNiA2OSAy
YSAwYSAgMDEgMTMgMDQgMDAgMDQgMjMgNzIgNjQgICAwLy4uLmkqLi4uLi4uI3JkICANCiAgMDAx
MDogIDZlIDU2IDYxIDZjIDc1IDY1IDIwIDZlICA2ZiA3NCAyMCA3NSA2ZSA2OSA3MSA3NSAgIG5W
YWx1ZSBub3QgdW5pcXUgIA0KICAwMDIwOiAgNjUgMjAgNzcgNjkgNzQgNjggNjkgNmUgIDIwIDcz
IDY5IDYyIDZjIDY5IDZlIDY3ICAgZSB3aXRoaW4gc2libGluZyAgDQogIDAwMzA6ICA3MyAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzICAgICAgICAgICAg
ICAgICANCmxkYXBfd3JpdGU6IHdhbnQ9NDksIHdyaXR0ZW49NDkNCiAgMDAwMDogIDMwIDJmIDAy
IDAxIDA2IDY5IDJhIDBhICAwMSAxMyAwNCAwMCAwNCAyMyA3MiA2NCAgIDAvLi4uaSouLi4uLi4j
cmQgIA0KICAwMDEwOiAgNmUgNTYgNjEgNmMgNzUgNjUgMjAgNmUgIDZmIDc0IDIwIDc1IDZlIDY5
IDcxIDc1ICAgblZhbHVlIG5vdCB1bmlxdSAgDQogIDAwMjA6ICA2NSAyMCA3NyA2OSA3NCA2OCA2
OSA2ZSAgMjAgNzMgNjkgNjIgNmMgNjkgNmUgNjcgICBlIHdpdGhpbiBzaWJsaW5nICANCiAgMDAz
MDogIDczICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHMg
ICAgICAgICAgICAgICAgIA0KY29ubj0xMDAxIG9wPTUgUkVTVUxUIHRhZz0xMDUgZXJyPTE5IHRl
eHQ9cmRuVmFsdWUgbm90IHVuaXF1ZSB3aXRoaW4gc2libGluZ3MNClRyYWNlYmFjayAobW9zdCBy
ZWNlbnQgY2FsbCBsYXN0KToNCiAgRmlsZSAiLi9zZXR1cC9wcm92aXNpb24iLCBsaW5lIDI0NSwg
aW4gPG1vZHVsZT4NCiAgICBub3N5bmM9b3B0cy5ub3N5bmMsbGRhcF9kcnlydW5fbW9kZT1vcHRz
LmxkYXBfZHJ5cnVuX21vZGUsdXNlZWFkYj1lYWRiKQ0KICBGaWxlICJiaW4vcHl0aG9uL3NhbWJh
L3Byb3Zpc2lvbi5weSIsIGxpbmUgMTMwNSwgaW4gcHJvdmlzaW9uDQogICAgZG9tX2Zvcl9mdW5f
bGV2ZWw9ZG9tX2Zvcl9mdW5fbGV2ZWwpDQogIEZpbGUgImJpbi9weXRob24vc2FtYmEvcHJvdmlz
aW9uLnB5IiwgbGluZSA5MTIsIGluIHNldHVwX3NhbWRiDQogICAgIkRFU0NSSVBUT1IiOiBkZXNj
cg0KICBGaWxlICJiaW4vcHl0aG9uL3NhbWJhL3Byb3Zpc2lvbi5weSIsIGxpbmUgMjM5LCBpbiBz
ZXR1cF9hZGRfbGRpZg0KICAgIGxkYi5hZGRfbGRpZihkYXRhLGNvbnRyb2xzKQ0KICBGaWxlICJi
aW4vcHl0aG9uL3NhbWJhL19faW5pdF9fLnB5IiwgbGluZSAyNTgsIGluIGFkZF9sZGlmDQogICAg
c2VsZi5hZGQobXNnLGNvbnRyb2xzKQ0KX2xkYi5MZGJFcnJvcjogKDE5LCAnTERBUCBlcnJvciAx
OSBMREFQX0NPTlNUUkFJTlRfVklPTEFUSU9OIC0gIDxyZG5WYWx1ZSBub3QgdW5pcXVlIHdpdGhp
biBzaWJsaW5ncz4gPD4nKQ0K
--=-bGZqaJas0lpiam3pf2jA--
--=-wu98lDL/cs9xvAtVkpXf
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iD8DBQBLjLtkz4A8Wyi0NrsRApu+AJ0cW7Vd8zPhS57s8r+iW3D5lFbNHQCgkYCP
vgrrkMMEYjbxPtMqqgUHbrY=
=ZH85
-----END PGP SIGNATURE-----
--=-wu98lDL/cs9xvAtVkpXf--
13 years
Re: (ITS#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by abartlet＠samba.org
--=-3cgveKzr2Byp6ib+VYg9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Mon, 2009-08-03 at 20:44 +0200, masarati(a)aero.polimi.it wrote:
> [Resending because I forgot the ITS number in the subject]
>=20
> I have a simple prototype that on add/modrdn populates/maintains an
> attribute (rdnValue) with the distinguished values of the naming
> attributes of the RDN. While doing this, it also checks for uniqueness o=
f
> the rdnValue value within siblings.
>=20
> You can find it here
> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.=
c>
>=20
> Please test and comment. I hope it does what intended.
I'm starting to look at this now. I'm sorry so many months have past
since you posted it.
Andrew Bartlett
--=20
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.
--=-3cgveKzr2Byp6ib+VYg9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iD8DBQBLjJRvz4A8Wyi0NrsRAqh2AJ4uvpxIGj0PTacpWVLVO18BRrWqaQCeOqhh
VdZtFVltm6uv6qY3Lw7ULpk=
=zoZi
-----END PGP SIGNATURE-----
--=-3cgveKzr2Byp6ib+VYg9--
13 years
Status of ITS 5941?
by Lars Kellogg-Stedman
Hello all,
I think I've just run into ITS 5941
(http://www.openldap.org/its/index.cgi/Software%20Bugs?id=5941). I'm
trying to set up a proxy using the "translucent" overlay in front of
an Active Directory server; I'd like to rewrite some attributes (e.g.,
sAMAccountName -> uid) as part of this process. The config looks like
this:
moduleload translucent
moduleload rwm
database ldif
suffix "dc=dept,dc=example,dc=com"
directory "/var/lib/ldap/ad-proxy"
rootdn "cn=admin,dc=dept,dc=example,dc=com"
rootpw "password"
overlay translucent
uri ldap://127.0.0.1/
acl-bind bindmethod=simple
binddn=cn=binduser,ou=people,cn=admin,dc=dept,dc=example,dc=com
credentials=password
overlay rwm
rwm-map attribute uid sAMAccountName
With this configuration in place, I can complete one search, after
which slapd dies with:
Segmentation fault
If I explicitly request the rewritten attribute:
$ ldapsearch ... cn=lars uid
Slapd dies with a backtrace:
*** glibc detected *** slapd: double free or corruption (!prev):
0xb6602320 ***
======= Backtrace: =========
/lib/libc.so.6(+0x1b7751)[0x858751]
slapd(ber_memfree_x+0x50)[0x610c40]
slapd(slap_sl_free+0x70)[0x527240]
slapd(do_search+0x17f)[0x4c819f]
slapd(+0x3c15e)[0x4c515e]
slapd(+0x15921c)[0x5e221c]
/lib/libpthread.so.0(+0x2f8ab5)[0x334ab5]
/lib/libc.so.6(clone+0x5e)[0x8c4dce]
Does this look like the same problem? Is there a fix available? If
not, is there a workaround that doesn't involve running a second
instance of slapd as a rewriting proxy?
13 years
