Search results for "starttls" - openldap-technical

Re: replica of schema info

by Mike Jackson

Quoting Francesco Malvezzi <francesco.malvezzi(a)unimore.it>: > good morning, > > I would like to be able to replicate the schema info only from cn=config. > > I tried to add the olcSyncrepl to cn=schema > > dn: cn=schema,cn=config > changetype: modify > add: olcSyncrepl > olcSyncrepl: .... > > but doesn't work: > <olcSyncrepl> only allowed within database declaration The correct way to enable replication after cn=config already exists is with ldapmodify: dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl > It does work to add olcSyncrepl to olcDatabase={0}config,cn=config with > a filter like: > olcSyncrepl: {0}rid=001 provider=... binddn=... bindmethod=simple > search base="cn=schema,cn=config" filter="(!(cn=core))" > > but then the whole olcDatabase={0}config,cn=config becomes a shadow > context and I'm unable to ldapmodify anything (olcLoglevel for example). > > What am I missing? You need to set up all rids in your modify operation, each listing provider with their own URI. Optionally, you could even have different credentials pointing in different directions - nothing prevents this. For n-way replication, you need to perform the same modification to n sides. Otherwise your replicas will be read-only as you have seen. This is the same for any database, not just n0. Go back and enable CRL checking after you are sure that it works, if using TLS. Example, change the macros to suit your setup and apply this same ldif to each of your replicas: dn: olcDatabase={0}config,cn=config changetype: modify add: olcSyncRepl olcSyncrepl: rid=001 provider=%%LDAP_URI_1%% bindmethod=simple timeout=0 network-timeout=0 binddn="%%CONFIG_ROOT_DN%%" credentials="%%CONFIG_ROOT_PW%%" keepalive=0:0:0 starttls=critical tls_cert="%%LDAP_SERVER%%/ssl/cert.pem" tls_key="%%LDAP_SERVER%%/ssl/key.pem" tls_cacert="%%CA_CHAIN_SERVERS%%" tls_reqcert=demand tls_crlcheck=none filter="(objectclass=*)" searchbase="cn=config" scope=sub attrs="*,+" schemachecking=off type=refreshAndPersist retry="60 +" olcSyncrepl: rid=002 provider=%%LDAP_URI_2%% bindmethod=simple timeout=0 network-timeout=0 binddn="%%CONFIG_ROOT_DN%%" credentials="%%CONFIG_ROOT_PW%%" keepalive=0:0:0 starttls=critical tls_cert="%%LDAP_SERVER%%/ssl/cert.pem" tls_key="%%LDAP_SERVER%%/ssl/key.pem" tls_cacert="%%CA_CHAIN_SERVERS%%" tls_reqcert=demand tls_crlcheck=none filter="(objectclass=*)" searchbase="cn=config" scope=sub attrs="*,+" schemachecking=off type=refreshAndPersist retry="60 +" - add: olcMirrorMode olcMirrorMode: TRUE -mike

11 years

Re: olcAccess replication - error 80 attributes not within database namespace

by Igor Zinovik

2013/5/17 Howard Chu <hyc(a)symas.com> > Igor Zinovik wrote: > >> Hello. >> >> I'm trying to replicate access rules and limits for one of my databases, >> but >> with no success: >> suse:~ # cat olcAccess-syncrepl.ldif >> dn: olcDatabase={1}mdb,cn=config >> changetype: modify >> add: olcSyncrepl >> olcSyncrepl: {1}rid=002 >> provider=ldap://ldap1.local >> bindmethod=simple >> binddn="cn=admin,cn=config" >> credentials="TopSecret" >> searchbase="olcDatabase={1}**mdb,cn=config" >> attrs="olcAccess,olcLimits" >> timeout=3 >> network-timeout=0 >> starttls=yes >> tls_cert="/etc/openldap/ldap.**pem" >> tls_key="/etc/openldap/ldap.**key" >> tls_cacert="/etc/ssl/local-ca.**pem" >> tls_reqcert=demand >> tls_crlcheck=none >> >> >> suse:~ # ldapmodify -H ldap://ldap2.local -ZZxWD cn=admin,cn=config -f >> olcAccess-syncrepl.ldif >> Enter LDAP Password: >> modifying entry "olcDatabase={1}mdb,cn=config" >> ldap_modify: Other (e.g., implementation specific) error (80) >> additional info: Base DN "olcAccess,olcLimits" is not within the >> database naming context >> > > > slapd-2.4.33 if it matters. > > The error message is a bit garbled (obviously the Base DN is wrong) but > the error is basically correct. You're trying to replicate the wrong thing > from the wrong place. Setting a syncrepl consumer on the olcDatabase={1}mdb > database lets you replicate the *content* of that database. To replicate > the *configuration* of that database your consumer must be set where that > configuration is stored. > > The configuration is stored in olcDatabase={0}config. > Thanks Howard, but I still cannot get things working. Could you exaplain me following (i read documentation but it is not clear enough for me to understand): Does parameter `searchbase' in olcSyncrepl configuration statement set search starting point or it sets just a database name (which is set in olcSuffix) where search is performed? Here is my configuration provider setup: ldap1:~ # ldapsearch -H ldap://ldap1.local -LLLZZxWD cn=admin,cn=config -b olcOverlay={0}syncprov,olcDatabase={0}config,cn=config '&' dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 Here is my configuration consumer: ldap2:~ # ldapsearch -H ldap://ldap2.local -LLLZZxWD cn=admin,cn=config -b olcDatabase={0}config,cn=config '&' olcSyncrepl Enter LDAP Password: dn: olcDatabase={0}config,cn=config olcSyncrepl: {0}rid=001 provider=ldap://ldap1.local bindmethod=simple bind dn="cn=admin,cn=config" credentials="TopSecret" searchbase="cn=con fig" scope=sub filter="(olcDatabase={1}mdb)" attrs="olcAccess,olcLimits" retr y="60 +" timeout=3 network-timeout=0 starttls=yes tls_cert="/etc/openldap/lda p.pem" tls_key="/etc/openldap/ldap.key" tls_cacert="/etc/ssl/local-ca.pem" t ls_reqcert=demand tls_crlcheck=none A bit offtopic: could you guys implement some kind of human friendly formatting for long line statements and ACLs? So previous statement would look like this when i fetch it from catalog: olcSyncrepl: {0}rid=001 provider=ldap://ldap1.local bindmethod=simple binddn="cn=admin,cn=config" credentials="TopSecret" searchbase="cn=config" scope=sub filter="(olcDatabase={1}mdb)" attrs="olcAccess,olcLimits" retry="60 +" timeout=3 network-timeout=0 starttls=yes tls_cert="/etc/openldap/ldap.pem" tls_key="/etc/openldap/ldap.key" tls_cacert="/etc/ssl/local-ca.pem" t ls_reqcert=demand tls_crlcheck=none

12 years

RE26 testing call (2.6.10) #1

by Quanah Gibson-Mount

This is the first testing call for OpenLDAP 2.6.10. Depending on the results, this may be the only testing call. Generally, get the code for RE26: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_6/o…> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.6.10 Engineering Added slapd microsecond timestamp format for local logging (ITS#10140) Fixed libldap ldap_result behavior with LDAP_MSG_RECEIVED (ITS#10229) Fixed lloadd handling of starttls critical (ITS#10323) Fixed slapd syncrepl when used with slapo-rwm (ITS#10290) Fixed slapd regression with certain searches (ITS#10307) Fixed slapo-autoca olcAutoCAserverClass object (ITS#10288) Fixed slapo-pcache caching behaviors (ITS#10270) Minor Cleanup ITS#7080 ITS#7249 ITS#9934 ITS#10020 ITS#10168 ITS#10226 ITS#10279 ITS#10299 ITS#10302 ITS#10309 ITS#10312 ITS#10320 ITS#10325 ITS#10327 ITS#10328 ITS#10331 Regards, Quanah

1 month

Re: fedora and openldap

by Quanah Gibson-Mount

--On Tuesday, April 12, 2011 7:10 PM +0200 Judith Flo Gaya <jflo(a)imppc.org> wrote: > > I'm posting all the information together in this e-mail, hope you can > help me out, I'm quite desperate at this point. > > Following your advise I tried to set TLS in my server and client. > I generated the certificates for both client and server (self signed) and > sent the cacert file from the server to the clients. > > I started the server like this: > /usr/local/libexec/slapd -u ldap -h ldaps://curri0.imppc.local:636 -f > /usr/local/openldap-2.4.25/etc/openldap/slapd.conf -d 1 > > ( I installed a newer version of openldap in my server as the RH6 uses an > old one, I compiled it with tls and openssl) > > From the client I do : > ldapsearch -x -ZZ -d1 -h curri0.imppc.local:636 This is a startTLS request. You are using LDAPS. This will never work. Try ldapsearch -x -H ldaps://curri0.imppc.local:636/ instead. --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

14 years, 2 months

Re: why didn't ldap client validate ssl certificate?

by Tony G.

Hi Lei, What is the command line you are using with ldapsearch? You need to specify -Z to start TLS and use certs. >From man ldapsearch: -Z Issue StartTLS (Transport Layer Security) extended operation. If you use -ZZ, the command will require the operation to be successful. Give it a try. On Wed, Oct 21, 2009 at 4:28 AM, Hallvard B Furuseth < h.b.furuseth(a)usit.uio.no> wrote: > leilei175(a)gmail.com writes: > > On the client side,I have set the TLS_REQCERT as demand. > > The TLS_CACERTDIR is also set, but I didn't put any certificate in the > > directory. > > > > To my surprise, even though no certificate is provided, > > ldapsearch could still succeed returning the data. > > > > Is this a bug? > > Maybe the root certificate is installed with OpenSSL's default certs. > > Those are used if and only if you specify TLS_CACERT - or TLS_CACERTDIR > I presume, but I haven't tested that. See: > http://www.openldap.org/its/?findid=5582 > > -- > Hallvard > -- Tony

15 years, 7 months

Re: Syncrepl filtering

by Nick Milas

It seems we don't have much input on syncrepl filtering, but I found this thread, and it might serve as a starting point for testing: http://www.openldap.org/lists/openldap-technical/200906/msg00311.html Here is the working setup on the syncrepl consumer: syncrepl rid=123 provider=ldap://rh-test3.kvm.rla:389 type=refreshOnly interval=00:00:01:00 retry="30 10 600 20" searchbase="dc=local" filter="(|(objectClass=sambaGroupMapping)(uid=user1))" scope=sub schemachecking=off bindmethod=simple binddn="uid=syncrepl,ou=sysusers,dc=local" credentials=pwdsyncrepl # BEGIN Session TLS starttls="critical" tls_cacert=__CACERTFILE__ # End Session TLS Obviously the binddn should have (just read ?) access to the part of the DIT being replicated. In that thread, the user is using syncrepl type=refreshOnly with a filter on Openldap 2.3. From an older thread (on openldap v2.3.11): http://www.openldap.org/lists/openldap-bugs/200512/msg00014.html, you can see another working setup. The user mentions some problems with type = refreshAndPersist replication but these are reported as corrected in subsequent openldap versions. Nick

14 years, 7 months

slapd mmr failure due to tls cert name mismatch

by Patrick Hemmer

I have 2 servers (version 2.4.31) in multi-master-replication behind a single IP. Whenever replication tries to start, it fails because the cert name does not match the hostname. ---- TLS: hostname (per5-unity-ldap02.mbox.net) does not match common name in certificate (unity-ldap.mbox.net). 5009c52e slap_client_connect: URI=ldap://per5-unity-ldap02.mbox.net Error, ldap_start_tls failed (-11) 5009c52e do_syncrepl: rid=523 rc -11 retrying (5 retries left) ---- However in the slapd configuration, I have the olcSyncrepl tls_reqcert parameter set to 'never' ---- olcSyncrepl: {0}rid=523 provider="ldap://per5-unity-ldap02.mbox.net" network-timeout=2 retry="1 10 10 60 60 +" keepalive="60:3:60" starttls=critical tls_reqcert=never bindmethod=simple timeout=2 binddn="uid=foo,cn=bar" credentials="baz" type=refreshAndPersist searchbase="dc=my,dc=domain" ---- Why is this happening? I even ran across ITS#7014 which is about this exact issue, and with tls_reqcert=allow and tls_reqcert=never, it's not supposed to happen. Thanks -Patrick

12 years, 10 months

TLS_REQCERT and no server certificate

by Jan Synacek

Hello, quoting ldap.conf(5): TLS_REQCERT <level> ... try The server certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, the session is immediately terminated. ... I'd like to try the "If no certificate is provided" part, but can't manage to do so. I tried configuring the server to 1) not use any CA certificate or server certificate, 2) only use the CA certificate without any server certificate, 3) specify CA certificate dir with no certs in it, 4) specify CA certificate dir with a valid CA cert and no server certs. In any case, the client (ldapsearch) doesn't even connect to the server, stating either "SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure" or simply failing to connect with "Can't contact LDAP server (-1)". The server is listening on ldap and ldaps. I tested this using both ldaps and StartTLS. That leads me to a conclusion that what I'm trying to achieve is not achievable and that the manpage should be changed. Is the manpage wrong or is there any other way I can test the client with no server certificate provided? Cheers, -- Jan Synacek Software Engineer, Red Hat

11 years, 7 months

Re: LDAPS Support

by Ozgur K

06.06.2018, 21:59, "Dieter Klünter" <dieter(a)dkluenter.de>: > Am Tue, 05 Jun 2018 03:36:11 +0100 > schrieb web(a)tomjay.co.uk: > >> 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? Hello, please you can look more carefully to OpenLDAP website: http://www.openldap.org/faq/data/cache/185.html https://www.openldap.org/pub/ksoper/OpenLDAP_TLS_obsolete.html You can run ldaps: by creating and integrate SSL certificates. Regards Ozgur > RFC 4511 and 4513 are quite clear about this. While start TLS is defined > in RFC 2830, there is no formal specification for ldaps, furthermore > read on ldaps in /etc/services. > > -Dieter > > -- > Dieter Klünter | Systemberatung > http://sys4.de > GPG Key ID: E9ED159B > 53°37'09,95"N > 10°08'02,42"E

7 years

keepalive parameter setting in openldap for consumer doesnot work

by pramod kulkarni

Hi, I unplugged network cable of provider,added new users but it never synchronizes. with the consumer.Consumer never sends the keepalive signals I am using 2.4.39 version of Openldap on windows machine this is my consumer setting olcSyncrepl: {0}rid=002 provider=ldap://ipaddress:389 bindmethod=sasl timeou t=0 network-timeout=0 saslmech=external keepalive=1:1:10 starttls=critical tl s_cert="CN=Consumer3, O=CRAP" tls_cacert="CN=TestCA, O=CRAP" tls_reqcert=demand tls_cipher_suite=HIGH:MEDIUM:-SSLv2 filter="(objectclass=*)" searchbase="dc= crap,dc=com" scope=sub attrs="*,+" schemachecking=off type=refreshAndPersis t retry="60 +" if I make fresh setup of consumer & provider,it works & everything gets replicated properly. In the earlier version of openldap it was based on system setting like I used to get keepalive every 2 hours. What is the minimum value to be set for keepalive parameter in syncrepl? Can you please tell me do I need to make any changes on consumer side or provider ?

10 years, 9 months

openldap-technical search results for query "starttls"