openldap-technical

openldap-technical@openldap.org

18 participants
9897 discussions

Adding an Entry Outside the DIT
by A. Yuesuen 05 Jun '19

05 Jun '19

Hello, I have to work with a Shadow Server of my Company Ldap Server. And they are using for the authentication the Entry with the DN uid=zimbra,cn=admins,cn=zimbra but have the Suffic dn: dc=company,dc=com. How i can add a User with the dn uid=zimbra,cn=admins,cn=zimbra when the suffix ends with dn: dc=company,dc=com. Is there a way to add a Entry outside the DIT? best wishes Ajdar

2 1

SHA-2 and other hashes
by Norman Gray 03 Jun '19

03 Jun '19

Greetings. I've been doing some reading on password hashes, in OpenLDAP and elsewhere. It's slightly harder to find explicit details about this, than I expected, and some of what I learned was unexpected to me, though probably familiar to many on this list. In the expectation I'm not the only naive one, I'd like to log these on-list, with a broad query about whether I'm understanding things correctly. There are very good discussions at [1] and [2]. SHA-256/SHA-512 on OpenLDAP doesn't mean the same as what is nominally the same hash function in glibc. In OpenLDAP, the MD5 and SHA-whatever hash of a password is the result of hashing the password plus salt -- ie, pretty much what I expected -- but in glibc's crypt(3), the $5$ and $6$ hashes are the result of an unspecified number of rounds of such hashing (the $1$/MD5 glibc hash does appear to be compatible with OpenLDAP {SMD5}, though). (Quite possibly everyone else in the world already knew this, but I didn't!) While the glibc $5$ and $6$ hashes are therefore, in principle, somewhat resistant to brute-forcing, the OpenLDAP ones are not, and so should be managed as confidential data. MD5 _isn't_ significantly worse than plain SHA-whatever for password hashing, since its discovered defects with respect to collisions are not a problem for this application (it's still resistant to 'preimages'). However both are unsafe for secure password storage, simply because they're too fast (by design), and MD5 is unusable simply because 'everyone knows MD5 is broken', so it would require tedious explanation. Thus it would seem that the SHA-2 support optionally available in the OpenLDAP distribution (in contrib/slapd-modules/passwd/sha2) doesn't actually benefit me much, over and above the MD5 and SHA-1 support available by default. However PBKDF2 (available in contrib/slapd-modules/passwd/pbkdf2) would be usable immediately, though this appears to be not the best such function available. So the two options for password storage seem to be * use {SSHA} and -- as [3] stresses -- protect password attributes as if they were clear text; or * one way or another use a hash-stretching algorithm such as bcrypt (though [4] -- *sigh*) or scrypt [5] (maybe the best option?) or PBKDF2 * (and don't worry about having to protect password attributes?). Is that about right? Is there a consensus OpenLDAP best practice here? Best wishes, Norman [1] https://crackstation.net/hashing-security.htm [2] https://security.stackexchange.com/questions/211/how-to-securely-hash-passw… [3] https://openldap.org/doc/admin24/security.html [4] https://github.com/wclarie/openldap-bcrypt/issues/1 [5] https://github.com/Tarsnap/scrypt -- Norman Gray : https://nxg.me.uk

5 7

Help need with replication
by John C. Pfeifer 03 Jun '19

03 Jun '19

I am setting up a new OpenLDAP (2.4.47) cluster to migrate to from another LDAP product. I am having problems with delta-syncrepl multi-master mirror mode replication. It seems to be fine for a while and then something happens where some of the consumers start having the dreaded “CSN too old” errors. My understanding from the docs is that this ought to get resolved automatically by syncing the whole object…but that never happens. In my testing environment, there are two producers and two read-only consumers. In a recent example, two changes to the same object in within one minute (both change were mad against the same producer. From cn=accesslog (slightly redacted): dn: reqStart=20190520190341.000001Z,cn=accesslog objectclass: auditModify reqdn: uid=xyz,dc=umd,dc=edu reqend: 20190520190341.000002Z reqmod: entryCSN:= 20190520190341.087987Z#000000#001#000000 reqmod: modifyTimestamp:= 20190520190341Z reqresult: 0 reqsession: 7112 reqstart: 20190520190341.000001Z reqtype: modify dn: reqStart=20190520190418.000012Z,cn=accesslog objectclass: auditModify reqdn: uid=xyz,dc=umd,dc=edu reqend: 20190520190418.000013Z reqmod: entryCSN:= 20190520190418.183747Z#000000#001#000000 reqmod: modifyTimestamp:= 20190520190418Z reqresult: 0 reqsession: 7112 reqstart: 20190520190418.000012Z reqtype: modify If I do a search for the entryCSN, both producers have the correct value (having processed both changes)... dn: uid=xyz,dc=umd,dc=edu entrycsn: 20190520190418.183747Z#000000#001#000000 …but the consumers only processed the first change… dn: uid=xyx,dc=umd,dc=edu entrycsn: 20190520190341.087987Z#000000#001#000000 …are failing the second change (from slapd.log): do_syncrep2: rid=001 cookie=rid=001,sid=001,csn=20190520190418.183747Z#000000#001#000000 do_syncrep2: rid=001 CSN too old, ignoring 20190520190418.183747Z#000000#001#000000 (uid=xyz,,dc=umd,dc=edu) I am beginning to despair as to why this keeps happening and how to fix it when it does (short of reloading from a dump). And, yes, the clocks are being kept in sync. I will be the first to admit that I have got myself all turned around trying to get the configs right…and probably have something horribly wrong. Below are the relevant bits. Any advice is greatly appreciated. — CONFIGS — # # these lines are only on the producers # olcServerID: 1 ldap://producer1.umd.edu olcServerID: 2 ldap://producer2.umd.edu dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {2}mdb olcSuffix: dc=umd,dc=edu # # not on producer1 # olcSyncrepl: rid=1 provider=ldaps://producer1.umd.edu type=refreshAndPersist scope=sub searchbase="dc=umd,dc=edu" bindmethod=simple binddn=“SYNC_DN" credentials=“PW" schemachecking=off retry="5 5 300 +" interval=00:00:00:30 timeout=10 keepalive="240:10:30" tls_cert=/etc/openldap/certs/slapd-cert.pem tls_key=/etc/openldap/certs/slapd-key.pem tls_cacert=/etc/openldap/certs/slapd-cacert.pem tls_reqcert=never logbase="cn=accesslog" syncdata=accesslog logfilter="(&(objectClass=auditWriteObject)(reqResult=0))” # # not on producer2 # olcSyncrepl: rid=2 provider=ldaps://producer2.umd.edu type=refreshAndPersist scope=sub searchbase="dc=umd,dc=edu" bindmethod=simple binddn=“SYNC_DN" credentials=“PW" schemachecking=off retry="5 5 300 +" interval=00:00:00:30 timeout=10 keepalive="240:10:30" tls_cert=/etc/openldap/certs/slapd-cert.pem tls_key=/etc/openldap/certs/slapd-key.pem tls_cacert=/etc/openldap/certs/slapd-cacert.pem tls_reqcert=never logbase="cn=accesslog" syncdata=accesslog logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" olcUpdateRef: ldaps://master.main.eng.directory.it-eng-aaa.aws.umd.edu # # on producers, this is set to TRUE # olcMirrorMode: FALSE dn: olcOverlay={0}syncprov,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckPoint: 100 10 olcSpSessionlog: 250000 olcSpNoPresent: TRUE olcSpReloadHint: TRUE dn: olcOverlay={1}accesslog,olcDatabase={2}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE olcAccessLogPurge: 5+00:00 1+00:00 dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {3}mdb olcSuffix: cn=accesslog olcDbDirectory: /var/lib/ldap/accesslog olcDbMaxReaders: 126 olcDbSearchStack: 16 olcDbMaxSize: 10000000000 dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcSpCheckPoint: 100 1 olcSpNoPresent: TRUE olcSpReloadHint: TRUE olcSpSessionlog: 250000 // John Pfeifer Division of Information Technology University of Maryland, College Park

3 11

Updating slapd configuration programmatically
by Michel Gokan 03 Jun '19

03 Jun '19

I'm using slapd-mdb <http://manpages.courier-mta.org/htmlman5/slapd-mdb.5.html> and I'm looking for a way to programmatically update "maxsize" parameter using ldapmodify or similar. My main problem is that I have a huge dataset and I need more space. Any suggestions on how to update OpenLDAP configuration programmatically would be appreciated. My environment is Kubernetes and I deployed OpenLDAP as a container. I’ve also asked this question here: https://stackoverflow.com/questions/56373598/openldap-updating-slapd-config…

2 1

Re: accesslog database: overflow or data rotation?
by Manuela Mandache 30 May '19

30 May '19

Le mer. 15 mai 2019 19:52, Quanah Gibson-Mount <quanah(a)symas.com> a écrit : > --On Wednesday, May 15, 2019 8:23 PM +0200 Manuela Mandache > <manuela.mandache.mm(a)gmail.com> wrote: > > > Actually, the replication is in refreshAndPersist mode. > > Replication mode is immaterial. > Quanah, Thanks a lot for your detailed and comprehensive answers. Best regards, Manuela > >

4 8

Re: Extensible filters and substring searches
by Côme Chilliet 27 May '19

27 May '19

Le lundi 27 mai 2019, 07:45:34 CEST Quanah Gibson-Mount a écrit : > That's an IA5 string, so use either: > > caseExactIA5SubstringsMatch > or > caseIgnoreIA5SubstringsMatch > > I.e., the matching rules should match the syntax. So what would the syntax be? Because I get the error posted earlier anyway: >ldapsearch [options] "(ipHostNumber:1.3.6.1.4.1.1466.109.114.3:=10.*)" dn ># extended LDIF ># ># LDAPv3 ># base <dc=ecolo,dc=lan> with scope subtree ># filter: (ipHostNumber:1.3.6.1.4.1.1466.109.114.3:=10.*) ># requesting: dn ># > >ldap_search_ext: Bad search filter (-7) Côme

2 1

schema errors with slapcat with custom schema?
by Christopher Wood 22 May '19

22 May '19

I ran into ITS#8100 (replication item) with 2.4.45 and went to upgrade; one of the pre-upgrade slapcats complained about schema errors. The odd part is that the schema does indeed exist under cn=schema,cn=config and the attributes in question do exist in the resulting ldif. I was unable to find any reference to similar behaviour via ITS or Google search. Does this ring a bell with anybody? Does this have any implications for a subsequent slapadd after upgrading my custom-compiled openldap rpm? Will this affect future OpenLDAP upgrades? Have I missed a manpage?? Background and more details as follows. This is how I found out about ITS#8100: https://www.openldap.org/lists/openldap-technical/201706/msg00078.html https://www.openldap.org/its/index.cgi/Software%20Bugs?id=8100 The schema I had added: https://github.com/credativ/postfix-ldap-schema Adding the custom schema went fine apart from the replication issue: ---------- dn: cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.200 NAME 'mailacceptinggeneralid' DESC 'Postfix mail local address alias attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) olcAttributeTypes: ( 1.3.6.1.4.1.4203.666.1.201 NAME 'maildrop' DESC 'Postfix mail final destination attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) - add: olcObjectClasses olcObjectClasses: ( 1.3.6.1.4.1.4203.666.1.100 NAME 'postfixUser' DESC 'Postfix mail user class' SUP top AUXILIARY MAY ( mailacceptinggeneralid $ maildrop )) modifying entry "cn=schema,cn=config" ---------- The custom bits are indeed in the directory: [root@mailhost man]# /opt/openldap/bin/ldapsearch -D cn=config -W -s sub -b cn=schema,cn=config -o ldif-wrap=no | egrep 'postfixUser|maildrop|mailacceptinggeneralid' Enter LDAP Password: olcAttributeTypes: {245}( 1.3.6.1.4.1.4203.666.1.200 NAME 'mailacceptinggeneralid' DESC 'Postfix mail local address alias attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) olcAttributeTypes: {246}( 1.3.6.1.4.1.4203.666.1.201 NAME 'maildrop' DESC 'Postfix mail final destination attribute' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) olcObjectClasses: {49}( 1.3.6.1.4.1.4203.666.1.100 NAME 'postfixUser' DESC 'Postfix mail user class' SUP top AUXILIARY MAY ( mailacceptinggeneralid $ maildrop )) slapschema thinks something is odd, although I can ldapsearch and retrieve entries with these attributes just fine: [root@mailhost man]# /opt/openldap/sbin/slapschema -bdc=me -F/opt/openldap/etc/openldap/slapd.d 5ce5693b UNKNOWN attributeDescription "MAILACCEPTINGGENERALID" inserted. 5ce5693b UNKNOWN attributeDescription "MAILDROP" inserted. # (65) Object class violation: unrecognized objectClass 'postfixUser' dn: uid=mail1,dc=fake1.example,dc=me # (65) Object class violation: unrecognized objectClass 'postfixUser' dn: cn=mail1(a)somedomain.com,dc=fake1.example,dc=me slapcat only reports the attribute item, but not the objectClass item: [root@mailhost man]# /opt/openldap/sbin/slapcat -bdc=me -F/opt/openldap/etc/openldap/slapd.d -l'/var/tmp/dc=me.ldif' 5ce55367 UNKNOWN attributeDescription "MAILACCEPTINGGENERALID" inserted. 5ce55367 UNKNOWN attributeDescription "MAILDROP" inserted. For completeness, here's showing that the custom schema exists in the exports. Pardon the redactions, not listing people's names save for myself in a list post. [root@mailhost man]# egrep -i 'postfixUser|maildrop|mailacceptinggeneralid' /var/tmp/dc\=me.ldif | cut -d: -f1 objectClass MAILACCEPTINGGENERALID MAILACCEPTINGGENERALID MAILDROP MAILDROP objectClass MAILACCEPTINGGENERALID MAILACCEPTINGGENERALID MAILDROP MAILDROP [root@mailhost man]# egrep -i 'postfixUser|maildrop|mailacceptinggeneralid' /var/tmp/cn\=config.ldif olcAttributeTypes: {1}( 1.3.6.1.4.1.4203.666.1.201 NAME 'maildrop' DESC 'Pos olcObjectClasses: {0}( 1.3.6.1.4.1.4203.666.1.100 NAME 'postfixUser' DESC 'P ostfix mail user class' SUP top AUXILIARY MAY ( mailacceptinggeneralid $ ma

3 3

OPEN LDAP ACL
by Florent Vallée 21 May '19

21 May '19

Hello, I manage all my users with LDAP. I would like to build the following reading rules: 1. only admin can change passwords, authenticated users read and anonymous do nothing 2. Authenticated users access the database but can only read their account but not the rest 3. the group ou = system-read can read the whole database 4. the group ou = system-write can write in ou = ent 5. Anonymous access is forbidden My LDIF file : dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to attrs=userPassword by self write by dn="cn=admin,dc=example,dc=fr" write by * auth olcAccess: {1}to dn.base="" by self write by dn="ou=system-read,dc=example,dc=fr" read by * auth olcAccess: {2}to dn.subtree="ou=ent,dc=example,dc=fr" by self write by dn="ou=system-write,dc=example,dc=fr" write by * none olcAccess: {3}to * by self write by dn="cn=admin,dc=example,dc=fr" write by * none I have a lot of trouble with ACLs, I can not do what I want with. Thank you for your help. Florent

3 3

ObjectClass auxiliary - Beginner's question
by Olivier - 21 May '19

21 May '19

Hi all, I have to re-write a shcema but i'm beginner with this. I would like to add some attributes to describe service. We use a AUXILIARY class to add some attributes : objectclass ( 1.2.250.1.152.14.2.1.2 NAME 'intService' SUP top AUXILIARY MAY (...)) We have an object using this objectclass and other : dn: idService=196018, dmdName=Services, dc=fr objectClass: intService objectClass: organizationalUnit Now i would like to transform this object in static group so I use GroupOfnames and I got this error : Object class violation (65) additional info: invalid structural object class chain (organizationalUnit/groupOfNames) Why can't I use groupOfNames with organizationalUnit ? Or is it another problem ? Thanks a lot.

2 1

Re: accesslog database: overflow or data rotation?
by Manuela Mandache 15 May '19

15 May '19

Le mer. 15 mai 2019 22:42, Quanah Gibson-Mount <quanah(a)symas.com> a écrit : > --On Wednesday, May 15, 2019 10:37 PM +0200 Manuela Mandache > <manuela.mandache.mm(a)gmail.com> wrote: > > > > > > > > > > > > > > > Le mer. 15 mai 2019 19:52, Quanah Gibson-Mount <quanah(a)symas.com> a > > écrit : > > > > --On Wednesday, May 15, 2019 8:23 PM +0200 Manuela Mandache > > <manuela.mandache.mm(a)gmail.com> wrote: > > > >>> Actually, the replication is in refreshAndPersist mode. > >> > >> Replication mode is immaterial. > > > Thanks a lot for your detailed and comprehensive answers. > > Heh, I can't tell in this case if your serious or sarcastic, but I'll note > this: it's entirely possible (and legal, and there are valid reasons for > it) to have an accesslog for a database where the environment is not > replicated at all. So replication mode, etc, is utterly immaterial to > whether or not an accesslog may exist, what its purge interval is, etc. > If > that helps. :) > Oh dear, I was totally serious, meaning to thank you for your three answers in one go. I might have been too formal, to the point of making you doubt - sorry, English is not my mother tongue and I live in France... Now that you mention it, I did read somewhere in the web-wide documentation that the delta-syncrepl is only one of the possible uses for the accesslog DB. And thanks again (seriously ;)) Manuela > >

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