openldap-technical January 2018

openldap-technical@openldap.org

23 participants
26 discussions

Incosistent config after schema modification
by Ervin Hegedüs 11 Jan '18

11 Jan '18

Hi there, here are a 3 member multimaster config with OpenLDAP 2.4.44 (Debian 9.3). We need a custom schema, so I've made that - everithing has worked as well, but the customer said he needs to modify some attribute type in the new custom schema. I've made an ldif: dn: cn={5}cppm,cn=schema,cn=config changetype: modify replace: olcAttributeTypes olcAttributeTypes: {0}( cppmAttrs:1 NAME 'cppmCreateTime' DESC 'Create time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE ) olcAttributeTypes: {5}( cppmAttrs:6 NAME 'cppmExpireTime' DESC 'Expire time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE ) olcAttributeTypes: {7}( cppmAttrs:8 NAME 'cppmActivationTime' DESC 'Activati on time' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE ) # ldapmodify -Y EXTERNAL -H ldapi:/// -f mod1.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "cn={5}cppm,cn=schema,cn=config" Then I'ld liked to add this new objectclass to a member of tree, but I got an error: "cppmDomainName: attribute type undefined" but - of corse - I've added this attribute to the original schema. So, I'ld like to backup the config database, but the slapcat said: # slapcat -b cn=config 5a562aa7 olcObjectClasses: value #0 olcObjectClasses: AttributeType not found: "cppmVisitorCompany" 5a562aa7 config error processing cn={5}cppm,cn=schema,cn=config: olcObjectClasses: AttributeType not found: "cppmVisitorCompany" slapcat: bad configuration file! What's happenned? What em'I wrong? And what should I do now? Thanks, a.

4 12

proxy/backend pointers
by David LaPorte 10 Jan '18

10 Jan '18

Sorry to re-send to the list, but I'm hopeful someone might have some thoughts on whether this might be possible! We have an old unsupported application that authenticates users using an LDAP bind. The credential used for authentication (and what all the internal authorizations are tied to) is employee ID. We are moving to LDAP directory that uses email address instead of employee ID as the DN - the employee ID is still present as an attribute in the new directory and the password remains the same. Since I can't modify the problematic application, it’s not going away anytime soon, and it’s the last thing holding up migration to the new directory system, I'm hoping that I can use OpenLDAP as a shim between the application and the new directory to do something like the following: * Collect credentials (employee_id, password) during bind * using a privileged service account, search/bind against the new directory to map employee ID attribute to email address DN (like mod_authz_ldap does it) * return the success/failure as result of original bind I would appreciate any ideas or pointers if this is possible or if there might be a better way. Thanks in advance! Dave David LaPorte david(a)davidlaporte.org

1 0

[Q] what is the best practice or right way to change schemas order for cn=config case?
by Zeus Panchenko 09 Jan '18

09 Jan '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, what is the best practice or right way to change schemas order for cn=config case? 1. to move file? 2. to ldapmodify? for the one used to slapd.conf both of ways look weird ... :( - -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlo6mMsACgkQr3jpPg/3oypRzwCdHNMNgUewiolW91I7DB7cK5dE BqoAn0tXLDIMIBg0W9uG39pwN7LPRPth =jKuI -----END PGP SIGNATURE-----

3 3

Re: uidNumber for Service Accounts?
by Douglas Duckworth 08 Jan '18

08 Jan '18

Thanks everyone. I agree it would be ideal to differenaiate this account from others. So far it's in own OU while standard users are in People. Seeing an error. The ldif: dn: uid=preset,ou=Service Accounts,dc=blah objectClass: top objectClass: account objectClass: applicationProcess Enter LDAP Password: adding new entry "uid=preset,ou=Service Accounts,dc=blah ldap_add: Object class violation (65) additional info: invalid structural object class chain (account/applicationProcess) Sorry, I am LDAP padawan. Though this does work as it's now in the LDAP server: dn: uid=preset,ou=Service Accounts,dc=blah objectClass: top objectClass: account objectClass: applicationProcess objectClass: simpleSecurityObject uid: preset cn: preset sn: preset givenName: preset title: Password Reset Account description: Service Account For Resetting Passwords I will then great this account the ability to write to all users in People OU. Any security concerns? Thanks, Douglas Duckworth, MSc, LFCS HPC System Administrator Scientific Computing Unit Physiology and Biophysics Weill Cornell Medicine E: doug(a)med.cornell.edu O: 212-746-6305 F: 212-746-8690 On Wed, Dec 20, 2017 at 2:07 AM, Michael Ströder <michael(a)stroeder.com> wrote: > MJ J wrote: > > Service accounts typically use the simpleSecurityObject object class. > > But one needs an appropriate structural object class to add the entry. > 'simpleSecurityObject' is an auxiliary object class without any naming > attribute. > > Ciao, Michael. > > > On Tue, Dec 19, 2017 at 9:15 PM, Douglas Duckworth > > <dod2014(a)med.cornell.edu> wrote: > >> It seems I created this service account with posixAccount objectClass. > That > >> requires uidNumber. > >> > >> So I need to do some research on what's the appropriate objectClass for > this > >> service account. It's used by SSSD and Apache, for example, to perform > >> binds with our LDAP cluster since we do not allow anon binds. In > addtion > >> ACLs only permit this account, and the Manager, access to read the > entire > >> directory. > >> > >> From reading here http://www.zytrax.com/books/ldap/ape/#objectclasses I > >> think I would only need objectClass: account which the service account > >> already contains. So I could delete the posixAccount objectClass and > then > >> uidNumber, gidNumber, homeDirectory, and loginShell? > >> > >> Thanks, > >> > >> Douglas Duckworth, MSc, LFCS > >

2 1

OpenLDAP slave failure in case of master indisponibility
by Matthieu Cerda 02 Jan '18

02 Jan '18

Greetings, I am observing a rather strange issue in the following setup: * 1 OpenLDAP master server (2.4.31) * 4 OpenLDAP slave servers (2.4.40) * The OpenLDAP slaves do forward any update attempt to the master using the chain overlay / proxyauthz (mainly to update the pwdFailureTime attribute for ppolicy) If I try to shut the master down (for maintenance let's say), the slaves behave properly, then begin to deadlock one after each other after a few minutes (by deadlock I mean no log output anymore, and any ldapwhoami / ldapsearch request connects and then times out) On the attached image, I monitored at the same time one of the slaves using collectd, to keep an eye on cn=monitor data (the period between 15:24:30 and 15:26:00 has been extrapolated by Grafana, no data is available at this time since cn=monitor access also deadlocks) I can see that backload / pending threads and waiters seem to increase gradually until the server gets unresponsive. I found nothing on the ML (except https://www.openldap.org/lists/openldap-technical/200912/msg00112.html) or searching for clues, Is this predictable behavior or and obvious misconfiguration, or it is an interesting occastion to dig a bit deeper ? Thanks in advance, -- Matthieu Cerda Infrastructure, BU Means @ NBS System

2 2

openLDAP with let's encrypt SSL certificate
by Jonas Kellens 01 Jan '18

01 Jan '18

Hello I am trying to configure openLDAP on Centos 6.8 with SSL. LDAP version : @(#) $OpenLDAP: slapd 2.4.40 (May 10 2016 23:30:49) $ mockbuild@worker1.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.40/openldap-2.4.40/build-servers/servers/slapd LDAP service is running with ldaps:// support : ps -ef | grep slap ldap 22182 1 0 20:07 ? 00:00:00 /usr/sbin/slapd -h ldap:/// ldaps:/// ldapi:/// -u ldap root 22193 22118 0 20:07 pts/0 00:00:00 grep slap netstat -plane | grep 636 tcp 0 0 0.0.0.0:636 0.0.0.0:* LISTEN 0 45649460 22182/slapd tcp 0 0 :::636 :::* LISTEN 0 45649461 22182/slapd When I try to do an LDAP search, it fails to connect and the log shows : Dec 31 13:02:12 slap01 slapd[23776]: conn=1119 fd=13 ACCEPT from IP=xx.xx.xx.xx:45426 (IP=0.0.0.0:636) Dec 31 13:02:12 slap01 slapd[23776]: conn=1119 fd=13 closed (TLS negotiation failure) My /etc/openldap/slapd.conf file has the following lines : TLSCACertificateFile /etc/letsencrypt/live/slap01.domain.tld/fullchain.pem TLSCertificateFile /etc/letsencrypt/live/slap01.domain.tld/cert.pem TLSCertificateKeyFile /etc/letsencrypt/live/slap01.domain.tld/privkey.pem What else do I need to make openLDAP work with my let's encrypt SSL-certificate ? I've tried adding : TLSCACertificatePath /usr/share/pki/ca-trust-source But no success. Kind regards Jonas.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical January 2018