Re: Security between server and client nodes.
by Jayavant Patil
>>On 11/30/2011 08:01 AM, Jayavant Patil wrote:
>>
>>
>> On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil
>> <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com>> wrote:
>>
>>
>> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli
>> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote:
>> >>Hi
>>
>> >>I think you mean SSL connection or the STARTTLS Layer...?
>> >>Please read the manual http://www.openldap.org/doc/admin24/tls.html
>> >Ok.
>>
>> >>And tree security:
>> >>On my server, a client user can only see his own object:
>> >Are you using simple authentication mechanism?
>>
>> >>Maybe create a rule like this:
>> >>access to filter=(objectClass=
>> >>simpleSecurityObject)
>> >> by self read
>> >> by * none
>>
>> >I am not getting what the ACL rule specifies. Any suggestions?
>>
>>
>> I have two users ldap_6 and ldap_7. I want to restrict a user to
>> see his own data only.
>> In slapd.conf, I specified the rule as follows:
>> access to *
>> by self write
>> by * none
>>
>> But ldap_6 can see the ldap_7 user entries (or vice versa) with
>> $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
>> "ou=People,dc=abc,dc=com" "uid=ldap_7"
>>
>> Any suggestions?
>>
>On Wed, 30 Nov 2011 08:38:32 +0100 Raffael Sahli <public(a)raffaelsahli.com>
wrote:
>Yes, that's exactly the rule I wrote above.
>access to filter=(objectClass=
>simpleSecurityObject)
> by self read
> by * none
>Maybe you have to change the objectClass to posixAccount, or both or
>whatever....
>access to
>filter=(|(objectClass=simpleSecurityObject)(objectClass=posixAccount))
> by self read
> by * none
>Just add this rule before the global rule "access to *"
>>ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
>>"ou=People,dc=abc,dc=com" "uid=ldap_7"
>And if you search like this with bind "admin dn", you will see every
>object....
>You have to bind with user ldap_6 and not with root
But anyway client user knows the admin dn and rootbindpassword. So, with
this he will look into all directory information to which he is not
supposed to do.
e.g. ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -w cluster
So, how to avoid this?
--
Thanks & Regards,
Jayavant Ningoji Patil
Engineer: System Software
Computational Research Laboratories Ltd.
Pune-411 004.
Maharashtra, India.
+91 9923536030.
13 years, 6 months
mmr pair stops replicating: "consumer state is newer than provider"
by btb
hi. i have two servers, in an mmr arrangement, using delta-syncrepl.
on a couple of occasions, the servers have stopped replicating, and the
following is logged:
dsa1:
Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000
LDAP_RES_SEARCH_RESULT
Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000
LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform
Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrep2: rid=000 (53) Server is
unwilling to perform
Jun 27 06:13:29 ldap0 slapd[8699]: do_syncrepl: rid=000 rc -2 retrying
dsa2:
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 ACCEPT from
IP=10.200.41.20:49141 (IP=0.0.0.0:389)
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 STARTTLS
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=0 RESULT oid= err=0 text=
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 TLS established
tls_ssf=256 ssf=256
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 BIND
dn="uid=dsa1_slapd-repl-content,ou=dsa1.example.org,ou=services,ou=accounts,dc=example,dc=org"
method=128
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 BIND
dn="uid=dsa1_slapd-repl-content,ou=dsa1.example.org,ou=services,ou=accounts,dc=example,dc=org"
mech=SIMPLE ssf=0
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=1 RESULT tag=97 err=0
text=
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SRCH
base="cn=accesslog" scope=2 deref=0
filter="(&(objectClass=auditWriteObject)(reqResult=0))"
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SRCH attr=reqDN
reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=2 SEARCH RESULT
tag=101 err=53 nentries=0 text=consumer state is newer than provider!
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 op=3 UNBIND
Jun 27 09:13:29 ldap0 slapd[14910]: conn=49263 fd=9 closed
if i reload data and restart replication, things work again, for a
period of time, but then this happens again.
what determines "consumer state is newer than provider"? i'm also a
little bit confused about this message in the context of mmr. if one
has newer data than the other, i had sort of expected that the newer
data would replace the old [obviously it's not that simple, so i'd like
to understand what i'm missing].
lastly, how can i further troubleshoot why this happened in the first place?
i'm using 2.4.44 on freebsd, built from ports. i can provide any config
details etc - i just didn't want to inundate the post with guesses on
detail that might not be relevant.
thanks
-ben
7 years, 11 months
Re: LDAP Replica TLS problem
by Gremaud Cyrill
Hi,
If your certificate is self-signed, try to remove this line:
olcTLSCACertificateFile: /etc/openldap/certs/ldapscert.pem
Keep only olcTLSCertificateFile and olcTLSCertificateKeyFile
Best regard, cyrill gremaud
On 20 Oct 2014, at 17:07, Elmopi, Stefano <stefano.elmopi(a)sociale.it<mailto:stefano.elmopi@sociale.it>> wrote:
Hi,
I'm having trouble to run the replica LDAP with TLS, without TLS, all works !!
Provider and Consumer are identical
CentOS release 6.5
rpm -qa | grep ldap
openldap-clients-2.4.23-34.el6_5.1.x86_64
openldap-2.4.23-34.el6_5.1.x86_64
apr-util-ldap-1.3.9-3.el6_0.1.x86_64
nss-pam-ldapd-0.7.5-18.2.el6_4.x86_64
mod_authz_ldap-0.26-16.el6.x86_64
pam_ldap-185-11.el6.x86_64
openldap-servers-2.4.23-34.el6_5.1.x86_64
Provider config, file cn\=config.ldif
olcTLSCACertificateFile: /etc/openldap/certs/ldapscert.pem
olcTLSCertificateFile: /etc/openldap/certs/ldapscert.pem
olcTLSCertificateKeyFile: /etc/openldap/certs/keys/ldapskey.pem
olcTLSCipherSuite: TLSv1+RSA:!EXPORT:!NULL
olcTLSVerifyClient: never
Consumer config:
olcSyncrepl: {0}rid=000
provider=ldap://ldpsoc01devpom.sociale.it<http://ldpsoc01devpom.sociale.it/>
starttls=yes
type=refreshonly
retry="5 5 300 +"
searchbase="dc=example,dc=it"
attrs="*,+"
bindmethod=simple
binddn="uid=xxxxxxxx,ou=admin_bind,ou=Utenze_Amministratori,dc=example,dc=it"
credentials=xxxxxxx
interval=60
and, in /etc/openldap/ldap.conf
TLS_CACERT /etc/openldap/certs/ldapscert.pem
TLS_REQCERT never
the certificate is self-signed
On the slave, if I try the following command:
ldapsearch -ZZ -x -H ldap://ldpsoc01devpom -D 'uid=xxxxxxx,ou=admin_bind,ou=Utenze_Amministratori,dc=example,dc=it' -W 'objectclass=*' -v
everything is ok but when I try to use TLS in replication, the process goes wrong.
In the Provider log:
connection_get(16)
connection_get(16): got connid=1030
connection_read(16): checking for input on id=1030
connection_read(16): TLS accept failure error=-1 id=1030, closing
connection_closing: readying conn=1030 sd=16 for close
connection_close: conn=1030 sd=16
daemon: activity on 1 descriptor
daemon: activity on:
In the Consumer log:
slapd[6508]: =>do_syncrepl rid=000
slap_client_connect: URI=ldap://ldpsoc01devpom.sociale.it<http://ldpsoc01devpom.sociale.it/> Warning, ldap_start_tls failed (-11)
slap_client_connect: URI=ldap://ldpsoc01devpom.sociale.it<http://ldpsoc01devpom.sociale.it/> DN="uid=bind_replica,ou=admin_bind,ou=utenze_amministratori,dc=sociale,dc=it" ldap_sasl_bind_s failed (-1)
do_syncrepl: rid=000 rc -1 retrying (3 retries left)
daemon: activity on 1 descriptor
daemon: activity on:
Help, I do not know where to turn !!!!
Thanks
Ing. Stefano Elmopi
Cooperativa Capodarco - Resp. Area ICT Gestione Esercizio
Via Ostiense 131/L Corpo B, 00154 Roma
cell. 3466147165
tel. 0657060500
email:stefano.elmopi@sociale.it<mailto:email%3Astefano.elmopi@sociale.it>
"Ai sensi e per gli effetti della legge sulla tutela dei dati personali (D.lgs 196/2003),
le informazioni contenute nella presente @mail sono di natura riservata e destinate
ad un uso aziendale-lavorativo con esclusione di utilizzi ad uso personale; come tali,
pertanto, sono riservate esclusivamente ai destinatari sopra indicati. E' proibito leggere,
copiare, usare o diffondere il contenuto della presente @mail senza autorizzazione.
Se avete ricevuto questa @mail per errore, siete pregati di rispedire la stessa al mittente.
Grazie"
10 years, 7 months
slapo-chain - can't get it working
by Richard Nelson
I sent this two days ago, from an unsubscribed account and it still hasn't shown
up... don't know if moderation is hampered, or if it just didn't make through...
I have the basics covered - 1 master, 4 syncrepl slaves (going to 2-3 MM, 1-2
slaves). This setup has been working quite well - supporting AIX, Linux user
data, Samba PDC/BDCs, and Kerberos (slapd 2.4.7 Debian Sid/unstable)
The only issue I have now, is having to find the master to perform any updates.
I'd like to use slapo-chain so that update referrals are automatically handled,
especially since so little stuff supports referrals - even things that should.
There are a few examples here and there, and unfortunately, some of them
contradict others (probably written to different ldap levels).
As an example of my plight, here is the output of ldappasswd on a slave machine
(ldapmodify shows the same issue, but isn't as easy to show)
#
# on the slave, when trying a ldappasswd:
$ ldappasswd -Ydigest-md5 -w<my passwd>
SASL/DIGEST-MD5 authentication started
SASL username: renegade
SASL SSF: 128
SASL data security layer installed.
Result: Referral (10)
Referral: ldap://ldap-master.cobpli.svl.ibm.com
#
# The following is the slave ldap trace, and there is *no* traffic to the master...
conn=0 op=1 BIND authcid="renegade(a)COBPLI.SVL.IBM.COM"
authzid="renegade(a)COBPLI.SVL.IBM.COM"
conn=0 op=1 BIND dn="uid=renegade,ou=users,dc=cobpli,dc=svl,dc=ibm,dc=com"
mech=DIGEST-MD5 sasl_ssf=128 ssf=128
conn=0 op=1 RESULT tag=97 err=0 text=
conn=0 op=2 EXT oid=1.3.6.1.4.1.4203.1.11.1
conn=0 op=2 PASSMOD
conn=0 op=2 RESULT oid= err=10 text=
#
# The basics work:
$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: renegade(a)COBPLI.SVL.IBM.COM
SASL SSF: 56
SASL data security layer installed.
dn:uid=renegade,ou=users,dc=cobpli,dc=svl,dc=ibm,dc=com
#
# Proxy authentication works:
$ ldapwhoami -Uproxy -Ydigest-md5 -w<passwd> -Xu:cowboy
SASL/DIGEST-MD5 authentication started
SASL username: u:cowboy
SASL SSF: 128
SASL data security layer installed.
dn:uid=cowboy,ou=users,dc=cobpli,dc=svl,dc=ibm,dc=com
#
# Here is the likely relevant ldap sections (chain overlay, syncprop, updatref):
#
overlay chain
chain-uri "ldap://ldap-master.cobpli.svl.ibm.com/"
# Neither of these lines make a difference
chain-rebind-as-user TRUE
#chain-rebind-as-user FALSE
# Here, I've tried simple/sasl, varied saslmech, etc...
chain-idassert-bind bindmethod="simple"
saslmech=digest-md5
authz=proxyauthz
binddn="uid=proxy,ou=users,dc=cobpli,dc=svl,dc=ibm,dc=com"
credentials="<passwd>"
mode=self
chain-idassert-authzFrom "*"
syncrepl rid=1
provider=ldap://ldap-master.cobpli.svl.ibm.com/
starttls=no
binddn="cn=Replicator,ou=DSA,dc=cobpli,dc=svl,dc=ibm,dc=com"
bindmethod=simple
credentials=<passwd>
searchbase="dc=cobpli,dc=svl,dc=ibm,dc=com"
schemaChecking=off
type=refreshAndPersist retry="10 10 300 +"
updateref ldap://ldap-master.cobpli.svl.ibm.com/
17 years
Syncrepl with subordinate databases
by Robert Minsk
I have multiple sites that I am trying to sync up to a global server.
Each site is configured (striped down) as:
############################################################################
# mdb database for o=chi01,ou=studios,dc=methodstudios,dc=net
############################################################################
database mdb
suffix "o=chi01,ou=studios,dc=methodstudios,dc=net"
# Save the time that the entry gets modified
lastmod on
# Subordinate of the ou=studios,dc=methodstudios,dc=net database below
subordinate advertise
overlay syncprov
syncprov-reloadhint TRUE
syncprov-checkpoint 100 5
############################################################################
# mdb database for ou=studios,dc=methodstudios,dc=net
############################################################################
database mdb
suffix "ou=studios,dc=methodstudios,dc=net"
The above is my configuration for Chicago. I have similar ones for New
York (ny01) and Los Angeles (la01)
On my global server I am trying to use sync replication to clone each
site. The global server is configured (striped down) as:
############################################################################
# mdb database for o=global,ou=studios,dc=methodstudios,dc=net
############################################################################
database mdb
suffix "o=global,ou=studios,dc=methodstudios,dc=net"
# Save the time that the entry gets modified
lastmod on
# Subordinate of the ou=studios,dc=methodstudios,dc=net database below
subordinate advertise
overlay syncprov
syncprov-reloadhint TRUE
syncprov-checkpoint 100 5
############################################################################
# mdb database for o=chi01,ou=studios,dc=methodstudios,dc=net
############################################################################
database mdb
suffix "o=chi01,ou=studios,dc=methodstudios,dc=net"
# Subordinate of the ou=studios,dc=methodstudios,dc=net database below
subordinate advertise
syncrepl rid=1 provider=ldap://chi01.methodstudios.com
type=refreshOnly retry="60 10 300 +"
interval=00:00:10:00
searchbase="o=chi01,ou=studios,dc=methodstudios,dc=net"
bindmethod=simple starttls=yes
binddn="****"
credentials=**** schemachecking=off
############################################################################
# mdb database for o=ny01,ou=studios,dc=methodstudios,dc=net
############################################################################
database mdb
suffix "o=ny01,ou=studios,dc=methodstudios,dc=net"
# Subordinate of the ou=studios,dc=methodstudios,dc=net database below
subordinate advertise
syncrepl rid=2 provider=ldap://ny01.methodstudios.com
type=refreshOnly retry="60 10 300 +"
interval=00:00:10:00
searchbase="o=ny01,ou=studios,dc=methodstudios,dc=net"
bindmethod=simple starttls=yes
binddn="****"
credentials=**** schemachecking=off
############################################################################
# mdb database for ou=studios,dc=methodstudios,dc=net
############################################################################
database mdb
suffix "ou=studios,dc=methodstudios,dc=net"
overlay glue
overlay syncprov
syncprov-reloadhint TRUE
syncprov-checkpoint 100 5
Now that I have the configuration out of the way. Syncrepl on the
global server is failing on chi01. The chi01 server syslog has
Oct 23 18:41:35 boote01-chi01 slapd[19324]: conn=1000 op=2 SRCH
base="o=chi01,ou=studios,dc=methodstudios,dc=net" scope=2 deref=0
filter="(objectClass=*)"
Oct 23 18:41:35 boote01-chi01 slapd[19324]: conn=1000 op=2 SRCH attr=* +
Oct 23 18:41:35 boote01-chi01 slapd[19324]: conn=1000 op=2 SEARCH RESULT
tag=101 err=53 nentries=0 text=consumer state is newer than provider!
Oct 23 18:41:35 boote01-chi01 slapd[19324]: conn=1000 op=3 UNBIND
Looking at the ny01 server (ldapsearch -x -h ny01 -b
o=ny01,ou=studios,dc=methodstudios,dc=net -s base +) where syncrepl is
working
# ny01, studios, methodstudios.net
dn: o=ny01,ou=studios,dc=methodstudios,dc=net
structuralObjectClass: organization
entryUUID: 257c5408-717c-1032-9b24-31eddc101779
creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net
createTimestamp: 20130625004432Z
entryCSN: 20130625004432.932104Z#000000#000#000000
modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net
modifyTimestamp: 20130625004432Z
contextCSN: 20131023210335.999443Z#000000#000#000000
entryDN: o=ny01,ou=studios,dc=methodstudios,dc=net
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE
Looking at the global server (ldapsearch -x -h global -b
o=ny01,ou=studios,dc=methodstudios,dc=net -s base +):
# ny01, studios, methodstudios.net
dn: o=ny01,ou=studios,dc=methodstudios,dc=net
structuralObjectClass: organization
entryUUID: ccbe6442-d084-1032-8149-e14ce02952dd
creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net
createTimestamp: 20131023231549Z
entryCSN: 20131023231549.982220Z#000000#000#000000
modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net
modifyTimestamp: 20131023231549Z
entryDN: o=ny01,ou=studios,dc=methodstudios,dc=net
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE
Notice no contextCSN.
Looking at the chi01 server (ldapsearch -x -h chi01 -b
o=chi01,ou=studios,dc=methodstudios,dc=net -s base +):
# chi01, studios, methodstudios.net
dn: o=chi01,ou=studios,dc=methodstudios,dc=net
structuralObjectClass: organization
entryUUID: 4b4f63f6-81bb-1032-97d3-7d320a684bf1
creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net
createTimestamp: 20130715165653Z
entryCSN: 20130715165653.289427Z#000000#000#000000
modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net
modifyTimestamp: 20130715165653Z
contextCSN: 20131018000127.430328Z#000000#000#000000
entryDN: o=chi01,ou=studios,dc=methodstudios,dc=net
subschemaSubentry: cn=Subschema
hasSubordinates: TRUE
Looking at the global server (ldapsearch -x -h global -b
o=chi01,ou=studios,dc=methodstudios,dc=net -s base +):
# chi01, studios, methodstudios.net
dn: o=chi01,ou=studios,dc=methodstudios,dc=net
structuralObjectClass: organization
entryUUID: cc675698-d084-1032-8eb1-f1b765ca1756
creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net
createTimestamp: 20131023231549Z
entryCSN: 20131023231549.411641Z#000000#000#000000
modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net
modifyTimestamp: 20131023231549Z
entryDN: o=chi01,ou=studios,dc=methodstudios,dc=net
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE
Notice no contextCSN.
Looking at the global server root of the glued database (ldapsearch -x
-h global -b ou=studios,dc=methodstudios,dc=net -s base +):
# studios, methodstudios.net
dn: ou=studios,dc=methodstudios,dc=net
structuralObjectClass: organizationalUnit
entryUUID: cc769b12-d084-1032-86fe-a1b1821abdab
creatorsName: cn=admin,ou=studios,dc=methodstudios,dc=net
createTimestamp: 20131023231549Z
entryCSN: 20131023231549.511823Z#000000#000#000000
modifiersName: cn=admin,ou=studios,dc=methodstudios,dc=net
modifyTimestamp: 20131023231549Z
contextCSN: 20131024000524.348070Z#000000#000#000000
entryDN: ou=studios,dc=methodstudios,dc=net
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE
So after all that. Is the syncrepl from chi01 using the contextCSN from
the root of the glued database? It seems all the syncrepl from all the
sites fail unless they have the latest change. How do you handle
syncrepl on glued databases?
--
Robert Minsk
Systems and Software Engineer
WWW.METHODSTUDIOS.COM <http://www.methodstudios.com>
730 Arizona Ave, Santa Monica, CA 90401
O:+1 310 434 6500 <tel:+13104346500> // F:+1 310 434 6501
<tel:+13104346501>
Los Angeles
<http://www.methodstudios.com/signature/url/los-angeles><http://www.methodstudios.com/signature/url/los-angeles>
This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed.
11 years, 7 months
RE: N-way multi master configuration issue
by Naga Chaitanya Palle
Hi Buchan,
After making the changes are per your suggestions, I am still not able to read data between the servers.
Also, I deleted DI data on server 2 and restarted to import data from server1 , but no use.
Can you please check the slapd.conf files and suggest.
Server 1 slapd.conf file
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/share/openldap2.4/schema/sudo.schema
include /usr/share/openldap2.4/schema/core.schema
include /usr/share/openldap2.4/schema/cosine.schema
include /usr/share/openldap2.4/schema/inetorgperson.schema
include /usr/share/openldap2.4/schema/nis.schema
include /usr/share/openldap2.4/schema/misc.schema
include /usr/share/openldap2.4/schema/openldap.schema
include /usr/share/openldap2.4/schema/ppolicy.schema
include /usr/share/openldap2.4/schema/corba.schema
loglevel 296
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/ldap2.4/slapd.pid
argsfile /var/run/ldap2.4/slapd.args
access to attrs=userPassword
by self write
by users read
by anonymous auth
#access to attrs=shadowLastChange
# by self write
# by * auth
access to *
by * read
access to *
by dn.base="cn=Manager,dc=comverse-in,dc=com" read
by * break
# Load dynamic backend modules:
# modulepath /usr/lib/openldap
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
#TLSCipherSuite HIGH:MEDIUM:+SSLv2
#TLSCACertificateFile /etc/openldap2.4/cacerts/cacert.pem
#TLSCertificateFile /etc/openldap2.4/cacerts/slapd-cert.pem
#TLSCertificateKeyFile /etc/openldap2.4/cacerts/slapd-key.pem
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
serverId 001
database bdb
suffix "dc=comverse-in,dc=com"
rootdn "cn=Manager,dc=comverse-in,dc=com"
rootpw {SSHA}9tKeVZfgKFCfgIFQxXt5esH0HhQk1dIS
# 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 {crypt}ijFYNcSNctBYg
# 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/ldap2.4
# 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
#index sudoUser eq
index sudoUser eq
index member eq
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
#index objectclass,entryCSN,entryUUID eq
# Load dynamic backend modules:
# modulepath /usr/lib/openldap
modulepath /usr/lib/openldap2.4
# modules available in openldap-servers-overlays RPM package:
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload denyop.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload smbk5pwd.la
moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# modules available in openldap-servers-sql RPM package:
# moduleload back_sql.la
syncrepl rid=123
provider=ldap://devonly144.comverse-in.com
type=refreshAndPersist
interval=00:00:01:00
searchbase="dc=comverse-in,dc=com"
filter="(objectClass=*)"
scope=sub
attrs="*"
schemachecking=off
bindmethod=simple
binddn="cn=Manager,dc=comverse-in,dc=com"
credentials=sonora
index objectClass,entryCSN,entryUUID eq
mirrormode true
overlay syncprov
syncprov-checkpoint 100 10
overlay ppolicy
ppolicy_default "cn=DefaultPassword,ou=pwpolicies,dc=comverse-in,dc=com"
ppolicy_hash_cleartext
ppolicy_use_lockout
#SUDOERS_BASE=ou=SUDOers,dc=comverse-in,dc=com
# 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
#replogfile /var/lib/ldap/openldap-master-replog
#replica uri=ldaps://rht144.comverse-in.com:389 starttls=critical
Server2 slapd.conf file
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/share/openldap2.4/schema/sudo.schema
include /usr/share/openldap2.4/schema/core.schema
include /usr/share/openldap2.4/schema/cosine.schema
include /usr/share/openldap2.4/schema/inetorgperson.schema
include /usr/share/openldap2.4/schema/nis.schema
include /usr/share/openldap2.4/schema/misc.schema
include /usr/share/openldap2.4/schema/openldap.schema
include /usr/share/openldap2.4/schema/ppolicy.schema
include /usr/share/openldap2.4/schema/corba.schema
loglevel 296
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/ldap2.4/slapd.pid
argsfile /var/run/ldap2.4/slapd.args
access to attrs=userPassword
by self write
by users read
by anonymous auth
#access to attrs=shadowLastChange
# by self write
# by * auth
access to *
by * read
access to *
by dn.base="cn=Manager,dc=comverse-in,dc=com" read
by * break
# Load dynamic backend modules:
# modulepath /usr/lib/openldap
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
#TLSCipherSuite HIGH:MEDIUM:+SSLv2
#TLSCACertificateFile /etc/openldap2.4/cacerts/cacert.pem
#TLSCertificateFile /etc/openldap2.4/cacerts/slapd-cert.pem
#TLSCertificateKeyFile /etc/openldap2.4/cacerts/slapd-key.pem
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
serverId 002
#database bdb
database bdb
#suffix "dc=comverse-in,dc=com"
suffix "dc=comverse-in,dc=com"
#rootdn "cn=Manager,dc=comverse-in,dc=com"
rootdn "cn=Manager,dc=comverse-in,dc=com"
rootpw {SSHA}4qLml3DcOyfwiKlN/garIms4a8fmsNkx
#rootpw sonora
# 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 {crypt}ijFYNcSNctBYg
# 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/ldap2.4
# 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
#index sudoUser eq
index sudoUser eq
index member eq
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
#index objectclass,entryCSN,entryUUID eq
# Load dynamic backend modules:
# modulepath /usr/lib/openldap
modulepath /usr/lib/openldap2.4
# modules available in openldap-servers-overlays RPM package:
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload denyop.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload smbk5pwd.la
moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# modules available in openldap-servers-sql RPM package:
# moduleload back_sql.la
overlay ppolicy
ppolicy_default "cn=DefaultPassword,ou=pwpolicies,dc=comverse-in,dc=com"
ppolicy_hash_cleartext
ppolicy_use_lockout
#SUDOERS_BASE=ou=SUDOers,dc=comverse-in,dc=com
# 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
#replogfile /var/lib/ldap/openldap-master-replog
#replica uri=ldaps://rht144.comverse-in.com:389 starttls=critical binddn="cn=Manager,dc=comverse-in,dc=com" bindmethod=simple credentials=sonora
#serverId 2
syncrepl rid=124
provider=ldap://uplite98.comverse-in.com
type=refreshAndPersist
interval=00:00:01:00
searchbase="dc=comverse-in,dc=com"
filter="(objectClass=*)"
scope=sub
attrs="*"
schemachecking=off
bindmethod=simple
binddn="cn=Manager,dc=comverse-in,dc=com"
credentials=sonora
#updateref ldap://uplite98.comverse-in.com
index objectClass,entryCSN,entryUUID eq
mirrormode true
overlay syncprov
syncprov-checkpoint 100 10
Thanks and Regards,
Naga Chaitanya
-----Original Message-----
From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net]
Sent: Friday, August 26, 2011 7:15 PM
To: Naga Chaitanya Palle
Cc: openldap-technical(a)openldap.org
Subject: Re: N-way multi master configuration issue
On Friday, 26 August 2011 15:28:13 Naga Chaitanya Palle wrote:
> Hi buchan,
>
> My server 1 is uplite98.comverse-in.com. In its slapd.conf, I have syncrepl
> pointing to server 2 devonly144.comverse-in.com and vice versa for
> server2.
Then your serverid (and, it should actually be serverId) is wrong:
> > serverid 124 ldap://devonly144.comverse-in.com
> > syncrepl rid=124
> >
> > provider=ldap://devonly144.comverse-in.com:389
The URI form of serverId is useful if you have the same configuration on all
your masters, in which case the listening address of your server must match
one of the URIs. You may want to use this form for now:
serverId 1
If your serverId's weren't correct (check the contextCSNs), you should
probably re-import an export of one server on the other one.
> I did not exactly understand what you indicated.
> Can you please be more specific about what changes needs to be done in the
> slapd.conf file?
In a multi-master setup, each server should be replicating off *all* servers,
including itself.
> Thanks and Regards,
> Naga Chaitanya
>
> -----Original Message-----
> From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net]
> Sent: Friday, August 26, 2011 6:56 PM
> To: openldap-technical(a)openldap.org
> Cc: Naga Chaitanya Palle
> Subject: Re: N-way multi master configuration issue
>
> On Friday, 26 August 2011 12:56:38 Naga Chaitanya Palle wrote:
> > Hi,
> >
> > I am trying to set up N-way multimaster configuration using syncrepl on
> > openldap2.4 for RHEL 5.4
> >
> > Currently I am using two masters for testing.
> >
> > The slapd.conf on server1 is
> > moduleload syncprov.la
> > serverid 124 ldap://devonly144.comverse-in.com
> > syncrepl rid=124
> >
> > provider=ldap://devonly144.comverse-in.com:389
> > type=refreshAndPersist
> > interval=00:00:01:00
> > searchbase="dc=comverse-in,dc=com"
> > filter="(objectClass=*)"
> > scope=sub
> > attrs="*"
> > schemachecking=off
> > bindmethod=simple
> > binddn="cn=Manager,dc=comverse-in,dc=com"
> > credentials=sonora
> >
> > index objectClass,entryCSN,entryUUID eq
> > mirrormode true
> >
> > overlay syncprov
> > syncprov-checkpoint 100 10
> >
> >
> > The slapd.conf on server2 is
> > moduleload syncprov.la
> > serverid 123 ldap://uplite98.comverse-in.com
> > syncrepl rid=123
> >
> > provider=ldap://uplite98.comverse-in.com:389
> > type=refreshAndPersist
> > interval=00:00:01:00
> > searchbase="dc=comverse-in,dc=com"
> > filter="(objectClass=*)"
> > scope=sub
> > attrs="*"
> > schemachecking=off
> > bindmethod=simple
> > binddn="cn=Manager,dc=comverse-in,dc=com"
> > credentials=sonora
> >
> > index objectClass,entryCSN,entryUUID eq
> > mirrormode true
> >
> > overlay syncprov
> > syncprov-checkpoint 100 10
> >
> > But there is no data synchronization happening between the severs.
>
> Of course not, you have configured each server only to replicate from
> itself.
>
> > When I added test3 user on server1, it is not reflecting on server 2.
> > Same way when I added test4 user on server2 it is not reflecting on
> > server1.
> >
> > Please let me know what is missing in this configuration.
>
> syncrepl statements pointing to the other master.
>
> Regards,
> Buchan
>
>
>
>
> ===========================================================================
> ==== Please refer to http://www.aricent.com/legal/email_disclaimer.html for
> important disclosures regarding this electronic communication.
> ==========================================================================
> =====
===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
13 years, 9 months
RE: N-way multi master configuration issue
by Naga Chaitanya Palle
Any inputs please?
________________________________________
From: Naga Chaitanya Palle
Sent: Monday, August 29, 2011 1:37 PM
To: Buchan Milne
Cc: openldap-technical(a)openldap.org
Subject: RE: N-way multi master configuration issue
Hi Buchan,
After making the changes are per your suggestions, I am still not able to read data between the servers.
Also, I deleted DI data on server 2 and restarted to import data from server1 , but no use.
Can you please check the slapd.conf files and suggest.
Server 1 slapd.conf file
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/share/openldap2.4/schema/sudo.schema
include /usr/share/openldap2.4/schema/core.schema
include /usr/share/openldap2.4/schema/cosine.schema
include /usr/share/openldap2.4/schema/inetorgperson.schema
include /usr/share/openldap2.4/schema/nis.schema
include /usr/share/openldap2.4/schema/misc.schema
include /usr/share/openldap2.4/schema/openldap.schema
include /usr/share/openldap2.4/schema/ppolicy.schema
include /usr/share/openldap2.4/schema/corba.schema
loglevel 296
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/ldap2.4/slapd.pid
argsfile /var/run/ldap2.4/slapd.args
access to attrs=userPassword
by self write
by users read
by anonymous auth
#access to attrs=shadowLastChange
# by self write
# by * auth
access to *
by * read
access to *
by dn.base="cn=Manager,dc=comverse-in,dc=com" read
by * break
# Load dynamic backend modules:
# modulepath /usr/lib/openldap
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
#TLSCipherSuite HIGH:MEDIUM:+SSLv2
#TLSCACertificateFile /etc/openldap2.4/cacerts/cacert.pem
#TLSCertificateFile /etc/openldap2.4/cacerts/slapd-cert.pem
#TLSCertificateKeyFile /etc/openldap2.4/cacerts/slapd-key.pem
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
serverId 001
database bdb
suffix "dc=comverse-in,dc=com"
rootdn "cn=Manager,dc=comverse-in,dc=com"
rootpw {SSHA}9tKeVZfgKFCfgIFQxXt5esH0HhQk1dIS
# 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 {crypt}ijFYNcSNctBYg
# 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/ldap2.4
# 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
#index sudoUser eq
index sudoUser eq
index member eq
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
#index objectclass,entryCSN,entryUUID eq
# Load dynamic backend modules:
# modulepath /usr/lib/openldap
modulepath /usr/lib/openldap2.4
# modules available in openldap-servers-overlays RPM package:
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload denyop.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload smbk5pwd.la
moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# modules available in openldap-servers-sql RPM package:
# moduleload back_sql.la
syncrepl rid=123
provider=ldap://devonly144.comverse-in.com
type=refreshAndPersist
interval=00:00:01:00
searchbase="dc=comverse-in,dc=com"
filter="(objectClass=*)"
scope=sub
attrs="*"
schemachecking=off
bindmethod=simple
binddn="cn=Manager,dc=comverse-in,dc=com"
credentials=sonora
index objectClass,entryCSN,entryUUID eq
mirrormode true
overlay syncprov
syncprov-checkpoint 100 10
overlay ppolicy
ppolicy_default "cn=DefaultPassword,ou=pwpolicies,dc=comverse-in,dc=com"
ppolicy_hash_cleartext
ppolicy_use_lockout
#SUDOERS_BASE=ou=SUDOers,dc=comverse-in,dc=com
# 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
#replogfile /var/lib/ldap/openldap-master-replog
#replica uri=ldaps://rht144.comverse-in.com:389 starttls=critical
Server2 slapd.conf file
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/share/openldap2.4/schema/sudo.schema
include /usr/share/openldap2.4/schema/core.schema
include /usr/share/openldap2.4/schema/cosine.schema
include /usr/share/openldap2.4/schema/inetorgperson.schema
include /usr/share/openldap2.4/schema/nis.schema
include /usr/share/openldap2.4/schema/misc.schema
include /usr/share/openldap2.4/schema/openldap.schema
include /usr/share/openldap2.4/schema/ppolicy.schema
include /usr/share/openldap2.4/schema/corba.schema
loglevel 296
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/ldap2.4/slapd.pid
argsfile /var/run/ldap2.4/slapd.args
access to attrs=userPassword
by self write
by users read
by anonymous auth
#access to attrs=shadowLastChange
# by self write
# by * auth
access to *
by * read
access to *
by dn.base="cn=Manager,dc=comverse-in,dc=com" read
by * break
# Load dynamic backend modules:
# modulepath /usr/lib/openldap
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
#TLSCipherSuite HIGH:MEDIUM:+SSLv2
#TLSCACertificateFile /etc/openldap2.4/cacerts/cacert.pem
#TLSCertificateFile /etc/openldap2.4/cacerts/slapd-cert.pem
#TLSCertificateKeyFile /etc/openldap2.4/cacerts/slapd-key.pem
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
serverId 002
#database bdb
database bdb
#suffix "dc=comverse-in,dc=com"
suffix "dc=comverse-in,dc=com"
#rootdn "cn=Manager,dc=comverse-in,dc=com"
rootdn "cn=Manager,dc=comverse-in,dc=com"
rootpw {SSHA}4qLml3DcOyfwiKlN/garIms4a8fmsNkx
#rootpw sonora
# 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 {crypt}ijFYNcSNctBYg
# 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/ldap2.4
# 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
#index sudoUser eq
index sudoUser eq
index member eq
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
#index objectclass,entryCSN,entryUUID eq
# Load dynamic backend modules:
# modulepath /usr/lib/openldap
modulepath /usr/lib/openldap2.4
# modules available in openldap-servers-overlays RPM package:
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload denyop.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload smbk5pwd.la
moduleload syncprov.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la
# modules available in openldap-servers-sql RPM package:
# moduleload back_sql.la
overlay ppolicy
ppolicy_default "cn=DefaultPassword,ou=pwpolicies,dc=comverse-in,dc=com"
ppolicy_hash_cleartext
ppolicy_use_lockout
#SUDOERS_BASE=ou=SUDOers,dc=comverse-in,dc=com
# 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
#replogfile /var/lib/ldap/openldap-master-replog
#replica uri=ldaps://rht144.comverse-in.com:389 starttls=critical binddn="cn=Manager,dc=comverse-in,dc=com" bindmethod=simple credentials=sonora
#serverId 2
syncrepl rid=124
provider=ldap://uplite98.comverse-in.com
type=refreshAndPersist
interval=00:00:01:00
searchbase="dc=comverse-in,dc=com"
filter="(objectClass=*)"
scope=sub
attrs="*"
schemachecking=off
bindmethod=simple
binddn="cn=Manager,dc=comverse-in,dc=com"
credentials=sonora
#updateref ldap://uplite98.comverse-in.com
index objectClass,entryCSN,entryUUID eq
mirrormode true
overlay syncprov
syncprov-checkpoint 100 10
Thanks and Regards,
Naga Chaitanya
-----Original Message-----
From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net]
Sent: Friday, August 26, 2011 7:15 PM
To: Naga Chaitanya Palle
Cc: openldap-technical(a)openldap.org
Subject: Re: N-way multi master configuration issue
On Friday, 26 August 2011 15:28:13 Naga Chaitanya Palle wrote:
> Hi buchan,
>
> My server 1 is uplite98.comverse-in.com. In its slapd.conf, I have syncrepl
> pointing to server 2 devonly144.comverse-in.com and vice versa for
> server2.
Then your serverid (and, it should actually be serverId) is wrong:
> > serverid 124 ldap://devonly144.comverse-in.com
> > syncrepl rid=124
> >
> > provider=ldap://devonly144.comverse-in.com:389
The URI form of serverId is useful if you have the same configuration on all
your masters, in which case the listening address of your server must match
one of the URIs. You may want to use this form for now:
serverId 1
If your serverId's weren't correct (check the contextCSNs), you should
probably re-import an export of one server on the other one.
> I did not exactly understand what you indicated.
> Can you please be more specific about what changes needs to be done in the
> slapd.conf file?
In a multi-master setup, each server should be replicating off *all* servers,
including itself.
> Thanks and Regards,
> Naga Chaitanya
>
> -----Original Message-----
> From: Buchan Milne [mailto:bgmilne@staff.telkomsa.net]
> Sent: Friday, August 26, 2011 6:56 PM
> To: openldap-technical(a)openldap.org
> Cc: Naga Chaitanya Palle
> Subject: Re: N-way multi master configuration issue
>
> On Friday, 26 August 2011 12:56:38 Naga Chaitanya Palle wrote:
> > Hi,
> >
> > I am trying to set up N-way multimaster configuration using syncrepl on
> > openldap2.4 for RHEL 5.4
> >
> > Currently I am using two masters for testing.
> >
> > The slapd.conf on server1 is
> > moduleload syncprov.la
> > serverid 124 ldap://devonly144.comverse-in.com
> > syncrepl rid=124
> >
> > provider=ldap://devonly144.comverse-in.com:389
> > type=refreshAndPersist
> > interval=00:00:01:00
> > searchbase="dc=comverse-in,dc=com"
> > filter="(objectClass=*)"
> > scope=sub
> > attrs="*"
> > schemachecking=off
> > bindmethod=simple
> > binddn="cn=Manager,dc=comverse-in,dc=com"
> > credentials=sonora
> >
> > index objectClass,entryCSN,entryUUID eq
> > mirrormode true
> >
> > overlay syncprov
> > syncprov-checkpoint 100 10
> >
> >
> > The slapd.conf on server2 is
> > moduleload syncprov.la
> > serverid 123 ldap://uplite98.comverse-in.com
> > syncrepl rid=123
> >
> > provider=ldap://uplite98.comverse-in.com:389
> > type=refreshAndPersist
> > interval=00:00:01:00
> > searchbase="dc=comverse-in,dc=com"
> > filter="(objectClass=*)"
> > scope=sub
> > attrs="*"
> > schemachecking=off
> > bindmethod=simple
> > binddn="cn=Manager,dc=comverse-in,dc=com"
> > credentials=sonora
> >
> > index objectClass,entryCSN,entryUUID eq
> > mirrormode true
> >
> > overlay syncprov
> > syncprov-checkpoint 100 10
> >
> > But there is no data synchronization happening between the severs.
>
> Of course not, you have configured each server only to replicate from
> itself.
>
> > When I added test3 user on server1, it is not reflecting on server 2.
> > Same way when I added test4 user on server2 it is not reflecting on
> > server1.
> >
> > Please let me know what is missing in this configuration.
>
> syncrepl statements pointing to the other master.
>
> Regards,
> Buchan
>
>
>
>
> ===========================================================================
> ==== Please refer to http://www.aricent.com/legal/email_disclaimer.html for
> important disclosures regarding this electronic communication.
> ==========================================================================
> =====
===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
13 years, 9 months
Re: Dovecot can't connect to openldap over starttls
by Dan White
On 03/19/17 09:07 +0100, info(a)gwarband.de wrote:
>Am 2017-03-19 01:09, schrieb Dan White:
>>>>>>>On 03/17/2017 04:27 PM, info(a)gwarband.de wrote:
>>>>>>>> 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.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
# Read slapd.conf(5) for possible values
loglevel 256
There are more verbose options.
# Include ACLs
include /etc/ldap/acl.conf
>> What are the contents of /etc/ldap/ldap.conf?
>
> The ldap.conf has no difference to the dovecot-ldap.conf.
> See: https://gwarband.de/openldap/ldap.conf
> The point "TLS_REQCERT" is in both confs "demand". I've changed it
> after that.
>
> The ldapsearch command works also under the user "dovecot"
> See: https://gwarband.de/openldap/ldapsearch-dovecot.log
>
> ~$ ldapsearch -x -ZZ -D "cn=admin,dc=gwarband,dc=de" -W "cn=mailbox"
There is a difference in your binding DN.
Debug Dovecot's implementation of ldap_start_tls_s().
--
Dan White
8 years, 2 months
client server connection to LDAP/Kerberos
by Asmaa Ahmed
Hello,
I recently added Kerberos authentication to my LDAP server, and I am trying to connect the other servers to it.I have a server running Davical shared calendar, and I hope to get it working with my LDAP server again after Kerberos integration.
Here is my configuration which was working before the integration and my source is "http://wiki.davical.org/w/Configuration/LDAP#Kerberos_Authentication"
$c->authenticate_hook['config'] = array( 'host' => 'ldap.domain.com', //host name of your LDAP Server 'port' => '389', //port// 'bindDN' => 'cn=admin,dc=domain,dc=com', //DN to bind request to this server (if required)// 'passDN' => 'password', //Password of request bind 'baseDNUsers' => 'ou=People,dc=domain,dc=com', //where to look for valid user 'filterUsers' => 'objectClass=*', //filter which must validate a user according to RFC4515, i.e. surrounded by brackets 'protocolVersion' => 3, // important for simple auth (no sasl)// 'startTLS' => true, // securing your LDAP connection 'i_use_mode_kerberos' => "i_know_what_i_am_doing",
My slapd error logs:Jan 31 23:40:00 ldap slapd[1059]: conn=1273 fd=43 ACCEPT from IP=203.28.247.193:56887 (IP=0.0.0.0:389)Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=0 BIND dn="" method=128Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=0 RESULT tag=97 err=0 text=Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SRCH base="ou=People,dc=domain,dc=com" scope=2 deref=0 filter="(objectClass=*)"Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SRCH attr=uid modifyTimestamp cn mailJan 31 23:40:00 ldap slapd[1059]: conn=1273 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=Jan 31 23:40:00 ldap slapd[1059]: conn=1273 op=2 UNBIND
My OLC configuration:root@ldap:/var/log# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(|(cn=config)(olcDatabase={1}hdb))"dn: cn=configobjectClass: olcGlobalcn: configolcArgsFile: /var/run/slapd/slapd.argsolcAuthzRegexp: {0}uid=([^,]+),cn=domain.com,cn=gssapi,cn=auth uid=$1 ,ou=people,dc=domain,dc=comolcLogLevel: statsolcPidFile: /var/run/slapd/slapd.pidolcSaslRealm: DOMAIN.COMolcToolThreads: 1
dn: olcDatabase={1}hdb,cn=configobjectClass: olcDatabaseConfigobjectClass: olcHdbConfigolcDatabase: {1}hdbolcDbDirectory: /var/lib/ldapolcSuffix: dc=domain,dc=comolcAccess: {0}to attrs=userPassword,shadowLastChange by anonymous auth by * no neolcAccess: {1}to dn.subtree="ou=krb5,dc=domain,dc=com" by dn="c n=adm-srv,ou=krb5,domain,dc=com" write by dn="cn=kdc-srv,ou =krb5,domain,dc=com" read by * noneolcAccess: {2}to attrs=loginShell,gecos by self write by users read by * noneolcAccess: {3}to dn.base="" by * readolcAccess: {4}to * by users read by * noneolcLastMod: TRUEolcRootDN: uid=admin,ou=people,domain,dc=com
Any suggestion to fix the binding and get my search working again with kerberos authentication ?
Thanks.
12 years, 4 months
Re: Openldap for proxy AD
by Willy Ramos
Hi,
Yes, there are some entries with the attribute userPassword like this value.
But don´t found the entries, when I put the password.
Thanks.
Em 25/11/2013 12:54, Peter Gietz escreveu:
> Hi,
>
> since it is working for a lot of people (including some of our
> customers) it seems that you are doing something wrong.
>
> What about the contents of your entries: Are you sure that you have the
> attribute userPassword with the value
>
> {SASL}<username>@<AD-realm>
>
> set in all entries that are to bind via AD?
>
> Cheers,
>
> Peter
>
>
> Am 22.11.2013 15:05, schrieb Willy Ramos:
>> Em 22/11/2013 09:21, Andrew Findlay escreveu:
>>> On Wed, Nov 20, 2013 at 02:55:43PM -0200, Willy Ramos wrote:
>>>
>>>> Subject: Re: Openldap for proxy AD
>>> Have you tried following the examples in the Admin Guide?
>>>
>>> http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authentica…
>>>
>>>
>>> There is a detailed setup and diagnosic guide there which should help
>>> you
>>> to isolate the problem.
>>>
>>> Andrew
>> Thanks Andrew,
>>
>> I was testing based in this Admin Guide.
>>
>> When I Check that the user can bind to AD:
>>
>> ldapsearch -x -Hldap://dc1.example.com/ \
>> -D cn=user,cn=Users,DC=ad,DC=example,DC=com \
>> -w userpassword \
>> -b cn=user,cn=Users,DC=ad,DC=example,DC=com \
>> Or with
>> -s base \
>> "(objectclass=*)"
>> Or
>>
>> testsaslauthd -u user -p userpassword
>>
>> It´s works.
>>
>> I was reading about and Seems don´t find the schemas of objectclass or
>> userPassword attribute;
>>
>> But I could not resolve yet.
>>
>> See the logs
>>
>>
>> Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 ACCEPT from
>> IP=127.0.0.1:51698 (IP=0.0.0.0:636)
>> Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 TLS established
>> tls_ssf=256 ssf=256
>> Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 EXT
>> oid=1.3.6.1.4.1.1466.20037
>> Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 STARTTLS
>> Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=0 RESULT oid= err=1
>> text=TLS already started
>> Nov 22 11:57:30 mail slapd[18370]: conn=1192 op=1 UNBIND
>> Nov 22 11:57:30 mail slapd[18370]: conn=1192 fd=11 closed
>>
>> Thanks.
>>
--
Att.
Willy R. M
11 years, 6 months