openldap-technical February 2021

openldap-technical@openldap.org

20 participants
22 discussions

How to restrict access to operational attributes?
by Uwe Sauter 08 Feb '21

08 Feb '21

Good morning, I'm trying to restrict access to the operational attributes that are provided by the ppolicy overlay (e.g. pwdChangedTime, pwdHistory). When I add the following to my ACL configuration file and try to verify the configuration an error occurs: #### ACL access to attrs=pwdHistory by * none ######## #### slaptest output 601cf554 /etc/openldap/acl.conf: line 96: unknown attr "pwdHistory" in to clause 601cf554 <access clause> ::= access to <what> [ by <who> [ <access> ] [ <control> ] ]+ <what> ::= * | dn[.<dnstyle>=<DN>] [filter=<filter>] [attrs=<attrspec>] <attrspec> ::= <attrname> [val[/<matchingRule>][.<attrstyle>]=<value>] | <attrlist> <attrlist> ::= <attr> [ , <attrlist> ] <attr> ::= <attrname> | @<objectClass> | !<objectClass> | entry | children <who> ::= [ * | anonymous | users | self | dn[.<dnstyle>]=<DN> ] [ realanonymous | realusers | realself | realdn[.<dnstyle>]=<DN> ] [dnattr=<attrname>] [realdnattr=<attrname>] [group[/<objectclass>[/<attrname>]][.<style>]=<group>] [peername[.<peernamestyle>]=<peer>] [sockname[.<style>]=<name>] [domain[.<domainstyle>]=<domain>] [sockurl[.<style>]=<url>] [dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]] [ssf=<n>] [transport_ssf=<n>] [tls_ssf=<n>] [sasl_ssf=<n>] <style> ::= exact | regex | base(Object) <dnstyle> ::= base(Object) | one(level) | sub(tree) | children | exact | regex <attrstyle> ::= exact | regex | base(Object) | one(level) | sub(tree) | children <peernamestyle> ::= exact | regex | ip | ipv6 | path <domainstyle> ::= exact | regex | base(Object) | sub(tree) <access> ::= [[real]self]{<level>|<priv>} <level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage <priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+ <control> ::= [ stop | continue | break ] dynacl: <name>=ACI <pattern>=<attrname> slaptest: bad configuration file! #################### My questions: * How can I restrict access to operational attributes? Does this depend on the specific overlay? * Is this a bug in the ppolicy overlay? One might consider the pwd* attributes confidential but at the same time allowing anonymous queries might be necessary. * Is there anything I miss (besides still using configuration files – they are way easier to handle)? Best, Uwe

5 13

OpenLDAP 2.5.1 ALPHA released
by Quanah Gibson-Mount 08 Feb '21

08 Feb '21

Hello -technical, The second alpha release for the OpenLDAP 2.5 series released today, and the source can be obtained from the download page: <https://www.openldap.org/software/download/> The OpenLDAP 2.5 series contains numerous bug fixes and enhancements. Note that this release includes the new load balancer functionality. A list of issues marked complete for this alpha can be found in Bugzilla: <https://bugs.openldap.org/buglist.cgi?bug_status=VERIFIED&list_id=858&produ…> Any testing in dev/qa/test environments that people can engage in with this alpha would be extremely helpful. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Best way two update a full OpenLDAP database from LDIF file
by Prunk Dump 06 Feb '21

06 Feb '21

Hello ! My network infrastructure uses some special database not compatible with LDAP. But I need an OpenLDAP server to administer my Web Services accounts on my DMZ. So I have written a script to export our "special" database to an LDIF file. This works pretty well. I've successfully loaded it on my OpenLDAP server. But now I don't know how to update my OpenLDAP database from the new generated LDIF files (when users are added, updated or removed) without disturbing the whole LDAP service (it's not a very good idea to delete the entire database and recreate it from the new LDIF file as it stop the service completely during the operation). Is there a way to update an OpenLDAP database to fit a new given LDIF file ? -> Updating/deleting the OUs -> Deleting the objects that are not present. -> Deleting the attributes removed. -> Updating the attributes that have changed without deleting the object. Doing this step by step to disturb as little as possible the OpenLDAP service. Thanks for the help. Regards, Baptiste.

5 6

Re: Upgrade from 2.4.44 to 2.4.55
by Quanah Gibson-Mount 05 Feb '21

05 Feb '21

--On Friday, February 5, 2021 10:51 AM -0800 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > > We use centOS 7 and rely on base repo. > > > openldap-servers-2.4.44-22.el7.x86_64 : LDAP server > Repo : base > > > > openldap-servers-2.4.44-21.el7_6.x86_64 : LDAP server > Repo : @base Symas provides free drop in replacments for the ancient version of OpenLDAP shipped with RHEL7: <https://repo.symas.com/sofl/rhel7/> I suggest using them. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Upgrade from 2.4.44 to 2.4.55
by Quanah Gibson-Mount 05 Feb '21

05 Feb '21

--On Friday, February 5, 2021 10:20 AM -0800 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > > Quanah, > > > We use binaries from OS distribution / repos, i mean do say can i > directly do an inplace upgrade from 2.4.44 to latest version or do i need > to worry about OS related libraries?. Since 2.4.57 is a very young > release I wanted to play safe :) but eventually we will upgrade to .57. > Also if my current installation is using bdb/hdb can i still continue > with those backends with the latest version? If i want to migrate from > bdb/hdb to mdb when upgrading, are there any migration processes for that? What distribution are you using? -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Context CSN timestamp
by Frédéric Goudal 05 Feb '21

05 Feb '21

Hello, I have a strange problem of synchronization, since yesterday my slave servers have a small difference of 2 or 3 minutes with the master. I mean the context CSN of the slave is 3 mn earlier than contextCSN of the master. My first question is the following : how the timestamp of the contextCSN of the slave is computed ? Is it a copy of the tilmestamp from the master ? Or is it based on the localtime of the slaves ? My second question is that maybe such a small difference is « normal » (as the contextCSN of slave is progressing that means that replication is not fully stopped just a bit delayed) and I should only worry for a greater difference of time than one minute. Thanks in advance. Fred

2 1

Re: Upgrade from 2.4.44 to 2.4.55
by Quanah Gibson-Mount 05 Feb '21

05 Feb '21

--On Thursday, February 4, 2021 5:03 PM -0800 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > > Is there any upgrade process to upgrade from 2.4.44 to 2.4.55 ? You should upgrade to 2.4.57. I'm not sure what you mean as far as "upgrade process". Are you using binaries you built yourself? Binaries from a distribution? etc. Generally new dot releases are simply a drop in replacement. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

ldapmodify: wrong attributeType at line N
by Harri T. 05 Feb '21

05 Feb '21

Hi Updating the user attribute "shadowWarning" works fine: # cat tmp4.ldif dn: uid=john,ou=People,dc=example,dc=com changetype: modify replace: shadowWarning shadowWarning: 7 # ldapmodify -H ldapi:/// -D cn=admin,dc=example,dc=com -w ******** -f tmp4.ldif modifying entry "uid=john,ou=People,dc=example,dc=com" When I add the attribute "mail" into ldif the update fails: # cat tmp3.ldif dn: uid=john,ou=People,dc=example,dc=com changetype: modify replace: shadowWarning shadowWarning: 7 replace: mail mail: john.doe(a)example.com # ldapmodify -H ldapi:/// -D cn=admin,dc=example,dc=com -w ******** -f tmp3.ldif ldapmodify: wrong attributeType at line 5, entry "uid=john,ou=People,dc=example,dc=com" What's wrong with the file tmp3.ldif? Kind regards, Harri

4 4

Multi-master provider and delta syncrepl
by paul.jc＠yahoo.com 02 Feb '21

02 Feb '21

Hi all, We are setting up multi-master (3 providers) and are curious if it is recommended to use delta syncrepl between the providers vs standard sync. Currently, we have delta-sync set up between consumers and our single provider. Are there any gotchas with using delta syncrepl for provider-provider replication? I am curious if a new provider is added, does/should the accesslog db get sync'd as well, or does each provider get its own unique accesslog db? And if each accesslog db is unique, how do consumers using delta syncrepl deal with a provider that has sync'd the change in its main db but not in the accesslog? Is this a non-issue if all consumers are aware of all providers and would that mean all consumers have to sync from all providers? I'm sure the answer to this is clear but I am missing it in the docs. Any input or clarification is appreciated. Thanks! Paul

2 1

Unable to bind with LDAP DN having encoded chars
by radiatejava 02 Feb '21

02 Feb '21

I am using openldap client library 2.4.44 on Centos 7.3, LDAP v3 setting. I am having an issue with LDAP bind when the DN has encoded representation of special characters like é (e acute). Actual DN is CN=mithun,OU=Groupes de Sécurité,DC=mytest,DC=net and when it is sent by the app (frontend) to our backend, it is coming as CN=mithun,OU=Groupes de S\u00e9curit\u00e9,DC=insaaadev,DC=net. Basically, é comes encoded as \u00e9 which is as per the encoding mentioned here https://www.fileformat.info/info/unicode/char/e9/index.htm To further try out, I directly hardcoded the DN to CN=mithun,OU=Groupes de S\u00e9curit\u00e9,DC=mytest,DC=net and that worked fine. I want to understand why it fails when the DN in the same format comes from the frontend app. Appreciate your help, thanks.

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical February 2021