Search results for "starttls" - openldap-technical

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

by Andreas Rudat

Am 04.10.2011 18:59, schrieb Dan White: > On 04/10/11 09:22 -0700, Howard Chu wrote: >> Dan White wrote: >>> 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. >> >> How did this conversation get to STARTTLS? The Subject is asking >> about SASL EXTERNAL over ldapi, which does not need TLS. > > I was led down that path via the howto referenced in the original > post, and > made several, possibly incorrect, assumptions about what the end goal is. > Sorry for that confusion Howard and thanks for you help Dan, I will work with the man page now and will create a new better topic if needed. Andreas

15 years

Re: Enforce remote SSL/TLS

by Kasper Loopstra

On 11/23/2011 05:51 PM, Dan White wrote: > On 23/11/11 17:06 +0100, Kasper Loopstra wrote: >> Dear list, >> >> We are using PAM to authenticate posixUsers against OpenLDAP. This >> works great, and allows 'local' (ssh) logins. However, we also use >> LDAP for a number of other services, including remote access and >> editing via other software. This means we would like to keep our >> users passwords as secure as possible, and enforce encrypted logins >> for all remote hosts. However, PAM should still be able to >> authenticate. The manner of encryption is not really important, it >> just has to be strong enough to be useful over the internet, and >> usable for all (or most) clients. >> >> We have tried various solutions with ssf directives in >> /etc/ldap/slapd.conf as well as the security tls=1 directive. All of >> these attempts broke PAM. > > Which PAM ldap module are you using? with PADL's module, you'd want to > configure 'ssl on' (for ldaps:///) or 'ssl starttls' (for starttls over > ldap:///) and also configure the tls_* settings appropriately. > We're using libpam-ldap from Debian, which is indeed the PADL module according to the comments. Is it really necesary to use SSL when communicating within localhost? If it is, that's fine, it just doesn't seem to be the right way to handle local traffic. > For your slapd configuration, see the slapd.conf manpage - the TLS* > options, as well as the 'security' option. If you are wishing to perform > secure connections over ldaps:///, verify that in your slapd init script, > that you are passing 'ldaps:///' as one of your '-h' command line > parameters. > According to the init file provided by Debian, it seems to be using the conf file for this information. Is that correct/possible, or should we be asking the Debian people? Thanks for the quick response, Kasper Loopstra

14 years, 11 months

RE: [EXT] RE: OpenLDAP Pass-through Authentication

by Windl, Ulrich

Can you explain the intentions for " olcRemoteAuthTLS: starttls=yes tls_reqcert=never"? Starting TLS without a certificate? Do you expect encryption then? Kind regards, Ulrich Windl > -----Original Message----- > From: Dino Edwards <dino.edwards(a)mydirectmail.net> > Sent: Wednesday, February 12, 2025 12:39 PM > To: 'Quanah Gibson-Mount' <quanah(a)fast-mail.org>; openldap- > technical(a)openldap.org > Subject: [EXT] RE: OpenLDAP Pass-through Authentication > > > > > 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" > > Thanks

1 year, 8 months

Re: Issue with slapd and Google LDAP Integration (lowercase user)

by Quanah Gibson-Mount

--On Monday, November 4, 2024 8:29 PM -0300 tmp 2810 <t2810mp(a)gmail.com> wrote: > Once again, I apologize; I ran so many tests that I accidentally copied > one where the binddn was incorrect. > > The target looks more like this: > >## example.com > uri "ldaps://ldap.google.com/dc=proxy" > suffixmassage "dc=proxy" "dc=example,dc=com" > lastmod off > readonly on > idassert-bind bindmethod=simple > binddn="cn=ChiwewDaw" cn, is by definition, case insensitive. If Google LDAP is forcing case sensitivity in this attribute, it is gross violation of the LDAP RFCs. However, having had to interface with it in the past, I don't believe that is the case. I would generally suspect that this is not the full DN of the user. > idassert-bind bindmethod=sasl > saslmech=EXTERNAL > tls_reqcert=demand > tls_reqsan=demand > starttls=critical This is not sufficient, please read the man page: idassert-bind bindmethod=none|simple|sasl [binddn=<simple DN>] [credentials=<simple password>] [saslmech=<SASL mech>] [secprops=<properties>] [realm=<realm>] [authcId=<authentication ID>] [authzId=<authorization ID>] [authz={native|proxyauthz}] [mode=<mode>] [flags=<flags>] [starttls=no|yes|critical] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_reqsan=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_ecname=<names>] [tls_protocol_min=<version>] [tls_crlcheck=none|peer|all] You *must* specify tls_cert, tls_key, and tls_cacert as a part of idassert-bind as it provides the TLS identity to bind as. In your configuration for simple bind, tls_cert and tls_key are unnecessary as you're not doing SASL/EXTERNAL binds. --Quanah

1 year, 11 months

Antw: [EXT] Re: STARTTLS vs LDAPS

by Ulrich Windl

>>> <thomaswilliampritchard(a)gmail.com> schrieb am 31.03.2022 um 06:29 in Nachricht <20220331042904.5262.30720(a)hypatia.openldap.org>: > Quanah Gibson-Mount wrote: >> --On Wednesday, March 30, 2022 8:28 PM +0200 Stefan Kania >> <stefan(a)kania-online.de> wrote: >> >> > That's what can be found in the FAQ on openldap.org: >> > >> > https://www.openldap.org/faq/data/cache/605.html >> > >> > I would trust this more then any rumors on any stackxxxx page ;) >> Unfortunately, the FAQ is dead weight we want to kill and not maintained in >> any way, shape, or form. It's currently provided for historical purposes. >> >> As to this overall discussion, one of the primary issues with connections >> over ldap:/// is that there's zero way with simple binds to prevent the >> bind dn + password being sent in the clear by a client to the server. With >> ldaps:/// the encryption is set up before the BIND occurs so you don't run >> this risk. > > Is that true? Surely I can > 1. connect to the server > 2. Send starttls > 3. Then bind bind can't I? > I'm fairly certain I've used LDAP Client operating in that order. I think the point was that you can bind even when not having started TLS before. I don't know whether this can prevent it: olcSecurity: ssf=0 update_ssf=128 simple_bind=64 (I can't remember why I put "ssf=0" there; maybe to allow anonymous DLAPv2) Regards, Ulrich > >> >> So from that standpoint, I'd personally prefer to see ldaps:/// qualified >> in an RFC so the standardization argument goes away and ldaps be noted as >> the preferred method for sites that require encryption. > > I agree there is no technical reason LDAPS would not be better. It should be > made standard.

4 years, 7 months

RE: Syncrepl and mmr

by Quanah Gibson-Mount

Hi John, SIDs (server IDs) must be unique across servers. RIDs (replication IDs) must be unique inside a single server. So the answer to your question is essentially "no". If you email me your full cn=config db bits from both servers (minus passwords), there's some cleanup on them I can send back. The serverID: 1 <URI> bit is only necessary if you are doing cn=config replication, which you are not doing. If you are going to use the <#> <URI> form, then the <URI> must EXACTLY MATCH the arguments slapd is being started with. Personally, since I do not do cn=config replication, and the URIs are customizable by customers, I go with the much simpler: olcServerID: <#> form. Then each server only has a single value for olcServerID, which is its specific serverID. This way I never have to worry that MMR replication is going to get mesed up because of URI changes. --Quanah --On Tuesday, February 18, 2014 10:09 AM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > All, > > The long weekend didn't help...still at a loss. Question... > > If the olcServerIDs look like, on all three servers: > > olcServerID: 1 ldap://mm-server1.example.ldap > olcServerID: 2 ldap://mm-server2.example.ldap > olcServerID: 3 ldap://mm-server3.example.ldap > > Should the Replica IDs (rid) in the olcSycnrepl directive be: > > olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap > bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" > credentials=<password> interval=01:00:00:00 > searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on > type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" > syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002 > provider=mm-server2.example.ldap bindmethod=simple > binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> > interval=01:00:00:00 searchbase="dc=example,dc=ldap" > logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 > +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no > olcSyncrepl: {0} rid=003 provider=mm-server3.example.ldap > bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" > credentials=<password> interval=01:00:00:00 > searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on > type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" > syncdata=accesslog starttls=no > > OR > > olcSyncrepl: {0} rid=1 provider=mm-server1.example.ldap bindmethod=simple > binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> > interval=01:00:00:00 searchbase="dc=example,dc=ldap" > logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 > +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no > olcSyncrepl: {1} rid=2 provider=mm-server2.example.ldap bindmethod=simple > binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> > interval=01:00:00:00 searchbase="dc=example,dc=ldap" > logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 > +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no > olcSyncrepl: {0} rid=3 provider=mm-server3.example.ldap bindmethod=simple > binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> > interval=01:00:00:00 searchbase="dc=example,dc=ldap" > logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 > +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no > > OR > > Does it matter? > > Also, should the all three olcSycrepl directives be loaded on all three > servers so they look identical. What I mean by that is should each > Server "replicate" to itself? There is confusion on this matter. I > asked Quanah that back in late January, and he stated that the system > knows about itself so it knows what to ignore. Then last week, he asked > why I had the master replicating to itself. > > Also, since I have refreshAndPersist configured do I need an interval as > well? > > Thanks in advance, > > John > > -----Original Message----- > From: openldap-technical-bounces(a)OpenLDAP.org > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, > John - 0442 - MITLL Sent: Friday, February 14, 2014 4:28 PM > To: Quanah Gibson-Mount; openldap-technical(a)openldap.org > Subject: RE: Syncrepl and mmr > > All, > > I just created an mm-server3, using the config_dbase and main_dbase from > mm-server2 -- copied the ldif's I created from mm-server2 then ran > slapadd. > > On mm-server3: > olcServerID: 1 ldap://mm-server1.example.ldap > olcServerID: 2 ldap://mm-server2.example.ldap > olcServerID: 3 ldap://mm-server3.example.ldap > > olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap > bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" > credentials=<password> interval=01:00:00:00 > searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on > type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" > syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002 > provider=mm-server2.example.ldap bindmethod=simple > binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> > interval=01:00:00:00 searchbase="dc=example,dc=ldap" > logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 > +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no > olcSyncrepl: {0} rid=003 provider=mm-server3.example.ldap > bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" > credentials=<password> interval=01:00:00:00 > searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on > type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" > syncdata=accesslog starttls=no > > Started slapd, no errors. It immediately sync'd up with mm-server1! > Changes that I made on mm-server1 days ago which have never replicated > over to mm-server2...replicated to mm-server3 immediately on startup. > > I had not even got around to adding mm-server3 to mm-server1 (or > mm-server2) yet. > > The olcServerIDs and olcSyncrepl on both mm-server1 and 2 show: > olcServerID: 1 ldap://mm-server1.example.ldap > olcServerID: 2 ldap://mm-server2.example.ldap > > olcSyncrepl: {0} rid=001 provider=mm-server1.example.ldap > bindmethod=simple binddn="cn=ldapadmin,dc=group42,dc=ldap" > credentials=<password> interval=01:00:00:00 > searchbase="dc=example,dc=ldap" logbase="cn=accesslog" schemachecking=on > type=refreshAndPersist retry="60 +" filter="(objectClass=*)" attrs=*,+" > syncdata=accesslog starttls=no olcSyncrepl: {1} rid=002 > provider=mm-server2.example.ldap bindmethod=simple > binddn="cn=ldapadmin,dc=group42,dc=ldap" credentials=<password> > interval=01:00:00:00 searchbase="dc=example,dc=ldap" > logbase="cn=accesslog" schemachecking=on type=refreshAndPersist retry="60 > +" filter="(objectClass=*)" attrs=*,+" syncdata=accesslog starttls=no > > So...now, I am at even more of a loss. Why would mm-server1 be > replicating to mm-server3 and not 2? When the configs are the same > between mm-server2 and 3??? > > > > Thanks in advance... > John > > > -----Original Message----- > From: openldap-technical-bounces(a)OpenLDAP.org > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, > John - 0442 - MITLL Sent: Friday, February 14, 2014 1:34 PM > To: Quanah Gibson-Mount; openldap-technical(a)openldap.org > Subject: RE: Syncrepl and mmr > > All, > > If I went off the beaten' path...where did I go wrong? (my config and > error messages are in a previous posting) > > Thanks in advance, > John > > -----Original Message----- > From: openldap-technical-bounces(a)OpenLDAP.org > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Borresen, > John - 0442 - MITLL Sent: Friday, February 14, 2014 8:40 AM > To: Quanah Gibson-Mount; openldap-technical(a)openldap.org > Subject: RE: Syncrepl and mmr > > Thanks Quanah, > > A few weeks back I asked that question (on 1/30): >> All Masters in the chain have the olcServerID's and olcSynRepl for >> itself and its partner? I can understand having each knowing about >> the others but why itself? It's replicating to itself? > -You replied > -It knows about itself so it knows what to ignore. > > Even in the Admin Guide is specifies setting it up that way...each server > has all the others and itself listed. I was following the procedures > delineated in the Admin Guide and in the man-pages (including how I > understood what was put out on the board): From the Admin Guide: > 8.3.3. N-Way Multi-Master > > For the following example we will be using 3 Master nodes. Keeping in > line with test050-syncrepl-multimaster of the OpenLDAP test suite, we > will be configuring slapd(8) via cn=config > > This sets up the config database: > > dn: cn=config > objectClass: olcGlobal > cn: config > olcServerID: 1 > > dn: olcDatabase={0}config,cn=config > objectClass: olcDatabaseConfig > olcDatabase: {0}config > olcRootPW: secret > > second and third servers will have a different olcServerID obviously: > > dn: cn=config > objectClass: olcGlobal > cn: config > olcServerID: 2 > > dn: olcDatabase={0}config,cn=config > objectClass: olcDatabaseConfig > olcDatabase: {0}config > olcRootPW: secret > > This sets up syncrepl as a provider (since these are all masters): > > dn: cn=module,cn=config > objectClass: olcModuleList > cn: module > olcModulePath: /usr/local/libexec/openldap > olcModuleLoad: syncprov.la > > Now we setup the first Master Node (replace $URI1, $URI2 and $URI3 etc. > with your actual ldap urls): > > dn: cn=config > changetype: modify > replace: olcServerID > olcServerID: 1 $URI1 > olcServerID: 2 $URI2 > olcServerID: 3 $URI3 > > dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config > changetype: add > objectClass: olcOverlayConfig > objectClass: olcSyncProvConfig > olcOverlay: syncprov > > dn: olcDatabase={0}config,cn=config > changetype: modify > add: olcSyncRepl > olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" > bindmethod=simple credentials=secret searchbase="cn=config" > type=refreshAndPersist retry="5 5 300 5" timeout=1 > olcSyncRepl: rid=002 provider=$URI2 binddn="cn=config" > bindmethod=simple credentials=secret searchbase="cn=config" > type=refreshAndPersist retry="5 5 300 5" timeout=1 > olcSyncRepl: rid=003 provider=$URI3 binddn="cn=config" > bindmethod=simple credentials=secret searchbase="cn=config" > type=refreshAndPersist retry="5 5 300 5" timeout=1 > - > add: olcMirrorMode > olcMirrorMode: TRUE > > I followed what is put in the Admin Guide, etc... > > Thanks > > -----Original Message----- > From: openldap-technical-bounces(a)OpenLDAP.org > [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Quanah > Gibson-Mount Sent: Thursday, February 13, 2014 1:57 PM > To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org > Subject: Re: Syncrepl and mmr > > --On Thursday, February 13, 2014 10:54 AM -0500 "Borresen, John - 0442 - > MITLL" <John.Borresen(a)ll.mit.edu> wrote: > >> All, > > Your configuration is very confused. Why do you have the master > replicate to itself, for example? > > --Quanah > > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > > -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

12 years, 8 months

Re: number of contextcsn entries per database

by Howard Chu

PJunod(a)mediageneral.com wrote: > I have setup two ldap servers for authentication and access control in a > multi-master configuration. I am concerned about the number of contextcsn > entries that are supposed to be present in each database. Right now there are > two servers participating in the multi-master configuration. From my > understanding, there should be one contextCSN entry per database per host. My > cn=config database has two contextCSN entries as I would expect. One for each > syncrepl rid configured. My bdb database only has one contextCSN entry though, > with an rid of just “000”. (my rid’s are 001, 002, 101, and 102) ContextCSN is an attribute. Attributes have values, they do not have entries. CSNs carry SIDs not RIDs. If you don't use the correct terminology no one will understand what you're talking about. If a database contains changes from more than one server, then its contextCSN should contain more than one value, and each value should have distinct SIDs. But the SIDs will only be used correctly if the URLs in the ServerID directive match the actual URLs given to the slapd -h option. > Replication seems to work fine on both databases. I can write to either one > and the changes are replicated over immediately. I am just curious about this > discrepancy in the number of contextCSN entries. Could someone confirm the > number of contextCSN entries per database and if it should match the number of > hosts participating in the multi-master replication? Here are some relevant > settings for the replication: > > dn: cn=config > > olcServerID: 1 ldap://<server1> > > olcServerID: 2 ldap://<server2> > > ####################### > > # module{0}, config > > dn: cn=module{0},cn=config > > objectClass: olcModuleList > > cn: module{0} > > olcModulePath: /usr/lib64/openldap2.4 > > olcModuleLoad: {0}syncprov.la > > ####################### > > # {0}config, config > > dn: olcDatabase={0}config,cn=config > > olcSyncrepl: {0}rid=001 provider=ldap://<server1> binddn="cn=Ma > > nager,cn=config" bindmethod=simple credentials=<password> searchbase="cn=config > > " type=refreshAndPersist retry="5 500 5 +" timeout=1 starttls=yes > > olcSyncrepl: {1}rid=002 provider=ldap://<server2> binddn="cn=Ma > > nager,cn=config" bindmethod=simple credentials=<password> searchbase="cn=config > > " type=refreshAndPersist retry="5 500 5 +" timeout=1 starttls=yes > > olcMirrorMode: TRUE > > ####################### > > # {0}syncprov, {0}config, config > > dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config > > objectClass: olcOverlayConfig > > objectClass: olcSyncProvConfig > > olcOverlay: {0}syncprov > > ####################### > > # {1}bdb, config > > dn: olcDatabase={1}bdb,cn=config > > olcSyncrepl: {0}rid=101 provider=ldap://<server1> binddn="cn=Ma > > nager,dc=mgcorp,dc=net" bindmethod=simple credentials=<password> searchbase="dc > > =mgcorp,dc=net" type=refreshAndPersist interval=00:00:00:10 retry="5 500 5 +" > > timeout=1 starttls=yes > > olcSyncrepl: {1}rid=102 provider=ldap://<server2> binddn="cn=Ma > > nager,dc=mgcorp,dc=net" bindmethod=simple credentials=<password> searchbase="dc > > =mgcorp,dc=net" type=refreshAndPersist interval=00:00:00:10 retry="5 500 5 +" > > timeout=1 starttls=yes > > olcMirrorMode: TRUE > > ############################## > > Here are the results of searches for contextCSN in cn=config and dc=mgcorp,dc=net: > > ldapsearch -x -W -s base -D "cn=Manager,cn=config" -h "<server2>" -b > "cn=config" contextCSN > > contextCSN: 20101110214932.998233Z#000000#000#000000 > > contextCSN: 20101028121213.444193Z#000000#001#000000 > > ldapsearch -x -W -s base -D "cn=Manager,dc=mgcorp,dc=net" -h "<server2>" -b > "dc=mgcorp,dc=net" contextCSN > > contextCSN: 20101110213409.736943Z#000000#000#000000 > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

15 years, 11 months

RE: Syncrepl and mmr

by Quanah Gibson-Mount

--On Friday, January 31, 2014 8:54 AM -0500 "Borresen, John - 0442 - MITLL" <John.Borresen(a)ll.mit.edu> wrote: > Thanks Quanah > > I'm sure it isn't 100% correct, but I added the following ACL to my > accesslog DB on both MM servers: > > olcAccess: to * by dn="cn=ldapadmin,dc=group42,dc=ldap" read by * none Well, it may not have been this issue, but it definite would become an issue then. ;) > I'm still seeing > gp42-admin3 (MM server1) > Jan 31 08:25:17 gp42-admin3 slapd[3599]: conn=5551 op=2 SRCH > base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 31 > 08:25:17 gp42-admin3 slapd[3599]: conn=5551 op=2 SRCH attr=reqDN reqType > reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 31 08:25:17 > gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with > LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:17 gp42-admin3 slapd[3599]: > do_syncrepl: rid=001 rc -1 retrying Jan 31 08:25:17 gp42-admin3 > slapd[3599]: send_search_entry: conn 5551 ber write failed. Jan 31 > 08:25:17 gp42-admin3 slapd[3599]: conn=5551 fd=32 closed (connection lost > on write) Jan 31 08:25:17 gp42-admin3 slapd[3599]: do_syncrep2: rid=002 > got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:17 > gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying Your masters are unable to talk to each other. You need to determine why. This will take debugging on your part, as I've never seen anything like this before. > gp42-admin4 (MM server2) > Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 fd=101 ACCEPT from > IP=155.34.133.73:10446 (IP=0.0.0.0:389) Jan 31 08:25:19 gp42-admin4 > slapd[26000]: conn=8050 op=0 BIND dn="dc=group42,dc=ldap" method=163 Jan > 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 op=0 RESULT tag=97 err=13 > text=TLS confidentiality required Jan 31 08:25:19 gp42-admin4 > slapd[26000]: conn=8050 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap" > method=128 Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 op=1 > RESULT tag=97 err=13 text=TLS confidentiality required Jan 31 08:25:19 > gp42-admin4 slapd[26000]: conn=8050 op=2 UNBIND > Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 fd=101 closed > Jan 31 08:25:51 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty > syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:51 gp42-admin4 > slapd[26000]: do_syncrepl: rid=001 rc -1 retrying This says that your consumer is connecting without sending a startTLS, while you've configured the master to require startTLS. Clearly you need to either enable startTLS in the syncrepl statement, or not require starttls on your master. --Quanah > -----Original Message----- > From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Sent: Thursday, January 30, 2014 5:10 PM > To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org > Subject: RE: Syncrepl and mmr > > --On Thursday, January 30, 2014 4:51 PM -0500 "Borresen, John - 0442 - > MITLL" <John.Borresen(a)ll.mit.edu> wrote: > >> Well, that was helpful -- lol > > > Looking at your previously supplied configuration, it is clearly apparent > that you provided your replication user no ACLs to read the accesslog DB, > so the error you see makes sense. It can't read the data out of > accesslog, so it throws an error stating that fact. > > --Quanah > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

12 years, 8 months

Re: Disallow ldap operations without start_tls

by Howard Chu

Joshua Schaeffer wrote: >> Michael Ströder wrote: >>> >>> Simply use LDAPS (on separate port). It was never defined in a standard but >>> most >>> LDAP-enabled software supports it. > > I did ended up doing this. I had an application that didn't support start_tls > on an ldap URI, but did support ldaps (or at least I couldn't find a way to > get it to issue start_tls). In OpenLDAP's libldap just use a URL extension: ldap://host/????starttls -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

10 years, 8 months

Re: Cannot re-enable synchronization

by Olivier Nicole

Hi, On Monday I had a major issue, my root CA (for all my encryption) expired, so my LDAP server number 1 became inaccessible. I have a server number 2, running from another root certificate, that did not expire and that was properly replicating from the server number 1, using: syncrepl rid=0 provider=ldaps://ldap server 1/ type=refreshAndPersist bindmethod=simple binddn=cn=Manager,dc=xxx credentials="XXX" searchbase=dc=xxx tls_reqcert=try starttls=yes retry="60 10 300 +" But since I updated the root certificate on server 1, I cannot get the replication. I can still ldapsearch from server 2 to server 1. In the log of server 1 I see a proper connection, but I don't know how to further debug the replication. Best regards, Olivier

10 years, 5 months

openldap-technical search results for query "starttls"