Extensible filters and substring searches
by Côme Chilliet
Hello,
I’m trying to understand if it is possible or not to do a substring search on an attribute which does not specify a substring matching rule.
I was expecting to be able to use an extensible filter and specify the sub matching rule to use, but it does not seem to work ldapsearch says "ldap_search_ext: Bad search filter (-7)" as soon as the filter contains an asterisk.
And indeed reading https://tools.ietf.org/html/rfc4515 it does look like extensible filter does not allow asterisk, but it is surprising to me.
Is there really no way to do an extensible search on a substring?
I found some examples on the web of such filters, like here: http://www.zytrax.com/books/ldap/apa/search.html
They give these examples:
> # override SUBSTR match with case sensitive match
> sn:caseExactSubstringMatch:=*S* # only finds Smith
> # functionally same as above using OID
> sn:2.5.13.7:=*S*
But these do not work if I try them in ldapsearch I get bad search filter.
Côme
4 years, 3 months
How to correctly import schemas?
by Jens Bürger
Dear people of OpenLDAP,
I have a Univention Corporate Server (UCS) running at a local site, with a well-populated LDAP.
I have a VM on the Internet, providing some web services.
I’d like to just clone the LDAP data from the local UCS machine to the VM regularly.
While copying the database is a no-brainer (scp & ssh-key), I currently fail at importing the UCS-specific LDAP schemas into the LDAP of the VM. The schema conversion created a {0}core.ldif as starting point. Importing this into openldap failed because I have not the right to modification to core (of course).
Any hints?
Kind regards,
Jens
4 years, 3 months
Help need with replication
by John C. Pfeifer
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
4 years, 3 months
Re: accesslog database: overflow or data rotation?
by Manuela Mandache
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 years, 3 months
Re: Extensible filters and substring searches
by Côme Chilliet
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
4 years, 3 months
schema errors with slapcat with custom schema?
by Christopher Wood
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
4 years, 4 months
OPEN LDAP ACL
by Florent Vallée
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
4 years, 4 months
ObjectClass auxiliary - Beginner's question
by Olivier -
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.
4 years, 4 months
Re: accesslog database: overflow or data rotation?
by Manuela Mandache
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
>
>
4 years, 4 months
Re: accesslog database: overflow or data rotation?
by Manuela Mandache
Le mar. 14 mai 2019 19:31, Quanah Gibson-Mount <quanah(a)symas.com> a écrit :
> --On Tuesday, May 14, 2019 8:03 PM +0200 Dieter Kluenter
> <dieter(a)dkluenter.de> wrote:
>
> >> olcDbMaxSize defined for this database? Thanks!
> >
> > Depending on the number of operations you may set logpurge to a
> > appropriate value.
>
> Yeah, I think the question is, what happens if you have so many operations
> in an <interval> that it maxes out the DB, where the interval is smaller
> than the logpurge interval.
Hi all,
Thank you Quanah for your answers (and Dieter too, it seems :)). This was
indeed the question.
But it's a good point, one could (if using
> cn=config) do an on-the-fly modification of the logpurge interval so that
> the DB gets purged more frequently to accomodate the rate of change.
>
> --Quanah
>
Would a small logpurge interval strongly influence the system's
performance?
If it would, a both ways on-the-fly change based on automatic watch of the
actual size of the accesslog database might be interesting if the high rate
writes are a seldom event.
If it wouldn't, setting a small enough interval from the beggining would do
the trick.
Regards,
Manuela
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
>
4 years, 4 months