OpenLDAP results limited via SSL?
by a.leurs＠consense-gmbh.de
Hello,
I have installed OpenLDAP on my Windows machine (Windows 10) and configured a connection to our company LDAP.
The connection is via LDAPS.
Here is my slapd.conf
#LDAP Backend configuration file
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
ucdata-path ./ucdata
include ./schema/core.schema
include ./schema/cosine.schema
include ./schema/nis.schema
include ./schema/inetorgperson.schema
pidfile ./run/slapd.pid
argsfile ./run/slapd.args
# Full log level
loglevel 32768 16384 2048 1024 512 256 128 64 32 16 8 4 2 1
sizelimit 10000
timelimit 10000
# Enable TLS if port is defined for ldaps (to openldap)
TLSVerifyClient never
#TLSCipherSuite ECDHE-RSA-AES256-SHA384:AES256-SHA256:!RC4:HIGH:!MD5:!aNULL:!EDH:!EXP:!SSLV2:!eNULL
TLSCipherSuite HIGH:MEDIUM:-SSLv2:-SSLv3
TLSProtocolMin 3.3
TLSCertificateFile ./secure/certs/maxcrc.cert.pem
TLSCertificateKeyFile ./secure/certs/maxcrc.key.pem
TLSCACertificateFile ./secure/certs/maxcrc.cert.pem
# Configuration for Connection to company.local
database meta
suffix "DC=company,DC=local"
rootdn "DC=company,DC=local"
rebind-as-user yes
uri ldaps://DC001.company.local:636/dc=company,DC=local
lastmod off
chase-referrals no
idassert-bind bindmethod=simple
binddn="cn=CN=User Name,OU=Users,OU=Orga,DC=company,DC=local"
credentials=XXX
tls_reqcert=never
tls_cacert=./secure/certs/company-ca.pem
tls ldaps tls_reqcert=allow tls_cacert=./secure/certs/company-ca.pem
overlay rwm
rwm-map attribute uid samaccountname
rwm-map attribute member memberOf
rwm-map attribute sn sn
rwm-map attribute givenname givenname
rwm-map attribute intials initials
When I connect to the OpenLDAP server with Softerra LDAP-Browser and search the directory I don't get any results, when the results are more than 65 entries.
When I use paging in the search (to restrict the results to only 65 results) then it works.
On a machine of a colleague the limit is 70 results.
We didn't find any information where an restriction on the LDAP server could be.
Any idea why the results are limited?
When I do a connection without SSL it works fine.
2 years, 8 months
[Question]: centos8 install - looking for migrationtools package
by Dave Macias
Hello,
Our production env is centos7 and we were testing to see how it would work
on centos8.
There were no issues using the symas pkgs. Thank you for providing them!
I was wondering if someone knew where I could find the migrationtools for
centos8?
I think since rhel stopped supporting openldap-servers, it would make sense
that the migrationtools package would disappear too.
Perhaps this is not the right place to ask, but any input is much
appreciated.
Thank you,
Dave
2 years, 8 months
Re: [EXT] Re: syncrepl does not work as expected
by kumar rahul
Hi Quanah
Both the servers are set up as master as well as consumer so that sync
works in both directions. So
the sync setup is like "A -> B",
and when A fails B is updated and the expectation is that "B -> A" should
work because a multi master setup is already in place. Let me know based on
the attached configuration files if my assumption is correct or not.
Also Add data works when A fails and B is updated then sync "B -> A"works
fine.
After Delete data sync does not work when A fails and data is deleted from
B. Once A comes back both databases have data which was deleted on B.
Thanks
Rahul
On Tue, Jun 23, 2020 at 8:11 AM Ulrich Windl <
Ulrich.Windl(a)rz.uni-regensburg.de> wrote:
> >>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am 22.06.2020 um 18:09
> in
> Nachricht
> <13855_1592842197_5EF0D7D5_13855_226_1_A497B27F9A5328340A4CDBAC@
> [192.168.1.144]>
>
>
> >
> > ‑‑On Monday, June 22, 2020 3:08 PM +0000 Kumar Rahul
> > <rahul2002mit(a)gmail.com> wrote:
> >
> >> Hi Quanah
> >>
> >> Thank you for all the help so far. I am still seeing the original
> >> issue reported. Let me know if you need fresh set of configuration
> >> information.
> >
> > I've told you repeatedly what is necessary, you haven't provided it.
> >
> > To re‑iterate:
> >
> > Full configuration of both servers, not config snippets or LDAP modify
> > change code.
>
> Actually (if I read the description correctly the sync setup is like "A ->
> B",
> and when A fails B is updated and expectation is that "B -> A" will work
> automagically (which is not true IMHO). Then multi-master setup is needed.
>
> >
> > Regards,
> > Quanah
> >
> >
> >
> > ‑‑
> >
> > Quanah Gibson‑Mount
> > Product Architect
> > Symas Corporation
> > Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> > <http://www.symas.com>
>
>
>
>
2 years, 8 months
Re: [EXT] Re: syncrepl does not work as expected
by kumar rahul
Hi Ulrich
Both the servers are set up as master as well as consumer so that sync
works in both directions. So
the sync setup is like "A -> B",
and when A fails B is updated and the expectation is that "B -> A" should
work because a multi master setup is already in place. Let me know based on
the attached configuration files if my assumption is correct or not.
Also Add data works when A fails and B is updated then sync "B -> A"works
fine.
After Delete data sync does not work when A fails and data is deleted from
B. Once A comes back both databases have data which was deleted on B.
Thanks
Rahul
On Tue, Jun 23, 2020 at 8:11 AM Ulrich Windl <
Ulrich.Windl(a)rz.uni-regensburg.de> wrote:
> >>> Quanah Gibson-Mount <quanah(a)symas.com> schrieb am 22.06.2020 um 18:09
> in
> Nachricht
> <13855_1592842197_5EF0D7D5_13855_226_1_A497B27F9A5328340A4CDBAC@
> [192.168.1.144]>
>
>
> >
> > ‑‑On Monday, June 22, 2020 3:08 PM +0000 Kumar Rahul
> > <rahul2002mit(a)gmail.com> wrote:
> >
> >> Hi Quanah
> >>
> >> Thank you for all the help so far. I am still seeing the original
> >> issue reported. Let me know if you need fresh set of configuration
> >> information.
> >
> > I've told you repeatedly what is necessary, you haven't provided it.
> >
> > To re‑iterate:
> >
> > Full configuration of both servers, not config snippets or LDAP modify
> > change code.
>
> Actually (if I read the description correctly the sync setup is like "A ->
> B",
> and when A fails B is updated and expectation is that "B -> A" will work
> automagically (which is not true IMHO). Then multi-master setup is needed.
>
> >
> > Regards,
> > Quanah
> >
> >
> >
> > ‑‑
> >
> > Quanah Gibson‑Mount
> > Product Architect
> > Symas Corporation
> > Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> > <http://www.symas.com>
>
>
>
>
2 years, 8 months
syncrepl does not work as expected
by rahul2002mit＠gmail.com
Hi
I am using LDAP protocol as front end and Berkeley DB as back end. I am observing a strange syncrepl issue
type=refreshAndPersist is being used
$OpenLDAP: slapd 2.4.44
OS: RHEL7U6
I have 2 server setup say S1 and S2. S1 is in provider and S2 is in consumer mode. Added data D1 in database and that was synced with S2 database. Now I killed slapd process on server S1.
At this point server S2 assumes provider role. Now I removed data D1 from database using server S2. Once deletion is complete validated that data was removed from server S2 database.
Now i brought S1 slapd service back up and started the application which starts syncrepl.
Here is what i see
both server S1 and S2 has data D1 which was actually deleted.
Expected behavior: Both server should sync properly and data D1 which was deleted using Server S2 should not be present in the database after sync.
Request you guys to help.
Thanks
Rahul
2 years, 9 months
Privileges for slapd service
by darkdragon
Dockerfile:
```Dockerfile
FROM debian:buster
ENV container docker
# systemd
RUN apt-get update && apt-get install -y \
systemd systemd-sysv && \
apt-get clean && \
rm -rf /var/lib/apt/lists/*
RUN systemctl disable systemd-resolved.service
RUN systemctl disable systemd-hostnamed.service
STOPSIGNAL SIGRTMIN+3
CMD [ "/sbin/init" ]
RUN apt-get update && DEBIAN_FRONTEND=noninteractive apt-get install
-y --no-install-recommends \
slapd && \
apt-get clean && rm -rf /var/lib/apt/lists/*
RUN systemctl enable slapd.service
# Allow restart of slapd after dpkg-reconfigure (docker forbids this by default)
RUN bash -c "install -m755 <(printf '#!/bin/sh\nexit 0') /usr/sbin/policy-rc.d"
```
Build command:
```sh
docker build -t tmp .
```
Run command:
```sh
docker run \
--name=tmp \
-it \
--tmpfs /run \
--tmpfs /run/lock \
--tmpfs /tmp \
-v /sys/fs/cgroup:/sys/fs/cgroup:ro \
--rm \
tmp
```
Slapd restart (run within container):
```sh
service slapd restart
```
Log (journalctl -u slapd):
Jun 18 07:14:25 81bb7d58af2b systemd[1]: Starting LSB: OpenLDAP
standalone server (Lightweight Directory Access Protocol)...
Jun 18 07:14:25 81bb7d58af2b slapd[39]: @(#) $OpenLDAP: slapd (Apr 20
2020 18:19:54) $
Debian OpenLDAP
Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org>
Jun 18 07:14:25 81bb7d58af2b slapd[40]: slapd starting
Jun 18 07:14:25 81bb7d58af2b slapd[27]: Starting OpenLDAP: slapd.
Jun 18 07:14:25 81bb7d58af2b systemd[1]: Started LSB: OpenLDAP
standalone server (Lightweight Directory Access Protocol).
Jun 18 07:14:35 81bb7d58af2b systemd[1]: Stopping LSB: OpenLDAP
standalone server (Lightweight Directory Access Protocol)...
Jun 18 07:14:35 81bb7d58af2b slapd[72]: Stopping OpenLDAP: slapd.
Jun 18 07:14:35 81bb7d58af2b systemd[1]: slapd.service: Succeeded.
Jun 18 07:14:35 81bb7d58af2b systemd[1]: Stopped LSB: OpenLDAP
standalone server (Lightweight Directory Access Protocol).
Jun 18 07:14:40 81bb7d58af2b systemd[1]: slapd.service: Found
left-over process 40 (slapd) in control group while starting unit.
Ignoring.
Jun 18 07:14:40 81bb7d58af2b systemd[1]: This usually indicates
unclean termination of a previous run, or service implementation
deficiencies.
Jun 18 07:14:40 81bb7d58af2b systemd[1]: Starting LSB: OpenLDAP
standalone server (Lightweight Directory Access Protocol)...
Jun 18 07:14:40 81bb7d58af2b slapd[99]: Starting OpenLDAP: slapd failed!
Jun 18 07:14:40 81bb7d58af2b systemd[1]: slapd.service: Control
process exited, code=exited, status=1/FAILURE
Jun 18 07:14:40 81bb7d58af2b systemd[1]: slapd.service: Failed with
result 'exit-code'.
Jun 18 07:14:40 81bb7d58af2b systemd[1]: Failed to start LSB: OpenLDAP
standalone server (Lightweight Directory Access Protocol).
---
The problem seems to be an unclean stop (left-over process) which
still occupies the port.
Which capabilities [1] / seccomp [2] is needed by slapd?
[1]: https://linux.die.net/man/7/capabilities
[2]: https://docs-stage.docker.com/engine/security/seccomp/
---
My goal is to set the domain to "thisbox".
Running the following code (within container):
```sh
cat <<EOF >/tmp/slapd
Name: slapd/domain
Template: slapd/domain
Value: thisbox
Owners: slapd
EOF
DEBIAN_FRONTEND=noninteractive DEBCONF_DB_OVERRIDE=/tmp/slapd
dpkg-reconfigure slapd
```
Log (journalctl -u slapd):
-- Logs begin at Thu 2020-06-18 07:43:44 UTC, end at Thu 2020-06-18
07:44:57 UTC. --
Jun 18 07:43:44 fe1ddc01fdaf systemd[1]: Starting LSB: OpenLDAP
standalone server (Lightweight Directory Access Protocol)...
Jun 18 07:43:44 fe1ddc01fdaf slapd[38]: @(#) $OpenLDAP: slapd (Apr 20
2020 18:19:54) $
Debian OpenLDAP
Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org>
Jun 18 07:43:44 fe1ddc01fdaf slapd[39]: slapd starting
Jun 18 07:43:44 fe1ddc01fdaf slapd[28]: Starting OpenLDAP: slapd.
Jun 18 07:43:44 fe1ddc01fdaf systemd[1]: Started LSB: OpenLDAP
standalone server (Lightweight Directory Access Protocol).
Jun 18 07:43:48 fe1ddc01fdaf systemd[1]: Stopping LSB: OpenLDAP
standalone server (Lightweight Directory Access Protocol)...
Jun 18 07:43:48 fe1ddc01fdaf slapd[160]: Stopping OpenLDAP: slapd.
Jun 18 07:43:48 fe1ddc01fdaf systemd[1]: slapd.service: Succeeded.
Jun 18 07:43:48 fe1ddc01fdaf systemd[1]: Stopped LSB: OpenLDAP
standalone server (Lightweight Directory Access Protocol).
Jun 18 07:43:48 fe1ddc01fdaf systemd[1]: Starting LSB: OpenLDAP
standalone server (Lightweight Directory Access Protocol)...
Jun 18 07:43:48 fe1ddc01fdaf slapd[170]: @(#) $OpenLDAP: slapd (Apr
20 2020 18:19:54) $
Debian OpenLDAP
Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org>
Jun 18 07:43:48 fe1ddc01fdaf slapd[170]: daemon: bind(8) failed
errno=98 (Address already in use)
Jun 18 07:43:48 fe1ddc01fdaf slapd[170]: daemon: bind(8) failed
errno=98 (Address already in use)
Jun 18 07:43:48 fe1ddc01fdaf slapd[170]: slapd stopped.
Jun 18 07:43:48 fe1ddc01fdaf slapd[170]: connections_destroy: nothing
to destroy.
Jun 18 07:43:48 fe1ddc01fdaf slapd[165]: Starting OpenLDAP: slapd failed!
Jun 18 07:43:48 fe1ddc01fdaf systemd[1]: slapd.service: Control
process exited, code=exited, status=1/FAILURE
Jun 18 07:43:48 fe1ddc01fdaf systemd[1]: slapd.service: Failed with
result 'exit-code'.
Jun 18 07:43:48 fe1ddc01fdaf systemd[1]: Failed to start LSB: OpenLDAP
standalone server (Lightweight Directory Access Protocol).
So the problem indicates that the address is already in use.
---
Setting the configuration within Dockerfile (no need to restart in container):
```Dockerfile
RUN echo "" >> /tmp/slapd && \
echo "Name: slapd/domain" >> /tmp/slapd && \
echo "Template: slapd/domain" >> /tmp/slapd && \
echo "Value: thisbox" >> /tmp/slapd && \
echo "Owners: slapd" >> /tmp/slapd && \
echo "" >> /tmp/slapd && \
DEBIAN_FRONTEND=noninteractive \
DEBCONF_DB_OVERRIDE=/tmp/slapd \
dpkg-reconfigure slapd
```
doesn't throw any error, but doesn't seem to work either.
```sh
ldapadd -Q -Y EXTERNAL -H ldapi:///
```
logs to stdout:
```
adding new entry "ou=users,dc=thisbox"
ldap_add: Server is unwilling to perform (53)
additional info: no global superior knowledge
```
So for some reason the setup on container creation doesn't seem to be used.
---
I am new to LDAP, so I am apologizing if I am using something
completely wrongly. Just trying to fix
https://salsa.debian.org/freedombox-team/freedombox/-/issues/1880.
Any help appreciated!
2 years, 9 months
ldapsearch filter behaviour
by mradu＠live.com
Hi,
I have 2 LDAP servers. The old one is running openldap2-2.3.32 and the new one is running openldap2-2.4.41.
They both have identical configuration and data.
Running the following ldapsearch command against the 2 servers only yields results on the old openldap 2.3.32:
ldapsearch -H ldap://server -b 'dc=mycorp,dc=com' -D 'cn=Administrator,dc=mycorp,dc=com' -w 'passwd' '(cn=*)' cn
Aparently every time I am using a filter having the "*" wildcard the new openldap fails to give back any results. Any ideea what is going on?
Thanks
2 years, 9 months
Re: Info needed on OpenLDAP support / compliance on FIPS 140.2
by Vijay Kumar
Thank you Quanah,
As i mentioned, we are using OpenLDAP 2.4.48 version from
https://www.openldap.org/ which internally uses OpenSSL
I would like to know, is this version of OpenLDAP with OpennSSL does FIPS
compliant.?
Regards,
Vijay Kumar
On Mon, Jun 15, 2020 at 10:22 PM Quanah Gibson-Mount <quanah(a)symas.com>
wrote:
>
>
> --On Monday, June 15, 2020 5:03 PM +0530 Vijay Kumar
> <pasumarthivijaykumar(a)gmail.com> wrote:
>
> >
> > Hi Team,
> >
> >
> > We are using the version 2.4.48 OpenLDAP, we would like to know which
> > versions of OpenLDAP which used OpenSSL are compliant towards FIPS 140.2
> > standards.?
>
> Hello,
>
> Do *NOT* post to multiple lists.
>
> The FIPS question is not really an OpenLDAP question at all. Either the
> build of OpenLDAP you are using is linked to a FIPS version of OpenSSL or
> it isn't. You'd need to find out from whomever provided your OpenLDAP
> build (and that's assuming it's linked to OpenSSL) if that OpenSSL build
> is
> FIPS enabled.
>
> Reards,
> Quaanh
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
--
Thanks & Regards,
Vijay Kumar
*+91-94944 44009*
2 years, 9 months
Re: Re: Info needed on OpenLDAP support / compliance on FIPS 140.2
by Vijay Kumar
Thanks a lot Philip Guenther
Absolute needful Info to all.
Regards,
Vijay Kumar
On Tue, Jun 16, 2020 at 1:43 PM Marc Roos <M.Roos(a)f1-outsourcing.eu> wrote:
>
> Thanks for this clear insight!
>
>
> -----Original Message-----
> To: Scott Classen
> Cc: Vijay Kumar; openldap-technical(a)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
>
>
>
--
Thanks & Regards,
Vijay Kumar
*+91-94944 44009*
2 years, 9 months
Re: syncrepl does not work as expected
by Giuseppe De Marco
Ciao kumar,
A fully working example, configurable with ansible with delta syncrepl
ready to go, for studies and prototyping, Is here:
https://github.com/peppelinux/ansible-slapd-eduperson2016
Run as It come in a container, for a replica node see delta repl readme,
Have fun and don't give up
Il lun 15 giu 2020, 21:29 Quanah Gibson-Mount <quanah(a)symas.com> ha scritto:
>
>
> --On Monday, June 15, 2020 8:05 PM +0000 Kumar Rahul
> <rahul2002mit(a)gmail.com> wrote:
>
> > dn: olcDatabase={1}mdb,cn=config
> > objectClass: olcMdbConfig
> > olcDatabase: {1}mdb
> > olcDbDirectory: /usr/local/var/openldap-data/data_db
> > olcSuffix: dc=smartsan
> > olcRootDN: cn=info,dc=data
> > olcAccess: {0}to * by dn.base="cn=info,dc=data" read by * break
>
> Assuming the above is your actual configuration, then..
>
> Your sync replication configuration uses:
>
> binddn="cn=admin,dc=smartsan"
>
> But this identity is given no access to your database, as it's not the
> rootDN, and there are no ACLs providing access to it.
>
> As an aside, your ACL {0} makes no sense since you have cn=info,cn=data as
> your rootdn, and rootdn's are not subject to access control. The only
> other thing it does is break to the default ACL of to * by * none.
>
> Regards,
> Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
--
------------------------------------------------------------------------------------------------------------------
Il banner è generato automaticamente dal servizio di posta elettronica
dell'Università della Calabria
<https://www.unical.it/portale/portaltemplates/view/view.cfm?100061>
2 years, 9 months
