RE: el9 bind ip address

[Marc]

> 
> > I don't really get what is wrong with how it was:
> >
> > "As I mentioned already, use systemd drop-in file (see `man 5
> > systemd.unit` for more details). Or use `systemctl edit --full
> > slapd.service`."
> 
> 
> As previously mentioned, you will need to ask RedHat their reasoning.
> 

The quote is part of the answer of redhat. I am not sure if it makes sense to 
ask any further there. Especially since I am not really familiar with this 
transition wanting to run everything via this systemd.

RE: el9 bind ip address

[Marc]

I don't really get what is wrong with how it was:

"As I mentioned already, use systemd drop-in file (see `man 5 systemd.unit` for 
more details).
Or use `systemctl edit --full slapd.service`."

> 
> in RedHat 7 the file /usr/lib/systemd/system/slapd.service contains:
> 
> ExecStart=/usr/sbin/slapd -u ldap -h ${SLAPD_URLS} $SLAPD_OPTIONS
> 
> In RedHat 9 the file /usr/lib/systemd/system/slapd.service contains:
> 
> ExecStart=/usr/sbin/slapd -u ldap -h "ldap:/// ldaps:/// ldapi:///"
> 
> So the urls are directly configured there and not via a variable. The
> file /etc/sysconfig/slapd doesn't exist.
> 
> Am 21.05.2024 um 00:10 schrieb Marc:
> >>> Anyone know if this file is still working in el9? Looks like if I put
> >> SLAPD_URLS it is not read.
> >>>
> >>> /etc/sysconfig/slapd
> >>>
> >> That's a question for Red Hat. No one on the OpenLDAP Project has
> >> anything to do with that.
> >>
> >
> > Yes I already reported it (I think) don't even know where to report for
> el9 at this bugzilla. Just wondering if I was crazy or others noticed the
> same.
> 
> --
> Viele Gruesse,
> 
> Dirk Kastens
> Universitaet Osnabrueck, Rechenzentrum (Computer Center)
> Nelson-Mandela-Str. 4, 49076 Osnabrueck, Germany
> Tel.: +49-541-969-2347, FAX: -2470

RE: el9 bind ip address

[Marc]

> > Anyone know if this file is still working in el9? Looks like if I put
> SLAPD_URLS it is not read.
> >
> > /etc/sysconfig/slapd
> >
> That's a question for Red Hat. No one on the OpenLDAP Project has
> anything to do with that.
> 

Yes I already reported it (I think) don't even know where to report for el9 at 
this bugzilla. Just wondering if I was crazy or others noticed the same.

RE: How to setup replication in openldap 2.6.7

[Marc]

> 
> How to setup replication in openldap 2.6.7
> Please let me know

:) you have to give the manuals a try. You have to decide also what replication 
type you choose. I am still having the old one

add: olcSyncrepl
olcSyncrepl: {0}rid=..

el9 bind ip address

[Marc]

Anyone know if this file is still working in el9? Looks like if I put 
SLAPD_URLS it is not read.

/etc/sysconfig/slapd

RE: ldclt ldap performance testing

[Marc]

> 
> >
> > > I am doing some basic testing with ldap with this command.
> > >
> > > ldclt \
> > > -a 400 \
> > > -H ldap://x.x.x.x: \
> > > -e bindeach,bindonly,close \
> > > -D "uid=test,dc=me,dc=local" \
> > > -w yy \
> > > -n 1
> > >
> > > I was testing this on two container test environments. Both are
> running
> > > with ~500MB, 1 core.
> > >
> > > 1. alpine - slapd 2.6.3, mdb still with default slapd.conf
> > > ldclt[5594]: Average rate: 12627.00/thr  (1262.70/sec), total:  12627
> > > ldclt[5594]: Average rate:0.00/thr  (   0.00/sec), total:  0
> > > ldclt[5594]: All threads are dead - exit.
> > >
> > > 2. alpine - slapd 2.6.6, mdb configured with acl's, ssl, modules etc.
> > > ldclt[8900]: Average rate: 1495.00/thr  ( 149.50/sec), total:   1495
> > > ldclt[8900]: Average rate: 1498.00/thr  ( 149.80/sec), total:   1498
> > > ldclt[8900]: Average rate: 1490.00/thr  ( 149.00/sec), total:   1490
> > >
> > > What should I be expecting from this? It looks like maybe slapd of 1.
> > is
> > > not 100% with this 'threads are dead' messages. While slapd of 2.
> with
> > > 150 req/sec is that to be expected normal?
> >
> > Doing a search on self gives me values that I would expect more (2
> being
> > faster than 1)
> >
> > -e esearch \
> > -f '(&(objectClass=)(cn=test))' \
> > -D "cn=test,dc=me,dc=local" \
> > -b "cn=test,dc=me,dc=local" \
> >
> > 1.
> > ldclt[8415]: Average rate: 54358.00/thr  (5435.80/sec), total:  54358
> > ldclt[8415]: Average rate: 53850.00/thr  (5385.00/sec), total:  53850
> > ldclt[8415]: Average rate: 53957.00/thr  (5395.70/sec), total:  53957
> > ldclt[8415]: Average rate: 54594.00/thr  (5459.40/sec), total:  54594
> >
> > 2.
> > ldclt[8223]: Average rate: 90102.00/thr  (9010.20/sec), total:  90102
> > ldclt[8223]: Average rate: 93745.00/thr  (9374.50/sec), total:  93745
> > ldclt[8223]: Average rate: 92066.00/thr  (9206.60/sec), total:  92066
> > ldclt[8223]: Average rate: 91523.00/thr  (9152.30/sec), total:  91523
> > ldclt[8223]: Average rate: 96301.00/thr  (9630.10/sec), total:  96301
> >
> > Any ideas why these binds on 2. could be so slow?
> >
> >
> 
> >  Binds are always going to be
> > slower than other operations since they involve things such as TLS (if
> > used), DNS, and other items.  Well written LDAP clients bind, and then
> > use
> > a persistent connection to do their operations.
> 
> I just searched a bit and did some requests on https files and it looks
> like most are reporting results between 100 - 200. So I guess this is
> sort of ok.

So probably it would be faster if I authenticate users via a 'manager' bind and 
wich has access to user dn/passwords? Or is it possible to use an existing bind 
and 'switch' to a different user bind?

RE: ldclt ldap performance testing

[Marc]

> 
> > I am doing some basic testing with ldap with this command.
> >
> > ldclt \
> > -a 400 \
> > -H ldap://x.x.x.x: \
> > -e bindeach,bindonly,close \
> > -D "uid=test,dc=me,dc=local" \
> > -w yy \
> > -n 1
> >
> > I was testing this on two container test environments. Both are running
> > with ~500MB, 1 core.
> >
> > 1. alpine - slapd 2.6.3, mdb still with default slapd.conf
> > ldclt[5594]: Average rate: 12627.00/thr  (1262.70/sec), total:  12627
> > ldclt[5594]: Average rate:0.00/thr  (   0.00/sec), total:  0
> > ldclt[5594]: All threads are dead - exit.
> >
> > 2. alpine - slapd 2.6.6, mdb configured with acl's, ssl, modules etc.
> > ldclt[8900]: Average rate: 1495.00/thr  ( 149.50/sec), total:   1495
> > ldclt[8900]: Average rate: 1498.00/thr  ( 149.80/sec), total:   1498
> > ldclt[8900]: Average rate: 1490.00/thr  ( 149.00/sec), total:   1490
> >
> > What should I be expecting from this? It looks like maybe slapd of 1.
> is
> > not 100% with this 'threads are dead' messages. While slapd of 2. with
> > 150 req/sec is that to be expected normal?
> 
> Doing a search on self gives me values that I would expect more (2 being
> faster than 1)
> 
> -e esearch \
> -f '(&(objectClass=)(cn=test))' \
> -D "cn=test,dc=me,dc=local" \
> -b "cn=test,dc=me,dc=local" \
> 
> 1.
> ldclt[8415]: Average rate: 54358.00/thr  (5435.80/sec), total:  54358
> ldclt[8415]: Average rate: 53850.00/thr  (5385.00/sec), total:  53850
> ldclt[8415]: Average rate: 53957.00/thr  (5395.70/sec), total:  53957
> ldclt[8415]: Average rate: 54594.00/thr  (5459.40/sec), total:  54594
> 
> 2.
> ldclt[8223]: Average rate: 90102.00/thr  (9010.20/sec), total:  90102
> ldclt[8223]: Average rate: 93745.00/thr  (9374.50/sec), total:  93745
> ldclt[8223]: Average rate: 92066.00/thr  (9206.60/sec), total:  92066
> ldclt[8223]: Average rate: 91523.00/thr  (9152.30/sec), total:  91523
> ldclt[8223]: Average rate: 96301.00/thr  (9630.10/sec), total:  96301
> 
> Any ideas why these binds on 2. could be so slow?
> 
> 

>  Binds are always going to be
> slower than other operations since they involve things such as TLS (if
> used), DNS, and other items.  Well written LDAP clients bind, and then
> use
> a persistent connection to do their operations.

I just searched a bit and did some requests on https files and it looks like 
most are reporting results between 100 - 200. So I guess this is sort of ok. 

RE: cache userPassword with bind

[Marc]

> 
> > Am just testing with an alpine linux container and an ldap db with ~10
> > entries, almost nothing. Yet when I look in top res memory is 700MB. So
> I
> > assume everything is already cached, but I don't really get then this
> > logging. I don't even get why 700MB is being used, my data is probably
> 
> > few 100KB.
> 
> It's the ACL cache, which is internal and you have no control over.

oh ok that makes sense.

> You've provided virtually no information on your environment's
> configuration for slapd.  I would note that if you're seeing "result not
> in
> cache" then you have your logging level turned up insanely high on the
> server, which will slow down everything.
> 

I am just testing if some application is efficiently authenticating with a 
simple bind (and not doing searches) In a later stage I would like to maybe 
optimize authenticating against ldap with credential caching.  When I saw this 
I just thought I could do something with it. (In another thread I posted about 
having binds max out at 150req/s, while searches are ~9000req/s)

RE: cache userPassword with bind

[Marc]

> >
> > > > I am testing a bit with bind's. With consecutive binds with the
> same
> > > test account I always get 'result not in cache'. How can I get this
> in
> > > cache?
> > > >
> > > > access_allowed: result not in cache (userPassword)
> > > >
> > > > 6628dba5.0659c27a 0x7ff072843b38 conn=1023 op=0 BIND
> > > dn="uid=test,dc=me,dc=local" method=128
> > > > 6628dba5.0660ea46 0x7ff072843b38 => access_allowed: result not in
> > cache
> > > (userPassword)
> > > > 6628dba5.066470b9 0x7ff072843b38 => access_allowed: auth access to
> > > "uid=test,dc=me,dc=local " "userPassword" requested
> > > > 6628dba5.0667703c 0x7ff072843b38 => slap_access_allowed: backend
> > > default auth access granted to "(anonymous)"
> > > > 6628dba5.0668099f 0x7ff072843b38 => access_allowed: auth access
> > granted
> > > by read(=rscxd)
> > >
> > >
> > > I think you need to index the userPassword attribute. For that you
> need
> > > to add the appropriate
> > > olcDBIndex entry to your database configuration.
> > >
> > >
> >
> https://www.openldap.org/doc/admin26/guide.html#MDB%20Database%20Directiv
> > > es
> >
> > After doing this :
> >
> > mv slapd.ldif slapd.ldif.bak
> >
> > adding to the mdb section in slapd.conf
> > index   userPasswordpres,eq
> >
> > /etc/openldap # slapindex userPassword
> > /etc/openldap # echo $?
> > 0
> >
> > I am still getting this
> > access_allowed: result not in cache (userPassword)
> >
> 
> Or is this related to adding openldap-overlay-proxycache ?

Am just testing with an alpine linux container and an ldap db with ~10 entries, 
almost nothing. Yet when I look in top res memory is 700MB. So I assume 
everything is already cached, but I don't really get then this logging. I don't 
even get why 700MB is being used, my data is probably a few 100KB. 

RE: cache userPassword with bind

[Marc]

> 
> > > I am testing a bit with bind's. With consecutive binds with the same
> > test account I always get 'result not in cache'. How can I get this in
> > cache?
> > >
> > > access_allowed: result not in cache (userPassword)
> > >
> > > 6628dba5.0659c27a 0x7ff072843b38 conn=1023 op=0 BIND
> > dn="uid=test,dc=me,dc=local" method=128
> > > 6628dba5.0660ea46 0x7ff072843b38 => access_allowed: result not in
> cache
> > (userPassword)
> > > 6628dba5.066470b9 0x7ff072843b38 => access_allowed: auth access to
> > "uid=test,dc=me,dc=local " "userPassword" requested
> > > 6628dba5.0667703c 0x7ff072843b38 => slap_access_allowed: backend
> > default auth access granted to "(anonymous)"
> > > 6628dba5.0668099f 0x7ff072843b38 => access_allowed: auth access
> granted
> > by read(=rscxd)
> >
> >
> > I think you need to index the userPassword attribute. For that you need
> > to add the appropriate
> > olcDBIndex entry to your database configuration.
> >
> >
> https://www.openldap.org/doc/admin26/guide.html#MDB%20Database%20Directiv
> > es
> 
> After doing this :
> 
> mv slapd.ldif slapd.ldif.bak
> 
> adding to the mdb section in slapd.conf
> index   userPasswordpres,eq
> 
> /etc/openldap # slapindex userPassword
> /etc/openldap # echo $?
> 0
> 
> I am still getting this
> access_allowed: result not in cache (userPassword)
> 

Or is this related to adding openldap-overlay-proxycache ?

RE: cache userPassword with bind

[Marc]

> > I am testing a bit with bind's. With consecutive binds with the same
> test account I always get 'result not in cache'. How can I get this in
> cache?
> >
> > access_allowed: result not in cache (userPassword)
> >
> > 6628dba5.0659c27a 0x7ff072843b38 conn=1023 op=0 BIND
> dn="uid=test,dc=me,dc=local" method=128
> > 6628dba5.0660ea46 0x7ff072843b38 => access_allowed: result not in cache
> (userPassword)
> > 6628dba5.066470b9 0x7ff072843b38 => access_allowed: auth access to
> "uid=test,dc=me,dc=local " "userPassword" requested
> > 6628dba5.0667703c 0x7ff072843b38 => slap_access_allowed: backend
> default auth access granted to "(anonymous)"
> > 6628dba5.0668099f 0x7ff072843b38 => access_allowed: auth access granted
> by read(=rscxd)
> 
> 
> I think you need to index the userPassword attribute. For that you need
> to add the appropriate
> olcDBIndex entry to your database configuration.
> 
> https://www.openldap.org/doc/admin26/guide.html#MDB%20Database%20Directiv
> es

After doing this :

mv slapd.ldif slapd.ldif.bak

adding to the mdb section in slapd.conf
index   userPasswordpres,eq

/etc/openldap # slapindex userPassword
/etc/openldap # echo $?
0

I am still getting this 
access_allowed: result not in cache (userPassword)

cache userPassword with bind

[Marc]

I am testing a bit with bind's. With consecutive binds with the same test 
account I always get 'result not in cache'. How can I get this in cache?

access_allowed: result not in cache (userPassword)

6628dba5.0659c27a 0x7ff072843b38 conn=1023 op=0 BIND 
dn="uid=test,dc=me,dc=local" method=128
6628dba5.0660ea46 0x7ff072843b38 => access_allowed: result not in cache 
(userPassword)
6628dba5.066470b9 0x7ff072843b38 => access_allowed: auth access to 
"uid=test,dc=me,dc=local " "userPassword" requested
6628dba5.0667703c 0x7ff072843b38 => slap_access_allowed: backend default auth 
access granted to "(anonymous)"
6628dba5.0668099f 0x7ff072843b38 => access_allowed: auth access granted by 
read(=rscxd)

RE: ldclt ldap performance testing

[Marc]

> I am doing some basic testing with ldap with this command.
> 
> ldclt \
> -a 400 \
> -H ldap://x.x.x.x: \
> -e bindeach,bindonly,close \
> -D "uid=test,dc=me,dc=local" \
> -w yy \
> -n 1
> 
> I was testing this on two container test environments. Both are running
> with ~500MB, 1 core.
> 
> 1. alpine - slapd 2.6.3, mdb still with default slapd.conf
> ldclt[5594]: Average rate: 12627.00/thr  (1262.70/sec), total:  12627
> ldclt[5594]: Average rate:0.00/thr  (   0.00/sec), total:  0
> ldclt[5594]: All threads are dead - exit.
> 
> 2. alpine - slapd 2.6.6, mdb configured with acl's, ssl, modules etc.
> ldclt[8900]: Average rate: 1495.00/thr  ( 149.50/sec), total:   1495
> ldclt[8900]: Average rate: 1498.00/thr  ( 149.80/sec), total:   1498
> ldclt[8900]: Average rate: 1490.00/thr  ( 149.00/sec), total:   1490
> 
> What should I be expecting from this? It looks like maybe slapd of 1. is
> not 100% with this 'threads are dead' messages. While slapd of 2. with
> 150 req/sec is that to be expected normal?

Doing a search on self gives me values that I would expect more (2 being faster 
than 1)

-e esearch \
-f '(&(objectClass=)(cn=test))' \
-D "cn=test,dc=me,dc=local" \
-b "cn=test,dc=me,dc=local" \

1.
ldclt[8415]: Average rate: 54358.00/thr  (5435.80/sec), total:  54358
ldclt[8415]: Average rate: 53850.00/thr  (5385.00/sec), total:  53850
ldclt[8415]: Average rate: 53957.00/thr  (5395.70/sec), total:  53957
ldclt[8415]: Average rate: 54594.00/thr  (5459.40/sec), total:  54594

2.
ldclt[8223]: Average rate: 90102.00/thr  (9010.20/sec), total:  90102
ldclt[8223]: Average rate: 93745.00/thr  (9374.50/sec), total:  93745
ldclt[8223]: Average rate: 92066.00/thr  (9206.60/sec), total:  92066
ldclt[8223]: Average rate: 91523.00/thr  (9152.30/sec), total:  91523
ldclt[8223]: Average rate: 96301.00/thr  (9630.10/sec), total:  96301

Any ideas why these binds on 2. could be so slow?

ldclt ldap performance testing

[Marc]

I am doing some basic testing with ldap with this command. 

ldclt \
-a 400 \
-H ldap://x.x.x.x: \
-e bindeach,bindonly,close \
-D "uid=test,dc=me,dc=local" \
-w yy \
-n 1

I was testing this on two container test environments. Both are running with 
~500MB, 1 core.

1. alpine - slapd 2.6.3, mdb still with default slapd.conf
ldclt[5594]: Average rate: 12627.00/thr  (1262.70/sec), total:  12627
ldclt[5594]: Average rate:0.00/thr  (   0.00/sec), total:  0
ldclt[5594]: All threads are dead - exit.

2. alpine - slapd 2.6.6, mdb configured with acl's, ssl, modules etc.
ldclt[8900]: Average rate: 1495.00/thr  ( 149.50/sec), total:   1495
ldclt[8900]: Average rate: 1498.00/thr  ( 149.80/sec), total:   1498
ldclt[8900]: Average rate: 1490.00/thr  ( 149.00/sec), total:   1490

What should I be expecting from this? It looks like maybe slapd of 1. is not 
100% with this 'threads are dead' messages. While slapd of 2. with 150 req/sec 
is that to be expected normal?

Re: Accesslog requirement for sync replication

[Marc Franquesa]

Missatge de Ondřej Kuzník  del dia dt., 30 de gen.
2024 a les 16:19:

> are you running with syncprov-reloadhint by any chance? It's just a
> warning that syncprov might consider using the attribute but it's not
> defined. I've just moved the check to syncprov-nopresent[0] which
> doesn't really have any uses without an accesslog DB being around.


You're right, I realized that I had the Reloadhint setting to true. Once
disabled my issue has gone. Thanks much for pointing.

No need for accesslog if you're doing plain syncrepl.
>

Well, I wanted to use delta-syncrepl, but the small size and changes on my
DIT didn't require it, so I kept as is


> AFAIK people don't usually do deltasync for cn=config).
>

Make sense.

This bring me a new question (which I think I already get replied or found
in some place but now I'm unable to find)

On a multiple replica setup (N-way Multimaster) setup, how does the server
identify itself in the multiple olcSyncrepl attributes to avoid trying to
replicate against itself ?

Thanks much

Accesslog requirement for sync replication

[Marc Franquesa]

Hi

I have been using replication since long time without any issues (and still
without issues), but on recent versions I got this warning on the logs:

syncprov_setup_accesslog: couldn't get definition for attribute reqType, is
accesslog configured?

The answer is no, I never configured accesslog (this why I'm a bit
confused, as I never used/needed on my replication setup). After reviewing
the documentation I understand that for syncrepl I should load and
configure accesslog overlay.

Although I have some questions/concerns I haven't been able to
found/understand from the documentation and would like someone clarifies:

* Is there any way to implement replication without accesslog? (currently I
have it but I would like to not get that warning)

* If I setup accesslog, do I need to setup a different accesslog DIT for
each target DIT I replicate? Or can a single accesslog be shared with 2
different target DITs?

I mean: I'm currently replicating both cn=config (dynamic configuration)
and the main DIT (so 2 different contexts/DITs/trees) Do I need to use a
different accesslog DIT for each one or can they share the same DIT as
accesslog ?

* Does this log DIT needs to be backup up or is simply a log which I could
get rid of in case of recovery?

Any comments, hints or simply answers are welcome

Thanks

RE: openldap-technical mailing list probe message

[Marc]

Any one else getting ~20 messages?

> -Original Message-
> From: openldap-technical-
> bounces+c0b8b5a8faa7db954b532a84b16686b22acfe...@openldap.org  technical-bounces+c0b8b5a8faa7db954b532a84b16686b22acfe...@openldap.org>
> Sent: Friday, 19 January 2024 04:19
> To: Marc 
> Subject: openldap-technical mailing list probe message
> 
> This is a probe message.  You can ignore this message.
> 
> The openldap-technical@openldap.org mailing list has received a number
> of bounces from you, indicating that there may be a problem delivering
> messages to x.  A sample is attached below.
> Please examine this message to make sure there are no problems with
> your email address.  You may want to check with your mail
> administrator for more help.
> 
> You don't need to do anything to remain an enabled member of the
> mailing list.
> 
> If you have any questions or problems, you can contact the mailing
> list owner at
> 
> openldap-technical-ow...@openldap.org

RE: Scaling slapd nodes in Kubernetes with the MDB Backend

[Marc]

 
>   There is a long list of considerations/preparation needed when running
>   OpenLDAP in a container setup (we use Nomad). From memory:
>   - use the HA proxy protocol, now supported in 2.5/2.6 so you see
> client IP's
> 

Is it not enough to just have multiple tasks with different ips on the same 
host/task name. Dns should do the rest, not?

> 
> how does knowledge about the client IP help in containerization ?
> 
> 
>   - DB persistence: make sure each container always has the same db
> files.
> 
> 
> 
> You mean a shared volume across all pods, or that they obtain a updated
> local replica when the pod bootstraps ?
> 

I don't have that many changes to ldap. So it could be sufficient to just work 
with stateless containers. That update on startup.
I have the replication id change automatically on the assigned ip.

> 
> yeah, we have more or less the same design:
> 
> multi AZ, multi-region N-way master replication (one master node per
> Region/AZ). Then auto-scaling groups are read-only slaves handling queries
> and authentications. We use ARGON2 so auths can easily take 3 or more secs
> and goggle up 64MB of RAM each, plus a lot of CPU time.
> 

Using ARGON2 auth takes 3 seconds (was thinking of switching to this)?

RE: Trying to create master/slave solution with syncrepl

[Marc]

> 
> Ok, thank you. I got some error logging and it said:
> 
> Oct 12 19:24:07 openldap2 slapd[1713088]: slap_client_connect:
> URI=ldaps://openldap.plmail.de/ DN="uid=replica,dc=plmail,dc=de"
> ldap_sasl_bind_s failed (-1)
> Oct 12 19:24:07 openldap2 slapd[1713088]: do_syncrepl: rid=001 rc -1
> retrying (1 retries left)
> 
> So, I switched from ldaps to ldap, and suddenly, the synchronozation
> worked.

Ok that is bad, because that means your SSHA is going over a unencrypted 
connection and afaik this ssha can be (easily?) brute forced with something 
like john the ripper (only tried one account of mine, so could be not as bad as 
I write)

> But I have no idea what the the problem with ldaps is.
> Isn't it enough to just write an ldaps uri instead of an ldap uri?

Most likely your cert. If it is self signed make sure you have things like this 
in your ldap.conf, and your hostnames are correct.

TLS_CACERTDIR 
TLS_REQCERT demand

RE: Trying to create master/slave solution with syncrepl

[Marc]

> I am trying to create an OpenLDAP master/slave solution with syncrepl,
> but I have not been successful so far.
> 
> I followed the suggestions of this site, with another sync password:
> 
> https://www.itzgeek.com/how-tos/linux/configure-openldap-master-slave-
> replication.html
> 
> One thing I made different, on the master server, I created the
> replication user with a userPassword: in SSHA-Format instead of clear
> text.

I have clear text (older os), maybe that is it?

> Additionally, I set, following the suggestion of another website:
> 
> olcDbIndex: entryUUID eq
> olcDbIndex: entryCSN eq
> 
> Now, I can see with tcpdump that the slave server contacts the master
> server and that the master server send replies, but no LDAP users are
> synchronized to the slave. 

Maybe acl's? You have to give your sync users access to everything. On the 
other hand if you do not need these accounts on your slaves, it is safer not to 
have this copied ;)

> Unfortunately, nothing about replication is
> logged to syslog, though I started slapd on both master and slave with
> options "-s Sync -c rid=001".

change logging like this or so.

dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: ber sync acl

dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: ber sync acl stats

RE: Unable to ldapadd Kerberos schema in LDIF format

[Marc]

> I'm currently experimenting with (MIT) Kerberos and got to the point where
> I need to add the Kerberos definitions to
> LDAP (krb5-kdc.ldif). (This is on Rocky Linux 9 with symas-openldap-
> servers-2.6.6-1.el9.x86_64.)
> 
> First question: is this the correct schema file or should I use the one
> provided by MIT Kerberos 1.20.1
> (/usr/share/doc/krb5-server-ldap/kerberos.ldif) ?
> 
> 
> If I use krb5-kdc.ldif I get the following:
> 
> [root@gateway ~]# cd /opt/symas/etc/openldap/schema/
> [root@gateway schema]# ldapadd -Y EXTERNAL -H ldapi:/// -f krb5-kdc.ldif
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> adding new entry "cn=krb5-kdc,cn=schema,cn=config"
> ldap_add: Constraint violation (19)
>  additional info: structuralObjectClass: no user modification
> allowed
> 

This is what works (recently tested) when I create containers, see if this one 
works (this is everything on one line)

ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f sendmail.ldif


dn: cn=sendmail,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: sendmail
olcAttributeTypes: {0}( 1.3.6.1.4.1.6152.10.3.1.10 NAME 'sendmailMTACluster' 
DESC 'cluster name associated with a set of MTAs' EQUALITY caseIgnoreIA5Match 
SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
olcAttributeTypes: {1}( 1.3.6.1.4.1.6152.10.3.1.11 NAME 'sendmailMTAHost' DESC 
'host name associated with a MTA cluster' EQUALITY caseIgnoreIA5Match SUBSTR 
caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
olcAttributeTypes: {2}( 1.3.6.1.4.1.6152.10.3.1.13 NAME 'sendmailMTAKey' DESC 
'key (left hand side) of an aliases or map entry' EQUALITY caseIgnoreMatch 
SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
olcAttributeTypes: {3}( 1.3.6.1.4.1.6152.10.3.1.14 NAME 'sendmailMTAMapName' 
DESC 'identifier for the particular map' EQUALITY caseIgnoreMatch SYNTAX 
1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE )
olcAttributeTypes: {4}( 1.3.6.1.4.1.6152.10.3.1.16 NAME 'sendmailMTAMapValue' 
DESC 'value (right hand side) of a map entry' EQUALITY caseIgnoreMatch SYNTAX 
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
olcAttributeTypes: {5}( 1.3.6.1.4.1.6152.10.3.1.24 NAME 'sendmailMTAMapSearch' 
DESC 'recursive search for values of a map entry' EQUALITY caseExactMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
olcAttributeTypes: {6}( 1.3.6.1.4.1.6152.10.3.1.25 NAME 'sendmailMTAMapURL' 
DESC 'recursive search URL for values of a map entry' EQUALITY caseExactMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
olcAttributeTypes: {7}( 1.3.6.1.4.1.6152.10.3.1.18 NAME 
'sendmailMTAAliasGrouping' DESC 'name that identifies a particular aliases 
grouping' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
olcAttributeTypes: {8}( 1.3.6.1.4.1.6152.10.3.1.20 NAME 'sendmailMTAAliasValue' 
DESC 'value (right hand side) of an alias' EQUALITY caseIgnoreMatch SYNTAX 
1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {9}( 1.3.6.1.4.1.6152.10.3.1.26 NAME 
'sendmailMTAAliasSearch' DESC 'recursive search for values of an alias' 
EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
olcAttributeTypes: {10}( 1.3.6.1.4.1.6152.10.3.1.27 NAME 'sendmailMTAAliasURL' 
DESC 'recursive search URL for values of an alias' EQUALITY caseExactMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
olcAttributeTypes: {11}( 1.3.6.1.4.1.6152.10.3.1.22 NAME 'sendmailMTAClassName' 
DESC 'identifier for the class' EQUALITY caseIgnoreMatch SYNTAX 
1.3.6.1.4.1.1466.115.121.1.15{128} SINGLE-VALUE )
olcAttributeTypes: {12}( 1.3.6.1.4.1.6152.10.3.1.23 NAME 
'sendmailMTAClassValue' DESC 'member of a class' EQUALITY caseIgnoreMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
olcAttributeTypes: {13}( 1.3.6.1.4.1.6152.10.3.1.28 NAME 
'sendmailMTAClassSearch' DESC 'recursive search for members of a class' 
EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
olcAttributeTypes: {14}( 1.3.6.1.4.1.6152.10.3.1.29 NAME 'sendmailMTAClassURL' 
DESC 'recursive search URL for members of a class' EQUALITY caseExactMatch 
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
olcObjectClasses: {0}( 1.3.6.1.4.1.6152.10.3.2.10 NAME 'sendmailMTA' DESC 
'Sendmail MTA definition' SUP top STRUCTURAL MAY ( sendmailMTACluster $ 
sendmailMTAHost $ Description ) )
olcObjectClasses: {1}( 1.3.6.1.4.1.6152.10.3.2.11 NAME 'sendmailMTAMap' DESC 
'Sendmail MTA map definition' SUP sendmailMTA STRUCTURAL MUST 
sendmailMTAMapName MAY ( sendmailMTACluster $ sendmailMTAHost $ Description ) )
olcObjectClasses: {2}( 1.3.6.1.4.1.6152.10.3.2.12 NAME 'sendmailMTAMapObject' 
DESC 'Sendmail MTA map object' SUP sendmailMTAMap STRUCTURAL MUST ( 
sendmailMTAMapName $ sendmailMTAKey ) MAY ( sendmailMTACluster $ 
sendmailMTAHost $ sendmailMTAMapValue $ sendmailMTAMapSearch $ 

RE: openldap + bind-dyndb-ldap + bind

[Marc]

> 
> 
> 
> >
> > > If I enable this module, does it mean that this slapd stops receiving
> > > updates from the master?
> >
> > No, it's perfectly fine to run syncprov on consumers as well.
> >
> 
> I guess such messages are related to that my ldap is not allowing updates
> not? Which I want for this one.
> 
> "Server is unwilling to perform: shadow context; no update referral:
> connection error"
> 

What a fuckups there at redhat/fedora. This plugin served me always wel. Now 
these morons require ldap write access which I manage to bypass with[1]. Then I 
guess it downloads everything from ldap and I have more memory/swap usage and 
named is being slow because of the disk access.





[1]
--- a/src/ldap_helper.c  2023-09-21 10:01:10.227396899 +
+++ b/src/ldap_helper.c  2023-09-21 10:09:50.785071437 +
@@ -3064,6 +3064,9 @@
 isc_result_t result;
 ldap_connection_t *ldap_conn = NULL;

+result = ISC_R_SUCCESS;
+return result;
+
 REQUIRE(dn != NULL);
 REQUIRE(mods != NULL);
 REQUIRE(ldap_inst != NULL);

RE: openldap + bind-dyndb-ldap + bind

[Marc]

> 
> > If I enable this module, does it mean that this slapd stops receiving
> > updates from the master?
> 
> No, it's perfectly fine to run syncprov on consumers as well.
> 

I guess such messages are related to that my ldap is not allowing updates not? 
Which I want for this one.

"Server is unwilling to perform: shadow context; no update referral: connection 
error"

Is there some ingenious option/module that silently drops write requests? For 
buggy clients?

RE: openldap + bind-dyndb-ldap + bind

[Marc]

If I enable this module, does it mean that this slapd stops receiving updates 
from the master?

> 
> You need to load the syncprov module.
> 
> I wrote a test for this package recently in Ubuntu, you can see the
> script here: https://git.launchpad.net/ubuntu/+source/bind-dyndb-
> ldap/tree/debian/tests/dyndb-ldap?h=applied/ubuntu/devel
> 
> On Wed, Sep 20, 2023 at 7:02 PM Marc  wrote:
> >
> > Anyone experience with openldap and dyndb from bind?
> >
> > I am getting this:
> >
> > critical extension is not recognized: unable to start SyncRepl session:
> is RFC 4533 supported by LDAP

RE: openldap + bind-dyndb-ldap + bind

[Marc]

I just loaded the module, and had a slightly different response

error: LDAP error: Critical extension is unavailable: critical control 
unavailable in context: unable to start SyncRepl session: is RFC 4533 supported 
by LDAP server?

So I added this config

dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
changeType: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionLog: 100

Then I got a succesful connection message

Now I have things like this

1. serial (2013010102) write back to LDAP failed

I guess the named is trying to update the ldap server, which I do not want. How 
to resolve this? Or can this be ignored?


2. database: error: failed to convert DN 
'idnsName=..com.126,idnsName=xx' to DNS name: empty label

I guess these are ldap entries that have errors, and need to be fixed manually?


3. LDAP error: Size limit exceeded: unable to start SyncRepl session
LDAP data synchronization failed: socket is not connected
ldap_syncrepl will reconnect in 60 seconds

No idea what is going on here.


> 
> You need to load the syncprov module.
> 
> I wrote a test for this package recently in Ubuntu, you can see the
> script here: https://git.launchpad.net/ubuntu/+source/bind-dyndb-
> ldap/tree/debian/tests/dyndb-ldap?h=applied/ubuntu/devel
> 
> > >
> > Anyone experience with openldap and dyndb from bind?
> >
> > I am getting this:
> >
> > critical extension is not recognized: unable to start SyncRepl session:
> is RFC 4533 supported by LDAP

openldap + bind-dyndb-ldap + bind

[Marc]

Anyone experience with openldap and dyndb from bind?

I am getting this:

critical extension is not recognized: unable to start SyncRepl session: is RFC 
4533 supported by LDAP

RE: removed syncrepl getting Server is unwilling to perform (53)

[Marc]

> >> a) Some config changes still require a server restart.
> >>
> >> b) It sounds like it has no updateRef line configured?  If this server
> is
> >> no longer a write node, why are you sending writes to it?
> >>
> >
> > I was trying to remove the slave, make it standalone and remove some
> > records for testing.
> 
> 
> 
> Was it a slave, or was it an MMR node? 

I was using olcSyncrepl

> it wasn't an MMR node, I don't know why you would be messing with
> olcMirrorMode, since that's only for MMR configurations.

Because at some point I was trying anything I could find on the internet.

RE: removed syncrepl getting Server is unwilling to perform (53)

[Marc]

> >>
> >> I removed the synrepl from a ldap server.  Now I am getting errors when
> >> deleting entries
> >>
> >> ldap_modify: Server is unwilling to perform (53)
> >> additional info: shadow context; no update referral
> >>
> >>
> >> I also tried adding this, but does not change anything.
> >>
> >> dn: olcDatabase={0}config,cn=config
> >> changetype:modify
> >> add: olcMirrorMode
> >> olcMirrorMode: FALSE
> >>
> >> I don't think it is the acl's as I was able to change logging level
> >> before, when it was a slave. However now I am also not able to update
> >> the logging level.
> >>
> >> What config settings should I look at?
> >>
> >>
> >
> > conn=1004 op=32 SEARCH RESULT tag=101 err=0 qtime=0.62 etime=0.000498
> > nentries=0 text= conn=1004 op=33 DEL dn="xx,dc=local"
> > conn=1004 op=33 RESULT tag=107 err=53 qtime=0.40 etime=0.001071
> > text=shadow context; no update referral
> 
> 
> a) Some config changes still require a server restart.
> 
> b) It sounds like it has no updateRef line configured?  If this server is
> no longer a write node, why are you sending writes to it?
> 

I was trying to remove the slave, make it standalone and remove some records 
for testing.

RE: removed syncrepl getting Server is unwilling to perform (53)

[Marc]

> 
> I removed the synrepl from a ldap server.  Now I am getting errors when
> deleting entries
> 
> ldap_modify: Server is unwilling to perform (53)
> additional info: shadow context; no update referral
> 
> 
> I also tried adding this, but does not change anything.
> 
> dn: olcDatabase={0}config,cn=config
> changetype:modify
> add: olcMirrorMode
> olcMirrorMode: FALSE
> 
> I don't think it is the acl's as I was able to change logging level before,
> when it was a slave. However now I am also not able to update the logging
> level.
> 
> What config settings should I look at?
> 
> 

conn=1004 op=32 SEARCH RESULT tag=101 err=0 qtime=0.62 etime=0.000498 
nentries=0 text=
conn=1004 op=33 DEL dn="xx,dc=local"
conn=1004 op=33 RESULT tag=107 err=53 qtime=0.40 etime=0.001071 text=shadow 
context; no update referral

RE: [EXTERNAL] removed syncrepl getting Server is unwilling to perform (53)

[Marc]

Ctest2:/# grep -r -i readonly /etc/openldap/slapd.d/*

/etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif:olcReadOnly: FALSE
/etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif:olcReadOnly: FALSE
/etc/openldap/slapd.d/cn=config/olcDatabase={1}mdb.ldif:olcReadOnly: FALSE
/etc/openldap/slapd.d/cn=config/olcDatabase={2}monitor.ldif:olcReadOnly: FALSE
/etc/openldap/slapd.d/cn=config.ldif:olcReadOnly: FALSE

> OlcReadOnly=FALSE ?
> 
> 
> Sent from my iPad
> 
> 
>   On Aug 29, 2023, at 3:25 PM, Marc  wrote:
> 
> 
> 
>   
>   I removed the synrepl from a ldap server. Now I am getting errors
> when deleting entries ldap_modify: Server is unwilling to perform (53)
> additional info: shadow context; no update referral I also tried adding
> this, but does not change anything. 
>   I removed the synrepl from a ldap server.  Now I am getting errors
> when deleting entries
> 
>   ldap_modify: Server is unwilling to perform (53)
>   additional info: shadow context; no update referral
> 
> 
>   I also tried adding this, but does not change anything.
> 
>   dn: olcDatabase={0}config,cn=config
>   changetype:modify
>   add: olcMirrorMode
>   olcMirrorMode: FALSE
> 
>   I don't think it is the acl's as I was able to change logging level
> before, when it was a slave. However now I am also not able to update the
> logging level.
> 
>   What config settings should I look at?
> 
> 

removed syncrepl getting Server is unwilling to perform (53)

[Marc]

I removed the synrepl from a ldap server.  Now I am getting errors when 
deleting entries

ldap_modify: Server is unwilling to perform (53)
additional info: shadow context; no update referral


I also tried adding this, but does not change anything.

dn: olcDatabase={0}config,cn=config
changetype:modify
add: olcMirrorMode
olcMirrorMode: FALSE

I don't think it is the acl's as I was able to change logging level before, 
when it was a slave. However now I am also not able to update the logging level.

What config settings should I look at?

 

RE: still stuck with allowing access to all attributes except 1 or 2

[Marc]

> 2
> 
> On 8/27/23 19:01, Marc wrote:
> >>> olcAccess: {2} to attrs=userPassword,shadowLastChange
> >>>by ssf=256 self read
> >>>by ssf=256 anonymous auth
> >>>by * none break
> 
> I think the problem is this rule. You specify 'by * none break', which
> means that evaluation is not stopped if this rule does not match.
> Because of that, the later rules for user '' do match and '' can
> read the 'userPassword' attribute.
> 
> You would have to specify a separate rule for 'userPassword' without
> 'break', something like this:
> 
> olcAccess: {1} to attrs=userPassword
>   by self read
>   by anonymous auth
> 

Well done Souji! Thanks that seems to be working better, and I can remove these 
redundant read - search combinations!

RE: still stuck with allowing access to all attributes except 1 or 2

[Marc]

> 
> >
> > olcAccess: {0} to dn.exact=""
> >   by * read
> > olcAccess: {1} to dn.exact="cn=Subschema"
> >   by * read
> 
> 
> The above 2 acls generally go on the frontend DB.
>

hmmm, I have everything on {-1}frontend

> 
> > olcAccess: {2} to attrs=userPassword,shadowLastChange
> >   by ssf=256 self read
> >   by ssf=256 anonymous auth
> >   by * none break
> >
> > ...
> >
> > olcAccess: {7} to dn.subtree="xx" filter=(objectClass=posixAccount)
> > attrs=   by ssf=64 dn.exact="" read
> >   by * break
> > olcAccess: {8} to dn.subtree="xx"
> >   by ssf=256 dn.exact="" search
> >   by ssf=256 self read
> >   by anonymous
> 
> The rest of these acls generally go on the MDB database.  Have you
> configured your backend ACLs incorrectly?
> 
> 
> What exactly is the issue you're trying to report? Your subject doesn't
> really give a solid indication of what the problem is you're having.
> 

 is getting the userPassword hash, which I do not want it to have. Of 
course I can list 50 attributes which it can have. But it would be nicer if I 
could just exclude an attribute.

still stuck with allowing access to all attributes except 1 or 2

[Marc]

olcAccess: {0} to dn.exact=""
  by * read
olcAccess: {1} to dn.exact="cn=Subschema"
  by * read
olcAccess: {2} to attrs=userPassword,shadowLastChange
  by ssf=256 self read
  by ssf=256 anonymous auth
  by * none break

...

olcAccess: {7} to dn.subtree="xx" filter=(objectClass=posixAccount) attrs=
  by ssf=64 dn.exact="" read
  by * break
olcAccess: {8} to dn.subtree="xx"
  by ssf=256 dn.exact="" search
  by ssf=256 self read
  by anonymous

is there not a syntax or so for attrs=-userPassword

Or am I approaching this incorrectly?

RE: Help writing a slapd plugin

[Marc]

> 
> Inspired by the proprietary server at ldap.dnssek.info, I'd like to make
> a slapd plugin that, when queried for a particular email address, finds
> the OpenPGP keys and S/MIME certificates by doing DNS lookups (possibly
> aided by DANE), and then serves them back to the requestor.
> 

Interesting. Although I am not entirely sure what you are trying to solve and 
why this needs to be solved in ldap and not in eg. MTA 

RE: requested some clean up / verification of my acls (paid)

[Marc]

> 
> First I apologize for posting a non-technical question / follow up to
> this list, however I can speak for the high value add that having
> official support for OpenLDAP that the Symas team offers.  Like most
> folks on this list, we have a great deal of in house expertise on many
> software stacks including directory services in general.  With that
> said, the Symas team members are great to work with, literally write the
> software that we are asking questions about and as a result have many
> years of experience and expertise that is easy to reach for.  IMO the
> support that the Symas org puts forward is a model that vendors should
> be striving for.
> 

Thanks Aaron, good point, just forwarded email to sales

requested some clean up / verification of my acls (paid)

[Marc]

I have ~11 acl's that could use more attention, limiting access to what is 
required (to mta, system, cron). They are working, but I would to have an 
expert look at them. I think someone with experience could tune some things 
better. Anyone interested?

excluding attribute in acl

[Marc]

Is it possible to specify something like allow access to all attributes - 
userPassword?

RE: restricting acls more by adding a filter

[Marc]

Hi Sean, Your search helped me a bit tracking this down currently I am testing 
with something like this

to dn.subtree="dc=local" 
filter=(|(objectClass=sendmailMTAClass)(objectClass=sendmailMTA))
  by ssf=64 dn.exact="cn=cron,dc=local" read

to dn.subtree="dc=local" 
  by ssf=64 dn.exact="cn=cron,dc=local" search

> 
> 
> 
> 
> I'm wondering if a "search" privilege needs to be granted somewhere and
> "(objectClass=*)" is a a loophole that bypasses the need for the
> "search" privilege. What happens if you say "filter=(&(objectClass=*))"
> ?
> 
> 
>   Sean.
> 
> 
> On 1/08/2023 10:34 pm, Marc wrote:
> 
> I have a ldapsearch that returns this object
> 
> sendmailMTAClassName: w
> sendmailMTAClassValue: xxx
> sendmailMTAClassValue: yyy
> sendmailMTAClassValue: zzz
> objectClass: sendmailMTA
> objectClass: sendmailMTAClass
> 
> I thought I could strengthen the acl by just appending to with a
> filter
> 
> but if I add these below, the ldapsearch does not return anything
> err=32
> 
> filter=(objectClass=sendmailMTAClass)
> filter=(|(objectClass=sendmailMTAClass)(objectClass=sendmailMTA))
> filter=(|(objectClass=sendmailMTAClass)(objectClass=sendmailMTA))
> filter=(objectClass=sendmailMTA*)
> 
> If I change the filter to this, I get the expected result again
> 
> filter=(objectClass=*)
> 
> Goal is to have ldapsearch only list the specific objectClasses. Or
> should I do
> this with listing only attributes.
> 

RE: restricting acls more by adding a filter

[Marc]

> 
> > I have a ldapsearch that returns this object
> >
> > sendmailMTAClassName: w
> > sendmailMTAClassValue: xxx
> > sendmailMTAClassValue: yyy
> > sendmailMTAClassValue: zzz
> > objectClass: sendmailMTA
> > objectClass: sendmailMTAClass
> >
> > I thought I could strengthen the acl by just appending to with a
> filter
> >
> > but if I add these below, the ldapsearch does not return anything
> err=32
> >
> > filter=(objectClass=sendmailMTAClass)
> > filter=(|(objectClass=sendmailMTAClass)(objectClass=sendmailMTA))
> > filter=(|(objectClass=sendmailMTAClass)(objectClass=sendmailMTA))
> > filter=(objectClass=sendmailMTA*)
> 
> 
> a) ACLs are contextual

I am just appending this to an existing 'standard' type of acl

to dn.subtree="dc=local" 
filter=(|(objectClass=sendmailMTAClass)(objectClass=sendmailMTA))
  by ssf=64 dn.exact="cn=cron,dc=local" read

RE: restricting acls more by adding a filter

[Marc]

If I add this filter=(&(objectClass=*)), I also get the expected result.




I'm wondering if a "search" privilege needs to be granted somewhere and 
"(objectClass=*)" is a a loophole that bypasses the need for the "search" 
privilege. What happens if you say "filter=(&(objectClass=*))" ?


  Sean.


On 1/08/2023 10:34 pm, Marc wrote:

I have a ldapsearch that returns this object

sendmailMTAClassName: w
sendmailMTAClassValue: xxx
sendmailMTAClassValue: yyy
sendmailMTAClassValue: zzz
objectClass: sendmailMTA
objectClass: sendmailMTAClass

I thought I could strengthen the acl by just appending to with a filter

but if I add these below, the ldapsearch does not return anything err=32

filter=(objectClass=sendmailMTAClass)
filter=(|(objectClass=sendmailMTAClass)(objectClass=sendmailMTA))
filter=(|(objectClass=sendmailMTAClass)(objectClass=sendmailMTA))
filter=(objectClass=sendmailMTA*)

If I change the filter to this, I get the expected result again

filter=(objectClass=*)

Goal is to have ldapsearch only list the specific objectClasses. Or should 
I do 
this with listing only attributes.

RE: updating from el7 to alpine openldap 2.6

[Marc]

> 
> > I am updating my ldap container and migrate from el7 to alpine. While
> > running some test queries I noticed that the new 2.6 alpine has
> probably
> > different defaults, I am getting "Size limit exceeded (4)". However
> this
> > does not show in the ldap error log.
> 
> That's not an error, so it wouldn't show up in any error log.  It would
> be
> part of normal "stats" level logging however.  I suggest reading the
> slapd.conf(5)/slapd-config(5) man pages as to the default settings for
> time
> and size limits if none are explicitly specified in your configuration.
> 
> 
> > What would be good loglevel config to see quickly if there is an issue
> > with client queries? I am a little worried that if MTA's are getting
> > incomplete results and dropping mail.
> 
> "stats".
> 

Thanks! I noticed indeed the err=4, so I will run a few days with this test 
container see if I only have the err=0

restricting acls more by adding a filter

[Marc]

I have a ldapsearch that returns this object

sendmailMTAClassName: w
sendmailMTAClassValue: xxx
sendmailMTAClassValue: yyy
sendmailMTAClassValue: zzz
objectClass: sendmailMTA
objectClass: sendmailMTAClass

I thought I could strengthen the acl by just appending to with a filter

but if I add these below, the ldapsearch does not return anything err=32

filter=(objectClass=sendmailMTAClass)
filter=(|(objectClass=sendmailMTAClass)(objectClass=sendmailMTA))
filter=(|(objectClass=sendmailMTAClass)(objectClass=sendmailMTA))
filter=(objectClass=sendmailMTA*)

If I change the filter to this, I get the expected result again

filter=(objectClass=*)

Goal is to have ldapsearch only list the specific objectClasses. Or should I do 
this with listing only attributes.

updating from el7 to alpine openldap 2.6

[Marc]

I am updating my ldap container and migrate from el7 to alpine. While running 
some test queries I noticed that the new 2.6 alpine has probably different 
defaults, I am getting "Size limit exceeded (4)". However this does not show in 
the ldap error log. 

What would be good loglevel config to see quickly if there is an issue with 
client queries? I am a little worried that if MTA's are getting incomplete 
results and dropping mail. 

Re: OpenLDAP and NTLM

[Marc Boorshtein]

>
>
>
> NTLM has been obsoleted and shouldn't be used at all.  SASL/GSSAPI or
> SASL/GSS-SPNEGO should be fine.
>

I understand, but this is a legacy (really legacy) application that can't
be changed. Is NTLM still working?

>

OpenLDAP and NTLM

[Marc Boorshtein]

I see that NTLM is supported as an authentication mechanism for
supportedSASLMechanisms, but I'm not seeing any docs.  Do I configure
GSSAPI and NTLM is now available?

Thanks
Marc

RE: Migrate HDB to MDB

[Marc Roos]

 I think you also need a bit of help with your spam setup ;)

<<< 550-XM-RJCT22: [212.26.193.44] is prohibited from connecting to 
XMission mail <<< 550-servers due to high spam volume. See the following 
for more information:

This server is not even sending out that many mails.


-Original Message-
From: Pete Ashdown [mailto:pashd...@xmission.com] 
Sent: 20 December 2020 19:22
To: openldap-technical@openldap.org
Subject: Migrate HDB to MDB

I'm looking for some assistance in converting a legacy LDAP from an HDB 
backend to MDB.  I've been unable to find any resources in how this can 
be executed and my attempts at using ldapmodify have failed.  I'm 
willing to pay consulting fees if someone is available to help, or 
otherwise be educated if is documented somewhere.

Thanks in advance.

RE: HAProxy protocol support?

[Marc Roos]

 
> So management is insisting that we migrate our openLDAP systems from 
on premise into the cloud

If I maybe totally off topic. Why would they, for what reasons?

RE: Now combining acl attribute access with regular access fails

[Marc Roos]

 
Hmm, I am not to familiar with the acl's. I have solved 
it now by duplicating the by lines to the other section 
something like this


 {5} access to dn.subtree="ou=People,dc=example,dc=com" 
 attrs="entry,uid,cn,sn,mail,mailHost"
by dn="cn=outsourced_ironport,dc=example,dc=com" read
by dn="cn=outsourced_bla,dc=example,dc=com" read 
 {6} access to dn.subtree="ou=People,dc=example,dc=com" 
by dn="cn=outsourced_bla,dc=example,dc=com" read 


But I am not to pleased with this solution either. I had to 
create a new account and save the password on a client, 
while user account dn's are available there, and they should
access these 'own' attributes.

https://www.mail-archive.com/openldap-technical@openldap.org/msg25113.html



-Original Message-
To: openldap-technical
Subject: Re: Now combining acl attribute access with regular access 
fails

You are confusing “continue” with “break”.

> On Aug 31, 2020, at 9:22 AM, Marc Roos  
wrote:
> 
> 
> Now I have that either works, but not both. Reversing these rules also 

> does not work (with keeping the continue at 5)
> 
> {5} access to dn.subtree="ou=People,dc=example,dc=com" 
>by dn="cn=outsourced_bla,dc=example,dc=com" read 
>by * continue
> {6} access to dn.subtree="ou=People,dc=example,dc=com" 
> attrs="entry,uid,cn,sn,mail,mailHost"
>by dn="cn=outsourced_ironport,dc=example,dc=com" read
> 
> Any help possible?
> 


//
John Pfeifer
Division of Information Technology
University of Maryland, College Park

RE: Now combining acl attribute access with regular access fails

[Marc Roos]

Where can I get some support on these acl's?



-Original Message-
To: openldap-technical
Subject: Now combining acl attribute access with regular access fails


Now I have that either works, but not both. Reversing these rules also 
does not work (with keeping the continue at 5)

{5} access to dn.subtree="ou=People,dc=example,dc=com" 
by dn="cn=outsourced_bla,dc=example,dc=com" read 
by * continue
{6} access to dn.subtree="ou=People,dc=example,dc=com" 
attrs="entry,uid,cn,sn,mail,mailHost"
by dn="cn=outsourced_ironport,dc=example,dc=com" read

Any help possible?

Now combining acl attribute access with regular access fails

[Marc Roos]

Now I have that either works, but not both. Reversing these rules also 
does not work (with keeping the continue at 5)

{5} access to dn.subtree="ou=People,dc=example,dc=com" 
by dn="cn=outsourced_bla,dc=example,dc=com" read 
by * continue
{6} access to dn.subtree="ou=People,dc=example,dc=com" 
attrs="entry,uid,cn,sn,mail,mailHost"
by dn="cn=outsourced_ironport,dc=example,dc=com" read

Any help possible?

RE: Acl attribute access

[Marc Roos]

 
However attributes of cn=test,ou=People,dc=example,dc=com are not 
working.

Anyone there?



-Original Message-
To: openldap-technical
Subject: RE: Acl attribute access


I had to add objectClass to Dan's example to get this to work. Not sure 
if this is the correct approach though.

access to dn.subtree="ou=People,dc=example,dc=com" 
attrs="entry,uid,cn,sn,mail,mailHost"
by dn="cn=outsourced_ironport,dc=example,dc=com" read
by * break 

[1]
https://www.openldap.org/faq/data/cache/429.html


-Original Message-
To: openldap-technical
Subject: Acl attribute access


If I have this acl:
to
dn="sendmailMTAKey=t...@b.com,ou=,ou=d,ou=c,dc=b,dc=
a,dc=local"
 by ssf=64
dn.exact="uid=acctest,ou=,ou=d,ou=c,dc=b,dc=a,dc=loc
al" read
 
I can access with this ldap search:
ldapsearch  -LLL -W -s sub -b
"sendmailMTAKey=t...@b.com,ou=,ou=d,ou=c,dc=b,dc=aaa
aa,dc=local" -D
"uid=acctest,ou=,ou=d,ou=c,dc=b,dc=a,dc=local" -H 
ldaps://ldap.local sendmailMTAKey

If I change the acl to
to
dn="sendmailMTAKey=t...@b.com,ou=,ou=d,ou=c,dc=b,dc=
a,dc=local" attrs="sendmailMTAKey"
 by ssf=64
dn.exact="uid=acctest,ou=,ou=d,ou=c,dc=b,dc=a,dc=loc
al" read

The ldapsearch is not returning any object. How to resolve this?

RE: Acl attribute access

[Marc Roos]

I had to add objectClass to Dan's example to get this to work. Not sure 
if this is the correct approach though.

access to dn.subtree="ou=People,dc=example,dc=com" 
attrs="entry,uid,cn,sn,mail,mailHost"
by dn="cn=outsourced_ironport,dc=example,dc=com" read
by * break 

[1]
https://www.openldap.org/faq/data/cache/429.html


-Original Message-
To: openldap-technical
Subject: Acl attribute access


If I have this acl:
to
dn="sendmailMTAKey=t...@b.com,ou=,ou=d,ou=c,dc=b,dc=
a,dc=local"
 by ssf=64
dn.exact="uid=acctest,ou=,ou=d,ou=c,dc=b,dc=a,dc=loc
al" read
 
I can access with this ldap search:
ldapsearch  -LLL -W -s sub -b
"sendmailMTAKey=t...@b.com,ou=,ou=d,ou=c,dc=b,dc=aaa
aa,dc=local" -D
"uid=acctest,ou=,ou=d,ou=c,dc=b,dc=a,dc=local" -H 
ldaps://ldap.local sendmailMTAKey

If I change the acl to
to
dn="sendmailMTAKey=t...@b.com,ou=,ou=d,ou=c,dc=b,dc=
a,dc=local" attrs="sendmailMTAKey"
 by ssf=64
dn.exact="uid=acctest,ou=,ou=d,ou=c,dc=b,dc=a,dc=loc
al" read

The ldapsearch is not returning any object. How to resolve this?

RE: Acl with variable in filter

[Marc Roos]

In 2005 this was not possible, has this changed? 

> access to dn.children="ou=users,o=mydomain.com" 
filter=(groupname=(.+))
>   by group.expand="cn=$1,ou=groups,o=mydomain.com" write

[1]
https://www.openldap.org/lists/openldap-software/200501/msg00322.html

-Original Message-
To: openldap-technical
Subject: Acl with variable in filter

Is it possible to have a variable VAR in an acl filter?

Something like this:

to
dn="sendmailMTAKey=t...@b.com,ou=,ou=d,ou=c,dc=b,dc=
a,dc=local" filter="(sendmailMTAMapValue=VAR1)
 by ssf=64
dn.exact="uid=VAR1,ou=,ou=d,ou=c,dc=b,dc=a,dc=local" 

read

user | this expansion in acl

[Marc Roos]

I am not getting this page. Maybe there should be an example or so. I 
can use user anywhere in the acls and it will expand to the dn of the 
binddn of the ldapsearch request?

user | this :  resolves to the set { 
"cn=User,cn=adfasdfa,cn=asdfadfa,ou=asdfasdfas,ou=adsasdfasdf", 
"cn=Resource" }

How can I get only 'User' and not the whole dn also not 'cn=User'?

[1]
https://www.openldap.org/faq/data/cache/1133.html

Acl with variable in filter

[Marc Roos]

Is it possible to have a variable VAR in an acl filter?

Something like this:

to 
dn="sendmailMTAKey=t...@b.com,ou=,ou=d,ou=c,dc=b,dc=
a,dc=local" filter="(sendmailMTAMapValue=VAR1)
 by ssf=64 
dn.exact="uid=VAR1,ou=,ou=d,ou=c,dc=b,dc=a,dc=local" 
read

Acl attribute access

[Marc Roos]

If I have this acl:
to 
dn="sendmailMTAKey=t...@b.com,ou=,ou=d,ou=c,dc=b,dc=
a,dc=local"
 by ssf=64 
dn.exact="uid=acctest,ou=,ou=d,ou=c,dc=b,dc=a,dc=loc
al" read
 
I can access with this ldap search:
ldapsearch  -LLL -W -s sub -b 
"sendmailMTAKey=t...@b.com,ou=,ou=d,ou=c,dc=b,dc=aaa
aa,dc=local" -D 
"uid=acctest,ou=,ou=d,ou=c,dc=b,dc=a,dc=local" -H 
ldaps://ldap.local sendmailMTAKey

If I change the acl to 
to 
dn="sendmailMTAKey=t...@b.com,ou=,ou=d,ou=c,dc=b,dc=
a,dc=local" attrs="sendmailMTAKey"
 by ssf=64 
dn.exact="uid=acctest,ou=,ou=d,ou=c,dc=b,dc=a,dc=loc
al" read

The ldapsearch is not returning any object. How to resolve this?

RE: slapd 2.4.44 Performance problems

[Marc Roos]

 

Share some comparison performance charts ;)



-Original Message-
Subject: Re: slapd 2.4.44 Performance problems

We are using the version that comes with CentOS/RHEL7. 

Will try a new deployment using back-mdb.

Thanks.

RE: anonymize data

[Marc Roos]

Maybe use acls with different ssf? This way you can keep your queries 
the same and extract full data on your own very secure connection?


-Original Message-
To: openldap-technical@openldap.org
Subject: anonymize data

Hi all,

I have a question anonymizing data.
My openldap have some confidential data inside and I would like this  : 
if a person has a flag confidentiality set to 1 (or is in a special ou), 
openldap will replace or answer a different data.


For example :


if we request "sn" on this record , it will reply "Smith"

dn: cn=Smith,ou=public,c=com
confidentiality: 0
sn: Smith

if we request "sn" on this record , it will reply "XXX"

dn: cn=Bond,ou=public,c=com
confidentiality: 1

sn: Bond

I'm not sur Openldap can offer this kind of functionnality.
Thanks for your help !

RE: Re: Info needed on OpenLDAP support / compliance on FIPS 140.2

[Marc Roos]

 
Thanks for this clear insight!


-Original Message-
To: Scott Classen
Cc: Vijay Kumar; openldap-technical@openldap.org
Subject: *SPAM* Re: Info needed on OpenLDAP support / compliance 
on FIPS 140.2

On Mon, 15 Jun 2020, Scott Classen wrote:
> Did you build the OpenLDAP binary from source or are you using a 
> binary distribution from somewhere? Like Quanah already stated, you 
> need to determine if the version of OpenSSL you linked against is FIPS 

> compliant. The FIPS designation has nothing to do with OpenLDAP per 
se.
> 
> e.g. on my CentOS distro I can type
> 
> # openssl version
> OpenSSL 1.0.2k-fips  26 Jan 2017
> 
> And it lets me know that OpenSSL is FIPS compliment. Then if I build 
> OpenLDAP using the openssl libraries provided with my distro then I’m 

> assuming it would then inherit some of this FIP-ness.

Simply _using_ that library is not nearly enough to pass any sort of 
compliance check.  Here's a session using a similar library (CentOS
7.7.1908) with anonymous RC4-MD5, an absolutely non-FIPS-compliant 
cipher
suite:

$ openssl version
OpenSSL 1.0.2k-fips  26 Jan 2017
$ echo foo | openssl s_server -cipher ADH-RC4-MD5 -nocert -quiet & [1] 
31787 $ openssl s_client -connect localhost:4433 -cipher aNULL -quiet 
foo read:errno=0 $ fg echo foo | openssl s_server -cipher ADH-RC4-MD5 
-nocert -quiet ^C $ 


First, you have to actually tell the library to go into FIPS mode.  The 
CLI 'openssl' tool will do that when the OPENSSL_FIPS environment 
variable is set and I seem to recall that the system openssl libs on 
RedHat systems (don't remember if it carried over to CentOS) would do so 
if a kernel parameter was set, but in general applications using libssl 
and libcrypto have to use the FIPS_mode_set() API to turn on FIPS mode 
themselves.  
Last I checked, OpenLDAP had no calls to FIPS_mode_set(), so unless your 
system libcrypto has something external to force FIPS mode *and your're 
using it*, OpenLDAP will _not_ be using the library in FIPS mode.


Furthermore, is that build of openssl still covered by a valid FIPS 
certificate?  "It's a build of sources for which some build has had a 
FIPS certificate issued" is cute verbiage and there are many people that 
only care about that: verbiage so they can check a unclearly specified 
box on their documents.  Not a bad option if that's all your customers 
expect and all you sell/promise, given that FIPS mode is not strictly 
beneficial with the difficulty it creates for fixing bugs in crypto 
implementations, including--historically--in openssl's code base.

While some customers will find that sufficient to check a box on their 
documents, it ain't going to make real FIPS compliance people (U.S. 
government agencies) blink before ignoring it.  If you're going to have 
a compliance audit from such a group, with scheduled followups and 
30/60/90 day remediation requirements, then no, stock openldap on stock 
centos, for example, will not get you there.


Philip Guenther

Re: Read only Replica

[Marc Franquesa]

What I like most of this list is that I always learnt (or remember)
something in few posts.

About the ServerID>0:

Sure, didn't realized that and makes total sense, as ServerID is used to
generate CSN changes, so if ServerID=0 then is not writting CSNs -> not a
provider.

About my setup and needs:

At the end I'm going to deploy a N-way multimaster, but while testing just
wanted to ensure no "accidental" writes reach the new 'tested' member.

You solved perfectly all my concerns

Thanks much

Missatge de Quanah Gibson-Mount  del dia dj., 9 d’abr.
2020 a les 17:31:

>
>
> --On Thursday, April 9, 2020 6:19 PM +0200 Michael Ströder
>  wrote:
> >> a) syncprov (and possibly accesslog), no serverID >1, and no syncrepl
> >> statement, it is a standalone provider
> >
> > should be: serverID > 0 <=> serverID >= 1
> >
> >> b) syncprov (and possibly accesslog), serverID > 1, and a syncrepl
> >> statement, it is a multimaster node
> >
> > should be: serverID > 0 <=> serverID >= 1
>
> Correct, thanks. :)
>
> > Isn't mirrormode true not also needed for MMR?
>
> Ah right, thanks. :)
>
> >> I'm not really clear what you mean by "read only" in any of these cases.
> >> If you want an LDAP server that accepts no writes at all, then you
> >> shouldn't configure replication, as any writes that occur on the
> >> provider will then occur on the consumer, and additionally set the
> >> readonly configuration parameter to TRUE.
> >
> > He probably wants to implement a 2-tier replication topology where
> > applications/systems access pure consumer replicas which do not accept
> > write operations from normal clients but only the modifications
> > retrieved via syncrepl from providers.
> > (At least that's how Æ-DIR is designed. ;-)
>
> Yeah, that's my guess too, but their statements make that hard to
> determine. ;)
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> 
>

Re: Read only Replica

[Marc Franquesa]

Hi

Hi

Thanks for the quick reply.

No I didn't add any olcReferral anywhere, may idea is to have truly read
only C (rejecting writes, not referring to the master).

My use case might be quite strange, and not the best approach:

I'm currenlty building a docker container which uses an already existing
DIT, loading proper LDIFs. For this it parses the them to figure out the
current setup.

I'm assuming (may be wrongly) that:

1- If the DIT loads and uses syncprov modules -> Is a Master/Provider
2- If the DIT has olcSyncrepl -> Is a Slave/Consumer

If 1 & 2 are both true I assume I'm in a N-Way Multimaster scenario
If only 1 is true I assume I'm the Master on a Master/Slave setup
If only 2 is true I assume I'm the Slave (ReadOnly) on a Master/Slave
scenario.

In all above cases I would like the slave to be readonly replica, totally
denying writes.

- Is this possible or I have to refer either way?
- If this is the case (Referral required) how I ensure that only the C node
becomes readonly and refers to master (either A or B).

Regards

Missatge de Xuhua Lin  del dia dj., 9 d’abr. 2020 a
les 0:39:

> Hi Marc, very interesting I'm doing similar setups as yours. Do you add
> olcReferral on C?
>
> Xuhua
>

Read only Replica

[Marc Franquesa]

I wrongly supposed that a LDAP server configured with replication
(sycnrepl) and not using syncprov modules (so is only a consumer and not a
provider) would automatically behave as a Read-ONLY replica as it will sync
from other servers specified on the syncrepl settings but will not be
providing deltas thru syncprov module.

However I tested the following scenario (N-way multimatseer with one
'Readreplica')

- Servers A and B with syncprov enabled (so they are providers)
- Servers A and B both sync (syncprel) to the other (so they are consumers)
- Added server C syncrepl to A and B, *BUT not loading syncprov*. So is a
consumer only, (ReadReplica)?

However I verified that I can make changes to C and they got stored into C.
(Not replicated to A/B as they don't sync with C).

- So how I got C behave like a true ReadOnly replica (denying writes)?
- If I have to set some settings, note that I'm also replicating olcConfig
tree cn=config, so how I got this setting applied only to one server?

Thanks for any hints or explation on my doubts.

Sync replication, with failing consumer

[Marc Roos]

With sync replication, having a provider at state C (newest) and a 
consumer starting with rid=100 and state=A. 

After syncing provider and consumer both are in state C

When then the consumer is killed, and a new consumer is started with the 
same rid=100 and again state A. 

Does this consumer sync data from the provider again? Or does the 
provider has data stored of the previous consumer and block syncing?

RE: *****SPAM***** Adding ACL to an Attribute

[Marc Roos]

 
> -w `cat /var/lib/nethserver/secrets/libuser`

Use -y  option? (and 'echo -n' password to file, thus without newline 
character)


Start with acls something like this (default do not allow access): 

olcAccess: {0} to dn.exact="" by * read
olcAccess: {1} to dn.exact="cn=Subschema" by * read
olcAccess: {2} to attrs=userPassword,shadowLastChange
  by ssf=256 self read
  by ssf=256 anonymous auth
  by * none break
.
.
.
olcAccess: {9} to * by * none

I think my question is in the basis similar to yours, so maybe keep 
track of this for answer.
https://www.mail-archive.com/openldap-technical@openldap.org/msg24126.html


-Original Message-
To: openldap-technical@openldap.org
Subject: *SPAM* Adding ACL to an Attribute

Hi all,

SYSTEM: NethServer-7.6.1810, a distro using Centos7.6.1810
OpenLDAP: openldap-2.4.44-21.el7_6.x86_64 Extra package: Self Service 
Password

I am using Self Service Password with question/answer method to change 
the password.
I store the answer in an attibute named: info.

$answer_objectClass = "extensibleObject"; $answer_attribute = "info";

The original Account provider is LDAP which I want to replace with 
Active Directory.
All the user have to choose a question/answer before I replace LDAP with 
AD as the Account provider.


While LDAP is still the Account provider, anybody with console access to 
the server can see the question/answer using the command:

# ldapsearch  -D cn=libuser,dc=directory,dc=nh -w `cat 
/var/lib/nethserver/secrets/libuser` -h 127.0.0.1


# toto, People, directory.nh
dn: uid=toto,ou=People,dc=directory,dc=nh
...
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
objectClass: extensibleObject
shadowLastChange: 18220
userPassword:: cm9ibTEyMDQ0OQ==
info: {car}Honda

I created a Virtual Machine to test the scenario with 3 users.

In NethServer, the original Account provider is LDAP.
I did a script to extract the users and their answers to file.ldif I 
remove LDAP.
I install Active Directory module.
I import the users/groups to AD. In the importation, AD creates new 
passwords for the imported users.
I add a section to Self Service Password for AD.
I modify AD with info.ldip to include the answer.

# /usr/bin/systemd-run -M nsdc -q -t /usr/bin/ldbmodify -H 
/var/lib/samba/private/sam.ldb /var/lib/samba/private/file.ldif Modified 
3 records successfully #

The users can then modify their password responding to the same 
question/answer they had with LDAP.
All is working perfectly.

PROBLEM:
I cannot encrypt the answer in LDAP because when I import the users to 
Active Directory, it cannot reads the encrypted answer. I think that AD 
is using another way to encrypt/decypt?
If I don't encrypt the answer, the importation to AD is working 
correctly.

While still using LDAP as Account provider and before I change it to 
Active Directory, I would like to add an additional ACL so nobody can 
read the answer stored in "info".

After googling a lot I found a way to describe the ACL. I hope it is the 
right way.

access to attrs=info
by self write
by anonymous auth
by group="cn=domain admins,ou=Groups,dc=directory,dc=nh" write
by * none

How can I create the content of newacl.ldif file to be able to add that 
ACL to OpenLDAP (ldapmodify  -Y EXTERNAL -H ldapi:/// -f 
/temp/newacl.ldif)

Thank you,

Drukpa 

RE: acl help access to 'own' attributes

[Marc Roos]

Read to the attribute is fine. I tried to explain a bit in 'pseudo' code

> Access to children(?) ou=,ou=,ou=,dc=,dc=,dc=local
> filter=(sendmailMTAMapValue=VAR1) attrs=sendmailMTAKey
>   by uid=VAR1,ou=,ou=,ou=,dc=,dc=,dc=local read 

-Original Message-
To: openldap-technical@openldap.org
Subject: Re: acl help access to 'own' attributes

What I still don't understand do you want only write access to a single 
Attribute or to the whole object

(1)

access to dn.children=[1]
  by self write
  by * none

or (2)

access to attr 
  by self write
  by * none

This (1) will give permission to all Users located in [1] write access 
to their own object. (2) will give access only to a list (comma
separated) of attributes. But be aware that you have to look at which 
position you put the new ACL in your ACL-List


Am 27.11.19 um 22:41 schrieb Marc Roos:
> Can anyone help how I should make the acls that allows users[2] access 

> attributes of ldap entries[1] that have themselves listed in the 
> attribute value sendmailMTAMapValue
>
> Something like:
> Access to children? ou=,ou=,ou=,dc=,dc=,dc=local
> filter=(sendmailMTAMapValue=VAR1) attrs=sendmailMTAKey
>   by uid=VAR1,ou=,ou=,ou=,dc=,dc=,dc=local read
>
>
> [1]
> dn: 
> sendmailMTAKey=t...@example.com,ou=,ou=,ou=,dc=,dc=aaa
> a,
> dc=local
> objectClass: sendmailMTA
> objectClass: sendmailMTAMap
> objectClass: sendmailMTAMapObject
> objectClass: ritAdditionalInfo
> sendmailMTAMapName: virtuser
> sendmailMTACluster: mail
> sendmailMTAKey: t...@example.com
> sendmailMTAMapValue: testuser
>
> [2]
> uid=testuser,ou=,ou=,ou=,dc=,dc=,dc=local
>
--
Stefan Kania
Landweg 13
25693 St. Michaelisdonn


Signieren jeder E-Mail hilft Spam zu reduzieren und schützt Ihre 
Privatsphäre. Ein kostenfreies Zertifikat erhalten Sie unter 
https://www.dgn.de/dgncert/index.html

Does copying lock.mdb and data.mdb give syncrep errors?

[Marc Roos]

Can I just copy the mdb databases to a different server, or are there 
'unique' values inside?

RE: acl help access to 'own' attributes

[Marc Roos]

 
> It depends on how many user you have, 
Why?
> were are the user-objects are located in your tree,
At [2]
>If the users are spread over the hole tree you need some kind of 
regex-ACLs
No just [2]

Is it not possible to focus on this example, I think I can manage from 
there.


-Original Message-
To: openldap-technical@openldap.org
Subject: Re: acl help access to 'own' attributes

It depends on how many user you have, were are the user-objects are 
located in your tree, there are not enough  information to solve your 
problem. If the users are spread over the hole tree you need some kind 
of regex-ACLs


Am 27.11.19 um 22:41 schrieb Marc Roos:
> Can anyone help how I should make the acls that allows users[2] access 

> attributes of ldap entries[1] that have themselves listed in the 
> attribute value sendmailMTAMapValue
>
> Something like:
> Access to children? ou=,ou=,ou=,dc=,dc=,dc=local
> filter=(sendmailMTAMapValue=VAR1) attrs=sendmailMTAKey
>   by uid=VAR1,ou=,ou=,ou=,dc=,dc=,dc=local read
>
>
> [1]
> dn: 
> sendmailMTAKey=t...@example.com,ou=,ou=,ou=,dc=,dc=aaa
> a,
> dc=local
> objectClass: sendmailMTA
> objectClass: sendmailMTAMap
> objectClass: sendmailMTAMapObject
> objectClass: ritAdditionalInfo
> sendmailMTAMapName: virtuser
> sendmailMTACluster: mail
> sendmailMTAKey: t...@example.com
> sendmailMTAMapValue: testuser
>
> [2]
> uid=testuser,ou=,ou=,ou=,dc=,dc=,dc=local
>
--
Stefan Kania
Landweg 13
25693 St. Michaelisdonn


Signieren jeder E-Mail hilft Spam zu reduzieren und schützt Ihre 
Privatsphäre. Ein kostenfreies Zertifikat erhalten Sie unter 
https://www.dgn.de/dgncert/index.html

RE: acl help access to 'own' attributes (paid support)

[Marc Roos]

Paid support is also welcome. 


-Original Message-
To: openldap-technical
Subject: acl help access to 'own' attributes


Can anyone help how I should make the acls that allows users[2] access 
attributes of ldap entries[1] that have themselves listed in the 
attribute value sendmailMTAMapValue

Something like:
Access to children? ou=,ou=,ou=,dc=,dc=,dc=local
filter=(sendmailMTAMapValue=VAR1) attrs=sendmailMTAKey
  by uid=VAR1,ou=,ou=,ou=,dc=,dc=,dc=local read


[1]
dn: 
sendmailMTAKey=t...@example.com,ou=,ou=,ou=,dc=,dc=,
dc=local
objectClass: sendmailMTA
objectClass: sendmailMTAMap
objectClass: sendmailMTAMapObject
objectClass: ritAdditionalInfo
sendmailMTAMapName: virtuser
sendmailMTACluster: mail
sendmailMTAKey: t...@example.com
sendmailMTAMapValue: testuser

[2]
uid=testuser,ou=,ou=,ou=,dc=,dc=,dc=local

acl help access to 'own' attributes

[Marc Roos]

Can anyone help how I should make the acls that allows users[2] access 
attributes of ldap entries[1] that have themselves listed in the 
attribute value sendmailMTAMapValue

Something like:
Access to children? ou=,ou=,ou=,dc=,dc=,dc=local 
filter=(sendmailMTAMapValue=VAR1) attrs=sendmailMTAKey
  by uid=VAR1,ou=,ou=,ou=,dc=,dc=,dc=local read


[1]
dn: 
sendmailMTAKey=t...@example.com,ou=,ou=,ou=,dc=,dc=,
dc=local
objectClass: sendmailMTA
objectClass: sendmailMTAMap
objectClass: sendmailMTAMapObject
objectClass: ritAdditionalInfo
sendmailMTAMapName: virtuser
sendmailMTACluster: mail
sendmailMTAKey: t...@example.com
sendmailMTAMapValue: testuser

[2]
uid=testuser,ou=,ou=,ou=,dc=,dc=,dc=local

switching to containers, slapd tuning?

[Marc Roos]

I have now setups with vm's with a local slapd and nscd for caching 
authentication requests. If I separate these processes eg. different container 
for slapd, different container for the application that does system 
authentication. I will not be able to share cache memory etc.

 I was wondering if I would ever be able to come near this performance with 
direct communication between slapd and the application (thus without something 
like nscd) and how to tune slapd. 

Acl on userPassword on a specfic base

[Marc Roos]

I have problems authenticating against this acl[0] with nslcd, if I 
use[1] authentication is fine. I have the impression the dn.exact is not 
able to access the password attribute, because getent shows the other 
attributes. How should I rewrite this so the dn.exact is able to read 
the password attributes from dn.subtree?


[0]
olcAccess: {0} to dn.exact="" by * read
olcAccess: {1} to dn.exact="cn=Subschema" by * read
olcAccess: {2} to attrs=userPassword,shadowLastChange by ssf=256 self 
read by ssf=256 anonymous auth by * none continue
olcAccess: {3} to 
dn.subtree="ou=,ou=,ou=eee,dc=ccc,dc=bbb,dc=aaa" by 
dn.exact="cn=system,ou=,dc=ccc,dc=bbb,dc=aaa" ssf=64 read
olcAccess: {4} to * by * none

[1]
olcAccess: {0} to dn.exact="" by * read
olcAccess: {1} to dn.exact="cn=Subschema" by * read
olcAccess: {2} to attrs=userPassword,shadowLastChange by ssf=256 self 
read by ssf=256 anonymous auth by * none
olcAccess: {3} to * by ssf=64 users read by * none

RE: LDAP loadbalancer with URL redirect

[Marc Roos]

 
haproxy?


-Original Message-
Subject: LDAP loadbalancer with URL redirect

Hi, 

I have two different LDAP ldap://ldap1 and ldap://ldap2 behind a same 
public IP 10.0.0.1 Is there a solution to make a reverse proxy with 
redirection ?
I mean if a LDAP request arrive to 10.0.0.1 with URI target 
"ldap://ldap1; , the request is redirected to server ldap1.

Thanks.

Procedure going from search query to an acl

[Marc Roos]

I have client that coredumps with these acl's. When I remove them, the 
client is getting data from the ldap server and I can see the queries it 
is doing on the server. I thougt the lines below would give access to 
ou=Services and below by test, but I guess not. 

dn: olcDatabase={-1}frontend,cn=config
olcAccess: {0} to dn.exact="" by * read
olcAccess: {1} to dn.exact="cn=Subschema" by * read
olcAccess: {2} to attrs=userPassword,shadowLastChange by ssf=256 self 
read by ssf=256 anonymous auth by * none
olcAccess: {3} to dn.exact="ou=Services,dc=example,dc=local" 
attrs="children" by dn.exact="cn=test,ou=Hosts,dc=example,dc=local" 
ssf=64 read by * break
olcAccess: {4} to dn.children="ou=Services,dc=example,dc=local" by 
dn.exact="cn=test,ou=Hosts,dc=example,dc=local" ssf=64 read
olcAccess: {5} to * by * none

acl_mask: access to entry "name=asdf,ou=Services,dc=example,dc=local", 
attr "bla" requested
acl_mask: access to entry "ou=Services,dc=example,dc=local", attr 
"entry" requested

I guess I should grep the log for the acl_mask entries not? What would 
be an adviced procedure to do this? I also do not want to get a huge 
list of acls for just one client type. Everything below 
"ou=Services,dc=example,dc=local" is test to read. (No password 
attributes stored there)

Adding syncprov to running slapd

[Marc Roos]

I am adding the syncprovider to a running server with these:

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov


dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
olcSpCheckpoint: 100 10
olcSpSessionlog: 100

However when I do slapd -VVV the overlay is not listed. Do I need to

1. restart?
2. use syncprov.la instead of syncprov?

RE: Socat tcp to local socket

[Marc Roos]

 

Got it working with this:

socat -s UNIX-LISTEN:/var/run/ldapi,unlink-early,fork  
OPENSSL:ldap.local:8443,cafile=/etc/pki/ca-trust/source/anchors/ca.crt,v
erify=0,keepalive,reuseaddr



-Original Message-
To: openldap-technical
Subject: RE: Socat tcp to local socket



With this I am able to issue just one ldap search on the socket. 
Subsequent queries fail with 'ldap_sasl_bind(SIMPLE): Can't contact LDAP 
server (-1)'

socat -d -d
OPENSSL:192.168.10.18:8443,cafile=/etc/openldap/cacerts/ca.crt,verify=0,
keepalive,reuseaddr,ignoreeof
UNIX-LISTEN:/var/run/ldapi,reuseaddr,type=1,ignoreeof

I am just wondering if this is even possible, maybe the tcp connections 
keeps an authorized session? Or ldapi communication is just different? 
If this ldapi communication is different from ldaps. I guess I am only 
left with the options like
- connecting with some forwarded ssh session to the local ldapi server 
socket
- maybe export ldapi with stunnel on the server, and capture it again 
with stunnel/socat
- look into slapd proxy/meta

RE: Socat tcp to local socket

[Marc Roos]

Hi Harry, 

I just did a build from srpm, and currently I trying to get the scenario 
of a pipe between sockets working. Just to make sure this pipe is 
working correctly before I am moving to the tcp/tls connection.

Of course my problem persists with socat using something like this.
socat -s -d -d -d -t 3 UNIX-CONNECT:/var/run/ldapi,raw,ignoreeof  
UNIX-LISTEN:/var/run/bla,raw,ignoreeof,fork

You have a suggestion how to to do this with dpipe, I have tried this 

dpipe vde_plug /var/run/ldapi = vde_plug /var/run/bla

But it does not launch nor reports the error.




-Original Message-
Subject: Re: Socat tcp to local socket

>
> With this I am able to issue just one ldap search on the socket.
> Subsequent queries fail with 'ldap_sasl_bind(SIMPLE): Can't contact 
> LDAP server (-1)'

Sure, use either very long timeouts or use an other tool, i.e. dpipe.

The problem with socat is, socat terminates after each ldapsearch.

dpipe only stops, if manual terminated. Their are some other useful 
tools in vde2 package.

>
> socat -d -d
> OPENSSL:192.168.10.18:8443,cafile=/etc/openldap/cacerts/ca.crt,verify=
> 0,
> keepalive,reuseaddr,ignoreeof
> UNIX-LISTEN:/var/run/ldapi,reuseaddr,type=1,ignoreeof
>
> I am just wondering if this is even possible, maybe the tcp 
> connections keeps an authorized session? Or ldapi communication is 
just different?
> If this ldapi communication is different from ldaps. I guess I am only 

> left with the options like
> - connecting with some forwarded ssh session to the local ldapi server 

> socket
> - maybe export ldapi with stunnel on the server, and capture it again 
> with stunnel/socat
> - look into slapd proxy/meta
>
>
>
>
>
>
>
>
>

--
Harry Jede

RE: Socat tcp to local socket

[Marc Roos]

With this I am able to issue just one ldap search on the socket. 
Subsequent queries fail with 'ldap_sasl_bind(SIMPLE): Can't contact LDAP 
server (-1)'

socat -d -d 
OPENSSL:192.168.10.18:8443,cafile=/etc/openldap/cacerts/ca.crt,verify=0,
keepalive,reuseaddr,ignoreeof  
UNIX-LISTEN:/var/run/ldapi,reuseaddr,type=1,ignoreeof

I am just wondering if this is even possible, maybe the tcp connections 
keeps an authorized session? Or ldapi communication is just different? 
If this ldapi communication is different from ldaps. I guess I am only 
left with the options like 
- connecting with some forwarded ssh session to the local ldapi server 
socket
- maybe export ldapi with stunnel on the server, and capture it again 
with stunnel/socat
- look into slapd proxy/meta

Socat tcp to local socket

[Marc Roos]

Anyone having some experience using socat (or something similar?) to 
connect to a remote slapd server tcp/tls with a local socket? I have a 
client that requires the local ldapi socket. But I do not want to 
install there an instance of slapd.

RE: any working documentation?

[Marc Roos]

 
http://www.openldap.org/doc/admin24/tls.html

And maybe something like this:
https://www.ibm.com/support/knowledgecenter/en/SSMNED_5.0.0/com.ibm.apic.cmc.doc/task_apionprem_gernerate_self_signed_openSSL.html



-Original Message-
From: Dmitri Seletski [mailto:drj...@gmail.com] 
Sent: maandag 19 augustus 2019 21:26
To: openldap-technical@openldap.org
Subject: any working documentation?

Hello.


I am new to the list, so if you gonna beat me with your feet - please 
don't hit me in the face.

I did not find help/user list. So post here.

Where can I find working documentation for OpenLDAP?

Most current i found:

https://www.openldap.org/doc/admin24/quickstart.html

It says nothing of TLS encryption. I fail to start service

See output below:



TLSMC: MozNSS compatibility interception begins.
tlsmc_intercept_initialization: INFO: entry options follow:
tlsmc_intercept_initialization: INFO: cacertdir = `/etc/openldap/certs'
tlsmc_intercept_initialization: INFO: certfile = `OpenLDAP Server'
tlsmc_intercept_initialization: INFO: keyfile = 
`/etc/openldap/certs/password'
tlsmc_convert: INFO: trying to open NSS DB with CACertDir = 
`/etc/openldap/certs'.
tlsmc_open_nssdb: INFO: trying to initialize moznss using security dir 
`/etc/openldap` prefix `certs`.
tlsmc_open_nssdb: WARN: could not initialize MozNSS context - error 
-8015.
tlsmc_convert: INFO: cannot open the NSS DB, expecting PEM configuration 
is present.
tlsmc_intercept_initialization: INFO: altered options follow:
tlsmc_intercept_initialization: INFO: cacertdir = `/etc/openldap'
tlsmc_intercept_initialization: INFO: certfile = `OpenLDAP Server'
tlsmc_intercept_initialization: INFO: keyfile = 
`/etc/openldap/certs/password'
tlsmc_intercept_initialization: INFO: successfully intercepted TLS 
initialization. Continuing with OpenSSL only.
TLSMC: MozNSS compatibility interception ends.
TLS: could not use certificate `OpenLDAP Server'.
TLS: error:02001002:system library:fopen:No such file or directory
bss_file.c:402
TLS: error:20074002:BIO routines:FILE_CTRL:system lib bss_file.c:404
TLS: error:140AD002:SSL routines:SSL_CTX_use_certificate_file:system lib
ssl_rsa.c:468
5d5af51b main: TLS init def ctx failed: -1 5d5af51b slapd destroy: 
freeing system resources.
5d5af51b slapd stopped.
5d5af51b connections_destroy: nothing to destroy.



Where can I submit errata to documentation maintainer?(as quick start 
clearly doesn't work in my default install of OpenLDAP on CentOS 7)

And how can I start SLAPD without encryption?

I can generate self signed private/public key and make ln -s of my CA 
cert folder to 'cacertdir = `/etc/openldap'', but this seems SOOO 
unnecessary. At least on 'try out' step.

Thanks in advance

Dmitri

Anyone having tested indexes for the use sendmail

[Marc Roos]

Is there maybe someone here that has tested the index use for sendmail, 
taking into account the issue Michael addresses? :)



-Original Message-
Subject: Re: mdb index reporting available?

On 8/19/19 11:22 AM, Ulrich Windl wrote:
> Can you present an example here where an index added as suggested 
> makes performance actually worse?

I sent this link before:

https://unix.stackexchange.com/questions/451118/openldap-bdb-equality-candidates-memberof-not-indexed/457561#457561

As you can see the guy asking did not accept my answer and his own 
"solution" was to just add the index without further thinking.

Ciao, Michael.

RE: Initial syncreplication details

[Marc Roos]

I am not sure if this is true. Because it looks like provider and 
consumer are a bit to long on high load for the changes that were made.


-Original Message-
Subject: Initial syncreplication details



Am I correct to understand from this page[0] that the consumer gets its 
'new' contextCSN from the slapcat import. (I saw it in the file). And 
will get all data since that date at startup? 

The replication id is of no influence. So if I would stop slapd import 
again the same old slapcat file. It would again receive all new data 
since that contextCSN? Regardless of the same rid being used with the 
provider.

The idea behind this is that if you create a container with a default 
imported slapcat/slapadd file. Every time the task is stopped and 
started. It will go back to it initial container state. (unless you make 
it statefull of course) I am not adding that much data so I could make a 
new default image every week or so, this would be used every time  a 
container is launched. 
(which only happens in a failover situation)

[0]
https://www.openldap.org/doc/admin24/replication.html

Initial syncreplication details

[Marc Roos]

Am I correct to understand from this page[0] that the consumer gets its 
'new' contextCSN from the slapcat import. (I saw it in the file). And 
will get all data since that date at startup? 

The replication id is of no influence. So if I would stop slapd import 
again the same old slapcat file. It would again receive all new data 
since that contextCSN? Regardless of the same rid being used with the 
provider.

The idea behind this is that if you create a container with a default 
imported slapcat/slapadd file. Every time the task is stopped and 
started. It will go back to it initial container state. (unless you make 
it statefull of course) 
I am not adding that much data so I could make a new default image every 
week or so, this would be used every time  a container is launched. 
(which only happens in a failover situation)

[0]
https://www.openldap.org/doc/admin24/replication.html

RE: mdb index reporting available?

[Marc Roos]

 


Nevermind, I see the statement now with the ber sync logging, after 
removing an index and then querying it




-Original Message-

Subject: RE: mdb index reporting available?

 
I do have to say I like this message at ber sync more. Enabling the 
stats is not an option to keep in production on.

RE: mdb index reporting available?

[Marc Roos]

 
I do have to say I like this message at ber sync more. Enabling the 
stats is not an option to keep in production on.

RE: mdb index reporting available?

[Marc Roos]

Hi Michael

 >
 >> I am using CentOS6/CentOS7 and currently testing with CentOS7 
default 
 >> openldap 2.4.44, but switched their default db to mdb.
 >
 >AFAIK they don't use my back-port patch for ITS#7796.
 >
 >> I am using eg sendmail as a client. So I have no clue what the 
search 
 >> queries are.
 >
 >Look at your logs to see the LDAP filter strings (loglevel stats).

Was always seeing these with ber sync

 >> I can of course copy the indexes from an 'old' environment. 
 >
 >What do you mean by "copy"? The indexing is configured with slapd.conf
 >(aka static config) or cn=config (back-config).

Over time I am adding indexes until there are no such messages (except 
for 
some incidental queries). And since I have slapd's for specific groups
I can easily determine the index settings by querying their oldDbIndex
and add those to the new setup

 >> But if I am going to allow some other task to query the ldap in the 
 >> future, I will again not know if they are accessing keys that are 
maybe 
 >> not indexed or not properly indexed.
 >
 >Again: Simply look at the logs.

Yes will enable this stats

RE: mdb index reporting available?

[Marc Roos]

I am using CentOS6/CentOS7 and currently testing with CentOS7 default 
openldap 2.4.44, but switched their default db to mdb. 
I am using eg sendmail as a client. So I have no clue what the search 
queries are. I can of course copy the indexes from an 'old' environment. 
But if I am going to allow some other task to query the ldap in the 
future, I will again not know if they are accessing keys that are maybe 
not indexed or not properly indexed.


-Original Message-
From: Michael Ströder [mailto:mich...@stroeder.com] 
Sent: zaterdag 17 augustus 2019 12:56
To: Marc Roos; openldap-technical
Subject: Re: mdb index reporting available?

On 8/17/19 12:29 PM, Marc Roos wrote:
> I used to have some help with what and how I should add indexes, but 
> it looks like the new mdb backend is not telling me anymore. Is this 
> correct? Anyway to get a warning when some index needs to be set?
> 
> bdb_equality_candidates: () not indexed
> bdb_inequality_candidates: (createTimestamp) not indexed etc

This message is not specific to a particular backend.

But anyway this message is pretty useless without closely looking at the 
search filters actually used:

https://www.openldap.org/its/index.cgi?findid=7796

Which OpenLDAP builds are you using on which platform?

Ciao, Michael.

mdb index reporting available?

[Marc Roos]

I used to have some help with what and how I should add indexes, but it 
looks like the new mdb backend is not telling me anymore. Is this 
correct? Anyway to get a warning when some index needs to be set?

bdb_equality_candidates: () not indexed
bdb_inequality_candidates: (createTimestamp) not indexed
etc

https://mishikal.wordpress.com/2013/05/16/openldap-a-comparison-of-back-mdb-and-back-hdb-performance/

Fresh install changing the hdb to mdb

[Marc Roos]

This is the default file that rhel/centos have in their slapd.d dir for 
the database. I thought I would just remove this one and place the one 
for mdb, seems to work, don't know about this entryUUID? Or can I do 
this with ldapmodify? 

[@53386e4b0025 cn=config]# cat /tmp/olcDatabase\=\{2\}hdb.ldif
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 4f2ac1fc
dn: olcDatabase={2}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=my-domain,dc=com
olcRootDN: cn=Manager,dc=my-domain,dc=com
olcDbIndex: objectClass eq,pres
olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub
structuralObjectClass: olcHdbConfig
entryUUID: 537b0adc-5476-1039-9bf9-1dc025e1859d
creatorsName: cn=config
createTimestamp: 20190816133433Z
entryCSN: 20190816133433.095410Z#00#000#00
modifiersName: cn=config
modifyTimestamp: 20190816133433Z

[@53386e4b0025 cn=config]# cat olcDatabase\=\{2\}mdb.ldif
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 b6a274bd
dn: olcDatabase={2}mdb
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {2}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=my-domain,dc=com
olcRootDN: cn=Manager,dc=my-domain,dc=com
olcDbIndex: objectClass eq,pres
olcDbIndex: ou,cn,mail,surname,givenname eq,pres,sub
structuralObjectClass: olcMdbConfig
entryUUID: 537b0adc-5476-1039-9bf9-1dc025e1859d
creatorsName: cn=config
createTimestamp: 20190816133433Z
entryCSN: 20190816133433.095410Z#00#000#00
modifiersName: cn=config
modifyTimestamp: 20190816133433Z

RE: Environment variable in slapd config

[Marc Roos]

> You're just replacing once constant with another here, why not just 
set it correctly once, in the source file?

Because the destination field is not always the same, it is different 
for different vm groups.


> Why use a rootpw at all?

I though I cannot get around using this when changing the log level or 
acls during runtime for instance?


> Why aren't you using slapadd to initialize the config?

No specific reason. 

>>  
>> Cool thanks! I am more fan of Centos because then I can fall back on 
>> RedHat support, especially for production environments. I am not sure 

>> your script is takling the issue described here, but looking at it, I 

>> think you can add also --no-cache. You should beware of ENV 
>> LDAP_ROOTPASS that stays when the task is launched (at least on 
>> mesos), better work with the hashes. Furthermore I try to run as less 

>> tasks as possible under root so I am binding to a high port ;) I also 

>> need to be able to use slapadd otherwise syncing will take to long.
>> 
>> So at the moment mine looks like this ;)
>> 
>> 
>> # Version: 0.0.1 - openldap
>> FROM centos:7
>> 
>> ENV SLAPD_USER="ldap" \
>> SLAPD_UID=10061 \
>> SLAPD_CFG_DIR="/etc/openldap/" \
>> SLAPD_DATA_DIR="/var/lib/ldap" \
>> SLAPD_KEY_DIR="/etc/pki/tls/private" \
>> SLAPD_CRT_DIR="/etc/pki/tls/certs" \
>> SLAPD_OPTS="-d 0 -4 -u ldap" \ 
>> SLAPD_URLS="ldap://0.0.0.0:8443/; 
>> 
>> # create user/group
>> RUN groupadd $SLAPD_USER -g $SLAPD_UID \
> && useradd $SLAPD_USER -u $SLAPD_UID -g $SLAPD_UID --system 

RE: Make slapadd faster?

[Marc Roos]

 

Ok ok I will look at this mdb again.


-Original Message-
From: Quanah Gibson-Mount [mailto:qua...@symas.com] 
Subject: Re: Make slapadd faster?



--On Friday, August 16, 2019 10:14 AM +0200 Marc Roos 
 wrote:

>
> I know you can disable some checks to make slapadd faster. But I think 

> in my test vm with limited disk iops, it looks like this disk io is 
> the problem.
> I am not sure how slapadd adds entries, I guess one at a time? You 
> could get a significant improvement by reading more entries and 
> writing more entries at once? And if such a batch transaction fails 
> you can always go back to submitting the transactions of the batch one 

> by one, to identify which one is failing.

Stop using back-hdb, it's signficantly slower than back-mdb.  If you're 
going to insist on using back-hdb, then you *must* have a well tuned 
DB_CONFIG before you import.

For any backend, ensure you have tool-threads set appropriately (For 
back-mdb, values > 2 are ignored).

Use the -q flag if you know the LDIF is good.

slapadd has been heavily profiled and tested.

--Quanah



--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>

RE: Environment variable in slapd config

[Marc Roos]

 
I guess I am missing some info??? Is there any animosity between 
openldap and redhat? My general perspective is RedHat has made a core 
business of supporting a linux enterprise os. So I do hope that, if the 
shit hits the fan, you can rely on the paid services based on the 
knowledge of their 10k+ employees or so? These guys that work on ceph 
are doing a great job, looks like very competent people. And now they 
are owned by IBM I like them even more. :) Always have had IBM in high 
regards with their r 





-Original Message-
Subject: RE: Environment variable in slapd config



--On Friday, August 16, 2019 5:17 PM +0200 Marc Roos 
 wrote:

> I am more fan of Centos because then I can fall back on RedHat 
> support, especially for production environments.

That's the most laughable statement (in relation to OpenLDAP at least) 
that I've heard in years.  Thanks for the morning chuckle.

--Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>

RE: Environment variable in slapd config

[Marc Roos]

 
Thanks Howard, I am already doing this for the default configuration.
I was hoping I could get around fetching secrets and importing changes
at run time.

-Original Message-
Subject: Re: Environment variable in slapd config

Marc Roos wrote:
>  
> Indeed. Ansible is just a tool you should use for the fitting job. 
> Afaik I only have to set a few variables and I do not have in the 
> hundreds of services. But I would not mind looking at your Dockerfile 
> to see how you prepare the image.
> 
> The ceph mailing list is 'full' of people using ansible, and then 
> whining on what to do, and how to fix things when something does not 
> work. Because they do not know how and where things are configured.
> All these 'easy' tools are like these higher level programming 
> languages. They just lower the threshold for the 'bunglers' to enter 
> an area of expertise, they were not able to enter before.
> 
> 
> -Original Message-
> Subject: Re: Environment variable in slapd config
> 
> 
> 
> Probably the original poster wanted to set several env vars and use 
> them as distinct RID values for multiple syncrepl directives. This is 
> a common pattern for poor man's config management.
> 
> Ciao, Michael.

For this use case the simplest approach is to start with a template file 
that uses shell variables and just let the shell do the substitution for 
you. This is exactly what the OpenLDAP test suite does for its own 
config files.

If you need to get fancier use sed or awk. These are basic Unix admin 
questions and have nothing to do with OpenLDAP.

--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

RE: Environment variable in slapd config

[Marc Roos]

n=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f 
$SLAPD_CFG_DIR/schema/apache.ldif \
&& ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f 
$SLAPD_CFG_DIR/schema/samba.ldif \
&& ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f 
$SLAPD_CFG_DIR/schema/.ldif \
&& ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f 
$SLAPD_CFG_DIR/schema/quota.ldif \

&& ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f 
$SLAPD_CFG_DIR/change-frontend.ldif \
&& rm -f $SLAPD_CFG_DIR/change-frontend.ldif \
&& ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f 
$SLAPD_CFG_DIR/change-db.ldif \
&& rm -f $SLAPD_CFG_DIR/change-db.ldif \
&& ldapadd -Q -D "cn=admin,cn=config" -Y EXTERNAL -H ldapi:/// -f 
$SLAPD_CFG_DIR/change-config-sendmail.ldif \

&& ldapadd -Q -Y EXTERNAL -H ldapi:/// -f 
$SLAPD_CFG_DIR/change-config.ldif \
&& rm -f $SLAPD_CFG_DIR/change-config.ldif \
    && kill -HUP $(cat /var/run/openldap/slapd.pid) \
&& sync \
&& chown $SLAPD_USER /var/run/ldapi

#ADD db.tgz /var/lib/ldap/
RUN [ -f "/tmp/ldap.db.gz" ] \
&& runuser -l ldap -c 'gunzip -c /tmp/ldap.db.gz | slapadd -c 2> 
/tmp/import-errors' \
&& cd /var/lib/ldap && db_checkpoint -1 -h /var/lib/ldap && 
db_archive -d \
&& rm -f /tmp/ldap.db.gz || echo "not importing ldap.db"


COPY entrypoint.sh /sbin/

CMD ["/sbin/entrypoint.sh"]




-Original Message-
From: Neal Lawson [mailto:o...@sr375.com] 
Sent: vrijdag 16 augustus 2019 15:41
To: Howard Chu
Cc: Marc Roos; michael; openldap-technical@openldap.org
Subject: Re: Environment variable in slapd config

I have been working on a docker image with a script that likely does 
almost what you want with some mods, you’re welcome to steal it and 
make your own modifications. 
https://github.com/DoctorOgg/docker-openldap



On Aug 16, 2019, at 6:36 AM, Howard Chu  wrote:

Marc Roos wrote:



Indeed. Ansible is just a tool you should use for the fitting 
job. Afaik 
I only have to set a few variables and I do not have in the 
hundreds of 
services. But I would not mind looking at your Dockerfile to 
see how you 
prepare the image.

The ceph mailing list is 'full' of people using ansible, and 
then 
whining on what to do, and how to fix things when something 
does not 
work. Because they do not know how and where things are 
configured.
All these 'easy' tools are like these higher level programming 

languages. They just lower the threshold for the 'bunglers' to 
enter an 
area of expertise, they were not able to enter before. 


-Original Message-
Subject: Re: Environment variable in slapd config



Probably the original poster wanted to set several env vars 
and use them 
as distinct RID values for multiple syncrepl directives. This 
is a 
common pattern for poor man's config management.

Ciao, Michael.



For this use case the simplest approach is to start with a template 
file that uses
shell variables and just let the shell do the substitution for you. 
This is exactly
what the OpenLDAP test suite does for its own config files.

If you need to get fancier use sed or awk. These are basic Unix 
admin questions and
have nothing to do with OpenLDAP.

-- 
 -- Howard Chu
 CTO, Symas Corp.   http://www.symas.com
 Director, Highland Sun http://highlandsun.com/hyc/
 Chief Architect, OpenLDAP  http://www.openldap.org/project/

RE: Environment variable in slapd config

[Marc Roos]

Yes and an environment variable is easy to set on task launch to a 
'unique' value or can be parsed from the marathon gui eg.



-Original Message-
Subject: Re: Environment variable in slapd config

>  
> If you have a container image, and you spawn from that multiple 
> instances, you have to be able to 'easily' change unique qualifiers, 
> not?

What part of "RIDs are supposed to be unique within a single config"
did you not understand?

If you run multiple instances, each one has its own config. It doesn't 
matter if you use the same RID in multiple configs.
> 
> 
> -Original Message-
> Subject: Re: Environment variable in slapd config
> 
> Michael Ströder wrote:
>> On 8/16/19 12:02 PM, Marc Roos wrote:
>>> Is it possible to reference an environment variable in olcSyncrepl: 
>>> {0}rid= ?
>>
>> No.
> 
> The example doesn't even make sense. RIDs are supposed to be unique 
> within a single config, there's no reason for them to have any global 
> context such as an env var would imply.
>>
>> My recommendation is to use a decent config managment (ansible, chef, 

>> puppet, salt, ..) for the job.



--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

RE: Environment variable in slapd config

[Marc Roos]

 
Indeed. Ansible is just a tool you should use for the fitting job. Afaik 
I only have to set a few variables and I do not have in the hundreds of 
services. But I would not mind looking at your Dockerfile to see how you 
prepare the image.

The ceph mailing list is 'full' of people using ansible, and then 
whining on what to do, and how to fix things when something does not 
work. Because they do not know how and where things are configured.
All these 'easy' tools are like these higher level programming 
languages. They just lower the threshold for the 'bunglers' to enter an 
area of expertise, they were not able to enter before. 


-Original Message-
Subject: Re: Environment variable in slapd config



Probably the original poster wanted to set several env vars and use them 
as distinct RID values for multiple syncrepl directives. This is a 
common pattern for poor man's config management.

Ciao, Michael.

RE: Environment variable in slapd config

[Marc Roos]

 
If you have a container image, and you spawn from that multiple 
instances, you have to be able to 'easily' change unique qualifiers, 
not?


-Original Message-
Subject: Re: Environment variable in slapd config

Michael Ströder wrote:
> On 8/16/19 12:02 PM, Marc Roos wrote:
>> Is it possible to reference an environment variable in olcSyncrepl: 
>> {0}rid= ?
> 
> No.

The example doesn't even make sense. RIDs are supposed to be unique 
within a single config, there's no reason for them to have any global 
context such as an env var would imply.
> 
> My recommendation is to use a decent config managment (ansible, chef, 
> puppet, salt, ..) for the job.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

RE: Antw: RE: Openldap in container advice, how have you done it?

[Marc Roos]

The ip address is known when I start the container that would mean I 
need to sed some ready ldif and import it into the slapd at runtime. 
That would also require the the availability of some secret to be able 
to import it. 

Although I have prepared the container for ldif fetching. Nicer would be 
if I could specify something like an environment variable in olcSyncrepl



-Original Message-
From: Ulrich Windl [mailto:ulrich.wi...@rz.uni-regensburg.de] 
Sent: maandag 12 augustus 2019 8:56
To: Marc Roos
Subject: Antw: RE: Openldap in container advice, how have you done it?

 >>> "Marc Roos"  schrieb am 10.08.2019 um 
14:07 in Nachricht 
<"H0710014b895.1565438831.sx.f1-outsourcing.eu*"@MHS>:

> Ok so long rep id is not going to work modifying entry 
> "olcDatabase={2}hdb,cn=config"
> ldap_modify: Other (e.g., implementation specific) error (80)
>  additional info: Error: parse_syncrepl_line: syncrepl id 
> 1911533132 is out of range [0..999]

Why not derive the ID from some container ID or from the container's IP 
address?

> 
> 
> 
> 
> ‑Original Message‑
> From: Marc Roos
> Sent: zaterdag 10 augustus 2019 1:24
> To: openldap‑techni...@openldap.org
> Subject: Openldap in container advice, how have you done it?
> 
> 
> 
> I was thinking of putting read‑only slapd('s) in a container 
> environment so other tasks can query their data. Up until now I have 
> had replication only between vm's.
> 
> To be more flexible I thought of using stateless containers. Things 
> that could be caveats
> 
> ‑ replication id's
> say I spawn another instance, I need to have a new replication id to 
> get updates from the master. But what if the tasks is killed, should I 

> keep this replication id? Or better just always use a random unique 
> replication id whenever a slapd container is launched? Maybe use 
> launch date/time (date +'%g%H%M%S%2N') as repid? Is this giving issues 

> with the master? What if I test with launching instances and the 
> master will think there are a hundred slaves that are not connecting 
anymore?
> 
> ‑ updating of a newly spawned slapd instance When the new task is 
> launched, it is not up to date with its database, can I prevent 
> connections to the slapd until it is fully synced?
> Say I have user id's in slapd, it could be that when launching a new 
> instance, this user is not available yet. When clients are requesting 
> this data, they do not get it, and this user could be 'offline' until 
> that specific instance of slapd is fully updated.
> 
> ‑ to prevent lots of records syncing
> Can I just copy the data of /var/lib/ldap of any running instance to 
> the container default image? Or does it have some unique id's that 
> will prevent this data to be run multiple times? Is there some advice 
> on how to do this?
> 
> ‑ doing some /var/lib/ldap cleanup
> I am cleaning with db_checkpoint ‑1 ‑h /var/lib/ldap, and db_archive 
‑d. 
> Is there an option slapd can initiate this? 
> 
> ‑ keep uniform configuration environment, or better a few different 
> slapd instances?
> In my current environment vm slave slapd's only sync data from the 
> master that the masters acls allow access to. That results in that on 
> some vm's the ldap database is quite small and on other it is larger.
> I think for the container slapd instances to have all data, and just 
> limit client access via the acls. But this means a lot more indexes on 

> the slapd
> 
> What else am I missing?

Environment variable in slapd config

[Marc Roos]

 

Is it possible to reference an environment variable in olcSyncrepl: 
{0}rid= ?



--On Saturday, August 10, 2019 6:54 PM +0200 Michael Ströder 
 wrote:

> Are you talking about the serverID?
>
> serverID is not needed on a read-only consumer. Just leave it out.

He's talking about replication ID (rid), and it's clearly out of bounds 
in his post.  The slapd.conf/slapd-config man pages clearly document the 
allowed range that can be used for a RID.

  rid   identifies  the  current  syncrepl  directive  
within 
the
  replication consumer site.  It is  a  non-negative  
integer not
  greater than 999 (limited to three decimal digits

--Quanah



--

RE: Openldap in container advice, how have you done it?

[Marc Roos]

 >On Sat, Aug 10, 2019 at 01:23:41AM +0200, Marc Roos wrote:
 >>- updating of a newly spawned slapd instance
 >>When the new task is launched, it is not up to date with its 
database,
 >>can I prevent connections to the slapd until it is fully synced?
 >
 >This is not implemented at this time. See ITS#7616 
 ><https://openldap.org/its/?findid=7616>.
 
Hmm interesting. Maybe we can differentiate between a recent startup and 

getting up-to-date with the provider. 
As opposed to blocking client requests with LDAP_BUSY during a 'normal'
sync
 
 
 >>- to prevent lots of records syncing
 >>Can I just copy the data of /var/lib/ldap of any running instance to 
the
 >>container default image?
 >
 >Maybe, if they are all running identical software and configuration. 
The 
 >more robust way to do it is slapcat the database on a known-good 
system, 
 >and slapadd it on the new one you're bringing up. In current versions 
it 
 >is safe to use slapcat (but not slapadd) while slapd is running.
 
Yes doing this now with creating the docker image.
 
 >>- doing some /var/lib/ldap cleanup
 >>I am cleaning with db_checkpoint -1 -h /var/lib/ldap, and db_archive 
-d.
 >>Is there an option slapd can initiate this?
 >
 >See <https://www.openldap.org/doc/admin24/maintenance.html>.
 >
 >Checkpointing can be configured using the 'checkpoint' directive (with 

 >slapd.conf, olcDbCheckpoint with slapd-config).
 >
 >The DB_CONFIG flag DB_LOG_AUTOREMOVE causes transaction logs to be 
 >cleaned up automatically.

Thanks!

 >But please consider migrating to the LMDB backend, which does not 
 >require any such maintenance.
 >
 
When I have finished migrating the centos7 vm to centos7 containers, 
do not want to do to many changes at once.