Steinmetz, Robin wrote:
>
> conn=1 op=0 do_extended: unsupported operation "1.3.6.1.4.1.1466.20037"
> conn=1 op=0 RESULT tag=120 err=2 text=unsupported extended operation
This is the StartTLS extended operation for enabling an encrypted channel in
an existing LDAP connection.
It seems your OpenLDAP server installation is not build with SSL/TLS support
or it's not enabled in your server's configuration.
Ciao, Michael.
Hello,
one question to back-meta:
Is it possible to have several ldaps:// URLs as entries, without
client-side authentication? I.e. I just want to configure the CA cert path
and connect to a ldaps repository ('normal' ssl, no starttls).
I saw the section in the man page about idassert-bind, but was not
completely sure they apply to ldaps URLs without authentication.
Best regards,
Peter
--On Monday, June 12, 2023 5:36 PM +0200 cYuSeDfZfb cYuSeDfZfb
<cyusedfzfb(a)gmail.com> wrote:
> Hi Quanah,
>
> Thanks for the swift reponse! I think I do, yes, see, from consumer one:
>
> olcSyncrepl: {0}rid=202
> provider=ldap://master-acc-02.ldap.infra.com:389 bindmethod=simple
> filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory
> Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com"
> schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+"
> starttls=critical tls_reqcert=demand
> olcSyncrepl: {1}rid=201
> provider=ldap://master-acc-01.ldap.infra.com:389 bindmethod=simple
> filter="(objectClass=*)" scope=sub binddn="cn=mirrormode,ou=Directory
> Access,o=infra,c=com" credentials=XYZ searchbase="o=infra,c=com"
> schemachecking=on type=refreshAndPersist retry="60 +" attrs="*,+"
> starttls=critical tls_reqcert=demand
> olcUpdateRef: ldap://provider-acc-02.ldap.infra.com:389
> olcUpdateRef: ldap://provider-acc-01.ldap.infra.com:389
That's syncrepl, not syncprov.
However, the issue could be ACLs. If you use the rootdn for your database
to run the query, can you see the contextCSN value stored in your database
root?
--Quanah
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]
-ben
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
Greetings.
I would have thought (possibly naively) that StartTLS was unnecessary
when connecting to slapd through a unix socket -- the client and the
server are on the same machine, and so don't need to be reassured about
each other's identity. However this seems not to be be the case:
% ldapsearch -LLL -H ldapi://%2Fvar%2Frun%2Fopenldap%2Fldapi
'(uid=foo)'
ldap_sasl_interactive_bind_s: Confidentiality required (13)
additional info: stronger confidentiality required
(same result with ldapi:///).
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
The machine is also listening on ldap://0.0.0.0 and requiring TLS. I
don't see anything in the documentation which seems to suggest I can
have different TLS rules on different interfaces or protocols (ie, ldap:
vs ldapi:) -- am I just missing that?
The /usr/local/etc/ldap.conf doesn't mention TLS, so the TLS requirement
isn't coming in from there.
My practical problem is that I'm trying to get nslcd (on the same
machine) to talk to OpenLDAP locally. If there's a certificate problem
I can sort that out, but I can't help feeling that that ought to be
unnecessary -- that I'm missing something simple.
This is 2.4.45 on FreeBSD.
Best wishes,
Norman
--
Norman Gray : https://nxg.me.uk
Hi Quanah,
Thank you for your response. I figured what you said in your
response, and I have another question about the SASL. I have a ldap testing
server, let's say the url is test.sample.net, and when I run the following
command:
ldapsearch -H ldap://test.sample.net:389 -x -b "" -s base -LLL
supportedSASLMechanisms
it returned:
dn:
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: NTLM
then I run the command:
ldapsearch -H ldap://test.sample.net:389 -Y DIGEST-MD5
then it prompt:
SASL/DIGEST-MD5 authentication started
Please enter your password:
I give a password, then it prompt:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): user not found: no secret in database
so question here, what password it asked here? since it's not asking for a
DN. There could be many credentials here, will the server figure out the
user by the password input?
Thank you!
Peter
On Mon, Jan 6, 2020 at 8:17 PM Quanah Gibson-Mount <quanah(a)symas.com> wrote:
>
>
> --On Tuesday, December 31, 2019 10:44 AM -0500 Peter Sui <peters(a)qnext.com>
>
> wrote:
>
> > if I run:
> > ldapsearch -h ldap.forumsys.com -p 636 -b "" -s base "(objectClass=*)"
> -D
> > "cn=read-only-admin,dc=example,dc=com" -w password -Z
>
> It is not valid to combine startTLS with port 636. Also, you should
> update
> your options to match modern standards.
>
>
> Example against ldaps:///
>
> ldapsearch -H ldaps://ldap.forumsys.com:636
>
> as opposed to
>
> ldapsearch -h ldap.forumsys.com -p 636
>
> Example against ldap:///
>
> ldapsearch -H ldap://ldap.forumsys.com:389
>
> as opposed to
>
> ldapsearch -h ldap.forumsys.com -p 389
>
>
> I would note that the -Z(Z) options are for startTLS (generally against
> port 389). It is not valid to mix startTLS with ldaps:// URIs. You've
> not
> provided any useful information about your setup, so it's not possible to
> give you much help past that.
>
> As for your SASL question, as documented in the ldapsearch man page, you
> provide the SASL Mech as a parameter to the -Y option. For example:
>
> ldapsearch -Y GSSAPI -H ldap://ldap.forumsys.com:389
>
> Regards,
> Quanah
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <http://www.symas.com>
>
On Apr 21, 2010, at 11:54 PM, Siddhartha Jain wrote:
> Hi,
>
> I have setup replication between two primary servers to use TLS.
>
> The config says:
> {0}rid=101 provider=ldap://pldap01.xyz.net binddn="cn=Manager,dc=xyz,dc=net" bindmethod=simple credentials=secret searchbase="dc=xyz,dc=net" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cert=/etc/openldap/cacerts/newcert.pem tls_cacert=/etc/openldap/cacerts/cacert.pem tls_key=/etc/openldap/cacerts/newreq.pem
> {1}rid=102 provider=ldap://pldap02.xyz.net binddn="cn=Manager,dc=xyz,dc=net" bindmethod=simple credentials=secret searchbase="dc=xyz,dc=net" type=refreshOnly interval=00:00:00:10 retry="5 5 300 5" timeout=1 starttls=yes tls_cert=/etc/openldap/cacerts/newcert.pem tls_cacert=/etc/openldap/cacerts/cacert.pem tls_key=/etc/openldap/cacerts/newreq.pem
>
>
> Replication works alright but logs show these lines on pldap01:
> Apr 22 03:47:20 pldap01 slapd[3451]: conn=1089 fd=22 TLS established tls_ssf=256 ssf=256
> Apr 22 03:47:20 pldap01 slapd[3451]: slap_client_connect: URI=ldap://pldap02.xyz.net Warning, ldap_start_tls failed (-11)
>
> And, this on pldap02:
> Apr 22 03:47:40 pldap02 slapd[2564]: conn=1096 fd=26 TLS established tls_ssf=256 ssf=256
> Apr 22 03:47:51 pldap02 slapd[2564]: slap_client_connect: URI=ldap://pldap01.xyz.net Warning, ldap_start_tls failed (-11)
>
>
> To be fair, the certificates are self-signed and don't match the DN but I am assuming that "starttls=yes" forces TLS and the consumers cannot default to plaintext. Right? If yes, does this mean that in syncrepl, tls use is hardcoded to verify certificates and fall back to non-verified TLS session if verification fails? Or, is this configurable meaning can I enforce verification (preferable in production)?
>
>
>
> Thanks,
>
> - Siddhartha
To get clients to use unverified certs, you can add a line to your /etc/ldap/ldap.conf
TLS_REQCERT allow
This tells the client to ignore certificate errors and use TLS without question. Was this what you were looking for? I don't know much else about your other questions, sorry.
-a
On 18.07.2011 18:35, Naga Chaitanya Palle wrote:
> am configuring TLS for syncrepl. But the consumer is not reading any
> updates from the server. Without tls the configuration was working fine.
> Please let me know where I am going wrong
Afaik ldaps is for ssl, not tls, i have working setup with:
provider=ldap://hostname:389
starttls=yes
You can see helpful hints with "loglevel sync" when having sync problems.
--
veiko
