PJunod(a)mediageneral.com wrote:
> I have setup two ldap servers for authentication and access control in a
> multi-master configuration. I am concerned about the number of contextcsn
> entries that are supposed to be present in each database. Right now there are
> two servers participating in the multi-master configuration. From my
> understanding, there should be one contextCSN entry per database per host. My
> cn=config database has two contextCSN entries as I would expect. One for each
> syncrepl rid configured. My bdb database only has one contextCSN entry though,
> with an rid of just “000”. (my rid’s are 001, 002, 101, and 102)
ContextCSN is an attribute. Attributes have values, they do not have entries.
CSNs carry SIDs not RIDs.
If you don't use the correct terminology no one will understand what you're
talking about.
If a database contains changes from more than one server, then its contextCSN
should contain more than one value, and each value should have distinct SIDs.
But the SIDs will only be used correctly if the URLs in the ServerID directive
match the actual URLs given to the slapd -h option.
> Replication seems to work fine on both databases. I can write to either one
> and the changes are replicated over immediately. I am just curious about this
> discrepancy in the number of contextCSN entries. Could someone confirm the
> number of contextCSN entries per database and if it should match the number of
> hosts participating in the multi-master replication? Here are some relevant
> settings for the replication:
>
> dn: cn=config
>
> olcServerID: 1 ldap://<server1>
>
> olcServerID: 2 ldap://<server2>
>
> #######################
>
> # module{0}, config
>
> dn: cn=module{0},cn=config
>
> objectClass: olcModuleList
>
> cn: module{0}
>
> olcModulePath: /usr/lib64/openldap2.4
>
> olcModuleLoad: {0}syncprov.la
>
> #######################
>
> # {0}config, config
>
> dn: olcDatabase={0}config,cn=config
>
> olcSyncrepl: {0}rid=001 provider=ldap://<server1> binddn="cn=Ma
>
> nager,cn=config" bindmethod=simple credentials=<password> searchbase="cn=config
>
> " type=refreshAndPersist retry="5 500 5 +" timeout=1 starttls=yes
>
> olcSyncrepl: {1}rid=002 provider=ldap://<server2> binddn="cn=Ma
>
> nager,cn=config" bindmethod=simple credentials=<password> searchbase="cn=config
>
> " type=refreshAndPersist retry="5 500 5 +" timeout=1 starttls=yes
>
> olcMirrorMode: TRUE
>
> #######################
>
> # {0}syncprov, {0}config, config
>
> dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
>
> objectClass: olcOverlayConfig
>
> objectClass: olcSyncProvConfig
>
> olcOverlay: {0}syncprov
>
> #######################
>
> # {1}bdb, config
>
> dn: olcDatabase={1}bdb,cn=config
>
> olcSyncrepl: {0}rid=101 provider=ldap://<server1> binddn="cn=Ma
>
> nager,dc=mgcorp,dc=net" bindmethod=simple credentials=<password> searchbase="dc
>
> =mgcorp,dc=net" type=refreshAndPersist interval=00:00:00:10 retry="5 500 5 +"
>
> timeout=1 starttls=yes
>
> olcSyncrepl: {1}rid=102 provider=ldap://<server2> binddn="cn=Ma
>
> nager,dc=mgcorp,dc=net" bindmethod=simple credentials=<password> searchbase="dc
>
> =mgcorp,dc=net" type=refreshAndPersist interval=00:00:00:10 retry="5 500 5 +"
>
> timeout=1 starttls=yes
>
> olcMirrorMode: TRUE
>
> ##############################
>
> Here are the results of searches for contextCSN in cn=config and dc=mgcorp,dc=net:
>
> ldapsearch -x -W -s base -D "cn=Manager,cn=config" -h "<server2>" -b
> "cn=config" contextCSN
>
> contextCSN: 20101110214932.998233Z#000000#000#000000
>
> contextCSN: 20101028121213.444193Z#000000#001#000000
>
> ldapsearch -x -W -s base -D "cn=Manager,dc=mgcorp,dc=net" -h "<server2>" -b
> "dc=mgcorp,dc=net" contextCSN
>
> contextCSN: 20101110213409.736943Z#000000#000#000000
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--On Friday, January 31, 2014 8:54 AM -0500 "Borresen, John - 0442 - MITLL"
<John.Borresen(a)ll.mit.edu> wrote:
> Thanks Quanah
>
> I'm sure it isn't 100% correct, but I added the following ACL to my
> accesslog DB on both MM servers:
>
> olcAccess: to * by dn="cn=ldapadmin,dc=group42,dc=ldap" read by * none
Well, it may not have been this issue, but it definite would become an
issue then. ;)
> I'm still seeing
> gp42-admin3 (MM server1)
> Jan 31 08:25:17 gp42-admin3 slapd[3599]: conn=5551 op=2 SRCH
> base="cn=accesslog" scope=2 deref=0 filter="(objectClass=*)" Jan 31
> 08:25:17 gp42-admin3 slapd[3599]: conn=5551 op=2 SRCH attr=reqDN reqType
> reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Jan 31 08:25:17
> gp42-admin3 slapd[3599]: do_syncrep2: rid=001 got empty syncUUID with
> LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:17 gp42-admin3 slapd[3599]:
> do_syncrepl: rid=001 rc -1 retrying Jan 31 08:25:17 gp42-admin3
> slapd[3599]: send_search_entry: conn 5551 ber write failed. Jan 31
> 08:25:17 gp42-admin3 slapd[3599]: conn=5551 fd=32 closed (connection lost
> on write) Jan 31 08:25:17 gp42-admin3 slapd[3599]: do_syncrep2: rid=002
> got empty syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:17
> gp42-admin3 slapd[3599]: do_syncrepl: rid=002 rc -1 retrying
Your masters are unable to talk to each other. You need to determine why.
This will take debugging on your part, as I've never seen anything like
this before.
> gp42-admin4 (MM server2)
> Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 fd=101 ACCEPT from
> IP=155.34.133.73:10446 (IP=0.0.0.0:389) Jan 31 08:25:19 gp42-admin4
> slapd[26000]: conn=8050 op=0 BIND dn="dc=group42,dc=ldap" method=163 Jan
> 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 op=0 RESULT tag=97 err=13
> text=TLS confidentiality required Jan 31 08:25:19 gp42-admin4
> slapd[26000]: conn=8050 op=1 BIND dn="cn=ldapadmin,dc=group42,dc=ldap"
> method=128 Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 op=1
> RESULT tag=97 err=13 text=TLS confidentiality required Jan 31 08:25:19
> gp42-admin4 slapd[26000]: conn=8050 op=2 UNBIND
> Jan 31 08:25:19 gp42-admin4 slapd[26000]: conn=8050 fd=101 closed
> Jan 31 08:25:51 gp42-admin4 slapd[26000]: do_syncrep2: rid=001 got empty
> syncUUID with LDAP_SYNC_ADD (cn=accesslog) Jan 31 08:25:51 gp42-admin4
> slapd[26000]: do_syncrepl: rid=001 rc -1 retrying
This says that your consumer is connecting without sending a startTLS,
while you've configured the master to require startTLS. Clearly you need
to either enable startTLS in the syncrepl statement, or not require
starttls on your master.
--Quanah
> -----Original Message-----
> From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
> Sent: Thursday, January 30, 2014 5:10 PM
> To: Borresen, John - 0442 - MITLL; openldap-technical(a)openldap.org
> Subject: RE: Syncrepl and mmr
>
> --On Thursday, January 30, 2014 4:51 PM -0500 "Borresen, John - 0442 -
> MITLL" <John.Borresen(a)ll.mit.edu> wrote:
>
>> Well, that was helpful -- lol
>
>
> Looking at your previously supplied configuration, it is clearly apparent
> that you provided your replication user no ACLs to read the accesslog DB,
> so the error you see makes sense. It can't read the data out of
> accesslog, so it throws an error stating that fact.
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Architect - Server
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
--
Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
Joshua Schaeffer wrote:
>> Michael Ströder wrote:
>>>
>>> Simply use LDAPS (on separate port). It was never defined in a standard but
>>> most
>>> LDAP-enabled software supports it.
>
> I did ended up doing this. I had an application that didn't support start_tls
> on an ldap URI, but did support ldaps (or at least I couldn't find a way to
> get it to issue start_tls).
In OpenLDAP's libldap just use a URL extension:
ldap://host/????starttls
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
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
