Search results for "starttls" - openldap-technical

AW: Re: AW: Re: AW: Re: AW: StartTLS is not working

by Hauke Coltzau

Hi Dat, please read the openssl man pages and make yourself familiar with the creation of certificates. There are a lot things which can be done just the wrong way, which only creates a lot of frustration. Take the time and do some reading, you will save that time later on. To your problem. The quistions are: Where did you store the certificate for your LDAP server? Where did you store the private key? If you followed the tutorial then you should have the server's certificate and private key under /usr/lib/ssl/ServerCA/ and it's name should be something like host.yourdomain.com.cert.pem Make a find /usr/lib/ssl/ -name "*.pem" This should show you every certificate you generated. Best regards, Hauke ----- Ursprüngliche Mail ----- Von: "Dat Duong" <datduong2000(a)yahoo.com> An: "Hauke Coltzau" <hauke.coltzau(a)FernUni-Hagen.de> CC: "openldap-technical" <openldap-technical(a)openldap.org> Gesendet: Donnerstag, 9. Oktober 2008 10:02:13 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien Betreff: Re: AW: Re: AW: Re: AW: StartTLS is not working Hi Hauke, I've followed the mini tutorial and got stuck at the path for the server certificates in your tutorial. The path is not correct for slapd. Can you verify? TLSCertificateFile /usr/lib/ssl/certs/<fqdn>.cert.pem TLSCertificateKeyFile /usr/lib/ssl/private/<fqdn>.key.pem thanks ----- Original Message ---- From: Hauke Coltzau <hauke.coltzau(a)FernUni-Hagen.de> To: Dat Duong <datduong2000(a)yahoo.com> Cc: openldap-technical <openldap-technical(a)openldap.org> Sent: Thursday, October 9, 2008 12:46:00 AM Subject: AW: Re: AW: Re: AW: StartTLS is not working Hi Dat, > I've added the below to /etc/openldap/ldap.conf on RHEL 5: > TLS_CACERT /etc/openldap/cacerts/ServerCA.chain.pem > TLS_REQCERT demand > > and still getting errors messages... below: > > TLS certificate verification: Error, self signed certificate The LDAP server does not send a server certificate but a self signed certificate. Are you sending the RootCA's certificate? Create a server certificate as described in the tutorial and let your LDAP server use this. I assume that you will have to read a bit more about certificates and openssl to understand all the steps of the mini tutorial. Rergards, Hauke ----- Original Message ---- From: Hauke Coltzau < hauke.coltzau(a)FernUni-Hagen.de > To: openldap-software < openldap-software(a)openldap.org > Cc: Dat Duong < datduong2000(a)yahoo.com > Sent: Wednesday, October 8, 2008 2:09:11 AM Subject: AW: Re: AW: StartTLS is not working Hi Dat, glad to see that the first problem has been solved now. As Dieter already pointed out, we need to know how the certificates have been created. As a rough overview, you will need to run through following steps: 0. Understand the basic idea: At the end of this MiniHowto, you will have three certification authorities: UserCA: For user certificates (usually password protected) ServerCA: For server certificates (usually NOT password protected) RootCA: The CA that everyone has to trust in the end. This CA only exists to create and verify the UserCA and ServerCA. For your LDAP server, you create a server certificate with your ServerCA. The LDAP clients will accept the LDAP certificate as long as they trust the ServerCA. They will trust the ServerCA because they trust the RootCA. To make them do so, you will need the certificates of the ServerCA AND the RootCA on each client. Just to make sure: We are not talking about copying the LDAP certificate to the client. Instead, you will copy the CA certificates to the client. 1. Create directory structure and files containing random numbers (need to be root for this): # Make sure uuencode is installed. On Debian based # systems, type # # apt-get install sharutils # cd /usr/lib/ssl/ for i in RootCA ServerCA UserCA; do mkdir -p $i/newcerts; mkdir $i/certs; mkdir $i/crl; mkdir $i/private; touch $i/index.txt; echo 01 > $i/serial; chmod -R g-rwx,o-rwx $i; done for i in `find /usr/lib/ssl/ -name private` do cat /dev/urandom | uuencode -m bla | head -19 | sed "s/begin.*//g" | tail -18 | xargs | sed "s/ //g" > $i/.rand chmod 770 $i/.rand ls -l $i/.rand done At the end of this step, you will have three subdirectories in /usr/lib/ssl: RootCA: Contains the root CA's self-signed certificate and private key as well as the certificates created by the root CA. ServerCA: Contains the CA which is used to create server certificates. Again, the directory contains of the server CA's certificate and key as well as the certificates created by the server CA. UserCA: Contains the CA which is used to create user certificates. 2. openssl.cnf Adapt your openssl.cnf (should be in /usr/lib/ssl, too) to have proper entries for each of the CAs: HOME = /usr/lib/ssl [ RootCA ] dir = /usr/lib/ssl/RootCA certs = $dir/certs crl_dir = $dir/crl database = $dir/index.txt new_certs_dir = $dir/newcerts certificate = $dir/RootCA.cert.pem serial = $dir/serial crl = $dir/crl.pem private_key = $dir/private/RootCA.key.pem RANDFILE = $dir/private/.rand policy = policy_match x509_extensions = ca_cert [ ServerCA ] dir = /usr/lib/ssl/ServerCA certs = $dir/certs crl_dir = $dir/crl database = $dir/index.txt new_certs_dir = $dir/newcerts certificate = $dir/ServerCA.cert.pem serial = $dir/serial crl = $dir/crl.pem private_key = $dir/private/ServerCA.key.pem RANDFILE = $dir/private/.rand x509_extensions = usr_cert (Same with [ UserCA ]) There are more options to be set, but they depend on your environment. Have a look at the default_days, default_md, ... parameters. 1. Create a self signed certificate (RootCA): cd /usr/lib/ssl/RootCA # Create the private key first # You will be asked for a new pasword here. Make it a good one and remember it ;-) openssl genrsa -aes256 -out /usr/lib/ssl/RootCA/private/RootCA.key.pem -rand /usr/lib/ssl/RootCA/private/.rand 2048 chmod g-rwx,o-rwx /usr/lib/ssl/RootCA/private/RootCA.key.pem # Now create a certification request. Because the cert is self-signed, this # directly creates the RootCA's certificate. You will be asked for the # password you just created. # # All in one line: openssl req -new -x509 -days 1827 -key /usr/lib/ssl/RootCA/private/RootCA.key.pem -out /usr/lib/ssl/RootCA/RootCA.cert.pem # Copy the certificate to the certs directory and create a link named like # the cert's hash value cp RootCA.cert.pem certs/00.pem cd certs ln -s /usr/lib/ssl/RootCA/certs/00.pem `openssl x509 -hash -noout -in 00.pem`.0 Now you should have the cert (00.pem) and something like 1a2783e8.0 pointing to /usr/lib/ssl/RootCA/00.pem 2. Create the ServerCA cd /usr/lib/ssl/ServerCA # Create the private key for the ServerCA # You will be asked for a new password here. Do not make it the same as the RootCA's # password, but still - make it a good one. # openssl genrsa -aes256 -out /usr/lib/ssl/ServerCA/private/ServerCA.key.pem -rand /usr/lib/ssl/ServerCA/private/.rand 2048 chmod g-rwx,o-rwx /usr/lib/ssl/ServerCA/private/ServerCA.key.pem # Create the certification request. You will be asked for the # newly created password. # (All in one line) openssl req -new -days 1827 -key /usr/lib/ssl/ServerCA/private/ServerCA.key.pem -out /usr/lib/ssl/ServerCA/ServerCA.req.pem # Let the RootCA sign the request and create the certificate. # You will need the RootCA's password for this. # openssl ca -name RootCA -in /usr/lib/ssl/ServerCA/ServerCA.req.pem -out /usr/lib/ssl/ServerCA/ServerCA.cert.pem # Copy and link the certificate. # mv /usr/lib/ssl/RootCA/newcerts/01.pem /usr/lib/ssl/RootCA/certs/ cd /usr/lib/ssl/RootCA/certs/ ln -s 01.pem `openssl x509 -in 01.pem -hash -noout`.0 # And copy the part neccessary for browser integration into # another file (this is the part between BEGIN CERTIFICATE and END CERTIFICATE) # cd /usr/lib/ssl/ServerCA sed -n '/-----BEGIN CERTIFICATE-----/,$p' ServerCA.cert.pem > ServerCA.crt # Create the CACerts file used on the client side to verify a server cert mkdir /usr/lib/ssl/cacerts/ cat /usr/lib/ssl/RootCA/RootCA.cert.pem /usr/lib/ssl/ServerCA/ServerCA.cert.pem > /usr/lib/ssl/cacerts/ServerCA.chain.pem # The newly created file (ServerCA.chain.pem) is the CACertsFile which has to be copied # to every client. Create a /usr/lib/ssl/cacerts/ directory on the client side and copy # the file to that location. 3. Do the same with the User CA 4. Create your LDAP server certificate. As for the name in your cert, use the fqdn of the machine you are running the server on. cd /usr/lib/ssl/ServerCA # You will NOT need a password here # openssl genrsa -out <fqdn-of-your-server>.key.pem -rand ./private/.rand 2048 openssl req -new -key <fqdn-of-your-server>.key.pem -out <fqdn-of-your-server>.req.pem # But here, you will be asked for the ServerCA's password openssl ca -name ServerCA -in <fqdn-of-your-server>.req.pem -out <fqdn-of-your-server>.cert.pem Move and link the new certificate (in newcerts) as above. 5. Configure LDAP server and clients Make sure that your ldap server can read its own private key. If your ldap server is running as user openldap, make sure that this user owns the private key in /usr/lib/ssl/ServerCA/private/ Normal users should never be allowed to read the key! This would break the whole security mechanism. In your slapd.conf, you will have TLSCertificateFile /usr/lib/ssl/certs/<fqdn>.cert.pem TLSCertificateKeyFile /usr/lib/ssl/private/<fqdn>.key.pem And on client side ldap.conf: TLS_CACERT /usr/lib/ssl/cacerts/ServerCA.chain.pem TLS_REQCERT demand Hope this helps, Hauke p.s.: The description is strongly influenced by Frank Steidl's tutorial as it can be found at http://fra.nksteidl.de/Erinnerungen/OpenSSL.php ----- Ursprüngliche Mail ----- Von: "Dieter Kluenter" < dieter(a)dkluenter.de > An: openldap-technical(a)openldap.org Gesendet: Dienstag, 7. Oktober 2008 22:34:14 GMT +01:00 Amsterdam/Berlin/Bern/Rom/Stockholm/Wien Betreff: Re: AW: StartTLS is not working Dat Duong < datduong2000(a)yahoo.com > writes: > Hi Hauke, > > I still can't get TLS to work. Here is the error message. > > TLS certificate verification: Error, self signed certificate > tls_write: want=7, written=7 > 0000: 15 03 01 00 02 02 30 ......0 > TLS trace: SSL3 alert write:fatal:unknown CA > TLS trace: SSL_connect:error in SSLv3 read server certificate B > TLS trace: SSL_connect:error in SSLv3 read server certificate B > TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed Please describe the parameters to create your certificate chain. I presume you have not signed your certificates with a known certificate authority. -Dieter -- Dieter Klünter | Systemberatung http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E --

16 years, 1 month

[Q] can I replicate several branches to the same slave from one master?

by Zeus Panchenko

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi, please advise I need to replicate not all but some branches from one master to one slave not sure how much correct I have done that, but here what I have: slave starts successfully, records appear on slave as expected, services successfully use data as expected ... but the replication fails (fragments of log files are bellow) on master I see: consumer state is newer than provider on slave: LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform so ... what is wrong here? branches to replicate: ou=People,dc=example ou=clusterX,ou=Sendmail,dc=example to be used by 3 services on the slave 1. email (smtp auth and imap4/pop3 auth) object dn sample: uid=ja@foo.bar,authorizedService=mail@foo.bar,uid=johnd,ou=People,dc=example 2. jabber object dn sample: uid=aj@foo.bar,authorizedService=xmpp@foo.bar,uid=johnd,ou=People,dc=example 3. sendmail configuration (here is the detailed diagram https://github.com/z-eos/umi/wiki/DB-topology) ====================================================================== here is the configuration layout: - ---[ master configuration quotation start ]--------------------------- ... access to dn.children="dc=example" by dn.exact="uid=replABC,ou=repl,dc=example" read by * break # syncprov specific indexing index entryCSN eq index entryUUID eq overlay syncprov syncprov-checkpoint 50 10 syncprov-sessionlog 100 overlay accesslog logdb cn=example-accesslog logops writes logold (objectclass=*) index default eq ### Accesslog DB database mdb maxsize 1073741824 suffix cn=example-accesslog rootdn "cn=root,cn=example-accesslog" rootpw *** directory "/var/db/openldap-data/example-accesslog" index default eq index entryCSN,objectClass,reqEnd,reqResult,reqStart overlay syncprov syncprov-nopresent TRUE syncprov-reloadhint TRUE ... - ---[ master configuration quotation end ]--------------------------- - ---[ slave configuration quotation start ]---------------------------- syncrepl rid=123 provider=ldap://master.example:389 starttls=critical searchbase="dc=example" bindmethod=simple binddn="uid=replABC,ou=repl,dc=example" credentials="***" filter="(|(&(objectClass=authorizedServiceObject)(objectClass=mailutilsAccount)(authorizedService=mail(a)foo.bar)))" attrs="cn,entry,entryCSN,entryUUID,o,uid,uidNumber,gidNumber,gecos,homeDirectory,loginShell,userPassword,creatorsName,createTimestamp,modifiersName,modifyTimestamp,mail,rfc822MailMember,sn,authorizedService,mu-mailBox" tls_cacert=/usr/local/etc/openldap/ssl/ca.crt tls_cert=/usr/local/etc/openldap/ssl/ABC.crt tls_key=/usr/local/etc/openldap/ssl/ABC.key tls_reqcert=try type=refreshAndPersist retry="60 +" logbase="cn=example-accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog syncrepl rid=123 provider=ldap://master.example:389 starttls=critical searchbase="dc=example" bindmethod=simple binddn="uid=replABC,ou=repl,dc=example" credentials="***" filter="(&(objectClass=authorizedServiceObject)(authorizedService=xmpp(a)foo.bar))" tls_cacert=/usr/local/etc/openldap/ssl/ca.crt tls_cert=/usr/local/etc/openldap/ssl/ABC.crt tls_key=/usr/local/etc/openldap/ssl/ABC.key tls_reqcert=try type=refreshAndPersist retry="60 +" logbase="cn=example-accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog syncrepl rid=123 provider=ldap://master.example:389 starttls=critical searchbase="ou=ABC,ou=Sendmail,dc=example" bindmethod=simple binddn="uid=replABC,ou=repl,dc=example" credentials="***" tls_cacert=/usr/local/etc/openldap/ssl/ca.crt tls_cert=/usr/local/etc/openldap/ssl/ABC.crt tls_key=/usr/local/etc/openldap/ssl/ABC.key tls_reqcert=try type=refreshAndPersist retry="60 +" logbase="cn=example-accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog - ---[ slave configuration quotation end ]---------------------------- ====================================================================== here are logs - ---[ master slapd.log quotation start ]------------------------------- Jun 26 22:54:25 master slapd[75509]: conn=55585 fd=19 ACCEPT from IP=192.168.0.1:54127 (IP=192.168.0.254:389) Jun 26 22:54:25 master slapd[75509]: conn=55585 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jun 26 22:54:25 master slapd[75509]: conn=55585 op=0 STARTTLS Jun 26 22:54:25 master slapd[75509]: conn=55586 fd=20 ACCEPT from IP=192.168.0.1:57184 (IP=192.168.0.254:389) Jun 26 22:54:25 master slapd[75509]: conn=55585 op=0 RESULT oid= err=0 text= Jun 26 22:54:25 master slapd[75509]: conn=55586 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jun 26 22:54:25 master slapd[75509]: conn=55586 op=0 STARTTLS Jun 26 22:54:25 master slapd[75509]: conn=55586 op=0 RESULT oid= err=0 text= Jun 26 22:54:25 master slapd[75509]: conn=55586 fd=20 TLS established tls_ssf=256 ssf=256 Jun 26 22:54:25 master slapd[75509]: conn=55585 fd=19 TLS established tls_ssf=256 ssf=256 Jun 26 22:54:25 master slapd[75509]: conn=55586 op=1 BIND dn="uid=replABC,ou=repl,dc=example" method=128 Jun 26 22:54:25 master slapd[75509]: conn=55586 op=1 BIND dn="uid=replABC,ou=repl,dc=example" mech=SIMPLE ssf=0 Jun 26 22:54:25 master slapd[75509]: conn=55586 op=1 RESULT tag=97 err=0 text= Jun 26 22:54:25 master slapd[75509]: conn=55585 op=1 BIND dn="uid=replABC,ou=repl,dc=example" method=128 Jun 26 22:54:25 master slapd[75509]: conn=55585 op=1 BIND dn="uid=replABC,ou=repl,dc=example" mech=SIMPLE ssf=0 Jun 26 22:54:25 master slapd[75509]: conn=55585 op=1 RESULT tag=97 err=0 text= Jun 26 22:54:25 master slapd[75509]: conn=55586 op=2 SRCH base="cn=example-accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Jun 26 22:54:25 master slapd[75509]: conn=55586 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jun 26 22:54:25 master slapd[75509]: conn=55585 op=2 SRCH base="cn=example-accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Jun 26 22:54:25 master slapd[75509]: conn=55585 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jun 26 22:54:25 master slapd[75509]: conn=55586 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Jun 26 22:54:25 master slapd[75509]: conn=55585 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Jun 26 22:54:25 master slapd[75509]: conn=55586 op=3 UNBIND Jun 26 22:54:25 master slapd[75509]: conn=55586 fd=20 closed Jun 26 22:54:25 master slapd[75509]: conn=55585 op=3 UNBIND Jun 26 22:54:25 master slapd[75509]: conn=55585 fd=19 closed Jun 26 22:54:31 master slapd[75509]: conn=55587 fd=19 ACCEPT from IP=192.168.0.1:58488 (IP=192.168.0.254:389) Jun 26 22:54:31 master slapd[75509]: conn=55587 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Jun 26 22:54:31 master slapd[75509]: conn=55587 op=0 STARTTLS Jun 26 22:54:31 master slapd[75509]: conn=55587 op=0 RESULT oid= err=0 text= Jun 26 22:54:31 master slapd[75509]: conn=55587 fd=19 TLS established tls_ssf=256 ssf=256 Jun 26 22:54:31 master slapd[75509]: conn=55587 op=1 BIND dn="uid=replABC,ou=repl,dc=example" method=128 Jun 26 22:54:31 master slapd[75509]: conn=55587 op=1 BIND dn="uid=replABC,ou=repl,dc=example" mech=SIMPLE ssf=0 Jun 26 22:54:31 master slapd[75509]: conn=55587 op=1 RESULT tag=97 err=0 text= Jun 26 22:54:31 master slapd[75509]: conn=55587 op=2 SRCH base="cn=example-accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Jun 26 22:54:31 master slapd[75509]: conn=55587 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jun 26 22:54:31 master slapd[75509]: conn=55587 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! Jun 26 22:54:31 master slapd[75509]: conn=55587 op=3 UNBIND Jun 26 22:54:31 master slapd[75509]: conn=55587 fd=19 closed - ---[ master slapd.log quotation end ]------------------------------- - ---[ slave slapd.log quotation start ]-------------------------------- Jun 26 21:41:44 ABC slapd[67186]: @(#) $OpenLDAP: slapd 2.4.44 (Feb 7 2017 01:19:39) $ root@foo.bar:/usr/ports/net/openldap24-server/work/openldap-2.4.44/servers/slapd Jun 26 21:41:44 ABC slapd[67187]: slapd starting Jun 26 21:41:44 ABC slapd[67187]: conn=1000 fd=14 ACCEPT from IP=127.0.0.1:32266 (IP=127.0.0.1:389) Jun 26 21:41:44 ABC slapd[67187]: conn=1001 op=0 BIND dn="" method=128 Jun 26 21:41:44 ABC slapd[67187]: conn=1002 fd=17 ACCEPT from IP=127.0.0.1:35827 (IP=127.0.0.1:389) Jun 26 21:41:44 ABC slapd[67187]: conn=1000 op=0 BIND dn="" method=128 Jun 26 21:41:44 ABC slapd[67187]: conn=1001 op=0 RESULT tag=97 err=0 text= Jun 26 21:41:44 ABC slapd[67187]: conn=1001 fd=16 ACCEPT from IP=127.0.0.1:37048 (IP=127.0.0.1:389) Jun 26 21:41:44 ABC slapd[67187]: conn=1002 op=0 BIND dn="" method=128 Jun 26 21:41:44 ABC slapd[67187]: conn=1000 op=0 RESULT tag=97 err=0 text= Jun 26 21:41:44 ABC slapd[67187]: conn=1002 op=0 RESULT tag=97 err=0 text= Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrepl: rid=123 rc -2 retrying Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrepl: rid=123 rc -2 retrying Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrep2: rid=123 (53) Server is unwilling to perform Jun 26 21:41:45 ABC slapd[67187]: do_syncrepl: rid=123 rc -2 retrying Jun 26 21:42:43 ABC slapd[67187]: conn=1003 fd=9 ACCEPT from IP=127.0.0.1:37489 (IP=127.0.0.1:389) Jun 26 21:42:43 ABC slapd[67187]: conn=1003 op=0 BIND dn="" method=128 - ---[ slave slapd.log quotation end ]-------------------------------- - -- Zeus V. Panchenko jid:zeus@im.ibs.dn.ua IT Dpt., I.B.S. LLC GMT+2 (EET) -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQYIXL6FUmD7SUfqoOveOk+D/ejKgUCWVGE9gAKCRCveOk+D/ej Kp1JAJ9tFikqgeCHlzUXfQrcTQuHlAqNKwCdEMnIM6uOFRCNBN6oHmh4AyQ6j1U= =Xn/Y -----END PGP SIGNATURE-----

7 years, 4 months

Re: slapd(8C) man page, -c option: covers delete phase?

by Francesco Malvezzi

On 02/03/22 20:29, Michael Ströder wrote: > On 3/2/22 11:49, Francesco Malvezzi wrote: >> on a consumer I spotted a zombie entry which was deleted on provider. > > Which OpenLDAP version are you using? consumer: openldap-2.5.6 provider: openldap-2.4.56 > >> Replication is syncrepl: >> >> olcSyncrepl: {0}rid=003 provider=ldap://ldap-master.example.org >> binddn="cn=repluser,ou=agents,dc=example,dc=org" bindmethod=simple >> credentials="secret" searchbase="ou=people,dc=example,dc=org" >> type=refreshOnly interval=00:00:01:00 retry="5 5 30 +" timeout=1 >> scope=sub schemachecking=on exattrs=sambaHomeDrive sizelimit=100000 >> timelimit=7200 starttls=yes filter="....." > > I cannot really tell what's going on in your deployment. got it: the procedure is fine but the environment is broken. I stopped slapd, deleted the mdb files, restarted slapd and in an acceptable time the users have been all re-synced with all zombies dropped. It is not elegant at all, so I need to investigate the deployment. > > But I wonder why you added sizelimit= to the syncrepl directive. Do you > really have less than 100000 entries? yes, the example.edu userbase is really this small (67k users more or less). Anyhow I removed the sizelimit, even if I think it would hurt me in the other way (banning users from showing up, not from being removed), > > Ciao, Michael. thank you so much for your time, Francesco

2 years, 8 months

Re: groups added to provider not replicating to consumer

by btb

a bit of additional data which may be relevant: the consumer synrepl config: {0}rid=0 provider=ldap://dsa.example.net starttls=critical bindmethod=simple binddn="cn=repl- content,ou=exo,ou=services,ou=accounts,dc=example,dc=net" credentials="xxxxx" searchbase="dc=example,dc=net" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on type=refreshAndPersist retry="15 +" syncdata=accesslog using ldapsearch on the consumer, against the provider, the replication dn is able to see the entry in question: >ldapsearch -xLLLZZH 'ldap://dsa.example.net' -D 'cn=repl-content,ou=exo,ou=services,ou=accounts,dc=example,dc=net' -w 'xxxxx' -b 'cn=test_group,ou=general,ou=groups,dc=example,dc=net' -s base '*' '+' dn: cn=test_group,ou=general,ou=groups,dc=example,dc=net objectClass: top objectClass: groupOfNames description: test group cn: test_group member: uid=dummy_default,ou=dummy_accounts,ou=other,ou=accounts,dc=example, dc=net structuralObjectClass: groupOfNames entryUUID: d68c73e4-10c1-1031-8246-9dfa8daa46e0 creatorsName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=net createTimestamp: 20120402034404Z entryCSN: 20120402034404.808333Z#000000#000#000000 modifiersName: uid=dit_admin,ou=role_accounts,ou=accounts,dc=example,dc=net modifyTimestamp: 20120402034404Z entryDN: cn=test_group,ou=general,ou=groups,dc=example,dc=net subschemaSubentry: cn=Subschema hasSubordinates: FALSE

12 years, 7 months

Replication Design Advice

by Andrei Bănaru

Hello OpenLDAP users, I’m looking for some advice concerning an OpenLDAP solution I’m about to deploy between 4 locations in company I work for. Currently I’ve implemented a LDAP DIT in my country and we’ve had exquisite results. I’ve integrated RADIUS for wireless authentication, MIT Kerberos, Samba PDC, dovecot and the list can continue but that’s not the scope of this message. We have some global services located in one of the countries that all other 3 countries use ( trac, svn, web2project, alfresco ). We want that each country to have it’s own LDAP DIT ( we don’t want to have a global LDAP with slaves in each country because some of us want locally significant objects ( for authorization purposes ) and having a slave LDAP means read-only ). That’s why I thought of using multi-n-master on each of the four LDAP servers. The ideea I had was that each country will have only a portion of the DIT being sent to the others ( we narrow the searchbase in syncrepl ): Country 1 sends ou=COUNTRY-1,dc=example,dc=com Country 2 sends ou=COUNTRY-2,dc=example,dc=com Country 3 sends ou=COUNTRY-3,dc=example,dc=com Country 4 sends ou=COUNTRY-4,dc=example,dc=com In each ou=COUNTRY-{1..4} they will have ou=People and ou=Groups. Basically that’s the only thing I want to be consistent across all LDAP DITs. I’ve tested the solution using some virtual machines and besides the starttls and some things each administrator will have to be cautious about things went smoothly. I've also read something about slapo-translucent - will now test to see how it works. Can I get some suggestions / maybe a whole new architecture for my needs in case I didn’t foresee problems ? Thx! -- Andrei BĂNARU Internal Support CCNA Security, CCIP StreamWIDE Romania

12 years, 5 months

Re: whose responsability

by Dan White

>On Sun, Jul 10, 2011 at 5:41 PM, Dan White <dwhite(a)olp.net> wrote: >>> ldapsearch -x -w PASSWORD -D uid=user,ou=people,dc=my,dc=domain -b >>> uid=user,ou=people,dc=my,dc=domain >>> >>> And everyting works ok. >>> My doubt is: >>> >>> who is performing the password checking? The openldap server >>> daemon (slapd) ou the ldapsearch ? >> >> When userPassword is configured with '{SASL}user@domain', you are using >> SASL pass-through authentication. See section 14.5 (Pass-Through >> authentication) of the OpenLDAP Administrator's Guide for documentation. >> >> In such a scenario, authentication is ultimately handled by the libsasl2 >> glue layer, and is controlled by the configuration of your sasl slapd.conf >> file, which is typically found in /usr/lib/sasl2/slapd.conf. >> >> Presumably you've configured pass-through authentication because of a need >> to authenticate against a saslauthd daemon (pwcheck_method: saslauthd). On 10/07/11 17:56 -0300, Friedrich Locke wrote: >Thanks for your response! > >But who is doing the comunication with saslauthd, the slap daemon >process or the ldapsearch process ? > >Thanks once more! slapd will be communicating with saslauthd (or your configured pwcheck_method) via libsasl2. With your ldapsearch command, the dn and password will be transmitted in clear text over the wire to your openldap/slapd server, for authentication, unless you've configured ldaps or starttls encryption for protection. -- Dan White

13 years, 4 months

RE: openldap and MozNSS

by Quanah Gibson-Mount

--On Tuesday, June 25, 2013 2:01 PM -0400 Rodney Simioni <rodney.simioni(a)verio.net> wrote: > > Comment below. > -----Original Message----- > From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Sent: Tuesday, June 25, 2013 12:27 PM > To: Rodney Simioni; openldap-technical(a)openldap.org > Subject: RE: openldap and MozNSS > > --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. [[Rod's comment]] I'm using '-H', I'm still getting > 'unsupported extended operation', but thanks. My point was, show an EXACT ldapsearch command where it is not pulling in crap from a local or system ".ldaprc" or "ldap.conf" file. Until you do that, god knows what those files are setting. --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, 4 months

TLS negation failure

by espeake＠oreillyauto.com

We have a client server that is failing on the ssl handshake using TLS. The following is from the server log when the client is trying to connect. Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 ACCEPT from IP=172.17.1.10:55469 (IP=0.0.0.0:389) Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 STARTTLS Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 RESULT oid= err=0 text= Sep 19 09:12:50 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 closed (TLS negotiation failure) On the client when I run the following: openssl s_client -showcerts -connect tntest-ldap.oreillyauto.com:389 I get this on the client CONNECTED(00000003) 139669033973408:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 226 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE If I do the same command on port 636 I can see the certificate. All of our applications that use ldap are all set for TLS. Even if I force them to port 636 they fail. Any ideas to look at are appreciated. Eric Speake Web Systems Administrator O'Reilly Auto Parts This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.

11 years, 1 month

Re: Client doesn't send certificate for LDAPS

by btb＠bitrate.net

On Mar 8, 2014, at 08.50, Joshua Schaeffer <jschaeffer0922(a)gmail.com> wrote: > I'm in the process of setting up my slapd server to operate over LDAPS and having trouble when using a CA certificate (being my own certificate authority). I've been able to setup LDAPS when using a self-signed server certificate: please use ldap+starttls, not ldaps. > This works fine and I'm able to authenticate clients. However if I use a CA certificate (again, being my own CA) to sign my server certificate and then change olcTLSVerifyClient to demand and add olcTLSCACertificateFile then I can no longer authenticate. I've installed my CA certificate on the client machine and pointed both ldap.conf and nslcd.conf to the CA certificate. However I get the following when debugging: why are you setting olcTLSVerifyClient when changing from a self signed cert to a properly signed cert? did you read the description of this setting in man 5 slapd-config? it has nothing to do with use of a self-signed vs a regular cert. be methodical when doing an exercise like this. first switch from your self signed cert to your proper cert. test. then, modify olcTLSVerifyClient and see what happens. > Why would the client not send the certificate if I've pointed TLS_CACERT in ldap.conf and tls_cacertfile to that cert? TLS_CACERT and tls_cacertfile point to the ca cert. why would this cert be sent anywhere by the client? the server already has this cert. those settings allow the client to establish a chain of trust to the certificate presented by the server. it’s a “bootstrapping” mechanism, so to speak. you tell the client [by way of those settings] to implicitly trust, no questions asked, certain ca certificates. then when the client is presented a certificate by a server, it can be deemed “trustworthy”, even though it had no prior knowledge of this particular cert. -ben

10 years, 8 months

Re: Ppolicy issues

by Tony Earnshaw

Bryan Payne skrev, on 20-02-2008 16:10: > Thank you for your help. I added the pwdPolicySubentry to a user to no > avail. I did find this in the logfile though: > > Feb 20 09:01:13 ldapserver slapd[6709]: conn=95289 op=4 SEARCH RESULT > tag=101 err=50 nentries=0 text=Operations are restricted to > bind/unbind/abandon/StartTLS/modify password > > So it looks like it's trying to do something but cannot. While I'm > concerned about password strength, I'm more concerned (at this point) > with just having the machine prompt for a password change. I'm running > centos 4.6 and openldap 2.3.39. I compiled it with the following: > > ./configure --enable-crypt --enable-ppolicy --with-tls > --prefix=/opt/openldap/ > > Once again, thanks for any help. I'd strongly advise you to chuck out your self-built 2.3.39 and install the rpms at http://staff.telkomsa.net/packages/rhel4/openldap/$basearch. You need both libldap and openldap. Shouldn't be difficult if you install to /opt (you an old Solaris person? Or other SYSV?) These will install to LFH locations; however, being rpms you can always chuck them off again if they don't please (which they will ;) ). Then take it again from the beginning. These are Buchan Milne's rpms and have their own discrete, patched db4 4.2.52 which will not conflict with the db4 4.2.52 which you have from CentOS. Moreover everything including sonames is named differently from Red Hat's, so it all takes a bit of getting used to. But when you have, you'll never look back. Best, --Tonni -- Tony Earnshaw Email: tonni at hetnet dot nl

16 years, 8 months

openldap-technical search results for query "starttls"