Am Tue, 25 Dec 2012 21:27:39 +0530
schrieb anil beniwal <beni.anil(a)gmail.com>:
> Hi
>
> We are having 4 million users to migrate, all data exported from
> oracle to multiple ldif files.
> Imported 1 million till now, took almost 28 hours. and openldap-data
> dir of about 28G.
> openldap version 2.4.33 bdb version 5.1.29 RHEL 6.3 RAM 8G 4 cpu ,
> system is a VM.
>
> Currently running slapadd output
> + /apps/openldap/sbin/slapadd -q -c -w -f
> /apps/openldap/etc/openldap/slapd.conf -l /root/User9.ldif
> bdb_monitor_db_open: monitoring disabled; configure monitor database
> to enable
> . 2.27% eta 21h31m elapsed 29m57s
> spd 1.6 k/s str2entry: invalid value for attributeType
> postalAddress #0 (syntax 1.3.6.1.4.1.1466.115.121.1.41)
> slapadd: could not parse entry (line=394416)
> * 2.81% eta 19h59m elapsed 34m40s spd
> 10.1 k/s
1. There are too many errors like above.
> Its seems to be taking weeks go import whole data.
It takes about 2 - 4 hours in order to slapadd 4 mio.entires, depending
on file system and disk type.
>
> is there any tool or any other approach which we can use to make it
> fast,Or we are going with wrong configuration.
> Or we have to switch to ODS or RHDS
There is no necessity for other tools, just modify the ldif file.
[...]
> DB_CONFIG
>
> set_cachesize 0 4294967295 0
increase cachesize to at least 4GB that is
set_cachesize 4 0 1
[...]
> checkpoint 128 15
I would set checkpointing to 0 15
[...]
> concurrency 100
> index entryCSN eq
> index entryUUID eq
> index
> mail,uid,postalCode,smail,channelType,channelValue,answer,behavName,objectclass,tokenID,type
> eq
> index givenName,sn,city,question,behavValue,cn,extName sub
> index displayName approx
> # Replication Configuration
> overlay syncprov
> syncprov-checkpoint 100 10
> syncprov-sessionlog 100
>
> serverid 1
>
> syncrepl rid=111
> provider=ldap://s01.com
> binddn="cn=Manager,dc=example,dc=com"
> bindmethod=simple
> starttls=yes
> tls_reqcert=allow
> schemachecking=off
> credentials=G00gle#
> searchbase="dc=example,dc=com"
> type=refreshAndPersist
> retry="5 5 300 +"
> interval=00:00:00:10
>
> syncrepl rid=222
> provider=ldap://m04.com
> binddn="cn=Manager,dc=example,dc=com"
> bindmethod=simple
> starttls=yes
> tls_reqcert=allow
> schemachecking=off
> credentials=G00gle#
> searchbase="dc=example,dc=com"
> type=refreshAndPersist
> retry="5 5 300 +"
> interval=00:00:00:10
>
> ######
>
> mirrormode TRUE
>
> directory /apps/openldap/var/openldap-data
>
> overlay unique
> unique_attributes mail
>
> overlay ppolicy
> ppolicy_default "cn=default,ou=pwdPolicy,dc=example,dc=com"
> ppolicy_use_lockout
Please not that overlay declarations follow all database declarations,
modify slapd.conf accordingly.
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95"N
10°08'02,42"E
On Mon, 2017-11-20 at 11:22 +0000, Howard Chu wrote:
> William Brown wrote:
> > On Fri, 2017-11-17 at 08:34 +0100, Michael Ströder wrote:
> > > William Brown wrote:
> > > > Just want to point out there are some security risks with ssf
> > > > settings.
> > > > I have documented these here:
> > > >
> > > > https://fy.blackhats.net.au/blog/html/2016/11/23/the_minssf_tra
> > > > p.ht
> > > > ml
> > >
> > > Nice writeup. I always considered SSF values to be naive and
> > > somewhat
> > > overrated. People expect too much when looking at these numbers -
> > > especially regarding the "strength" of cryptographic algorithms
> > > which
> > > changes over time anyway with new cryptanalysis results coming
> > > up.
> > >
> > > Personally I always try to implement a TLS-is-must policy and
> > > prefer
> > > LDAPS (with correct protocol and ciphersuites configured) over
> > > LDAP/StartTLS to avoid this kind of pre-TLS leakage.
> > > Yes, I deliberately ignore "LDAPS is deprecated". ;-]
> >
> > I agree. If only there was a standards working group that could
> > deprecate startTLS in favour of TLS .... :)
>
> I have to agree as well. On my own servers I also use TLS on other
> "plaintext"
> ports too (such as pop3 and others) that no one has any business
> connecting to
> in plaintext.
Yep. TLS and end-to-end is the way of the future. We need to update our
documents to support this :)
>
> > > Furthermore some LDAP server implementation (IIRC e.g. MS AD)
> > > refuse
> > > to
> > > accept SASL/GSSAPI bind requests sent over TLS-secured channel.
> > > Which
> > > is
> > > IMO also somewhat questionable.
> >
> > Yes, I really agree. While a plain text port exists, data leaks are
> > possible. We should really improve this situation, where we have
> > TLS
> > for all data to prevent these mistakes.
> >
> > I think a big part of the issue is that GSSAPI forces the
> > encryption
> > layer, and can't work via an already encrypted channel. The people
> > I
> > know involved in this space are really resistant to changing this
> > due
> > to the "kerberos centric" nature of the products.
>
> Interesting. Our libldap/liblber works fine with GSSAPI's encryption
> layered
> over TLS and vice versa.
>
Sadly your libldap/liblber is not the only one we have to use. I'm told
that especially AD for IPA trust's is unable to do GSSAPI-over-TLS.
Really, IMO if the SSF is already > 1, then GSSAPI shouldn't install
encryption layer, but you know, I'm not the one who writes the SASL
code ... If you have some contacts in this space, I'm open to
suggestion as to how we can proceed to improve this,
--
Sincerely,
William Brown
Software Engineer
Red Hat, Australia/Brisbane
Hi all, Ben, Dieter,
thank you for your help ...
got it working on ldaps without TLS :-))
we can close that thread
cheers Axel
AXEL GROSSE
Principal Solution Architect, Sales Solution Center, Axway
P: +61-405-995-768
828 Pacific Highway
Gordon, 2072 NSW
agrosse(a)axway.com
http://www.axway.com
-----Original Message-----
From: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb
Sent: Friday, 4 October 2013 6:20 AM
To: openldap-technical(a)openldap.org
Subject: Re: Openldap server with TLS not working
On 2013.10.03 08.22, Axel Grosse wrote:
-----Original Message-----
> From: openldap-technical-bounces(a)OpenLDAP.org
> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Dieter
> Klünter
> Sent: Thursday, 3 October 2013 6:46 PM
> To: openldap-technical(a)openldap.org
> Subject: Re: Openldap server with TLS not working
>
> Am Thu, 3 Oct 2013 00:16:28 +0000
> schrieb Axel Grosse <agrosse(a)axway.com>:
>
>> Hi ben,
>> thanks for the comment.
>> agree with you on TLS usage should be perferred but the client that
>> is connecting is only capable of LDAPS ... he has not implemented TLS
>> Client jet .
>>
>> But can you please take a look to the error I am facing
>>
>> 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:
>>
>> any idea what can cause this ?
>>
>> -----Original Message-----
>> From: openldap-technical-bounces(a)OpenLDAP.org
>> [mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of btb
>> Sent: Wednesday, 2 October 2013 10:57 PM To:
>> openldap-technical(a)openldap.org Subject: Re: Openldap server with TLS
>> not working
>>
>> 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]
>
> You are connnecting to port 389, but s_client is not able to initiate
> a LDAP startTLS session (only SMTP and IMAP), so you have to connect
> ldaps and port 636.
>
> -Dieter
>
> Hi Ben, Dieter
> can we focus on LDAPS because TLS1 is not an option and even if LDAPS > is deprecated I should be able to configure it ..
>
> TLSCACertificateFile /etc/openldap/ssl/VordelCA.crt > TLSCertificateFile /etc/openldap/ssl/VordelDev.crt > TLSCertificateKeyFile /etc/openldap/ssl/VordelDev.key > TLSVerifyClient never > > > are this entries in the slapd.conf sutable for LDAPS ?
> if not whats missing ?
nothing more is required
> start the server with
> /usr/sbin/slapd -h ldap://192.168.30.169:636 -u ldap
/usr/sbin/slapd -h 'ldaps:///' [...]
you must specify ldaps, and you do not need to explicitly specify the port. 636 is the default. see man 8 slapd for details.
Hi!
If that’s the paths of the actual certificates, I could imagine that the user running slapd has no access to /root/ and below. Despite of that I think it’s a bad idea to place certificates for a server into a user’s home directory.
Regards,
Ulrich
From: tmp 2810 <t2810mp(a)gmail.com>
Sent: Tuesday, November 5, 2024 5:07 PM
To: Quanah Gibson-Mount <quanah(a)fast-mail.org>
Cc: openldap-technical(a)openldap.org
Subject: [EXT] Re: Issue with slapd and Google LDAP Integration (lowercase user)
Thats my actual config and the message on the logs is : Unauhtenticated
================================================
uri "ldaps://ldap.google.com/dc=proxy<http://ldap.google.com/dc=proxy>"
suffixmassage "dc=proxy" "dc=example,dc=com"
lastmod off
readonly on
idassert-bind bindmethod=sasl
saslmech=EXTERNAL
tls_reqcert=demand
tls_reqsan=demand
tls_cert=/root/ldapcerts/google_cert.crt
tls_key=/root/ldapcerts/google_cert.key
tls_cacert=/root/ldapcerts/ca/gtsr1.pem
================================================
I've actually been trying all kinds of configurations for the last 2 weeks. Is there a chance that this doesn't work with Google's LDAP? I can't find a single example on the entire internet of someone who has managed to do this whit the LDAP of google.
El mar, 5 nov 2024 a las 12:51, Quanah Gibson-Mount (<quanah(a)fast-mail.org<mailto:quanah@fast-mail.org>>) escribió:
--On Monday, November 4, 2024 8:29 PM -0300 tmp 2810 <t2810mp(a)gmail.com<mailto:t2810mp@gmail.com>>
wrote:
> Once again, I apologize; I ran so many tests that I accidentally copied
> one where the binddn was incorrect.
>
> The target looks more like this:
>
>## example.com<http://example.com>
> uri "ldaps://ldap.google.com/dc=proxy<http://ldap.google.com/dc=proxy>"
> suffixmassage "dc=proxy" "dc=example,dc=com"
> lastmod off
> readonly on
> idassert-bind bindmethod=simple
> binddn="cn=ChiwewDaw"
cn, is by definition, case insensitive. If Google LDAP is forcing case
sensitivity in this attribute, it is gross violation of the LDAP RFCs.
However, having had to interface with it in the past, I don't believe that
is the case. I would generally suspect that this is not the full DN of the
user.
> idassert-bind bindmethod=sasl
> saslmech=EXTERNAL
> tls_reqcert=demand
> tls_reqsan=demand
> starttls=critical
This is not sufficient, please read the man page:
idassert-bind bindmethod=none|simple|sasl [binddn=<simple
DN>]
[credentials=<simple password>] [saslmech=<SASL
mech>]
[secprops=<properties>] [realm=<realm>]
[authcId=<authentication
ID>] [authzId=<authorization ID>]
[authz={native|proxyauthz}]
[mode=<mode>] [flags=<flags>]
[starttls=no|yes|critical]
[tls_cert=<file>] [tls_key=<file>]
[tls_cacert=<file>]
[tls_cacertdir=<path>]
[tls_reqcert=never|allow|try|demand]
[tls_reqsan=never|allow|try|demand]
[tls_cipher_suite=<ciphers>]
[tls_ecname=<names>]
[tls_protocol_min=<version>]
[tls_crlcheck=none|peer|all]
You *must* specify tls_cert, tls_key, and tls_cacert as a part of
idassert-bind as it provides the TLS identity to bind as. In your
configuration for simple bind, tls_cert and tls_key are unnecessary as
you're not doing SASL/EXTERNAL binds.
--Quanah
*Ldap issue*
I tried to search using below commnad and I am getting following error
ldapsearch -x -H ldap://127.0.0.1:389/ -D "cn=manager,ou=system,o=example"
-w secret
*error:*
ldap_bind: Invalid credentials (49)
*My slapd.conf contents is as below:*
database bdb
suffix o=example.com
rootdn cn=manager,ou=system,o=example.com
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
#rootpw {SSHA}JvA5Ovk302pb39afL2yVk9VeAeMNCZAm
# rootpw {crypt}ijFYNcSNctBYg
#access to *
# by * write
access to dn.subtree="o=example.com"
by dn="cn=ldaproot,ou=system,o=example.com" write
by * auth
allow update_anon
access to * by anonymous read
# This allows the ldaproot to extract as much info as possible from the DB
limits dn.exact="cn=ldaproot,ou=system,o=example.com" size=unlimited
time=unlimited
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
# logging setting
loglevel none
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com(a)EXAMPLE.COM
Hello,
I don't clearly understand what you're trying to achieve?
There are two possible ways to do encrypted connections:
- with StartTLS via Port 389 (ldap:// - non-encrypted connections are still
possible, if onfigured in your slapd config)
- with SSL/TLS via 639 (ldaps://)
You can disable/enable each way in your /etc/sysconfig/openldap file.
Please read this: http://www.openldap.org/faq/data/cache/185.html
Bye, Benjamin
On Sat, Aug 27, 2011 at 12:00, pradyumna dash <neomatrixgem(a)gmail.com>wrote:
> List,
>
> It would be great if someone can share doc on TLS with OpenLDAP
> configuration on SLES 11, I tried all the possible ways to make it happen
> but no luck.
>
> I tried with both yast2 and by CA.pl and openssl commands, but no luck,
> When i do netstat .lnap |grep ldap it shows both 636 and 389 port listtening
> to the
> hostname, When i check the logs it shows the destination port its showing
> is 389.
>
> But when i try ldapsearch -x -H ldaps://hostname, its also showing me the
> ldap contents, dont know whats wrong, I also tried to open
> /etc/sysconfig/openldap
> and assigned the LDAP service to run on 127.0.0.1, but if i do so then its
> not able to get the server.
>
> Please help.
>
> Regards,
> Neo
>
--
To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is
to do -- Sartre | Do be do be do -- Sinatra
>> HI all,
>>
>> Taking advantage of the technical list for once and the OpenLDAP
>> "related" questions :-)
>>
>> Anyone messed with ejabberd and OpenLDAP? I'm looking for an XMPP
>> server with the best LDAP support.
>>
>> ejabberd does auth, rosters and vcards but the ability to load a list
>> of hosts/domains from LDAP like you can do
>> with Exim etc. would rule.
>>
>> Any suggestions?
>
>
> i went through this exercise, albeit some time ago, and ultimately settled
> on openfire. others i considered at the time were ejabberd, in.jabberd,
> jabberd2, openfire, prosody, and tigase. none had what i would call
> fantastic ldap support, but openfire came reasonably close, and offered
> other benefits which outweighed the areas in which its ldap implementation
> lacked. most notably, there was only support for ldaps. no starttls. i
> don't recall any providing the ability to read hosts or domains from ldap.
> prosody also seemed to have promise, but at the time, it was too early in
> it's development stages to be used as a daily service.
>
Yeah, I think I've settled on ejabberd as I need multi domains. Quite
surprised you can't
load up hosts via an RDBMS or Directory server.
--
http://www.suretecsystems.com/services/openldap/http://www.surevoip.co.uk
Reformatted:
>>>>>On 03/17/2017 04:27 PM, info(a)gwarband.de wrote:
>>>>>> Hello guys,
>>>>>>
>>>>>> actually I'm trying to configure dovecot to access openldap for
>>>>>> passwordcheck.
>>>>>> All datalinks:
>>>>>>
>>>>>> https://gwarband.de/openldap/dovecot.log
Mar 11 11:18:26 s1 dovecot: auth: Debug: Read auth token secret from /var/run/dovecot/auth-token-secret.dat
Mar 11 11:18:26 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s() failed: Connect error
Mar 11 11:18:26 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s() failed: Connect error
Mar 11 11:18:26 s1 dovecot: auth: Debug: auth client connected (pid=27177)
Mar 11 11:18:33 s1 dovecot: imap-login: Disconnected (no auth attempts in 7 secs): user=<>, rip=149.172.171.148, lip=188.68.37.50, session=<gcDtzHFKbwCVrKuU>
>>>>>> https://gwarband.de/openldap/dovecot-ldap.conf
uris = ldap://ldap.gwarband.de
dn = cn=T000000002,ou=tech,dc=gwarband,dc=de
dnpass = secret
tls = yes
tls_ca_cert_file = /etc/ssl/certs/LetsEncrypt.pem
auth_bind = yes
ldap_version = 3
base = dc=gwarband,dc=de
scope = subtree
user_attrs = mail=maildir:/var/vmail/%{ldap:mailbox},uid=vmail,gid=vmail
user_filter = (&(email=%u)(memberOf=cn=mailbox,ou=application,ou=groups,dc=gwarband,dc=de))
pass_attrs = email=user
pass_filter = (&(email=%u)(memberOf=cn=mailbox,ou=application,ou=groups,dc=gwarband,dc=de))
>>>>>> https://gwarband.de/openldap/openldap.log
Mar 11 10:48:38 s1 slapd[26962]: conn=1001 fd=14 ACCEPT from IP=188.68.37.50:60814 (IP=188.68.37.50:389)
Mar 11 10:48:38 s1 slapd[26962]: conn=1001 op=0 STARTTLS
Mar 11 10:48:38 s1 slapd[26962]: conn=1002 fd=15 ACCEPT from IP=188.68.37.50:60815 (IP=188.68.37.50:389)
Mar 11 10:48:38 s1 slapd[26962]: conn=1002 op=0 STARTTLS
Mar 11 10:49:42 s1 slapd[26962]: connection_get(14): got connid=1001
Mar 11 10:49:42 s1 slapd[26962]: connection_read(14): checking for input on id=1001
Mar 11 10:49:42 s1 slapd[26962]: connection_read(14): TLS accept failure error=-1 id=1001, closing
Mar 11 10:49:42 s1 slapd[26962]: connection_get(15): got connid=1002
Mar 11 10:49:42 s1 slapd[26962]: connection_read(15): checking for input on id=1002
Mar 11 10:49:42 s1 slapd[26962]: connection_read(15): TLS accept failure error=-1 id=1002, closing
Mar 11 10:49:42 s1 slapd[26962]: conn=1001 fd=14 closed (TLS negotiation failure)
Mar 11 10:49:42 s1 slapd[26962]: conn=1002 fd=15 closed (TLS negotiation failure)
>>>>>> https://gwarband.de/openldap/trace.dump
It appears that the client is sending an unbind request after the server
sends a successful starttls response.
>>>>>> The bugreportinglink from openldap:
>>>>>>
>>>>>> http://www.openldap.org/its/index.cgi/Incoming?id=8615
>>>>Am 2017-03-17 22:48, schrieb Tomas Habarta:
>>>>> been running Dovecot 2.2.27 against OpenLDAP 2.4.40 normally over
>>>>> the unix socket on the same machine, but tried over inet with
>>>>> STARTTLS and it's working ok... I would suggest double-checking
>>>>> key/certs setup on OpenLDAP side; for the test I have used LE certs,
>>>>> utilizing following cn=config attributes:
>>>>>
>>>>> olcTLSCertificateKeyFile contains private key
>>>>> olcTLSCertificateFile contains certificate
>>>>> olcTLSCACertificateFile contains both certs (DST Root CA X3
>>>>> and Let's Encrypt Authority X3)
>>>>>
>>>>> and used the same CA file in Dovecot's tls_ca_cert_file
>>>>> Is ldapsearch working ok (-ZZ) and only Dovecot has
>>>>> troubles or ... ?
>>>On 03/18/2017 09:41 AM, info(a)gwarband.de wrote:
>>>> I have also installed LE certs. But nothing helps, I have
>>>> double-checking all certs. ldapsearch with -ZZ works see:
>>>>
>>>> https://gwarband.de/openldap/ldapsearch.log
ldapsearch -x -ZZ -D "cn=admin,dc=gwarband,dc=de" -W "cn=mailbox"
>>>> I have also uploaded the TLSCACertificateFile, maybe I have a failure
>>>> in the merge of the two fiels:
>>>>
>>>> https://gwarband.de/openldap/LetsEncrypt.crt
>>>>
>>>> And also I have uploaded my complete openldap configuration:
>>>>
>>>> https://gwarband.de/openldap/openldap.conf
# Certificate
TLSCACertificateFile /etc/ssl/certs/LetsEncrypt.pem
TLSCertificateFile /etc/ssl/certs/gwarbandDE_LDAP.pem
TLSCertificateKeyFile /etc/ssl/certs/gwarbandDE_LDAP.key
TLSCipherSuite SECURE128:-ARCFOUR-128:-CAMELLIA-128-CBC:-3DES-CBC:-CAMELLIA-128-GCM
TLSProtocolMin 3.1
TLSVerifyClient never
>>>> All other components can work and communicate with my openldap
>>>> server. The components are postfix, openxchange, apache
>>>> (phpldapadmin). My installated software is:
>>>>
>>>> Debian 8
>>>> OpenLDAP 2.4.40
>>>> Dovecot 2.2.13
>>Am 2017-03-18 12:30, schrieb Tomas Habarta:
>>> Well, if ldapsearch works, try to replicate its settings for dovecot
>>> client. It's not obvious what settings ldapsearch uses, have a look
>>> at default client settings in /etc/openldap/ldap.conf, there may be
>>> something set a slightly different way. Also double check permissions
>>> for files used by dovecot, I mean mainly the file listed for
>>> tls_ca_cert_file as dovecot may not have an access for reading... I
>>> cannot see anything downright bad, just posted CA cert (which is ok,
>>> tested) is *.crt and your config mentions *.pem but I consider it's
>>> the same file. Finally, I would recommend to enable debug option for
>>> dovecot's client
>>>
>>> debug_level = -1 (which logs all available) in your dovecot-ldap.conf
>>>
>>> to see what the library reports and work further on that. You can
>>> compare with output from ldapsearch by adding -d-1 switch to it. Hard
>>> to tell more at the moment.
What are the contents of /etc/ldap/ldap.conf?
>On 03/18/2017 01:31 PM, info(a)gwarband.de wrote:
>> I've replicate the settings from ldapsearch to dovecot but no success.
>>
>> To the certificate:
>>
>> Yes it's a *.crt file but I have linked the *.pem file to it and
>> dovecot has read access to that file. I have enabled the debugging in
>> dovecot and have uploaded the output:
>>
>> https://gwarband.de/openldap/dovecot-connect.log
Mar 18 12:43:31 s1 dovecot: auth: Error: ldap_extended_operation_s
Mar 18 12:43:31 s1 dovecot: auth: Error: ldap_extended_operation
Mar 18 12:43:31 s1 dovecot: auth: Error: ldap_connect_to_host: TCP ldap.gwarband.de:389
Mar 18 12:43:31 s1 dovecot: auth: Error: connect success
Mar 18 12:43:31 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s() failed: Connect error
>>
>> And the other site with ldapsearch:
>>
>> https://gwarband.de/openldap/ldapsearch-connect.log
>>
>> I'm pretty sure that there is a problem with the sslhandshaking between
>> openldap and dovecot, but I can't find the source of the problem. One
>> of the steps in the sslhandshaking is not success but in the debugging
>> output I can't find any line with a hit to it.
Am 2017-03-18 14:01, schrieb Tomas Habarta:
> Increase log level on server side as well to see what the server says...
> You may remove anything in TLSCipherSuite for the purpose of testing
> too. Hopefully anyone knowing OpenLDAP internals could help you analyse
> it more deeply.
Your ldapsearch command should reference your ldap.conf config
(ldap.conf(5)), and your dovecot-ldap.conf (assuming that it uses libldap)
will also, but overwrite any settings using dovecot-ldap.conf. Compare any
differences.
Look for permissions problems. Run your ldapsearch command as the same user
dovecot runs under.
Hi.
I have replication setup .
Full replication of o=company, but user for replication (uid=replica,ou=users,o=company) is limited by ACL.
Master configuration:
access to dn.subtree="ou=users,o=company" attrs=userPassword
by anonymous auth
access to dn.base="o=company"
by dn.exact="uid=replica,ou=users,o=company" read
access to dn.subtree="ou=dev,o=company"
by dn.exact="uid=replica,ou=users,o=company" read
#######################################################################
# BDB database definitions
#######################################################################
database hdb
suffix "o=company"
rootdn "cn=ldapadm,o=company"
rootpw password
directory /var/db/openldap-data/o=company
overlay syncprov
Slave configuration:
#######################################################################
# BDB database definitions
#######################################################################
database hdb
suffix "o=company"
rootdn "cn=ldapadm,o=company"
rootpw password
directory /var/db/openldap-data/o=company
syncrepl rid=001
provider=ldap://ro1.devel.ldap.company.ru:389
type=refreshAndPersist
retry="5 10 300 +"
searchbase="o=company"
scope=sub
schemachecking=off
starttls=critical
bindmethod=simple
tls_reqcert=never
binddn="uid=replica,ou=users,o=company"
credentials="password"
Replication works.
When i move object in forbidden by ACL subtree, then no information about this modification goes to the replica server
e.g. operation on master server:
dn: ou=groups2,ou=dev,o=company
changetype: moddn
newrdn: ou=groups2
deleteoldrdn: 1
newsuperior: ou=corp,o=company
This object is not deleted and contextCSN is not updated on the replica.
Is it expected behavior or not?
--
Konstantin Menshikov
Comment below.
-----Original Message-----
From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
Sent: Tuesday, June 25, 2013 12:27 PM
To: Rodney Simioni; openldap-technical(a)openldap.org
Subject: RE: openldap and MozNSS
--On Tuesday, June 25, 2013 11:40 AM -0400 Rodney Simioni <rodney.simioni(a)verio.net> wrote:
> I'm getting further, I went to http://ltb-project.org and downloaded a
> newer version of openldap. BTW, thank you, it's a nice site.
>
> But when I do a 'ldapsearch -d -1 -x -LLL -ZZ', I'm getting "
> unsupported extended operation"
>
> Does anybody have a clue?
I would advise you to specifically use -H <URI> so it is clear what you are connecting to and how. For example, -ZZ requests startTLS, but if you are using an ldaps:// URI, that makes no sense, because they are mutually exclusive.
[[Rod's comment]] I'm using '-H', I'm still getting 'unsupported extended operation', but thanks.
--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
This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio Inc. makes no warranty that this email is error or virus free. Thank you.
