openldap-software April 2007

openldap-software@openldap.org

90 participants
96 discussions

ppolicy and sync replication
by Craig Squires 04 Apr '07

04 Apr '07

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

2 2

make test question
by Josh Miller 04 Apr '07

04 Apr '07

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

3 2

RE: DIGEST-MD5 returns 'user not found'
by Chapman, Kyle 03 Apr '07

03 Apr '07

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.

5 9

Re: err=52
by jerrrry＠voila.fr 03 Apr '07

03 Apr '07

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. > >

1 0

LDAP Sync protocol doubt
by Irfaz 02 Apr '07

02 Apr '07

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!

3 4

connection timeout
by Brandon McCombs 02 Apr '07

02 Apr '07

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

2 1

slapd segfaults during SASL/GSSAPI bind
by Paul Turgyan 02 Apr '07

02 Apr '07

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?

2 3

err=52
by jerrrry＠voila.fr 02 Apr '07

02 Apr '07

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

5 5

OpenLDAP Test suite
by Irfaz 02 Apr '07

02 Apr '07

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!

3 2

DIGEST-MD5 returns 'user not found'
by lemons_terry＠emc.com 02 Apr '07

02 Apr '07

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

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software April 2007