slapd-meta
by Fr3ddie
Hello to the list,
I'm trying to configure the slapd-meta OpenLDAP backend on an online
cn=config
configuration with no luck. Slapd version is 2.4.39 (the maximum I can
achieve on the target machines building from vanilla source).
The documentation is clear but too concise for me so I will try to explain
what I'm trying to do to see if there is anybody that can help me.
Currently I have 3 slapd servers that share a common root for the DIT, i.e.:
dc=loc1,dc=root
dc=loc2,dc=root
dc=loc3,dc=root
What I would like to achieve is to obtain a fourth server that contains
the previous trees, along with its own tree, i.e. a server that contains:
dc=loc0,dc=root (locally hosted data)
dc=loc1,dc=root (coming from the first server, chasing referrals)
dc=loc2,dc=root (coming from the second server, chasing referrals)
dc=loc3,dc=root (coming from the third server, chasing referrals)
this way, all the clients connecting to this server will be able to
retrieve data also from the other three remote servers.
As far as I understood, I only need to configure the "loc0" server to access
the other three servers and get the data to serve to clients.
I have already configured the fourth server with its local DIT and this is
the configuration:
# cat 'cn=config.ldif'
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcPidFile: /var/run/slapd/slapd.pid
structuralObjectClass: olcGlobal
creatorsName: cn=config
olcServerID: 1
olcThreads: 32
olcToolThreads: 8
olcRequires: LDAPv3
olcConnMaxPendingAuth: 100
olcTLSCACertificateFile: /etc/ssl/certs/my_ca_cert.pem
olcTLSCertificateFile: /etc/ssl/certs/this-host_x509_cert.pem
olcTLSCertificateKeyFile: /etc/ssl/private/this-host_x509_key.key
olcTLSVerifyClient: try
olcTimeLimit: 600
olcLogLevel: stats2 sync
[...]
# cat 'cn=module{0}.ldif'
dn: cn=module{0}
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}accesslog
structuralObjectClass: olcModuleList
[...]
Schema files are the following:
cn={0}core.ldif
cn={1}cosine.ldif
cn={2}nis.ldif
cn={3}inetorgperson.ldif
cn={4}dyngroup.ldif
cn={5}kerberos.ldif
# cat 'olcDatabase={1}hdb.ldif'
dn: olcDatabase={1}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=loc0,dc=root
olcAccess: {0}to
attrs=userPassword,shadowLastChange,krbPrincipalKey by dn="cn
=admin,dc=loc0,dc=root" write by anonymous auth by self write by *
none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by dn="cn=admin,dc=loc0,dc=root" write by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=loc0,dc=root
olcRootPW:: xxxxxxxxxxxxxxxxxxxx
olcDbCacheSize: 10000
olcDbCheckpoint: 512 10
olcDbConfig: {0}set_cachesize 0 524288000 1
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE
olcDbIDLcacheSize: 30000
olcDbIndex: default pres,eq
[...]
structuralObjectClass: olcHdbConfig
olcSyncrepl: {0}rid=0 provider=ldap://second-host.loc0.root
bindmethod=s
imple binddn="cn=admin,dc=loc0,dc=root" credentials=xxxxxx
searchbase="dc=loc0,dc=root"
logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObj
ect)(reqResult=0))" schemachecking=on type=refreshAndPersist
retry="60 +" syn
cdata=accesslog starttls=yes
olcMirrorMode: TRUE
[...]
On top of this DB I have the "syncprov" and the "accesslog" overlays
configured
(these are two servers in "MirrorMode", configured following the
OpenLDAP admin documentation).
I believe this DB is the ones containing the actual "loc0" DIT data...
Then I have the accesslog DB for the replica (with the syncprov overlay
on top):
# cat 'olcDatabase={2}hdb.ldif'
dn: olcDatabase={2}hdb
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap/accesslog
olcSuffix: cn=accesslog
olcRootDN: cn=admin,dc=loc0,dc=root
olcDbConfig: {0}set_cachesize 0 524288000 1
olcDbConfig: {1}set_lk_max_objects 1500
olcDbConfig: {2}set_lk_max_locks 1500
olcDbConfig: {3}set_lk_max_lockers 1500
olcDbConfig: {4}set_flags DB_LOG_AUTOREMOVE
olcDbIndex: default eq
olcDbIndex: entryCSN,objectClass,reqEnd,reqResult,reqStart
[...]
On top of this environment I start loading the needed modules with this
LDIF file:
version: 1
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: back_ldap
-
add: olcModuleLoad
olcModuleLoad: back_meta
-
add: olcModuleLoad
olcModuleLoad: rwm
and it seems I'm able to load the new modules without errors
into the configuration, thus I obtain:
# cat 'cn=module{0}.ldif'
dn: cn=module{0}
structuralObjectClass: olcModuleList
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_hdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}accesslog
olcModuleLoad: {3}back_ldap
olcModuleLoad: {4}back_meta
olcModuleLoad: {5}rwm
[...]
Now I try to load the slapd-meta directives into a new database using
this LDIF:
version: 1
dn: olcDatabase={3}meta,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMetaConfig
olcDatabase: {3}meta
olcSuffix: dc=root
olcDbURI: "ldap://server-loc1.loc1.root/dc=loc1,dc=root"
olcDbIdAssertBind: bindmethod=simple
binddn="cn=admin,dc=loc1,dc=root" credentials=xxxxxx starttls=yes
tls_reqcert=demand
olcDbURI: "ldap://server-loc2.loc2.root/dc=loc2,dc=root"
olcDbIdAssertBind: bindmethod=simple
binddn="cn=admin,dc=loc2,dc=root" credentials=xxxxxx starttls=yes
tls_reqcert=demand
olcDbURI: "ldap://server-loc3.loc3.root/dc=loc3,dc=root"
olcDbIdAssertBind: bindmethod=simple
binddn="cn=admin,dc=loc3,dc=root" credentials=xxxxxx starttls=yes
tls_reqcert=demand
but I obtain an error that sticks me trying various combinations without
success:
# ldapadd -Y EXTERNAL -H ldapi:/// -f slapd-META-DB-CREATION.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcDatabase={3}meta,cn=config"
ldap_add: Object class violation (65)
additional info: attribute 'olcDbURI' not allowed
and:
# tail /var/log/openldap/slapd.log
Nov 9 19:47:17 server01 slapd[32392]: conn=1025 op=2 ENTRY
dn="dc=loc0,dc=root"
Nov 9 19:47:29 server01 slapd[32392]: conn=1052 op=2 INTERM
oid=1.3.6.1.4.1.4203.1.9.1.4
Nov 9 19:49:47 server01 slapd[32392]: conn=1327 op=2 ENTRY
dn="dc=loc0,dc=root"
Nov 9 19:52:17 server01 slapd[32392]: conn=1628 op=2 ENTRY
dn="dc=loc0,dc=root"
Nov 9 19:54:46 server01 slapd[32392]: conn=1929 op=2 ENTRY
dn="dc=loc0,dc=root"
Nov 9 19:57:07 server01 slapd[32392]: Entry
(olcDatabase={3}meta,cn=config), attribute 'olcDbURI' not allowed
Into the slapd-meta documentation the "URI" directive is mentioned but
the "DbURI" seems to
raise a "better error", in fact if I try to modify the above LDIF file
using "URI" I obtain:
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
adding new entry "olcDatabase={3}meta,cn=config"
ldap_add: Undefined attribute type (17)
additional info: olcUri: attribute type undefined
Moreover, it is not stated into the slapd-meta docs that the slapd-ldap
backend is needed by slapd-meta but,
anyway, I think its needed because if I try to load the slapd-meta alone
it raises an error (I don't remember exactly which one).
At this point I'm stuck to this error and I wasn't able to find any hint
on the web to solve this :(
The examples I was able to find were related with the static slapd.conf
configuration, I counldn't
find any "full" configuration example using the cn=config.
I'm wondering if I should create a "cn=root" actual DB first and then
link the sub-DITs to it,
or, maybe, add some other overlay... I really can't understand how it
should work :(
Can please anybody help me?
Thank you very much
6 years, 11 months
Documentation Feedback
by Tom Jay
Hello,
I would like to voice my frustration with the quality of the openLDAP documentation. I am compiling openLDAP from source on Debian 7, and have spent about 2-3 continuous days getting to the point where I can add an LDAP user with a UID. I have been close to giving up with the software, but need it for the LDAP functionality, and as very few viable alternatives exist, have been forced to continue with the installation. I have however almost lost confidence in the product, and am concerned that if there are any problems with it in the future, or I want to enable another feature, I will be almost helpless in getting it to work.
The main problem is the Quick-Start Guide. This is anything but quick, and forces the user to consult the less-than-succinct Admin guide. The two together are inconsistent, difficult to follow and do a poor job of explaining what each feature does. The accessibility of information is less than optimal, which means that the user has to look elsewhere, consuming even more time. Unfortunately, there is not much relevant information on the Internet, forcing the user to get stuck in an almost endless loop of checking documentation, testing, reading manuals, and searching on the Internet, in order to get some kind of idea how the software works and what needs to be done to get it working.
I would offer to contribute to the documentation, but due to its lack of usefulness, do not have an understanding of the basic concepts myself. The best I would be able to do is describe my experience and provide the steps that I followed to get a basic installation working.
Hopefully someone can volunteer the time to test the documentation, in the same way a new user would!
Tom
7 years
UNKNOWN attributeDescription "ATTRIBUTE1" inserted
by PenguinWhispererThe
Hi all,
I've been trying to update a schema with new olcAttributeTypes and modified
an existing objectClass (X) so these attributesTypes may be used with it.
However after adding these attributes to objectClass X I did a "rollback"
(replacing the current olcObjectClasses (replace: olcObjectClasses) with
the old definition and the same for the olcAttributes (replace:
olcAttributeTypes).
I think somewhere along the way something wasn't cleaned up properly.
Now when I start slapd service I get:
slapd[21335]: UNKNOWN attributeDescription "ATTRIBUTE1 " inserted.
slapd[21335]: UNKNOWN attributeDescription "ATTRIBUTE2" inserted.
slapd[21335]: [66B blob data]
With slapschema:
UNKNOWN attributeDescription "ATTRIBUTE1 " inserted.
UNKNOWN attributeDescription "ATTRIBUTE2" inserted.
UNKNOWN attributeDescription "ATTRIBUTE3
With slapcat I can't find anything that's matching these names.
When I grep in the mdb file grep says the binary file is matching.
However when I ldapsearch for the attribute I can't find it.
Neither with slapcat.
Note that I replaced the actual attribute names in the posted output.
So I think I might have some data in that mdb that's not linked to anything
anymore.
So my question is: how can I clean this up? And/or what did/went wrong?
Thanks in advance for your help.
7 years
Directory structure searching
by Gurjot Kaur
Hi,
I am encountered a problem regarding the checking of the directory structure during ldapsearch request.
I did slapadd on my LDAP server (OpenLDAP 2.4.44 with MDB backend) for few entries and found the below error as my top entry "ou=people,dc=my-domain,dc=com" was missing from the DB.
###############################################################################
/usr/local/sbin/slapadd -v -c -w -f /usr/local/etc/openldap/slapd.conf -l 2_tmp.ldif
578c3c23 mdb_monitor_db_open: monitoring disabled; configure monitor database to enable
added: "ou=Test1,ou=people,dc=my-domain,dc=com" (00000005)
added: "ou=Test2,ou=people,dc=my-domain,dc=com" (00000006)
added: "ou=Test3,ou=people,dc=my-domain,dc=com" (00000007)
added: "ou=Test4,ou=people,dc=my-domain,dc=com" (00000008)
_#################### 100.00% eta none elapsed none fast!
modified: "(null)" (00000001)
Closing DB...Error, entries missing!
entry 4: ou=people,dc=my-domain,dc=com
###############################################################################
The above error is fine.
Do the above entries get added to the DB, though the parent node for these entries was not present?
Because when I search for the entry using the below ldapsearch command, this gives me the correct result.
###############################################################################
ldapsearch -x -D cn=Manager, dc=my-domain,dc=com -w secret -b ou=Test1,ou=people, dc=my-domain,dc=com -s sub "(&(objectclass=organizationalUnit)(ou=Test1*))" -H ldap://0.0.0.0:2016
# extended LDIF
#
# LDAPv3
# base <ou=Test1,ou=people,dc=my-domain,dc=com> with scope subtree
# filter: (&(objectclass=organizationalUnit)(ou=Test1*))
# requesting: ALL
#
# Test1, people, my-domain.com
dn: ou=Test1,ou=people, dc=my-domain,dc=com
ou: Test1
objectClass: organizationalUnit
companyName: Test1
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
###############################################################################
Does this means ldapsearch check just for the specific entry and not the complete directory structure?
Thanks in advance.
Regards,
Gurjot Kaur
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
7 years, 1 month
Missing user entries after restoring a backup ldif
by Matt Spaulding
Hello,
I restored an ldap database using the command:
slapadd -l /my/file.ldif
The restore went completely without error. But when I go to do an
ldapsearch I find that some of the users that should be in the database are
not there. I go back and edit my ldif backup file and search for the uids
of the users and confirm that they are in fact in the ldif file.
Why would something like this happen?
Best Regards,
Matt
7 years, 1 month
Re: openldap 2.4.44 + ITS 8432 patch still infinitely replicates
by Howard Chu
Paul B. Henson wrote:
>> From: Quanah Gibson-Mount
>> Sent: Friday, July 22, 2016 10:40 AM
>>
>> Also see ITS 8448.
>
> Ah, thanks much for the heads up on these additional issues. Perhaps it
> would be safest for me to stick with 2.4.41 until a 2.4.45 is officially
> released with fixes for both the replication loop and possible fallout from
> its fix :). We've been pretty lucky with 2.4.41, knock on bits, it's been
> very stable with no issues or problems that I've seen while we've been
> running it.
The bug noted in ITS#8460 is not present in 2.4 at all. Quanah is also running
experimental backports of features from 2.5 and forgets to mention that
sometimes. This particular issue is from 2.5 (and is now fixed in git).
Most likely it's the same issue as #8448. You can disregard both of these.
>> --On Thursday, July 21, 2016 5:47 PM -0700 Quanah Gibson-Mount
>> <quanah(a)zimbra.com> wrote:
>>
>>> I would note that I've opened up two new ITSes for problems that only
>>> occur on systems that have the ITS8432 fix. Still waiting on fixes for
>>> those, which is why I haven't pushed the fix into RE24 yet.
>>>
>>> ITSes 8460 and 8462.
>>>
>>> --Quanah
>>>
>>> --On Thursday, July 21, 2016 2:59 PM -0700 "Paul B. Henson"
>>> <henson(a)acm.org> wrote:
>>>
>>>>> From: Howard Chu
>>>>> Sent: Thursday, July 21, 2016 3:36 AM
>>>>>
>>>>> The fix for #8432 only prevents the redundant mod from being
>> processed
>>>>> on a particular node. If other nodes are still accepting the redundant
>>>>> op
>>>> then yes,
>>>>> it will continue to propagate. So yes, you need the patched code on
> all
>>>>> nodes.
>>>>
>>>> Okay, thanks for the clarification. I usually stage updates to avoid a
>>>> complete outage at any given time. It's interesting though that I had
>>>> never seen this problem running 2.4.41 until I introduced a 2.4.44
> system
>>>> into the mix, and then it went away once I reverted that system back to
>>>> 2.4.41. I wonder why that combination caused it to pop up suddenly.
> I'll
>>>> have to schedule a downtime window and update them all at once and
>> see
>>>> what happens.
>>>>
>>>> By any chance have you had the time to look at ITS 8444? The reporter
>>>> says he sees a similar circular replication issue when the memberOf
>>>> overlay is enabled, which we also use.
>>>>
>>>> Thanks much.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 2 months
Re: Antw: Intermediate certificates not being sent
by Howard Chu
Nat Sincheler wrote:
>
>
> On 7/27/2016 11:19 PM, Ulrich Windl wrote:
>>>>> Nat Sincheler <fai1107(a)macrotex.net> schrieb am 26.07.2016 um 17:20 in
>> Nachricht <991f77f9-fd05-eb9b-7f07-f350c4a7bc68(a)macrotex.net>:
>>
>>>
>>> On 7/25/2016 11:24 PM, Ulrich Windl wrote:
>>>>>>> Nat Sincheler <fai1107(a)macrotex.net> schrieb am 25.07.2016 um 19:06 in
>>>> Nachricht <c19c2a3a-3c90-5baa-43c7-800b050ea5b7(a)macrotex.net>:
>>>>> We have an OpenLDAP server that is listening on port 636 over ldaps.
>>>>> When I run
>>>>>
>>>>> openssl s_client -showcerts -connect ldap-server:636
>>>>>
>>>>> I only see the host certificate. The intermediate and root certificates
>>>>> do *not* come through.
>>>>
>>>> If I di that on one of outr servers, I get:
>>>> Root CA
>>>> Intermediate CA
>>>> Server Certificate
>>>>
>>>> ...
>>>> New, TLSv1/SSLv3, Cipher is AES256-SHA
>>>> Server public key is 2048 bit
>>>>
>>>>>
>>>>> For this server I have in the file slapd.d/cn=config.ldif the setting
>>>>>
>>>>> olcTLSCACertificatePath: /etc/ssl/certs
>>>>
>>>> Hi!
>>>>
>>>> Here it works with these settings:
>>>> olcTLSCACertificatePath: /etc/ssl/certs
>>>> olcTLSCertificateFile: /etc/ssl/servercerts/slapd.pem
>>>> olcTLSCertificateKeyFile: /etc/ssl/private/slapd.key
>>>>
>>>> Could it be a permissions problem? Did you try to check the certificate
>>> chain with openssl (preferrable as LDAP user)?
>>>
>>> When I run the openssl s_client command I get no errors, but I also get
>>> no intermediate or root certificates sent. I see this in the output: "No
>>> client certificate CA names sent".
>>
>> Hi!
>>
>> To me it looks like a problem with your certificates. Try to verify them
>> using openssl, like this:
>> openssl verify -CApath /etc/ssl/certs -verbose /etc/ssl/servercerts/slapd.pem
>> /etc/ssl/servercerts/slapd.pem: OK
>
> % grep -R Certificate *.ldif
>
> olcTLSCACertificatePath: /etc/ssl/certs
> olcTLSCertificateFile: /etc/ssl/certs/server.pem
> olcTLSCertificateKeyFile: /etc/ssl/private/server.key
>
> % directory2:/etc/ldap# openssl verify -CApath /etc/ssl/certs -verbose
> /etc/ssl/certs/server.pem
>
> /etc/ssl/certs/server.pem: OK
>
> So, the openssl command line can find the certificate chain. Why can't openldap?
If your OpenLDAP build is not behaving the same as your OpenSSL build, then
most likely your OpenLDAP was not built with OpenSSL. Otherwise, their
behavior would match.
You never provided essential information such as OS platform and OpenLDAP
version, so nobody can give you definitive answers.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 2 months
Intermediate certificates not being sent
by Nat Sincheler
We have an OpenLDAP server that is listening on port 636 over ldaps.
When I run
openssl s_client -showcerts -connect ldap-server:636
I only see the host certificate. The intermediate and root certificates
do *not* come through.
For this server I have in the file slapd.d/cn=config.ldif the setting
olcTLSCACertificatePath: /etc/ssl/certs
I checked and all the intermediate and root certificates are in
/etc/ssl/certs soft-linked via the usual OpenSSL rehash hash, e.g.,
lrwxrwxrwx 1 root root 42 Jul 14 19:03 b4261fc2.0 ->
/etc/ssl/certs/incommon-usertrust-2024.pem
Any idea why the intermediate and root certificates do not get sent to
the LDAPS client? Is there something in the LDAP log that might give me
a clue as to what is going on?
7 years, 2 months
Multimaster syncrepl configuration
by Gurjot Kaur
Hello,
I have a doubt in setting up multimaster syncrepl configuration.
I just added syncrepl information for the "dn: olcDatabase={0}config,cn=config" and overlays for "dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config" in both the Master 1 and Master 2 servers.
But I didn't add any syncrepl for "dn: olcDatabase={1}mdb,cn=config" for any server. While adding I got this error:
modifying entry "olcDatabase={1}mdb,cn=config"
ldap_modify: Server is unwilling to perform (53)
additional info: shadow context; no update referral
Nevertheless, what I am unable to understand is that my data is replicating in both the servers correctly. Is there no difference between adding syncrepl for config database or mdb database.
Or adding syncrepl to config database is applicable for all the databases?
Thanks,
Gurjot Kaur
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
7 years, 2 months
sizelimit
by Maily Peng
Hi all,
I can not apply a limits directive to my slapd.conf. I need a user
(cn=replicator,ou=AppUsers,dc=company,dc=net) to have read access to all
entries of a database.
The global sizelimits ( 1000) seems to override any other database
directive. Each ldapsearch returns a " 4 Size limit exceeded".
openldap version : 2.4.42
here is a sample of my slapd.conf
...
# Define global ACLs to disable default read access.
sizelimit 1000
timelimit 5
tool-threads 8
pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args
#######################################################################
# database definitions
#######################################################################
#########################################
# Directories DATABASE
#########################################
database mdb
suffix "ou=Directories,dc=company,dc=net"
subordinate
checkpoint 1024 5
dbnosync
maxsize 10737418240
envflags writemap
rootdn "cn=admin,dc=company,dc=net"
# Mode 700 recommended.
directory /var/lib/openldap/ldap
# acl
authz-regexp uid=([^,]*),cn=digest-md5,cn=auth
ldap:///ou=company,dc=company,dc=net??sub?(&(objectclass=psnDirectoryContact)(cli=sipdefault:$1))
access to *
by dn.exact="cn=replicator,ou=AppUsers,dc=company,dc=net" write
by * break
...........
access to dn.sub="ou=AppUsers,dc=company,dc=net" attrs=userpassword
by anonymous auth
by * none
# Indices to maintain
index cn,dc,sn,uid,mail,telephoneNumber pres,eq,sub
index arecord,description eq
index
objectClass,macAddress,custID,locationID,zoneGroupPrefix,entryUUID,entryCSN
pres,eq
# Sync Repl
overlay syncprov
# all standard entries in the accesslog that were successful
syncrepl rid=0
provider=ldap://
bindmethod=simple
binddn="cn=user,ou=login,cn=system"
credentials=secret
searchbase="ou=Directories,dc=company,dc=net"
logbase="cn=accesslog_directories"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=on
type=refreshAndPersist
retry="60 +"
syncdata=accesslog
#limits
limits dn.exact="cn=replicator,ou=AppUsers,dc=company,dc=net"
size=unlimited time=unlimited
....
thanks in advance.
7 years, 2 months
