Search results for "starttls" - openldap-technical

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

13 years, 7 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

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

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

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

6 years, 5 months

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, 2 months

olcAccess replication - error 80 attributes not within database namespace

by Igor Zinovik

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.

11 years, 6 months

N-Way Multimaster with syncrepl and delta-repl -- slapd stops responding

by Robert W. Smith

Hi, I am running a 4-way multi-master configuration with a number of slaves in remote locations. I am currently running openldap 2.4.33 on top of CentOS 6.3 (I built 2.4.33 from a modified base centos 6 spec file). I was originally running the centos base openldap 2.4.23 using N-way multimaster using the syncrepl configuration but I was having problems with the masters and slaves staying in perfect sync--other than this 2.4.23 was running stably since last spring. I'll try to be brief in what has happened since Feb 1. * I upgraded the 4 masters to 2.4.33 and kept the syncrepl configuration. The syncrepl masters were using RefreshAndPersist while the slave consumers were using RefreshOnly. * After the upgrade the 2.4.33 masters began locking up, not refusing connections, but not returning queries--this would happen 3-4 per day. When one master locked all the masters would lock. Slaves appear to not be affected by this. * I downgraded back 2.4.23 in all of the masters only to have the lock-ups continue. * I slapcat'ed the database on one master and blew away the databases on all the other masters and slaves and rebuilt everything. I rebuilt one master and one slave and rsync'ed the slapd.d directory where needed. Then I started each master one-by-one to validate that they mirrored the databases correctly. Then I repeated this on the slaves. Unfortunately the masters would continue to lock up as above. * So, seeing that the lock-ups were occurring regardless of the openldap version I decided to go back to 2.4.33 and make the move to delta-replication. * This past weekend I finally got delta-replication working. I did the slapcat-rebuild slapd.d-slapadd on one master and rsync'ed slapd.d to each master one at a time. All was well and all databases were in perfect sync. * Unfortunately the masters would continue to lock, accepting connections but never servicing the request so all queries would hang. Looking at this again today I noticed that my masters were all running at near 100% CPU but continuing to service queries. Depending on the # of CPUs only one or two threads would be running this high. Using strace -tt -p <pid-ofthread>, this is what would be spewing out: 18:52:05.713266 sched_yield() = 0 18:52:05.713323 sched_yield() = 0 18:52:05.713380 sched_yield() = 0 18:52:05.713438 sched_yield() = 0 18:52:05.713495 sched_yield() = 0 18:52:05.713553 sched_yield() = 0 18:52:05.713611 sched_yield() = 0 18:52:05.713668 sched_yield() = 0 18:52:05.713726 sched_yield() = 0 18:52:05.713783 sched_yield() = 0 18:52:05.713840 sched_yield() = 0 18:52:05.713898 sched_yield() = 0 I haven't correlated this to the slapd daemons hanging, yet. There is nothing interesting in the logs when the slapd daemons would hang. Again when one master hangs they all would hang. I would restart each master one by one and on occasions when one master restarted the others would start servicing again. Other times it would take two or three restarts to get all of the masters servicing again. The only gain with delta-replication is that they only hang once a day now and usually after I had gone home. For now I have implemented a small script that is run from cron every two minutes to test the slapd daemons if they are hung doing a simple ldapsearch and if so then restart the slapd daemon. This is done on all four masters. My database is not large at all with only ~100 users but it is critical as it is the backend authentication for everything including the remote access. Here is the slapcat of my cn=config database (minus the schemas and operational attributes). It is a fairly typical delta-replication configuration. The accesslogs use hdb as that is what most (all) of the accesslogs examples show. The main database is bdb. Any suggestions would be greatly appreciated. Regards, Bob --bs dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: slapd.conf olcConfigDir: slapd.d olcArgsFile: /var/run/openldap/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcLocalSSF: 71 olcPidFile: /var/run/openldap/slapd.pid olcReadOnly: FALSE olcSaslSecProps: noplain,noanonymous olcSecurity: tls=1 olcServerID: 1 ldap://auth1noc.man.o3b.local olcServerID: 2 ldap://auth2noc.man.o3b.local olcServerID: 3 ldap://auth1noc.btz.o3b.local olcServerID: 4 ldap://auth2noc.btz.o3b.local olcServerID: 5 ldap://auth1gw.nma.o3b.local olcServerID: 6 ldap://auth2gw.nma.o3b.local olcServerID: 7 ldap://auth1gw.sun.o3b.local olcServerID: 8 ldap://auth2gw.sun.o3b.local olcServerID: 9 ldap://auth1gw.per.o3b.local olcServerID: 10 ldap://auth2gw.per.o3b.local olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCipherSuite: HIGH:MEDIUM:SSLv2 olcTLSCertificateFile: /etc/openldap/cacerts/auth-o3b.crt olcTLSCertificateKeyFile: /etc/openldap/cacerts/auth-o3b.key olcTLSCRLCheck: none olcToolThreads: 1 olcWriteTimeout: 0 olcTLSCACertificateFile: /etc/pki/tls/certs/o3b-master-ca.crt olcTLSVerifyClient: never olcLogLevel: sync olcConnMaxPending: 101 dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib64/openldap olcModuleLoad: {0}syncprov.la olcModuleLoad: {1}memberof.la olcModuleLoad: {2}ppolicy.la olcModuleLoad: {3}accesslog.la dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.subtree="cn=monitor" by dn.base="cn=rootdn,dc=o3bnetworks .net" read olcAccess: {2}to dn.base="cn=subschema" by * read olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSecurity: tls=1 olcMonitoring: FALSE olcPasswordHash: {SSHA} dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.base="cn=rootdn,dc=o3bnetworks.net" write by dn.bas e="cn=syncdn,dc=o3bnetworks.net" read by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcLimits: {0}dn.base="cn=rootdn,dc=o3bnetworks.net" size=unlimited time=unli mited olcLimits: {1}dn.base="cn=syncdn,dc=o3bnetworks.net" size=unlimited time=unli mited olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcMirrorMode: TRUE olcMonitoring: FALSE olcRootPW:: *** olcSyncrepl: {0}rid=001 provider=ldap://auth1noc.man.o3b.local bindmethod=simp le binddn="cn=syncdn,dc=o3bnetworks.net" credentials="33jJ9nSkSD" keepalive=0 :5:0 starttls=yes tls_reqcert=allow tls_cipher_suite=HIGH:MEDIUM:SSLv2 search base="cn=config" scope=sub schemachecking=off type=refreshAndPersist retry="5 5 300 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)( reqResult=0))" syncdata=accesslog olcSyncrepl: {1}rid=002 provider=ldap://auth2noc.man.o3b.local bindmethod=simp le binddn="cn=syncdn,dc=o3bnetworks.net" credentials="33jJ9nSkSD" keepalive=0 :5:0 starttls=yes tls_reqcert=allow tls_cipher_suite=HIGH:MEDIUM:SSLv2 search base="cn=config" scope=sub schemachecking=off type=refreshAndPersist retry="5 5 300 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)( reqResult=0))" syncdata=accesslog olcSyncrepl: {2}rid=003 provider=ldap://auth1noc.btz.o3b.local bindmethod=simp le binddn="cn=syncdn,dc=o3bnetworks.net" credentials="33jJ9nSkSD" keepalive=0 :5:0 starttls=yes tls_reqcert=allow tls_cipher_suite=HIGH:MEDIUM:SSLv2 search base="cn=config" scope=sub schemachecking=off type=refreshAndPersist retry="5 5 300 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)( reqResult=0))" syncdata=accesslog olcSyncrepl: {3}rid=004 provider=ldap://auth2noc.btz.o3b.local bindmethod=simp le binddn="cn=syncdn,dc=o3bnetworks.net" credentials="33jJ9nSkSD" keepalive=0 :5:0 starttls=yes tls_reqcert=allow tls_cipher_suite=HIGH:MEDIUM:SSLv2 search base="cn=config" scope=sub schemachecking=off type=refreshAndPersist retry="5 5 300 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)( reqResult=0))" syncdata=accesslog dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov olcSpCheckpoint: 1000 60 dn: olcOverlay={1}accesslog,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {1}accesslog olcAccessLogDB: cn=accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE olcAccessLogPurge: 2+00:00 1+00:00 dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcConfig objectClass: top objectClass: olcHdbConfig olcDbDirectory: /var/lib/ldap/accesslog olcSuffix: cn=accesslog olcDbConfig: [Deleted] aXIgLXEgb3B0aW9uKS4g olcAddContentAcl: FALSE olcDbCacheFree: 1 olcDbCacheSize: 1000 olcAccess: {0}to * by self write by dn.base="cn=rootdn,dc=o3bnetworks.net" r ead by dn.base="cn=authdn,dc=o3bnetworks.net" read by dn.base="cn=syncdn,dc= o3bnetworks.net" read olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbDNcacheSize: 0 olcDbIndex: default eq olcMaxDerefDepth: 15 olcLimits: {0}dn.base="cn=syncdn,dc=o3bnetworks.net" size=unlimited time=unli mited olcDbSearchStack: 16 olcLastMod: TRUE olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbNoSync: FALSE olcDbShmKey: 0 olcReadOnly: FALSE olcSecurity: tls=1 olcRootDN: cn=accesslogdn olcDatabase: {1}hdb dn: olcOverlay={0}syncprov,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpNoPresent: TRUE olcSpReloadHint: TRUE dn: olcDatabase={3}monitor,cn=config objectClass: olcDatabaseConfig olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=monitor,cn=Monitor olcRootPW:: bW9uaXRvcg== olcSecurity: tls=1 olcMonitoring: FALSE olcDatabase: {3}monitor dn: olcDatabase={3}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcSuffix: dc=o3bnetworks.net olcAddContentAcl: FALSE olcLastMod: TRUE olcLimits: {0}dn.base="cn=syncdn,dc=o3bnetworks.net" size=unlimited time=unli mited olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=rootdn,dc=o3bnetworks.net olcRootPW:: *** olcSecurity: tls=1 olcMirrorMode: TRUE olcMonitoring: TRUE olcDbDirectory: /var/lib/ldap olcDbConfig: [Deleted] olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass pres,eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: gidNumber pres,eq olcDbIndex: memberUid pres,eq,sub olcDbIndex: displayName pres,eq,sub olcDbIndex: sambaSID pres,eq,sub olcDbIndex: sambaDomainName pres,eq olcDbIndex: sambaGroupType pres,eq olcDbIndex: ou pres,eq,sub olcDbIndex: sambaSIDList pres,eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 olcAccess: {0}to * by self write by group/groupOfNames/member.exact="cn=ldap admins,dc=o3bnetworks.net" write by dn.base="cn=authdn,dc=o3bnetworks.net" r ead by dn.base="cn=syncdn,dc=o3bnetworks.net" read by users read by anonym ous read olcDbCacheSize: 1000 olcDatabase: {3}bdb olcSyncrepl: {0}rid=011 provider=ldap://auth1noc.man.o3b.local bindmethod=simp le binddn="cn=syncdn,dc=o3bnetworks.net" credentials="33jJ9nSkSD" keepalive=0 :5:0 starttls=yes tls_reqcert=allow tls_cipher_suite=HIGH:MEDIUM:SSLv2 search base="dc=o3bnetworks.net" scope=sub schemachecking=off type=refreshAndPersist retry="5 5 300 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWrit eObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {1}rid=012 provider=ldap://auth2noc.man.o3b.local bindmethod=simp le binddn="cn=syncdn,dc=o3bnetworks.net" credentials="33jJ9nSkSD" keepalive=0 :5:0 starttls=yes tls_reqcert=allow tls_cipher_suite=HIGH:MEDIUM:SSLv2 search base="dc=o3bnetworks.net" scope=sub schemachecking=off type=refreshAndPersist retry="5 5 300 +" logbase="cn=accesslog" logfilter="(&(objectClass=auditWrit eObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {2}rid=013 provider=ldap://auth1noc.btz.o3b.local bindmethod=simp le binddn="cn=syncdn,dc=o3bnetworks.net" credentials="33jJ9nSkSD" keepalive=0 :5:0 starttls=yes tls_reqcert=allow tls_cipher_suite=HIGH:MEDIUM:SSLv2 filter ="(objectclass=*)" searchbase="dc=o3bnetworks.net" scope=sub schemachecking=o ff type=refreshAndPersist retry="5 5 300 +" logbase="cn=accesslog" logfilter= "(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog olcSyncrepl: {3}rid=014 provider=ldap://auth2noc.btz.o3b.local bindmethod=simp le binddn="cn=syncdn,dc=o3bnetworks.net" credentials="33jJ9nSkSD" keepalive=0 :5:0 starttls=yes tls_reqcert=allow tls_cipher_suite=HIGH:MEDIUM:SSLv2 filter ="(objectclass=*)" searchbase="dc=o3bnetworks.net" scope=sub schemachecking=o ff type=refreshAndPersist retry="5 5 300 +" logbase="cn=accesslog" logfilter= "(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog dn: olcOverlay={0}memberof,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {0}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: FALSE dn: olcOverlay={1}syncprov,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {1}syncprov olcSpCheckpoint: 1000 60 dn: olcOverlay={2}ppolicy,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcPPolicyConfig olcOverlay: {2}ppolicy olcPPolicyDefault: cn=O3b,ou=Password,ou=Policy,dc=o3bnetworks.net dn: olcOverlay={3}accesslog,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: {3}accesslog olcAccessLogOps: writes olcAccessLogSuccess: TRUE olcAccessLogDB: cn=accesslog olcAccessLogPurge: 2+00:00 1+00:00

11 years, 8 months

Re: Secure replication

by Real, Elizabeth (392K)

Quanah, I ran netstat -a | egrep ":ldap" and found that the replication between my two test servers was not ldaps thus me reaching out to this forum. If “ldap://” is secure already then I do not need to proceed further. These are the SLAPD_URLS in the /etc/sysconfig/slapd file: SLAPD_URLS="ldapi:/// ldap:/// ldaps:///" I have TLS enabled everywhere and have encrypted connections between clients and servers. These are the ciphers running on both masters: SSLv3 TLSv1.2 I am using simple binds so I’ll look at SASL/EXTERNAL with authz-regexp mapping. Why is version 2.4.40 unsafe for multi-master replication? I can upgrade at a later time I just wanted to find out how to enable ldaps between the two servers. Thank you, Liz From: Quanah Gibson-Mount <quanah(a)symas.com> Reply-To: Quanah Gibson-Mount <quanah(a)symas.com> Date: Saturday, May 6, 2017 at 1:02 PM To: "Real, Elizabeth (392K)" <Elizabeth.Real(a)jpl.nasa.gov>, "openldap-technical(a)openldap.org" <openldap-technical(a)openldap.org> Subject: Re: Secure replication --On Saturday, May 06, 2017 1:56 AM +0000 "Real, Elizabeth (392K)" <Elizabeth.Real(a)jpl.nasa.gov<mailto:Elizabeth.Real@jpl.nasa.gov>> wrote: The olcSyncRepl directive on both systems needs to go from: olcSyncRepl: rid=001 provider=ldap to: olcSyncRepl: rid=001 provider=ldaps The use of "ldap://" does not mean that you have insecure replication. The "ldaps" designation was developed to allow for SSL encrypted connections as a part of LDAPv2, which did not have a formal design spec for allowing SSL encryption. The LDAPv3 spec, which is what OpenLDAP 2.4 (and much earlier version) implement, specifically has startTLS as a part of that specification, which uses "ldap:///". I.e., ldaps is a bastardized hack for LDAPv2. The proper way to do TLS encryption with LDAPv3 capable servers such as OpenLDAP 2.[1-4+] is to use the startTLS extended operation over a "ldap:///" URI. In addition, there are other ways to have an encrypted connection between an LDAP client and server without involving TLS at all, such as SASL/GSSAPI. As Michael noted, you can, in addition to enabling TLS encryption between the client and servers, use client cert authentication (SASL/EXTERNAL) so as to remove the requirement for clear text credentials to be stored in the olcSyncRepl attribute (if using simple binds). And again, the usage of SASL/GSSAPI also precludes the neccessity of storing cleartext credentials in the olcSyncRepl attribute. As an aside, I would note that 2.4.40 is completely unsafe to use with multimaster replication. I would generally suggest forming a clear set of requirements for your replication environment, and then asking how to implement them. Your current question is too vague/general to really be answered well. Hope that helps! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

7 years, 6 months

openldap-technical search results for query "starttls"