ACL for sync reader
by Frédéric Goudal
Hello,
I have a production ldap with some acl set. For historical reason the synchronizationn is done with the root dn which is bad.
I want to add a user to perform synchronization it must have the right to read everytthing.
is the acl :
access to * by dn.exact=<somedn> break
added in first position be enough to read everything (even attributs that have been limited on some other acl) AND not break the current configuration ?
Thanks in advance.
f.g.
2 years, 3 months
Re: Is there any easy way to decode openldap logs
by chandan jain
It is openldap-2.4.32, i don't see any mdb support option while compiling .
It is compiled with below options:
tar -xzf db-5.3.21.tar.gz
tar -zxf openldap-2.4.32.tgz
cd db-5.3.21
cd build_unix/
../dist/configure --enable-compat185 --enable-dbm --disable-static
--enable-cxx && make && make install
db_verify -V
cd ../..
cd openldap-2.4.32
./configure --prefix=/usr/local/OpenLDAP --with-tls=no --enable-modules=yes
--enable-overlays=yes --enable-ppolicy=yes && make depend && make && make
install
Regards
Chandan
On Thu, 4 Mar 2021 at 22:48, Quanah Gibson-Mount <quanah(a)symas.com> wrote:
>
>
> --On Thursday, March 4, 2021 10:40 PM +0530 chandan jain
> <chandandevops(a)gmail.com> wrote:
>
> >
> >
> > Thanks quanah, I will change log level to 256 to see the results.
> >
> >
> > Also, is it possible to migrate from bdb to mdb, the ldap is mirror mode
> > sync with 2 nodes and it is compiled version not a rpm one.
>
> Assuming it was built with back-mdb support, yes. I have no idea what
> release you're running, but you'll want a current one.
>
> --Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
2 years, 3 months
Re: Is there any easy way to decode openldap logs
by chandan jain
Thanks quanah, I will change log level to 256 to see the results.
Also, is it possible to migrate from bdb to mdb, the ldap is mirror mode
sync with 2 nodes and it is compiled version not a rpm one.
Regards
Chandan
On Thu, Mar 4, 2021, 21:49 Quanah Gibson-Mount <quanah(a)symas.com> wrote:
>
>
> --On Thursday, March 4, 2021 12:00 PM +0530 chandan jain
> <chandandevops(a)gmail.com> wrote:
>
> >
> > Hi Techies,
> >
> >
> > I am new to openLDAP, i am reading its log file. Is their any easy way to
> > decode the logs to identify what is going on?
>
> I would suggest simply setting a loglevel of "stats". You're currently
> going to suffer from information overload.
>
> I'd also note that the BDB backend is deprecated and is generally not
> recommended for use.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
2 years, 3 months
Is there any easy way to decode openldap logs
by chandan jain
Hi Techies,
I am new to openLDAP, i am reading its log file. Is their any easy way to
decode the logs to identify what is going on?
Please see below logs:
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 1 descriptor
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on:
Mar 3 03:22:01 myserver OpenLDAP[53304]:
Mar 3 03:22:01 myserver OpenLDAP[53304]: slap_listener_activate(7):
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: epoll: listen=7 busy
Mar 3 03:22:01 myserver OpenLDAP[53304]: >>> slap_listener(ldap://
0.0.0.0:389)
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: listen=7, new connection
on 19
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 1 descriptor
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on:
Mar 3 03:22:01 myserver OpenLDAP[53304]:
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: added 19r (active)
listener=(nil)
Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 fd=19 ACCEPT from IP=
10.101.21.156:60358 (IP=0.0.0.0:389)
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: epoll: listen=7
active_threads=0 tvp=zero
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 2 descriptors
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on:
Mar 3 03:22:01 myserver OpenLDAP[53304]: 19r
Mar 3 03:22:01 myserver OpenLDAP[53304]:
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: read active on 19
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: epoll: listen=7
active_threads=0 tvp=zero
Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_get(19)
Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_get(19): got
connid=103380
Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_read(19): checking for
input on id=103380
Mar 3 03:22:01 myserver OpenLDAP[53304]: op tag 0x60, time 1614759721
Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=0 do_bind
Mar 3 03:22:01 myserver OpenLDAP[53304]: >>> dnPrettyNormal:
<cn=Manager,dc=icma-web,dc=com>
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 1 descriptor
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on:
Mar 3 03:22:01 myserver OpenLDAP[53304]: <<< dnPrettyNormal:
<cn=Manager,dc=icma-web,dc=com>, <cn=manager,dc=icma-web,dc=com>
Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=0 BIND
dn="cn=Manager,dc=icma-web,dc=com" method=128
Mar 3 03:22:01 myserver OpenLDAP[53304]: do_bind: version=3
dn="cn=Manager,dc=icma-web,dc=com" method=128
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: epoll: listen=7
active_threads=0 tvp=zero
Mar 3 03:22:01 myserver OpenLDAP[53304]: ==> bdb_bind: dn:
cn=Manager,dc=icma-web,dc=com
Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=0 BIND
dn="cn=Manager,dc=icma-web,dc=com" mech=SIMPLE ssf=0
Mar 3 03:22:01 myserver OpenLDAP[53304]: do_bind: v3 bind:
"cn=Manager,dc=icma-web,dc=com" to "cn=Manager,dc=icma-web,dc=com"
Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_result: conn=103380
op=0 p=3
Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_result: err=0
matched="" text=""
Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_response: msgid=1
tag=97 err=0
Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=0 RESULT tag=97
err=0 text=
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 1 descriptor
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on:
Mar 3 03:22:01 myserver OpenLDAP[53304]: 19r
Mar 3 03:22:01 myserver OpenLDAP[53304]:
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: read active on 19
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: epoll: listen=7
active_threads=0 tvp=zero
Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_get(19)
Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_get(19): got
connid=103380
Mar 3 03:22:01 myserver OpenLDAP[53304]: connection_read(19): checking for
input on id=103380
Mar 3 03:22:01 myserver OpenLDAP[53304]: op tag 0x63, time 1614759721
Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=1 do_search
Mar 3 03:22:01 myserver OpenLDAP[53304]: >>> dnPrettyNormal:
<dc=icma-web,dc=com>
Mar 3 03:22:01 myserver OpenLDAP[53304]: <<< dnPrettyNormal:
<dc=icma-web,dc=com>, <dc=icma-web,dc=com>
Mar 3 03:22:01 myserver OpenLDAP[53304]: SRCH "dc=icma-web,dc=com" 2 0
Mar 3 03:22:01 myserver OpenLDAP[53304]: 0 0 0
Mar 3 03:22:01 myserver OpenLDAP[53304]: begin get_filter
Mar 3 03:22:01 myserver OpenLDAP[53304]: EQUALITY
Mar 3 03:22:01 myserver OpenLDAP[53304]: end get_filter 0
Mar 3 03:22:01 myserver OpenLDAP[53304]: filter: (uid=icma_emp_1emp113)
Mar 3 03:22:01 myserver OpenLDAP[53304]: attrs:
Mar 3 03:22:01 myserver OpenLDAP[53304]:
Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=1 SRCH
base="dc=icma-web,dc=com" scope=2 deref=0 filter="(uid=icma_emp_1emp113)"
Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_search
Mar 3 03:22:01 myserver OpenLDAP[53304]: bdb_dn2entry("dc=icma-web,dc=com")
Mar 3 03:22:01 myserver OpenLDAP[53304]: => access_allowed: search access
to "dc=icma-web,dc=com" "entry" requested
Mar 3 03:22:01 myserver OpenLDAP[53304]: <= root access granted
Mar 3 03:22:01 myserver OpenLDAP[53304]: => access_allowed: search access
granted by manage(=mwrscxd)
Mar 3 03:22:01 myserver OpenLDAP[53304]: search_candidates:
base="dc=icma-web,dc=com" (0x00000001) scope=2
Mar 3 03:22:01 myserver OpenLDAP[53304]: =>
bdb_dn2idl("dc=icma-web,dc=com")
Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_filter_candidates
Mar 3 03:22:01 myserver OpenLDAP[53304]: #011AND
Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_list_candidates 0xa0
Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_filter_candidates
Mar 3 03:22:01 myserver OpenLDAP[53304]: #011OR
Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_list_candidates 0xa1
Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_filter_candidates
Mar 3 03:22:01 myserver OpenLDAP[53304]: #011EQUALITY
Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_equality_candidates
(objectClass)
Mar 3 03:22:01 myserver OpenLDAP[53304]: => key_read
Mar 3 03:22:01 myserver OpenLDAP[53304]: bdb_idl_fetch_key: [b49d1940]
Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_index_read: failed (-30988)
Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_equality_candidates: id=0,
first=0, last=0
Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_filter_candidates: id=0
first=0 last=0
Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_filter_candidates
Mar 3 03:22:01 myserver OpenLDAP[53304]: #011EQUALITY
Mar 3 03:22:01 myserver OpenLDAP[53304]: => bdb_equality_candidates (uid)
Mar 3 03:22:01 myserver OpenLDAP[53304]: => key_read
Mar 3 03:22:01 myserver OpenLDAP[53304]: bdb_idl_fetch_key: [9a14f458]
Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_index_read: failed (-30988)
Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_equality_candidates: id=0,
first=0, last=0
Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_filter_candidates: id=0
first=0 last=0
Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_list_candidates: id=0
first=0 last=0
Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_filter_candidates: id=0
first=0 last=0
Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_list_candidates: id=0
first=1 last=0
Mar 3 03:22:01 myserver OpenLDAP[53304]: <= bdb_filter_candidates: id=0
first=1 last=0
Mar 3 03:22:01 myserver OpenLDAP[53304]: bdb_search_candidates: id=0
first=1 last=0
Mar 3 03:22:01 myserver OpenLDAP[53304]: bdb_search: no candidates
Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_result: conn=103380
op=1 p=3
Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_result: err=0
matched="" text=""
Mar 3 03:22:01 myserver OpenLDAP[53304]: send_ldap_response: msgid=2
tag=101 err=0
Mar 3 03:22:01 myserver OpenLDAP[53304]: conn=103380 op=1 SEARCH RESULT
tag=101 err=0 nentries=0 text=
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on 1 descriptor
Mar 3 03:22:01 myserver OpenLDAP[53304]: daemon: activity on:
2 years, 3 months
openldap client library connection caching?
by Rallavagu Kon
All,
Deployed OpenLDAP 2.4 in production (with replication) mainly serving saslauthd and sendmail on Linux with client library 2.4.49. We are experiencing sporadic errors "ldap_simple_bind() failed -1 (Can't contact LDAP server).”. This issue happens on both saslauthd and on openldap when replicating to other service. However, upon investigation we have found that this error is not disruptive as both services (saslauthd and openldap server) have “retry” options built-in and subsequent request (immediately after a failure) receives successful response. Also, noticed that this issue manifests when communication occurs via ELB (AWS) and no connect issues were manifested when clients are directly pointed to openldap server (all connections are TLS). This makes me infer (suspect) that openldap client library might be caching (or tcp alive etc.) the connection which is not working well with ELB (Elastic Load Balancer). Wondering if the connection is really cached and is there a configuration parameter that I can try and tune the behavior (tried to chase this down looking into the source code of client library but could not locate it, perhaps I need to look more but wondering if someone else in the community has any experience in this regard).
Thank You.
2 years, 3 months
difference in multi-master replication since 2.4.57
by Emmanuel Seyman
Hello, all.
I have two OpenLDAP servers in production that were running 2.4.44 .
Both of these servers host 5 directories, each with their own
backends. This is a bog-standard 2-node RHEL7 multi-master
configuration that has worked for years. The binaries are the
LTB-Project rpms.
I updated my OpenLDAP servers to 2.4.57 last week. A few minutes after
the upgrade, I started to see syncrepl alerts in Nagios and I'm having
a hard time convincing myself that the upgrade isn't responsible for
the errors.
The problem is that I don't see any messages in the log that stand
out as being errors (granted, I'm not sure what I'm looking for).
In fact, the alert flaps every once in a while as the two nodes
come back in sync and drift away from each other again.
Here's what the output of the syncrepl nagios plugin looks like:
2021-03-03 09:54:01: CRITICAL - directories are not in sync - 199 seconds late (W:10 - C:5)
2021-03-03 09:56:01: CRITICAL - directories are not in sync - 197 seconds late (W:10 - C:5)
2021-03-03 09:58:01: CRITICAL - directories are not in sync - 42 seconds late (W:10 - C:5)
2021-03-03 10:00:01: CRITICAL - directories are not in sync - 4200 seconds late (W:10 - C:5)
2021-03-03 10:02:01: CRITICAL - directories are not in sync - 81 seconds late (W:10 - C:5)
2021-03-03 10:04:01: CRITICAL - directories are not in sync - 201 seconds late (W:10 - C:5)
2021-03-03 10:06:01: CRITICAL - directories are not in sync - 196 seconds late (W:10 - C:5)
2021-03-03 10:08:01: CRITICAL - directories are not in sync - 42 seconds late (W:10 - C:5)
2021-03-03 10:10:01: CRITICAL - directories are not in sync - 200 seconds late (W:10 - C:5)
2021-03-03 10:12:01: CRITICAL - directories are not in sync - 81 seconds late (W:10 - C:5)
I find these values surprising considering I've never seen a syncrepl
error in the 2 years before the upgrade. Is there a known issue with
replication in 2.4.57 that would explain these sync differences?
Regards,
Emmanuel
2 years, 3 months
Issue on backup on Open LDAP 2.4.38
by pascal.foulon＠orange.com
Hi all
Since several weeks , we met an issue on our test and UA Open LDAP main master servers version 2.4.38 hosted on Linux Red Hat 6.4 :
slapd: [INFO] Using /etc/default/slapd for configuration
slapd: [INFO] Launching OpenLDAP database backup...
slapd: [OK] data saved in /var/opt/data/flat/openldap/backups/data-20210303154336.ldif
603fa0ac bdb(cn=changelog): Logging region out of memory; you may need to increase its size
603fa0ac hdb_db_open: database "cn=changelog": db_open(/var/opt/data/db/openldap/changelog/id2entry.bdb) failed: Cannot allocate memory (12).
603fa0ac backend_startup_one (type=hdb, suffix="cn=changelog"): bi_db_open failed! (12)
slap_startup failed
slapd: [ALERT] OpenLDAP database backup failed
Once a week, this servers is completely updated using a backup sent from our production server
On the backup master server, backup process runs well.
Any idea to fix this issue ?
Regards
[logo Orange]<http://www.orange.com/>
Pascal Foulon
Concepteur Développeur
Responsable Technique / MOE portail Intranet France Mobile
Expert technique VMPAL-E / Quartz / Web Admin / IFM / Annuaire Groupe
Orange/TGI/OLS/SOFT/IDF-NANCY/DPI
mobile : +33 6 82 57 28 73 <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoic...>
pascal.foulon(a)orange.com<mailto:pascal.foulon@orange.com>
EDS Océane 58H « Annuaire Groupe » : BJC031
EDS Océane IFM « Intranet France Mobile » : BJC038
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
2 years, 3 months
openldap meta to active directory bind err=49 most explicit return information ?
by Nicolas Renault
Hi,
I have a meta that proxify bind requests to 3 AD.
A CAS server use the meta backend to authenticate users.
if I connect into the cas ui with a user and good password , all is fine.
if I connect into the cas ui with the same user and a bad password ,
it's fail , all is fine
if I connect into the cas ui with a another user (password expired on
the AD) using the good expired password, it's fail , all is fine
But I want to have a information windows that says : "bad password " or
"password expired" , I cannot because return code is always ' RESULT
tag=97 err=49 text= '
Did someone knows a way to get the information ? ( same question with
"locked account" and all the existing case )
Regards
Nicolas
2 years, 3 months
OpenLDAP 2.5.2 Beta binary builds for testing
by Quanah Gibson-Mount
Symas is pleased to provide binary builds of the OpenLDAP 2.5.2 beta for
testing purposes only on the following select platforms. Builds install
into /opt/openldap25/ with state files stored in /var/opt/openldap25/ so as
to be entirely self contained. No init scripts are provided and it is
expected that end testers are familiar with OpenLDAP configuration. Please
file any software (not packaging) related issues found at
https://bugs.openldap.org/
Platforms:
Ubuntu 20.04 LTS
RHEL8 and binary compatible distributions (note: requires EPEL)
Fedora 34
--------------------------------------------------
Ubuntu 20.04 LTS installation instructions:
sudo add-apt-repository ppa:symas/openldap25
sudo apt-get update
sudo apt install openldap-clients openldap-server
--------------------------------------------------
--------------------------------------------------
RHEL8 installation instructions:
dnf install 'dnf-command(copr)'
dnf install epel-release
dnf copr enable symas/openldap25
yum install openldap25-libs openldap25-clients openldap25-server
--------------------------------------------------
--------------------------------------------------
Fedora 34 installation instructions:
dnf install 'dnf-command(copr)'
dnf copr enable symas/openldap25
yum install openldap25-libs openldap25-clients openldap25-server
--------------------------------------------------
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
2 years, 3 months
