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, 1 month
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/
16 years, 6 months
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, 1 month
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, 2 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, 2 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
7 years, 8 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.
11 years, 9 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
10 years, 12 months
cn=config replication stops after adding olcAccess entries
by Jan Hugo Prins
Hello,
I'm trying to setup a new MMR cluster.
I started the installation using the documentation from:
https://www.openldap.org/doc/admin24/replication.html#N-Way%20Multi-Master
OS: CentOS 7.7.
CentOS RPM packages OpenLDAP version 2.4.44-21
The base installation works fine, all schema's loaded etc.
At first I was thinking everything was fine, until I started testing
failure scenario's.
When I tried to rebuild a failed node I noticed that it wouldn't be
populated.
cn=config was empty except for the base config and only some data was
replicated.
After a lot of searching I found that adding any olcAccess rules would
destroy the replication.
With the olcAccess lines in the config below only the schemas are
replicated. When I remove all olcAccess lines all replication works.
The base config I use for a node looks like this:
dn: cn=config
objectClass: olcGlobal
cn: config
olcServerID: 1 ldap://ldap01.internal
olcServerID: 2 ldap://ldap02.internal
olcServerID: 3 ldap://ldap03.internal
olcPidFile: /var/run/openldap/slapd.pid
olcLogLevel: 16512
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=config
olcRootPW: eich4mieceeB6ma9ehah
olcSyncRepl: rid=001 provider=ldap://ldap01.internal binddn="cn=config"
bindmethod=simple
credentials=XXXXXX searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 +" timeout=1
olcSyncRepl: rid=002 provider=ldap://ldap02.internal binddn="cn=config"
bindmethod=simple
credentials=XXXXXX searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 +" timeout=1
olcSyncRepl: rid=003 provider=ldap://ldap03.internal binddn="cn=config"
bindmethod=simple
credentials=XXXXXX searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 +" timeout=1
olcMirrorMode: TRUE
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/lib64/openldap/
olcModuleLoad: syncprov.la
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
The complete config on a running node looks like this:
dn: cn=config
objectClass: olcGlobal
objectClass: olcConfig
objectClass: top
cn: config
olcLogLevel: 16512
olcPidFile: /var/run/openldap/slapd.pid
olcServerID: 1 ldap://ldap01.internal
olcServerID: 2 ldap://ldap02.internal
olcServerID: 3 ldap://ldap03.internal
dn: cn=module{0},cn=config
objectClass: olcModuleList
objectClass: olcConfig
objectClass: top
cn: module{0}
olcModuleLoad: {0}syncprov.la
olcModulePath: /usr/lib64/openldap/
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcConfig
objectClass: olcFrontendConfig
objectClass: top
olcAccess: {0}to dn.subtree="dc=domain,dc=com"
attrs=userPassword,shadowLastChange by self write by
dn.base="cn=bbsyncrepl, dc=domain,dc=com" read by anonymous auth
by * none
olcAccess: {1}to dn.subtree="dc=domain,dc=com" attrs=sambaNTPassword
by self write by dn.base="cn=bbsyncrepl, dc=domain,dc=com" read
by anonymous auth by * none
olcAccess: {2}to dn.subtree="dc=domain,dc=com" attrs=sambaLMPassword
by self write by dn.base="cn=bbsyncrepl, dc=domain,dc=com" read
by anonymous auth by * none
olcAccess: {3}to dn.subtree="dc=domain,dc=com" by
dn.base="cn=bbsyncrepl,dc=domain,dc=com" read by self write by * read
olcAddContentAcl: FALSE
olcDatabase: {-1}frontend
olcLastMod: TRUE
olcMaxDerefDepth: 0
olcMonitoring: TRUE
olcReadOnly: FALSE
olcSchemaDN: cn=Subschema
olcSyncUseSubentry: FALSE
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
objectClass: olcConfig
objectClass: top
olcDatabase: {0}config
olcMirrorMode: TRUE
olcMonitoring: TRUE
olcRootDN: cn=config
olcRootPW: XXXXXX
olcSyncrepl: {0}rid=001 provider=ldap://ldap01.internal
binddn="cn=config" bindmethod=simple credentials=XXXXXX
searchbase="cn=config" type=refreshAndPersist retry="5 5 300 +" timeout=1
olcSyncrepl: {1}rid=002 provider=ldap://ldap02.internal
binddn="cn=config" bindmethod=simple credentials=XXXXXX
searchbase="cn=config" type=refreshAndPersist retry="5 5 300 +" timeout=1
olcSyncrepl: {2}rid=003 provider=ldap://ldap03.internal
binddn="cn=config" bindmethod=simple credentials=XXXXXX
searchbase="cn=config" type=refreshAndPersist retry="5 5 300 +" timeout=1
dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config
objectClass: olcSyncProvConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {0}syncprov
dn: olcOverlay={1}syncprov,olcDatabase={0}config,cn=config
objectClass: olcSyncProvConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {1}syncprov
dn: olcDatabase={1}bdb,cn=config
objectClass: olcBdbConfig
objectClass: olcDatabaseConfig
objectClass: olcConfig
objectClass: top
olcAddContentAcl: FALSE
olcDatabase: {1}bdb
olcDbCacheFree: 1
olcDbCacheSize: 1000000
olcDbCheckpoint: 512 5
olcDbDirectory: /var/lib/ldap
olcDbDirtyRead: FALSE
olcDbDNcacheSize: 0
olcDbIDLcacheSize: 0
olcDbIndex: default sub
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn eq,subinitial
olcDbIndex: uid pres,eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: mailLocalAddress pres,eq
olcDbIndex: memberUid eq
olcDbIndex: mail eq,subinitial
olcDbIndex: mailRoutingAddress pres,eq
olcDbIndex: sambaSID eq
olcDbIndex: sn eq,subinitial
olcDbIndex: sambaPrimaryGroupSID eq
olcDbIndex: givenName eq,subinitial
olcDbIndex: sendmailMTAHost pres,eq,sub
olcDbIndex: sambaDomainName eq
olcDbIndex: sendmailMTAKey pres,eq,sub
olcDbIndex: sendmailMTAMapName pres,eq
olcDbIndex: sendmailMTAAliasValue pres,eq
olcDbIndex: sendmailMTAMapValue pres,eq
olcDbIndex: sendmailMTAAliasGrouping pres,eq
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbNoSync: FALSE
olcDbSearchStack: 16
olcDbShmKey: 0
olcLastMod: TRUE
olcLimits: {0}dn.exact="cn=Manager,dc=domain,dc=com" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcLimits: {1}dn.exact="cn=bbsyncrepl,dc=domain,dc=com"
size.soft=unlimited size.hard=unlimited time.soft=unlimited
time.hard=unlimited
olcLimits: {2}dn.exact="cn=incontrol,dc=domain,dc=com"
size.soft=unlimited size.hard=unlimited time.soft=unlimited
time.hard=unlimited
olcMaxDerefDepth: 15
olcMirrorMode: TRUE
olcMonitoring: TRUE
olcReadOnly: FALSE
olcRootDN: cn=Manager,dc=domain,dc=com
olcRootPW: XXXXXX
olcSuffix: dc=domain,dc=com
olcSyncrepl: {0}rid=004 provider=ldap://ldap01.internal
binddn="cn=Manager,dc=domain,dc=com" bindmethod=simple
credentials=XXXXXX searchbase="dc=domain,dc=com" type=refreshAndPersist
interval=00:00:00:10 retry="5 5 300 5" timeout=1 network-timeout=0
starttls=no filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off
olcSyncrepl: {1}rid=005 provider=ldap://ldap02.internal
binddn="cn=Manager,dc=domain,dc=com" bindmethod=simple
credentials=XXXXXX searchbase="dc=domain,dc=com" type=refreshAndPersist
interval=00:00:00:10 retry="5 5 300 5" timeout=1 network-timeout=0
starttls=no filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off
olcSyncrepl: {2}rid=006 provider=ldap://ldap03.internal
binddn="cn=Manager,dc=domain,dc=com" bindmethod=simple
credentials=XXXXXX searchbase="dc=domain,dc=com" type=refreshAndPersist
interval=00:00:00:10 retry="5 5 300 5" timeout=1 network-timeout=0
starttls=no filter="(objectClass=*)" scope=sub attrs="*" schemachecking=off
dn: olcOverlay={0}syncprov,olcDatabase={1}bdb,cn=config
objectClass: olcSyncProvConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: {0}syncprov
In the logging I see the following:
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access to "cn=config" "entry" requested
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access
granted
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access granted by manage(=mwrscxd)
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access to "cn=config" "objectClass" requested
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access
granted
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access granted by manage(=mwrscxd)
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access to "cn=config" "entry" requested
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access
granted
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access granted by manage(=mwrscxd)
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access to "cn=config" "objectClass" requested
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access
granted
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access granted by manage(=mwrscxd)
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access to "cn=config" "entry" requested
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access
granted
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access granted by manage(=mwrscxd)
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access to "cn=config" "objectClass" requested
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access
granted
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: search access granted by manage(=mwrscxd)
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e =>
access_allowed: read access to "cn=config" "entry" requested
Jan 27 09:37:34 radius01.internal slapd[16596]: 5e2ea14e <= root access
granted
But also:
Jan 27 09:38:36 radius01.internal slapd[16596]: 5e2ea18c do_syncrep2:
rid=003 LDAP_RES_SEARCH_RESULT
Jan 27 09:38:36 radius01.internal slapd[16596]: 5e2ea18c do_syncrep2:
rid=003 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform
Jan 27 09:38:36 radius01.internal slapd[16596]: 5e2ea18c do_syncrep2:
rid=003 (53) Server is unwilling to perform
Jan 27 09:38:36 radius01.internal slapd[16596]: 5e2ea18c do_syncrepl:
rid=003 rc -2 retrying
Jan 27 09:39:30 radius01.internal slapd[16596]: 5e2ea1c2 do_syncrep2:
rid=002 LDAP_RES_SEARCH_RESULT
Jan 27 09:39:30 radius01.internal slapd[16596]: 5e2ea1c2 do_syncrep2:
rid=002 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform
Jan 27 09:39:30 radius01.internal slapd[16596]: 5e2ea1c2 do_syncrep2:
rid=002 (53) Server is unwilling to perform
Jan 27 09:39:30 radius01.internal slapd[16596]: 5e2ea1c2 do_syncrepl:
rid=002 rc -2 retrying
Something else I see, when I use jxplorer to look at the content of a
server using the cn=config credentials I would expect to see all values
including the empty values. On a server without olcAccess lines I see
this, but when there are olcAccess lines I only see the configured
values. All unset values are not visible.
Any help is appreciated.
Thank you very much.
Jan Hugo Prins
4 years, 10 months
Re: Authenticate to ldap using Kerberos
by Howard Chu
Dan White wrote:
> On 09/09/10 20:05 -0700, Russ Allbery wrote:
>> Wouter van Marle<wouter(a)squirrel-systems.com> writes:
>>> At this moment, I can connect to my ldap server from Evolution,
>>> authenticated. I have to enter a username and a password in my evo
>>> settings, which one way or another is communicated to openldap, which
>>> then checks this un/pw combo and considers it valid to give the
>>> information.
>>
>> If you are using Kerberos, you should never have to enter your username
>> and password into anything that isn't kinit or your initial authentication
>> to your system. If you do, that something is broken and is not using
>> Kerberos properly. Period.
>
> So if the poster had stated that he wanted to perform PAM authentication
> for his simple binds, I don't think he'd be confronted with such a violent
> reaction. However, from the standpoint of slapd, that's exactly what he's
> wanting to do.
>
> Performing simple binds have precisely the same negative security footprint
> regardless of where his passwords may be stored. I'm assuming Evolution
No, it makes a difference, and the fact that you're not aware of the
difference demonstrates that you haven't thought it through enough to be
qualified to render an opinion on it.
Kerberos is secure precisely because client passwords are never transmitted
across the network. Period. When you break that guarantee, everything else
about the Kerberos system is jeopardized, and typically, when Kerberos is in
use at a site, there's a large ecosystem of apps dependent on it and all of
their security goes down the drain at the same time.
> supports ldaps or STARTTLS, which would go a long way in mitigating that
> risk. If it didn't support TLS, I'd think that'd be a much more urgent
ldaps or TLS might be ok, assuming you're not using a broken SSL
implementation. Abusing Kerberos in the requested way and relying on other
security systems to take up the slack is opening yourself up to a whole world
of unintended consequences, and we need only look at Debian last year to see
how real those problems may be.
> focus (GSSAPI only provides 56 bits of encryption).
The strength of GSSAPI's encryption layer is irrelevant in this discussion
since, when used properly, it NEVER exposes the client's secret key to anybody
else.
>> SASL is what you do when you implement Kerberos properly. Evolution is
>> not doing this. It's either implementing a broken version of SASL where
>> it only implements a single mechanism (PLAIN), or it's actually not doing
>> SASL at all (most likely). The problem is exactly that Evolution is not
>> properly implementing Kerberos SASL mechanisms.
>
> Would you agree that any application which does not support the full range
> of SASL mechanisms is broken? What about simple binds? Would you suggest
> that OpenLDAP remove all support for simple binds? If not, why not?
RFC4513 pretty much deprecates Simple Binds. Certainly it discourages using
them on an unprotected session, and the OP has already stated that he has yet
to get TLS working. And applications don't have to implement specific SASL
mechanisms, that's all hidden inside libldap and libsasl2. All they have to do
is use the right libldap calls and they automatically get support for all
mechanisms, currently known as well as future mechs.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
14 years, 2 months