Search results for "starttls" - openldap-technical

Re: STARTTLS vs LDAPS

by Braiam

On Thu, Mar 31, 2022 at 11:46 AM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Thursday, March 31, 2022 12:16 PM -0400 Braiam <braiamp(a)gmail.com> > wrote: > > > What would be the process to modify content on the openldap.org page? > > Depends on the content. The main web pages are in the OpenLDAP Web git > repository. > This repository seems to be the FAQ: https://git.openldap.org/project/faq/-/tree/master/data/item There's a website project too. I couldn't figure out what markup language items on the faq project uses. > --Quanah > -- Braiam

2 years, 7 months

Re: Reg OpenLdap on Ubuntu

by Michael Ströder

Asimananda Mohanty wrote: > Hi Michael, > > Thanks for the reply. > > I tried with "ldapsearch -x -H ldap://ldap-company.com:636 > <http://ldap-company.com:636> -ZZ -D dc=ldap-company,dc=com" and got the > error : > > ber_get_next failed. > ldap_start_tls: Can't contact LDAP server (-1) Sorry should have been ldapsearch -x -H ldap://ldap-company.com -ZZ for LDAP access going to standard port 389 (clear-text) and then using StartTLS extended operation. Another option is to use LDAPS (LDAP over SSL) to separate port: ldapsearch -x -H ldaps://ldap-company.com:636 -ZZ Ciao, Michael. -- Michael Ströder E-Mail: michael(a)stroeder.com http://www.stroeder.com

15 years, 3 months

Re: help with openldap-2.4.29-sasl-2.1.25 bind problems

by luxInteg

On Tuesday 06 March 2012 14:40:17 Dan White wrote: > Make sure you are not hitting this bug in cyrus sasl: > > https://bugzilla.cyrusimap.org/show_bug.cgi?id=3480 > > One way to determine if you are, is to perform your gssapi bind without > ldaps or starttls-over-ldap. I did the test as you suggested. I get the same result whether ldap:// or ldaps:// (i.e whether or not I use tls). Unfortunately I cannot make head nor tail of the link if there is a gssppi-sasl patch or indeed which file in sasl-2.1.25 I need to modify for a fix. I also did a wander on the internet search engines but found nowt of consequence. Advice would be much appreciated. sincerely lux-integ

12 years, 7 months

Re: Problems using OpenLPAP for authentification of users: Client library issues STARTTLS but TLS is not configured

by Jörg Spilker

Dieter Kluenter schrieb: Hello Dieter, > Some Linux distributions have enabled 'ssl start_tls' as default, > please check your /etc/ldap.conf carefully. thanks for your help. Tracing getent passwd, i could see that ldap.conf is first searched in /etc, then in /etc/openldap. And OpenSUSE 11.0 installs /etc/ldap.conf with the pwdutils package and /etc/openldap/ldap.conf with the openldap package. I did all my configuration work in /etc/openldap/ldap.conf. But /etc/ldap.conf contains the line ssl start_tls. I´ve now removed /etc/ldap.conf and the nss_ldap error is gone. I will probably open a bugzilla case because it´s very annoying. Greetings, Jörg

16 years, 4 months

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

by Dieter Kluenter

manu(a)netbsd.org (Emmanuel Dreyfus) writes: > Dieter Kluenter <dieter(a)dkluenter.de> wrote: > >> No, ldapi:/// doesn't present a certificate, but you may establish a >> startTLS session to ldapi:///, in this case the client requests a >> server certificate. > > Let me rephrase: I would like to specify two LDAP servers in ldaprc > - one ldapi:/// with anonymous bind > - one ldaps:// with SASL EXTERNAL for and required server certificate > > It seems to me it is not possible. This can be achieved by ACL's, man slapd.access(5), access to ... by sockname=... access to .. by tls_ssf=... -Dieter -- Dieter Klünter | Systemberatung sip: +49.40.20932173 http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6

14 years, 4 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.

2 years, 7 months

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

13 years, 1 month

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

12 years, 11 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 week, 1 day

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

10 years, 8 months

openldap-technical search results for query "starttls"