Everything is setup on RHEL 6.4 with Openldap 2.4.
I have one provider and one consumer. StartTLS has been enabled and everything is working as intended. My only problem arises here -
When a user is setup with a password and he tries to change his password on a consumer pointing client, I get a passwd: Authentication token manipulation error. This message is misleading since the password is in fact changed on the provider ( I have the olcUpdateRef directive setup). This creates a situation where the user can login to consumer pointed boxes with his old password and provider pointed boxes with his new password. If the user tries to change his password for the second time on consumer pointed boxes, I get Password change failed. Server message: unwilling to verify old password passwd: Authentication token manipulation error which understandably is because the password in the actual LDAP db is different from what is being supplied and being accepted by the client. What is going on here? Why isn’t the password not getting updated properly in the consumer?
Here are some of the relevant snippets of configs -
For Syncrepl in olcDatabase={2}bdb.ldif on consumer
###For Replication
olcSyncrepl: rid=100
provider="ldap://server.com
type=refreshAndPersist
retry="60 30 300 +"
searchbase=“dc=ex,dc=example,dc=com"
bindmethod=simple
binddn="cn=Manager,dc=ex,dc=example,dc=com"
credentials=secret
starttls=yes
tls_cacert=/etc/pki/CA/cacert.pem
tls_cert=/etc/pki/tls/certs/cert.pem
tls_key=/etc/pki/tls/certs/key.pem
olcUpdateRef: ldap://server.com
ACL on provider -
lcAccess: to attrs=userPassword
by self write
by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write
by anonymous auth
by * none
olcAccess: to *
by self write
by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write
by users read
olcAccess: to attrs=entry
by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write
by * read
Let me know if any more configs are needed and I will post them. Any help is appreciated.
Siddharth Choure
Senior Systems Engineer
Hello,
* Summary:
I'm trying to set up syncrepl in my LDAP infrastructure. The logs on
my consumer show that syncrepl is failing to negotiate TLS when
connecting to the provider. Other LDAP commands such as ldapsearch and
sssd show no problem connecting using the same TLS configuration.
At this point, I don't have a good idea of how to continue debugging
this problem. Are there any more configuration items affecting TLS I
should be looking at? Or any way of getting more details on the TLS
nagotiation?
* The provider ("auth-00.[MYDOMAIN]"):
slapd 2.4.23 from openldap-servers-2.4.23-15.el6.x86_64 on Scientific
Linux 6. TLS is configured with
[cn=config]
olcTLSCACertificateFile: /etc/ssl/[MYCA].pem
olcTLSCertificateFile: /etc/ssl/certs/auth-00.crt.pem # Has
CN=auth-00.[MYDOMAIN]
olcTLSCertificateKeyFile: /etc/ssl/private/auth-00.key.pem
olcTLSVerifyClient: never
If I try:
$ ldapsearch -ZZ -x -H ldap://auth-00.[MYDOMAIN]/ uid=iain
it connects and cheerfully returns objects
* The provider ("auth-01.MYDOMAIN"):
Same slapd version, same package, same OS. syncrepl configuration:
olcSyncrepl: rid=001 provider=ldap://auth-00.[MYDOMAIN]:389
bindmethod=simple timeout=0
network-timeout=0 binddn="cn=syncrepl,dc=[MYDOMAIN]"
credentials="[MYPASSWORD]"
keepalive=0:0:0 filter="(objectClass=*)" searchbase="dc=[MYDOMAIN]" scope=sub
schemachecking=off type=refreshAndPersist retry="10 3 120 5 600 +"
starttls=critical
tls_cacert=/etc/ssl/MYCA.pem
* The error
Consumer:
Jan 28 11:53:12 auth-01 slapd[5595]: slapd starting
Jan 28 11:53:12 auth-01 slapd[5595]: slap_client_connect:
URI=ldap://auth-00.[MYDOMAIN]:389 Error, ldap_start_tls failed (-11)
Jan 28 11:53:13 auth-01 slapd[5595]: do_syncrepl: rid=001 rc -11
retrying (2 retries left)
Provider receiving syncrepl connection:
Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 fd=32 ACCEPT from
IP=[AUTH-01'S IP]:42669 (IP=0.0.0.0:389)
Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 op=0 STARTTLS
Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 op=0 RESULT oid= err=0 text=
Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 fd=32 closed (TLS
negotiation failure)
Provider receiving ldapsearch connection:
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 fd=103 ACCEPT from
IP=[AUTH-01'S IP]:42765 (IP=0.0.0.0:389)
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 op=0 STARTTLS
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 op=0 RESULT oid= err=0 text=
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 fd=103 TLS established
tls_ssf=256 ssf=256
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 op=1 BIND [...]
Thanks,
Iain.
--
Systems Engineer
KAUST Visualisation Laboratory
I have two servers i'd like to setup to do MMR. I have several BDB backends that I would like to replicate. My question is do I need to create a "replicate" user for each BDB backend as well as a syncrepl statement under each BDB definition and an acl to allow the sync user to read the each BDB? Consider the slapd configuration below. Or is is possible to just setup one user with read access to all of my BDB backends and then setup just one syncrepl statement?
serverID 1 ldap://txeduds1
serverID 2 ldap://txeduds2
database bdb
suffix "dc=il,dc=edu,dc=com"
rootdn "cn=LDAPAdmin,dc=il,dc=edu,dc=com"
rootpw xxxx
directory /var/lib/ldap/ldap.edu.il
monitoring off
syncrepl rid=001
provider=ldap://txeduds1:389
type=refreshAndPersist
retry="60 10 300 +"
searchbase="dc=il,dc=edu,dc=com"
attrs="*,+"
schemachecking=off
bindmethod=simple
starttls=no
tls_reqcert=never
binddn="cn=ilreplicator,ou=ilservice,dc=il,dc=edu,dc=com"
credentials=xxxx
##Syncrepl
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
mirrormode on
limits dn.exact="cn=ilreplicator,ou=ilservice,dc=il,dc=edu,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
####################################################################################
####################################################################################
access to attrs=userpassword
by dn.base="cn=njreplicator,ou=njservice,dc=nj,dc=edu,dc=com read
by self write
by anonymous auth
by * none
database bdb
suffix "dc=nj,dc=edu,dc=com"
rootdn "cn=LDAPAdmin,dc=nj,dc=edu,dc=com"
rootpw xxxx
directory /var/lib/ldap/ldap.edu.nj
monitoring off
syncrepl rid=001
provider=ldap://txeduds1:389
type=refreshAndPersist
retry="60 10 300 +"
searchbase="dc=nj,dc=edu,dc=com"
attrs="*,+"
schemachecking=off
bindmethod=simple
starttls=no
tls_reqcert=never
binddn="cn=njreplicator,ou=njservice,dc=nj,dc=edu,dc=com"
credentials=xxx
##Syncrepl
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
mirrormode on
limits dn.exact="cn=njreplicator,ou=njservice,dc=nj,dc=edu,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
####################################################################################
####################################################################################
access to attrs=userpassword
by dn.base="cn=gareplicator,ou=gaservice,dc=ga,dc=edu,dc=com" read
by self write
by anonymous auth
by * none
database bdb
suffix "dc=ga,dc=edu,dc=com"
rootdn "cn=LDAPAdmin,dc=ga,dc=edu,dc=com"
rootpw xxx
directory /var/lib/ldap/ldap.edu.ga
syncrepl rid=001
provider=ldap://txeduds1:389
type=refreshAndPersist
retry="60 10 300 +"
searchbase="dc=ga,dc=edu,dc=com"
attrs="*,+"
schemachecking=off
bindmethod=simple
starttls=no
tls_reqcert=never
binddn="cn=gareplicator,ou=gaservice,dc=ga,dc=edu,dc=com"
credentials=xxx
##Syncrepl
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
mirrormode on
Hello,
after reading :
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=734187
It seems that when the consumer provide ldaps service, I must specify
tls_key and tls_cert parameter with the provider files.
If not specified, syncrepl will use consumer certificat and they will
never match the provider cert. This is why I got the error :
slapd[31043]: do_syncrepl: rid=003 rc -1 retrying (9 retries left)
the private key didn't match with the provider.
So in this setup, cert and private key from provider must be deployed
on each consumer.
Regards,
Hugo
On 6 December 2011 12:04, Hugo Deprez <hugo.deprez(a)gmail.com> wrote:
> Hello,
>
> if I don't sepcify the key path I get the following error when starting slpad :
>
> slap_client_connect: URI=ldaps://ldap.domain.fr:1024/ TLS context
> initialization failed (-1)
> slapd[31043]: do_syncrepl: rid=003 rc -1 retrying (9 retries left)
>
> So I need the tls_key=/etc/ldap/ssl/ldap-key.pem pointing to the key
> of the provider.
>
> Any idea why I should specify the private key of the provider ?
>
> Regards,
>
> On 2 December 2011 15:11, Raffael Sahli <public(a)raffaelsahli.com> wrote:
>> On 12/02/2011 02:50 PM, Hugo Deprez wrote:
>>>
>>> Hello Philip,
>>>
>>> thank you for your explanation.
>>>
>>> This is more clear now.
>>>
>>> So I changed my configuration like :
>>>
>>> Syncrepl rid=003
>>> provider=ldaps://my.server:1024/
>>> type=refreshOnly
>>> retry="60 10 600 +"
>>> interval=00:00:00:10
>>> searchbase="dc=my,dc=domain"
>>> scope=sub
>>> schemachecking=on
>>> bindmethod=simple
>>> tls_reqcert=demand
>>> tls_cert=/etc/ssl/certs/ldap-cert.pem
>>> tls_cacert=/etc/ssl/certs/ldap-cert.pem
>>> tls_key=/etc/ldap/ssl/ldap-key.pem
>>> binddn="cn=syncrepluser..."
>>> credentials=********
>>>
>>> I added the tls_key, tls_cacert, tls_reqcert parameter.
>>> The tls option are using the certificate and the key of the LDAP Provider.
>>>
>>> The last thing I don't understand is that the tls_key is needed. So I
>>> need to deploy the private key of the provider to each consumer.
>>>
>>> I though the certificate would be sufficient ?
>>
>>
>> No you don't have to deploy the private key!
>> In syncrepl, just define the tls_cacert, and it works.
>>
>>
>>
>>>
>>> Regards,
>>>
>>>
>>>
>>>
>>>
>>> On 18 October 2011 06:28, Philip Guenther
>>> <guenther+ldaptech(a)sendmail.com> wrote:
>>>>
>>>> On Sun, 16 Oct 2011, Hugo Deprez wrote:
>>>>>
>>>>> It seems that the proper configuration for my case is :
>>>>>
>>>>> syncrepl rid=003
>>>>> provider=ldaps://ldap.mydomain.fr:1024/
>>>>> type=refreshOnly
>>>>> retry="60 10 600 +"
>>>>> interval=00:00:00:10
>>>>> searchbase="dc=mydomain,dc=fr"
>>>>> scope=sub
>>>>> schemachecking=on
>>>>> bindmethod=simple
>>>>> tls_reqcert=never
>>>>> binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
>>>>> credentials=my_password
>>>>>
>>>>> It works, but I am confuse with those parameters. If I understand
>>>>> well, I will never use TLS here, but only ssl ?
>>>>> Hence, it was a TLS issue ?
>>>>
>>>> No, you're using TLS. You're just not using the StartTLS operation.
>>>>
>>>> There are two ways to use SSL/TLS: "negotiate-on-connect" and "upgrade
>>>> from clear". The former is what you get when you use an ldaps:// URL,
>>>> where the first data the client sends is the raw SSL/TLS ClientHello
>>>> packet. The latter is what you get when you use an ldap:// URL and have
>>>> starttls=yes or starttls=critical, where the first data the client sends
>>>> is LDAP protocol data in the clear, including a StartTLS request. If the
>>>> server sends a success response to that StartTLS request, then the client
>>>> starts the SSL/TLS handshake with its ClientHello packet.
>>>>
>>>> This should answer why it failed when you tried to combine an ldaps://
>>>> URL
>>>> with starttls=yes: the exchange was already using SSL/TLS and (rightly)
>>>> libldap won't let you negotiate multiple levels of SSL/TLS encryption.
>>>>
>>>> (You may note that I write "SSL/TLS". That's because they're just
>>>> different versions of the same protocol. Using 'SSL' as a shorthand for
>>>> "negotiate on connect" and 'TLS' for "upgrade from clear" is poor naming,
>>>> as the choice of method is orthogonal to the protocol version. Your
>>>> ldaps:// connection is probably negotiating the TLS 1.0 protocol (aka SSL
>>>> version 3.1), just as an ldap:// connection using StartTLS may, on a
>>>> poorly configured server, negotiate SSL 3.0)
>>>>
>>>>
>>>> Next: the fact that you need tls_reqcert=never for TLS negotiation to
>>>> succeed strongly suggests the problem is either
>>>> a) the subject and subjectAltName of the cert don't match the hostname in
>>>> the URL, OR
>>>> b) the client doesn't have the self-signed CA cert at the root of the
>>>> signing chain for the server's cert.
>>>>
>>>> Those are both necessary to protect the server against Man-in-the-Middle
>>>> attacks.
>>>>
>>>> (It used to be that tls_reqcert=allow would disable check (b) and only
>>>> perform check (a), or at least that was the case when using the OpenSSL
>>>> crypto backend, but that behavior has apparently been removed from the
>>>> version in git as of August. Given the vagaries of the error reporting
>>>> of
>>>> the underlying crypto libraries, this was a useful tool in tracking down
>>>> which check was causing TLS failures. Oh well.)
>>>>
>>>> So, does the server's certificate subject or subjectAltName match the
>>>> hostname from the URL the client is using? Have you verified that the CA
>>>> at the root of the server's cert's chain really is configured for the
>>>> client?
>>>>
>>>>
>>>> Philip Guenther
>>
>>
>>
>> --
>> Raffael Sahli
>> public(a)raffaelsahli.com
>> Switzerland
>>
>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli <public(a)raffaelsahli.com>
wrote:
>Hi
>I think you mean SSL connection or the STARTTLS Layer...?
>Please read the manual http://www.openldap.org/doc/admin24/tls.html
Ok.
>And tree security:
>On my server, a client user can only see his own object:
Are you using simple authentication mechanism?
>Maybe create a rule like this:
>access to filter=(objectClass=
>simpleSecurityObject)
> by self read
> by * none
I am not getting what the ACL rule specifies. Any suggestions?
--
Thanks & Regards,
Jayavant Ningoji Patil
Engineer: System Software
Computational Research Laboratories Ltd.
Pune-411 004.
Maharashtra, India.
+91 9923536030.
I see. I will have to look at it more closley. Thanks for your reply, Hallvard!
Regards,
Khaled
2010/11/12 Hallvard B Furuseth <h.b.furuseth(a)usit.uio.no>:
> Khaled Blah writes:
>> Thanks for your reply, Hallvard. Do I understand it correctly that I
>> can re-use LDAP structures on which a bind has already been done?
>
> Yes, a Bind on an LDAP* remains in force until the next Bind, possibly
> StartTLS (I don't remember) or Unbind.
>
>> Do you know of any other stateful data I would have to look at?
>
> The assertion implies a broken data structure, so my guess is you either
> reused the LDAP* after Unbind, or you have some data corruption in your
> program.
>
> --
> Hallvard
>
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, I bump it up to 256, to match the ssf=256 I have set in
> the olcSecurity attribute on cn=config.
Many thanks for this advice -- it works perfectly. I've set olcLocalSSF
to 256.
Hmm: 71 is an oddly-chosen default. Is there a story there, I wonder?
(Apologies, also, for taking so long to respond: this project had
swapped right out of my head, and it was only a couple of days ago that
it was able to page back in).
Best wishes,
Norman
--
Norman Gray : https://nxg.me.uk
On 28.09.2017 21:41, Robert Heller wrote:
> Will these spit out useful error messages? If I just get "TLS Negotiation
> failure" it is not going to be helpful.
>
You can make it a little bit more verbose with the option "-d -1"
It is only a suggestion, but can you test the parameter
TLS_REQCERT allow
in your /etc/openldap/ldap.conf
This ist not a good option for production systems, but it seems you come
in trouble with your certificates.
You have to set your
TLS_CACERT
xor
TLS_CACERTDIR
correctly in your /etc/openldap/slapd.conf to work stressless with your
ssl/tls.
best regards
Michael
> At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote:
>
>>
>> --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>
>>
>>
>
--
Michael Wandel
Braakstraße 43
33647 Bielefeld
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' for the schema, be it "/var/run/ldpai" or "localhost",
> but for StartTLS they'll match the server cert against the *hostname*.
>
> I did not expect that, though I can see how it can be justified.
Sounds like a/the "clever trick" I was looking for.
Now that I knew for what I was looking ,I was able to find it in
ibraries/libldap/tls_{o,g,m}.c
Thanks a lot
Peter
--
Peter Marschall
peter(a)adpm.de
--On Tuesday, June 25, 2013 11:40 AM -0400 Rodney Simioni
<rodney.simioni(a)verio.net> wrote:
> I'm getting further, I went to http://ltb-project.org and downloaded a
> newer version of openldap. BTW, thank you, it's a nice site.
>
> But when I do a 'ldapsearch -d -1 -x -LLL -ZZ', I'm getting " unsupported
> extended operation"
>
> Does anybody have a clue?
I would advise you to specifically use -H <URI> so it is clear what you are
connecting to and how. For example, -ZZ requests startTLS, but if you are
using an ldaps:// URI, that makes no sense, because they are mutually
exclusive.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration