thank you very much Ulf, it works.
--On Monday, February 12, 2024 5:09 PM + Chili Mili
wrote:
find / -type s
find: '/proc/9/map_files': Permission denied
/usr/var/run/ldapi
The Unix socket file located inside the container is at
/usr/var/run/ldapi. I have tried to mount it to the host system but
encountered the same
Le 12/02/2024 à 16:19, Chili Mili a écrit :
outside:
lsof -U |grep slapd
--> no output
Hi,
maybe I can help here
If lsof isn't installed inside the container you may use nsenter
("namespace enter") on the host
You'll need the PID of the running container
Details here
Am 12.02.24 um 18:09 schrieb Chili Mili:
find / -type s
find: '/proc/9/map_files': Permission denied
/usr/var/run/ldapi
The Unix socket file located inside the container is at /usr/var/run/ldapi. I
have tried to mount it to the host system but encountered the same result.
Again, use it from
find / -type s
find: '/proc/9/map_files': Permission denied
/usr/var/run/ldapi
The Unix socket file located inside the container is at /usr/var/run/ldapi. I
have tried to mount it to the host system but encountered the same result.
any idea?
thanks
Am 12.02.24 um 17:01 schrieb Chili Mili:
it seems that Unix sockets aren't being used. I've compared the results with the old
server, and they are consistent. Additionally, I've checked using lsof -U -a -p
with the same outcome.
Please keep in mind that the ldap is running in the docker
it seems that Unix sockets aren't being used. I've compared the results with
the old server, and they are consistent. Additionally, I've checked using lsof
-U -a -p with the same outcome.
Please keep in mind that the ldap is running in the docker container
Am 12.02.24 um 16:19 schrieb Chili Mili:
inside the container:
lsof -U |grep slapd
bash: lsof: command not found
That's quite sad. I assume, you have no experience using linux?
Best regards
Ulf
inside the container:
lsof -U |grep slapd
bash: lsof: command not found
outside:
lsof -U |grep slapd
--> no output
Am 12.02.24 um 13:18 schrieb Chili Mili:
per example :
ourside of the container :
docker exec -it
lsof -U |grep slapd
would be interesting.
Best regards
Ulf
per example :
ourside of the container :
docker exec -it
Am 09.02.24 um 16:45 schrieb chilimi...@outlook.de:
> Could you please provide guidance on how to conduct searches within
the container given this constraint?
docker exec ldapsearch ...
Additional to this, I would like to activate pagination, but I have not been
able to find any
Thank you for your feedback. To clarify, my intention is to perform searches
within the container. However, due to the nature of the ldapi listener being a
unix domain socket, only processes within the Docker container itself can
communicate with it. Could you please provide guidance on how
On Fri, Feb 9, 2024 at 1:07 PM wrote:
> Problem:
> When attempting to use the ldapi:// URI to interact with the OpenLDAP
> server using commands like ldapmodify or ldapsearch, an error is
> encountered: ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1).
>
> Process
Problem:
When attempting to use the ldapi:// URI to interact with the OpenLDAP server
using commands like ldapmodify or ldapsearch, an error is encountered:
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1).
Process is running
# ps -aux |grep ldap
ldap 9 0.0 0.4 42232968
Michael and Richard, hello.
On 16 Jul 2018, at 5:09, Richard Gray wrote:
Have a look at 'olcLocalSSF' in slapd-config(5), which lets you set
the security strength factor for local (i.e. ldapi://) sessions. It
defaults to 71, which is likely why you're seeing that error message.
Personally
/certs/XXX.crt
olcTLSCertificateKeyFile: /usr/local/etc/openldap/certs/XXX.key
olcTLSCACertificateFile: /usr/local/etc/openldap/certs/FOO
olcLogLevel: 0
Have a look at 'olcLocalSSF' in slapd-config(5), which lets you set the
security strength factor for local (i.e. ldapi://) sessions. It defaults
.
However this seems not to be be the case:
% ldapsearch -LLL -H ldapi://%2Fvar%2Frun%2Fopenldap%2Fldapi
'(uid=foo)'
ldap_sasl_interactive_bind_s: Confidentiality required (13)
additional info: stronger confidentiality required
You want to set localSSF in your config to match
:
% ldapsearch -LLL -H ldapi://%2Fvar%2Frun%2Fopenldap%2Fldapi
'(uid=foo)'
ldap_sasl_interactive_bind_s: Confidentiality required (13)
additional info: stronger confidentiality required
(same result with ldapi:///).
What am I misunderstanding?
In the slapd.ldif I have:
dn: cn
I wrote:
False alarm. But if you want to test if SASL/EXTERNAL is available
on a connection, check supportedSASLMechanisms in the root DSE.
(ldapi:// offers it, ldap:// does not unless you supplied a client cert)
Er, ldapi:// *usually* offers it. I guess there may be platforms
where
On 27. april 2017 13:28, Michael Ströder wrote:
Is there an reliable way to detect whether LDAPI support is enabled in the
OpenLDAP build
on a particular platform? I vaguely remember the developer discussions about
disabling
LDAPI on platforms where the peer credentials are not secure
HI!
Is there an reliable way to detect whether LDAPI support is enabled in the
OpenLDAP build
on a particular platform? I vaguely remember the developer discussions about
disabling
LDAPI on platforms where the peer credentials are not secure.
Background: I'd like to detect with python-ldap
f=128
>>
>> Which all seems to work fine for my usage with one exception. If I
>> try to use any of the command line tools with "-Y EXTERNAL -H
>> ldapi:///", I now get:
>>
>> additional info: SASL(-15): mechanism too weak for this user: mech
>> EXTERNA
tion. If I
> try to use any of the command line tools with "-Y EXTERNAL -H
> ldapi:///", I now get:
>
> additional info: SASL(-15): mechanism too weak for this user: mech
> EXTERNAL is too weak
>
> Is there some configuration item that I can change to allow
with "-Y EXTERNAL -H ldapi:///", I now
get:
additional info: SASL(-15): mechanism too weak for this user: mech EXTERNAL
is too weak
Is there some configuration item that I can change to allow that work while
maintaining my existing policy of no anonymous binds for everything else,
I have locked down my server to disallow anonymous binds and set the
SSF=128. I also have SaslSecProps: noplain,noanonymous,minssf=128
Which all seems to work fine for my usage with one exception. If I try to
use any of the command line tools with "-Y EXTERNAL -H ldapi:///",
Ulrich Windl wrote:
Michael Strödermich...@stroeder.com schrieb am 29.03.2015 um 12:12 in
I have this in my config:
# SSF value for ldapi://
localSSF 256
What I don't understand here is: Doesn't 256 _require_ encryption for
ldapi:// then?
There is a reason for everything I write
Ulrich Windl wrote:
Isn't the SSF strength for ldapi:// zero?
The SSF strength of ldapi:// is whatever you set with configuration directive
localSSF. It's your local security policy decision.
Personally on my systems I don't see any problem with setting it to an equal
strength like
Ulrich Windl wrote:
Michael Strödermich...@stroeder.com schrieb am 30.03.2015 um 11:24 in
Nachricht 55191633.90...@stroeder.com:
Ulrich Windl wrote:
Michael Strödermich...@stroeder.com schrieb am 29.03.2015 um 12:12 in
I have this in my config:
# SSF value for ldapi://
localSSF 256
What I
Ulrich Windl wrote:
I've configured slapd to require excryption (confidentiality).
You did not post relevant configuration details.
Now
connections via ldapi:// fail with 13 Confidentiality required. When
adding -ZZ for ldapsearch (e.g.), the connection fails, because the
certificate does
I'm running OpenLDAP 2.4 on CentOS. I'm trying to set it up so clients
can use the ldapi:/// socket without TLS, but any clients using ldap://
must use TLS.
I believe that the relevant olc variables are olcLocalSSF and
olcSecurity. I can't get it to work - either TLS is required no matter
which
On Tue, 26 Aug 2014, Tom wrote:
I'm running OpenLDAP 2.4 on CentOS. I'm trying to set it up so clients
can use the ldapi:/// socket without TLS, but any clients using ldap://
must use TLS.
I believe that the relevant olc variables are olcLocalSSF and
olcSecurity. I can't get it to work
I'm running OpenLDAP 2.4 on CentOS 6.5. I'm trying to set it up so
clients can use the ldapi:/// socket without TLS, but any clients using
ldap:// must use TLS.
I believe that the relevant olc variables are olcLocalSSF and
olcSecurity. I can't get it to work - either TLS is required no matter
I'm running OpenLDAP 2.4 on CentOS. I'm trying to set it up so clients
can use the ldapi:/// socket without TLS, but any clients using ldap://
must use TLS.
I believe that the relevant olc variables are olcLocalSSF and
olcSecurity. I can't get it to work - either TLS is required no matter
to generate
and manage.)
Thankfully the security overlords who came up with this one are also the
ones who have to generate and manage the certs :-)
[snip]
Well, for starters, the peername.ip=127.0.0.1 clause does *NOT* match
ldapi:// connections. It matches ldap://127.0.0.1/ and ldaps://127.0.0.1
Thank you for your feedback Philip. Comments inline.
On 02/18/2013 07:16 AM, Philip Guenther wrote:
On Mon, 18 Feb 2013, Patrick Lists wrote:
I'm tying achieve the following with OpenLDAP RE24 from last week:
Connections on ldapi:/// are plain text and ldap connections require TLS
On Mon, 18 Feb 2013, Patrick Lists wrote:
On 02/18/2013 07:16 AM, Philip Guenther wrote:
On Mon, 18 Feb 2013, Patrick Lists wrote:
I'm tying achieve the following with OpenLDAP RE24 from last week:
Connections on ldapi:/// are plain text and ldap connections require
TLS
On Mon, 18 Feb 2013, Patrick Lists wrote:
I'm tying achieve the following with OpenLDAP RE24 from last week:
Connections on ldapi:/// are plain text and ldap connections require TLS
with client cert auth.
Perhaps it would be help if you started by answering, at least for
yourself, what
Hi,
how do the openldap tools technically verfify certificates with ldapi:// ?
With ldapi, you don't have a hostname or IP address, so how do the openldap
tools do it?
I tried to browse the code but got losat somewhere ion the way.
Any hints to the code or a short step-by-step explanation
Peter Marschall wrote:
how do the openldap tools technically verfify certificates with ldapi:// ?
Which certs do you want to verify?
With ldapi, you don't have a hostname or IP address, so how do the openldap
tools do it?
Are you talking about SASL/EXTERNAL? There are no certs involved
Hi,
On Monday, 28. May 2012, Michael Ströder wrote:
how do the openldap tools technically verfify certificates with ldapi://
?
Which certs do you want to verify?
With ldapi, you don't have a hostname or IP address, so how do the
openldap tools do it?
Are you talking about SASL
On Mon, 28 May 2012, Michael Ströder wrote:
Peter Marschall wrote:
how do the openldap tools technically verfify certificates with ldapi:// ?
Which certs do you want to verify?
I assume the answer is the one the server returns when you do StartTLS on
the ldapi:// connection.
It's pretty
Hi,
On Monday, 28. May 2012, Philip Guenther wrote:
On Mon, 28 May 2012, Michael Ströder wrote:
Peter Marschall wrote:
how do the openldap tools technically verfify certificates with
ldapi:// ?
Which certs do you want to verify?
I assume the answer is the one the server returns
Peter Marschall wrote:
On Monday, 28. May 2012, Philip Guenther wrote:
On Mon, 28 May 2012, Michael Ströder wrote:
Peter Marschall wrote:
how do the openldap tools technically verfify certificates with
ldapi:// ?
Which certs do you want to verify?
I assume the answer is the one the server
Hi Michael,
On Monday, 28. May 2012, Michael Ströder wrote:
Peter Marschall wrote:
On Monday, 28. May 2012, Philip Guenther wrote:
On Mon, 28 May 2012, Michael Ströder wrote:
Peter Marschall wrote:
how do the openldap tools technically verfify certificates with
ldapi:// ?
Which
Michael Ströder wrote:
= StartTLS over LDAP is undefined and probably every API should simple refuse
it at all or accept any server cert. In both cases the underlying LDAPI
channel is fully trusted anyway.
If the client really would like to implement an additional *security* check
Michael Ströder wrote:
= StartTLS over LDAP is undefined
^^
Hmmpf. An I was missing here. So it means: StartTLS over LDAPI is undefined.
Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
On Mon, 28 May 2012, Philip Guenther wrote:
If no path is specified (e.g., ldapi://) then the checking code is
passed a hostname of localhost.
...which then remaps that to the local hostname (if available) for the
actual check.
Huh. So for any URI that doesn't specify a host component
Hi,
On Monday, 28. May 2012, Philip Guenther wrote:
...which then remaps that to the local hostname (if available) for the
actual check.
Huh. So for any URI that doesn't specify a host component, be it
ldapi:// or ldap://; or ldaps://, the OpenLDAP tools will connect to
the default 'host
Michael Ströder wrote:
2. I have hangs in the client through python-ldap after slapd died. Not sure
whether that's related to OpenLDAP client libs though.
This is because the Unix domain socket for the LDAPI connection is not
properly closed and removed. In this case python-ldap hangs forever
performing your
ldapsearch
command.
I don't see how you will will be able to obtain SASL EXTERNAL over
STARTTLS
otherwise.
How did this conversation get to STARTTLS? The Subject is asking
about SASL EXTERNAL over ldapi, which does not need TLS.
I was led down that path via the howto referenced
On 03/10/11 21:43 +0200, Andreas Rudat wrote:
Am 03.10.2011 20:51, schrieb Dan White:
On 03/10/11 19:41 +0200, Andreas Rudat wrote:
tls_cert
tls_key
My mail client may have corrupted this part of your configuration. You'll
of course need valid entries here.
These options are defaults in my
EXTERNAL over STARTTLS
otherwise.
How did this conversation get to STARTTLS? The Subject is asking about SASL
EXTERNAL over ldapi, which does not need TLS.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect
you will will be able to obtain SASL EXTERNAL over STARTTLS
otherwise.
How did this conversation get to STARTTLS? The Subject is asking
about SASL EXTERNAL over ldapi, which does not need TLS.
I was led down that path via the howto referenced in the original post, and
made several, possibly
Hello,
everytime I try
*ldapmodify -Y EXTERNAL -H ldapi:///*
*
I get the following
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
and thats all, same with password (-W), it stopped at all and no log messages.
Thanks
On Mon, 03 Oct 2011 16:27:39 +0200, Andreas Rudat wrote:
*ldapmodify -Y EXTERNAL -H ldapi:///*
*
I get the following
SASL/EXTERNAL authentication started
SASL username:
gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
and thats all, same with password (-W), it stopped
On 03/10/11 16:27 +0200, Andreas Rudat wrote:
Hello,
everytime I try
*ldapmodify -Y EXTERNAL -H ldapi:///*
*
I get the following
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
and thats all, same with password (-W
Am 03.10.2011 16:43, schrieb Dan White:
On 03/10/11 16:27 +0200, Andreas Rudat wrote:
Hello,
everytime I try
*ldapmodify -Y EXTERNAL -H ldapi:///*
*
I get the following
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
On 03/10/11 17:43 +0200, Andreas Rudat wrote:
Am 03.10.2011 16:43, schrieb Dan White:
On 03/10/11 16:27 +0200, Andreas Rudat wrote:
*ldapmodify -Y EXTERNAL -H ldapi:///*
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
Am 03.10.2011 18:04, schrieb Dan White:
On 03/10/11 17:43 +0200, Andreas Rudat wrote:
Am 03.10.2011 16:43, schrieb Dan White:
On 03/10/11 16:27 +0200, Andreas Rudat wrote:
*ldapmodify -Y EXTERNAL -H ldapi:///*
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn
On 03/10/11 19:41 +0200, Andreas Rudat wrote:
Am 03.10.2011 18:04, schrieb Dan White:
On 03/10/11 17:43 +0200, Andreas Rudat wrote:
so tls issn't allowed in my configuration? I added tls on
ldap.conf and /etc/default/slapd
Debug says:
TLS: can't connect: A TLS packet with unexpected length
Am 03.10.2011 20:51, schrieb Dan White:
On 03/10/11 19:41 +0200, Andreas Rudat wrote:
Am 03.10.2011 18:04, schrieb Dan White:
On 03/10/11 17:43 +0200, Andreas Rudat wrote:
so tls issn't allowed in my configuration? I added tls on ldap.conf
and /etc/default/slapd
Debug says:
TLS: can't
On Wed, Feb 16, 2011 at 08:37:01AM -0800, Quanah Gibson-Mount wrote:
I don't get where you're getting this idea from. I've never been
required to use ldapi for setting up cn=config. The requirement of
using ldapi for cn=config management is something Debian/Ubuntu is
doing. Which is why
--On Wednesday, February 16, 2011 6:00 PM + Andrew Findlay
andrew.find...@skills-1st.co.uk wrote:
OK - forget the link to cn=config - that is just what got me interested
in ldapi: to start with.
The ldapi: transport seems to be almost undocumented. There is a brief
(but useful) mention
Andrew Findlay wrote:
On Wed, Feb 16, 2011 at 08:37:01AM -0800, Quanah Gibson-Mount wrote:
I don't get where you're getting this idea from. I've never been
required to use ldapi for setting up cn=config. The requirement of
using ldapi for cn=config management is something Debian/Ubuntu
It took me quite some time to figure out a small configuration error
(concerning ldapi:// confidentiality required) and I just want to let
you know about it and possibly save you some time during your next
debugging session:
Security strength factor olcSecurity: ... values that are differing
66 matches
Mail list logo
