Search results for "starttls" - openldap-technical

Re: Can't get TLS working.

by c0re

I tryed to test with ldapsearch, but it ignores ldap.conf somehow (where CA certificate defined) and I always recieve additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate in certificate chain) Tryed with ldapsearch -Z -d 1 -h ldap.domain.com 2010/9/16 Dieter Kluenter <dieter(a)dkluenter.de>: > c0re <nr1c0re(a)gmail.com> writes: > >> # making clientkey >> openssl genrsa -out client.key 2048 >> # making certificate request >> openssl req -new -key client.key -out client.csr >> # signing >> openssl x509 -req -days 1024 -CA ../ssl/rootcrt.pem -CAkey >> ../ssl/rootkey.pem -in client.csr -out client.crt -CAserial >> ../ssl/root.seq >> >> # configuring on client >> TLS_CACERT /usr/local/etc/openldap/ssl-client/rootcrt.pem >> TLS_CERT /usr/local/etc/openldap/ssl-client/client.crt >> and >> TLS_KEY /usr/local/etc/openldap/ssl-client/client.key >> >> Trying again with slapd debug and client calling "id test" > > [...] > As there are no obvious errors in the log you should get TLS properly > working, prior to testing with pam. Just do a ldapsearch or a > ldapwhoami either on uri ldaps:// or startTLS on ldap:// > > -Dieter > > -- > Dieter Klünter | Systemberatung > sip: 7770535(a)sipgate.de > http://www.dpunkt.de/buecher/2104.html > GPG Key ID:8EF7B6C6 >

14 years, 9 months

Re: Forcing TLS encryption

by Wiebe Cazemier

----- Original Message ----- > From: "Philip Guenther" <guenther+ldaptech(a)sendmail.com> > To: "Wiebe Cazemier" <wiebe(a)halfgaar.net> > Cc: "Dieter Klünter" <dieter(a)dkluenter.de>, openldap-technical(a)openldap.org > Sent: Friday, 28 December, 2012 9:36:50 PM > Subject: Re: Forcing TLS encryption > > On Fri, 28 Dec 2012, Wiebe Cazemier wrote: > > I understand that, but this way, even when you're forcing TLS, > > users can > > still expose their passwords if their computers are mal-configured. > > SMTP, IMAP, FTP, etc don't allow this, because they reject the > > connection if LOGINNAME is given before STARTTLS. > > That is not true of SMTP's AUTH PLAIN, IMAP's AUTHENTICATE PLAIN, or > IMAP's LOGIN. The PLAIN SASL mechanism and IMAP's LOGIN command both > send > the username and password without waiting for a response from the > server**. > > > > It's kind of a security issue. Is it because in LDAP, username and > > password are given as one command, and the server doesn't have the > > chance to abort at that point? If so, then I guess it's > > unavoidable. > > Correct. > > > Philip Guenther > > ** Well, to be completely accurate, IMAP AUTHENTICATE requires a > server > response if the server doesn't support the SASL-IR capability > > Then why is the LDAPS port deprecated? If the connection is SSL from the start, you don't have this issue.

12 years, 6 months

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

by Quanah Gibson-Mount

--On Tuesday, June 27, 2017 2:04 AM -2100 Zeus Panchenko <zeus(a)ibs.dn.ua> wrote: > 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 ]---------------------------- Wouldn't it be simpler to define ACLs on the master that limit what the replication identity has access to that matches your filters? I would also note that your stanza limiting what attrs are replicated is missing the operational attributes that are necessary for sync replication to function, so I would fully expect errors. As Andrew already noted (and you later fixed), syncrepl RIDs are required to be unique, as documented in the man page. Given that OpenLDAP functions off of CSN values, partial replication is tricky, as the master can then have a contextCSN that does not correspond to anything in a partially replicated database, depending on how you slice it. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

8 years

using ldap database (multiple upstream servers), how to force reconnect after failover?

by David Young

Hi technical, We have an openldap server (v2.4.39) which acts as a reverse proxy for 2 backend servers (replicated). The intention is that we use this "proxy" server for authentication requests for applications which can't handle SSL, or multiple backend servers, properly. The implementation works as designed - a query is received from a client, passed on to the first server defined in olcDbURL (server1). If the first server is unavailable, after a brief timeout (1 sec), the query is passed to the second server in the oldDbURL (server2). Here's the problem - server1 is never polled again. Queries continue to be passed to server2, but when server2 is unavailable, all queries fail, even if server1 is now available again. Is there a config directive I can use to force ldap to reattempt connection to server1 after the initial failure? My config is below. Thanks :) David --- dn: olcDatabase={1}ldap objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {1}ldap olcSuffix: dc=mydomain,dc=net,dc=nz olcAddContentAcl: FALSE olcLastMod: FALSE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcDbURI: "ldaps://server1 ldaps://server2" olcDbStartTLS: none starttls=no olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbNetworkTimeout: 1 olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE structuralObjectClass: olcLDAPConfig entryUUID: 01eb5074-6f65-1033-8a02-cd0b00053594 creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20140514033850Z olcDbIdleTimeout: 1m olcDbConnTtl: 5m entryCSN: 20140514033850.182221Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20140514033850Z

10 years, 7 months

RE: ldapmodify add olcSyncrepl (okey but not okey)

by Jason Trupp

To add a second replica you should be able to replicate your existing replica's config on a new server without making any changes. Jason Trupp Symas Corporation (855) LDAP-GUY -----Original Message----- From: openldap-technical [mailto:openldap-technical-bounces@openldap.org] On Behalf Of lejeczek Sent: Monday, November 19, 2018 8:48 AM To: openldap-technical(a)openldap.org Subject: ldapmodify add olcSyncrepl (okey but not okey) hi everyone I'm must be doing something trivially wrong and am hoping someone could help. I'm trying to add second replica: $ ldapmodify -vv -h rider.my.dom:1389 -D "cn=admin,cn=config" -w my.Biotec13 -x ldap_initialize( ldap://rider.my.dom:1389 ) dn: olcDatabase={1}bdb,cn=config changetype: modify add: olcSyncrepl: rid=002 provider=ldap://swir.my.dom:1389 bindmethod=simple timeout=0 network-timeout=0 binddn="uid=replicator,ou=people,dc=my,dc=dom" credentials="lejek9090" keepalive=0:0:0 starttls=no filter="(objectclass=*)" searchbase="dc=my,dc=dom" scope=sub attrs="*,+" schemachecking=off type=refreshOnly interval=00:00:10:00 retry="5 5 300 +" exit code of the above to shell is 0 yet next ldapsearch finds no such new entry exists. At the time of ldapmodify in logs I see: Nov 19 14:40:48 rider slapd[90048]: slap_queue_csn: queueing 0x7f22cc111e00 20181119144048.167126Z#000000#005#000000 Nov 19 14:40:48 rider slapd[90048]: slap_graduate_commit_csn: removing 0x7f22cc111e00 20181119144048.167126Z#000000#005#000000 How to get it work? Many thanks, L.

6 years, 7 months

Re: ldaprc with ldaps:// and ldap:// fallback

by Michael Ströder

Dan White wrote: > On 24/06/10 22:13 +0200, Emmanuel Dreyfus wrote: >> Dan White <dwhite(a)olp.net> wrote: >> >>> You could do SASL EXTERNAL over both, with ldapi:/// using Unix >>> peercred, >>> i.e.: >>> >>> authz-regexp >>> ".*uidNumber=([^,]+),cn=peercred,cn=external,cn=auth" >>> ldap:///ou=People,dc=example,dc=net??one?(uidNumber=$1) >> >> That sounds nice, but will it works with the "TLS_REQCERT demand" I have >> for ldaps:// ? > > Try: > > TLS_REQCERT: try > > In this case, EXTERNAL should only be offered after successful TLS > negotiation, or over a unix domain socket. Why should this have effect for ldapi:/// at all? > If TLS negotiation fails, then a SASL bind won't work without selecting > another mechanism. There is no TLS negotiation on a Unix domain socket at all. IMO many statements in this thread cause confusion: EXTERNAL acts differently depending on the connection type used. AFAIK you can query whether it's available for a certain connection by reading attribute supportedSASLMechanisms in the rootDSE. Emmanuel should simply set up a test environment where all the relevant clients always use SASL/EXTERNAL and have a SASL authc-to-authz-DN mapping in place for ldaps:// with client certs and ldapi:/// with peer credentials. The TLS options only affect ldaps:// or ldap:// with StartTLS ext.op. Ciao, Michael.

15 years

Re: syncrepl provider not working after upgrade to 2.4.26

by Nick Milas

On 17/10/2011 9:52 μμ, Nick Milas wrote: > I upgraded with the same configuration to v2.4.26 and provider is not > working Hmm, actually I changed a couple of things: 1. I am now using a different openldap RPM package (with different paths etc.); This should not be important, because I have updated configuration accordingly and everything (except syncrepl provider) works fine. 2. I have chosen to use hdb rather than bdb in the new setup. All entries were migrated by using slapcat on the initial instance and then slapadd on the new openldap instance. (They were migrated successfully. Could the use of hdb on the provider cause such a problem ("server is unwilling to perform")? (According to documentation hdb supports syncrepl). I read that this error means that "lapd will return an unwilling to perform error if the backend holding the target entry does not support the given operation". Why wouldn't the backend support sync operations in this case? Note that I tried (in consumers) all sorts of configurations (plain ldap without starttls or with starttls, ldaps) but nothing worked. In any case, below is my whole slapd.conf (Note: In this Openldap RPM, provided by the LTB project, all modules are included and not dynamically loaded): Thanks, Nick ----------------------------------------------------------------------------------- slapd.conf: ----------------------------------------------------------------------------------- include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/eduperson.schema include /usr/local/openldap/etc/openldap/schema/postfix.schema include /usr/local/openldap/etc/openldap/schema/dyngroup.schema include /usr/local/openldap/etc/openldap/schema/misc.schema include /usr/local/openldap/etc/openldap/schema/ppolicy.schema include /usr/local/openldap/etc/openldap/schema/schac-20090326-1.4.0.schema include /usr/local/openldap/etc/openldap/schema/dnsdomain2.schema include /usr/local/openldap/etc/openldap/schema/proftpd-quota.schema include /usr/local/openldap/etc/openldap/schema/kerberos.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args # Load dynamic backend modules: modulepath /usr/local/openldap/lib64 loglevel sync sizelimit unlimited timelimit unlimited TLSCipherSuite HIGH:MEDIUM:+SSLv2 TLSCACertificateFile /usr/local/openldap/etc/openldap/certs/chain.pem TLSCertificateFile /usr/local/openldap/etc/openldap/certs/cert.pem TLSCertificateKeyFile /usr/local/openldap/etc/openldap/certs/priv.pem TLSVerifyClient never database hdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret ######## # ACLs # ######## include /usr/local/openldap/etc/openldap/acl.conf directory /usr/local/openldap/var/openldap-data overlay auditlog auditlog /usr/local/openldap/var/openldap-data/ldapaudit.log index objectClass eq,pres index employeeType pres,eq index cn eq,pres,sub index sn,givenname eq,pres,sub index mail eq,pres,sub index uid eq,pres index ou eq,pres index mailacceptinggeneralid eq,pres index owner eq index entryCSN,entryUUID eq index vacationActive eq index associatedDomain pres,eq,sub index aRecord,pTRRecord pres,eq,sub index aliasInactive eq index krbPrincipalName eq,pres,sub index schacUserStatus eq,pres # Allow dynamic lists overlay dynlist dynlist-attrset nisMailAlias labeledURI dynlist-attrset groupOfURLs labeledURI member # Setup Provider - Allow Consumer Sync overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 database monitor access to * by dn.exact="cn=Manager,dc=example,dc=com" read by * none -----------------------------------------------------------------------------------

13 years, 8 months

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

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

8 years

RE: OpenLDAP Pass-through Authentication

by Quanah Gibson-Mount

--On Wednesday, February 12, 2025 6:38 AM -0500 Dino Edwards <dino.edwards(a)mydirectmail.net> wrote: > > >> But here's an example for cn-config, you'd probably have to adjust for > your own environment. > >> dn: olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config >> objectClass: olcOverlayConfig >> objectClass: olcRemoteAuthCfg >> olcOverlay: {6}remoteauth >> olcRemoteAuthTLS: starttls=yes tls_reqcert=never > >olcRemoteAuthMapping: default ldaps://ad.example.com:636 >> olcRemoteAuthDNAttribute: seeAlso >> olcRemoteAuthDomainAttribute: maildrop >> olcRemoteAuthDefaultDomain: default >> olcRemoteAuthDefaultRealm: ldaps://ad.example.com:636 >> olcRemoteAuthStore: FALSE >> olcRemoteAuthRetryCount: 3 > > > I tried loading the example below as a remoteauth.ldif file but I got the > following errors. Guessing the DN is wrong here? > > 67ac865a.098ae3bb 0x7eff0a2166c0 connection_input: conn=1005 deferring > operation: binding > 67ac865a.098c174e 0x7eff0aa176c0 conn=1005 op=1 ADD > dn="olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config" > 67ac865a.098cea57 0x7eff0aa176c0 conn=1005 op=1 RESULT tag=105 err=21 > qtime=0.000066 etime=0.000133 text=objectClass: value #1 invalid per > syntax ldap_add: Invalid syntax (21) > additional info: objectClass: value #1 invalid per syntax > 67ac865a.098d6d29 0x7eff0a2166c0 conn=1005 op=2 UNBIND > adding new entry "olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config" As I said, you'll need to adjust for your environment. You also will likley need to moduleload the remoteauth overlay. --Quanah

4 months, 2 weeks

openldap-technical search results for query "starttls"