Search results for "starttls" - openldap-technical

RE: Debugging TLS negotiation failure

by Christopher Paul

> -----Original Message----- > From: terry.lemons(a)dell.com <terry.lemons(a)dell.com> > Sent: Thursday, May 11, 2023 1:10 PM > To: openldap-technical(a)openldap.org > Subject: Re: Debugging TLS negotiation failure > > I'm using a self-signed server certificate, so no CA should be involved. Not > sure if that is causing the problem? Try prepending to your ldapsearch: "LDAPTLS_REQCERT=allow ldapsearch ..." I have also noticed that the errors returned when using StartTLS (TCP/389 "ldap://" prefix URIs) are more informative than when using (non-protocol but widely supported) TCP/636 "ldaps://". Chris Paul | Rex Consulting | https://www.rexconsulting.net

1 year, 6 months

Re: OpenLDAP with SSL connection and search only with wildcard

by Quanah Gibson-Mount

--On Monday, June 15, 2020 7:03 AM +0000 a.leurs(a)consense-gmbh.de wrote: > I thought maybe the size limit is exceeded. > > But when I go back to a ldap connection (instead of a ldaps-connection) > it works fine. Active Directory does things differently than OpenLDAP does. What actions are available over ldaps:/// may not match what can be done with startTLS. You'd need to talk to your AD administrator to determine what actions are allowed on which ports, or for them to adjust your permissions. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 years, 5 months

Re: Antw: [EXT] Re: STARTTLS vs LDAPS

by Quanah Gibson-Mount

--On Friday, April 1, 2022 11:59 AM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > But honestly, you could get the same when setting up SSL incorrectly > (using eNULL or RSA-PSK-NULL-SHA). > Also I think if you require an anonymous bind first, the SSF may prevent > sending actual user passwords unencrypted; right? For your first bit, you can set up the server to only accept certain cipher suites which would not allow such a thing to happen. On the second bit, there is no way to prevent a client that attempts to bind with a dn/password over ldap:/// from sending it in the clear. Regards, Quanah

2 years, 7 months

Re: Antw: [EXT] Re: STARTTLS vs LDAPS

by Quanah Gibson-Mount

--On Thursday, March 31, 2022 9:11 AM +0200 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > I think the point was that you can bind even when not having started TLS > before. Correct. > I don't know whether this can prevent it: > olcSecurity: ssf=0 update_ssf=128 simple_bind=64 There is no way to prevent a client from sending a BIND request to an ldap:/// URI with the DN and password in the clear. Even if you set ssf=1 (server mandates encryption), the most that will happen is that the client will get disconnected, but the DN and password will already have traveled over the network in the clear before the client gets disconnected so anyone sniffing the traffic would have access to it. --Quanah

2 years, 7 months

Re: How do tool verify certs with ldapi:// ?

by Philip Guenther

On Mon, 28 May 2012, Philip Guenther wrote: > If no path is specified (e.g., "ldapi://") then the checking code is > passed a hostname of "localhost". ...which then remaps that to the local hostname (if available) for the actual check. Huh. So for any URI that doesn't specify a host component, be it "ldapi://" or "ldap://" or "ldaps://", the OpenLDAP tools will connect to the default 'host' for the schema, be it "/var/run/ldpai" or "localhost", but for StartTLS they'll match the server cert against the *hostname*. I did not expect that, though I can see how it can be justified. Philip Guenther

12 years, 5 months

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/

10 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>

6 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.

2 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

13 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

6 years, 2 months

openldap-technical search results for query "starttls"