ppolicy and sync replication
by Craig Squires
This is a followup to a thread from a couple of months ago. The issue is
interaction between ppolicy and syncrepl overlays. The message I want to
start at is:
http://www.openldap.org/lists/openldap-software/200701/msg00131.html
which didn't get a direct reply. Here's a quote of the relevant context:
> From: Sadique Puthen <xenguy(a)gmail.com>
>
> I did a bit more testing about this.
>
> I set up password policy as below. Only relevant part given.
>
> pwdLockout: TRUE
> pwdMaxFailure: 3
> pwdLockoutDuration: 90
>
> 1 - I did bind to the master server 3 times using wrong password. I
> failed to bind using the right password after that and failed.
> Expected
> 2- I did bind to the consumer server using the right password.
> Failed. Expected.
I note that in my experience, for this to work the "overlay ppolicy"
statement in the consumer's slapd.conf must precede the "overlay
syncrepl" statement. Without that, the consumer doesn't seem to respect
the account lock.
> After 90 seconds everything works fine.
At this point I'm having some further problems:
2a- I bind with the right password on the consumer after the lockout
duration and the pwdFailureTime and pwdAccountLockedTime attributes
are deleted on the consumer, as expected. However, related to Sadique's
next step, those attributes still exist on the provider because
obviously no info gets pushed back from the consumer. This isn't
necessarily a problem for me, but the following is:
2b- I bind with the right password on the provider after the lockout
duration and the attributes are now deleted there. But the consumer
now crashes and is not recoverable. Oddly, if I bind incorrectly on
the provider first and then bind correctly the crash does not occur.
With the new incorrect bind after the lockout duration the
pwdAccountLockedTime attribute is deleted while the old pwdFailureTime
attributes are not. They are deleted with the following correct bind. So
there's something specific about the LockedTime attr that's at issue.
I'm running 2.3.34 on RHEL AS4 (both provider and consumer) using Buchan
Milne's RPMs (thanks Buchan!!). The same issue existed in 2.3.31. I
should also note that I'm doing delta syncrepl... and haven't tried this
with regular syncrepl. I've noticed asides at a couple of places in the
archives that suggest that at least some ppolicy related attrs aren't
supposed to be replicated, yet there's some suggestion at others that
they are. In particular, Pierangelo Masarati states, in a reply to the
original message from Sadique, that: "In general, ppolicy related
state values are not replicated; each replica is on its own as far as
state-related attributes in enforcing password policy. [...]"
Here's a summary of my provider and consumer slapd.conf files:
Provider:
--------
database bdb
suffix "cn=log"
[directory, rootdn, indexes]
overlay syncprov
syncprov-reloadhint true
syncprov-nopresent true
access to *
by dn="<replicator>" read
database bdb
[suffix, directory, rootdn, indexes]
overlay syncprov
syncprov-checkpoint 100 10
overlay accesslog
logdb cn=log
logops writes
logsuccess true
overlay unique
unique_attributes <attr1 attr2>
overlay ppolicy
access to dn="<password policy subtree>"
by dn="<replicator>" read
by * none
[acls, cachesize, checkpoint, limits]
Consumer:
--------
database bdb
[suffix, directory, indexes, rootdn]
overlay ppolicy
syncrepl rid=1
provider=<provider>
type=refreshAndPersist
retry="60 10 300 3"
bindmethod=simple
starttls=critical
binddn="<replicator>"
credentials=<secret>
searchbase="<provider's suffix>"
logbase="cn=log"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
overlay syncprov
[acls]
I've tried preventing replication of the two offending attrs via an acl
but that didn't prevent the replication (because they're operational?).
Any help would be much appreciated. I have debug output if required.
[here's the rest of Sadique's message]
> 3- I did bind to the consumer server using the wrong password three
> times. I failed to bind to the consumer using the right password
> after that. Failed. Expected
> 4 - I did bind to the master server using the right password.
> Success. Not expected before elapsing 90 seconds.
>
> I know the consumer server is not supposed to update the master
> server database, but is there any work around? Does openldap support
> multi master replication? Is this a limitation. Does this mean a
> client locked on consumer server - as set by the policy - would be
> able to bind to the master server overriding the policy.
Cheers, Craig
16 years, 2 months
make test question
by Josh Miller
When running 'make test', if any of the tests fail, will the testing
continue or will it stop all further tests?
I'm wondering if I should be parsing the test output and reviewing it to
ensure proper builds.
Thanks,
--
Joshua M. Miller - RHCE,VCP
16 years, 2 months
RE: DIGEST-MD5 returns 'user not found'
by Chapman, Kyle
Does:
Ldapsearch -y digest-md5 -U root -R tivo2 -W
Show anything diff. I havent used sasldb2 stuff in a while, however with digestmd5 when secrets are stored in the ldap dit, had to be clear text.
-----Original Message-----
From: openldap-software-bounces+kyle_chapman=g1.com(a)OpenLDAP.org [mailto:openldap-software-bounces+kyle_chapman=g1.com@OpenLDAP.org] On Behalf Of lemons_terry(a)emc.com
Sent: Monday, April 02, 2007 10:36 AM
To: openldap-software(a)openldap.org
Subject: DIGEST-MD5 returns 'user not found'
Hi
I'm trying to use DIGEST-MD5 authentication on a SLES 9 SP3 system running OpenLDAP 2.
tivo2:~ # ldapsearch
SASL/DIGEST-MD5 authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
additional info: SASL(-13): user not found: no secret in database
When I run 'ldapsearch -d 2', I see that 'username=root' and 'realm=tivo2.backup'.
I believe that I have the correct entry for 'root' in the SASL database:
sasldblistusers2
root@tivo2: userPassword
So why is SASL saying 'user not found'?
Thanks
tl
Terry Lemons
Backup Platforms Group
EMC²
where information lives
4400 Computer Drive, MS D239
Westboro MA 01580
Phone: 508 898 7312
Email: Lemons_Terry(a)emc.com
NOTICE: This E-mail may contain confidential information. If you are not
the addressee or the intended recipient please do not read this E-mail
and please immediately delete this e-mail message and any attachments
from your workstation or network mail system. If you are the addressee
or the intended recipient and you save or print a copy of this E-mail,
please place it in an appropriate file, depending on whether
confidential information is contained in the message.
16 years, 2 months
Re: err=52
by jerrrry＠voila.fr
OK i will test our Red Hat gold support. it's the fisrt time !
and if they cannot do anything i will upgrade openldap.
Thomas
> Message du 02/04/07 à 15h50
> De : "Aaron Richton"
> A : "jerrrry(a)voila.fr"
> Copie à : openldap-software(a)openldap.org
> Objet : Re: err=52
>
> On Mon, 2 Apr 2007, jerrrry(a)voila.fr wrote:
>
> > my issue is that i have to use the RedHat ES 4 Openldap package.
>
> Then your issue should be directed to support.redhat.com...
>
>
> I'm pretty sure that your "err=52" is ITS#4429, reported against 2.3.20
> and fixed in 2.3.21 (April, 2006).
>
> RedHat obviously doesn't care about patches that affect actual sites (such
> as mine and yours), even given a full year to integrate them. I'd highly
> suggest using an alternative software source that has acceptable support.
> (I would claim that the mere fact that you're running into a known and
> long-fixed bug does not constitute "acceptable support" if you're running
> an OpenLDAP server.) But if you "have to use" the RedHat ES 4 package,
> you'll have to take it up with them that their laziness is causing you
> production issues.
>
>
16 years, 2 months
LDAP Sync protocol doubt
by Irfaz
Hi ,
I was testing the usage of OpenLDAP content synchronization
feature....But I was struck with an error : "Critical Extension
unavailable"....
I was trying to call ldap_sync_init after ldap_sync_initialize.....and I am
not clear about the usage of the Sync APis..
Please provide me some inputs on the same and if possible some sample test
codes to achieve client notification from server about updations....
Irfaz Sait
Software Engineer
Huawei Technologies India Pvt. Ltd.
INNOVATION NEVER STOPS!
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
16 years, 2 months
connection timeout
by Brandon McCombs
Hello,
Using my client app I wrote I can receive a "Connection reset" error
from the OpenLDAP server if I leave the app idle long enough however the
idletimeout directive in slapd.conf is not specified so the default
should be to never time out. Is a connection reset message the same
thing as connection closed message? I'd assume so which begs the
question, why did it do that if the timeout is disabled by the lack of
the idletimeout directive in slapd.conf?
thanks
16 years, 2 months
slapd segfaults during SASL/GSSAPI bind
by Paul Turgyan
I've gotton several slapd core files where slap has segfaulted during
a GSSAPI bind.
Unfortunately I can't make slapd core. But the stack trace always
looks the same:
(gdb) bt
#0 0xb7f3a410 in ?? ()
#1 0xad328d28 in ?? ()
#2 0x00000006 in ?? ()
#3 0x000056ae in ?? ()
#4 0xb7c0b041 in *__GI_raise (sig=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#5 0xb7c0c7d7 in *__GI_abort () at ../sysdeps/generic/abort.c:88
#6 0xb7c3e4ce in __libc_message (do_abort=2,
fmt=0xb7cee5c0 "*** glibc detected *** %s: 0x%s ***\n")
at ../sysdeps/unix/sysv/linux/libc_fatal.c:145
#7 0xb7c48196 in malloc_printerr (action=2, str=0x0, ptr=0x0) at
malloc.c:5525
#8 0xb7c46e9d in _int_free (av=0xb7cfb820, mem=0x97bf77a4) at
malloc.c:4235
#9 0xb7c45bfb in *__GI___libc_free (mem=0x97bf77a4) at malloc.c:3404
#10 0x0807ad56 in ch_free (ptr=0x97bf77a4) at ch_malloc.c:139
#11 0x080a5b86 in slap_sasl_authorize (sconn=0x945e1d48,
context=0xad72f228,
requested_user=0x945e2658 "tjsm(a)UMICH.EDU", rlen=14,
auth_identity=0x945e2759 "tjsm(a)UMICH.EDU", alen=14,
def_realm=0x96849538 "UMICH.EDU", urlen=9, props=0x0) at sasl.c:673
#12 0xb7e73ba3 in do_authorization (s_conn=0x945e1d48) at server.c:1163
#13 0xb7e73d18 in sasl_server_step (conn=0x945e1d48,
clientin=0xa8ec5716 "`?\006\t*\206H\206?\022\001\002\002\002\001
\004",
clientinlen=0, serverout=0xad329114, serveroutlen=0x56ae) at
server.c:1420
#14 0x080a6984 in slap_sasl_bind (op=0x7683c860, rs=0xad329240) at
sasl.c:1399
#15 0x0807d06a in fe_op_bind (op=0x7683c860, rs=0xad329240) at bind.c:
276
#16 0x0807c873 in do_bind (op=0x7683c860, rs=0xad329240) at bind.c:200
#17 0x08061a8f in connection_operation (ctx=0x0, arg_v=0x7683c860)
at connection.c:1132
#18 0x08116168 in ldap_int_thread_pool_wrapper (xpool=0x81cd520) at
tpool.c:478
#19 0xb7e54c6b in start_thread (arg=0xad329bb0) at pthread_create.c:261
#20 0xb7c9ad9e in clone () from /lib/libc.so.6
It looks to me that slap_sasl_authorize is freeing someting that has
already been freed
namely context->c_sasl_dn.
Here is the context structure:
(gdb) p *(Connection *) context
$5 = {c_struct_state = 2, c_conn_state = 3, c_conn_idx = 46,
c_close_reason = 0x81446c5 "?", c_mutex = {__data = {__lock = 0,
__count = 0, __owner = 0, __kind = 0, __nusers = 0, __spins = 0},
__size = '\0' <repeats 23 times>, __align = 0}, c_sb = 0x9efce118,
c_starttime = 1175269483, c_activitytime = 1175269483, c_connid =
4957353,
c_peer_domain = {bv_len = 7, bv_val = 0xa5863d98 "unknown"},
c_peer_name = {
bv_len = 22, bv_val = 0xa368c190 "IP=141.211.14.17:58013"},
c_listener = 0x81c02c8, c_sasl_bind_in_progress = 1,
c_sasl_bind_mech = {
bv_len = 6, bv_val = 0x8435bbc0 "GSSAPI"}, c_sasl_dn = {bv_len =
35,
bv_val = 0x97bf77a4 "hasSubordinates1\a\004
\005FALSESESESEALSEALSEEALSEALSEavin,ou=People,dc=umich,dc=edu\004%
uid=jleasia,ou=People,dc=umich,dc=edu\004
$uid=ktexas,ou=People,dc=umich,dc=edu\004!
uid=lmp,ou=People,dc=umich,dc=edu\004%uid=philr"...}, c_sasl_authz_dn
= {bv_len = 0, bv_val = 0x0},
c_authz_backend = 0x81e6dc8, c_authz_cookie = 0x0, c_authz = {
sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {
bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0},
sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0,
sai_sasl_ssf = 0},
c_protocol = 3, c_ops = {stqh_first = 0x7683c860, stqh_last =
0x7683c92c},
c_pending_ops = {stqh_first = 0x0, stqh_last = 0xad72f2d0},
c_write_mutex = {
__data = {__lock = 0, __count = 0, __owner = 0, __kind = 0,
__nusers = 0,
__spins = 0}, __size = '\0' <repeats 23 times>, __align = 0},
c_write_cv = {__data = {__lock = 0, __futex = 1782, __total_seq =
891,
__wakeup_seq = 891, __woken_seq = 891, __mutex = 0xad72f238,
__nwaiters = 0, __broadcast_seq = 0},
__size = "\000\000\000\000?\006\000\000{\003\000\000\000\000\000
\000{\003\000\000\000\000\000\000{\003\000\000\000\000\000\0008?r?",
'\0' <repeats 11 times>, __align = 7653631721472}, c_currentber =
0x968f5370, c_writewaiter = 0,
c_is_tls = 0, c_needs_tls_accept = 0, c_sasl_layers = 0,
c_sasl_done = 0,
c_sasl_authctx = 0x945e1d48, c_sasl_sockctx = 0x0,
c_sasl_extra = 0x927e6f80, c_sasl_bindop = 0x7683c860,
c_pagedresults_state = {ps_be = 0x0, ps_size = 0, ps_cookie = 0,
ps_count = 0}, c_n_ops_received = 4, c_n_ops_executing = 1,
c_n_ops_pending = 0, c_n_ops_completed = 3, c_n_get = 4, c_n_read
= 4,
c_n_write = 0, c_pb = 0x0, c_extensions = 0x0, c_clientfunc = 0,
c_clientarg = 0x0, c_send_ldap_result = 0x806fb10
<slap_send_ldap_result>,
c_send_search_entry = 0x80714a0 <slap_send_search_entry>,
c_send_search_reference = 0x80705d0 <slap_send_search_reference>,
c_send_ldap_extended = 0x8070290 <slap_send_ldap_extended>,
c_send_ldap_intermediate = 0x8070440 <slap_send_ldap_intermediate>}
Current environment:
openldap-2.3.32
cyrus sasl 2.1.21
heimdal 0.6.6
linux from source - kernal 2.6.18
Any ideas?
16 years, 2 months
err=52
by jerrrry＠voila.fr
Hi all,
i'm using openldap 2.2.13 as a proxy to an other ldap server. it works and after few days, authentications doesn't work any more. and i have an error 52 in my ldap log:
ar 29 17:51:13 guardsdef1 slapd[23444]: conn=4 op=5 SRCH base="ou=personnes,o=st" scope=2 deref=3 filter="(&(objectClass=*)(uid=n588t67))"
Mar 29 17:51:13 guardsdef1 slapd[23444]: conn=4 op=5 SRCH attr=uid
Mar 29 17:51:13 guardsdef1 slapd[23444]: conn=4 op=5 SEARCH RESULT tag=101 err=52 nentries=0 text=
Mar 29 17:51:13 guardsdef1 slapd[23444]: conn=4 op=5 SEARCH RESULT tag=101 err=52 nentries=0 text=
this error means:
LDAP_UNAVAILABLE: Indicates that the LDAP server cannot process the client's bind request, usually because it is shutting down.
my slapd conf:
database ldap
suffix o=sg
uri ldaps://ldap.s45ame.iioup.soen
Do you have any idea why open ldap "is shutting down" ?
thank you for your help
Thomas
16 years, 2 months
OpenLDAP Test suite
by Irfaz
Hi..
I am not able to find OpenLDAP test suite in my installed package
in Linux..Please provide me some info to get the test suite..
Irfaz Sait
Software Engineer
Huawei Technologies India Pvt. Ltd.
INNOVATION NEVER STOPS!
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
16 years, 2 months
DIGEST-MD5 returns 'user not found'
by lemons_terry＠emc.com
Hi
I'm trying to use DIGEST-MD5 authentication on a SLES 9 SP3 system running OpenLDAP 2.
tivo2:~ # ldapsearch
SASL/DIGEST-MD5 authentication started
Please enter your password:
ldap_sasl_interactive_bind_s: Internal (implementation specific) error (80)
additional info: SASL(-13): user not found: no secret in database
When I run 'ldapsearch -d 2', I see that 'username=root' and 'realm=tivo2.backup'.
I believe that I have the correct entry for 'root' in the SASL database:
sasldblistusers2
root@tivo2: userPassword
So why is SASL saying 'user not found'?
Thanks
tl
Terry Lemons
Backup Platforms Group
EMC²
where information lives
4400 Computer Drive, MS D239
Westboro MA 01580
Phone: 508 898 7312
Email: Lemons_Terry(a)emc.com
16 years, 2 months
