Janne Peltonen wrote:
> Hi!
>
> We've got a proxy OpenLDAP setup using the "ldap" proxy database (the newer
> "meta" backend had some issues, so I couldn't use that one). Most of the time,
> the proxy bind goes OK, but sometimes, the connection goes like this (proxy
> log, using ldaps):
>
> --clip--
> Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 ACCEPT from IP=128.214.54.152:36460 (IP=0.0.0.0:636)
> Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 TLS established tls_ssf=256 ssf=256
> Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 op=0 BIND dn="<removed>" method=128
> Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 op=0 RESULT tag=97 err=52 text=Start TLS failed
> Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7716 fd=96 closed (connection lost)
> --clip--
>
> On the backend, this appears to be the case that a new connection kind of
> overruns the old one; see what happens with connection 6983:
Looks odd indeed, but doesn't seem related to the other errors. Would need much finer
resolution timestamps to correlate what's going on, unless you know there are no other
active connections on the proxy when this occurred on the backend.
>
> --clip--
> Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 fd=23 ACCEPT from IP=128.214.222.155:46144 (IP=0.0.0.0:389)
> Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 ACCEPT from IP=128.214.222.155:46146 (IP=0.0.0.0:389)
> Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=0 EXT oid=1.3.6.1.4.1.1466.20037
> Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=0 STARTTLS
> Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 op=1 UNBIND
> Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6983 fd=23 closed
> Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 EXT oid=1.3.6.1.4.1.1466.20037
> Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 STARTTLS
> Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=0 RESULT oid= err=0 text=
> Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 TLS established tls_ssf=256 ssf=256
> Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 BIND dn="<removed>" method=128
> Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 BIND dn="<removed>" mech=SIMPLE ssf=0
> Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=1 RESULT tag=97 err=0 text=
> [SRCH and result lines]
> Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 op=3 UNBIND
> Jan 7 16:01:12 ldap-v-2 slapd[61739]: conn=6984 fd=41 closed
> --clip--
>
> This doesn't seem to have any correlation to the amount of binds of server
> load, at least that I'm aware - and anyway, the servers are nowhere near at
> capacity - we only get ~2 binds per second.
>
> Normal connection would look like this:
>
> --clip--
> Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 fd=159 ACCEPT from IP=128.214.54.152:36362 (IP=0.0.0.0:636)
> Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 fd=159 TLS established tls_ssf=256 ssf=256
> Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 BIND dn="<removed>" method=128
> Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 BIND dn="<removed>" mech=SIMPLE ssf=0
> Jan 7 16:00:55 ldap-r-1 slapd[16851]: conn=7650 op=0 RESULT tag=97 err=0 text=
> [SRCH and SEARCH RESULT lines]
> Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7650 op=219 UNBIND
> Jan 7 16:01:12 ldap-r-1 slapd[16851]: conn=7650 fd=159 closed
> --clip--
>
> So this far, it looks as if the problem was that if we accept a second
> connection for the same client before the proxy has had time to do a bind (or
> indeed, a STARTTLS for the bind) on the backend for the second connection.
>
> But we seem to be getting spurious Start TLS failed messages also without any
> competing connections. Here's one using ldap+STARTTLS but no other ACCEPTs
> anywhere near:
These aren't spurious - your TLS library has genuinely failed to start a session. Which TLS library
are you using? What OS are you running on? The most common cause for periodic failures is
running out of entropy for the PRNG.
> --clip--
> Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 fd=62 ACCEPT from IP=128.214.173.135:43148 (IP=0.0.0.0:389)
> Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 EXT oid=1.3.6.1.4.1.1466.20037
> Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 STARTTLS
> Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=0 RESULT oid= err=0 text=
> Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 fd=62 TLS established tls_ssf=256 ssf=256
> Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=1 BIND dn="ou=shibboleth,ou=login,dc=helsinki,dc=fi" method=128
> Jan 17 17:46:20 ldap-r-1 slapd[28738]: conn=529684 op=1 RESULT tag=97 err=52 text=Start TLS failed
> Jan 17 17:46:22 ldap-r-1 slapd[28738]: conn=529684 fd=62 closed (connection lost)
> --clip--
>
> on the proxy, and backend:
>
> --clip--
> Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 fd=92 ACCEPT from IP=128.214.222.155:48996 (IP=0.0.0.0:389)
> Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 EXT oid=1.3.6.1.4.1.1466.20037
> Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 STARTTLS
> Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 op=0 RESULT oid= err=0 text=
> Jan 17 17:46:20 ldap-v-2 slapd[40089]: conn=406149 fd=92 closed (TLS negotiation failure)
> --clip--
> Any ideas what could be causing these? It's a bit hard to pinpoint the problem,
> since it happens so rarely - we seem to get a couple dozen of these every hour
> to around 16 000 succesful binds, not really depending on system load. This is
> RHEL 7 and OpenLDAP 2.4.40.
>
> It may be the case that the same DN binding very often increases the
> probability of a Start TLS failed error, which I guess would be the first case
> (a new ACCEPT + BIND for a DN too soon after the previous one). But as I said,
> these seem to also sometimes appear even without any other connections being
> opened at the same time. (Although there might be some old connections open for
> the same DN.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Hi
current version of openldap 2.4.23-7.2 I have however built and used
2.4.31 with the same results.
I have a single provider that has multiple domians
ie dc=company
dc=subdivision1,dc=company
dc=subdivision2,dc=company
on some of the consumers, I have a single syncrepl config with the base,
so these servers have all the users and replication tends to work fine.
olcSyncrepl: {0}
rid=00x
provider=ldaps://x.x.x.x
bindmethod=simple
binddn="cn=replica,dc=repl_config,dc=company"
credentials="xxxxx"
filter="(objectclass=*)"
searchbase="dc=company"
scope=sub
attrs="*,+"
schemachecking=off
type=refreshAndPersist
retry="5 5 300 +"
starttls=yes
tls_reqcert=never
tls_cert=/etc/ldap/ssl/ca-cert.pem
tls_key=/etc/ldap/ssl/keys/ca-key.pem
on some of the consumers, I have multiple syncrepl configs so that I
replicate specific subdivision data to those servers.
olcSyncrepl: {0}
rid=001
provider=ldaps://x.x.x.x
bindmethod=simple
binddn="cn=replica,dc=repl_config,dc=company"
credentials="xxxxx"
filter="(objectclass=*)"
searchbase="dc=company"
scope=base
attrs="*,+"
schemachecking=off
type=refreshAndPersist
retry="5 5 300 +"
starttls=yes
tls_reqcert=never
tls_cert=/etc/ldap/ssl/ca-cert.pem
tls_key=/etc/ldap/ssl/keys/ca-key.pem
olcSyncrepl: {1}
rid=002
provider=ldaps://x.x.x.x
bindmethod=simple
binddn="cn=replica,dc=repl_config,dc=company"
credentials="xxxxx"
filter="(objectclass=*)"
searchbase="dc=repl_config,dc=company"
scope=base
attrs="*,+"
schemachecking=off
type=refreshAndPersist
retry="5 5 300 +"
starttls=yes
tls_reqcert=never
tls_cert=/etc/ldap/ssl/ca-cert.pem
tls_key=/etc/ldap/ssl/keys/ca-key.pem
olcSyncrepl: {2}
rid=002
provider=ldaps://x.x.x.x
bindmethod=simple
binddn="cn=replica,dc=repl_config,dc=company"
credentials="xxxxx"
filter="(objectclass=*)"
searchbase="dc=subdivision,dc=company"
scope=base
attrs="*,+"
schemachecking=off
type=refreshAndPersist
retry="5 5 300 +"
starttls=yes
tls_reqcert=never
tls_cert=/etc/ldap/ssl/ca-cert.pem
tls_key=/etc/ldap/ssl/keys/ca-key.pem
whats happening with these consumers is that the initial sync seems to
work and some changes to the provider do make it down to the consumer
but lately most changes are NOT making it down to the consumer, when I
log sync then I am seeing that the csn is committed for the change for
the first rid but then for the next rid it logs that the csn is too old?
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080 NEW_COOKIE:
rid=080,csn=20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: slap_queue_csn: queing 0xb4230120
20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082 NEW_COOKIE:
rid=082,csn=20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081 NEW_COOKIE:
rid=081,csn=20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083
cookie=rid=083,csn=20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: slap_graduate_commit_csn: removing
0xb422e830 20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083 CSN too old,
ignoring 20120822075659.107448Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=082 NEW_COOKIE:
rid=082,csn=20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=081 NEW_COOKIE:
rid=081,csn=20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080
LDAP_RES_INTERMEDIATE - NEW_COOKIE
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=080 NEW_COOKIE:
rid=080,csn=20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083
cookie=rid=083,csn=20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: slap_queue_csn: queing 0xb4f11d20
20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: slap_graduate_commit_csn: removing
0xb4f18508 20120822075659.112753Z#000000#000#000000
Aug 22 09:56:59 fw1 slapd[30938]: do_syncrep2: rid=083 CSN too old,
ignoring 20120822075659.112753Z#000000#000#000000
--
Thank you,
Mark Adrian Coetser
mark(a)pkfnet.co.za
Le 04/10/2023 à 14:46, Emmanuel Seyman a écrit :
> Hello, all.
>
> I have an instance of OpenLDAP in which I use groups to manage access
> controls, similar to the way the FAQ and admin guide describe it.
>
> My DIT layout:
>
> uid=userildr1,ou=people,o=gdAA,dc=example,dc=com
> uid=userildr2,ou=people,o=gdAA,dc=example,dc=com
> ...
> cn=readINT,ou=groups,o=gdAA,dc=example,dc=com
> cn=writeINT,ou=groups,o=gdAA,dc=example,dc=com
> cn=superadmin,ou=groups,o=gdAA,dc=example,dc=com
> ...
> ou=people,o=INT,dc=example,dc=com
> ...
> ou=groups,o=INT,dc=example,dc=com
>
>
> Outside of the DIT, my slapd.conf file (yes, I know) contains:
>
> access to dn.sub="o=INT,dc=example,dc=com"
> by self write
> by group/groupOfUniqueNames/uniqueMember="cn=superadmin,ou=groups,o=gdAA,dc=example,dc=com" write
> by group/groupOfUniqueNames/uniqueMember="cn=writeINT,ou=groups,o=gdAA,dc=example,dc=com" write
> by group/groupOfUniqueNames/uniqueMember="cn=readINT,ou=groups,o=gdAA,dc=example,dc=com" read
>
> The uid=userildr1,ou=people,o=gdAA,dc=example,dc=com entry is in the readINT
> group yet seems unable to run a search. I get an error 50 ("Operations are
> restricted to bind/unbind/abandon/StartTLS/modify password") and cannot
> figure out why this is happening. If anyone can tell me what's going on,
> I would appreciate it.
>
> I'm seeing "config_back_db_open: line 0: warning: cannot assess the validity of
> the ACL scope within backend naming context" in the log files but this looks
> harmless.
>
> This is OpenLDAP 2.5.14 running on RHEL 8, with the LTB packages.
> Logs and the configuration file are available if necessary.
>
Hello Emmanuel,
the error "Operations are restricted to
bind/unbind/abandon/StartTLS/modify password" means the account has the
pwdReset flag set to TRUE and must reset its password. It is linked to
password policy.
--
Clément Oudot | Identity Solutions Manager
clement.oudot(a)worteks.com
Worteks |https://www.worteks.com
William Brown wrote:
> On Fri, 2017-11-17 at 08:34 +0100, Michael Ströder wrote:
>> William Brown wrote:
>>> Just want to point out there are some security risks with ssf
>>> settings.
>>> I have documented these here:
>>>
>>> https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.ht
>>> ml
>>
>> Nice writeup. I always considered SSF values to be naive and somewhat
>> overrated. People expect too much when looking at these numbers -
>> especially regarding the "strength" of cryptographic algorithms which
>> changes over time anyway with new cryptanalysis results coming up.
>>
>> Personally I always try to implement a TLS-is-must policy and prefer
>> LDAPS (with correct protocol and ciphersuites configured) over
>> LDAP/StartTLS to avoid this kind of pre-TLS leakage.
>> Yes, I deliberately ignore "LDAPS is deprecated". ;-]
>
> I agree. If only there was a standards working group that could
> deprecate startTLS in favour of TLS .... :)
I have to agree as well. On my own servers I also use TLS on other "plaintext"
ports too (such as pop3 and others) that no one has any business connecting to
in plaintext.
>> Furthermore some LDAP server implementation (IIRC e.g. MS AD) refuse
>> to
>> accept SASL/GSSAPI bind requests sent over TLS-secured channel. Which
>> is
>> IMO also somewhat questionable.
>
> Yes, I really agree. While a plain text port exists, data leaks are
> possible. We should really improve this situation, where we have TLS
> for all data to prevent these mistakes.
>
> I think a big part of the issue is that GSSAPI forces the encryption
> layer, and can't work via an already encrypted channel. The people I
> know involved in this space are really resistant to changing this due
> to the "kerberos centric" nature of the products.
Interesting. Our libldap/liblber works fine with GSSAPI's encryption layered
over TLS and vice versa.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Am Mon, 12 Dec 2011 15:51:38 +0530
schrieb Jayavant Patil <jayavant.patil82(a)gmail.com>:
> Hi,
>
> I am using openldap-2.4.19-4.x86_64 on fedora 12 machine. I have
> enabled openldap SSL/TLS. How do I know (test) that I am using
> SSL/TLS connections instead of normal ldap:///?
This is written to syslog
slapd[1276]: conn=1001 fd=17 ACCEPT from IP=[::1]:34267 (IP=[::]:389)
slapd[1276]: conn=1001 op=0 EXT oid=1.3.6.1.4.1.1466.20037
slapd[1276]: conn=1001 op=0 STARTTLS
slapd[1276]: conn=1001 op=0 RESULT oid= err=0 text=
slapd[1276]: conn=1001 fd=17 TLS established tls_ssf=256 ssf=256
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95"N
10°08'02,42"E
On 4/8/21 4:07 PM, work(a)seyboldt.org wrote:
> i need to open my LDAP-Directory to a public available Server.
>
> What is the best secure way to connect my LDAP-Server to my Public
> server?
This is a pretty broad question.
Good answers usually need more info:
- which kind of data is stored inside the LDAP server?
- how do LDAP clients access the server?
- which OS is the LDAP server running on?
- against which attacks do you want to protect your deployment?
Some general security measures include:
- use TLS-protected connections everywhere (StartTLS or LDAPS)
- use decently secure authentication mechs
- implement secure OpenLDAP ACLs to protect the database content
- build stripped-down, specific OpenLDAP packages for your needs
- use systemd's sand-boxing options (if using systemd on Linux at all)
- use kernel-level MAC like SELinux or AppArmor (if OS is Linux)
Ciao, Michael.
On 3/2/22 11:49, Francesco Malvezzi wrote:
> on a consumer I spotted a zombie entry which was deleted on provider.
Which OpenLDAP version are you using?
> Replication is syncrepl:
>
> olcSyncrepl: {0}rid=003 provider=ldap://ldap-master.example.org
> binddn="cn=repluser,ou=agents,dc=example,dc=org" bindmethod=simple
> credentials="secret" searchbase="ou=people,dc=example,dc=org"
> type=refreshOnly interval=00:00:01:00 retry="5 5 30 +" timeout=1
> scope=sub schemachecking=on exattrs=sambaHomeDrive sizelimit=100000
> timelimit=7200 starttls=yes filter="....."
I cannot really tell what's going on in your deployment.
But I wonder why you added sizelimit= to the syncrepl directive. Do you
really have less than 100000 entries?
Ciao, Michael.
--On Wednesday, March 30, 2022 8:28 PM +0200 Stefan Kania
<stefan(a)kania-online.de> wrote:
> That's what can be found in the FAQ on openldap.org:
>
> https://www.openldap.org/faq/data/cache/605.html
>
> I would trust this more then any rumors on any stackxxxx page ;)
Unfortunately, the FAQ is dead weight we want to kill and not maintained in
any way, shape, or form. It's currently provided for historical purposes.
As to this overall discussion, one of the primary issues with connections
over ldap:/// is that there's zero way with simple binds to prevent the
bind dn + password being sent in the clear by a client to the server. With
ldaps:/// the encryption is set up before the BIND occurs so you don't run
this risk.
So from that standpoint, I'd personally prefer to see ldaps:/// qualified
in an RFC so the standardization argument goes away and ldaps be noted as
the preferred method for sites that require encryption.
--Quanah
William Brown wrote:
> Just want to point out there are some security risks with ssf settings.
> I have documented these here:
>
> https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_trap.html
Nice writeup. I always considered SSF values to be naive and somewhat
overrated. People expect too much when looking at these numbers -
especially regarding the "strength" of cryptographic algorithms which
changes over time anyway with new cryptanalysis results coming up.
Personally I always try to implement a TLS-is-must policy and prefer
LDAPS (with correct protocol and ciphersuites configured) over
LDAP/StartTLS to avoid this kind of pre-TLS leakage.
Yes, I deliberately ignore "LDAPS is deprecated". ;-]
Furthermore some LDAP server implementation (IIRC e.g. MS AD) refuse to
accept SASL/GSSAPI bind requests sent over TLS-secured channel. Which is
IMO also somewhat questionable.
Ciao, Michael.
> Thanks for that, in the end I gave up on TLS and just used SSL. Later when I
> try again, it'll be after upgrading both the provider and the consumer to
> the same versions. For now I'm using:
Warren you wimp!!! I understand, but do go back to it as StartTLS is a
standard, LDAP over SSL isn't.
Thanks.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
Suretec Systems is a limited company registered in Scotland. Registered
number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie,
Aberdeenshire, AB51 8GL.
Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html
Do you know we have our own VoIP provider called SureVoIP? See
http://www.surevoip.co.uk
Did you see our API news?
http://www.surevoip.co.uk/news-events/surevoip-launches-innovative-api
