Hi,
On Monday I had a major issue, my root CA (for all my encryption)
expired, so my LDAP server number 1 became inaccessible.
I have a server number 2, running from another root certificate, that
did not expire and that was properly replicating from the server
number 1, using:
syncrepl rid=0
provider=ldaps://ldap server 1/
type=refreshAndPersist
bindmethod=simple
binddn=cn=Manager,dc=xxx
credentials="XXX"
searchbase=dc=xxx
tls_reqcert=try
starttls=yes
retry="60 10 300 +"
But since I updated the root certificate on server 1, I cannot get the
replication.
I can still ldapsearch from server 2 to server 1.
In the log of server 1 I see a proper connection, but I don't know how
to further debug the replication.
Best regards,
Olivier
Michael Ströder wrote:
> => StartTLS over LDAP is undefined and probably every API should simple refuse
> it at all or accept any server cert. In both cases the underlying LDAPI
> channel is fully trusted anyway.
>
> If the client really would like to implement an additional *security* check
> that a rogue attacker did not trick the client to connect to another Unix
> domain socket (MITM service) checking the server's identity by matching
> "localhost" also does not make sense to me.
A rough idea:
GeneralName can be an URI. So the LDAPI URI should be in subjectAltName
extension and checked by the client (if some name has to be checked at all).
Anything else is nonsense.
Ciao, Michael.
On Mon, 5 Nov 2012, Admus wrote:
...
> The output of `gnutls-cli --print-cert -p 636 ldap1.example.com` is:
>
> - The hostname in the certificate matches 'ldap1.example.com'.
> - Peer's certificate issuer is unknown
> - Peer's certificate is NOT trusted
In order to verify the server's certificate, root CA that's 'above' the
server's cert needs to be configured as a trusted CA for the client.
For OpenSSL, that's done by placing it in the file designated by the
TLS_CACERT ldap.conf option, or in the directory designated by the
TLS_CACERTDIR ldap.conf option with the correct hashed filename.
The ldap.conf(5) manpage indicates that the latter is ignored for GnuTLS,
so presumably you just have to place the trusted root certificate(s) in a
single file and point TLS_CACERT at that, in whatever format GnuTLS uses.
Philip Guenther
Am Mon, 7 Oct 2013 10:37:29 +0200
schrieb felas <felas85(a)gmail.com>:
> Hi i have installed OpenLdap in local, and i try to enabled the TLS
> Auth. I follow this guide
> https://help.ubuntu.com/12.04/serverguide/openldap-server.html#openldap-ser…
> but when i try to auth with my program(in Eclipse) i have this error:
>
> Unable to connect to server 192.168.1.156:636 (91) Connect Error
> java.net.ConnectException: Connection Refused
If you followed the provided guide, you only started slapd on port 389
and local socket. Modify your program to initiate startTLS on port 389.
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95"N
10°08'02,42"E
Howard Chu skrev, on 30-01-2008 12:12:
[...]
>> FWIW your rhl5 src rpm rebuilt on Fedora FC6 has no problems with ldaps,
>> ldap starttls or ldapi; it does everything perfectly normally -
>> otherwise I'd have reacted negatively far sooner.
>
> Probably because it still uses OpenSSL, and not GnuTLS like Debian does.
Ah. Indeed. I just knew there had to be one more reason why I don't use
Debian if I can avoid it.
Then Buchan will have to redesign his spec and rpms to add GnuTLS to Red
Hat and use that, which should be fun. It's available from Red Hat for rhl5.
--Tonni
--
Tony Earnshaw
Email: tonni at hetnet dot nl
Hi Rajagopal,
Can you confirm the below points?
1) let us know the client application are you using.
2) Paste here your slapd.conf file.
On 20 November 2015 at 13:16, Rajagopal Rc <rajagopal.rc(a)tcs.com> wrote:
> Hi,
> I am trying to force users to change their password at first login or after
> password reset by administrator.
>
> Tried following:
> 1)Password policy 'pwdMustChange TRUE' doesn't seems to be working as non
> of the
> users get prompt to change their password at first login.
>
> 2) used the 'pwdReset TRUE' attribute in users attributes, and it won't
> prompt
> to change the password and didn't allow to login
> i observe below messages in log
>
> "slapd[12684]: connection restricted to password changing only
> slapd[12684]: send_ldap_result: err=50 matched="" text="Operations are
> restricted to bind/unbind/abandon/StartTLS/modify password"
> slapd[12684]: conn=1053 op=1 SEARCH RESULT tag=101 err=50 nentries=0
> text=Operations are restricted to bind/unbind/abandon/StartTLS/modify
> password"
>
> Please help me configure the option to force all users to change their
> password
> at first login or after pwd reset by administrator.
>
> Thanks & Regards
> Raj
> Tata Consultancy Services
> Mailto: rajagopal.rc(a)tcs.com
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty. IT Services
> Business Solutions
> Consulting
> ____________________________________________
>
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain
> confidential or privileged information. If you are
> not the intended recipient, any dissemination, use,
> review, distribution, printing or copying of the
> information contained in this e-mail message
> and/or attachments to it are strictly prohibited. If
> you have received this communication in error,
> please notify us by reply e-mail or telephone and
> immediately and permanently delete the message
> and any attachments. Thank you
>
>
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
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:DA147B05
53°37'09,95"N
10°08'02,42"E
Everything is setup on RHEL 6.4 with Openldap 2.4.
I have one provider and one consumer. StartTLS has been enabled and everything is working as intended. My only problem arises here -
When a user is setup with a password and he tries to change his password on a consumer pointing client, I get a passwd: Authentication token manipulation error. This message is misleading since the password is in fact changed on the provider ( I have the olcUpdateRef directive setup). This creates a situation where the user can login to consumer pointed boxes with his old password and provider pointed boxes with his new password. If the user tries to change his password for the second time on consumer pointed boxes, I get Password change failed. Server message: unwilling to verify old password passwd: Authentication token manipulation error which understandably is because the password in the actual LDAP db is different from what is being supplied and being accepted by the client. What is going on here? Why isn’t the password not getting updated properly in the consumer?
Here are some of the relevant snippets of configs -
For Syncrepl in olcDatabase={2}bdb.ldif on consumer
###For Replication
olcSyncrepl: rid=100
provider="ldap://server.com
type=refreshAndPersist
retry="60 30 300 +"
searchbase=“dc=ex,dc=example,dc=com"
bindmethod=simple
binddn="cn=Manager,dc=ex,dc=example,dc=com"
credentials=secret
starttls=yes
tls_cacert=/etc/pki/CA/cacert.pem
tls_cert=/etc/pki/tls/certs/cert.pem
tls_key=/etc/pki/tls/certs/key.pem
olcUpdateRef: ldap://server.com
ACL on provider -
lcAccess: to attrs=userPassword
by self write
by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write
by anonymous auth
by * none
olcAccess: to *
by self write
by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write
by users read
olcAccess: to attrs=entry
by dn.base="cn=Manager,dc=ex,dc=example,dc=com" write
by * read
Let me know if any more configs are needed and I will post them. Any help is appreciated.
Siddharth Choure
Senior Systems Engineer
Hello,
* Summary:
I'm trying to set up syncrepl in my LDAP infrastructure. The logs on
my consumer show that syncrepl is failing to negotiate TLS when
connecting to the provider. Other LDAP commands such as ldapsearch and
sssd show no problem connecting using the same TLS configuration.
At this point, I don't have a good idea of how to continue debugging
this problem. Are there any more configuration items affecting TLS I
should be looking at? Or any way of getting more details on the TLS
nagotiation?
* The provider ("auth-00.[MYDOMAIN]"):
slapd 2.4.23 from openldap-servers-2.4.23-15.el6.x86_64 on Scientific
Linux 6. TLS is configured with
[cn=config]
olcTLSCACertificateFile: /etc/ssl/[MYCA].pem
olcTLSCertificateFile: /etc/ssl/certs/auth-00.crt.pem # Has
CN=auth-00.[MYDOMAIN]
olcTLSCertificateKeyFile: /etc/ssl/private/auth-00.key.pem
olcTLSVerifyClient: never
If I try:
$ ldapsearch -ZZ -x -H ldap://auth-00.[MYDOMAIN]/ uid=iain
it connects and cheerfully returns objects
* The provider ("auth-01.MYDOMAIN"):
Same slapd version, same package, same OS. syncrepl configuration:
olcSyncrepl: rid=001 provider=ldap://auth-00.[MYDOMAIN]:389
bindmethod=simple timeout=0
network-timeout=0 binddn="cn=syncrepl,dc=[MYDOMAIN]"
credentials="[MYPASSWORD]"
keepalive=0:0:0 filter="(objectClass=*)" searchbase="dc=[MYDOMAIN]" scope=sub
schemachecking=off type=refreshAndPersist retry="10 3 120 5 600 +"
starttls=critical
tls_cacert=/etc/ssl/MYCA.pem
* The error
Consumer:
Jan 28 11:53:12 auth-01 slapd[5595]: slapd starting
Jan 28 11:53:12 auth-01 slapd[5595]: slap_client_connect:
URI=ldap://auth-00.[MYDOMAIN]:389 Error, ldap_start_tls failed (-11)
Jan 28 11:53:13 auth-01 slapd[5595]: do_syncrepl: rid=001 rc -11
retrying (2 retries left)
Provider receiving syncrepl connection:
Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 fd=32 ACCEPT from
IP=[AUTH-01'S IP]:42669 (IP=0.0.0.0:389)
Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 op=0 STARTTLS
Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 op=0 RESULT oid= err=0 text=
Jan 28 11:53:23 auth-00 slapd[10701]: conn=7849 fd=32 closed (TLS
negotiation failure)
Provider receiving ldapsearch connection:
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 fd=103 ACCEPT from
IP=[AUTH-01'S IP]:42765 (IP=0.0.0.0:389)
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 op=0 STARTTLS
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 op=0 RESULT oid= err=0 text=
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 fd=103 TLS established
tls_ssf=256 ssf=256
Jan 28 13:55:59 auth-00 slapd[22621]: conn=1099 op=1 BIND [...]
Thanks,
Iain.
--
Systems Engineer
KAUST Visualisation Laboratory
I have two servers i'd like to setup to do MMR. I have several BDB backends that I would like to replicate. My question is do I need to create a "replicate" user for each BDB backend as well as a syncrepl statement under each BDB definition and an acl to allow the sync user to read the each BDB? Consider the slapd configuration below. Or is is possible to just setup one user with read access to all of my BDB backends and then setup just one syncrepl statement?
serverID 1 ldap://txeduds1
serverID 2 ldap://txeduds2
database bdb
suffix "dc=il,dc=edu,dc=com"
rootdn "cn=LDAPAdmin,dc=il,dc=edu,dc=com"
rootpw xxxx
directory /var/lib/ldap/ldap.edu.il
monitoring off
syncrepl rid=001
provider=ldap://txeduds1:389
type=refreshAndPersist
retry="60 10 300 +"
searchbase="dc=il,dc=edu,dc=com"
attrs="*,+"
schemachecking=off
bindmethod=simple
starttls=no
tls_reqcert=never
binddn="cn=ilreplicator,ou=ilservice,dc=il,dc=edu,dc=com"
credentials=xxxx
##Syncrepl
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
mirrormode on
limits dn.exact="cn=ilreplicator,ou=ilservice,dc=il,dc=edu,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
####################################################################################
####################################################################################
access to attrs=userpassword
by dn.base="cn=njreplicator,ou=njservice,dc=nj,dc=edu,dc=com read
by self write
by anonymous auth
by * none
database bdb
suffix "dc=nj,dc=edu,dc=com"
rootdn "cn=LDAPAdmin,dc=nj,dc=edu,dc=com"
rootpw xxxx
directory /var/lib/ldap/ldap.edu.nj
monitoring off
syncrepl rid=001
provider=ldap://txeduds1:389
type=refreshAndPersist
retry="60 10 300 +"
searchbase="dc=nj,dc=edu,dc=com"
attrs="*,+"
schemachecking=off
bindmethod=simple
starttls=no
tls_reqcert=never
binddn="cn=njreplicator,ou=njservice,dc=nj,dc=edu,dc=com"
credentials=xxx
##Syncrepl
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
mirrormode on
limits dn.exact="cn=njreplicator,ou=njservice,dc=nj,dc=edu,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
####################################################################################
####################################################################################
access to attrs=userpassword
by dn.base="cn=gareplicator,ou=gaservice,dc=ga,dc=edu,dc=com" read
by self write
by anonymous auth
by * none
database bdb
suffix "dc=ga,dc=edu,dc=com"
rootdn "cn=LDAPAdmin,dc=ga,dc=edu,dc=com"
rootpw xxx
directory /var/lib/ldap/ldap.edu.ga
syncrepl rid=001
provider=ldap://txeduds1:389
type=refreshAndPersist
retry="60 10 300 +"
searchbase="dc=ga,dc=edu,dc=com"
attrs="*,+"
schemachecking=off
bindmethod=simple
starttls=no
tls_reqcert=never
binddn="cn=gareplicator,ou=gaservice,dc=ga,dc=edu,dc=com"
credentials=xxx
##Syncrepl
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
mirrormode on
