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
> olcRemoteAuthTLS: starttls=no tls_reqcert=never
> AD pretty much always requires TLS, but you've turned it off entirely. I
would expect this to fail.
> You either need to use ldaps:// + port 636 & starttls=no
> OR
>ldap:// + port 389
> and starttls=yes
Actually, it this particular case your assumption is incorrect. I setup
another application to authentication to this particular domain controller
without TLS with ldap://dc01.remotedomain.tld:389 and it authenticates with
no problem. I will eventually configure TLS but I'm just trying to keep it
simple for now until I get this working.
Let's say I have this scenario:
Local username: local.user
Local Openldap: localdomain.local
Remote User: remote.user
Remote AD controller: dc01.remotedomain.tld
Remote AD Domain name: remotedomain
RemoteAuthDomainAttribute: o (Organization)
This is the config I'm using in remoteauth.ldif:
dn: cn=module{2},cn=config
objectClass: olcModuleList
cn: module{1}
olcModulePath: /opt/bitnami/openldap/lib/openldap
olcModuleLoad: remoteauth.so
dn: olcOverlay={6}remoteauth,olcDatabase={2}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcRemoteAuthCfg
olcOverlay: {6}remoteauth
olcRemoteAuthDNAttribute: seeAlso
olcRemoteAuthDomainAttribute: o
olcRemoteAuthDefaultRealm: remotedomain
olcRemoteAuthMapping: remotedomain ldap://dc01.remotedomain.tld:389
olcRemoteAuthTLS: starttls=no tls_reqcert=never
olcRemoteAuthRetryCount: 3
This is the remote user config in openldap:
dn: cn=local.user,ou=users,dc=localdomain,dc=local
objectClass: inetOrgPerson
cn: local.user
sn: User
displayName: Local User
givenName: Local
mail: luser(a)somedomain.tld
o: remotedomain:remote.user
seeAlso: cn=Remote user,ou=Users,dc=remotedomain,dc=tld
uid: local.user
userPassword::
This config is not working. Authhentication fails with the following logs.
Please note there is not a single entry for the remote domain which I assume
it means that openldap is not even attempting to reach the remote domain
controller:
.28ab4b96 0x7fe6abfff6c0 conn=1001 op=1 SRCH attr=uid mail displayName
67b738e8.28ac875d 0x7fe6abfff6c0 conn=1001 op=1 SEARCH RESULT tag=101 err=0
qtime=0.000016 etime=0.000161 nentries=1 tex
67b738e8.28b3d836 0x7fe6b0c756c0 conn=1002 fd=13 ACCEPT from
IP=172.16.32.1:40524 (IP=0.0.0.0:1389)
67b738e8.28b6ddb4 0x7fe6abfff6c0 conn=1002 op=0 BIND
dn="cn=local.user,ou=users,dc=localdomain,dc=local" m
67b738e8.28b7c4b3 0x7fe6abfff6c0 conn=1002 op=0 RESULT tag=97 err=49
qtime=0.000028 etime=0.000106 text=
67b738e8.28bd54b7 0x7fe6b0c756c0 conn=1002 fd=13 closed (connection lost)
67b738e8.28bdf386 0x7fe6abfff6c0 conn=1001 fd=12 closed (connection lost)
67b738f7.218e694d 0x7fe6b0c756c0 conn=1003 fd=12 ACCEPT from
IP=172.16.32.1:36998 (IP=0.0.0.0:1389)
67b738f7.218f04b4 0x7fe6abfff6c0 conn=1003 op=0 BIND
dn="cn=ldap-admin,dc=localdomain,dc=local" method=128
67b738f7.218f6645 0x7fe6abfff6c0 conn=1003 op=0 BIND
dn="cn=ldap-admin,dc=localdomain,dc=local" mech=SIMPLE bind_ssf=0
67b738f7.218fd3a9 0x7fe6abfff6c0 conn=1003 op=0 RESULT tag=97 err=0
qtime=0.000008 etime=0.000077 text=
67b738f7.21933140 0x7fe6b0c756c0 conn=1003 op=1 SRCH
base="ou=users,dc=localdomain,dc=local" scope=2 deref=0
filter="(&(uid=dds)(objectClass=inetOrgPerson))"
67b738f7.21936655 0x7fe6b0c756c0 conn=1003 op=1 SRCH attr=uid mail
displayName
67b738f7.21943fac 0x7fe6b0c756c0 conn=1003 op=1 SEARCH RESULT tag=101 err=0
qtime=0.000008 etime=0.000098 nentries=0 tex
67b738f7.2196cf66 0x7fe6abfff6c0 conn=1003 fd=12 closed (connection lost)
Thanks
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
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
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
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>
>
