Am 2017-03-20 14:29, schrieb 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().
The loglevel was manually edited to -1 ("any") and the log shows the
output of this loglevel.
Yes the binding DN is diffrent, but I have also tried the
"cn=T000000002,ou=tech,dc=gwarband,dc=de" with no success.
I don't have any idea how to set a higher debug level to dovecot. In my
opinion I have the highest. So I can't deliver a greater log.
Chris Jackson wrote:
> On Feb 11, 2011, at 09:50 AM, Chris Jackson wrote:
>
> Is it possible to prevent anonymous and unauthenticated binds to
> ldaps:// 636 but allow them on ldap:// 389?
>
> I want to allow staff to query my ldaps:// outside of my network
> while requiring them to login to do so but allow anyone to bind
> (anonymous, unauthenticated, or authenticated) internally on ldaps//:
> 389.
>
> I know:
> Anonymous bind can be disabled by "disallow bind_anon" and
> Unauthenticated bind mechanism is disabled by default. But if I use
> "disallow bind_anon it stops in on both ports.
Sure, this are global directives.
> I want to stop it just on ldaps://.
You don't need ldaps:// in your local network? May be.
I think a easier solution is to identify your Internet Gateway by IP.
> Chris Jackson
>
>
> On Feb 14, 2011, at 11:28 AM, Aaron Richton wrote:
>
> Stopping users that are "unauthenticated" makes no sense;
> everything's unauthenticated at time=0. You might as well stop slapd
> if you want a 100% inability to serve data.
>
> You can deny anonymous users that aren't plaintext, including any
> ldaps:/// connections, with something like:
>
> access to *
> by anonymous ssf=0 transport_ssf=0 tls_ssf=0 sasl_ssf=0 none break
> by anonymous none
>
> early on in your ACL stanzas. I'm pretty sure this'll deny anonymous
> StartTLS users on 389, though; not sure if that's what you want. I
> can't think of any way to use the slapd access language to
> differentiate based on listeners, which would probably be the most
> elegant way to handle what you asked. To be fair, this entire
> exercise seems really odd from where I sit -- are you positive that
> this will have the desired effect? (If somebody out in Peru is
> permitted to connect in unencrypted and make anonymous queries, why
> not allow them to make those same queries encrypted? What's the
> difference?)
>
> here is a scenario:
>
> Site has a ldap server on ldap://389. Firewall blocks access to 389
> from internet. Everyone queries the ldap via anonymous binds. Site
> would like to allow staff the ability to query the ldap from outside
> the firewall. This would be done via ldaps:// 636 to users who have
> authenticated via username/password. They do not want to allow
> anonymous queries outside the firewall.
>
> Using the "disallow bind_anon" would prevent anon binds on both
> ldap:// and ldaps://. This would break the inside machines ability
> to query. If we dont use "disallow bind_anon" then machines outside
> of the firewall could query the ldap.
>
> ---Is the only option for them to setup two separate ldap servers?
No. You should use ACLs to solve this problem. Read man slapd.access
an/or search the openldap archives.
Assuming you have a NAT gatway as Firewall machine.
Replace all "by anonymous" statements with these 6 statements:
by anonymous auth continue
by peername.ip="127.0.0.1" read continue
by peername.ip="10.0.0.0%255.0.0.0" read continue
by peername.ip="172.16.0.0%255.240.0.0" read continue
by peername.ip="192.168.0.0%255.255.0.0" read continue
by peername.ip="gateway-ip" auth
One may write these statements more effective, but in general they will
do.
Replace "gateway-ip" with yours.
Put the above statements also in every ACL just before the
by *
when this ACL do NOT have an "by anonymous" statement.
Maybe the last line could/should be:
by ssf=56 peername.ip="gateway-ip" auth
Caveats:
Your gateway can no longer access your LDAP Server with
the "gateway-ip". But this is a Firewall Design Question.
I've tested this only with unencrypted sessions; anoymous and
authenticated. But TLS or SSL will not grant more rights, if you do not
tell the ACLs to do so.
Here the output from the two searches:
# ldapsearch -x -LLL -H ldap://192.168.231.90/ dn
Insufficient access (50)
# ldapsearch -x -LLL -H ldap://192.168.231.90/ dn -D
cn=admin,dc=kronprinz,dc=xx -W
dn: dc=kronprinz,dc=xx
dn: cn=admin,dc=kronprinz,dc=xx
> One with "disallow bind_anon" and one without. Then only open the
> firewall for port 636 to the ldap server which has "disallow
> bind_anon".
>
> Chris Jackson
--
Harry Jede
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
You have not added the syncrepl overlay to the syncrepl provider(s). You should probably re-read the available documentation on syncrepl replication, you have missed several things which are clearly documented there.
Perhaps you should start with the simple example in the openldap documentation, get that working locally, and then compare differences to your problematic setup.
Poorly understood / configured multimaster replication is probably worse than not having any multimaster replication at all.
On 30/08/2011, at 4:03 PM, Naga Chaitanya Palle <Naga.Chaitanya(a)aricent.com> wrote:
> 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.
> ===============================================================================
>
On 03/03/12 15:17, Michael Ströder wrote:
> Daniel Pocock wrote:
>> On 03/03/12 12:46, Michael Ströder wrote:
>>> Using DNS SRV is simply not specified regarding SSL/TLS. There's no way
>>> to map a naming context to a server cert despite your local security
>>> policy says your DNS is trusted by some other means.
>>>
>>>> A hostname can be a reference identity
>>>>
>>>> But a reference identity is not always a hostname. It depends on the
>>>> client configuration.
>>>
>>> The naming context (aka search root) cannot be a reference identity in
>>> the context of SSL/TLS. Period.
>>
>> The RFC does not say that.
>
> It does not have to say that.
>
>> Neither does it state that an implementation
>> should support the concept. It appears to leave the implementor some
>> discretion about their choice of reference identity.
>
> Yes.
>
>>> Feel free to write an Internet draft updating TLS-RFCs and RFC 2782.
>>> This could specify how a naming context is compared to some information
>>> in a subjectAltName extension since there's no standard saying something
>>> about this yet. A suitable GeneralName choice would be directoryName.
>>
>> It is already in RFC 6125:
>>
>> http://tools.ietf.org/html/rfc6125#section-6.2
>
> I can't see any language which clearly defines rules how to derive the
> reference identity from a LDAP naming context. Just poiting out that it
> is no problem with SIP is not sufficient.
>
>> Many a mini-RFC about best practice for RFC 6125 in the LDAP world would
>> be useful though
>
> You would have to clearly define what a client has to do to derive and
> check the reference identity if its configuration simply contains
> ldaps:///dc=example,dc=com
>
> Frankly I don't like RFC 6125. IIRC I gave up reviewing the I-Ds when
> the authors insisted on adding support for wildcard certs.
The concepts proposed in RFC 6125 may not be ideal, but it does provide
a stronger solution than we have now when using DNS SRV + TLS together
The current implementation of the client code uses the hostname derived
from a DNS SRV lookup as a reference identity
Also, whatever is implemented, it may not please everyone: so just as
you can choose whether you want TLSv1 or SSLv2 support in the client
code, I think it is reasonable that an administrator should be able to
choose the policy they prefer for server validation: I'm not proposing
that a single solution should be imposed for everyone.
> If I understood you correctly you propose that if a server's cert
> contains subjectAltname::dNSName:example.com this cert should be
> accepted for any application protocol having something like
> dc=example,dc=com, @example.com etc.
> I don't like that approach. It broadens the semantics in such a way that
> you cannot have distinct server certs for different services. Mainly I
> think that untyped GeneralName::dNSName was defined before we had
> several types of SRV RRs (except MX RRs) and no-one ever clearly
> specified its semantics.
I agree it is not perfect: however, it is stronger than what we have now.
Some sites will find that level of security is quite sufficient (just
checking that the subjectAltname::dNSName = base DN). Bigger sites will
want something more, as you correctly point out ...
> Same problem like looking up MX RR for a domain and then connecting to
> the MX servers with StartTLS.
>
> For a naming context ldaps:///dc=example,dc=com one could specify that
> subjectAltname MUST contain dNSName:_ldaps._tcp.example.com to at least
> express the connection to the SRV RR for the LDAP service. Or other
> approaches with other types of GeneralName.
XMPP tried using otherName, but also support dNSName like SIP, here is
an example openssl.cnf fragment:
http://wiki.xmpp.org/web/XMPP_Server_Certificates
I believe adding the Extended Key Usage (EKU) extension to the
certificate provides the service-specific validation that you are aiming
for (e.g. to ensure that someone who has a cert for the mailserver of
example.org can't set up an unauthorised LDAP server for example.org)
Here is how they do it for SIP using EKU, maybe this RFC could even be
adapted as a model for LDAP:
http://tools.ietf.org/html/rfc5924#section-4
OpenSSL can generate such certs without too much trouble:
http://www.openssl.org/docs/apps/x509v3_config.html#Extended_Key_Usage_
After some more testing f I turn off syncprov on all of my subordinates
and leave syncprov on on my superior it works. So it seems to be a
problem with having syncprov on subordinates.
On 12/18/2013 03:34 PM, Robert Minsk wrote:
> Openldap version 2.4.35
>
> Our global ldap server has the following naming contexts:
>
> namingContexts: o=global,ou=studios,dc=methodstudios,dc=net
> namingContexts: o=chi01,ou=studios,dc=methodstudios,dc=net
> namingContexts: o=det01,ou=studios,dc=methodstudios,dc=net
> namingContexts: o=la01,ou=studios,dc=methodstudios,dc=net
> namingContexts: o=ny01,ou=studios,dc=methodstudios,dc=net
> namingContexts: o=lon01,ou=studios,dc=methodstudios,dc=net
> namingContexts: o=van01,ou=studios,dc=methodstudios,dc=net
> namingContexts: ou=studios,dc=methodstudios,dc=net
> namingContexts: ou=login,dc=methodstudios,dc=net
>
> ou=studio,dc=methodstudios,dc=net is the superior database and global,
> chi01, det01, la01, ny01, lon01, van01 are all have "subordinate
> advertise" and are all sync providers.
>
> The sync provider:
>
> database mdb
> suffix "ou=studios,dc=methodstudios,dc=net"
> rootdn ...
> rootpw ...
> directory /var/lib/ldap/studios.methodstudios.net
> maxsize 17179869184
> serverID 201
>
> overlay glue
> overlay syncprov
> syncprov-reloadhint TRUE
> syncprov-checkpoint 100 5
> sync_use_subentry true
>
> ...
>
> The sync consumer only has a database for
> ou=studios,dc=methodstudios,dc=net.
>
> database mdb
> suffix "ou=studios,dc=methodstudios,dc=net"
> rootdn ...
> rootpw ...
> directory /var/lib/ldap/studios.methodstudios.net
> maxsize 17179869184
> serverID 202
>
> syncrepl rid=201 provider=ldap://<providor host name>
> type=refreshAndPersist retry="60 10 300 +"
> searchbase="ou=studios,dc=methodstudios,dc=net"
> bindmethod=simple starttls=yes
> binddn="..."
> credentials=... schemachecking=off
> sizelimit=unlimited timelimit=unlimited
> updateref ldap://<providor host name>
>
> It seems to be only syncing ou=studios,dc=methodstudios,dc=net and
> o=global,ou=studios,dc=methodstudios,dc=net. If I change the order of
> the provider server so that chi01 comes before global then only
> syncing ou=studios,dc=methodstudios,dc=net and
> o=chi01,ou=studios,dc=methodstudios,dc=net get sync.
>
> Am I doing anything obviously wrong?
>
> --
> 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.