Search results for "starttls" - openldap-technical

Re: Ubuntu Server 12.04: StartTLS

by Admus

On 11/05/2012 09:24 PM, Philip Guenther wrote: > On Mon, 5 Nov 2012, Admus wrote: > ... >> The output of `gnutls-cli --print-cert -p 636 ldap1.example.com` is: >> >> - The hostname in the certificate matches 'ldap1.example.com'. >> - Peer's certificate issuer is unknown >> - Peer's certificate is NOT trusted > In order to verify the server's certificate, root CA that's 'above' the > server's cert needs to be configured as a trusted CA for the client. > > For OpenSSL, that's done by placing it in the file designated by the > TLS_CACERT ldap.conf option, or in the directory designated by the > TLS_CACERTDIR ldap.conf option with the correct hashed filename. > > The ldap.conf(5) manpage indicates that the latter is ignored for GnuTLS, > so presumably you just have to place the trusted root certificate(s) in a > single file and point TLS_CACERT at that, in whatever format GnuTLS uses. > > > Philip Guenther > My cn=config looks as follow: olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem olcTLSCertificateFile: /etc/ssl/certs/ldap1_slapd_cert.pem olcTLSCertificateKeyFile: /etc/ssl/private/ldap1_slapd_key.pem I tried also set TLS_CACERT in /etc/ldap/ldap.conf to: TLS_CACERT /etc/ssl/certs/cacert.pem and TLS_CACERT /etc/ssl/certs/ldap1_slapd_cert.pem but without success, the error has became same. What should be TLS_CACERT value? Is /etc/ldap/ldap.conf respected at all? My client and server is the same host.

12 years, 7 months

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

by Dieter Kluenter

Robert Heller <heller(a)deepsoft.com> writes: > 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. > > How the hell do I get that to happen? [...] These are two differnt ports and methods to connect. On port 389 a client initiates a secured session by calling startTLS extended operation. While on port 636 the server requests a secured session. Check your init script, or systemctl service script, whether ldap:/// or ldaps:// is initiated, or both. -Dieter -- Dieter Klünter | Systemberatung http://sys4.de GPG Key ID: E9ED159B 53°37'09,95"N 10°08'02,42"E

7 years, 8 months

Re: Syncrepl question

by Quanah Gibson-Mount

--On Friday, December 05, 2008 1:18 PM -0800 Ivan Ordonez <iordonez(a)nature.berkeley.edu> wrote: > Hi Quanah, > > I was able to get it to work earlier when I add the startls=critical > line. It work when I did it on the slave1, at the time, I made the > slave1 as the master. Thanks so much for that. Now moving on the the > real master, things did not go well. Now the issue is that, any changes > I make on the master, doesn't go to the slaves. I have two slaves and I > want those two to get the changes. > > example: > > Master > | > _ _ _ _ _| |_ _ _ _ _ > | | > | | > | | > Slave1 Slave2 > > Now, when I make any change on the master, the changes will take effect > only on master and not on the slaves. I will get this error on both > slaves. > Is this because of the acl.bdc.readonly.conf line I have on both slave's > slapd.conf file? pdbedit -Lv username still work only on account were no > changes are made. Do you see any errors on the master from the slaves binding? Are you sure they have the right permissions to the master? Did you look at what sync logging shows? What is the contextCSN on your master versus your slaves? At this point, I suggest we take this discussion back to the list, since we got back your earlier config issue (starttls not being set in the syncrepl config). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

16 years, 6 months

Re: Ldap is up, trying to get tls working.

by John Tobin

Certificates verify. That's a neat tool, put that information somewhere useful. I had been trying to prove that the certificates were good for a long time. I changed from nscd, to nslcd by installing via yast, nss-pam-ldapd That wasn't too bad. I configured nslcd with: Uri ldap://nightmare.dark.net:389/ Base "dc=dark,dc=net" Ssl start_tls Tls_req never Tls_cacertfile /var/lib/ldap/cacert.pem Tls_cert /var/lib/ldap/server.pem Tls_key /var/lib/ldap/server.key Ldapsearch still works .... With -ZZ But su - jtobin Gets the same error message this time from kdeinit: nightmare:/var/log # tail -f messages |grep tls Nov 1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls failed:stat=-1 Nov 1 11:48:11 nightmare kdeinit4: nss-ldap: do_open: do_start_tls failed:stat=-1 I guess I am wondering if I configured something wrong.... Why am I seeing nss-ldap in here... I installed nslcd, configured it, and didn't change any thing in ldap.conf or nsswitch.conf, should anything else be changed? tob nighttrain:~ johntobin$ On 10/28/11 12:08 PM, "Christopher Wood" <christopher_wood(a)pobox.com> wrote: > Cheap advice inline. > > On Fri, Oct 28, 2011 at 11:44:25AM -0400, John Tobin wrote: >> Folks, >> >> I have openldap up, it supports vsftpd, sshd, and 5 client linux machines >> for remote login. >> >> I would like to get tls working. I would support either ldaps [port 636], >> or the tls available on port 389, I am aware of the differences in >> implementation, and the fact that an administrator effectively has to make >> a decision to support one or the other in most cases. >> >> Currently: >> I have slapd running configured for tls under ldap [std port 389]. >> I am testing it on the slapd machine, with a client on the same machine. >> I am pointing to the same cacertificate in slapd.d [cn=config.ldif] and >> ldap.conf. >> >> With that in place, and the ldap.conf below: >> nightmare:/etc # cat ldap.conf >> >> base dc=dark,dc=net >> uri ldap://nightmare.dark.net >> # scope sub >> # binddn "cn=admin,dc=dark,dc=net" >> # bindpw jackie >> bind_policy soft >> # The user ID attribute (defaults to uid) >> pam_login_attribute uid >> pam_lookup_policy yes >> pam_password exop >> nss_schema rfc2307bis >> tls_reqcert never >> pam_filter objectClass=posixAccount >> ldap_version 3 >> nss_map_attribute uniqueMember uniqueMember >> ssl start_tls >> tls_cacert /var/lib/ldap/cacert.pem >> tls_cert /var/lib/server.crt >> tls_key /var/lib/ldap/server.key >> >> I have run ldapsearch: >> nightmare:/media # ldapsearch -v -x -H ldap://nightmare.dark.net:389/ -b >> "dc=dark,dc=net" -Z > > Always test starttls with -ZZ, so if your starttls isn't working the > connection will fail. > >> ldap_initialize( ldap://nightmare.dark.net:389/??base ) >> filter: (objectclass=*) >> requesting: All userApplication attributes >> # extended LDIF >> # >> # LDAPv3 >> # base <dc=dark,dc=net> with scope subtree >> # filter: (objectclass=*) >> # requesting: ALL >> # >> >> # dark.net >> dn: dc=dark,dc=net >> dc: dark >> o: dark >> objectClass: organization >> objectClass: dcObject >> >> # admin, dark.net >> dn: cn=admin,dc=dark,dc=net >> objectClass: organizationalRole >> cn: admin >> >> # Default Policy, dark.net >> dn: cn=Default Policy,dc=dark,dc=net >> objectClass: namedObject >> objectClass: pwdPolicy >> cn: Default Policy >> >> # People, dark.net >> dn: ou=People,dc=dark,dc=net >> objectClass: organizationalUnit >> ou: People >> description: People is used in mapping the /etc/passwd entries >> >> # jtobin, People, dark.net >> dn: uid=jtobin,ou=People,dc=dark,dc=net >> uid: jtobin >> cn: John C. Tobin >> objectClass: account >> objectClass: posixAccount >> objectClass: top >> objectClass: shadowAccount >> loginShell: /bin/ksh >> uidNumber: 5000 >> gidNumber: 100 >> homeDirectory: /home/jtobin >> gecos: John C. Tobin >> >> # defaultDNS, dark.net >> dn: cn=defaultDNS,dc=dark,dc=net >> cn: defaultDNS >> objectClass: top >> objectClass: suseDnsConfiguration >> suseDefaultBase: ou=DNS,dc=dark,dc=net >> >> # DNS, dark.net >> dn: ou=DNS,dc=dark,dc=net >> objectClass: top >> objectClass: organizationalUnit >> ou: DNS >> >> # search result >> search: 3 >> result: 0 Success >> >> # numResponses: 8 >> # numEntries: 7 >> >> nightmare:~ # >> ##### >> >> So I am assuming the ldapserver on ldap://nightmare.dark.net:389/ with tls >> works. >> [I looked through the message output in /var/log/message and see the >> ³STARTTLS² and ³TLS established tls_ssf=256²] >> I have done a number of similar ldapsearches. This appears to work >> correctly. >> >> On the client machine I now do : >> >> nightmare:/media # su - jtobin >> su: user jtobin does not exist >> nightmare:/media # >> >> /var/log/message - output...... >> >> nightmare:/var/log # tail f |grep I tls >> >> Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 op=0 STARTTLS >> Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls >> failed:stat=-1 >> Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept >> failure error=-1 id=1217, closing >> Oct 28 11:29:01 nightmare slapd[11118]: conn=1217 fd=14 closed (TLS >> negotiation failure) >> Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 op=0 STARTTLS >> Oct 28 11:29:01 nightmare worker_nscd: nss-ldap: do_open: do_start_tls >> failed:stat=-1 > > Augh. If you can stop using nscd all this will be much easier for you. I > personally like nslcd rather than nss-ldap, but each to their own. > > If not, restart nscd before you start every troubleshooting round. > >> Oct 28 11:29:01 nightmare slapd[11118]: connection_read(14): TLS accept >> failure error=-1 id=1218, closing >> Oct 28 11:29:01 nightmare slapd[11118]: conn=1218 fd=14 closed (TLS >> negotiation failure) > > First I would test that all the CA certs and server certs in use are > understandable by each other. Does the server cert on the machine running > slapd validate against the CA cert on the machine running ldapsearch? Does the > server cert on the machine running slapd validate against the CA cert on the > client machine? > > openssl verify -CAfile cacert.pem servercert.pem > > If the output says "ok" then the actual cert part is fine. > > At this point I would crank up the slapd debug level (run it in the > foreground) and match it again your ldap client debug logs. See if you can > reproduce the error above using a client like ldapsearch, using the same > search parameters as the nss-ldap client would use. > >> [if you want more of the log, I can obviously get it, but these appear to >> be the important parts.] >> >> This is probably a configuration error, or a logical / architecture >> misunderstanding, ok, I m a newbie. >> Do I have certificates incorrectly generated? [certificates were generated >> via [1]http://www.openldap.org/faq/data/cache/185.html]. >> What did I do wrong? >> >> This is running openldap 2.4.26 off of Suse 12.1 milestone 5. > > I'm getting a puppetized starttls working with 2.4.26/openssl on debian, but > much the same thing. > >> Thanks in advance. >> tob >> >> References >> >> Visible links >> 1. http://www.openldap.org/faq/data/cache/185.html >

13 years, 7 months

Re: Error: CSN too old and replication fails

by Howard Chu

Howard Chu wrote: > Jérémy Wagner wrote: >> Hello, >> >> I'm facing some issues with syncrepl... >> >> The simplest situation in which I was able to reproduce the problem >> consists of 1 provider and 1 consumer. >> >> I have configured syncrepl to do a partial replication : >> >> olcSyncrepl: >> {0}rid=105 >> provider=ldaps://****:636 >> bindmethod=simple >> timeout=0 >> network-timeout=0 >> starttls=no >> filter="(mail=*)" >> searchbase="ou=groups,o=mydir" >> scope=sub >> schemachecking=off >> attrs="cn description mail member +" >> type=refreshAndPersist >> retry="60 +" >> tls_cert=**** tls_cacert=**** tls_key=**** >> >> olcSyncrepl: >> {1}rid=107 >> provider=ldaps://****:636 >> bindmethod=simple >> timeout=0 >> network-timeout=0 >> starttls=no >> filter="(objectclass=*)" >> searchbase="ou=operators,o=mydir" >> scope=sub >> schemachecking=off >> type=refreshAndPersist >> retry="60 +" >> tls_cert=**** tls_cacert=**** tls_key=**** >> >> olcSyncrepl: >> {2}rid=104 >> provider=ldaps://****:636 >> bindmethod=simple >> timeout=0 >> network-timeout=0 >> starttls=no >> filter="(uid=mytestuser)" >> searchbase="ou=people,o=mydir" >> scope=sub >> schemachecking=off >> type=refreshAndPersist >> retry="60 +" >> tls_cert=**** tls_cacert=**** tls_key=**** >> >> The initial sync (i.e. from an empty base) is fine, but then when I >> modify an entry (uid=mytestuser), it is not updated on the consumer, and >> I get the >> following messages: >> >> Feb 16 15:42:32 do_syncrep2: rid=107 NEW_COOKIE: >> rid=107,csn=20110216144232.222152Z#000000#000#000000 >> Feb 16 15:42:32 do_syncrep2: rid=104 >> cookie=rid=104,csn=20110216144232.222152Z#000000#000#000000 >> Feb 16 15:42:32 slap_graduate_commit_csn: removing 0x7fb58c0227d0 >> 20110216144232.222152Z#000000#000#000000 >> Feb 16 15:42:32 do_syncrep2: rid=104 CSN too old, ignoring >> 20110216144232.222152Z#000000#000#000000 >> Feb 16 15:43:05 do_syncrep2: rid=105 LDAP_RES_INTERMEDIATE - NEW_COOKIE >> Feb 16 15:43:05 do_syncrep2: rid=105 NEW_COOKIE: >> rid=105,csn=20110216144305.545784Z#000000#000#000000 >> Feb 16 15:43:05 slap_queue_csn: queing 0x7fb58c020b50 >> 20110216144305.545784Z#000000#000#000000 >> Feb 16 15:43:05 do_syncrep2: rid=107 LDAP_RES_INTERMEDIATE - NEW_COOKIE >> Feb 16 15:43:05 do_syncrep2: rid=107 NEW_COOKIE: >> rid=107,csn=20110216144305.545784Z#000000#000#000000 >> Feb 16 15:43:05 do_syncrep2: rid=104 >> cookie=rid=104,csn=20110216144305.545784Z#000000#000#000000 >> Feb 16 15:43:05 slap_graduate_commit_csn: removing 0x7fb58c0227d0 >> 20110216144305.545784Z#000000#000#000000 >> Feb 16 15:43:05 do_syncrep2: rid=104 CSN too old, ignoring >> 20110216144305.545784Z#000000#000#000000 >> >> (both servers are perfectly in sync with an NTP daemon) >> >> It looks like ITS #6619 is quite similar, and unresolved. >> >> What do these messages mean ? Is there a way to force the update ? > > Your current configuration is unsupported. Ordinarily when you configure > multiple consumers in a DB it is assumed they are all pointing at different > providers, and each provider will have a different serverID. In your case, > since it is all a single provider with a single serverID, all 3 consumers will > share a single contextCSN. Any update in any branch will update the contextCSN > to that newest state. Any updates in other branches that hadn't been received > yet (due to random timing between threads) will be received as "too old" > because the contextCSN already has a newer state. > > A workaround for this would be to split each consumer into its own subordinate > database, then each will have a private copy of its own contextCSN to work with. Another potential workaround, if all of the consumer configs were identical except for their baseDN, would be to simply consolidate them all into a single consumer, with a more complex search filter. searchbase=o=mydir filter=(| (&(entryDN:dnSubtreematch:=ou=groups,o=mydir)(mail=*)) (entryDN:dnSubtreematch:=ou=operators,o=mydir) (&(entryDN:dnSubtreematch:=ou=people,o=mydir)(uid=mytestuser))) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

14 years, 3 months

RE: [EXT] Re: Issue with slapd and Google LDAP Integration (lowercase user)

by Windl, Ulrich

Hi! If that’s the paths of the actual certificates, I could imagine that the user running slapd has no access to /root/ and below. Despite of that I think it’s a bad idea to place certificates for a server into a user’s home directory. Regards, Ulrich From: tmp 2810 <t2810mp(a)gmail.com> Sent: Tuesday, November 5, 2024 5:07 PM To: Quanah Gibson-Mount <quanah(a)fast-mail.org> Cc: openldap-technical(a)openldap.org Subject: [EXT] Re: Issue with slapd and Google LDAP Integration (lowercase user) Thats my actual config and the message on the logs is : Unauhtenticated ================================================ uri "ldaps://ldap.google.com/dc=proxy<http://ldap.google.com/dc=proxy>" suffixmassage "dc=proxy" "dc=example,dc=com" lastmod off readonly on idassert-bind bindmethod=sasl saslmech=EXTERNAL tls_reqcert=demand tls_reqsan=demand tls_cert=/root/ldapcerts/google_cert.crt tls_key=/root/ldapcerts/google_cert.key tls_cacert=/root/ldapcerts/ca/gtsr1.pem ================================================ I've actually been trying all kinds of configurations for the last 2 weeks. Is there a chance that this doesn't work with Google's LDAP? I can't find a single example on the entire internet of someone who has managed to do this whit the LDAP of google. El mar, 5 nov 2024 a las 12:51, Quanah Gibson-Mount (<quanah(a)fast-mail.org<mailto:quanah@fast-mail.org>>) escribió: --On Monday, November 4, 2024 8:29 PM -0300 tmp 2810 <t2810mp(a)gmail.com<mailto:t2810mp@gmail.com>> wrote: > 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<http://example.com> > uri "ldaps://ldap.google.com/dc=proxy<http://ldap.google.com/dc=proxy>" > suffixmassage "dc=proxy" "dc=example,dc=com" > lastmod off > readonly on > idassert-bind bindmethod=simple > binddn="cn=ChiwewDaw" cn, is by definition, case insensitive. If Google LDAP is forcing case sensitivity in this attribute, it is gross violation of the LDAP RFCs. However, having had to interface with it in the past, I don't believe that is the case. I would generally suspect that this is not the full DN of the user. > idassert-bind bindmethod=sasl > saslmech=EXTERNAL > tls_reqcert=demand > tls_reqsan=demand > starttls=critical This is not sufficient, please read the man page: idassert-bind bindmethod=none|simple|sasl [binddn=<simple DN>] [credentials=<simple password>] [saslmech=<SASL mech>] [secprops=<properties>] [realm=<realm>] [authcId=<authentication ID>] [authzId=<authorization ID>] [authz={native|proxyauthz}] [mode=<mode>] [flags=<flags>] [starttls=no|yes|critical] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_reqsan=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_ecname=<names>] [tls_protocol_min=<version>] [tls_crlcheck=none|peer|all] You *must* specify tls_cert, tls_key, and tls_cacert as a part of idassert-bind as it provides the TLS identity to bind as. In your configuration for simple bind, tls_cert and tls_key are unnecessary as you're not doing SASL/EXTERNAL binds. --Quanah

7 months, 1 week

Re: updating from 2.4.20 to 2.4.22 breaks syncrepl/TLS

by Thierry Lacoste

On 20 oct. 10, at 18:04, Buchan Milne wrote: > On Wednesday, 20 October 2010 16:13:44 Thierry Lacoste wrote: >> Hello, >> >> I have 2 CentOS 5.4 servers running OpenLDAP 2.4.20 >> installed from Buchan Milne's repository (openldap2.4- >> servers-2.4.20-1.el5). >> >> The first server is a Sync Provider. >> The second is a consumer with 'starttls=critical'. >> >> I have no problem after 'yum update' of the master >> (openldap2.4-servers-2.4.22-1.el5 is installed and replication is >> OK). >> >> But after 'yum update' of the slave, syncrepl won't work anymore >> because of TLS failures. >> >> Here are the logs on the master : >> Oct 20 16:51:15 vcos-castor slapd2.4[20097]: @(#) $OpenLDAP: slapd >> 2.4.22 (Apr 27 2010 12:04:27) $ >> bgmilne@centos5-32.ranger.dnsalias.com:/home/bgmilne/rpm/BUILD/ >> openldap-2.4.22/servers/slapd >> Oct 20 16:51:15 vcos-castor slapd2.4[20098]: slapd starting >> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 fd=16 ACCEPT >> from IP=IP.OF.THE.SLAVE:46212 (IP=0.0.0.0:389) >> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 op=0 EXT >> oid=1.3.6.1.4.1.1466.20037 >> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 op=0 STARTTLS >> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 op=0 RESULT >> oid= err=0 text= >> Oct 20 16:51:46 vcos-castor slapd2.4[20098]: conn=1000 fd=16 closed >> (TLS negotiation failure) >> >> Here are the logs on the slave : >> Oct 20 16:51:45 vcos-pollux slapd2.4[1808]: @(#) $OpenLDAP: slapd >> 2.4.22 (Apr 27 2010 12:04:27) $ >> bgmilne@centos5-32.ranger.dnsalias.com:/home/bgmilne/rpm/BUILD/ >> openldap-2.4.22/servers/slapd >> Oct 20 16:51:45 vcos-pollux slapd2.4[1809]: slapd starting >> Oct 20 16:51:45 vcos-pollux slapd2.4[1809]: slap_client_connect: >> URI=ldap://NAME_OF_THE_MASTER Error, ldap_start_tls failed (-11) >> Oct 20 16:51:45 vcos-pollux slapd2.4[1809]: do_syncrepl: rid=000 rc >> -11 retrying (4 retries left) >> >> ldapsearch from the slave can do TLS : >> $ ldapsearch -ZZ -x -h NAME_OF_THE_MASTER >> This is ldapsearch from openldap-clients-2.3.43-12.el5_5.2 as >> packaged >> by CentOS >> >> Any ideas on how to troubleshoot the problem? > > Note that the syncrepl statement now has its own tls configuration, > see the > options tls_cert, tls_key, tls_cacert, tls_cacertdir, tls_reqcert, > tls_ciphersuite, tls_crlcheck to the syncrepl statement. > > Regards, > Buchan Thanks a lot. That solved it. I didn't find anything about that in the Release Changes. Regards, Thierry

14 years, 7 months

Re: data import very slow for data migration

by Dieter Klünter

Am Tue, 25 Dec 2012 21:27:39 +0530 schrieb anil beniwal <beni.anil(a)gmail.com>: > Hi > > We are having 4 million users to migrate, all data exported from > oracle to multiple ldif files. > Imported 1 million till now, took almost 28 hours. and openldap-data > dir of about 28G. > openldap version 2.4.33 bdb version 5.1.29 RHEL 6.3 RAM 8G 4 cpu , > system is a VM. > > Currently running slapadd output > + /apps/openldap/sbin/slapadd -q -c -w -f > /apps/openldap/etc/openldap/slapd.conf -l /root/User9.ldif > bdb_monitor_db_open: monitoring disabled; configure monitor database > to enable > . 2.27% eta 21h31m elapsed 29m57s > spd 1.6 k/s str2entry: invalid value for attributeType > postalAddress #0 (syntax 1.3.6.1.4.1.1466.115.121.1.41) > slapadd: could not parse entry (line=394416) > * 2.81% eta 19h59m elapsed 34m40s spd > 10.1 k/s 1. There are too many errors like above. > Its seems to be taking weeks go import whole data. It takes about 2 - 4 hours in order to slapadd 4 mio.entires, depending on file system and disk type. > > is there any tool or any other approach which we can use to make it > fast,Or we are going with wrong configuration. > Or we have to switch to ODS or RHDS There is no necessity for other tools, just modify the ldif file. [...] > DB_CONFIG > > set_cachesize 0 4294967295 0 increase cachesize to at least 4GB that is set_cachesize 4 0 1 [...] > checkpoint 128 15 I would set checkpointing to 0 15 [...] > concurrency 100 > index entryCSN eq > index entryUUID eq > index > mail,uid,postalCode,smail,channelType,channelValue,answer,behavName,objectclass,tokenID,type > eq > index givenName,sn,city,question,behavValue,cn,extName sub > index displayName approx > # Replication Configuration > overlay syncprov > syncprov-checkpoint 100 10 > syncprov-sessionlog 100 > > serverid 1 > > syncrepl rid=111 > provider=ldap://s01.com > binddn="cn=Manager,dc=example,dc=com" > bindmethod=simple > starttls=yes > tls_reqcert=allow > schemachecking=off > credentials=G00gle# > searchbase="dc=example,dc=com" > type=refreshAndPersist > retry="5 5 300 +" > interval=00:00:00:10 > > syncrepl rid=222 > provider=ldap://m04.com > binddn="cn=Manager,dc=example,dc=com" > bindmethod=simple > starttls=yes > tls_reqcert=allow > schemachecking=off > credentials=G00gle# > searchbase="dc=example,dc=com" > type=refreshAndPersist > retry="5 5 300 +" > interval=00:00:00:10 > > ###### > > mirrormode TRUE > > directory /apps/openldap/var/openldap-data > > overlay unique > unique_attributes mail > > overlay ppolicy > ppolicy_default "cn=default,ou=pwdPolicy,dc=example,dc=com" > ppolicy_use_lockout Please not that overlay declarations follow all database declarations, modify slapd.conf accordingly. -Dieter -- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E

12 years, 5 months

Re: ssf Security Question

by William Brown

On Mon, 2017-11-20 at 11:22 +0000, Howard Chu wrote: > William Brown wrote: > > On Fri, 2017-11-17 at 08:34 +0100, Michael Ströder wrote: > > > William Brown wrote: > > > > Just want to point out there are some security risks with ssf > > > > settings. > > > > I have documented these here: > > > > > > > > https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_tra > > > > p.ht > > > > ml > > > > > > Nice writeup. I always considered SSF values to be naive and > > > somewhat > > > overrated. People expect too much when looking at these numbers - > > > especially regarding the "strength" of cryptographic algorithms > > > which > > > changes over time anyway with new cryptanalysis results coming > > > up. > > > > > > Personally I always try to implement a TLS-is-must policy and > > > prefer > > > LDAPS (with correct protocol and ciphersuites configured) over > > > LDAP/StartTLS to avoid this kind of pre-TLS leakage. > > > Yes, I deliberately ignore "LDAPS is deprecated". ;-] > > > > I agree. If only there was a standards working group that could > > deprecate startTLS in favour of TLS .... :) > > I have to agree as well. On my own servers I also use TLS on other > "plaintext" > ports too (such as pop3 and others) that no one has any business > connecting to > in plaintext. Yep. TLS and end-to-end is the way of the future. We need to update our documents to support this :) > > > > Furthermore some LDAP server implementation (IIRC e.g. MS AD) > > > refuse > > > to > > > accept SASL/GSSAPI bind requests sent over TLS-secured channel. > > > Which > > > is > > > IMO also somewhat questionable. > > > > Yes, I really agree. While a plain text port exists, data leaks are > > possible. We should really improve this situation, where we have > > TLS > > for all data to prevent these mistakes. > > > > I think a big part of the issue is that GSSAPI forces the > > encryption > > layer, and can't work via an already encrypted channel. The people > > I > > know involved in this space are really resistant to changing this > > due > > to the "kerberos centric" nature of the products. > > Interesting. Our libldap/liblber works fine with GSSAPI's encryption > layered > over TLS and vice versa. > Sadly your libldap/liblber is not the only one we have to use. I'm told that especially AD for IPA trust's is unable to do GSSAPI-over-TLS. Really, IMO if the SSF is already > 1, then GSSAPI shouldn't install encryption layer, but you know, I'm not the one who writes the SASL code ... If you have some contacts in this space, I'm open to suggestion as to how we can proceed to improve this, -- Sincerely, William Brown Software Engineer Red Hat, Australia/Brisbane

7 years, 6 months

RE: Openldap server with TLS not working

by Axel Grosse

Hi all, Ben, Dieter, thank you for your help ... got it working on ldaps without TLS :-)) we can close that thread cheers Axel AXEL GROSSE Principal Solution Architect, Sales Solution Center, Axway P: +61-405-995-768 828 Pacific Highway Gordon, 2072 NSW agrosse(a)axway.com http://www.axway.com -----Original Message----- From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb Sent: Friday, 4 October 2013 6:20 AM To: openldap-technical(a)openldap.org Subject: Re: Openldap server with TLS not working On 2013.10.03 08.22, Axel Grosse wrote: -----Original Message----- > From: openldap-technical-bounces(a)OpenLDAP.org > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter > Klünter > Sent: Thursday, 3 October 2013 6:46 PM > To: openldap-technical(a)openldap.org > Subject: Re: Openldap server with TLS not working > > Am Thu, 3 Oct 2013 00:16:28 +0000 > schrieb Axel Grosse <agrosse(a)axway.com>: > >> Hi ben, >> thanks for the comment. >> agree with you on TLS usage should be perferred but the client that >> is connecting is only capable of LDAPS ... he has not implemented TLS >> Client jet . >> >> But can you please take a look to the error I am facing >> >> openssl s_client -connect 192.168.30.169:389 -showcerts -CAfile >> ./ssl/VordelCA.crt CONNECTED(00000003) 710:error:140790E5:SSL >> routines:SSL23_WRITE:ssl handshake >> failure:s23_lib.c:188: >> >> any idea what can cause this ? >> >> -----Original Message----- >> From: openldap-technical-bounces(a)OpenLDAP.org >> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb >> Sent: Wednesday, 2 October 2013 10:57 PM To: >> openldap-technical(a)openldap.org Subject: Re: Openldap server with TLS >> not working >> >> On 2013.10.02 07.29, Axel Grosse wrote: >> >>> when I test on the server itself .. >>> openssl s_client -connect 192.168.30.169:389 -showcerts -CAfile >>> ./ssl/VordelCA.crt >>> CONNECTED(00000003) >>> 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake >>> failure:s23_lib.c:188: >> >> ldaps [port 636] is deprecated. use starttls with the standard port >> [389]. to test, just use ldapsearch [see the reference to -Z in the >> man page] > > You are connnecting to port 389, but s_client is not able to initiate > a LDAP startTLS session (only SMTP and IMAP), so you have to connect > ldaps and port 636. > > -Dieter > > Hi Ben, Dieter > can we focus on LDAPS because TLS1 is not an option and even if LDAPS > is deprecated I should be able to configure it .. > > TLSCACertificateFile /etc/openldap/ssl/VordelCA.crt > TLSCertificateFile /etc/openldap/ssl/VordelDev.crt > TLSCertificateKeyFile /etc/openldap/ssl/VordelDev.key > TLSVerifyClient never > > > are this entries in the slapd.conf sutable for LDAPS ? > if not whats missing ? nothing more is required > start the server with > /usr/sbin/slapd -h ldap://192.168.30.169:636 -u ldap /usr/sbin/slapd -h 'ldaps:///' [...] you must specify ldaps, and you do not need to explicitly specify the port. 636 is the default. see man 8 slapd for details.

11 years, 8 months

openldap-technical search results for query "starttls"