Re: N-way multi master configuration issue
by Brett Maxfield
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.
> ===============================================================================
>
13 years, 9 months
Re: OpenLDAP TLS server authority verification
by Daniel Pocock
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_
13 years, 3 months
Re: slapd segfault in openldap 2.4.45
by Scott Koch
Correction, my openldap version is 2.4.45(typo'ed in previous post).
On Wed, Dec 13, 2017 at 11:23 AM Scott Koch <scottkoch(a)gmail.com> wrote:
> This is an RPM of openldap I built from the latest upstream source. This
> slapd server is running on RHEL 7.4 x86_64.
>
> Error message:
> 2017-12-13T00:13:34.944152-05:00 ldap1.example.com kernel: slapd[983]:
> segfault at 766f6730 ip 00007f0272e2549b sp 00007f02017f55b8 error 4 in
> libc-2.17.so[7f0272ce8000+1b8000]
>
> We have seen 15 or so instances of this issue and in all cases the last
> LDAP operations follow the same pattern where there is an ABANDON and
> UNBIND, then there is a SRCH operation. See log output below of full
> connection for the client that performs the last operation.
>
> Let me know if there is any other information I can provide to help
> troubleshoot this problem.
>
> Thanks in advance for the help!
> -Scott
>
> 2017-12-13T00:13:03.560693-05:00 ldap1.example.com slapd[26514]:
> conn=873638 fd=105 ACCEPT from IP=10.0.4.37:48520 (IP=0.0.0.0:389)
>
> 2017-12-13T00:13:03.560869-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=0 EXT oid=1.3.6.1.4.1.1466.20037
>
> 2017-12-13T00:13:03.561012-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=0 STARTTLS
>
> 2017-12-13T00:13:03.561211-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=0 RESULT oid= err=0 text=
>
> 2017-12-13T00:13:03.569367-05:00 ldap1.example.com slapd[26514]:
> conn=873638 fd=105 TLS established tls_ssf=256 ssf=256
>
> 2017-12-13T00:13:03.569853-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
>
> 2017-12-13T00:13:03.570014-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=1 SRCH attr=* altServer namingContexts supportedControl
> supportedExtension supportedFeatures supportedLDAPVersion
> supportedSASLMechanisms domainControllerFunctionality defaultNamingContext
> lastUSN highestCommittedUSN
>
> 2017-12-13T00:13:03.570215-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
>
> 2017-12-13T00:13:03.571953-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0
> filter="(&(?objectClass=sudoRole)(|(!(?sudoHost=*))(?sudoHost=ALL)(?sudoHost=
> node1713.example.com)(?sudoHost=node1713)(?sudoHost=10.0.4.37)(?sudoHost=
> 10.134.0.0/18)(?sudoHost=ffff::ffff:ffff:fff:ffff)(?sudoHost=fe80::/64)(?sudoHost=+*)(|(?sudoHost=*\5C*)(?sudoHost=*?*)(?sudoHost=*\2A*)(?sudoHost=*[*]*)))
> <http://10.134.0.0/18)(?sudoHost=ffff::ffff:ffff:fff:ffff)(?sudoHost=fe80::/…>
> )"
>
> 2017-12-13T00:13:03.572214-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=2 SRCH attr=objectClass cn sudoCommand sudoHost sudoUser
> sudoOption sudoRunAs sudoRunAsUser sudoRunAsGroup sudoNotBefore
> sudoNotAfter sudoOrder modifyTimestamp
>
> 2017-12-13T00:13:03.573488-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text=
>
> 2017-12-13T00:13:34.943439-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=4 ABANDON msg=4
>
> 2017-12-13T00:13:34.943694-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0
> filter="(&(uid=ntp)(objectClass=posixAccount)(&(uidNumber=*)(!(uidNumber=0))))"
>
> 2017-12-13T00:13:34.943885-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=5 UNBIND
>
> 2017-12-13T00:13:34.944092-05:00 ldap1.example.com slapd[26514]:
> conn=873638 op=3 SRCH attr=objectClass uid userPassword uidNumber gidNumber
> gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp
> modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning
> shadowInactive shadowExpire shadowFlag krbLastPwdChange
> krbPasswordExpiration pwdAttribute authorizedService accountExpires
> userAccountControl nsAccountLock host loginDisabled loginExpirationTime
> loginAllowedTimeMap sshPublicKey mail
>
7 years, 5 months
Re: Syncrepl on glued databases only replicates the superior and the first subordinate
by Robert Minsk
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.
11 years, 5 months
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, 11 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, 9 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, 8 months
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, 7 months
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*
>
13 years, 3 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, 7 months