Search results for "starttls" - openldap-technical

Password Issues between provider and consumer

by Choure, Sidd

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

11 years

syncrepl failing with ldap_start_tls failed (-11)

by Iain Georgeson

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

12 years, 10 months

Syncrepl Multi-Master with multiple BDB backends

by Michael

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

10 years, 8 months

Re: Syncrepl SSL fail

by Hugo Deprez

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 >>

12 years, 11 months

Re: Security between server and client nodes.

by Jayavant Patil

>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.

12 years, 12 months

Re: Trying to understand an error message

by Khaled Blah

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 >

14 years

Re: ldapi and StartTLS

by Norman Gray

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

6 years, 3 months

Re: Openldap and sssd: getting slapd to do TLS negotiation or getting sssd to NOT do TLS negotiation

by Michael Wandel

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

7 years, 1 month

Re: How do tool verify certs with ldapi:// ?

by Peter Marschall

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

12 years, 6 months

RE: openldap and MozNSS

by Quanah Gibson-Mount

--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

11 years, 5 months

openldap-technical search results for query "starttls"