Search results for "starttls" - openldap-technical

Re: ldapdelete recursive (-r) with syncrepl

by Frank Crow

OpenLDAP 2.4.40 Syncrepl configuration: olcSyncUseSubentry: FALSE > olcSyncrepl: {0}rid=101 provider=ldap://server1 searchbase="o=xxx,dc=yyy, > dc=zzz" type=refreshOnly bindmethod=sasl saslmech=EXTERNAL > tls_cert=/etc/openldap/certs/xxxxx.crt > tls_key=/etc/openldap/certs/xxxxx.key > tls_cacert=/etc/openldap/certs/cacert.pem interval=00:00:00:10 > retry="5 10 10 10 30 +" timeout=1 starttls=critical > olcSyncrepl: {1}rid=102 provider=ldap://server2 > searchbase="o=xxx,dc=yyyy, > dc=zzz" type=refreshOnly bindmethod=sasl saslmech=EXTERNAL > tls_cert=/etc/openldap/certs/ldapadmin.crt > tls_key=/etc/openldap/certs/xxxxx.key > tls_cacert=/etc/openldap/certs/cacert.pem interval=00:00:00:10 > retry="5 10 10 10 30 +" timeout=1 starttls=critical > olcMirrorMode: TRUE BTW, I just tried addinging: dn: olcOverly={3}syncprov,olcDatabase={2},cn=config > changetype: modify > replace: olcSpCheckpoint > olcSpCheckpoint: 1024 > - > add: olcSpSessionlog > olcSpSessionlog: 1024 > - > add: olcSpReloadhint > olcSpReloadhint: TRUE And that seemed to fix it! Maybe it was just the checkpoint being "1 1" that was messing it up? Or maybe I needed the session log. I realize that this is the deprecated approach. I probably put in cn=changelog instead if there's a good reason to do so. -Frank On Tue, Apr 12, 2016 at 6:26 PM, Frank Crow <fjcrow2008(a)gmail.com> wrote: > OK, if I do a backup with slapcat, I still would want to wipe the existing > contents of the DIT first, right? > > Also, I just tried doing a list of deleted uid entries using "ldapdelete > -ZZ -f /file.ldif" and although the command did not complain, not all of > the entries in the file.ldif were deleted from all replicas. I really > think there is something wrong with my configuration! I suppose that I'll > try cn=changelog next. > > Thanks, > Frank > > > On Tue, Apr 12, 2016 at 5:47 PM, Michael Ströder <michael(a)stroeder.com> > wrote: > >> Frank Crow wrote: >> > I'm trying to create backup and restore scripts using LDAP command line >> > tools. >> >> For various reasons backup and restore should be done with command-line >> tools >> slapcat and slapadd which operate directly on the database files. >> >> And yes, with recent backend modules like back-mdb and back-hdb you can >> do hot >> backup while slapd is running. >> >> Of course, before a restore you have to stop slapd and remove the DB >> files. >> After using slapadd you should check whether ownership/permissions are >> still >> correct. >> >> Ciao, Michael. >> >> > > > -- > Frank > -- Frank

9 years, 2 months

RE: problem with ldap backend

by Alex Samad - Yieldbroker

Hi Just wondering if the features is supposed to work ? Am I delving into experimental code ? Alex > -----Original Message----- > From: Alex Samad - Yieldbroker > Sent: Thursday, 29 March 2012 9:28 AM > To: openldap-technical(a)openldap.org > Subject: RE: problem with ldap backend > > Hi > > I have progressed a little bit further > > I have stopped using olcdbaclbind and started to use > > olcDbIDAssertAuthzFrom: "*" > olcDbIDAssertBind: bindmethod=none authzId="CN=ad > readonly,OU=Services ,DC= xyz,DC=com" credentials="secret" starttls=no > > > but I get this > > text: 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform this > ope ration a successful bind must be completed on the connection., data 0, > v1db1 > > > I am able to ldapsearch with these credentials, I also tried change > bindmethod to simple, but same error > > How do I turn on debug for the ldap backend ? > > Any one have any ideas on how to make this work ? > > > Alex > > > > -----Original Message----- > > From: openldap-technical-bounces(a)OpenLDAP.org > > [mailto:openldap-technical- bounces(a)OpenLDAP.org] On Behalf Of Alex > > Samad - Yieldbroker > > Sent: Wednesday, 28 March 2012 1:58 PM > > To: openldap-technical(a)openldap.org > > Subject: problem with ldap backend > > > > Hi > > > > I am trying to setup a connection from openldap to MS AD > > > > I am using this > > > > dn: olcDatabase={3}ldap > > objectClass: olcDatabaseConfig > > objectClass: olcLDAPConfig > > olcDatabase: {3}ldap > > olcSuffix: dc=xyz,dc=com > > olcAccess: {0}to dn.base="" by * read > > olcAccess: {1}to dn.base="cn=Subschema" by * read > > olcAccess: {2}to * by self write by users read by anonymous auth > > olcReadOnly: TRUE > > olcRootDN: > gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth > > olcSizeLimit: 500 > > olcDbURI: "ldap://dc101. xyz.com ldap://dc201. xyz.com" > > olcDbRebindAsUser: TRUE > > olcDbChaseReferrals: TRUE > > > > > > This works fine when I pass a bind DN. > > > > I would like to convert this to allow anon access to ldap, which does > > a user bind to MS AD so I added this > > > > > > olcdbaclbind: bindmethod=simple binddn="CN=ad readonly,OU= xyz,DC= > > xyz,DC=com" credentials="secret" starttls=no > > > > but it is not working, I can not make a anon search request, they > > retrieve any thing frome the MSAD ldap server. > > > > Thanks > > > > > > > >

13 years, 2 months

Ldap problems in paradise, working with suse 12.1 miles stone 5

by John Tobin

Dear Ralf, Hi, I hope you are still here before the holidays, I would appreciate your advice and counsel. I have Suse 12.1 up, mile stone 5. It works well. I have installed and used ldap 2.4.26. It is also working with nss_ldap code. I am having some trouble on 2 counts. First I tried to get start_tls, and / or ldaps to work in that environment. I have not gotten tls to work. Was this tested at all in SUSE? TLS is critical to some success in the university lab I am running over here. I have posted the problem to the open ldap crew, and have heard nothing from anyone for solving the problem, or even assistance in how to debug it, or understand the failure I get.....[this is from nss_ldap] >> 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 In the middle of this mess Chris wood mentioned this would be easier, and may well work under nslcd. OK. I installed nslcd.... I have the lastest I believe: 0.7.13-7.3 I setup nslcd.conf to the best of my ability. With just a : Uri ldap://192.168.0.10/ Base dc=dark,dc=net Scope sub It works fine. For user jtobin [is only in ldap server] I get a login But in a similar fashion to nss_ldap, when I turn on ssl start_tls And add to the nslcd.conf above: Ssl start_tls Tls_reqcert allow Tls_cacertfile /var/lib/ldap/cacert.pem Tls_cert /var/lib/ldap/server.crt Tls_key /var/lib/ldap/server.key It fails.... I get: user jtobin does not exist But worse... I get nothing in the /var/log/localmessages file for debugging. Certificates were created using www.opeldap.org/faq/data/cache/185.html Which to my knowledge is the referenced site for openldap The certificate is a self signed cert. Most of my testing at the moment is local.... Client and slapd server are on the same machine, so same certificate file for tls_cacertfile, tls_cert, tls_key, though I have tested on remote clients with the same results. I see your name on a number of the nslcd doc and email. Help me out here.... How can I get this working / debugged? Who would have some of the information I need? Who would be interested in helping me to get this working. So far all I have gotten is a number of messages from interested parties asking me if I have gotten to work yet... Drop me aline with some advice as to how to get this resolved, or if it is probably not a short term Priority for anyone, tell me that. I will find a different strategy for securing my lab ldap client and server machines. [is getting this to work a priority at SUSE? Is there someone I can work with?] Sincerely tob There are a number of comments but the real statements are: Uri ldap://192.168.0.10/ Base dc=dark,dc=net Scope sub Ssl start_tls

13 years, 5 months

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

by Robert Heller

At Thu, 28 Sep 2017 16:08:42 -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote: > > --On Thursday, September 28, 2017 7:28 PM -0400 Robert Heller > <heller(a)deepsoft.com> wrote: > > > At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount <quanah(a)symas.com> > > wrote: > > > >> > >> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller > >> <heller(a)deepsoft.com> wrote: > >> > >> > >> > Slapd is reporting TLS Negotiation failure when SSSD tries to connect > >> > to it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess > >> > something is wrong with slapd's TLS configuration -- it is failing to > >> > do TLS Negotiation, either it is just not doing it or it is doing it > >> > wrong (somehow). Unless SSSD is not configured properly. > >> > >> You need to start with the following: > >> > >> >> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w > >> > >> to test startTLS > >> > >> and > >> > >> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w > >> > >> to test without startTLS > >> > >> If you can get those to work, then you can move on to SSSD. > > > > [heller@c764guest ~]$ ldapwhoami -x -ZZ -H ldap://c764guest:389 -D > > cn=Manager,dc=deepsoft,dc=com -W ldap_start_tls: Connect error (-11) > > additional info: TLS error -8157:Certificate extension not found. > > This may be of help: > <https://serverfault.com/questions/640910/my-certificate-doesnt-work-on-all-…> > > > [heller@c764guest ~]$ ldapwhoami -x -H ldaps://c764guest:636 -D > > cn=Manager,dc=deepsoft,dc=com -W Enter LDAP Password: > > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > > This may mean slapd isn't listening on port 636 (With no -d -1 info, hard > to know for sure). It may also simply be a different manifistation of the > error above. I added a -d option (picked 10), and discovered that it wanted the full name as specificed in the certificate. That fixed ldapwhoami and I put that in ldap.conf, smb.conf, and in sssd.conf, but sssd is still not behaving (samba is though, mostly -- it might also be having issues since sssd is not working)... > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > -- Robert Heller -- 978-544-6933 Deepwoods Software -- Custom Software Services http://www.deepsoft.com/ -- Linux Administration Services heller(a)deepsoft.com -- Webhosting Services

7 years, 8 months

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

by brendan kearney

Late ti the thread, so forgive the stupid question, but why arent you using SASL and forgoing all the OpenSSL vs MozNSS kerfuffle? If you have OpenLDAP and SSSD going on, surely Kerberos is something you are able to setup. On Sep 29, 2017 2:20 AM, "Michael Wandel" <m.wandel(a)t-online.de> wrote: > On 28.09.2017 21:41, Robert Heller wrote: > > Will these spit out useful error messages? If I just get "TLS > Negotiation > > failure" it is not going to be helpful. > > > > You can make it a little bit more verbose with the option "-d -1" > > It is only a suggestion, but can you test the parameter > > TLS_REQCERT allow > > in your /etc/openldap/ldap.conf > > This ist not a good option for production systems, but it seems you come > in trouble with your certificates. > > You have to set your > > TLS_CACERT > xor > TLS_CACERTDIR > > correctly in your /etc/openldap/slapd.conf to work stressless with your > ssl/tls. > > best regards > Michael > > > At Thu, 28 Sep 2017 12:29:19 -0700 Quanah Gibson-Mount <quanah(a)symas.com> > wrote: > > > >> > >> --On Thursday, September 28, 2017 3:34 PM -0400 Robert Heller > >> <heller(a)deepsoft.com> wrote: > >> > >> > >>> Slapd is reporting TLS Negotiation failure when SSSD tries to connect > to > >>> it. For both port 389 (ldap:///) and 636 (ldaps:///). So I guess > >>> something is wrong with slapd's TLS configuration -- it is failing to > do > >>> TLS Negotiation, either it is just not doing it or it is doing it > wrong > >>> (somehow). Unless SSSD is not configured properly. > >> > >> You need to start with the following: > >> > >>>> ldapwhoami -x -ZZ -H ldap://myhost:389 -D binddn -w > >> > >> to test startTLS > >> > >> and > >> > >> ldapwhoami -x -H ldaps://myhost:636 -D binddn -w > >> > >> to test without startTLS > >> > >> If you can get those to work, then you can move on to SSSD. > >> > >> --Quanah > >> > >> -- > >> > >> Quanah Gibson-Mount > >> Product Architect > >> Symas Corporation > >> Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > >> <http://www.symas.com> > >> > >> > > > > > -- > Michael Wandel > Braakstraße 43 > 33647 Bielefeld > >

7 years, 8 months

Re: OpenLDAP self-signed certificates issue

by Vijay Ganesan

Thanks Ryan and Udai. Don't really have to use ldaps. I understand now that the documentation <https://help.ubuntu.com/12.04/serverguide/openldap-server.html#openldap-tls> is for StartTLS an can use that. LDAPTLS_CACERT=/etc/ssl/certs/vijay_slapd_cert.pem ldapwhoami -H ldap://localhost -x -ZZ gives: *ldap_start_tls: Connect error (-11)* * additional info: A TLS packet with unexpected length was received.* with '-d1' I get the following which looks like it can connect but subsequent communication fails: ldap_url_parse_ext(ldap://localhost) ldap_create ldap_url_parse_ext(ldap://localhost:389/??base) ldap_extended_operation_s ldap_extended_operation ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 127.0.0.1:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_scanf fmt ({) ber: ber_flush2: 31 bytes to sd 3 ldap_result ld 0x7f2c70eef160 msgid 1 wait4msg ld 0x7f2c70eef160 msgid 1 (infinite timeout) wait4msg continue ld 0x7f2c70eef160 msgid 1 all 1 ** ld 0x7f2c70eef160 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Mon Sep 8 07:56:01 2014 ** ld 0x7f2c70eef160 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x7f2c70eef160 request count 1 (abandoned 0) ** ld 0x7f2c70eef160 Response Queue: Empty ld 0x7f2c70eef160 response count 0 ldap_chkResponseList ld 0x7f2c70eef160 msgid 1 all 1 ldap_chkResponseList returns ld 0x7f2c70eef160 NULL ldap_int_select read1msg: ld 0x7f2c70eef160 msgid 1 all 1 ber_get_next ber_get_next: tag 0x30 len 12 contents: read1msg: ld 0x7f2c70eef160 msgid 1 message type extended-result ber_scanf fmt ({eAA) ber: read1msg: ld 0x7f2c70eef160 0 new referrals read1msg: mark request completed, ld 0x7f2c70eef160 msgid 1 request done: ld 0x7f2c70eef160 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_extended_result ber_scanf fmt ({eAA) ber: ldap_parse_result ber_scanf fmt ({iAA) ber: ber_scanf fmt (}) ber: ldap_msgfree TLS: can't connect: A TLS packet with unexpected length was received.. ldap_err2string ldap_start_tls: Connect error (-11) additional info: A TLS packet with unexpected length was received. ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 3 ldap_free_connection: actually freed On Mon, Sep 8, 2014 at 7:13 AM, Ryan Tandy <ryan(a)nardis.ca> wrote: > On 07/09/14 10:28 PM, Vijay Ganesan wrote: > >> But I can't seem to connect using ldaps://localhost:636 using Apache >> Directory Studio client. I get a "Error while opening connection - >> Cannot connect on the server: Connection refused" error. >> I can connect fine using ldap://localhost:389. >> > > Like Udai wrote, ldaps is deprecated, and if possible you should use > STARTTLS on the LDAP port (389) instead. But if you really need ldaps, then > edit /etc/default/slapd, add ldaps:/// to the SLAPD_SERVICES line, and > restart slapd. > > What diagnostics can be run to figure out if TLS is working correctly? >> > > LDAPTLS_CACERT=/path/to/ca.pem ldapwhoami -H ldap://server -x -ZZ > > Add '-d1' to see some debugging information, including more detailed info > from the TLS library. > -- - Vijay

10 years, 9 months

Re: new entry lost on multi-master setup (two scenarios)

by Jose Ildefonso Camargo Tolosa

Ok, then... either:I'm missing something obvious, or no one have any idea on this... Should I create a bug report based on my findings here? Thanks! Ildefonso Camargo On Tue, Apr 19, 2011 at 2:12 PM, Jose Ildefonso Camargo Tolosa <ildefonso.camargo(a)gmail.com> wrote: > Greetings, > > Any comments on this? can anybody help me verify this possible bug? > > Ildefonso. > > On Sun, Apr 17, 2011 at 2:24 PM, Jose Ildefonso Camargo Tolosa > <ildefonso.camargo(a)gmail.com> wrote: >> Greetings, >> >> At first, I was going to create a bug report, but decided to send to >> list first. I tried this with both: 2.4.23 (Debian package), and >> 2.4.25, compiled from source, bdb 4.8. >> >> After a couple of entries just disappeared on one multi-master setup I >> had, I decided to further investigate, and found this (there are two >> cases, for the same procedure): >> >> 1. Configure two LDAP servers in multi-master setup. >> 2. Make sure they replicate correctly (off course). >> 3. Shutdown one of the two ldap servers. >> 4. Create a new entry (say, ou1) on the LDAP server that is left up. >> 5. Shutdown the last LDAP server. >> 6. Start the *other* LDAP server, the one where you didn't create the entry. >> 7. Create another entry, say: ou2, so that both servers has a new >> entry, that is *not* on the other server. >> 8. Shutdown the LDAP server (both servers down now). >> 9. Start both LDAP servers. >> >> Result (case 1): one of the two newly created entries is missing on >> *one* of the servers, and only one of the entries is missing on the >> other server. >> >> Result (case 2): one entry is missing on *both* servers. >> >> Both servers has NTP, and has the same timezone (ie, time is synchronized). >> >> I'm *not* replicating cn=config (I shouldn't, because I have different >> SSL certificates on each server). Now, more details: >> >> slapd with -d 16384 gives me this on the server that misses both >> entries, on this server I created the entry dn >> ou=ou2,dc=st-andes,dc=com (and the server decided to delete it!, and, >> for some reason, it didn't detected the new ou1 entry created on the >> other server): >> >> http://www.st-andes.com/openldap/case1/log-server2-case1.txt >> >> The other server (the one that kept one entry and lost the other), on >> this server I created the entry ou=ou1,dc=st-andes,dc=com, and it says >> it was changed by peer.....: >> >> http://www.st-andes.com/openldap/case1/log-server1-case1.txt >> >> Now, I'm seeing here that it is using 000 server id... but on the >> cn=config.ldif I have: >> >> olcServerID: 1 ldap://ldap.ildetech.com:389/ >> olcServerID: 2 ldap://ldap2.ildetech.com:389/ >> >> And the syncrepl: >> >> olcSyncRepl: rid=001 provider=ldap://ldap.ildetech.com:389 >> binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple >> credentials="secret" searchbase="dc=st-andes,dc=com" >> type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical >> olcSyncRepl: rid=002 provider=ldap://ldap2.ildetech.com:389 >> binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple >> credentials="secret" searchbase="dc=st-andes,dc=com" >> type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical >> olcMirrorMode: TRUE >> >> And, as you can see on the command line, I have the URL specified on >> the -h parameter, but it seems to be ignoring it!. Or, should I >> specify the *whole* urls that I put on the -h parameter? >> (ldap://ldap2.ildetech.com:389 ldap://127.0.0.1:389/ ldaps:/// >> ldapi:///) >> >> So, I decided to change the config: >> >> On server 1 (kirara): >> >> olcServerID: 1 >> >> and >> >> olcSyncRepl: rid=002 provider=ldap://ldap2.ildetech.com:389 >> binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple >> credentials="secret" searchbase="dc=st-andes,dc=com" >> type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical >> olcMirrorMode: TRUE >> >> On server 2 (happy): >> >> olcServerID: 2 >> >> and >> >> olcSyncRepl: rid=002 provider=ldap://ldap2.ildetech.com:389 >> binddn="cn=admin,dc=st-andes,dc=com" bindmethod=simple >> credentials="secret" searchbase="dc=st-andes,dc=com" >> type=refreshAndPersist retry="3 5 5 +" timeout=7 starttls=critical >> olcMirrorMode: TRUE >> >> With this new setup, and following the same procedure, I get one >> missing entry on *both* servers (at least servers gets to a consistent >> state), but I still have a missing entry. The logs for this setup: >> >> Server 2 (ID 2, where I created entry: ou2 while the other server was >> down), this server decided, wrongly, to delete entry ou2: >> >> http://www.st-andes.com/openldap/case2/log-server2-case2.txt >> >> And the other server (where I created ou1): >> >> http://www.st-andes.com/openldap/case2/log-server1-case2.txt >> >> This one never saw the other entry, ou2. >> >> For both cases, the syncprov module was with default configuration: >> >> dn: olcOverlay={0}syncprov >> objectClass: olcOverlayConfig >> objectClass: olcSyncProvConfig >> olcOverlay: {0}syncprov >> structuralObjectClass: olcSyncProvConfig >> entryUUID: 24354488-e5bf-102f-9e6a-ad3cba95f7f1 >> creatorsName: cn=config >> createTimestamp: 20110318152128Z >> entryCSN: 20110318152128.935227Z#000000#000#000000 >> modifiersName: cn=config >> modifyTimestamp: 20110318152128Z >> >> What do you think? >> >> Thanks in advance! >> >> Ildefonso Camargo >> >

14 years, 1 month

Re: Replication issues with openldap 2.5

by Quanah Gibson-Mount

--On Thursday, January 2, 2025 9:37 AM -0500 Ulises Gonzalez Horta <ugonzalezhorta(a)breezeline.com> wrote: > > > > Hi Shawn > > After closely inspecting both/all entries with slapcat on each of the > servers I confirmed that all the user entries are being replicated > -except- for the userPassword one. > So it looks like we found the issue. > > > Question is how to fix it, why is it not replicating the userPassword > attribute? > > I have removed my filter entry from my olcSyncrepl, now it looks like this > > olcSyncrepl: {0}rid=100 provider=ldap://master:389 type=refr > eshOnly interval=00:00:05:00 retry="300 +" > searchbase="dc=metrocast,dc=net" t > imelimit=unlimited sizelimit=unlimited bindmethod=simple > binddn="cn=repl,ou=boxes,dc=metrocast,dc=net" credentials="aaa" starttls > =critical tls_cacertdir="/etc/ldap/certs" > > But still not replicating the userPassword attribute, any clue?? Likely your provider does not grant read access for the userPassword attribute to the "cn=repl,ou=boxes,dc=metrocast,dc=net" user. You should be able to test this from the command line with ldapsearch. --Quanah

5 months, 1 week

OpenLDAP syncrepl over SSL

by Tony Davis

Hi, I wonder if anyone can help me with a question I have regarding an openldap setup on Redhat / Centos 5.8 using openldap-2.3.43. I am trying to setup replication, I have set this up using the simple bind method, which stores a password for the replication in the config. (This works) but I wondered if there was a way to have this replication take place using ssl certificates without the need to store the unhashed password in the slapd.conf? Is this possible? or do I still have to specify a replication user and pass, but all the auth takes place over ssl? This is my current config for replication: syncrepl rid=001 provider=ldap://master01.tld type=refreshAndPersist interval=00:00:05:00 retry="5 5 300 +" searchbase="dc=tld" attrs="*,+" bindmethod=sasl saslmech=EXTERNAL tls_cert=/etc/master02.tld.pem tls_key=/etc/master02.tld.key tls_cacert=/etc/openldap/cacerts/ca.pem tls_reqcert=demand starttls=yes mirrormode on updateref ldap://master01.tld but in the replication log i get the following: Jul 31 11:06:18 master02 slapd[6958]: do_syncrep1: rid 001 ldap_sasl_interactive_bind_s failed (7) Jul 31 11:06:18 master02 slapd[6958]: do_syncrepl: rid 001 retrying (3 retries left) Jul 31 11:06:18 master02 slapd[6958]: daemon: activity on 1 descriptor Jul 31 11:06:18 master02 slapd[6958]: daemon: activity on:

11 years, 10 months

RE: [EXTERNAL] Re: back-ldap and ldaps not working

by Quanah Gibson-Mount

--On Friday, July 07, 2017 8:10 PM +0000 Jon C Kidder <jckidder(a)aep.com> wrote: > I've removed the starttls=no syntax and the line now reads. > > olcDbStartTLS: ldaps > tls_cacert="/appl/openldap/etc/openldap/tls/cacerts.cer " > tls_reqcert=demand tls_crlcheck=none > > I have verified the change propagated to the configuration directory and > restarted the instance. I saw no errors during configuration parsing in > the log. I am still seeing this error when the chain overlay tries to > follow the referral but no complaints when syncrepl connects. I'm not sure how you do this with cn=config. With slapd.conf, it would be done via using "chain-tls" and not "tls", as per the man page: There are very few chain overlay specific directives; however, directives related to the instances of the ldap backend that may be implicitly instantiated by the overlay may assume a special meaning when used in conjunction with this overlay. They are described in slapd-ldap(5), and they also need to be prefixed by chain-. It may be worthwhile to set up a slapd.conf where "chain-tls" is specified, and see what happens with that on conversion. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

7 years, 11 months

openldap-technical search results for query "starttls"