openldap-technical

openldap-technical@openldap.org

7 participants
9864 discussions

Re: Multi Master replication with many 'nonpresent_callback' lines
by Quanah Gibson-Mount 02 May '17

02 May '17

--On Sunday, April 23, 2017 12:38 AM +0000 Jesper Grøndahl <grondahl(a)ruc.dk> wrote: > Our log level is stats and sync. > > The logs look like this, for the user being modified > ----- > nonpresent_callback: rid=005 present UUID > 528929d6-acaa-1036-922a-a3f5c9285d9d, dn uid=xxx,ou=users,dc=ruc,dc=dk > Entry uid=xxx,ou=users,dc=ruc,dc=dk CSN > 20170406140323.504919Z#000000#002#000000 greater than snapshot > 20170403102309.253881Z#000000#002#000000 It would appear you have serious issues with your installation, since the CSNs are off by 3 days. I would note that 2.4.40 is not stable for MMR as well. I would ensure you aren't suffering from clock skew across your servers, and upgrade to the current OpenLDAP release as well. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

detect LDAPI support
by Michael Ströder 27 Apr '17

27 Apr '17

HI! Is there an reliable way to detect whether LDAPI support is enabled in the OpenLDAP build on a particular platform? I vaguely remember the developer discussions about disabling LDAPI on platforms where the peer credentials are not secure. Background: I'd like to detect with python-ldap whether to enable LDAPI in automatic testing or not. Ciao, Michael.

2 2

test program for ldap_int_sasl_init issue
by Ryan Tandy 27 Apr '17

27 Apr '17

I'm looking into a Debian bug report: https://bugs.debian.org/860947 ldap_int_sasl_init says: /* XXX not threadsafe */ static int sasl_initialized = 0; I'm not yet sure whether it's the cause of that report, but it does seem to be problematic. I'm seeing spurious "no such mechanism" results and/or crashes in mutiple environments performing SASL binds in parallel: - slapd with multiple syncrepl clients all using SASL binds, - the ldclt tool from the 389-ds project, and - the test program I'm about to describe below. I wrote a test program for this issue, and I'd like to ask the list to check the code before I submit an ITS, in case I've made a mistake that renders my test invalid. gcc -g sasltest.c -pthread -llber -lldap -lsasl2 -DSASL As I understand it, -lldap_r should not be needed here since each thread creates its own LDAP instance. (It doesn't seem to change the results, anyway.) Built without -DSASL, it uses simple binds, and appears to work fine, but again, I'm not confident my code is correct. Thanks! Ryan

1 0

Re: chain overlay does an anonymous bind and ignores the chain binddn (v2.4.44)
by Howard Chu 27 Apr '17

27 Apr '17

Matthew Kemp wrote: > > On Thu, Apr 20, 2017 at 6:36 AM, mailing lists <listas.correo(a)yahoo.es > <mailto:listas.correo@yahoo.es>> wrote: > > Hello, > > I am testing the chain overlay from a read-only slave (consumer) slapd > server to a read-write master (provider), but what I am seeing is an > anonymous bind from the consumer to the provider instead of the > authorization identity configurated in the chain directive. > > > We're also seeing the same behavior and reported a similar issue last month to > this list: > http://www.openldap.org/lists/openldap-technical/201703/msg00047.html > > I'm hopeful we can track down this issue as it's causing us some issues that > we'll need to resolve eventually. Only ProxyAuth will work, now. As documented, the chain overlay only intercepts responses to operations, and only acts when it sees a referral in the response. In order for rebind-as-user to work, the overlay would need to intercept Bind requests and cache the credentials, but it never intercepts Bind requests, therefore it has nothing to rebind with. It *could* intercept referrals from Bind responses, and grab the user's credentials at that point. But back in 2004 we turned those off, and slapd now will never return a referral to a Bind request. (commit 100facedf3c9ec241121a5e3ad7aa059a7c57bc2 in git.) Probably we should remove references to rebind-as-user from the slapo-chain(5) manpage now, since that commit basically killed this feature. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Re: chain overlay does an anonymous bind and ignores the chain binddn (v2.4.44)
by Matthew Kemp 26 Apr '17

26 Apr '17

On Wed, Apr 26, 2017 at 4:12 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > Hi Matthew, > > Can you look at follow up#4 to ITS#8008 and see if that helps your > situation? > > --Quanah > Hey Quanah! Thanks for reaching out! Sadly in my case the update is not specifically helpful in my case. I found the override flag already, but I do not want to use a ProxyAuth and instead want to bind as the originating user who bound to the consumer. Override allows a ProxyAuth to be used rather than an anonymous bind, which is better, but not the intended behavior I want that the documentation seems to imply is possible. -- Matt Kemp Production Engineer Braintree

1 0

Re: chain overlay does an anonymous bind and ignores the chain binddn (v2.4.44)
by Quanah Gibson-Mount 26 Apr '17

26 Apr '17

--On Monday, April 24, 2017 7:38 PM -0500 Matthew Kemp <matthew.kemp(a)braintreepayments.com> wrote: > > > > > On Thu, Apr 20, 2017 at 6:36 AM, mailing lists <listas.correo(a)yahoo.es> > wrote: > > > > Hello, > > > I am testing the chain overlay from a read-only slave (consumer) slapd > server to a read-write master (provider), but what I am seeing is an > anonymous bind from the consumer to the provider instead of the > authorization identity configurated in the chain directive. > > > > > > We're also seeing the same behavior and reported a similar issue last > month to this list: > http://www.openldap.org/lists/openldap-technical/201703/msg00047.html > > > I'm hopeful we can track down this issue as it's causing us some issues > that we'll need to resolve eventually. Hi Matthew, Can you look at follow up#4 to ITS#8008 and see if that helps your situation? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Processing telephone number
by Quanah Gibson-Mount 26 Apr '17

26 Apr '17

--On Wednesday, April 26, 2017 9:53 AM +0200 "Angel L. Mateo" <amateo(a)um.es> wrote: > Hi, > > I have an openldap that stores information of my users. One of the > fields we are using is telephoneNumber to store the phone number of the > user. > > In this field we are storing now the complete phone number, that is, a > number like +34 123456789, but now we are deploying applications that > need just the extension number (the last 4 digits), not the hole one. > > Is there any overlay or other option we can use to provide those last 4 > digits of the telephoneNumber attribute without needing to store them in > another different attribute? Nope. I'd suggest fixing the application so it does whatever data manipulation is necessary. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Processing telephone number
by Angel L. Mateo 26 Apr '17

26 Apr '17

Hi, I have an openldap that stores information of my users. One of the fields we are using is telephoneNumber to store the phone number of the user. In this field we are storing now the complete phone number, that is, a number like +34 123456789, but now we are deploying applications that need just the extension number (the last 4 digits), not the hole one. Is there any overlay or other option we can use to provide those last 4 digits of the telephoneNumber attribute without needing to store them in another different attribute? -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información y las Comunicaciones Aplicadas (ATICA) http://www.um.es/atica Tfo: 868889150 Fax: 868888337

1 0

Password storage policy and DIT organisation
by Andreas Ames 26 Apr '17

26 Apr '17

Hi all, my questions below are more about openldap pragmatics than technical issues; if they are off-topic, please point me somewhere else to ask. As I'm a newbie, please bear with me, if I get things completely wrong. What I want to achieve using slapd: a) A centralised authentication service for system accounts of a handful of Linux hosts (libpam-ldapd) and some apache-based webapps (mod_authnz_ldap). b) Every user has a single password stored in exactly one place in the DIT (single-sign on is not topical in my environment). c) I would like to have fine-grained control over whether an ldap user has access to a specific host or webapp or not. Based on that I have got two questions: 1. DIT organisation Let's assume my suffix is dc=foo. I plan to have ou=Users,dc=foo for storing ldap users with their (unique) passwords and ou=Services,dc=foo to have account information for each of my services; e.g. ou=host1,ou=services,dc=foo to provide posix account information for host1, or ou=webapp1,ou=services,dc=foo for mod_authnz_ldap related information regarding webapp1 etc. I plan to use olcAuthzRegexp to authenticate users below ou=host1,ou=services,dc=foo or ou=webapp1,ou=services,dc=foo against ldap users in ou=Users,dc=foo. Is this a sensible setup or are there better hierarchies to achieve my goals? 2. Password storage policy (NB: I am using TLS with a self-signed certificate.) Theoretically I would prefer to store hashed passwords. If I understand correctly, olcAuthRegexp only works with SASL and hashed passwords can only possibly work with the PLAIN mechanism (??). So I tried that and simple binding works as expected, when directly binding to an entry with an attribute "userPassword" (i.e. without indirection through olcAuthzRegexp). To get SASL/PLAIN working, I have tried (without success up till now) to use saslauthd. Moreover the authentication path "client -> TLS/TCP/IP -> slapd (SASL/PLAIN) -> Unix Domain socket -> saslauthd -> localhost/TCP/IP -> slapd (simple bind)" seems a little over the top for my use case. So I am wondering, if hashed password storage is really such a good idea. What are the (security) implications of cleartext storage of passwords? Do you have document links discussing this in some depth? Thanks in advance ... Mit freundlichen Grüßen / With kind regards / Cordiali saluti, Andreas Please consider the environment before you print / Merci de penser à l'environnement avant d'imprimer / Bitte denken Sie an die Umwelt bevor Sie drucken Bombardier Transportation GmbH. Vorsitzender des Aufsichtsrats / Chairman of Supervisory Board: Wolfgang Toelsner. Geschäftsführung / Management Board: Michael Fohrer (Vorsitzender/Chairman), Olaf Berghoff, Dr. Daniel Perlzweig, Konrad Wiebalck. Sitz der Gesellschaft / Principal Office: Berlin. Registergericht / Registration Court: Amtsgericht Charlottenburg, HRB 64838. This e-mail message, and any attachments, may contain information that is confidential and/or privileged. They are intended for the exclusive use of the addressee. Any other person is strictly prohibited from disclosure, distribution or reproduction. No waiver whatsoever is intended by sending this e-mail. If you receive this e-mail in error please immediately inform the sender by return e-mail and delete this e-mail message along with all the attachments and destroy all copies.

3 2

Re: Manual LDAP 2.4.44 Installation
by Quanah Gibson-Mount 25 Apr '17

25 Apr '17

--On Tuesday, April 25, 2017 1:57 AM +0000 Alexandre Vilarinho <acvoliveira(a)yahoo.com.br> wrote: > root@Linux-LDAP-SERVER:~# /usr/local/sbin/slapadd -F > /usr/local/etc/slapd.d -l /usr/local/etc/openldap/slapd.ldif > 58fe9bea invalid config directory /usr/local/etc/slapd.d, error 2 > slapadd: bad configuration directory! As per my previous email: >> Also ensure that directory exists prior to running the command. Not sure how to be any more clear than that. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical