Unable to change ssl version on openldap 2.6.0
by Frédéric Goudal
Hello,
For a legacy application we need to drop the ssl version available on our openldap server.
Currently it supports TLSv1.2, checked with nmap --script ssl-enum-ciphers -p 636 host
What ever value I put on olcTLSProtocolmin the ssl version does not change… I have tried 3.0 3.1 3.2…
What do I miss ?
Or is it a feature ?
Thanks in advance
f.g.
—
Frédéric Goudal
Ingénieur Système, DSI Bordeaux-INP
+33 556 84 23 11
1 year, 1 month
2.5 Quick-Start guide roadblock: ldap_bind: Confidentiality required (13)
by Ben Poliakoff
I've been using the Symas OpenLDAP debian packages, and following the
Quick-Start guide for 2.5:
https://www.openldap.org/doc/admin25/quickstart.html
Following steps 1 - 10 has been straight forward, but when I get to step 11
(Add initial entries to your directory), I run into trouble when running
the ldapadd command:
root@openldap-x:/opt/symas/etc/openldap# ldapadd -x -D
"cn=Manager,dc=example,dc=com" -W -f bootstrap.ldif
Enter LDAP Password:
ldap_bind: Confidentiality required (13)
additional info: confidentiality required
root@openldap-x:/opt/symas/etc/openldap#
I used the provided slapd.ldif.default to seed the cn=config (updating it
with the appropriate domain components), as per the instructions in the
Quick-Start, so slapd isn't yet configured to run with ssl or starttls. Is
there a default SSF factor that I should adjust to get past this
bootstrapping failure? I don't see anything like that explicitly set in the
configs that were rendered into /opt/symas/etc/openldap/slapd.d, from my
slapd.ldif.
I'm not new to openldap, but this is the first time I've used the Symas
packages and also the first time trying to use olc instead of a slapd.conf
based configuration.
Ben
1 year, 1 month
OpenLdap on Rocky 8 -- suggestions?
by Aaron Bennett
Hi,
I'm migrating a small two-node OpenLDAP cluster from CentOS 7 to Rocky 8. I've been maintaining my own openldap rpms forked off of the RHEL 7 srpms, edited to link against OpenSSL instead of the never-to-be-sufficiently-d*mned GnuTLS. Now that there is no official openldap build from RedHat, I'm evaluating my choices.
Essentially it comes down to these:
1. Build from source every time. Not difficult and I'm comfortable with it, but I prefer when possible to not drop non-rpm packaged files into production
2. Package it myself. If we still used it super extensively like we did in the past, I would do this, but it's a lot of work.
3. Look for third-party packages that are frequently updated.
My preference is 3, which of course leads me to Symas OpenLdap. Looking at the symas page, it looks like there are two branches, the LTS 2.5 branch and the 2.6 branch. If this is accurate and the 2.5 branch is updated with security backports, etc, and is still gratis, that's the direction I'm looking to go. Any gotchas, or am I totally missing something obvious?
Best,
Aaron Bennett
---
Aaron Bennett
Manager of Systems Administration
Clark University ITS
1 year, 1 month
Re: log analysis tools
by Clément OUDOT
Le sam. 5 févr. 2022 à 20:57, Quanah Gibson-Mount <quanah(a)fast-mail.org> a
écrit :
>
>
> --On Friday, February 4, 2022 10:12 PM -0500 Dave Macias <davama(a)gmail.com>
>
> wrote:
>
> >
> >
> > https://www.ltb-project.org/documentation/ldap-stats.html
>
> Is that the one I used to help maintain? I don't believe it's been updated
> for 2.5 and later, unless it was forked and someone else has started
> working on it.
>
Hello Quanah,
this is indeed a fork done inside LTB project, there was no git repo for
this script (or I did not found it). Of course if there are changes in 2.5
log format, we can update the script.
Clément.
1 year, 1 month
str2entry: invalid value for attributeType objectClass #1 (syntax 1.3.6.1.4.1.1466.115.121.1.38)
by gpaz＠iter.es
`````
[root@ldap ~]# slapcat
The first database does not allow slapcat; using the first available one (2)
dn: dc=ldap,dc=test
objectClass: top
objectClass: dcObject
objectClass: organization
dc: ldap
o: ldap_test_iter
description: ldap_test_iter
structuralObjectClass: organization
entryUUID: 4a04a984-1dfc-103c-8835-d781e468857b
creatorsName: cn=Manager,dc=ldap,dc=test
createTimestamp: 20220209135948Z
entryCSN: 20220209135948.842285Z#000000#000#000000
modifiersName: cn=Manager,dc=ldap,dc=test
modifyTimestamp: 20220209135948Z
dn: ou=users,dc=ldap,dc=test
objectClass: organizationalUnit
ou: users
structuralObjectClass: organizationalUnit
entryUUID: 4a09e624-1dfc-103c-8836-d781e468857b
creatorsName: cn=Manager,dc=ldap,dc=test
createTimestamp: 20220209135948Z
entryCSN: 20220209135948.876561Z#000000#000#000000
modifiersName: cn=Manager,dc=ldap,dc=test
modifyTimestamp: 20220209135948Z
dn: ou=groups,dc=ldap,dc=test
objectClass: organizationalUnit
ou: groups
structuralObjectClass: organizationalUnit
entryUUID: 4a0dc5fa-1dfc-103c-8837-d781e468857b
creatorsName: cn=Manager,dc=ldap,dc=test
createTimestamp: 20220209135948Z
entryCSN: 20220209135948.901999Z#000000#000#000000
modifiersName: cn=Manager,dc=ldap,dc=test
modifyTimestamp: 20220209135948Z
dn: uid=pedro,ou=users,dc=ldap,dc=test
uid: pedro
cn: pedro
sn: pedro
objectClass: top
objectClass: posixAccount
objectClass: inetOrgPerson
loginShell: /bin/bash
uidNumber: 500
gidNumber: 500
mail: pedro(a)example.com
gecos: pedro user
homeDirectory: /home/pedro
structuralObjectClass: inetOrgPerson
entryUUID: 908089be-1dfc-103c-8838-d781e468857b
creatorsName: cn=Manager,dc=ldap,dc=test
createTimestamp: 20220209140147Z
userPassword:: e1NTSEF9eWdWaGZSMFhKY3N3blpLREdMbm9TU0VlanVWK01jL0s=
entryCSN: 20220217123622.452494Z#000000#000#000000
modifiersName: uid=pedro,ou=users,dc=ldap,dc=test
modifyTimestamp: 20220217123622Z
dn: cn=pedro,ou=groups,dc=ldap,dc=test
objectClass: posixGroup
objectClass: top
cn: pedro
userPassword:: e2NyeXB0fXg=
gidNumber: 500
memberUid: uid=pedro
structuralObjectClass: posixGroup
entryUUID: 9096c90e-1dfc-103c-8839-d781e468857b
creatorsName: cn=Manager,dc=ldap,dc=test
createTimestamp: 20220209140147Z
entryCSN: 20220209140147.240435Z#000000#000#000000
modifiersName: cn=Manager,dc=ldap,dc=test
modifyTimestamp: 20220209140147Z
dn: cn=module,dc=ldap,dc=test
cn: module
objectClass: top
objectClass: olcModuleList
olcModuleLoad: ppolicy.la
olcModulePath: /usr/lib64/openldap
structuralObjectClass: olcModuleList
entryUUID: 8ffa80b4-243f-103c-809a-d143605cbb0e
creatorsName: cn=Manager,dc=ldap,dc=test
createTimestamp: 20220217131629Z
entryCSN: 20220217131629.473761Z#000000#000#000000
modifiersName: cn=Manager,dc=ldap,dc=test
modifyTimestamp: 20220217131629Z
dn: ou=ppolicy,dc=ldap,dc=test
objectClass: organizationalUnit
ou: ppolicy
structuralObjectClass: organizationalUnit
entryUUID: aeeed796-2443-103c-9d36-4f3e029afe7a
creatorsName: cn=Manager,dc=ldap,dc=test
createTimestamp: 20220217134559Z
entryCSN: 20220217134559.393630Z#000000#000#000000
modifiersName: cn=Manager,dc=ldap,dc=test
modifyTimestamp: 20220217134559Z
`````
When I try enable the modulo I obtain the next error:
`````
[root@ldap ldap]# slapadd -n2 -l 2.2_ppolicy-bdb-ldap.test.ldif
str2entry: invalid value for attributeType objectClass #1 (syntax 1.3.6.1.4.1.1466.115.121.1.38)
slapadd: could not parse entry (line=1)
_#################### 100.00% eta none elapsed none fast!
Closing DB...
`````
File 2.2_ppolicy-bdb-ldap.test.ldif:
`````
[root@ldap ldap]# cat 2.2_ppolicy-bdb-ldap.test.ldif
dn: olcOverlay=ppolicy,olcDatabase={2}bdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=default,ou=ppolicy,dc=ldap,dc=test
olcPPolicyUseLockout: TRUE
olcPPolicyHashCleartext: TRUE
`````
Could anyone help me?
1 year, 1 month
slapcat truncates slapd.log
by Jose Garcia
Hello, openldap.org community!
This is my first thread here, in the hopes of finding a better understanding of a problem I'm having with OpenLDAP after several hours of unsuccessful troubleshooting. I'm in no way an expert on the matter so maybe someone more experienced here could help me get things a bit clearer.
I recently found this issue in two Ubuntu 18.04 servers I'm running with OpenLDAP 2.4 and bdb backend for their databases.
I want to export my LDAP database to an LDIF file by running:
# slapcat -l database.ldif
This works just fine. However, I realized every time I run such slapcat command, my slapd.log file gets truncated (i.e. all previous log entries are deleted).
This happens on both servers, no matter if the slapd daemon is running or not.
I don't know if this is normal or expected behavior, but it is weird to me that slapcat is wiping the log files. From what I understood slapd is in charge of the logging, so why is slapcat messing with that?
Is this just normal/expected behavior, or am I experiencing some kind of weird issue here?
1 year, 1 month
RE: Error when running make test or slapd after building on windows
by Joshua Dunbar
I see this issue here as well: https://www.mail-archive.com/openldap-bugs@openldap.org/msg08059.html
But not sure I understand what the resolution is
-----Original Message-----
From: Joshua Dunbar
Sent: Friday, February 18, 2022 11:19 AM
To: Howard Chu <hyc(a)symas.com>; Dr. Ogg <ogg(a)sr375.com>
Cc: Quanah Gibson-Mount <quanah(a)fast-mail.org>; openldap-technical(a)openldap.org
Subject: RE: Error when running make test or slapd after building on windows
I've attached the config.log
-----Original Message-----
From: Joshua Dunbar
Sent: Friday, February 18, 2022 11:12 AM
To: 'Howard Chu' <hyc(a)symas.com>; 'Dr. Ogg' <ogg(a)sr375.com>
Cc: 'Quanah Gibson-Mount' <quanah(a)fast-mail.org>; 'openldap-technical(a)openldap.org' <openldap-technical(a)openldap.org>
Subject: RE: Error when running make test or slapd after building on windows
I installed Msys and ran the pacman commands via the instructions here: https://www.msys2.org/. I then opened a MSYS MinGW 64-bit command prompt and ran configure, make depend, and make. Make ends with the following error
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/11.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .libs/os-ip.o: in function `ldap_int_poll':
C:/Users/USAF_Admin/Desktop/openldap-2.6.1/openldap-2.6.1/libraries/libldap/os-ip.c:391: undefined reference to `ber_pvt_wsa_err2string'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [Makefile:437: libldap.la] Error 1
make[2]: Leaving directory '/home/USAF_Admin/libraries/libldap'
make[1]: *** [Makefile:312: all-common] Error 1
make[1]: Leaving directory '/home/USAF_Admin/libraries'
make: *** [Makefile:320: all-common] Error 1
Any ideas?
-----Original Message-----
From: Joshua Dunbar
Sent: Thursday, February 17, 2022 6:17 PM
To: Howard Chu <hyc(a)symas.com>; Dr. Ogg <ogg(a)sr375.com>
Cc: Quanah Gibson-Mount <quanah(a)fast-mail.org>; openldap-technical(a)openldap.org
Subject: RE: Error when running make test or slapd after building on windows
Unfortunately this is for a government contract project and we are being mandated to use windows and not a containerized environment. Docker for windows was also booted.
I have MSYS installed, as well as latest openldap source.
-----Original Message-----
From: Howard Chu <hyc(a)symas.com>
Sent: Thursday, February 17, 2022 6:06 PM
To: Dr. Ogg <ogg(a)sr375.com>; Joshua Dunbar <jdunbar(a)montereytechnologies.com>
Cc: Quanah Gibson-Mount <quanah(a)fast-mail.org>; openldap-technical(a)openldap.org
Subject: Re: Error when running make test or slapd after building on windows
Dr. Ogg wrote:
> Why not run in a Linux VM or a docker container? and avoid Cygwin?
Or WSL2. I hear that works pretty well these days.
>
>
>> On Feb 17, 2022, at 2:48 PM, Joshua Dunbar <jdunbar(a)montereytechnologies.com> wrote:
>>
>> Are there up to date instructions on how to build with Cygwin or Msys somewhere? I am trying to do this on a 64 bit Windows 10 computer. The way I am doing it with Cygwin with default configure options must be wrong. I am new to both Cygwin and OpenLDAP so apologies for my inexperience.
>>
>> -----Original Message-----
>> From: Howard Chu <hyc(a)symas.com>
>> Sent: Thursday, February 17, 2022 5:40 PM
>> To: Quanah Gibson-Mount <quanah(a)fast-mail.org>; Joshua Dunbar
>> <jdunbar(a)montereytechnologies.com>; openldap-technical(a)openldap.org
>> Subject: Re: Error when running make test or slapd after building on
>> windows
>>
>> Quanah Gibson-Mount wrote:
>>>
>>>
>>> --On Thursday, February 17, 2022 8:00 PM +0000 Joshua Dunbar <jdunbar(a)montereytechnologies.com> wrote:
>>>
>>>>
>>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> I am attempting to install openldap (latest version 2.6.1) on
>>>> windows using Cygwin where I have installed dependencies of gcc
>>>> core and make in order to get configure to run. I then run
>>>> configure from a Cygwin terminal (without any arguments). Configure
>>>> seems to run fine, and so does make depend, and make. Then when I
>>>> attempt to run make test (or slapd with any other well formatted
>>>> slapd.conf file) I get the following error message. I
>>>
>>> Hi Joshua,
>>>
>>> It's likely related to this discussion:
>>>
>>> <https://cygwin.com/pipermail/cygwin/2019-July/241961.html>
>>
>> More than just that. OpenLDAP code supports real POSIX environments and native WIN32 environments.
>> It doesn't support Cygwin, which is a partially-working fake POSIX environment.
>>
>> You can use Cygwin or MSYS as the build platform, but the binaries will only work if built with the MinGW toolchain for native WIN32 output.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1 year, 1 month
Re: Error when running make test or slapd after building on windows
by Howard Chu
Dr. Ogg wrote:
> Why not run in a Linux VM or a docker container? and avoid Cygwin?
Or WSL2. I hear that works pretty well these days.
>
>
>> On Feb 17, 2022, at 2:48 PM, Joshua Dunbar <jdunbar(a)montereytechnologies.com> wrote:
>>
>> Are there up to date instructions on how to build with Cygwin or Msys somewhere? I am trying to do this on a 64 bit Windows 10 computer. The way I am doing it with Cygwin with default configure options must be wrong. I am new to both Cygwin and OpenLDAP so apologies for my inexperience.
>>
>> -----Original Message-----
>> From: Howard Chu <hyc(a)symas.com>
>> Sent: Thursday, February 17, 2022 5:40 PM
>> To: Quanah Gibson-Mount <quanah(a)fast-mail.org>; Joshua Dunbar <jdunbar(a)montereytechnologies.com>; openldap-technical(a)openldap.org
>> Subject: Re: Error when running make test or slapd after building on windows
>>
>> Quanah Gibson-Mount wrote:
>>>
>>>
>>> --On Thursday, February 17, 2022 8:00 PM +0000 Joshua Dunbar <jdunbar(a)montereytechnologies.com> wrote:
>>>
>>>>
>>>>
>>>> Hello,
>>>>
>>>>
>>>>
>>>> I am attempting to install openldap (latest version 2.6.1) on windows
>>>> using Cygwin where I have installed dependencies of gcc core and make
>>>> in order to get configure to run. I then run configure from a Cygwin
>>>> terminal (without any arguments). Configure seems to run fine, and so
>>>> does make depend, and make. Then when I attempt to run make test (or
>>>> slapd with any other well formatted slapd.conf file) I get the
>>>> following error message. I
>>>
>>> Hi Joshua,
>>>
>>> It's likely related to this discussion:
>>>
>>> <https://cygwin.com/pipermail/cygwin/2019-July/241961.html>
>>
>> More than just that. OpenLDAP code supports real POSIX environments and native WIN32 environments.
>> It doesn't support Cygwin, which is a partially-working fake POSIX environment.
>>
>> You can use Cygwin or MSYS as the build platform, but the binaries will only work if built with the MinGW toolchain for native WIN32 output.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
1 year, 1 month
