Search results for "starttls" - openldap-technical

Re: Connecting to LDAPS

by Howard Chu

Bernd May wrote: > hi, > > while I can hardly say anything about your code, I think you should read > up on how to use openssl in objective c (I guess thats what you use to > write your app). The code was pretty awful, but there's no need to call OpenSSL directly. ldap_initialize takes care of it. > As a side note, LDAPS is considered deprecated in favour of using > STARTTLS on Port 389 instead, so you might want to read up on that too. > > Regards, > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

11 years

Re: IETF opinion change on "implicit TLS" vs. StartTLS

by Quanah Gibson-Mount

--On Saturday, February 17, 2018 8:58 AM +1000 William Brown <wibrown(a)redhat.com> wrote: >> Personally, I'm all for it. I'd suggest using the above RFC as a >> template >> for one formalizing port 636, so it's finally a documented standard. > > Great! Where do we go from here to get this formalised properly? IETF ldapext is the starting point, I'd assume? Probably worthwhile to bring it up on that list? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

7 years, 9 months

right order mmr-main-DB combined with mmr cn=config

by Stefan Kania

Hello, I'm still working on replication of cn=config. The replication of the main DB is working with delta-syncrepl but I still have problems getting mmr running for cn=config. As I use Ansible to configure it here my question: Is the order of setting up the replication relevant? What I do at the moment: Setting up a basic config for all 4 servers: ----------------------------------------- dn: cn=config objectClass: olcGlobal cn: config olcLogLevel: sync olcLogLevel: stats olcPidFile: /var/symas/run/slapd.pid olcArgsFile: /var/symas/run/slapd.args olcToolThreads: 1 olcServerID: 1 ldap://ldap01.example.net olcServerID: 2 ldap://ldap02.example.net olcServerID: 3 ldap://ldap03.example.net olcServerID: 4 ldap://ldap04.example.net # create cn=config #dn: olcBackend={0}mdb,cn=config #objectClass: olcBackendConfig #olcBackend: {0}mdb dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /opt/symas/lib/openldap olcModuleLoad: back_mdb olcModuleLoad: back_monitor olcModuleLoad: autoca.la olcModuleLoad: otp.la olcModuleLoad: argon2.la olcModuleLoad: syncprov olcModuleLoad: back_monitor olcModuleLoad: accesslog.la include: file:///opt/symas/etc/openldap/schema/core.ldif include: file:///opt/symas/etc/openldap/schema/cosine.ldif include: file:///opt/symas/etc/openldap/schema/nis.ldif include: file:///opt/symas/etc/openldap/schema/inetorgperson.ldif include: file:///opt/symas/etc/openldap/schema/dyngroup.ldif include: file:///opt/symas/etc/openldap/schema/kerberos.openldap.ldif dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcSizeLimit: 500 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to dn="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcPasswordHash: {ARGON2} dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by * break dn: olcDatabase={1}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to dn.subtree="cn=monitor" by dn.exact=cn=admin,cn=config read by dn.exact=cn=admin,dc=example,dc=net read dn: olcDatabase={2}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcmdbConfig olcDatabase: {2}mdb olcSuffix: dc=example,dc=net olcRootDN: cn=admin,dc=example,dc=net olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcSizeLimit: unlimited olcTimeLimit: unlimited olcDbCheckpoint: 512 30 olcDbDirectory: /var/symas/openldap-data olcDbIndex: default eq olcDbIndex: objectClass olcDbIndex: entryUUID olcDbIndex: entryCSN olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: mail pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbIndex: description pres,eq,sub olcDbIndex: title pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbMaxSize: 85899345920 olcAccess: {0} to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by dn.exact=gidNumber=1111+uidNumber=1111,cn=peercred,cn=external,cn=auth manage by dn.exact=uid=ldap-admin,ou=users,dc=example,dc=net write by dn.exact=uid=repl-user,ou=users,dc=example,dc=net read by * break olcAccess: {1}to dn.exact="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read olcAccess: {3} to attrs=userPassword by anonymous auth by self write by * none olcLimits: {0} dn.exact="uid=repl-user,ou=users,dc=example,dc=net" time=unlimited size=unlimited olcLimits: {1} dn.exact="uid=ldap-admin,ou=users,dc=example,dc=net" time=unlimited size=unlimited ----------------------------------------- As you can see serverID is already set to URL-style for all servers ;-) But now I'm not sure, do I have to set up the replication for cn=config on all 4 servers and then set up replication of the main DB on just one of the servers and let it be replicated by the cn=config-replication? Or do I have to set up replication of the main DB on all servers first and then add the replication of cn=config to all servers and only replicate the changes made afterwards? Or do I have to set up the replication of main-DB and replication of cn=config on one server at a time? Or can I do it either way? The testsuit is showing using updateref on the replication of the main-DB do I really need it for mmr? If yes, do I need it for mmr of cn=config? I could not find any example that uses both, mmr for main-DB and mmr for cn=config. here is the order of my set up for cn=config replication: ------------------------ dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov dn: olcDatabase={0}config,cn=config changetype: modify replace: olcSyncRepl olcSyncRepl: rid=1 provider=ldap://ldap01.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes tls_reqcert=allow olcSyncRepl: rid=2 provider=ldap://ldap02.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes tls_reqcert=allow olcSyncRepl: rid=3 provider=ldap://ldap03.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes tls_reqcert=allow olcSyncRepl: rid=4 provider=ldap://ldap04.example.net binddn="cn=admin,cn=config" bindmethod=simple credentials=secret searchbase="cn=config" type=refreshAndPersist retry="5 5 300 20" timeout=1 starttls=yes tls_reqcert=allow - add: olcMultiprovider olcMultiprovider: TRUE ------------------------ And last but not least the set up of the main-DB replication: ----------------------- dn: olcDatabase={2}mdb,cn=config changetype: modify replace: olcSyncrepl olcSyncrepl: rid=102 provider=ldap://ldap02.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes tls_reqcert=allow olcSyncrepl: rid=103 provider=ldap://ldap03.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes tls_reqcert=allow olcSyncrepl: rid=104 provider=ldap://ldap04.example.net bindmethod=simple timeout=0 network-timeout=0 binddn=uid=repl-user,ou=users,dc=example,dc=net credentials=secret filter="(objectclass=*)" searchbase="dc=example,dc=net" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" logbase=cn=accesslog scope=sub schemachecking=off type=refreshAndPersist retry="60 +" syncdata=accesslog keepalive=240:10:30 starttls=yes tls_reqcert=allow - add: olcMultiprovider olcMultiprovider: TRUE ----------------------- This is the ldif for the first server so olcSyncrepl for ldap01.example.net is not configured. On the other servers is the same the own URI has no olcSyncrepl entry. Here olcUpdatRef is not configured. Replication of the main-DB is running. BTW olcUpdateRef is also not configured in the howto of Quanah ;-) So it must be ok :-) Could you please take a look if I did something wrong. I don't know where to look anymore.

3 years, 11 months

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

by Jose Ildefonso Camargo Tolosa

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, 7 months

olcSecurity: tls=1 and olcLocalSSF= : what value should I use?

by Jean-Francois Malouin

Sorry if this is long and naive, I'm making my way with OpenLDAP. I have this annoying problem of local access over ldapi:/// of a configured mdb database using its rootDN. Some details: (I typically use ldapvi to access/modify/edit config as I'm an old wolf with vi hard-wired in my brain!) (Same could be done using native OpenLDAP utilities ldapadd/search/delete/etc: just replace the ldapvi '-h' option with '-H' to specify the protocol/host/port). Binding using EXTERNAL mech over local ldapi:/// works correctly for 'cn=config'. For example, here I made a mod to olcLogLevel for 'cn=config': ~# ldapvi -Y EXTERNAL -h ldapi:/// -b 'cn=config' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 24 entries read add: 0, rename: 0, modify: 1, delete: 0 Action? [yYqQvVebB*rsf+?] y Done. Server logs for slapd show the binding with ssf=71: Sep 6 11:40:52 slapd[677]: conn=48667 fd=17 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi) Sep 6 11:40:52 slapd[677]: conn=48667 op=0 BIND dn="" method=163 Sep 6 11:40:52 slapd[677]: conn=48667 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" Sep 6 11:40:52 slapd[677]: conn=48667 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL sasl_ssf=0 ssf=71 However for the configured mdb database 'olcDatabase={1}mdb,cn=config' I have set olcSecurity: tls=1 to force binding with StartTLS. Here the relevant config piece for it: ('--out' makes ldapvi behave like ldapsearch). ~# ldapvi --out -Y EXTERNAL -h ldapi:/// -b 'olcDatabase={1}mdb,cn=config' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=example,dc=com olcRootDN: cn=admin,dc=example,dc=com olcRootPW: {SSHA}XXXXXXXXXXXXXXXXXXXX olcSecurity: tls=1 ... However this setting prohibits me from binding to it using ldapi:/// with EXTERNAL mech with its rootDN 'cn=admin,dc=example,dc=com' as I then get the message: ~# ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -D 'cn=admin,dc=example,dc=com' -b 'dc=example,dc=com' SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 Confidentiality required (13) Additional information: TLS confidentiality required I can however do a simple bind over StartTLS with the rootDN of the database either over localhost or a remote client: ~# ldapsearch -LLL -Z -x -w xxxxxxxx -H ldap://localhost -D 'cn=admin,dc=example,dc=com' -b 'dc=example,dc=com' slapd logs show: Sep 6 11:54:40 slapd[677]: conn=48699 fd=17 ACCEPT from IP=127.0.0.1:53542 (IP=0.0.0.0:389) Sep 6 11:54:40 slapd[677]: conn=48699 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Sep 6 11:54:40 slapd[677]: conn=48699 op=0 STARTTLS Sep 6 11:54:40 slapd[677]: conn=48699 op=0 RESULT oid= err=0 text= Sep 6 11:54:40 slapd[677]: conn=48699 fd=17 TLS established tls_ssf=256 ssf=256 Sep 6 11:54:40 slapd[677]: conn=48699 op=1 BIND dn="cn=admin,dc=example,dc=com" method=128 Sep 6 11:54:40 slapd[677]: conn=48699 op=1 BIND dn="cn=admin,dc=example,dc=com" mech=SIMPLE ssf=0 So ssf=265... I guess I need to modify either 'olcSecurity: tls=1' in the database config or add/insert the proper value for 'olcLocalSSF=' in the cn=config. What value should I use in order to still force StartTLS over simple binding and allow read/write/modify local access on the ldapi:/// listener. Regards! jf

7 years, 2 months

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

3 years, 8 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

16 years, 4 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

13 years, 8 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

17 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

15 years, 5 months

openldap-technical search results for query "starttls"