> Hi
>
> Just wondering if the features is supposed to work ? Am I delving into
> experimental code ?
It works as intended. The error message you receive is quite
self-explanatory: AD wants a successful bind, and you're requesting
bindmethod=none (i.e. bind with empty DN). You may want to try
bindmethod=simple
p.
>> -----Original Message-----
>> From: Alex Samad - Yieldbroker
>> Sent: Thursday, 29 March 2012 9:28 AM
>> To: openldap-technical(a)openldap.org
>> Subject: RE: problem with ldap backend
>>
>> Hi
>>
>> I have progressed a little bit further
>>
>> I have stopped using olcdbaclbind and started to use
>>
>> olcDbIDAssertAuthzFrom: "*"
>> olcDbIDAssertBind: bindmethod=none authzId="CN=ad
>> readonly,OU=Services ,DC= xyz,DC=com" credentials="secret" starttls=no
>>
>>
>> but I get this
>>
>> text: 000004DC: LdapErr: DSID-0C0906E8, comment: In order to perform
>> this
>> ope ration a successful bind must be completed on the connection., data
>> 0,
>> v1db1
>>
>>
>> I am able to ldapsearch with these credentials, I also tried change
>> bindmethod to simple, but same error
>>
>> How do I turn on debug for the ldap backend ?
>>
>> Any one have any ideas on how to make this work ?
>>
>>
>> Alex
>>
>>
>> > -----Original Message-----
>> > From: openldap-technical-bounces(a)OpenLDAP.org
>> > [mailto:openldap-technical- bounces(a)OpenLDAP.org] On Behalf Of Alex
>> > Samad - Yieldbroker
>> > Sent: Wednesday, 28 March 2012 1:58 PM
>> > To: openldap-technical(a)openldap.org
>> > Subject: problem with ldap backend
>> >
>> > Hi
>> >
>> > I am trying to setup a connection from openldap to MS AD
>> >
>> > I am using this
>> >
>> > dn: olcDatabase={3}ldap
>> > objectClass: olcDatabaseConfig
>> > objectClass: olcLDAPConfig
>> > olcDatabase: {3}ldap
>> > olcSuffix: dc=xyz,dc=com
>> > olcAccess: {0}to dn.base="" by * read
>> > olcAccess: {1}to dn.base="cn=Subschema" by * read
>> > olcAccess: {2}to * by self write by users read by anonymous auth
>> > olcReadOnly: TRUE
>> > olcRootDN:
>> gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
>> > olcSizeLimit: 500
>> > olcDbURI: "ldap://dc101. xyz.com ldap://dc201. xyz.com"
>> > olcDbRebindAsUser: TRUE
>> > olcDbChaseReferrals: TRUE
>> >
>> >
>> > This works fine when I pass a bind DN.
>> >
>> > I would like to convert this to allow anon access to ldap, which does
>> > a user bind to MS AD so I added this
>> >
>> >
>> > olcdbaclbind: bindmethod=simple binddn="CN=ad readonly,OU= xyz,DC=
>> > xyz,DC=com" credentials="secret" starttls=no
>> >
>> > but it is not working, I can not make a anon search request, they
>> > retrieve any thing frome the MSAD ldap server.
>> >
>> > Thanks
>> >
>> >
>> >
>> >
>
>
>
>
Hi,
On Thu, 3 Oct 2013, Axel Grosse wrote:
> 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 ?
>
> start the server with
> /usr/sbin/slapd -h ldap://192.168.30.169:636 -u ldap
in that case you need ldaps:// and not ldap:/ in the url. Now you are starting plaintext ldap on port 636.
Please just start slapd without any host specification and test using openssl s_client connect target:636
After that works start trimming down the ports slapd binds to.
Greetings
Christian
>
>
> thanks a lot
> 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 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 ?
>>
>>
>> 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: 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
>
>
--
Christian Kratzer CK Software GmbH
Email: ck(a)cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer
Hello Sebastian,
Sebastian Reinhardt <snr(a)lmv-hartmannsdorf.de> writes:
> Dieter Kluenter schrieb:
>> Hello Sebastian,
>>
>> Sebastian Reinhardt <snr(a)lmv-hartmannsdorf.de> writes:
>>
>>
>>> Dieter Kluenter schrieb:
>>>
>>>> Sebastian Reinhardt <snr(a)lmv-hartmannsdorf.de> writes:
[...]
>>> Now I have set the loglevel to "3" and I get the following output if I
>>> try to login (still fails):
>>>
>>
>> loglevel is != debug level, man slapd(8), run slapd -d3
>>
>>> -------------------/var/log/messages---------------------------------------------------------------------
>>>
>>
>> [...]
>>
>>> Feb 25 16:41:49 lmvserver kdm: :0[11544]: nss_ldap: could not search
>>> LDAP server - Server is unavailable
>>>
>> [...]
>>
>>
>>> Feb 25 16:41:49 lmvserver kdm: :0[11544]: pam_ldap: ldap_starttls_s:
>>> Connect error
>>> -------------------/var/log/messages---------------------------------------------------------------------
>>>
>>> I am not sure, if this is an configuration or certificate error? Do You
>>> understand this output above?
>>>
>>
>> The clients are nss_ldap and pam_ldap, check the clients
>> configuration for starttls parameters.
>> With debug level 3 you should see something like
[...]
> Sorry. I had not configured the pam_ldap (/etc/ldap.conf) config file
> properly. The certifikate entries were missing.
>
> Here is my /etc/ldap.conf:
> -------------------/etc/ldap.conf-------------------------------------------
> host 127.0.0.1
This Hostadress is probabely not the certifcate DN
> base dc=lmv,dc=lmv
> #uri ldap://127.0.0.1/
> #uri ldaps://127.0.0.1/
> #uri ldapi://%2fvar%2frun%2fldapi_sock/
> #ldap_version 3
> #binddn cn=proxyuser,dc=example,dc=com
> #bindpw secret
> rootbinddn cn=ldaproot,dc=lmv,dc=lmv
To bind as rootdn is not a good idea.
[...]
> #ssl on
> sslpath /etc/openldap/
although it is not the base of your problem, omit sslpath
> ssl start_tls
> ldap_version 3
> pam_filter objectclass=posixAccount
> nss_base_passwd ou=users,dc=lmv,dc=lmv
> nss_base_shadow ou=users,dc=lmv,dc=lmv
> nss_base_group ou=groups,dc=lmv,dc=lmv
> tls_checkpeer yes
> #ssl on
> tls_cacertfile /etc/openldap/cacert.pem
> tls_cacertdir /etc/openldap/
omit tls_cacertdir
> #tls_randfile /var/run/egd-pool
> #tls_ciphers TLSv1
> tls_cert /etc/openldap/clientcert_201.pem
> tls_key /etc/openldap/clientkey_201.pem
> #sasl_secprops maxssf=0
> #krb5_ccname FILE:/etc/.ldapcache
> -------------------/etc/ldap.conf-------------------------------------------
>
> And also my /etc/openldap/ldap.conf:
> -------------------/etc/openldap/ldap.conf-----------------------------
> TLS_CACERT /etc/openldap/cacert.pem
> TLS_CERT /etc/openldap/clientcert_201.pem
> TLS_KEY /etc/openldap/clientkey_201.pem
> TLS_REQCERT demand
> host 127.0.0.1
[...]
>
> TLS: can't accept.
> connection_read(14): TLS accept failure error=-1 id=33, closing
[...]
> What is wrong? The certificate is not accepted? Is the certificae not ok?
I presume the certificate DN is not in conformance with the called URI
To test this, just do a ldapsearch with a simple bind and starttls,
that is ldapsearch -x -D some DN -w passwd -ZZ ldap://my.remote.host
-b "" -s base +
You may do a strace on this process, that is "strace -o /tmp/myfile.txt
ldapsearch ...."
As you use a host certificate, on a successful session ou may see
something like
TLS trace: SSL_accept:SSLv3 flush data
connection_read(19): unable to get TLS client DN, error=49 id=8
But despite a error 49, the session is established.
-Dieter
--
Dieter Klünter | Systemberatung
http://www.dpunkt.de/buecher/2104.html
sip: +49.180.1555.7770535
GPG Key ID:8EF7B6C6
53°08'09,95"N
10°08'02,42"E
The problem is solved,
in my configuration I wrote:
----------------
dn: olcDatabase={2}mdb,cn=config
objectClass: olcmdbConfig
----------------
but with 2.6 ldapmodify is looking for:
objectClass: olcMdbConfig
so it must be a capital "M". With a small "m" you will get "err=53"
"server unwilling to perform"
@Quanah: In your blog about mmr it's also with a small "m", maybe you
can change it.
Am 07.12.21 um 16:52 schrieb Stefan Kania:
> Hi to all,
>
> is it now save to use mmr of cn=config with OpenLDAP 2.6? I got it
> running with 4 server.
> I'm installing all 4 server with Ansible so I created a basic configuration:
> ------------------
> 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: 4
>
> dn: cn=schema,cn=config
> objectClass: olcSchemaConfig
> cn: schema
>
> # Read all needed schema from variable in default/main.yml
> 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
>
> # Read all modules from variable in default/main.yml
> 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
>
> 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: olcBackend={0}mdb,cn=config
> objectClass: olcBackendConfig
> olcBackend: {0}mdb
>
> 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
>
> ------------------
> The "ServerID" is different for every server, every thing else is
> identical.
>
> Then I created a file to change the serverID:
> ------------------
> dn: cn=config
> changetype: modify
> replace: olcServerID
> olcServerID: 1 ldap://ldap01.example.net
> olcServerID: 2 ldap://ldap02.example.net
> olcServerID: 3 ldap://ldap03.example.net
> olcServerID: 4 ldap://ldap04.example.net
> ------------------
>
> and a file to configure the 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
> 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
> 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
> 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
> -
> add: olcMirrorMode
> olcMirrorMode: TRUE
> ------------------
>
> When I configure the server via Ansible (everything in one playbook) the
> replication of cn=config is not working. When I only do the basic
> configuration via Ansible and then add the change of serverID and then
> the replication of cn=config step by step on every single server:
> -------------
> ldapmodify -Y EXTERNAL -H ldapi:/// -f serverid.ldif
> ldapmodify -Y EXTERNAL -H ldapi:/// -f repl_config.ldif
> -------------
> everything is fine. The two files "serverid.ldif" and "repl_config.ldif"
> are the files Ansible created, so the content of the file is the same.
>
> Can it be, that the problem is because Ansible first sets all the
> ServerIDs on all servers and then configure the replication of cn=config
> on all servers?
>
>
> For setting up the configuration I took:
> https://www.openldap.org/devel/admin/replication.html
> Starting at 18.3.3
>
> What I don't understand: Do I realy have to put all Servers in the
> replication, even the server it self? So do I realy have to add on
> Server-01, the Server "server-01, server-02, server-03 ,server-04" to
> the replication? Dosn't it mean that server-01 is replicating to it
> self? If it's correct, can someone explain why? O did I understud
> something wrong on the webpage?
>
> Stefan
>
>
>
>
>
--
Stefan Kania
Landweg 13
25693 St. Michaelisdonn
Signieren jeder E-Mail hilft Spam zu reduzieren und schützt Ihre
Privatsphäre. Ein kostenfreies Zertifikat erhalten Sie unter
https://www.dgn.de/dgncert/index.html
Download der root-Zertifikate: https://www.dgn.de/dgncert/downloads.html
Hi there. I've another problem with TLS slapd and samba.
For each operation with slapd (ldapsearch -x -ZZ, getent, or samba tls
connection) I receive from slapd:
Aug 2 11:31:05 PDC slapd[1709]: connection_read(23): unable to get TLS
client DN, error=49 id=4
What's the problem? My certificate?
Certificate's creation is:
/usr/lib/ssl/misc/CA.pl -newca
openssl req -newkey rsa:1024 -nodes -keyout key.pem -out newreq.pem
/usr/lib/ssl/misc/CA.pl -sign
Then another problem is when I start slapd on the boot, after slapd
startup, samba , that try to connect to ldap with tls, could not connect
to slapd and give me:
2009/08/01 17:45:15, 10]
lib/ldap_debug_handler.c:samba_ldap_log_print_fn(26)
[LDAP] ldap_parse_extended_result
[2009/08/01 17:45:15, 10]
lib/ldap_debug_handler.c:samba_ldap_log_print_fn(26)
[LDAP] ldap_parse_result
[2009/08/01 17:45:15, 10]
lib/ldap_debug_handler.c:samba_ldap_log_print_fn(26)
[LDAP] ldap_msgfree
[2009/08/01 17:45:15, 10]
lib/ldap_debug_handler.c:samba_ldap_log_print_fn(26)
[LDAP] TLS: can't connect: Error in the push function..
[2009/08/01 17:45:15, 0] lib/smbldap.c:smb_ldap_start_tls(596)
[2009/08/01 17:45:15, 10]
lib/ldap_debug_handler.c:samba_ldap_log_print_fn(26)
[LDAP] ldap_err2string
Failed to issue the StartTLS instruction: Connect error
This only if I put in slapd.conf TLSClientVerify demand, if I put
TLSClientVerify never, samba connect to it, under TLS without problems.
Another issue is that, if i run slapd on startup and run samba after
login with /etc/init.d/samba start, it makes the connection successfully
without error. In the same script of slapd boot I set an "ldapsearch -x
-ZZ -d -1" I receive:
TLS: can't connect: Error in the push function.. the same of samba.
Anyone has ideas? The problem is in certificates?
thanks in advance
Am 30.01.2017 um 21:49 schrieb Quanah Gibson-Mount:
> For this testing call, we particularly need folks to test OpenLDAP with startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series and with the 1.1 series).
Hello,
nearly a week I now run that release without any noise.
It's compiled against openssl-1.1.0d and run on a ipv6 only host.
but: it's a small private server, no load, no replication...
One point is worth to mention:
I exposed the server also on port 443 and did a scan with ssllabs.com.
While I'm pretty sure to configure certificates properly,
ssllabs proof, the server deliver not only certificate and intermediate
but also the root as part of the initial SSL handshake.
my TLS settings are:
TLSCertificateFile /path/to/cert.pem
TLSCertificateKeyFile /path/to/key.pem
TLSCACertificateFile /path/to/intermediate.pem
TLSCACertificatePath /path/to/an/empty/directory/
TLSProtocolMin 3.3
$ openssl x509 -noout -in /path/to/cert.pem -issuer -subject
issuer= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
subject= /CN=ldap-test.example.org
$openssl x509 -noout -in /path/to/intermediate.pem -issuer -subject
issuer= /O=Digital Signature Trust Co./CN=DST Root CA X3
subject= /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
a manual test using openssl s_client also proof the root is wrongly delivered:
$ echo | openssl11 s_client -connect ldap-test.example.org:443 -showcerts
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = ldap-test.example.org
verify return:1
---
Certificate chain
...
Ultimate features would be OCSP stapling ( OK, no ldap client currently implement that )
and setting ecdh_curve via SSL_CTX_set1_curves_list
Andreas
On Thu, Jun 28, 2012 at 2:09 AM, Todd Stein <todd.stein(a)openx.org> wrote:
> Hi,
>
> I have a provider server and five consumer servers, all of which have the
> memberOf overlay configured:
>
> overlay memberof
> memberof-group-oc groupOfUniqueNames
> memberof-member-ad uniqueMember
> memberof-refint true
> memberof-dangling ignore
>
> syncrepl rid=005
> provider=ldap://<server>:389
> type=refreshAndPersist
> interval=00:00:05:00
> retry="60 10 600 +"
> searchbase="dc=<removed>,dc=<removed>"
> filter="(objectClass=*)"
> scope=sub
> attrs="*"
> schemachecking=off
> starttls=no
> bindmethod=simple
> binddn="cn=replica,dc=<removed>,dc=<removed>"
> credentials=<removed>
>
> When I bring a new replica online, it appears that entries are replicated
> in the order that they were created on the provider server which produces
> many "memberof_value_modify failed err=32" messages in the log, and
> incomplete memberOf data. To get around this, I wrote a script which
> empties all groups prior to replication, and then recreates the memberships
> after the initial replication. This seems to work, but is hardly ideal. Is
> there a "more correct" way of replicating memberOf values without
> manipulating my provider each time I bring up a new consumer?
>
>
I'm facing the same problem with OpenLDAP 2.4.33. Does anyone have any idea
on how to deal with this problem?
Thanks in advance
Marco
On 04/02/2013 20:08, Quanah Gibson-Mount wrote:
> --On Monday, February 04, 2013 9:16 AM +0200 Chris
> <chris(a)flamengro.co.za> wrote:
>
>> Thank you for the link. I have downloaded the newest version.
>
> Please keep replies on the list.
>
>> I get the following error message in my messages file when I start slapd
>>
>> Feb 4 09:15:53 ibm-01 slapd[25637]: [INFO] Using /etc/default/slapd for
>> configuration
>> Feb 4 09:15:53 ibm-01 slapd[25642]: [INFO] Launching OpenLDAP
>> configuration test...
>> Feb 4 09:15:53 ibm-01 nslcd[18834]: [a6c6dc] failed to bind to LDAP
>> server ldaps://ibm-01: Can't contact LDAP server
>
>> ldpasearch gives the following results
>>
>> ldapsearch -x -Z -b'dc=flamengro,dc=co,dc=za' uid=izak
>> ldap_start_tls: Protocol error (2)
>> additional info: unsupported extended operation
>
> Are you using startTLS (extended operation) or ldaps? These are two
> different things, and yet it seems you are trying to use both.
>
> --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
>
I ask forgiveness for replying to your email, I have just press reply
and did not looked at the address.
What I try to do is login from different machines on the network using
openldap. I have tried to set it up as I have read, maybe I must just go
over it again. Sorry for wasting your time.
Hi,
I have a particular object in my LDAP database that is failing to
replicate (using syncrepl between two slapd's running 2.4.31-1+nmu2 on
Debian Wheezy), despite other objects succeeding to replicate. I'm not
using a 'filter' configuration in my olcSyncrepl configuration that
might exclude this particular object, and I've checked that the binddn
I'm using has permission to see this object all the attributes of the
object that isn't replicating.
The (sanitised) configuration on the consumer is:
dn: olcDatabase={1}hdb,cn=config
olcSyncrepl: {0}rid=104 provider=ldap://producer.example.com
bindmethod=simple
binddn="uid=replicator,ou=pseudoaccounts,dc=example,dc=com"
credentials="..."
searchbase="dc=example,dc=com" logbase="cn=accesslog" logfilter="(&
(objectClass=auditWriteObject)(reqResult=0))" schemachecking=off
type=refreshAndPersist
retry="60 +" syncdata=accesslog starttls=critical tls_reqcert=demand
On the producer the overlay configuration for the database being
replicated is:
dn: olcOverlay={1}syncprov,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {1}syncprov
olcSpCheckpoint: 100 600
olcSpSessionlog: 100
olcSpNoPresent: TRUE
If I follow the sanitising I did in the above, then the failing object
would be uid=replicationcheck,ou=pseudoaccounts,dc=example,dc=com, and a
successfully replicated object would be
uid=geoffc,ou=People,dc=example,dc=com.
I've stopped slapd on the consumer and deleted all the /var/lib/ldap/
database files, to force re-replication. I get the same symptoms, this
one object doesn't replicate, but lots of other objects do replicate.
Any tips on how to further debug this?
Many thanks,
--
Geoff Crompton, System Administrator
T: +61 (0)3 9348 7138
Trinity College | University of Melbourne | Royal Parade, Parkville |
Victoria 3052, Australia
www.trinity.unimelb.edu.au