(ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by Philippe.eychart＠informatique.gov.pf
Full_Name: Philippe EYCHART
Version: 2.4.13
OS: slack12
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (123.50.82.141)
Hi,
The "tool_conn_setup" function (in common.c) autorise the Url synthaxe
"ldap:///dc=my%2cdc=domaine" which produce a SRV request to find the best server
to request (not yet according the rfc 2782 - I've made dnssrv.c patch to
implement priorities and I try to implement weight before submit this work). So,
the client tools - ldapsearch, ldapadd, ... permit this syntaxe (via
"ldap_dn2domain" and "ldap_domain2hostlist" functions).
Unfortunately, ldap_initialize() doesn't use these functions (but only
ldap_url_parselist_ext()) and doesn't allow this synthaxe. So, other packages
(like SAMBA) doesn't enjoy this capability : "passdb backend =
ldapsam:ldap:///dc=my%2cdc=domain" according a SRV definition
"_ldap._tcp.my.domain. IN SRV ..."
Is there any reason for that ? Can we envisage to increase this possibility ?
Regards
12 years, 8 months
(ITS#5918) slapacl(8c) badly worded
by quanah＠zimbra.com
Full_Name: Quanah Gibson-Mount
Version: RE24
OS: NA
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.29.239)
Slapacl is used to check the behavior of the slapd in verifying access
to data according to ACLs, as specified in slapd.access(5). It opens
the slapd.conf(5) configuration file, reads in the access directives,
and then parses the attr list given on the command-line; if none is
given, access to the entry pseudo-attribute is tested.
Besides the bit about "of the slapd", the first sentence is rather awkward.
12 years, 8 months
RE: (ITS#5912) Meta modify increment feature
by jorge.nevado＠ericsson.com
Hi
We have tested the solution. It works OK.
Greetings,
Jorge.
-----Original Message-----
From: Pierangelo Masarati [mailto:ando@sys-net.it]
Sent: jueves, 29 de enero de 2009 20:34
To: Jorge Nevado
Cc: openldap-its(a)openldap.org
Subject: Re: (ITS#5912) Meta modify increment feature
Fixed in HEAD; please test. Thanks, p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
12 years, 8 months
Re: (ITS#5398) An account locked in a consumer is only unlocked when the password is changed two times
by hyc＠symas.com
ssnet(a)ua.es wrote:
> Full_Name: maria saez
> Version: 2.4.8
> OS: debian etch
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (193.145.230.2)
>
>
>
> An account locked in a consumer needs two password changes in the provider to be
> unlocked.
I'm unable to reproduce this behavior in current code.
> The first time that we change the password in the provider the password change
> is replicated in the consumer but the account remains locked.
A single password change on the provider results in unlocking on the consumer
for me.
>
> Can you help us?
> We have openldap-2.4.7 and openldap-2.4.8
>
> Is this situation normal?
>
> We have the following configuration:
>
> Provider
> -------------------------------------------
> database bdb
> suffix "dc=xx,dc=es"
> rootdn "cn=config"
> directory /xx/data
> index entryCSN eq
> index entryUUID eq
> index objectClass eq
> index mail eq
> # define the replica provider for this database
> # (last directives in database section)
> overlay ppolicy
> ppolicy_default "cn=Standard Policy,ou=Policies,dc=xx,dc=es"
> ppolicy_use_lockout
>
> overlay syncprov
> syncprov-checkpoint 100 10
> syncprov-sessionlog 100
>
>
> Consumer
> ----------------------------------------------------------------
> database bdb
> suffix "dc=xx,dc=es"
> rootdn "cn=config"
> directory /xx/data
> index entryCSN eq
> index entryUUID eq
> index objectClass eq
> index mail eq
>
> overlay ppolicy
> ppolicy_default "cn=Standard Policy,ou=Policies,dc=ua,dc=es"
> ppolicy_use_lockout
>
> syncrepl rid=123
> provider=ldaps://xx.xx.es:xx/
> binddn="cn=config"
> bindmethod=simple
> credentials=xx
> searchbase="dc=xx,dc=es"
> schemachecking=on
> type=refreshAndPersist
> retry="60 +"
>
> overlay syncprov
> -------------------------------------------------------------------
> The policy we have defined:
>
> dn: cn=Standard Policy,ou=Policies,dc=xx,dc=es
> cn: Standard Policy
> objectClass: top
> objectClass: device
> objectClass: pwdPolicy
> pwdAttribute: 2.5.4.35
> pwdLockout: TRUE
> pwdLockoutDuration: 0
> pwdInHistory: 6
> pwdCheckQuality: 2
> pwdExpireWarning: 10
> pwdMaxAge: 120
> pwdMinLength: 5
> pwdGraceAuthnLimit: 3
> pwdAllowUserChange: TRUE
> pwdMustChange: TRUE
> pwdMaxFailure: 3
> pwdFailureCountInterval: 120
> pwdSafeModify: TRUE
> pwdMinAge: 120
> -------------------------------------------------------------
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
12 years, 8 months
(ITS#5917) slapd crashes with assertion failed and SIGABRT
by guido＠keamera.org
Full_Name: Guido Landi
Version: 2.3.43
OS: linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (194.246.126.62)
Hello,
I'm using OpenLDAP 2.3.43 with ldap backend as a proxy to Active Directory for
users autentication on linux(gentoo).
OpenLDAP keep on crashing while testing it through the nss_ldap module using
the "id" unix command. It often crashes for an assertion failed(that i can
easily reproduce) but sometimes with a segmentation fault or a glibc error
related to free()(heap corruption?).
I found as a workaround that if I set the maximum threads number to 2 it works
just fine.
I'm using glibc-2.6.1 with NPTL and I have compiled OpenLDAP with gcc-4.1.2 and
3.4.6.
Here is my slapd.conf, ldap.conf(used by the nss_ldap module) and some
backtraces.
####
slapd.conf
####
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/local.schema
modulepath /usr/lib/openldap/openldap
moduleload rwm
overlay rwm
rwm-map attribute cn sAMAccountName
database ldap
suffix "dc=mydomain,dc=it"
rootdn "ou=CV Utenti,dc=mydomain,dc=it"
lastmod off
uri ldaps://mydc.mydomain.it/
rebind-as-user
chase-referrals YES
index objectClass eq,sub
index uidNumber,gidNumber eq
index memberUid eq
index sAMAccountName eq,subinitial
#concurrency 0
#threads 2
TLSCACertificateFile /etc/openldap/ssl/cacert.pem
TLSCertificateFile /etc/openldap/ssl/server.pem
TLSCertificateKeyFile /etc/openldap/ssl/server.key
TLSCipherSuite ALL
TLSCRLCheck none
TLSReqCert none
TLSVerifyClient never
####
ldap.conf
####
uri ldaps://ldap-proxy.mydomain.it
port 636
base OU=mygroup,dc=mydomain,dc=it
scope sub
binddn CN=myaccount,DC=mydomain,DC=it
bindpw password
bind_policy soft
ldap_version 3
#nss_schema rfc2307bis
#debug 1000
REFERRALS no
pam_login_attribute cn
pam_filter objectClass=user
pam_password ad
pam_groupdn CN=UNIX Admins,DC=mydomain,DC=it
#pam_groupdn CN=UNIX-USERS,DC=mydomain,DC=it
pam_member_attribute member
nss_base_passwd OU=Users,DC=mydomain,DC=it
nss_base_shadow OU=Users,DC=mydomain,DC=it
nss_base_group DC=mydomain,DC=it?(objectClass=group)
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid uid
nss_map_attribute uniqueMember member
#nss_map_attribute uniqueMember msSFU30PosixMemberOf
nss_map_attribute userPassword unixUserPassword
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute loginShell loginShell
nss_map_attribute gecos name
nss_map_objectclass posixGroup group
nss_reconnect_tries 4
nss_reconnect_sleeptime 1
#nss_reconnect_maxsleeptime 16
nss_reconnect_maxconntries 6
#nss_initgroups backlink
#nss_max_group_depth 100
ssl yes
####
backtraces
####
put_simple_filter: "member=cn=certsvc_dcom_access,cn=users,dc=mydomain,dc=it"
ldap_send_initial_request
ldap_send_server_request
ldap_back_retry: conn 0x826a628 refcnt=2 unable to retry.
slapd: bind.c:157: ldap_back_conn_delete: Assertion `!(*(&((lc))->lc_lcflags) &
(((0x00000020U))))' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb722eb90 (LWP 25435)]
0xb7b711c7 in raise () from /lib/libc.so.6
(gdb) bt
#0 0xb7b711c7 in raise () from /lib/libc.so.6
#1 0xb7b72998 in abort () from /lib/libc.so.6
#2 0xb7b6a7e5 in __assert_fail () from /lib/libc.so.6
#3 0x081147d8 in ldap_back_conn_delete ()
#4 0x081150e1 in ?? ()
#5 0x08217930 in ?? ()
#6 0x0826a628 in ?? ()
#7 0xb722cde8 in ?? ()
#8 0x081166f5 in ldap_back_release_conn_lock ()
Backtrace stopped: frame did not save the PC
ber_flush: 104 bytes to sd 11
ldap_result ld 0x825dfb0 msgid 5
ldap_chkResponseList ld 0x825dfb0 msgid 5 all 0
ldap_chkResponseList returns ld 0x825dfb0 NULL
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb692db90 (LWP 25728)]
0xb7b711c7 in raise () from /lib/libc.so.6
(gdb) bt
#0 0xb7b711c7 in raise () from /lib/libc.so.6
#1 0xb7b72998 in abort () from /lib/libc.so.6
#2 0xb7b6a7e5 in __assert_fail () from /lib/libc.so.6
#3 0xb7f8da8c in ber_flush () from /usr/lib/liblber-2.3.so.0
#4 0xb7fb9005 in ldap_int_flush_request () from /usr/lib/libldap_r-2.3.so.0
#5 0xb7fb94da in ldap_send_server_request () from /usr/lib/libldap_r-2.3.so.0
#6 0xb7fb8fa9 in ldap_send_initial_request () from /usr/lib/libldap_r-2.3.so.0
#7 0xb7fa8188 in ldap_search_ext () from /usr/lib/libldap_r-2.3.so.0
#8 0x080f6eb0 in ldap_back_search ()
#9 0x08079a9f in fe_op_search ()
#10 0x080df1fa in overlay_op_walk ()
#11 0x080df3b1 in ?? ()
#12 0x082968d0 in ?? ()
#13 0xb692d18c in ?? ()
#14 0x00000002 in ?? ()
#15 0x08217190 in ?? ()
#16 0x00000000 in ?? ()
put_simple_filter: "member=cn=unix admins,ou=cv acl,dc=mydomain,dc=it"
ldap_send_initial_request
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
slapd: io.c:210: ber_flush: Assertion `( (sb)->sb_opts.lbo_valid == 0x3 )'
failed.
** ld 0xb560f238 Response Queue:
Empty
ldap_chkResponseList ld 0xb560f238 msgid 5 all 0
ldap_chkResponseList returns ld 0xb560f238 NULL
ldap_int_select
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb722eb90 (LWP 29674)]
---Type <return> to continue, or q <return> to quit---
0xb7b711c7 in raise () from /lib/libc.so.6
(gdb) bt
#0 0xb7b711c7 in raise () from /lib/libc.so.6
#1 0xb7b72998 in abort () from /lib/libc.so.6
#2 0xb7b6a7e5 in __assert_fail () from /lib/libc.so.6
#3 0xb7f8da70 in ber_flush () from /usr/lib/liblber-2.3.so.0
#4 0xb7fb9005 in ldap_int_flush_request () from /usr/lib/libldap_r-2.3.so.0
#5 0xb7fb94da in ldap_send_server_request () from /usr/lib/libldap_r-2.3.so.0
#6 0xb7fb8fa9 in ldap_send_initial_request () from /usr/lib/libldap_r-2.3.so.0
#7 0xb7fa8188 in ldap_search_ext () from /usr/lib/libldap_r-2.3.so.0
#8 0x080f6e10 in ldap_back_search ()
#9 0x08079a97 in fe_op_search ()
#10 0x080df15a in overlay_op_walk ()
#11 0x080df311 in over_op_func ()
#12 0x080df395 in over_op_search ()
#13 0x08079549 in do_search ()
#14 0x0807677a in connection_operation ()
#15 0xb7fa30a9 in ldap_int_thread_pool_wrapper () from
/usr/lib/libldap_r-2.3.so.0
#16 0xb7e5a013 in start_thread () from /lib/libpthread.so.0
#17 0xb7c0948e in clone () from /lib/libc.so.6
12 years, 8 months
Re: (ITS#5916) Allow alias dereferencing in search C API
by ando＠sys-net.it
michael(a)stroeder.com wrote:
> Hmm, maybe I missed something in this discussion and about the usage of
> client controls.
>
> But I'd vote for another function which provides a complete set of
> arguments for sending search requests. So if ldap_search_ext is
> considered incomplete regarding alias dereferencing I'd vote for
> introducing ldap_search_ext2 (or whatever name) with an additional argument.
Well, that's ldap_int_search*(); let's vote for the "public" name. As I
said, I think it makes sense, since alias dereferencing has always been
explicitly required in the request.
OTOH, I have no objection to using a client-side control, as it wouldn't
add too much complexity (well, it'd require to parse a list of strings
with a worst-case of N * M, with N: number of known client controls; M:
client controls passed to the request), and it would pave the way for
client controls in libldap :) I see Hallvard already has a request for
another one.
One consideration: I'm not overlooking the value of not changing the API
too often; also, I fear client-side controls could be another way to
wind up with revitalizing the old API instead of designing a new one -
if anyone ever seriously considered the opportunity to design it.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497
Email: ando(a)sys-net.it
-----------------------------------
12 years, 8 months
Re: (ITS#5916) Allow alias dereferencing in search C API
by h.b.furuseth＠usit.uio.no
michael(a)stroeder.com writes:
> But I'd vote for another function which provides a complete set of
> arguments for sending search requests. So if ldap_search_ext is
> considered incomplete regarding alias dereferencing I'd vote for
> introducing ldap_search_ext2 (or whatever name) with an additional
> argument.
Yes, the missing aliases argument is an API design bug. The API almost
but not quite has functions that match the protocol messages.
If we are going to export yet another search function, I'd like to see
another feature added as well: A way to pass the BER form of a filter
to the search function. And some helpers to build the BER form, and to
parse it back into the string form of a filter. Filters are complex
enough that it can be a pain to deal with the string form and its
quoting at times.
Of course, that one could be a client control too - e.g. combined with
passing NULL as the filter...
--
Hallvard
12 years, 8 months
Re: (ITS#5916) Allow alias dereferencing in search C API
by michael＠stroeder.com
Kurt(a)OpenLDAP.org wrote:
> On Jan 31, 2009, at 11:21 AM, hyc(a)symas.com wrote:
>> ando(a)sys-net.it wrote:
>>> h.b.furuseth(a)usit.uio.no wrote:
>>>> ando(a)sys-net.it writes:
>>>>> Proxy backends use ldap_set_option(3) to set alias
>>>>> dereferencing when requested by a search operation (and do
>>>>> not clean it up afterwards, as far as I can tell). Since
>>>>> LDAP handlers are pooled and reused, this behavior is
>>>>> inherently broken.
>> [..]
>> I recall complaining about this deficiency in the API back in 1998,
>> when I
>> first wrote back-ldap. Alias deref has always been a part of the
>> protocol, but
>> it has always been missing from the API. Perplexing...
>
> Yes, of course, one might use the client control mechanism to add an
> ability to set deref on a call by call basis instead of introducing
> yet another function.
Hmm, maybe I missed something in this discussion and about the usage of
client controls.
But I'd vote for another function which provides a complete set of
arguments for sending search requests. So if ldap_search_ext is
considered incomplete regarding alias dereferencing I'd vote for
introducing ldap_search_ext2 (or whatever name) with an additional argument.
Ciao, Michael.
12 years, 8 months
