Hello,
I'm under the impression that LDAPS (and not StartTLS) has been
depreciated in OpenLDAP, but I can't find anything on the OpenLDAP
website that says this. Is this the case, and is there a reference for
it?
Thanks.
--On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller
<heller(a)deepsoft.com> wrote:
> Slapd is reporting TLS Negotiation failure when SSSD tries to connect to
> it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess
> something is wrong with slapd's TLS configuration -- it is failing to do
> TLS Negotiation, either it is just not doing it or it is doing it wrong
> (somehow). Unless SSSD is not configured properly.
You need to start with the following:
>> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w
to test startTLS
and
ldapwhoami -x -H ldaps://myhost:636 -D binddn -w
to test without startTLS
If you can get those to work, then you can move on to SSSD.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
On 07/11/2018 08:52 PM, Norman Gray wrote:
> I would have thought (possibly naively) that StartTLS was unnecessary
> when connecting to slapd through a unix socket -- the client and the
> server are on the same machine, and so don't need to be reassured about
> each other's identity.
Yes.
> 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 the minimum SSF you've
configured (the default is 71).
'localSSF' is old slapd.conf name and 'olcLocalSSF' the accompanying
LDAP attribute in cn=config.
> dn: cn=config
> [..]
> olcSecurity: ssf=128
So add to cn=config:
olcLocalSSF: 128
Ciao, Michael.
Hello,
I am currently in the grips of trying to get syncrepl replication working
with StartTLS. It was working fine until recently. The only change that
occurred over the last 12 months (that relates to OpenLDAP) is that I've
started requiring TLS for connections.
My provider is running OpenLDAP 2.4.31 on Ubuntu 14.04, while one consumer
is running the exact same version on a Ubuntu 14.04 machine and the other
consumer is running OpenLDAP 2.4.28 on Ubuntu 12.04.
The provider has, AFAIK, a correct TLS configuration, given that I can
connect and search using the ldapsearch -ZZ utility from any of the servers.
The syncprov overlay is loaded and configured on the provider.
The consumers have the following (redacted, with unique rid values)
olcSyncRepl:
olcSyncrepl: {0}rid=1 provider=ldap://[LDAP_DNS] bindmethod=simple bi
nddn="[SYNC_USER]" credentials=[SYNC_PASS] searchbase="[L
DAP_BASE]" logbase="cn=accesslog" logfilter="(&(objectClass=auditWr
iteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist
retry="60
+" syncdata=accesslog starttls=critical tls_reqcert=demand
Unfortunately, on both consumers can't seem to be able to actually
start the TLS connection:
slapd[1257]: slap_client_connect: URI=ldap://[LDAP_DNS] Error,
ldap_start_tls failed (-11)
slapd[1257]: do_syncrepl: rid=001 rc -11 retrying
And the provider shows the following errors:
slapd[2126]: conn=1586 fd=100 ACCEPT from IP=[CONSUMER_IP]:35500
(IP=0.0.0.0:389)
slapd[2126]: conn=1586 op=0 EXT oid=1.3.6.1.4.1.1466.20037
slapd[2126]: conn=1586 op=0 STARTTLS
slapd[2126]: conn=1586 op=0 RESULT oid= err=0 text=
slapd[2126]: conn=1586 fd=100 closed (TLS negotiation failure)
Is there anything that I'm missing?
Cheers,
--
Xavier
On 4/1/22 10:59, Ulrich Windl wrote:
>>> Quanah Gibson-Mount <quanah(a)fast-mail.org> schrieb am 31.03.2022 um 17:45
>> There is no way to prevent a client from sending a BIND request to an
>> ldap:/// URI with the DN and password in the clear. Even if you set ssf=1
>> (server mandates encryption), the most that will happen is that the client
>> will get disconnected, but the DN and password will already have traveled
>> over the network in the clear before the client gets disconnected so anyone
>> sniffing the traffic would have access to it.
>
> But honestly, you could get the same when setting up SSL incorrectly (using
> eNULL or RSA-PSK-NULL-SHA).
Yes, but you would have to misconfigure this deliberately since Linux
distros ship with rather safe crypto policy defaults.
In opposite to that it's quite likely that StartTLS fails accidently.
Ciao, Michael.
--On Friday, June 02, 2017 11:01 AM +0200 r0m5 <r0m5(a)r0m5.eu> wrote:
>
> Hello,
>
> I am facing an issue with syncrepl and STARTTLS on 389 port. The kind of
> problem happening only sometimes, and disappearing "by itself". I use
> Debian Jessie, OpenLDAP 2.4.40+dfsg-1+deb8u2.
2.4.40 is 2.5 years old, 5 point releases behind, and had significant known
replication issues. I believe there is a build of 2.4.44 in backports for
Jessie. I would advise using that instead.
As far as debug logging, you would need to use "-d -1" to slapd, rather
than attempting to set the loglevel to -1, as some debug logging is only
possible via the slapd daemon. But your first step is to move to a current
release.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Thank you for the response! No, no... these are example data that I put
together to understand how Google users are structured and the issue that
uppercase letters are causing me. In the Google LDAP audit, I see that the
user fails and appears in lowercase.
Once again, I apologize; I ran so many tests that I accidentally copied one
where the binddn was incorrect.
The target looks more like this:
## example.com
uri "ldaps://ldap.google.com/dc=proxy"
suffixmassage "dc=proxy" "dc=example,dc=com"
lastmod off
readonly on
idassert-bind bindmethod=simple
binddn="cn=ChiwewDaw"
credentials="password-fake"
tls_reqcert=demand
tls_reqsan=demand
starttls=critical
tls_cert=/root/ldapcerts/ldap_cert.crt
tls_key=/root/ldapcerts/ldap_cert.key
tls_cacert=/root/ldapcerts/ca/gtsr1.pem
if i use:
idassert-bind bindmethod=sasl
saslmech=EXTERNAL
tls_reqcert=demand
tls_reqsan=demand
starttls=critical
i have the error : "Unauthenticated"
Michael Ströder wrote:
> On 3/31/22 19:15, Quanah Gibson-Mount wrote:
>> I think the clear text bind issue in fact shows that LDAPS is
>> technically superior to startTLS when encryption is required. The
>> remaining issue is there's no RFC for it. I'd like to see that
>> addressed.
> My attempt to resurrect the IETF ldapext WG failed back in 2015. :-/
>
> Well, in fact every LDAP server I've tested supports LDAPS. So at least implementors should not have any objections.
>
> So if you're eager to write an individual I-D I'd be willing to review, discuss and support it. But I won't write it.
At this point it could just be an Informational RFC, describing current practice.
>
> Ciao, Michael.
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Robert Heller <heller(a)deepsoft.com> writes:
R> At Thu, 28 Sep 2017 10:19:43 -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote:
>
>>
>> --On Thursday, September 28, 2017 2:08 PM -0400 Robert Heller
>> <heller(a)deepsoft.com> wrote:
>>
>> > OK, I have narrowed things down to slapd and sssd not playing nice with
>> > each other. slapd is able to listen on ldaps (port 636) and accept SSL
>> > connections (eg from openssl s_client and other applications using
>> > straight SSL). slapd will also listen on ldap (port 389), but refuses
>> > to negotiate a TLS connection on port 389. It also refuses to negotiate
>> > TLS connection on port 636. sssd seems to *insist* on negotiating a TLS
>> > connection on port 636 or port 389 and won't just connect using ssl to
>> > port 636. (At least that is what I *think* is going on.)
>> >
>> > So, I either need to get slapd to do TLS negotiation on port 389 OR port
>> > 636, or get sssd to NOT do TLS negotiation on port 636 and just connect
>> > with SSL.
>>
>> You're using a bit of a confusing word soup.
>
> Well, yes...
>
>>
>> ldaps == Deprecated, non-standard way of securing connection to LDAP.
>> Usually on port 636
>> startTLS == RFC standard way of securing connections to LDAP. Usually on
>> port 389
>
>
>
>>
>> If you are using ldaps, then you want startTLS to be disabled
>> if you are using startTLS, then you want it enabled.
>>
>> Your SSD config has:
>>
>> ldap_id_use_start_tls = false
>>
>> so this would be correct with use with ldaps:///
>
> But SSSD does not work with ldaps:///... It *wants* startTLS over ldap:///,
> which does not *seem* to work.
>
>>
>> You don't provide any error messages or other useful information, so one
>> can only specualte what issues you may be having.
>
> Slapd is reporting TLS Negotiation failure when SSSD tries to connect to it.
> For both port 389 (ldap:///) and 636 (ldaps:///). So I guess something is
> wrong with slapd's TLS configuration -- it is failing to do TLS Negotiation,
> either it is just not doing it or it is doing it wrong (somehow). Unless SSSD
> is not configured properly.
>>
>> I would note that most versions of openssl s_client do not support startTLS
>> with LDAP (Thus you cannot use it to test port 389). That feature was only
>> recently added to OpenSSL.
OK, back to basics,
1. check whether sssd is compiled with openssl's libcrypto:
ldd sssd
which should present something like
libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0
2. check whether slapd has been build with openssl
ldd slapd, which should present:
libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0
libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0
3. verify your certificates:
openssl verify -CAfile <file> <hostcert>
4. run slapd -h ldaps:///;
than test connection:
openssl s_client -connect <host:636> -CAfile <file>
-Dieter
>> If you want to test startTLS on port 389, your best bet is to use an ldap
>> client utility such as ldapwhoami, like:
>>
>> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w
[...]
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E