openldap
by Aravind Arjunan
hi,
I got problem in openldap master,slave replication.
I had configured openldap in RHEL 5 as master/slave in syncrepl method (
refreshOnly)
my problem is my slave server is not getting replicated with master.
I had integrated openldap with postfix also,so when i restart the postfix
service i get the below error which i mentioned.
plz help me with this issue.
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/qmail.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
# modulepath /usr/lib64/openldap
# moduleload back_bdb.la
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client
software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
access to attrs=userPassword
by self write
by dn="cn=syncuser,dc=panafnet,dc=com" read
by * auth
access to *
by dn="cn=syncuser,dc=panafnet,dc=com" read
by * read
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
suffix "dc=panafnet,dc=com"
rootdn "cn=Manager,dc=panafnet,dc=com"
rootpw {SSHA}9ma4wkvWQM2ws7E9q7qIgK9vQ2Rp4IhZ
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap/panafnet.com
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
index default sub
index entryCSN,entryUUID eq
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com(a)EXAMPLE.COM
overlay syncprov
syncprov-checkpoint 100 05
[root@master ~]#
=============================================================================
/etc/ldap.conf(master)
==============================================================================
#host 127.0.0.1
host 192.168.117.4 192.168.117.5
# The distinguished name of the search base.
base dc=panafnet,dc=com
# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.
binddn dc=panafnet,dc=com
# The credentials to bind with.
# Optional: default is no credential.
bindpw secret
# may incur a small performance impact.
nss_base_passwd ou=People,dc=panafnet,dc=com?one
nss_base_shadow ou=People,dc=panafnet,dc=com?one
nss_base_group ou=Group,dc=panafnet,dc=com?one
#nss_base_hosts ou=Hosts,dc=example,dc=com?one
#nss_base_services ou=Services,dc=example,dc=com?one
# SASL mechanism for PAM authentication - use is experimental
# at present and does not support password policy control
#pam_sasl_mech DIGEST-MD5
#uri ldap://127.0.0.1/
ssl no
tls_cacertdir /etc/openldap/cacerts
pam_password md5
==================================================================================
/etc/openlldap/slapd.conf(slave)
===================================================================================
# network or connect timeouts (see bind_timelimit).
host 192.168.117.5 192.168.117.4
# The distinguished name of the search base.
base dc=panafnet,dc=com
# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.
binddn dc=panafnet,dc=com
# The credentials to bind with.
# Optional: default is no credential.
bindpw secret
# to append the default base DN but this
# may incur a small performance impact.
nss_base_passwd ou=People,dc=panafnet,dc=com?one
nss_base_shadow ou=People,dc=panafnet,dc=com?one
nss_base_group ou=Group,dc=pananfet,dc=com?one
#nss_base_hosts ou=Hosts,dc=example,dc=com?one
ssl no
tls_cacertdir /etc/openldap/cacerts
=====================================================================================
Note: I had integrated ldap with postfix.
So when am restart my postfix service i got this error in logs.
Jul 1 16:05:59 master postfix/postfix-script: stopping the Postfix mail
system
Jul 1 16:05:59 master postfix/master[6303]: terminating on signal 15
Jul 1 16:06:01 master postfix/postfix-script: starting the Postfix mail
system
Jul 1 16:06:02 master postfix/master[1283]: daemon started -- version
2.3.3, configuration /etc/postfix
Jul 1 16:06:02 master postfix/pickup[1284]: nss_ldap: failed to bind to
LDAP server ldap://192.168.117.4: Invalid credentials
Jul 1 16:06:02 master postfix/qmgr[1285]: nss_ldap: failed to bind to LDAP
server ldap://192.168.117.4: Invalid credentials
Jul 1 16:06:02 master postfix/pickup[1284]: nss_ldap: failed to bind to
LDAP server ldap://192.168.117.5: Invalid credentials
Jul 1 16:06:02 master postfix/pickup[1284]: nss_ldap: could not search LDAP
server - Server is unavailable
Jul 1 16:06:02 master postfix/pickup[1284]: nss_ldap: failed to bind to
LDAP server ldap://192.168.117.4: Invalid credentials
Jul 1 16:06:02 master postfix/qmgr[1285]: nss_ldap: failed to bind to LDAP
server ldap://192.168.117.5: Invalid credentials
Jul 1 16:06:02 master postfix/qmgr[1285]: nss_ldap: could not search LDAP
server - Server is unavailable
Jul 1 16:06:02 master postfix/pickup[1284]: nss_ldap: failed to bind to
LDAP server ldap://192.168.117.5: Invalid credentials
Jul 1 16:06:02 master postfix/pickup[1284]: nss_ldap: could not search LDAP
server - Server is unavailable
Jul 1 16:06:02 master postfix/qmgr[1285]: nss_ldap: failed to bind to LDAP
server ldap://192.168.117.4: Invalid credentials
Jul 1 16:06:02 master postfix/qmgr[1285]: nss_ldap: failed to bind to LDAP
server ldap://192.168.117.5: Invalid credentials
Jul 1 16:06:02 master postfix/qmgr[1285]: nss_ldap: could not search LDAP
server - Server is unavailable
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
# modulepath /usr/lib64/openldap
# moduleload back_bdb.la
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client
software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
suffix "dc=panafnet,dc=com"
rootdn "cn=Manager,dc=panafnet,dc=com"
rootpw {SSHA}F/VF2kcFeRzWxmYddG2JryM/0odBN7Hy
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
# rootpw {crypt}ijFYNcSNctBYg
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap/panafnet.com
syncrepl
rid=0
provider=ldap://192.168.117.4:389
binddn="dc=panafnet,dc=com"
bindmethod=simple
credentials=SyncUser
searchbase="dc=panafnet,dc=com"
filter="(objectClass=*)"
attrs="*"
schemachecking=off
scope=sub
type=refreshOnly
interval=00:00:00:06
access to attrs=userPassword
by dn="cn=syncuser,dc=panafnet,dc=com" write
by * auth
access to *
by dn="cn=syncuser,dc=panafnet,dc=com" write
by * read
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub
index default sub
index entryCSN,entryUUID eq
# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com(a)EXAMPLE.COM
[root@slave ~]#
=====================================================================================
/etc/ldap.conf(slave
======================================================================================
17 years, 4 months
Re: I don't want to use GSSAPI !?
by Olivier
Hi Dan,
many thanks : with your guidance, I found where the problem came from, and
I think it's almost fixed (not fully though).
Ok : the situation is that I use layer between my machines and the ldap
server (aka : sssd). The sssd package depends on sasl libraries : that's
why it is installed on my boxes even if I don't usally use it.
The first thing is that I don't understand is : why the same command
"ldapsearch -ZZZ -h ldaphost ..." works fine on redhat 6 and failed on
redhat 5 (only works with '-x' on redhat5. I've noted your agurment that
this is the default behaviour).
Anyway, I saw where my authentication problem came from : On redhat5 I need
to tell nsswitch NOT to use sssd to get SUDOER database bcause this is not
supported before redhat6. So my nswitch.conf looks like this :
# cat /etc/nsswitch.conf
sudoers: ldap
passwd: files sss
shadow: files sss
group: files sss
...
So I had to configure /etc/ldap.conf to include all relevant information
for talking with the ldap server and get the sudoer db from ldap.
The problem is that I have not found which option I should use in ldap.conf
to say NOT to use sasl when binding the ldap directory (aka the equivalent
of '-x').
I have found two workarounds to make it work alyhough, but those methods
are not good to me :
1/ First method is to remove those two lines :
ssl start_tls
tls_cacertdir /etc/openldap/cacerts
from /etc/ldap.conf
-> ok, it works but now the user password circulate in clear over the sudo
processe.
2/ second method is to configure a proxy "binddn" in /etc/ldap.conf.
when I do that, it appears that then I can I leave "starttls" in the file,
sasl is not called over the sudo process and it works.
The problem : to make it work I need to declare the "bindpw" in
/etc/ldap.conf and I don't like that at all.
(BTW, I have not bee able to make it work with a disctinct /etc/ldap.secret)
Ok question : is there an option that I could install in /etc/ldap.conf to
telle NOT to use sasl (aka : equivalent of '-x' for ldapsearch).
Hope the issue/diag is clear,
If there is no other way, I suspect that I could try to create x509
certificates for my redhat5 machines and bind using an "external" SASL
mecanism. But I beleive that with this method the ACL configuration on the
server side can quickly become a nightmare.
Any thougt, guidance ?
Thanks,
---
Olivier
2015-10-23 23:45 GMT+02:00 Dan White <dwhite(a)cafedemocracy.org>:
> On 10/23/15 23:31 +0200, Olivier wrote:
>
>> 2015-10-22 20:54 GMT+02:00 Dan White <dwhite(a)cafedemocracy.org>:
>>
>>> Without including a '-x' option on the command line, you are directing
>>> ldapsearch to perform a SASL authenticated bind. See the ldapsearch
>>> manpage.
>>>
>>
>> I use SASL in certain circumstances (aka: EXTERNAL), but not GSSAPI and
>> find strange that this particular machine (I mean the client) even tries
>> it.
>>
>> Do you know why ldapsearch tries to authenticate using GSSAPI ?
>>
>
> Because your local cyrus sasl library determined it was the best option,
> because it was not provided with a specific mechanism to use (-Y).
>
> In this case, ldapsearch deferred the underlying authentication exchange
>>> to libsasl2, which has determined that GSSAPI is the most appropriate
>>> SASL
>>> mechanism to use, likely because the ldap server is offering it. You can
>>> use '-Y' to specify a preferred sasl mechanism, if that is your
>>> intention.
>>>
>>
>> Is there any way to configure the server not to serve GSSAPI mechanism ? I
>> have not fount any parameter that could deal with that on the server side.
>>
>
> Yes. Configure a sasl slapd.conf file, and specify an explicit 'mech_list'
> which excludes GSSAPI. See:
>
> http://www.cyrussasl.org/docs/cyrus-sasl/2.1.25/options.php
>
> You can remove the GSSAPI libsasl2 shared library from your system, but
>>> that would simply mask the problem.
>>>
>>
>> Mmm... Thanks for this idea, but again, this is GSSAPI that I don't want
>> to
>> use, not SASL.
>>
>> Is there any documentation that describes the dialog between the client
>> and
>> the server before they agree an a particular mechanism ?
>>
>
> SASL authentication is based on a server-offers - client-chooses model. The
> server offers all available mechanisms to the client, which then chooses
> the most appropriate mechanism to use based on which mechanisms it has
> available. You can explicitly set the mechanism with the '-Y' option, or
> via a SASL_MECH user-only option (see ldap.conf(5)).
>
> See section 5.2 of RFC 4513 for further detail.
>
> --
> Dan White
>
10 years, 1 month
Re: slapd on an interface alias
by Bernd May
Hi,
On 05.07.2013 09:17, Ulrich Windl wrote:
>> I was able to set up a master LDAP server and a replication consumer using the
>> Dynamic configuration ("cn=config") seems to
Are you trying to replicate the cn=config db or just the 'real data' dbs?
>> make things very difficult, because slapd ends in a state where _nobody_ can
>> make configuration changes.
A replicated database, i.e. on a consumer site is not editable because
this would lead to inconsistencies. That is basically what the error
message tells you.
>> I read lots of procedures using Google, but could not find the solution for this
>> problem. Thus I suggest to add documentation how to configure such a scenario:
>>
>> 1) Set up an LDAP Master server that provides service on a specific IP address
>> using TLS
>> 2) Set up a replication consumer that provides service on a specific IP address
>> using TLS also
>> 3) The replication consumer should use the address where the master server
>> listens for replication
Though a little scattered through the documentation of setting up
replication, man slapd and man slapd-config this is already covered in
the documentation. What you are looking for is a cookbook receipe.
I suggest learning in this order:
1. Setup an ldap server with basic configuration, listening to
protocol://address:port of your liking (you can even have multiple slapd
running on the same host if they use different dbs and ports). Make sure
that, if you use hostnames they point to the right IP addresses.
2. Setup TLS for said server, TLS certificate subject and
subjectAltNames usually do not incorporate ip addresses. Thus all you
require is a working DNS setup.
3. Setup a second ldap server with TLS listening to
protocol://address:port of your liking
4. Setup a syncprov on one of the servers and a syncrepl on the other,
replicating a small test db, e.g. a hdb, bdb, or mdb
5. Should you want to setup a multimaster system, setup syncprov and
syncrepl for both servers cn=config dbs and make sure you enable the
mirrormode
> Some details (randomly picked, with some names obfuscated):
> (master server)
> olcSyncrepl: {0}rid=2 provider="ldap://v07.domain.org/"
> searchbase="dc=domain,dc=org" type="refreshAndPersist" retry="120 +" starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,ou=system,dc=domain,dc=org" credent ials="wNkWudLd3ko8"
I assume you want to replicate cn=config in a multimaster setup,
otherwise this makes no sense. A master does not need a syncrepl
directive for providing syncrepl to a consumer.
> The process is started as "/usr/lib/openldap/slapd -h ldap://ds1.domain.org:389 ldaps://ds1.domain.org:636 ldapi:/// -F /etc/openldap/slapd.d -u ldap -g ldap -o slp=off"
Is this the same 'master' that has the syncrepl directive from above or
a consumer?
> Obviously a connection to the "v07" address is not possible, because the server listens to the "ds1" address.
If you used the above slapd command for your replication provider that
is true. Note that you can specify multiple URIs to -h
> Basically I think I have to fix the "olcSyncrepl provider" and possibly the "olcServerID", but with dynamic configuration I cannot do it:
>
> Using ldapmodify I get:
> v07:~ # ldapmodify -v -ZZ -x -W -D cn=config -H ldap://ds1.domain.org -f /tmp/fix1.ldif
> ldap_initialize( ldap://ds1.domain.org:389/??base )
> Enter LDAP Password:
> replace olcServerID:
> 1 ldap://ds1.domain.org
> modifying entry "cn=config"
> ldap_modify: Server is unwilling to perform (53)
> additional info: shadow context; no update referral
s.a. This tells you that the slapd service you bind to has a replicated
cn=config db which he is not allowed to modify and there is no master
service to which he could refere you to.
> When editing the files in the slap.d directory, I get:
You should not.
The canonical way when you have shut yourself out of your db in this way
is to slapcat your config, edit the output and slapdadd it to the
*offline* server cn=config db. Otherwise you get the reported checksum
errors.
Also the output suggest that you still might not have a syncprov
listening on the interface corresponding to the ip address of the hostname.
###
I fear you have not fully understood how LDAP replication works. I
advise reading the chapter 18 of the OpenLDAP Administration manual
carefully and afterwards have a look at the syncprov overlay and
syncrepl directives (man 5 slapo-syncprov; man 5 slapd-config)
Also I am not sure what you are actually trying to accomplish. Maybe a
set of acceptable requirements for your setup would help, e.g.
- I want one master db provider that provides database content and
updates to all consumer dbs
- I want connections between consumers to use TLS (server auth only |
client and server auth)
...
I hope that I could help you somewhat and look forward to any questions
you still have. (Don't fret, ldap sync setup is not that easy to
understand for the first time)
hth
--
Technische Universität Berlin - FGINET
Bernd May
System Administration
Sekr. TEL 16
Ernst-Reuter-Platz 7
10587 BERLIN
GERMANY
Mobile: 0160/90257737
E-Mail: bernd(a)inet.tu-berlin.de
WWW: inet.tu-berlin.de
12 years, 4 months
Authentication problem
by Jean-Charles
Hello
I have a problem authenticating from a client RedHat 6.3 to a server
RedHat 6.3
Connection is ok
I can change user when I am root with *su paula* with no problem
When I change from non root to paula *su paula* : I am requested a password,
but I get an incorrect password message despite the password bieng correct
Here are the details :
_*SERVER Configuration (obtained with slapcat)
*_
The first database does not allow slapcat; using the first available one
(2)
bdb_db_open: warning - no DB_CONFIG file found in directory
/var/lib/ldap: (2).
Expect poor performance for suffix "dc=jcs-PC,dc=home".
dn: dc=jcs-PC,dc=home
dc: jcs-PC
objectClass: dcObject
objectClass: organization
o: NETEXPANSION
structuralObjectClass: organization
entryUUID: b9dcdb1e-f628-1032-8eef-4f234421cd34
creatorsName: cn=ldapadmin,dc=jcs-PC,dc=home
createTimestamp: 20131210205228Z
entryCSN: 20131210205228.791640Z#000000#000#000000
modifiersName: cn=ldapadmin,dc=jcs-PC,dc=home
modifyTimestamp: 20131210205228Z
dn: ou=employes,dc=jcs-PC,dc=home
objectClass: organizationalUnit
ou: employes
structuralObjectClass: organizationalUnit
entryUUID: 2008d924-f629-1032-8ef0-4f234421cd34
creatorsName: cn=ldapadmin,dc=jcs-PC,dc=home
createTimestamp: 20131210205520Z
entryCSN: 20131210205520.207551Z#000000#000#000000
modifiersName: cn=ldapadmin,dc=jcs-PC,dc=home
modifyTimestamp: 20131210205520Z
dn: cn=Paula Bionda,ou=employes,dc=jcs-PC,dc=home
cn: Paula Bionda
sn: Bionda
uid: paula
uidNumber: 503
gidNumber: 1100
gecos: Paula Bionda
homeDirectory: /home/paula
shadowLastChange: 10877
shadowMin: 0
shadowMax: 999999
shadowWarning: 7
shadowInactive: -1
shadowExpire: -1
shadowFlag: 0
structuralObjectClass: person
entryUUID: e4f37848-f930-1032-985a-91cf669ea788
creatorsName: cn=ldapadmin,dc=jcs-PC,dc=home
createTimestamp: 20131214172830Z
loginShell: /bin/bash
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
userPassword:: e1NTSEF9aEFzWFZFejlIa2xQSUpFSFF2SnpoZmo1cTYzdzRLUlg=
entryCSN: 20131219155524.533147Z#000000#000#000000
modifiersName: cn=Paula Bionda,ou=employes,dc=jcs-PC,dc=home
modifyTimestamp: 20131219155524Z
dn: ou=groups,dc=jcs-PC,dc=home
objectClass: organizationalUnit
ou: groups
structuralObjectClass: organizationalUnit
entryUUID: e1a8545a-fa85-1032-84b7-a9514c4c1551
creatorsName: cn=ldapadmin,dc=jcs-PC,dc=home
createTimestamp: 20131216100923Z
entryCSN: 20131216100923.403228Z#000000#000#000000
modifiersName: cn=ldapadmin,dc=jcs-PC,dc=home
modifyTimestamp: 20131216100923Z
dn: cn=mygroup,ou=groups,dc=jcs-PC,dc=home
objectClass: top
objectClass: posixGroup
cn: mygroup
gidNumber: 1100
memberUid: paula
memberUid: giuseppe
structuralObjectClass: posixGroup
entryUUID: c26713a0-fa9f-1032-8b7d-155dd966052d
creatorsName: cn=ldapadmin,dc=jcs-PC,dc=home
createTimestamp: 20131216131437Z
entryCSN: 20131216131437.881194Z#000000#000#000000
modifiersName: cn=ldapadmin,dc=jcs-PC,dc=home
modifyTimestamp: 20131216131437Z
_*CLIENT C*__*onfiguration *_
authconfig-tui gives
[] Cache Infomation
[*] Use LDAP
[] Use NIS
[] Use IPAV2
[] Use WinBind
[*] Use MD5 Passwords
[*] Use Shadow Passwords
[*] Use LDAP Authentication
[] Use Kerboros
[*] Use Fingerprint Reader
[] Use Windbind Authentication
[*] Local Authorization is sufficient
[] Use TLS
ldap://192.168.1.12/
Base DN: dc=jcs-PC,dc=home
_*Result su paula
*_
a) when I am logged in as root, *su paula* logs me into paula : no problem
b) when I am not logged in as root and I do *su paula*
I am requested a password (as expected), but then I get incorrect
password despite the password being correct
Here is the log
Dec 19 18:49:50 jcs-PC slapd[6441]: => slap_access_allowed: backend
default read access granted to "(anonymous)"
Dec 19 18:49:50 jcs-PC slapd[6441]: => access_allowed: read access
granted by read(=rscxd)
Dec 19 18:49:50 jcs-PC slapd[6441]: conn=1005 op=3 SEARCH RESULT tag=101
err=0 nentries=1 text=
Dec 19 18:49:50 jcs-PC slapd[6441]: conn=1006 fd=21 ACCEPT from
IP=192.168.1.17:56000 (IP=0.0.0.0:389)
Dec 19 18:49:50 jcs-PC slapd[6441]: conn=1006 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Dec 19 18:49:50 jcs-PC slapd[6441]: conn=1006 op=0 STARTTLS
Dec 19 18:49:50 jcs-PC slapd[6441]: conn=1006 op=0 RESULT oid= err=0 text=
Dec 19 18:49:50 jcs-PC slapd[6441]: conn=1006 fd=21 closed (TLS
negotiation failure)
Dec 19 19:04:43 jcs-PC slapd[6441]: conn=1005 op=4 UNBIND
Dec 19 19:04:43 jcs-PC slapd[6441]: conn=1005 fd=14 closed
And these are the last 2 lines of wireshark
_Source_
_Destination_
_Protocol_ _Info_
192.168.1.17(Client) 192.168.1.12 (Server)
LDAP ExtendedReq LDAP_START_TLS_OID
192.168.1.12 192.168.1.17
LDAP ExtendedResp LDAP_START_TLS_OID
responseName missing
I am surprised about STARTLS because there seems to be nothing in my
configuration files about TLS
Thank you
Axel
--
11 years, 11 months
答复: 回复： mirror mode question
by 田格瑄
Hi Dieter,
Thanks for your kindly replies.
In my case, I don't use any SASL. I want to use simple bind, but my mirror mode can't work when my rootpw in hash( if the rootpw is in cleartext , the mirror mode can work). Could you pls advice what is wrong with my configration?
My slapd.conf file set as below.
moduleload syncprov.la
database bdb
suffix "dc=xxx,dc=xxx"
checkpoint 1024 15
rootdn "cn=manager,dc=xxx,dc=xxx"
rootpw {SSHA}aeiyuikahdkfjhdiuvy
directory /var/lib/ldap/xxx
access to *
by self write
by * read
# Indices to maintain for this database
index objectClass,entryCSN,entryUUID 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
serverID 1 (ldap2 service is 2)
syncrepl rid=001
provider=ldap://other side ip
bindmethod=simple
binddn="cn=manager,dc=xxx,dc=xxx"
credentials={SSHA} aeiyuikahdkfjhdiuvy
searchbase="dc=xxx,dc=xxx"
schemachecking=on
type=refreshAndPersist
retry="60 +"
mirrormode on
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
Thanks and regards
tiangexuan
-----邮件原件-----
发件人: openldap-technical-bounces(a)OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.org] 代表 Dieter Klünter
发送时间: 2014年4月8日 16:25
收件人: openldap-technical(a)openldap.org
主题: Re: 回复： mirror mode question
Hi,
If I remeber correctly, you mentioned sasl authentication. My comments on plaintext passwords are only related to sasl authentication. A sasl authentication is based on a SASL MECHANISM, as described in rfc-4422.
In order to compare the sasl authentication string with the stored password value, this has to be cleartext.
If your ldap operation is based on a simple bind, the stored password can, and should be, hashed.
-Dieter
Am Tue, 8 Apr 2014 14:16:31 +0800
schrieb 田格瑄 < <mailto:tiangexuan@sinap.ac.cn> tiangexuan(a)sinap.ac.cn>:
> Hi Michael and Dieter,
>
>
>
> I see the below mail, can I understand only the mirror mode
> replication can’t use the HASH password in rootpw, other Synchronous
> replication mode(example: syncrepl proxy) can use the HASH password?
>
>
>
> Thanks and regards
>
> tiangexuan
>
>
>
> ------------------ 原始邮件 ------------------
>
> 发件人: "Michael Ströder";<michael(a)stroeder.com
> < <mailto:michael@stroeder.com> mailto:michael@stroeder.com> >;
>
> 发送时间: 2014年3月5日(星期三) 下午4:09
>
> 收件人: "Dieter Klünter"< <mailto:dieter@dkluenter.de%20%3cmailto:dieter@dkluenter.de> dieter(a)dkluenter.de <mailto:dieter@dkluenter.de>
> >; "openldap-technical"<openldap-technical(a)openldap.org
> < <mailto:openldap-technical@openldap.org> mailto:openldap-technical@openldap.org> >;
>
> 主题: Re: mirror mode & sasl question
>
>
>
> Dieter Klünter wrote:
> > Am Wed, 5 Mar 2014 14:38:04 +0800
> > schrieb "Eileen(=^ω^=)" < <mailto:123784635@qq.com%20%3cmailto:123784635@qq.com> 123784635(a)qq.com <mailto:123784635@qq.com>
> > >:
> >> This is Eileen from China SINAP. I am a beginner for openldap soft.
> >> I encountered a problem in my study on two LDAP services
> >> replication. I have 2 LDAP services, one name LDPA1, the other is
> >> LDAP2 . I want to make them synchronously in mirror mode. But when
> >> I set LDAP services rootpw both in hash, the 2 LDAP serivces can’t
> >> be synchronous. My question is
> >> 1. if I set my rootpw in hash, my bindmethod must be SASL? If
> >> I must use sasl method, can I put the sasl service in the same ldap
> >> service? If bindmethod=sasl then what is the saslmech should be?
> >> 2. If I change to sasl method, do I need change my database
> >> record?
> >
> > In order to use sasl, passwords must be cleartext and you should
> > configure an apropriate authz-regexp, see man slapd.conf(5) You may
> > use any sasl mechanism that you sasl framework provides.
> > [...]
>
> To be more precise: In order to use password-based SASL mechs the
> passwords have to be stored in clear-text.
>
> Well, if working with SASL and TLS (LDAPS, StartTLS) one should
> consider using client certs and SASL/EXTERNAL for replication.
>
> Ciao, Michael.
>
>
>
--
Dieter Klünter | Systemberatung
<http://sys4.de> http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
11 years, 7 months
Issue with replication
by Jignesh Patel
We are running openldap in cluster mode with MDB setup, and we started second cluster after some time and we observe that data is non synch between those 2 servers.
So how do we synchronize the data.
> On Sep 7, 2018, at 8:00 AM, openldap-technical-request(a)openldap.org wrote:
>
> Send openldap-technical mailing list submissions to
> openldap-technical(a)openldap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.openldap.org/lists/mm/listinfo/openldap-technical
> or, via email, send a message with subject or body 'help' to
> openldap-technical-request(a)openldap.org
>
> You can reach the person managing the list at
> openldap-technical-owner(a)openldap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openldap-technical digest..."
>
>
> Send openldap-technical mailing list submissions to
> openldap-technical(a)openldap.org
> When replying, please edit your Subject: header so it is more specific than "Re: openldap-technical digest..."
>
> Today's Topics:
>
> 1. Replication issue? Data is different between master and
> consumer with same entryCSNs (Dave Steiner)
> 2. olcSecurity: tls=1 and olcLocalSSF= : what value should I
> use? (Jean-Francois Malouin)
> 3. Re: olcSecurity: tls=1 and olcLocalSSF= : what value should I
> use? (Quanah Gibson-Mount)
> 4. Re: Replication issue? Data is different between master and
> consumer with same entryCSNs (Frank Swasey)
> 5. Re: Replication issue? Data is different between master and
> consumer with same entryCSNs (Quanah Gibson-Mount)
> 6. Re: olcSecurity: tls=1 and olcLocalSSF= : what value should I
> use? (Jean-Francois Malouin)
> 7. Re: Replication issue? Data is different between master and
> consumer with same entryCSNs (Dave Steiner)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 5 Sep 2018 16:49:44 -0400
> From: Dave Steiner <steiner(a)rutgers.edu>
> To: openldap-technical(a)openldap.org
> Subject: Replication issue? Data is different between master and
> consumer with same entryCSNs
> Message-ID: <129e3614-50fe-ba15-4d4b-5f94d14abcd9(a)oit.rutgers.edu>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
>
> I've been noticing various data discrepancies between our LDAP master and LDAP
> consumers.? We are running OpenLDAP v2.4.44.? We have two masters running
> "mirromode TRUE" and all updates go through a VIP that points to the first one
> unless it's not available (doesn't happen very often except for during patches
> and restarts). We have 13 consumers that replicate through that same VIP.
>
> Here's an example of our syncrepl for a client:
>
> syncrepl rid=221
> ? type=refreshAndPersist
> ? schemachecking=on
> ? provider="ldap://ldapmastervip.rutgers.edu/"
> ? bindmethod=sasl
> ? saslmech=EXTERNAL
> ? starttls=yes
> ? tls_reqcert=demand
> ? tls_protocol_min="3.1"
> ? searchbase="dc=rutgers,dc=edu"
> ? attrs="*,+"
> ? retry="10 10 20 +"
> ? logbase="cn=accesslog"
> ? logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
> ? syncdata=accesslog
> ? network-timeout=30
> ? keepalive=180:3:60
>
> I check the contextCSN attributes on all the instances every day and they are
> all in sync (except during any major changes, of course). But I occasionally
> notice discrepancies in the data.... even though the contextCSNs and entryCSNs
> are the same.? For example (note hostnames have been changed):
>
> $ ldapsearch ... -H ldap://ldapmaster.rutgers.edu uid=XXXX postalAddress
> createTimestamp modifyTimestamp entryCSN
> dn: uid=XXXX,ou=People,dc=rutgers,dc=edu
> createTimestamp: 20121220100700Z
> postalAddress: Business And Science Bldg$227 Penn Street$Camden, NJ 081021656
> entryCSN: 20180505002024.083133Z#000000#001#000000
> modifyTimestamp: 20180505002024Z
>
> $ ldapsearch ... -H ldap://ldapconsumer3.rutgers.edu uid=XXXX postalAddress
> createTimestamp modifyTimestamp entryCSN
> dn: uid=XXXX,ou=People,dc=rutgers,dc=edu
> createTimestamp: 20121220100700Z
> postalAddress: BUSINESS AND SCIENCE BLDG$227 PENN STREET$CAMDEN, NJ 081021656
> entryCSN: 20180505002024.083133Z#000000#001#000000
> modifyTimestamp: 20180505002024Z
>
> So I'm trying to figure out why this happens (config issue, bug, ???) and
> second, if I can't use the contextCSN to report that everything is fine, what
> else can I do besides trying to compare ldif dumps.
>
> thanks,
> ds
> --
> Dave Steiner steiner(a)rutgers.edu
> IdM, Enterprise Application Services ?? ASB101; 848.445.5433
> Rutgers University, Office of Information Technology
>
>
6 years, 9 months
Re: objectclass sambaSamAccount
by Laurence Mayer
Hi Scott,
See below.
Thanks
Laurence
[root@fs1 ldap]# cat /etc/openldap/slapd.conf
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/samba.schema
# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
# Load dynamic backend modules:
#modulepath /usr/lib64/openldap
#moduleload back_bdb.la
#moduleload back_ldap.la
#moduleload back_ldbm.la
#moduleload back_passwd.la
#moduleload back_shell.la
# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client
software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
access to attrs=userPassword
by self write
by anonymous auth
by * none
#access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
database bdb
suffix "dc=istraresearch,dc=com"
rootdn "cn=xxxxx,dc=istraresearch,dc=com"
rootpw xxxxxxx
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# 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/sldap
# 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
# 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
Scott Classen wrote:
> Hi Laurence,
>
> What does your sldap.conf file look like? You are probably not including
> the proper samba schema file.
>
> Scott
>
> On Sep 2, 2008, at 6:47 AM, Laurence Mayer wrote:
>
>> Hi,
>>
>> OS: Linux Redhat x86_64
>> OpenLdap 2.3.27
>>
>> I am trying to add an objectclass sambaSamAccount to my ou=People.
>> My goal would be to have both samba and posix account for each user.
>>
>> I have included the samba schema to the slapd.conf file.
>>
>> I tried adding this to a file and running ldapadd:
>>
>> dn: uid=laurence, ou=People,dc=istraresearch,dc=com
>> sambaLogonTime: 0
>> displayName: Laurence Mayer
>> sambaLMPassword: xxxxx
>> sambaPrimaryGroupSID: S-1-5-21-2447931902-1787058256-3961074038-1201
>> objectClass: sambaSamAccount
>> sambaAcctFlags: [UX ]
>> gidNumber: 100
>> sambaKickoffTime: 2147483647
>> sambaPwdLastSet: 1010179230
>> sambaSID: S-1-5-21-2447931902-1787058256-3961074038-5004
>> sambaPwdCanChange: 0
>> sambaPwdMustChange: 2147483647
>> sambaNTPassword: xxxx
>>
>>
>> However I received the error:
>> adding new entry "uid=laurence, ou=People,dc=istraresearch,dc=com"
>> ldap_add: Internal (implementation specific) error (80)
>> additional info: no structuralObjectClass operational attribute
>>
>>
>> Please can you tell me what I need to do to achieve this.
>>
>> Thanks in advance
>>
>> Laurence
--
--------------------------
Laurence Mayer
Director of Operations & IT
Istra Research Ltd.
Tel: +972545233107
Fax: +972722765124
17 years, 2 months
Re: Security between server and client nodes.
by Jayavant Patil
On Wed, 30 Nov 2011 14:18:00 +0100 Raffael Sahli <public(a)raffaelsahli.com>
wrote:
>On 11/30/2011 01:48 PM, Jayavant Patil wrote:
>
>
> >>On 11/30/2011 08:01 AM, Jayavant Patil wrote:
> >>
> >>
> >> On Tue, Nov 29, 2011 at 6:26 PM, Jayavant Patil
> >> <jayavant.patil82(a)gmail.com <mailto:jayavant.patil82@gmail.com>
> <mailto:jayavant.patil82@gmail.com
> <mailto:jayavant.patil82@gmail.com>>> wrote:
> >>
> >>
> >> >>Mon, 28 Nov 2011 11:25:16 +0100 Raffael Sahli
> >> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>
> <mailto:public@raffaelsahli.com <mailto:public@raffaelsahli.com>>> wrote:
> >> >>Hi
> >>
> >> >>I think you mean SSL connection or the STARTTLS Layer...?
> >> >>Please read the manual http://www.openldap.org/doc/admin24/tls.html
> >> >Ok.
> >>
> >> >>And tree security:
> >> >>On my server, a client user can only see his own object:
> >> >Are you using simple authentication mechanism?
> >>
> >> >>Maybe create a rule like this:
> >> >>access to filter=(objectClass=
> >> >>simpleSecurityObject)
> >> >> by self read
> >> >> by * none
> >>
> >> >I am not getting what the ACL rule specifies. Any suggestions?
> >>
> >>
> >> I have two users ldap_6 and ldap_7. I want to restrict a user to
> >> see his own data only.
> >> In slapd.conf, I specified the rule as follows:
> >> access to *
> >> by self write
> >> by * none
> >>
> >> But ldap_6 can see the ldap_7 user entries (or vice versa) with
> >> $ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> >> "ou=People,dc=abc,dc=com" "uid=ldap_7"
> >>
> >> Any suggestions?
> >>
> >On Wed, 30 Nov 2011 08:38:32 +0100 Raffael Sahli
> <public(a)raffaelsahli.com <mailto:public@raffaelsahli.com>> wrote:
> >Yes, that's exactly the rule I wrote above.
>
> >access to filter=(objectClass=
> >simpleSecurityObject)
> > by self read
> > by * none
>
>
> >Maybe you have to change the objectClass to posixAccount, or both or
> >whatever....
>
> >access to
> >filter=(|(objectClass=
simpleSecurityObject)(objectClass=posixAccount))
> > by self read
> > by * none
>
>
> >Just add this rule before the global rule "access to *"
>
>
> >>ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -b
> >>"ou=People,dc=abc,dc=com" "uid=ldap_7"
>
> >And if you search like this with bind "admin dn", you will see every
> >object....
> >You have to bind with user ldap_6 and not with root
> But anyway client user knows the admin dn and rootbindpassword. So,
> with this he will look into all directory information to which he is
> not supposed to do.
> e.g. ldapsearch -x -v -D "cn=root,dc=abc,dc=com" -w cluster
>
> So, how to avoid this?
>
>Why client user knows the admin dn and pw????????
Because /etc/ldap.conf file on client contains admin dn and pw.
Each user information in the directory contains the following entries(here,
e.g. ldap_6)
dn: uid=ldap_6,ou=People,dc=abc,dc=com
uid: ldap_6
cn: ldap_6
sn: ldap_6
mail: ldap_6(a)abc.com
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
objectClass: hostObject
objectClass: simpleSecurityObject
shadowLastChange: 13998
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 514
gidNumber: 514
homeDirectory: /home/ldap_6
host: *
userPassword:: e2NyeXB0fSQxJGRUb1p6bVp5JGY2VFF5UWMxNndSbjdLcHpnMUlsdS8=
So, what should be the ACL rule so that each user can see his data only? I
tried but not getting the required, even the user himself is unable to see
his own data.
--
Thanks & Regards,
Jayavant Ningoji Patil
Engineer: System Software
Computational Research Laboratories Ltd.
Pune-411 004.
Maharashtra, India.
+91 9923536030.
13 years, 12 months
Re: top-level data entries not replicating, 2.4.15, now 2.4.17
by Brian Neu
I compiled new rpms and upgraded to 2.4.17 on both the provider and consumer. The problem persists.
New entries like:
dn:cn=test2,dc=srg,dc=com
objectclass: top
objectclass: person
userpassword:blah
sn:test2
don't replicate. But other entries do, like:
dn: uid=user1,ou=People,dc=srg,dc=com
uid: user1
cn: Advanced Open Systems
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword::
shadowLastChange: 14441
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 5000
gidNumber: 5000
homeDirectory: /home/user1
gecos: Advanced Open Systems
I've attached the slapd.conf for the master/provider.
Thank you in advance for any assistance.
--- On Thu, 8/20/09, Brian Neu <proclivity76(a)yahoo.com> wrote:
> From: Brian Neu <proclivity76(a)yahoo.com>
> Subject: Re: top-level data entries not replicating, 2.4.15
> To: "Jonathan Clarke" <jonathan(a)phillipoux.net>
> Cc: openldap-technical(a)openldap.org
> Date: Thursday, August 20, 2009, 8:39 AM
> Forgive me if pasting here is bad
> etiquette.
>
>
> <consumer slapd.conf>
>
> include
> /etc/openldap/schema/corba.schema
> include
> /etc/openldap/schema/core.schema
> include
> /etc/openldap/schema/cosine.schema
> include
> /etc/openldap/schema/duaconf.schema
> include
> /etc/openldap/schema/dyngroup.schema
> include
> /etc/openldap/schema/inetorgperson.schema
> include
> /etc/openldap/schema/java.schema
> include
> /etc/openldap/schema/misc.schema
> include
> /etc/openldap/schema/nis.schema
> include
> /etc/openldap/schema/openldap.schema
> include
> /etc/openldap/schema/ppolicy.schema
> include
> /etc/openldap/schema/collective.schema
> include
> /etc/openldap/schema/samba.schema
>
> allow bind_v2
>
> pidfile
> /var/run/openldap/slapd.pid
> argsfile
> /var/run/openldap/slapd.args
>
> TLSCACertificateFile /etc/openldap/cacerts/cavictory2.crt
> TLSCertificateFile /etc/openldap/keys/victory3cert.pem
> TLSCertificateKeyFile /etc/openldap/keys/victory3key.pem
>
> database hdb
> suffix "dc=srg,dc=com"
> checkpoint 1024 15
> rootdn
> "cn=Manager,dc=srg,dc=com"
>
> rootpw {MD5}blah
>
> directory /var/lib/ldap
>
> 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
>
> syncrepl rid=0
>
> provider=ldap://victory2.srg.com:389
> bindmethod=simple
> starttls=critical
>
> binddn="cn=replicator,dc=srg,dc=com"
> credentials=blah
> searchbase="dc=srg,dc=com"
> logbase="cn=accesslog"
> schemachecking=on
> type=refreshAndPersist
> retry="60 +"
> syncdata=accesslog
>
> updateref
> ldaps://victory2.srg.com
>
> database monitor
>
> access to *
> by
> dn.exact="cn=Manager,dc=srg,dc=com" write
> by * none
>
> </consumer slapd.conf>
>
>
> --- On Thu, 8/20/09, Jonathan Clarke <jonathan(a)phillipoux.net>
> wrote:
>
> > From: Jonathan Clarke <jonathan(a)phillipoux.net>
> > Subject: Re: top-level data entries not replicating,
> 2.4.15
> > To: "Brian Neu" <proclivity76(a)yahoo.com>
> > Cc: openldap-technical(a)openldap.org
> > Date: Thursday, August 20, 2009, 8:02 AM
> > On 19/08/2009 19:29, Brian Neu
> > wrote:
> > > Even with no logfilter on the consumer,
> > >
> > cn=replicator,dc=domain,dc=com&
> > >
> > sambaDomainName=SRG,dc=domain,dc=com
> > >
> > > don't replicate, even after wiping the database
> and
> > restarting. Everything else seems to replicate
> fine.
> > >
> > > How do I get top-level data entries to
> replicate?
> >
> > This really depends on your syncrepl configuration on
> the
> > consumer.
> > If you provide it here, maybe we can take a look.
> >
> > Aside from that, the latest version, 2.4.17, contains
> a few
> > fixes that
> > might help with this problem.
> >
> > Jonathan
> >
>
16 years, 3 months
RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount
This is expected to be the final testing call for 2.4.45, with an
anticipated release, depending on feedback, during the week of 2017/05/29.
For this testing call, we particularly need folks to test OpenLDAP with
startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series and with
the 1.1 series). There is currenly nothing in the test suite that covers
encrypted connections (Although it's on my todo list). To build against
OpenSSL 1.1 may also require cyrus-sasl HEAD out of the cyrus-sasl GIT
repository, depending on your build options as the current cyrus-sasl
release does not support the OpenSSL 1.1 series. It can be found at
<https://github.com/cyrusimap/cyrus-sasl>. If you build with GSSAPI and
use Heimdal, you will also need the Heimdal 7.1.0 or later release (as that
is where OpenSSL 1.1 support was added). It can be obtained from
<http://h5l.org/>.
Also new with this release is the ability to run "make its" in the tests/
directory. This will run a specific set of tests around past bugs to
ensure there are no regressions. While I've tested this with modular
openldap builds, it has not been tested with the modules and backends built
into slapd, so there could be some issues in that scenario.
Generally, get the code for RE24:
<http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h…>
Configure & build.
Execute the test suite (via make test) after it is built. Optionally, cd
tests && make its run through the regression suite.
Thanks!
OpenLDAP 2.4.45 Engineering
Added slapd support for OpenSSL 1.1.0 series (ITS#8353, ITS#8533,
ITS#8634)
Fixed libldap to fail ldap_result if the handle is already bad
(ITS#8585)
Fixed libldap to expose error if user specified CA doesn't exist
(ITS#8529)
Fixed libldap handling of Diffie-Hellman parameters (ITS#7506)
Fixed libldap GnuTLS use after free (ITS#8385)
Fixed libldap SASL initialization (ITS#8648)
Fixed slapd bconfig rDN escape handling (ITS#8574)
Fixed slapd segfault with invalid hostname (ITS#8631)
Fixed slapd sasl SEGV rebind in same session (ITS#8568)
Fixed slapd syncrepl filter handling (ITS#8413)
Fixed slapd syncrepl infinite looping mods with delta-sync MMR
(ITS#8432)
Fixed slapd callback struct so older modules without writewait
should function.
Custom modules may need to be updated for sc_writewait
callback (ITS#8435)
Fixed slapd-ldap/meta broken LDAP_TAILQ macro (ITS#8576)
Fixed slapd-mdb so it passes ITS6794 regression test (ITS#6794)
Fixed slapd-mdb double free with size zero paged result (ITS#8655)
Fixed slapd-meta uninitialized diagnostic message (ITS#8442)
Fixed slapo-accesslog to honor pauses during purge for cn=config
update (ITS#8423)
Fixed slapo-accesslog with multiple modifications to the same
attribute (ITS#6545)
Fixed slapo-relay to correctly initialize sc_writewait (ITS#8428)
Fixed slapo-sssvlv double free (ITS#8592)
Fixed slapo-unique with empty modifications (ITS#8266)
Build Environment
Added test065 for proxyauthz (ITS#8571)
Fix test008 to be portable (ITS#8414)
Fix test064 to wait for slapd to start (ITS#8644)
Fix its4336 regression test (ITS#8534)
Fix its4337 regression test (ITS#8535)
Fix regression tests to execute on all backends (ITS#8539)
Contrib
Added slapo-autogroup(5) man page (ITS#8569)
Added passwd missing conversion scripts for apr1 (ITS#6826)
Fixed contrib modules where the writewait callback was not
correctly initialized (ITS#8435)
Fixed smbk5pwd to build with newer OpenSSL releases
(ITS#8525)
Documentation
admin24 fixed tls_cipher_suite bindconf option (ITS#8099)
admin24 fixed typo cn=config to be slapd.d (ITS#8449)
admin24 fixed slapo-syncprov information to be curent
(ITS#8253)
admin24 fixed typo in access control docs (ITS#7341,
ITS#8391)
admin24 fixed minor typo in tuning guide (ITS#8499)
admin24 fixed information about the limits option (ITS#7700)
admin24 fixed missing options for syncrepl configuration
(ITS#7700)
admin24 fixed accesslog documentation to note it should not
be replicated (ITS#8344)
Fixed ldap.conf(5) missing information on SASL_NOCANON
option (ITS#7177)
Fixed ldapsearch(1) information on the V[V] flag behavior
(ITS#7177, ITS#6339)
Fixed slapd-config(5), slapd.conf(5) clarification on
interval keyword for refreshAndPersist (ITS#8538)
Fixed slapd-config(5), slapd.conf(5) clarify serverID
requirements (ITS#8635)
Fixed slapd-config(5), slapd.conf(5) clarification on
loglevel settings (ITS#8123)
Fixed slapo-ppolicy(5) to clearly note rootdn requirement
(ITS#8565)
Fixed slapo-memberof(5) to note it is not safe to use with
replication (ITS#8613)
Fixed slapo-syncprov(5) documentation to be current
(ITS#8253)
Fixed slapadd(8) manpage to note slapd-mdb (ITS#8215)
Fixed various minor grammar issues in the man pages
(ITS#8544)
Fixed various typos (ITS#8587)
LMDB 0.9.20 Release Engineering
Fix mdb_load with escaped plaintext (ITS#8558)
Fix mdb_cursor_last / mdb_put interaction (ITS#8557)
Thanks,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
8 years, 6 months