Search results for "starttls" - openldap-technical

Re: LDAP and SSL

by Dan White

On 26/09/11 10:18 -0400, criderkevin(a)aol.com wrote: > >I'm struggling with the need for SSL... > >We will use our new LDAP for apps. These servers are all locally housed so >each app server will talk to the LDAP server over our network. (why) Would >we need SSL? > >What about for mail services? It seems to me that our mail server would >also talk directly to the LDAP server...what am I missing here that >dictates the use of SSL with LDAP? I could see if one had their LDAP open >to be accessible direct access from off-network. Perhaps SSL is used >simply as a means to authenitcate? If you're performing TLS authentication, using client certificates, via STARTTLS, then using X.509 provides for a strong authentication mechanism using SASL (EXTERNAL). That's the one benefit that I know of beyond the obvious session based encryption that you obtain using certificates. -- Dan White

13 years, 1 month

Re: syncrepl mirrormode with SSL/TLS issues

by Quanah Gibson-Mount

--On Wednesday, January 09, 2013 6:19 PM -0600 Houston Ray <houston.r.hopkins(a)gmail.com> wrote: > > > I am attempting to move my sycrepl with mirrormode configuration over to > TLS using LDAPS (not starttls) and running into problems. > > > Multimaster setup (2 servers) behind a VIP > > both RHEL 6.3 Problem 1 > Openldap 2.4.23-26 Problem 2 Don't use RH's builds of OpenLDAP, they link to their broken MozNSS stuff. Use a current release of OpenLDAP. Once you've done that, then see what progress you can make. I would note you can get useful OpenLDAP builds for RHEL from <http://ltb-project.org/wiki/download#openldap> They link to OpenSSL rather than MozNSS, and are current. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

11 years, 10 months

Re: TLS, integrity and root DSE

by Quanah Gibson-Mount

--On Wednesday, July 24, 2013 4:08 PM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > Hi! > > When trying to require integrity for LDAP connections by specifying > "ssf=1" in Security, I have a problem with Perl where the cat bites its > tail: > > It's recommended to query the root DSE for TLS extension before trying to > use TLS like this: > > my $dse = $ldap->root_dse(); > > if ($dse->supported_extension(LDAP_EXTENSION_START_TLS)) { > my $msg = $ldap->start_tls('verify' => 'require', > 'capath' => '/etc/ssl/certs'); > ... Personally, I just always try to startTLS regardless. Then you can decide whether or not you wish to continue after that point based on whether or not it succeeds or fails. --Quanha -- Quanah Gibson-Mount Lead Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

11 years, 3 months

Re: Openldap server with TLS not working

by Michael Ströder

btb wrote: > On 2013.10.02 07.29, Axel Grosse wrote: > >> when I test on the server itself .. >> openssl s_client -connect 192.168.30.169:389 -showcerts -CAfile >> ./ssl/VordelCA.crt >> CONNECTED(00000003) >> 710:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake >> failure:s23_lib.c:188: > > ldaps [port 636] is deprecated. > use starttls with the standard port [389]. > to test, just use ldapsearch [see the reference to -Z in the man page] This is nonsense. From a security perspective there's no reason not to use LDAPS. Well, I'd even recommend LDAPS since SSL/TLS handshake is done *before* a client can send an LDAP PDU. With my deployments I always enable both but prefer LDAPS. I cannot imagine that any LDAP server or client will ever drop support for LDAPS since this would immediately rule out this implementation from broader market share. Ciao, Michael.

11 years, 1 month

Re: ldapi and StartTLS

by Richard Gray

On 2018-07-12 06:52, Norman Gray wrote: > What am I misunderstanding? > > In the slapd.ldif I have: > > dn: cn=config > objectClass: olcGlobal > cn: config > olcArgsFile: /var/run/openldap/slapd.args > olcPidFile: /var/run/openldap/slapd.pid > olcSecurity: ssf=128 > olcTLSCertificateFile: /usr/local/etc/openldap/certs/XXX.crt > olcTLSCertificateKeyFile: /usr/local/etc/openldap/certs/XXX.key > olcTLSCACertificateFile: /usr/local/etc/openldap/certs/FOO > olcLogLevel: 0 Have a look at 'olcLocalSSF' in slapd-config(5), which lets you set the security strength factor for local (i.e. ldapi://) sessions. It defaults to 71, which is likely why you're seeing that error message. Personally, I bump it up to 256, to match the ssf=256 I have set in the olcSecurity attribute on cn=config. -- Richard Gray _____________________________________________________________________________ This email has been filtered by SMX. For more info visit http://smxemail.com _____________________________________________________________________________

6 years, 4 months

Re: OpenLDAP self-signed certificates issue

by Michael Ströder

Ryan Tandy 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. LDAPS on separate port was not formally defined in a RFC. But there's nothing wrong using it. Personally I even prefer LDAPS since you can then make sure that the client has to establish a TLS connection before sending any LDAP PDU. > But if you really need ldaps, then edit > /etc/default/slapd, add ldaps:/// to the SLAPD_SERVICES line, and restart slapd. Yes. Ciao, Michael.

10 years, 2 months

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

by Dieter Kluenter

Hi, Jörg Spilker <js(a)jetsys.de> writes: > Hi, > > well, i don´t know what i´m doing wrong. I just want to authenticate > unix and windows users against OpenLDAP Database. I followed some howtos > to setup openldap, winbind etc. and nearly everything seems just fine. > But authenticating unix users finally doesn´t work. I´ve attached the > syslog output. START TLS extension not supportet. This is true, as i > haven´t configured OpenLPAP for TLS. But my LDAP client configuration > doesn´t specify an LDAPS URL. So what´s going wrong? Some Linux distributions have enabled 'ssl start_tls' as default, please check your /etc/ldap.conf carefully. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6 53°08'09,95"N 10°08'02,42"E

16 years, 4 months

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

by Dieter Kluenter

manu(a)netbsd.org (Emmanuel Dreyfus) writes: > Hello > > I would like to setup a ldaprc so that an application uses: > - a localhost-base slapd without authentification (just relying on > filesystem permission on the slapd socket) > - if it is not available, a remote slapd, authenticating using client > certificate > > Here is the desired ldaprc: > BASE dc=example,dc=net > URI ldapi:/// ldaps://ldap.example.net > TLS_CACERT /etc/openssl/ca.crt > TLS_CERT /etc/openssl/host.crt > TLS_KEY /etc/openssl/host.key > SASL_MECH EXTERNAL > TLS_REQCERT demand > > Of course it will not work, as the ldapi:/// connection will present a > certificate. I have the feeling the setup I am looking for cannot be > configured. Is that right? 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. -Dieter -- Dieter Klünter | Systemberatung sip: +49.40.20932173 http://www.dpunkt.de/buecher/2104.html GPG Key ID:8EF7B6C6

14 years, 4 months

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

by Jose Ildefonso Camargo Tolosa

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 >

13 years, 6 months

problem with ldap backend

by Alex Samad - Yieldbroker

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

12 years, 7 months

openldap-technical search results for query "starttls"