RE: Multi Master OpenLdap.
by arun.sasi1＠wipro.com
Team any update…
From: Arun Sasi V (WI01 - Manage IT)
Sent: Monday, July 11, 2011 3:20 PM
To: E.S. Rosenberg
Cc: openldap-technical(a)openldap.org
Subject: RE: Multi Master OpenLdap.
And also I could see below message
nonpresent_callback: rid=003 present UUI
Thanks,
-Arun
From: Arun Sasi V (WI01 - Manage IT)
Sent: Monday, July 11, 2011 1:36 PM
To: 'E.S. Rosenberg'
Cc: openldap-technical(a)openldap.org
Subject: RE: Multi Master OpenLdap.
Thank you very much Eli for concidering my issue. Here is my scenario...
I couldn’t find any abnormality in log files and also I never seen any deletion logs in the server. Slapd will go for hang and some ID`s will get disappear same will be replicate to slaves too. Mainly Groups and Computer accounts
I can see some UNBIND and connection lost logs from one server and another multimaster server from
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138411 op=24 SEARCH RESULT tag=101 err=32 nentries=0 text=
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138424 op=12 SRCH base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaGroupMapping)(gidNumber=65534))"
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138424 op=12 SRCH attr=gidNumber sambaSID sambaGroupType sambaSIDList description displayName cn objectClass
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138424 op=12 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138415 op=21 SRCH base="sambaDomainName=EMB,sambaDomainName=emb,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaTrustedDomainPassword)(sambaDomainName=emb))"
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138415 op=21 SEARCH RESULT tag=101 err=32 nentries=0 text=
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138385 op=46 SRCH base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaGroupMapping)(|(displayName=test)(cn=test)))"
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: conn=138385 op=46 SRCH attr=gidNumber sambaSID sambaGroupType sambaSIDList description displayName cn objectClass
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: <= bdb_equality_candidates: (displayName) not indexed
Jul 11 04:03:39 gb0135embldap01 slapd[9852]: <= bdb_equality_candidates: (cn) not indexed
Jul 11 04:07:53 gb0135embldap01 slapd[21335]: @(#) $OpenLDAP: slapd 2.4.15 (Mar 19 2009 10:07:59) $ ^Ibuildd@yellow:/build/buildd/openldap-2.4.15/debian/build/servers/slapd
Jul 11 04:07:54 gb0135embldap01 slapd[21337]: slapd starting
Jul 11 04:07:54 gb0135embldap01 slapd[21337]: conn=0 fd=23 ACCEPT from IP=[::1]:57016 (IP=[::]:389)
Jul 11 04:07:54 gb0135embldap01 slapd[21337]: conn=1 fd=24 ACCEPT from IP=134.32.44.37:40763 (IP=0.0.0.0:389)
OLCDATABSE
dn: olcDatabase={1}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=emb,dc=slb,dc=com
olcAccess: {0}to attrs=userPassword,shadowLastChange,sambaLMPassword,sambaNTPassword
by dn="cn=admin,dc=emb,dc=slb,dc=com" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by anonymous auth by self write
by * none
olcAccess: {1}to dn.base="" by * read
#Enable Local Admin to add users in the Group and also SunOne to add users to country groups
olcAccess: {2}to dn.subtree="ou=groups,dc=emb,dc=slb,dc=com"
by set="user/uid & [cn=group-admin,ou=SuperGroups,dc=emb,dc=slb,dc=com]/memberuid" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by * read
#Enable Local Admin to add computers
olcAccess: {3}to dn.subtree="ou=Computers,dc=emb,dc=slb,dc=com"
by set="user/uid & [cn=group-admin,ou=SuperGroups,dc=emb,dc=slb,dc=com]/memberuid" write
by * read
#Enable shell-admin to set up local user access
olcAccess: {4}to attrs=loginShell,homeDirectory
by set="user/uid & [cn=shell-admin,ou=SuperGroups,dc=emb,dc=slb,dc=com]/memberuid" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by * read
#Enable write access to account sun-one-replication for sun ldap replication.
olcAccess: {5}to *
by dn="cn=admin,dc=emb,dc=slb,dc=com" write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=136.250.9.48 write
by dn="cn=sunone-replication,dc=emb,dc=slb,dc=com" peername.ip=163.185.18.238 write
by * read
olcLastMod: TRUE
olcDbCheckpoint: 512 30
olcDbConfig: {0}set_cachesize 0 2097152 0
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: loginShell eq
olcDbIndex: uid eq,pres,sub
olcDbIndex: memberUid eq,pres,sub
olcDbIndex: uniqueMember eq,pres
olcDbIndex: sambaSID eq
olcDbIndex: sambaPrimaryGroupSID eq
olcDbIndex: sambaGroupType eq
olcDbIndex: sambaSIDList eq
olcDbIndex: sambaDomainName eq
olcDbIndex: default sub
structuralObjectClass: olcHdbConfig
entryUUID: f479600a-5f34-102f-8ddd-3ff046e70702
creatorsName: cn=admin,cn=config
createTimestamp: 20100928101442Z
olcRootDN: cn=admin,dc=emb,dc=slb,dc=com
olcSyncrepl: {0}rid=003 provider=ldap://gb0135embldap01.emb.slb.com binddn="cn
=admin,dc=emb,dc=slb,dc=com" bindmethod=simple credentials=Bsl@121z searchbas
e="dc=emb,dc=slb,dc=com" type=refreshOnly interval=00:00:00:10 retry="5 5 300
5" timeout=1 starttls=yes
olcSyncrepl: {1}rid=004 provider=ldap://ae0042embldap01.emb.slb.com binddn="cn
=admin,dc=emb,dc=slb,dc=com" bindmethod=simple credentials=Bsl@121z searchbas
e="dc=emb,dc=slb,dc=com" type=refreshOnly interval=00:00:00:10 retry="5 5 300
5" timeout=1 starttls=yes
olcMirrorMode: TRUE
entryCSN: 20100928191927.932499Z#000000#001#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20100928191927Z
Ldap Version
@(#) $OpenLDAP: slapd 2.4.15 (Mar 19 2009 10:07:59) $
Operating system
Distributor ID: Ubuntu
Description: Ubuntu 9.04
Release: 9.04
Codename: jaunty
Thanks,
-Arun
-----Original Message-----
From: E.S. Rosenberg [mailto:esr@g.jct.ac.il]
Sent: Monday, July 11, 2011 12:58 PM
To: Arun Sasi V (WI01 - Manage IT)
Cc: openldap-technical(a)openldap.org
Subject: Re: Multi Master OpenLdap.
Have you tried raising the loglevel?
Are the schemas the same between the servers?
Is time in sync between the servers?
What versions are you dealing with?
You don't provide a lot of info and most of us are not clairvoyant....
Regards,
Eli
2011/7/11 <arun.sasi1(a)wipro.com>:
>
>
>
>
> Thanks,
>
> -Arun
>
>
>
> From: Arun Sasi V (WI01 - Manage IT)
> Sent: Wednesday, July 06, 2011 5:46 PM
> To: 'openldap-technical(a)openldap.org'
> Subject: Multi Master OpenLdap.
>
>
>
> Hello Team,
>
>
>
> I have configured Multi-master Mirror mode replica setup in our environment.
> We have 3 regions slave Ldap server which is read only and two location we
> have configured as mirror mode replica Ldap. My problem here is…
>
>
>
> Master Ldap is going hang some times and some ID`s are disappearing from the
> master server. I couldn’t find any logs over there for why ID`s are
> disappearing and also why Ldap is going hung state.
>
>
>
> Thanks & Regards,
>
> Arun Sasi V
>
> Please do not print this email unless it is absolutely necessary.
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient should
> check this email and any attachments for the presence of viruses. The
> company accepts no liability for any damage caused by any virus transmitted
> by this email.
>
> www.wipro.com
Please do not print this email unless it is absolutely necessary.
The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments.
WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email.
www.wipro.com
13 years, 3 months
Re: N-way multi master configuration issue
by Dmitriy Kirhlarov
On 08/30/2011 10:15 PM, Naga Chaitanya Palle wrote:
> Hi,
>
> I was able to get the syncronization working between 2 providers.
> I had to remove data on both the servers and start from beginning.
> It worked.
>
> Now i am facing another issue.
> In case of single provider-client configuration, fot tls, i used to generate certificate on server and copy the same certificate to client for encrypted communication between provider and client.
>
> Now in case of N-way multimaster, i created server1 certificate and copied that certificate to server2 and vice versa. but there is no communication happening between the servers now.
>
> Can you please let me know how to use tls with N-way multimaster for N=2 and N>2.
1. You can use one certificate with several names
(http://therowes.net/~greg/2008/01/08/creating-a-certificate-with-multiple-h…)
2. or you can use one certificate per host (name inside certificate
should be the same, as dns-name for clients connections)
WBR
>
> Thanks and Regards,
> Naga Chaitanya
> ________________________________________
> 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: Issues with resetting user password
by Sami Ait Ali Oulahcen
> On Sep 21, 2020, at 22:28, CLARKE, ED C <ec4397(a)att.com> wrote:
>
> Hello Quanah,
>
> I appreciate your help, and I wanted to give you some insight on how IBM set up our LDAP server regarding password changes.
> Below is an example what we have, essentially the .sh script performs an ldapmodify operation, using the ResetPW.ldif file.
>
> ResetPW.sh ***** Reset password shell script ********
> $ cat ResetPW.sh
> #/bin/bash
>
> ldapmodify -h 127.0.0.1 -D "cn=Manager,dc=att,dc=com" -w LinuxONE -x -f /root/ResetPW.ldif
I really hope it’s not the real one.
> ----- root pdprfsl4.sldc.sbc.com /root -----
>
> ResetPW.ldif:
> $ cat ResetPW.ldif
> #
> dn: uid=foxdiv,ou=People,dc=att,dc=com
> changetype: modify
> replace: pwdReset
> pwdReset: TRUE
> -
> replace: userPassword
> userPassword: XXXXXXXXXX
> -
> ----- root pdprfsl4.sldc.sbc.com /root -----
>
> This process has been working, if this is not ideal, then I will make any changes that you recommend.
> Below is the results of a search command & the commands that you gave me:
>
> --- ec4397 Mon Sep 21 09:22:34 CDT 2020 pdprfsl4 /home/ec4397 ---
> $ sudo ldapsearch -x -b "uid=ec4397,ou=People,dc=att,dc=com" -H ldapi:/// -D "cn=Manager,dc=att,dc=com" -W
> Enter LDAP Password:
> # extended LDIF
> #
> # LDAPv3
> # base <uid=ec4397,ou=People,dc=att,dc=com> with scope subtree
> # filter: (objectclass=*)
> # requesting: ALL
> #
>
> # ec4397, People, att.com
> dn: uid=ec4397,ou=People,dc=att,dc=com
> uid: ec4397
> cn: ec4397
> objectClass: account
> objectClass: posixAccount
> objectClass: top
> objectClass: shadowAccount
> shadowLastChange: 17780
> shadowMin: 0
> shadowMax: 99999
> shadowWarning: 7
> loginShell: /bin/bash
> uidNumber: 2000
> gidNumber: 1001
> homeDirectory: /home/ec4397
> userPassword:: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= *** I commented this out ****
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
> --- ec4397 Mon Sep 21 09:22:34 CDT 2020 pdprfsl4 /home/ec4397 ---
>
> --- ec4397 Mon Sep 21 09:22:34 CDT 2020 pdprfsl4 /home/ec4397 ---
> $ sudo ldapwhoami -x -H ldapi:/// -D uid=foxdiv,ou=People,dc=att,dc=com -W
> [sudo] password for ec4397:
> Enter LDAP Password:
> ldap_bind: Invalid credentials (49)
> --- ec4397 Mon Sep 21 09:22:34 CDT 2020 pdprfsl4 /home/ec4397 ---
>
> Any other tests that you would like me to run?
>
> Thanks,
> Ed
>
>
>
> -----Original Message-----
> From: Quanah Gibson-Mount <quanah(a)symas.com>
> Sent: Friday, September 18, 2020 4:46 PM
> To: CLARKE, ED C <ec4397(a)att.com>; openldap-technical(a)openldap.org
> Subject: RE: Issues with resetting user password
>
>
>
> --On Friday, September 18, 2020 2:42 PM -0700 Quanah Gibson-Mount <quanah(a)symas.com> wrote:
>
>> Nothing you've provided shows any attempt to connect to the ldap
>> server using an SIMPLE BIND with the user DN
>> "uid=foxdiv,ou=People,dc=att,dc=com" and a password.
>
> As an example, the correct way to test the user password change went through would be something like:
>
> ldapwhoami -x -H ldap://ldap.example.com:389/ -D uid=foxdiv,ou=People,dc=att,dc=com -W
>
>
> If slapd is running on ldaps, adjust the URI accordingly. If it's on port
> 389 but requires startTLS, add the -ZZ option, etc.
>
> You will be prompted for the password for the LDAP user. If the operation
> succeeds, then the password was correctly updated in LDAP.
>
> It sounds as though you may be attempting *nix <-> ldap integration, but
> that hasn't been specified. Regardless, the above ldapwhoami command is
> the next step in confirming whether or not the password was correctly
> changed and accepted on the user side. If that works, and you're
> attempting the *nix<->ldap integration and *that* is not working, it would
> imply that the integration is not configured correctly.
>
>
> Regards,
> Quanah
>
>
> --
>
> Quanah Gibson-Mount
> Product Architect
> Symas Corporation
> Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.symas.com&d=DwICAg&… >
4 years, 1 month
Re: LDAP Crafted Search Request Access Allowed
by Net Warrior
Ok, thank you very much, I'm gonna review the configuration and follow your
advice.
Best regards.
2014-10-29 13:43 GMT-03:00 Andrew Findlay <andrew.findlay(a)skills-1st.co.uk>:
> On Wed, Oct 29, 2014 at 08:19:03AM -0300, Net Warrior wrote:
>
> > 200 Servers and 20 users
>
> OK - that means that you will not have problems with the default
> limits on result-set size (500 entries).
>
> > >I hope you don't really bind with the ROOTDN account!
> > NO! and I have a user to test the configuration but I do not use it to
> bind
> > purposes, but I could if I knew how to configure it.
>
> As you have quite a lot of servers and a policy of hiding all data
> from anonymous users, I would suggest having more than one LDAP-client
> account. Either create one per client server, or one per group of similar
> servers.
>
> I would suggest putting the client accounts in a dedicated part of the
> LDAP tree, so it might look like this:
>
> ou=Users,dc=server,dc=com POSIX user accounts
> ou=Groups,dc=server,dc=com POSIX groups
> ou=Clients,dc=server,dc=com Client machine accounts
>
> You need to get all your client machines to bind with their account DN
> and password before you start changing ACLs. Config file entries will look
> something like this:
>
> binddn cn=server1,ou=Clients,dc=server,dc=com
> bindpw SomeLongAndSecurePassword
>
> > >You should also add:
> > >tls_reqcert demand
> > >and you may want to consider restricting the connection to high-grade
> ciphers
> > e.g.:
> > >tls_ciphers HIGH:MEDIUM:@STRENGTH
> >
> > Both, client and server side right?
>
> Yes, but the keyword for slapd.conf is TLSCipherSuite
> and for ldap.conf it is TLS_CIPHER_SUITE
>
> Once you have *all* the clients using TLS and binding with their client
> account and password, you can start on ACLs. If your logging includes
> the 'stats' category (256) you will be able to see TLS setup and bind
> in the logs, e.g.:
>
> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 ACCEPT from
> IP=[::1]:43386 (IP=[::]:389)
> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 EXT
> oid=1.3.6.1.4.1.1466.20037
> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 STARTTLS
> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=0 RESULT oid= err=0
> text=
> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 fd=26 TLS established
> tls_ssf=128 ssf=128
> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND
> dn="cn=client234,ou=Clients,dc=server,dc=com" method=128
> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 BIND
> dn="cn=client234,ou=Clients,dc=server,dc=com" mech=SIMPLE ssf=0
> Oct 28 18:25:38 ldapserver slapd[4846]: conn=1009 op=1 RESULT tag=97 err=0
> text=
>
> After all that, the ACLs turn out to be really simple! Something like this
> will probably be close to what you need for the main database:
>
> access to attrs="userPassword"
> by self =w
> by * auth
>
> access to * by users read
>
> access to * by * none
>
> If you have a replica server then you will need to add an ACL giving read
> access
> to all attributes. This should go right at the top of the list, and will
> look something
> like this:
>
> access to * by dn.exact="cn=replicator,ou=Clients,dc=server,dc=com" read
>
> If you are using the Monitor database then you should probably protect it
> like this:
>
> access to dn.subtree="cn=Monitor"
> by users read
> by * none
>
> And to make sure that critical stuff like the root DSE and the schema can
> be
> read by everyone, add this to the global section of the config:
>
> access to * by * read
>
>
> Andrew
> --
> -----------------------------------------------------------------------
> | From Andrew Findlay, Skills 1st Ltd |
> | Consultant in large-scale systems, networks, and directory services |
> | http://www.skills-1st.co.uk/ +44 1628 782565 |
> -----------------------------------------------------------------------
>
10 years
RE: SSL handshake failure
by Bryce Powell
I managed to get this working, mostly by following directions in:
http://www.openldap.org/doc/admin24/tls.html
http://www.openldap.org/faq/data/cache/1514.html
Note that these steps work for my combination of OS and OpenLDAP package, as detailed in my initial posting.
My server and CA certificates were in PEM format, along with a password protected private key:
cso_root_ca.pem
cso_functional_ca.pem
cso_issuing_ca.pem
FQHostName.cert.pem
FQHostName.cert.keysecure.pem
* Decrypt the private key:
openssl rsa -in FQHostName.keysecure.pem -out FQHostName.key.pem
When prompted, enter the pass phrase for the private key.
* Convert the server cert/key pair to PKCS format:
openssl pkcs12 -export -inkey FQHostName.key.pem -in FQHostName.cert.pem -out FQHostName.cert.p12 -nodes -name 'FQHostName'
When prompted, enter a blank Export Password by hitting ENTER.
* Create the certutil certificate database:
certutil -N -d /etc/openldap/cacerts
When prompted, enter a new password for the key database.
* Remove the key database password:
certutil -d /etc/openldap/cacerts -W
When prompted, enter the current password for the key database.
e.g. Enter Password or Pin for "NSS Certificate DB":
When prompted, press ENTER to specify a blank new password.
Enter new password:
Re-enter password:
Password changed successfully.
* Import the CA chain:
certutil -A -d /etc/openldap/cacerts -n "CSO Root CA" -t CT,, -a -i cso_root_ca.pem
certutil -A -d /etc/openldap/cacerts -n "CSO Functional CA" -t CT,, -a -i cso_functional_ca.pem
certutil -A -d /etc/openldap/cacerts -n "CSO Issuing CA" -t CT,, -a -i cso_issuing_ca.pem
* Add the server certificate/key pair:
pk12util -i FQHostName.cert.p12 -d /etc/openldap/cacerts
When prompted, enter blank password by pressing ENTER.
* list all the certificates, to confirm the imports:
certutil -d /etc/openldap/cacerts -L
Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI
FQHostName u,u,u
CSO Root CA CT,,
CSO Functional CA CT,,
CSO Issuing CA CT,,
* Ensure the correct permissions and ownership are set:
ll /etc/openldap/cacerts
-rw-r-----. 1 root ldap 65536 Feb 28 11:44 cert8.db
-rw-r-----. 1 root ldap 16384 Feb 28 11:44 key3.db
-rw-r-----. 1 root ldap 16384 Feb 24 15:46 secmod.db
chmod and/or chown as necessary.
* modify /etc/openldap/slapd.conf (I'm not using cn=config as defined in the slapd folder):
TLSCACertificatePath /etc/openldap/cacerts
TLSCertificateFile FQHostName
Note that the certificate file specified above is the name of the server certificate 'Nickname' (the certificate Common Name) in the NSS certificate database.
As a result, the following warning will be displayed after a slapd restart:
$ sudo service slapd restart
Stopping slapd: [ OK ]
FQHostName is not readable by "ldap" [WARNING]
Starting slapd: [ OK ]
I believe this WARNING can safely be ignored. The OpenLDAP documentation for the TLSCertificateFile setting states:
"When using Mozilla NSS, if using a cert/key database (specified with TLSCACertificatePath), this directive specifies the name of the certificate to use."
I suspect there is still some code that is looking for the existence of an actual certificate file, and is not looking in the cert/key database.
* Modify the ldap.conf file:
TLS_CACERTDIR /etc/openldap/cacerts
* Test connectivity using TLS:
$ ldapsearch -x -ZZ -H ldap://FQHostName
The ldap log file should contain entries that indicate a successful TLS connection:
Feb 28 14:18:21 HostName slapd[18833]: conn=1016 op=0 STARTTLS
Feb 28 14:18:21 HostName slapd[18833]: conn=1016 op=0 RESULT oid= err=0 text=
Feb 28 14:18:21 HostName slapd[18833]: conn=1016 fd=26 TLS established tls_ssf=256 ssf=256
Or,
$ ldapwhoami -x -ZZ -H ldap://FQHostName
anonymous
Feb 28 14:31:48 HostName slapd[18833]: conn=1017 op=0 STARTTLS
Feb 28 14:31:48 HostName slapd[18833]: conn=1017 op=0 RESULT oid= err=0 text=
Feb 28 14:31:48 HostName slapd[18833]: conn=1017 fd=42 TLS established tls_ssf=256 ssf=256
-----Original Message-----
From: Rich Megginson [mailto:rich.megginson@gmail.com]
Sent: February 23, 2012 4:12 PM
To: Bryce Powell
Cc: openldap-technical(a)openldap.org
Subject: Re: SSL handshake failure
On 02/23/2012 04:36 PM, Bryce Powell wrote:
> Thanks, Howard. Would you know how I can find a suitable package that uses openssl?
>
> I also tried moving the CA certificate chain file to the /etc/openldap/cacerts/ folder, splitting the file into 3 separate certificates, and running c_rehash to generate the hashed links. After modifying ldap.conf to use the cacerts folder instead of the ca file:
>
> TLS: file cso_root_ca.pem does not end in [.0] - does not appear to be a CA certificate directory file with a properly hashed file name - skipping.
> TLS: loaded CA certificate file /etc/openldap/cacerts/5de054ac.0 from CA certificate directory /etc/openldap/cacerts.
> TLS: loaded CA certificate file /etc/openldap/cacerts/241dd1a5.0 from CA certificate directory /etc/openldap/cacerts.
> TLS: loaded CA certificate file /etc/openldap/cacerts/95df54c4.0 from CA certificate directory /etc/openldap/cacerts.
> TLS: file cso_functional_ca.pem does not end in [.0] - does not appear to be a CA certificate directory file with a properly hashed file name - skipping.
> TLS: file cso_issuing_ca.pem does not end in [.0] - does not appear to be a CA certificate directory file with a properly hashed file name - skipping.
> TLS: error: connect - force handshake failure: errno 0 - moznss error -5938
> TLS: can't connect: TLS error -5938:Encountered end of file.
> ldap_err2string
> ldap_start_tls: Connect error (-11)
> additional info: TLS error -5938:Encountered end of file
>
> So I guess I'm stuck until I compile from scratch using openssl, or find a package that doesn't use Mozilla NSS.
If you want to try to get it working with Mozilla NSS, I'm here to help.
Can you provide the output from running the server with the -d 1 arguments?
> Thanks
>
> -----Original Message-----
> From: Howard Chu [mailto:hyc@symas.com]
> Sent: February 23, 2012 1:04 PM
> To: Bryce Powell
> Cc: openldap-technical(a)openldap.org
> Subject: Re: SSL handshake failure
>
> Bryce Powell wrote:
>> Hi,
>> I can't get slapd to respond successfully to TLS or SSL connections using an
>> RSA 2048-bit PEM certificate:
> You're using Mozilla NSS, so the fact that OpenSSL tools accept your cert
> doesn't help you.
>
> While a lot of good work has gone into the Mozilla NSS support, I would still
> say the MozNSS design is braindead and is not well suited for anything besides
> the Netscape/Mozilla browser codebase and should be avoided. Rebuild OpenLDAP
> using OpenSSL and I suspect these problems will disappear.
>
>> $ ldapsearch -x -ZZ -d1 -H ldap://FQDNhostname
>> TLS: loaded CA certificate file /etc/openldap/cacerts/FQDNhostname.cacert.pem.
>> TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory
>> TLS: error: connect - force handshake failure: errno 21 - moznss error -5938
>> TLS: can't connect: TLS error -5938:Encountered end of file.
>> ldap_err2string
>> ldap_start_tls: Connect error (-11)
>> additional info: TLS error -5938:Encountered end of file
>> $ openssl s_client -connect FQDNhostname:636 -CAfile
>> /etc/openldap/cacerts/FQDNhostname.cacert.pem
>> CONNECTED(00000003)
>> 140457427965768:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
>> failure:s23_lib.c:184:
>> ---
>> no peer certificate available
>> ---
>> No client certificate CA names sent
>> ---
>> SSL handshake has read 0 bytes and written 113 bytes
>> ---
>> New, (NONE), Cipher is (NONE)
>> Secure Renegotiation IS NOT supported
>> Compression: NONE
>> Expansion: NONE
>> ---
>> The following packages are installed on CentOS 6.2:
>> openldap-servers-2.4.23-20.el6.x86_64
>> openldap-2.4.23-20.el6.x86_64
>> openldap-clients-2.4.23-20.el6.x86_64
>> openssl-1.0.0-20.el6_2.1.x86_64
>> openssl-devel-1.0.0-20.el6_2.1.x86_64
>> gnutls-2.8.5-4.el6.x86_64
>> gnutls-devel-2.8.5-4.el6.x86_64
>> nss-pam-ldapd-0.7.5-14.el6_2.1.x86_64
>> The /etc/openldap/ldap.conf file contains:
>> TLS_CACERT /etc/openldap/cacerts/FQDNhostname.cacert.pem
>> , which contains a chain of three certificates (root CA,
>> intermediate/functional, and issuing).
>> The /etc/openldap/slapd.conf file contains:
>> TLSCipherSuite HIGH:+SSLv3
>> TLSCertificateFile /etc/openldap/FQDNhostname.cert.pem
>> TLSCertificateKeyFile /etc/openldap/FQDNhostname.key.pem
>> The server is acting as a proxy to an Active Directory, and therefore I only
>> have one LDAP database defined. My intention is to use LDAPS for communication
>> between the client and LDAP proxy servers:
>> database ldap
>> suffix "dc=abc,dc=local"
>> rebind-as-user
>> uri "ldap://IPaddress1/ ldap://IPaddress2/ ldap://IPaddress3/ ldap://IPaddress4/"
>> chase-referrals yes
>> noundeffilter yes
>> use-temporary-conn yes
>> The certificate and private key are located in /etc/openldap/, with the
>> following permissions :
>> -r--r-----. 1 ldap ldap 2076 Feb 21 15:30 FQDNhostname.cert.pem
>> -r--r-----. 1 ldap ldap 1675 Feb 21 15:35 FQDNhostname.sdi.key.pem
>> The CN of the certificate matches the FQDN host name of the LDAP server.
>> The private key is not password protected.
>> Everything checks out OK by testing the certificate using openssl:
>> $ openssl verify -purpose sslserver -CAfile
>> /etc/openldap/cacerts/FQDNhostname.cacert.pem /etc/openldap/FQDNhostname.cert.pem
>> /etc/openldap/FQDNhostname.cert.pem: OK
>> OpenSSL client/server connections work fine too:
>> openssl s_server -cert /etc/openldap/FQDNhostname.cert.pem -key
>> /etc/openldap/FQDNhostname.key.pem -cipher 'HIGH:+SSLv3
>> openssl s_client -connect FQDNhostname:4433 -CAfile
>> /etc/openldap/cacerts/FQDNhostname.cacert.pem
>> *Bryce Powell*
>
12 years, 8 months
Re: Syncrepl with subordinate databases
by Robert Minsk
A summary of what I posted below . I have several subordinate databases
and each subordinate database acquires there data via a refreshOnly
syncrepl. Instead of storing the contextCSN on the subordinate database
the contextCSN gets stored on the superior database. As a result the
superior databases contextCSN is the maximum of the subordinate
databases. This causes all but the syncprov server with the latest
contextCSN to abort the sync with "consumer state is newer than provider!"
It seems a configuration option needs to be added that allows storing
and reading of the contextCSN on the subordinate databases as well as
the maximum contextCSN on the superior database.
On 10/23/2013 05:12 PM, Robert Minsk wrote:
> 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.
--
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
openldap
by Aravind Arjunan
hi,
I got problem in openldap master,slave replication.
I had configured openldap in RHEL 5 as master/slave in syncrepl method (
refreshOnly)
my problem is my slave server is not getting replicated with master.
I had integrated openldap with postfix also,so when i restart the postfix
service i get the below error which i mentioned.
plz help me with this issue.
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/qmail.schema
# 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/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
# modulepath /usr/lib64/openldap
# moduleload back_bdb.la
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la
# The next three lines allow use of TLS for encrypting connections using a
# 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
# 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
#
access to attrs=userPassword
by self write
by dn="cn=syncuser,dc=panafnet,dc=com" read
by * auth
access to *
by dn="cn=syncuser,dc=panafnet,dc=com" read
by * read
# 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
#######################################################################
database bdb
suffix "dc=panafnet,dc=com"
rootdn "cn=Manager,dc=panafnet,dc=com"
rootpw {SSHA}9ma4wkvWQM2ws7E9q7qIgK9vQ2Rp4IhZ
# 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/ldap/panafnet.com
# 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 default sub
index entryCSN,entryUUID eq
# 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
overlay syncprov
syncprov-checkpoint 100 05
[root@master ~]#
=============================================================================
/etc/ldap.conf(master)
==============================================================================
#host 127.0.0.1
host 192.168.117.4 192.168.117.5
# The distinguished name of the search base.
base dc=panafnet,dc=com
# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.
binddn dc=panafnet,dc=com
# The credentials to bind with.
# Optional: default is no credential.
bindpw secret
# may incur a small performance impact.
nss_base_passwd ou=People,dc=panafnet,dc=com?one
nss_base_shadow ou=People,dc=panafnet,dc=com?one
nss_base_group ou=Group,dc=panafnet,dc=com?one
#nss_base_hosts ou=Hosts,dc=example,dc=com?one
#nss_base_services ou=Services,dc=example,dc=com?one
# SASL mechanism for PAM authentication - use is experimental
# at present and does not support password policy control
#pam_sasl_mech DIGEST-MD5
#uri ldap://127.0.0.1/
ssl no
tls_cacertdir /etc/openldap/cacerts
pam_password md5
==================================================================================
/etc/openlldap/slapd.conf(slave)
===================================================================================
# network or connect timeouts (see bind_timelimit).
host 192.168.117.5 192.168.117.4
# The distinguished name of the search base.
base dc=panafnet,dc=com
# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.
binddn dc=panafnet,dc=com
# The credentials to bind with.
# Optional: default is no credential.
bindpw secret
# to append the default base DN but this
# may incur a small performance impact.
nss_base_passwd ou=People,dc=panafnet,dc=com?one
nss_base_shadow ou=People,dc=panafnet,dc=com?one
nss_base_group ou=Group,dc=pananfet,dc=com?one
#nss_base_hosts ou=Hosts,dc=example,dc=com?one
ssl no
tls_cacertdir /etc/openldap/cacerts
=====================================================================================
Note: I had integrated ldap with postfix.
So when am restart my postfix service i got this error in logs.
Jul 1 16:05:59 master postfix/postfix-script: stopping the Postfix mail
system
Jul 1 16:05:59 master postfix/master[6303]: terminating on signal 15
Jul 1 16:06:01 master postfix/postfix-script: starting the Postfix mail
system
Jul 1 16:06:02 master postfix/master[1283]: daemon started -- version
2.3.3, configuration /etc/postfix
Jul 1 16:06:02 master postfix/pickup[1284]: nss_ldap: failed to bind to
LDAP server ldap://192.168.117.4: Invalid credentials
Jul 1 16:06:02 master postfix/qmgr[1285]: nss_ldap: failed to bind to LDAP
server ldap://192.168.117.4: Invalid credentials
Jul 1 16:06:02 master postfix/pickup[1284]: nss_ldap: failed to bind to
LDAP server ldap://192.168.117.5: Invalid credentials
Jul 1 16:06:02 master postfix/pickup[1284]: nss_ldap: could not search LDAP
server - Server is unavailable
Jul 1 16:06:02 master postfix/pickup[1284]: nss_ldap: failed to bind to
LDAP server ldap://192.168.117.4: Invalid credentials
Jul 1 16:06:02 master postfix/qmgr[1285]: nss_ldap: failed to bind to LDAP
server ldap://192.168.117.5: Invalid credentials
Jul 1 16:06:02 master postfix/qmgr[1285]: nss_ldap: could not search LDAP
server - Server is unavailable
Jul 1 16:06:02 master postfix/pickup[1284]: nss_ldap: failed to bind to
LDAP server ldap://192.168.117.5: Invalid credentials
Jul 1 16:06:02 master postfix/pickup[1284]: nss_ldap: could not search LDAP
server - Server is unavailable
Jul 1 16:06:02 master postfix/qmgr[1285]: nss_ldap: failed to bind to LDAP
server ldap://192.168.117.4: Invalid credentials
Jul 1 16:06:02 master postfix/qmgr[1285]: nss_ldap: failed to bind to LDAP
server ldap://192.168.117.5: Invalid credentials
Jul 1 16:06:02 master postfix/qmgr[1285]: nss_ldap: could not search LDAP
server - Server is unavailable
# 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/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
# modulepath /usr/lib64/openldap
# moduleload back_bdb.la
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la
# The next three lines allow use of TLS for encrypting connections using a
# 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
# 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
#######################################################################
database bdb
suffix "dc=panafnet,dc=com"
rootdn "cn=Manager,dc=panafnet,dc=com"
rootpw {SSHA}F/VF2kcFeRzWxmYddG2JryM/0odBN7Hy
# 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/ldap/panafnet.com
syncrepl
rid=0
provider=ldap://192.168.117.4:389
binddn="dc=panafnet,dc=com"
bindmethod=simple
credentials=SyncUser
searchbase="dc=panafnet,dc=com"
filter="(objectClass=*)"
attrs="*"
schemachecking=off
scope=sub
type=refreshOnly
interval=00:00:00:06
access to attrs=userPassword
by dn="cn=syncuser,dc=panafnet,dc=com" write
by * auth
access to *
by dn="cn=syncuser,dc=panafnet,dc=com" write
by * read
# 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 default sub
index entryCSN,entryUUID eq
# 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
[root@slave ~]#
=====================================================================================
/etc/ldap.conf(slave
======================================================================================
16 years, 4 months
Re: I don't want to use GSSAPI !?
by Olivier
Hi Dan,
many thanks : with your guidance, I found where the problem came from, and
I think it's almost fixed (not fully though).
Ok : the situation is that I use layer between my machines and the ldap
server (aka : sssd). The sssd package depends on sasl libraries : that's
why it is installed on my boxes even if I don't usally use it.
The first thing is that I don't understand is : why the same command
"ldapsearch -ZZZ -h ldaphost ..." works fine on redhat 6 and failed on
redhat 5 (only works with '-x' on redhat5. I've noted your agurment that
this is the default behaviour).
Anyway, I saw where my authentication problem came from : On redhat5 I need
to tell nsswitch NOT to use sssd to get SUDOER database bcause this is not
supported before redhat6. So my nswitch.conf looks like this :
# cat /etc/nsswitch.conf
sudoers: ldap
passwd: files sss
shadow: files sss
group: files sss
...
So I had to configure /etc/ldap.conf to include all relevant information
for talking with the ldap server and get the sudoer db from ldap.
The problem is that I have not found which option I should use in ldap.conf
to say NOT to use sasl when binding the ldap directory (aka the equivalent
of '-x').
I have found two workarounds to make it work alyhough, but those methods
are not good to me :
1/ First method is to remove those two lines :
ssl start_tls
tls_cacertdir /etc/openldap/cacerts
from /etc/ldap.conf
-> ok, it works but now the user password circulate in clear over the sudo
processe.
2/ second method is to configure a proxy "binddn" in /etc/ldap.conf.
when I do that, it appears that then I can I leave "starttls" in the file,
sasl is not called over the sudo process and it works.
The problem : to make it work I need to declare the "bindpw" in
/etc/ldap.conf and I don't like that at all.
(BTW, I have not bee able to make it work with a disctinct /etc/ldap.secret)
Ok question : is there an option that I could install in /etc/ldap.conf to
telle NOT to use sasl (aka : equivalent of '-x' for ldapsearch).
Hope the issue/diag is clear,
If there is no other way, I suspect that I could try to create x509
certificates for my redhat5 machines and bind using an "external" SASL
mecanism. But I beleive that with this method the ACL configuration on the
server side can quickly become a nightmare.
Any thougt, guidance ?
Thanks,
---
Olivier
2015-10-23 23:45 GMT+02:00 Dan White <dwhite(a)cafedemocracy.org>:
> On 10/23/15 23:31 +0200, Olivier wrote:
>
>> 2015-10-22 20:54 GMT+02:00 Dan White <dwhite(a)cafedemocracy.org>:
>>
>>> Without including a '-x' option on the command line, you are directing
>>> ldapsearch to perform a SASL authenticated bind. See the ldapsearch
>>> manpage.
>>>
>>
>> I use SASL in certain circumstances (aka: EXTERNAL), but not GSSAPI and
>> find strange that this particular machine (I mean the client) even tries
>> it.
>>
>> Do you know why ldapsearch tries to authenticate using GSSAPI ?
>>
>
> Because your local cyrus sasl library determined it was the best option,
> because it was not provided with a specific mechanism to use (-Y).
>
> In this case, ldapsearch deferred the underlying authentication exchange
>>> to libsasl2, which has determined that GSSAPI is the most appropriate
>>> SASL
>>> mechanism to use, likely because the ldap server is offering it. You can
>>> use '-Y' to specify a preferred sasl mechanism, if that is your
>>> intention.
>>>
>>
>> Is there any way to configure the server not to serve GSSAPI mechanism ? I
>> have not fount any parameter that could deal with that on the server side.
>>
>
> Yes. Configure a sasl slapd.conf file, and specify an explicit 'mech_list'
> which excludes GSSAPI. See:
>
> http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/options.php
>
> You can remove the GSSAPI libsasl2 shared library from your system, but
>>> that would simply mask the problem.
>>>
>>
>> Mmm... Thanks for this idea, but again, this is GSSAPI that I don't want
>> to
>> use, not SASL.
>>
>> Is there any documentation that describes the dialog between the client
>> and
>> the server before they agree an a particular mechanism ?
>>
>
> SASL authentication is based on a server-offers - client-chooses model. The
> server offers all available mechanisms to the client, which then chooses
> the most appropriate mechanism to use based on which mechanisms it has
> available. You can explicitly set the mechanism with the '-Y' option, or
> via a SASL_MECH user-only option (see ldap.conf(5)).
>
> See section 5.2 of RFC 4513 for further detail.
>
> --
> Dan White
>
9 years
Re: slapd on an interface alias
by Bernd May
Hi,
On 05.07.2013 09:17, Ulrich Windl wrote:
>> I was able to set up a master LDAP server and a replication consumer using the
>> Dynamic configuration ("cn=config") seems to
Are you trying to replicate the cn=config db or just the 'real data' dbs?
>> make things very difficult, because slapd ends in a state where _nobody_ can
>> make configuration changes.
A replicated database, i.e. on a consumer site is not editable because
this would lead to inconsistencies. That is basically what the error
message tells you.
>> I read lots of procedures using Google, but could not find the solution for this
>> problem. Thus I suggest to add documentation how to configure such a scenario:
>>
>> 1) Set up an LDAP Master server that provides service on a specific IP address
>> using TLS
>> 2) Set up a replication consumer that provides service on a specific IP address
>> using TLS also
>> 3) The replication consumer should use the address where the master server
>> listens for replication
Though a little scattered through the documentation of setting up
replication, man slapd and man slapd-config this is already covered in
the documentation. What you are looking for is a cookbook receipe.
I suggest learning in this order:
1. Setup an ldap server with basic configuration, listening to
protocol://address:port of your liking (you can even have multiple slapd
running on the same host if they use different dbs and ports). Make sure
that, if you use hostnames they point to the right IP addresses.
2. Setup TLS for said server, TLS certificate subject and
subjectAltNames usually do not incorporate ip addresses. Thus all you
require is a working DNS setup.
3. Setup a second ldap server with TLS listening to
protocol://address:port of your liking
4. Setup a syncprov on one of the servers and a syncrepl on the other,
replicating a small test db, e.g. a hdb, bdb, or mdb
5. Should you want to setup a multimaster system, setup syncprov and
syncrepl for both servers cn=config dbs and make sure you enable the
mirrormode
> Some details (randomly picked, with some names obfuscated):
> (master server)
> olcSyncrepl: {0}rid=2 provider="ldap://v07.domain.org/"
> searchbase="dc=domain,dc=org" type="refreshAndPersist" retry="120 +" starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,ou=system,dc=domain,dc=org" credent ials="wNkWudLd3ko8"
I assume you want to replicate cn=config in a multimaster setup,
otherwise this makes no sense. A master does not need a syncrepl
directive for providing syncrepl to a consumer.
> The process is started as "/usr/lib/openldap/slapd -h ldap://ds1.domain.org:389 ldaps://ds1.domain.org:636 ldapi:/// -F /etc/openldap/slapd.d -u ldap -g ldap -o slp=off"
Is this the same 'master' that has the syncrepl directive from above or
a consumer?
> Obviously a connection to the "v07" address is not possible, because the server listens to the "ds1" address.
If you used the above slapd command for your replication provider that
is true. Note that you can specify multiple URIs to -h
> Basically I think I have to fix the "olcSyncrepl provider" and possibly the "olcServerID", but with dynamic configuration I cannot do it:
>
> Using ldapmodify I get:
> v07:~ # ldapmodify -v -ZZ -x -W -D cn=config -H ldap://ds1.domain.org -f /tmp/fix1.ldif
> ldap_initialize( ldap://ds1.domain.org:389/??base )
> Enter LDAP Password:
> replace olcServerID:
> 1 ldap://ds1.domain.org
> modifying entry "cn=config"
> ldap_modify: Server is unwilling to perform (53)
> additional info: shadow context; no update referral
s.a. This tells you that the slapd service you bind to has a replicated
cn=config db which he is not allowed to modify and there is no master
service to which he could refere you to.
> When editing the files in the slap.d directory, I get:
You should not.
The canonical way when you have shut yourself out of your db in this way
is to slapcat your config, edit the output and slapdadd it to the
*offline* server cn=config db. Otherwise you get the reported checksum
errors.
Also the output suggest that you still might not have a syncprov
listening on the interface corresponding to the ip address of the hostname.
###
I fear you have not fully understood how LDAP replication works. I
advise reading the chapter 18 of the OpenLDAP Administration manual
carefully and afterwards have a look at the syncprov overlay and
syncrepl directives (man 5 slapo-syncprov; man 5 slapd-config)
Also I am not sure what you are actually trying to accomplish. Maybe a
set of acceptable requirements for your setup would help, e.g.
- I want one master db provider that provides database content and
updates to all consumer dbs
- I want connections between consumers to use TLS (server auth only |
client and server auth)
...
I hope that I could help you somewhat and look forward to any questions
you still have. (Don't fret, ldap sync setup is not that easy to
understand for the first time)
hth
--
Technische Universität Berlin - FGINET
Bernd May
System Administration
Sekr. TEL 16
Ernst-Reuter-Platz 7
10587 BERLIN
GERMANY
Mobile: 0160/90257737
E-Mail: bernd(a)inet.tu-berlin.de
WWW: inet.tu-berlin.de
11 years, 4 months
Authentication problem
by Jean-Charles
Hello
I have a problem authenticating from a client RedHat 6.3 to a server
RedHat 6.3
Connection is ok
I can change user when I am root with *su paula* with no problem
When I change from non root to paula *su paula* : I am requested a password,
but I get an incorrect password message despite the password bieng correct
Here are the details :
_*SERVER Configuration (obtained with slapcat)
*_
The first database does not allow slapcat; using the first available one
(2)
bdb_db_open: warning - no DB_CONFIG file found in directory
/var/lib/ldap: (2).
Expect poor performance for suffix "dc=jcs-PC,dc=home".
dn: dc=jcs-PC,dc=home
dc: jcs-PC
objectClass: dcObject
objectClass: organization
o: NETEXPANSION
structuralObjectClass: organization
entryUUID: b9dcdb1e-f628-1032-8eef-4f234421cd34
creatorsName: cn=ldapadmin,dc=jcs-PC,dc=home
createTimestamp: 20131210205228Z
entryCSN: 20131210205228.791640Z#000000#000#000000
modifiersName: cn=ldapadmin,dc=jcs-PC,dc=home
modifyTimestamp: 20131210205228Z
dn: ou=employes,dc=jcs-PC,dc=home
objectClass: organizationalUnit
ou: employes
structuralObjectClass: organizationalUnit
entryUUID: 2008d924-f629-1032-8ef0-4f234421cd34
creatorsName: cn=ldapadmin,dc=jcs-PC,dc=home
createTimestamp: 20131210205520Z
entryCSN: 20131210205520.207551Z#000000#000#000000
modifiersName: cn=ldapadmin,dc=jcs-PC,dc=home
modifyTimestamp: 20131210205520Z
dn: cn=Paula Bionda,ou=employes,dc=jcs-PC,dc=home
cn: Paula Bionda
sn: Bionda
uid: paula
uidNumber: 503
gidNumber: 1100
gecos: Paula Bionda
homeDirectory: /home/paula
shadowLastChange: 10877
shadowMin: 0
shadowMax: 999999
shadowWarning: 7
shadowInactive: -1
shadowExpire: -1
shadowFlag: 0
structuralObjectClass: person
entryUUID: e4f37848-f930-1032-985a-91cf669ea788
creatorsName: cn=ldapadmin,dc=jcs-PC,dc=home
createTimestamp: 20131214172830Z
loginShell: /bin/bash
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
userPassword:: e1NTSEF9aEFzWFZFejlIa2xQSUpFSFF2SnpoZmo1cTYzdzRLUlg=
entryCSN: 20131219155524.533147Z#000000#000#000000
modifiersName: cn=Paula Bionda,ou=employes,dc=jcs-PC,dc=home
modifyTimestamp: 20131219155524Z
dn: ou=groups,dc=jcs-PC,dc=home
objectClass: organizationalUnit
ou: groups
structuralObjectClass: organizationalUnit
entryUUID: e1a8545a-fa85-1032-84b7-a9514c4c1551
creatorsName: cn=ldapadmin,dc=jcs-PC,dc=home
createTimestamp: 20131216100923Z
entryCSN: 20131216100923.403228Z#000000#000#000000
modifiersName: cn=ldapadmin,dc=jcs-PC,dc=home
modifyTimestamp: 20131216100923Z
dn: cn=mygroup,ou=groups,dc=jcs-PC,dc=home
objectClass: top
objectClass: posixGroup
cn: mygroup
gidNumber: 1100
memberUid: paula
memberUid: giuseppe
structuralObjectClass: posixGroup
entryUUID: c26713a0-fa9f-1032-8b7d-155dd966052d
creatorsName: cn=ldapadmin,dc=jcs-PC,dc=home
createTimestamp: 20131216131437Z
entryCSN: 20131216131437.881194Z#000000#000#000000
modifiersName: cn=ldapadmin,dc=jcs-PC,dc=home
modifyTimestamp: 20131216131437Z
_*CLIENT C*__*onfiguration *_
authconfig-tui gives
[] Cache Infomation
[*] Use LDAP
[] Use NIS
[] Use IPAV2
[] Use WinBind
[*] Use MD5 Passwords
[*] Use Shadow Passwords
[*] Use LDAP Authentication
[] Use Kerboros
[*] Use Fingerprint Reader
[] Use Windbind Authentication
[*] Local Authorization is sufficient
[] Use TLS
ldap://192.168.1.12/
Base DN: dc=jcs-PC,dc=home
_*Result su paula
*_
a) when I am logged in as root, *su paula* logs me into paula : no problem
b) when I am not logged in as root and I do *su paula*
I am requested a password (as expected), but then I get incorrect
password despite the password being correct
Here is the log
Dec 19 18:49:50 jcs-PC slapd[6441]: => slap_access_allowed: backend
default read access granted to "(anonymous)"
Dec 19 18:49:50 jcs-PC slapd[6441]: => access_allowed: read access
granted by read(=rscxd)
Dec 19 18:49:50 jcs-PC slapd[6441]: conn=1005 op=3 SEARCH RESULT tag=101
err=0 nentries=1 text=
Dec 19 18:49:50 jcs-PC slapd[6441]: conn=1006 fd=21 ACCEPT from
IP=192.168.1.17:56000 (IP=0.0.0.0:389)
Dec 19 18:49:50 jcs-PC slapd[6441]: conn=1006 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Dec 19 18:49:50 jcs-PC slapd[6441]: conn=1006 op=0 STARTTLS
Dec 19 18:49:50 jcs-PC slapd[6441]: conn=1006 op=0 RESULT oid= err=0 text=
Dec 19 18:49:50 jcs-PC slapd[6441]: conn=1006 fd=21 closed (TLS
negotiation failure)
Dec 19 19:04:43 jcs-PC slapd[6441]: conn=1005 op=4 UNBIND
Dec 19 19:04:43 jcs-PC slapd[6441]: conn=1005 fd=14 closed
And these are the last 2 lines of wireshark
_Source_
_Destination_
_Protocol_ _Info_
192.168.1.17(Client) 192.168.1.12 (Server)
LDAP ExtendedReq LDAP_START_TLS_OID
192.168.1.12 192.168.1.17
LDAP ExtendedResp LDAP_START_TLS_OID
responseName missing
I am surprised about STARTLS because there seems to be nothing in my
configuration files about TLS
Thank you
Axel
--
10 years, 10 months