Search results for "starttls" - openldap-technical

syncprov_db_open: invalid config, lastmod must be enabled

by Angel L. Mateo

Hi, I'm trying to configure chain overlay in a ldap replica consumer. My final purpose is that if this node receives an update, it directly tries to make it in the provider node, instead of returning the referrral. Is that possible? I think so... But I have a problem with the configuration. My config is ... moduleload back_ldap moduleload syncprov ... database hdb suffix dc=<mysuffix> ... overlay syncprov syncrepl rid=31 provider="ldap://<provider>" binddn="<replica user dn>" bindmethod=simple credentials=<password> searchbase="dc=<mysuffix>" type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 overlay chain chain-max-depth 1 chain-return-error true chain-uri ldap://<provider> chain-rebind-as-user yes chain-idassert-bind bindmethod=simple binddn=<replica user dn> credentials=<password> starttls=no mode="self" But when I test configuration with slaptest, I get: root@canis32:/etc/ldap# slaptest -f /etc/ldap/slapd.conf syncprov_db_open: invalid config, lastmod must be enabled backend_startup_one (type=hdb, suffix="<mysuffix>"): bi_db_open failed! (-1) slap_startup failed (test would succeed using the -u switch) and I can't run slapd. Any idea? I'm running slapd 2.4.21 (ubuntu lucid package) -- Angel L. Mateo Martínez Sección de Telemática Área de Tecnologías de la Información _o) y las Comunicaciones Aplicadas (ATICA) / \\ http://www.um.es/atica _(___V Tfo: 868887590 Fax: 868888337

12 years, 10 months

TLS replication/SALS bindmethod

by Darouichi, Aziz

Hi, I configured Muti-master replication, everything worked fine till I hashed rootpw to confirm to a hardcoded password in Oracle. I configured OpenLDAP servers to us SALS. This is my configuration. provider=ldap://xxx.xxx.xxx:389 bindmethod=sasl saslmech=external starttls=yes tls_cert=/etc/pki/tls/certs/slapd.pem tls_key=/etc/pki/tls/private/ldap.pem tls_cacert=/etc/pki/tls/certs/ca-bundle.crt tls_reqcert=demand binddn="cn=ldap,dc=establishment,dc=edu" credentials={SSHA}2vNffW+5hEolqIykgH9tCpxq9jTTVSSu searchbase="dc=establishment,dc=edu" schemachecking=on type=refreshAndPersist retry="60 +" when I run ldapsearch against servers I get response from both machines. ldapsearch -H ldap://server.establishment.edu -D "cn=ldap,dc=establishment,dc=edu" -w "PASSWORD" -x -b "dc=establishment ,dc=edu" "(objectclass=*)" uid. This what I get in the logs: May 23 09:37:01 ldap1 slapd[1559]: slap_client_connect: URI=ldap://xxx.xxx.edu:389 ldap_sasl_interactive_bind_s failed (-6) May 23 09:37:01 ldap1 slapd[1559]: do_syncrepl: rid=002 rc -6 retrying May 23 09:37:58 ldap1 slapd[1559]: conn=5220 op=0 do_extended: unsupported operation "1.3.6.1.4.1.1466.20037" May 23 09:38:01 ldap1 slapd[1559]: slap_client_connect: URI=ldap://xxx.xxx.edu:389 Warning, ldap_start_tls failed (2) May 23 09:38:01 ldap1 slapd[1559]: slap_client_connect: URI=ldap://xxx.xxx.edu:389 ldap_sasl_interactive_bind_s failed (-6) May 23 09:38:01 ldap1 slapd[1559]: do_syncrepl: rid=002 rc -6 retrying Thanks

13 years, 5 months

Re: connection problem with ldapmodify -Y EXTERNAL -H ldapi:///

by Dan White

On 03/10/11 21:43 +0200, Andreas Rudat wrote: >Am 03.10.2011 20:51, schrieb Dan White: >>On 03/10/11 19:41 +0200, Andreas Rudat wrote: >>>tls_cert >>>tls_key >> >>My mail client may have corrupted this part of your configuration. You'll >>of course need valid entries here. >> >These options are defaults in my conf. With some comments, after >installing the slapd package You'll need to create a (client) certificate and populate those two values, or otherwise find a way to specify them while performing your ldapsearch command. I don't see how you will will be able to obtain SASL EXTERNAL over STARTTLS otherwise. >>And again, you'll need to properly configure >>TLSVerifyClient/olcTLSVerifyClient in your OpenLDAP server config. >> >So I added this to cn=config: > >|*|add: olcTLSCACertificateFile >olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem >- >add: olcTLSCertificateFile >olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem >- >add: olcTLSCertificateKeyFile >olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem|* > >I think, thats what you meant? ... and olcTLSVerifyClient. >When properly configured, your list of supportedSASLMechanisms should >>include 'EXTERNAL'. >> >>For reference, see the manpages for ldap.conf and slapd-config (or >>slapd.conf), and see the OpenLDAP Administrator's Guide. I'd recommend depending a lot less on the howto you are reading, and a lot more on the above documentation. -- Dan White

13 years, 1 month

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

11 years, 10 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>

7 years, 4 months

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

9 years, 11 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.

5 years, 12 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.

14 years, 4 months

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

openldap-technical search results for query "starttls"