Re: slapd-meta and tls_reqcert=allow
by Manuel Gaupp
Jim Vanes <jimvanes(a)yahoo.ca> wrote:
> I'm using OpenLDAP 2.4.23-26 from Centos 6. I seem to be hitting a configuration issue regarding slapd-meta and SSL/TLS.
>
> Here is my meta config:
>
> database meta
> suffix "dc=virtual,dc=local"
> rootdn "cn=root,dc=virtual,dc=local"
> rootpw password
>
> # Local
> uri ldap://localhost/dc=ds1,dc=virtual,dc=local
> suffixmassage "dc=ds1,dc=virtual,dc=local" "dc=lab,dc=local"
> idassert-bind bindmethod=simple binddn="cn=root,dc=lab,dc=local" credentials=password
>
> #Remote AD server
> uri ldap://10.33.63.125:389/dc=ad1,dc=virtual,dc=local
> tls start
> suffixmassage "dc=ad1,dc=virtual,dc=local" "dc=mslab,dc=local"
> idassert-bind bindmethod=simple binddn="CN=Sync,CN=Users,DC=lab,DC=local" credentials="Password1" starttls="yes" tls_reqcert="allow"
>
> It seems as though tls_reqcert="allow" is ignored for the remote AD server. If set that variable in the ldap.conf everything works fine. But shouldn't the above function as an override to the default of 'demand'? The behaviour is the same when I change the above to use SSL instead.
I think you're running into an issue that I reported in September 2010.
See http://www.openldap.org/lists/openldap-technical/201009/msg00073.html and http://www.openldap.org/its/index.cgi?findid=6642
According to the Release Change Log, this issue should have been fixed in release 2.4.24. So you should definitely update to a more recent release.
Best regards,
Manuel
12 years, 5 months
Re: TLS negation failure
by espeake＠oreillyauto.com
From: Aaron Richton <richton(a)nbcs.rutgers.edu>
To: espeake(a)oreillyauto.com
Cc: openldap-technical(a)openldap.org
Date: 09/19/2013 10:13 AM
Subject: Re: TLS negation failure
On Thu, 19 Sep 2013, espeake(a)oreillyauto.com wrote:
> We have a client server that is failing on the ssl handshake using TLS.
> The following is from the server log when the client is trying to
connect.
>
> Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 ACCEPT from
> IP=172.17.1.10:55469 (IP=0.0.0.0:389)
> Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 EXT
> oid=1.3.6.1.4.1.1466.20037
> Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 STARTTLS
> Sep 19 09:12:49 tntest-ldap-3 slapd[18796]: conn=3534 op=0 RESULT oid=
> err=0 text=
> Sep 19 09:12:50 tntest-ldap-3 slapd[18796]: conn=3534 fd=28 closed (TLS
> negotiation failure)
>
The above information is from a connection when a server is running an
application that is trying to access the LDAP server. And this is what the
logging is doing on the server. I tried to change the logging level to
debug but my changes aren't going through. I tried deleting the
olcLogLevel and and then adding it back and tried a replace with no luck.
I also tried adding olcTLSCACertificatePath but none of my ldapmodifies
seem to be working. I am on version 2.4.31 with a 3 node n-way multimaster
setup.
Try something like
https://groups.google.com/forum/#!topic/mailing.openssl.users/1OOwXp45iIw
if you'd like. Or OpenLDAP Software such as ldapsearch(1).
The above allowed me to connect and the connection was closed as soon as it
opened.
Thanks,
Eric
This communication and any attachments are confidential, protected by Communications Privacy Act 18 USCS � 2510, solely for the use of the intended recipient, and may contain legally privileged material. If you are not the intended recipient, please return or destroy it immediately. Thank you.
11 years, 9 months
Re: SLAPD 2.4.9 and OpenSSL 0.9.8g on Ubuntu 8.04 server - client certificate not read
by Howard Chu
Hauke Coltzau wrote:
> Hello everybody,
>
> I'm just trying to set up a LDAPS server using my own
> certification authority, but the ldap server does not
> accept/understand my client certificate. Instead, the server
> sais:
>
> TLS: can't accept: The peer did not send any certificate..
> Here are the details:
>
> Client:
> =======
>
> # ldapsearch -x -LLL -ZZ -d 1
>
> ldap_create
> ldap_extended_operation_s
> ldap_extended_operation
> ldap_send_initial_request
> ldap_new_connection 1 1 0
> ldap_int_open_connection
> ldap_connect_to_host: TCP<serverip>:636
> ldap_new_socket: 3
> ldap_prepare_socket: 3
> ldap_connect_to_host: Trying<serverip>:636
> ldap_pvt_connect: fd: 3 tm: -1 async: 0
> TLS: can't connect: A TLS packet with unexpected length was received..
> ldap_err2string
> ldap_start_tls: Can't contact LDAP server (-1)
>
>
> Server:
> ========
>
> # slapd -VV
> @(#) $OpenLDAP: slapd 2.4.9 (Aug 1 2008 01:09:46) $
> buildd@king:/build/buildd/openldap2.3-2.4.9/debian/build/servers/slapd
>
>
> # slapd -h "ldaps://<ip>/" -u openldap -g openldap -d 127
You cannot use StartTLS (ldapsearch -Z) with an ldaps:// server, it's redundant.
> ldap.conf (partially)
> ---------------------
>
> uri ldaps://132.176.4.6/
> ssl yes
> tls_cacertfile /usr/lib/ssl/cacartes/<ca>.chain.crt
> tls_ciphers TLSv1
The above 3 keywords are not valid for ldap.conf. Read the ldap.conf(5) manpage.
> tls_cert /usr/lib/ssl/certs/<clientfqdn>.cert.pem
> tls_key /usr/lib/ssl/private/<clientfqdn>.key.pem
> What did I do wrong?
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
16 years, 10 months
slapadd hanging initializing mdb backend
by Mark
When I try to slapadd initial data into an empty mdb backend, the slapadd
hangs:
$ /tmp/openldap-2.4.31/sbin/slapadd -w -S 1 -c -F
/tmp/openldap-2.4.31/etc/slapd.d -b dc=example,dc=com -l
/tmp/openldap-2.4.31/etc/initdb.ldif
_#################### 100.00% eta none elapsed none fast!
(does not return to a shell prompt. I have to INT it.)
I add '-d -1' to get some debugging output and I get this after removing
the data.mdb and lock.mdb created above:
$ /tmp/openldap-2.4.31/sbin/slapadd -d -1 -w -S 1 -c -F
/tmp/openldap-2.4.31/etc/slapd.d -b dc=example,dc=com -l
/tmp/openldap-2.4.31/etc/initdb.ldif
(lines removed for brevity but can be submitted if need be)
4f9ea9c0 => str2entry: "dn: ou=Users,dc=example,dc=com
objectClass: organizationalUnit
ou: Users
"
4f9ea9c0 >>> dnPrettyNormal: <ou=Users,dc=example,dc=com>
4f9ea9c0 <<< dnPrettyNormal: <ou=Users,dc=example,dc=com>,
<ou=users,dc=example,dc=com>
4f9ea9c0 <= str2entry(ou=Users,dc=example,dc=com) -> 0x6afeba8
4f9ea9c0 oc_check_required entry (ou=Users,dc=example,dc=com), objectClass
"organizationalUnit"
4f9ea9c0 oc_check_allowed type "objectClass"
4f9ea9c0 oc_check_allowed type "ou"
4f9ea9c0 oc_check_allowed type "structuralObjectClass"
4f9ea9c0 => mdb_tool_entry_put( -1, "ou=Users,dc=example,dc=com" )
4f9ea9c0 => mdb_dn2id("ou=users,dc=example,dc=com")
4f9ea9c0 <= mdb_dn2id: get failed: MDB_NOTFOUND: No matching key/data pair
found (-30798)
4f9ea9c0 => mdb_dn2id_add 0x6: "ou=users,dc=example,dc=com"
4f9ea9c0 <= mdb_dn2id_add 0x6: 0
4f9ea9c0 => index_entry_add( 6, "ou=Users,dc=example,dc=com" )
4f9ea9c0 mdb_idl_insert_keys: 6 [9bee355f]
4f9ea9c0 mdb_idl_insert_keys: 6 [ef1184ca]
4f9ea9c0 mdb_idl_insert_keys: 6
4f9ea9c0 <= index_entry_add( 6, "ou=Users,dc=example,dc=com" ) success
4f9ea9c0 => mdb_entry_encode(0x00000006): ou=Users,dc=example,dc=com
4f9ea9c0 <= mdb_entry_encode(0x00000006): ou=Users,dc=example,dc=com
4f9ea9c0 => mdb_dn2id("dc=example,dc=com")
4f9ea9c0 <= mdb_dn2id: got id=0x1
4f9ea9c0 => mdb_entry_decode:
4f9ea9c0 <= mdb_entry_decode
4f9ea9c0 => mdb_tool_entry_modify( 1, "(null)" )
(it's hung)
Here is the /tmp/openldap-2.4.31/etc/initdb.ldif:
### BEGIN INITDB.LDIF
dn: dc=example,dc=com
objectClass: organization
objectClass: dcObject
dc: example
o: example.com
dn: cn=manager,dc=example,dc=com
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: manager
userPassword: {SSHA}asif
dn: cn=replicator,dc=example,dc=com
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: replicator
userPassword: {SSHA}asif
dn: ou=Groups,dc=example,dc=com
objectClass: organizationalUnit
ou: Groups
dn: cn=LDAP Admins,ou=Groups,dc=example,dc=com
objectClass: top
objectClass: groupOfUniqueNames
cn: LDAP Admins
uniqueMember: cn=manager,dc=example,dc=com
dn: ou=Users,dc=example,dc=com
objectClass: organizationalUnit
ou: Users
### END INITDB.LDIF
I used the following slaptest commands to create the initial slapd.d/
directory from a slapd.conf file:
$ /tmp/openldap-2.4.31/sbin/slaptest -u -f
/tmp/openldap-2.4.31/etc/slapd.conf -F /tmp/openldap-2.4.31/etc/slapd.d
config file testing succeeded
$ /tmp/openldap-2.4.31/sbin/slaptest -f /tmp/openldap-2.4.31/etc/slapd.conf
-F /tmp/openldap-2.4.31/etc/slapd.d
4f9eab15 mdb_db_open: database "dc=example,dc=com" cannot be opened, err 2.
Restore from backup!
4f9eab15 backend_startup_one (type=mdb, suffix="dc=example,dc=com"):
bi_db_open failed! (2)
slap_startup failed (test would succeed using the -u switch)
Here is the /tmp/openldap-2.4.31/etc/slapd.conf:
### BEGIN SLAPD.CONF
include /tmp/openldap-2.4.31/etc/schema/core.schema
include /tmp/openldap-2.4.31/etc/schema/cosine.schema
include /tmp/openldap-2.4.31/etc/schema/nis.schema
include /tmp/openldap-2.4.31/etc/schema/inetorgperson.schema
argsfile /tmp/openldap-2.4.31/var/run/slapd.args
pidfile /tmp/openldap-2.4.31/var/run/slapd.pid
threads 8
tool-threads 2
idletimeout 0
writetimeout 0
reverse-lookup off
loglevel stats
serverid 1 ldap://boardwalk:2389
modulepath /tmp/openldap-2.4.31/libexec
moduleload back_monitor.la
moduleload back_mdb.la
moduleload syncprov.la
password-hash {SSHA}
sizelimit unlimited
database config
rootdn "cn=manager,dc=example,dc=com"
access to *
by group="cn=LDAP Admins,ou=Groups,dc=example,dc=com" write
by users read
by * none
database monitor
rootdn "cn=manager,dc=example,dc=com"
access to *
by users read
by * none
database mdb
suffix "dc=example,dc=com"
rootdn "cn=manager,dc=example,dc=com"
directory /tmp/openldap-2.4.31/var/data
index objectClass eq
index entryCSN eq
index entryUUID eq
syncrepl rid=001
provider=ldap://boardwalk:2389
type=refreshAndPersist
retry="15 +"
bindmethod=simple
binddn="cn=replicator,dc=example,dc=com"
credentials="asif"
searchbase="dc=example,dc=com"
starttls=no
schemachecking=off
syncrepl rid=002
provider=ldap://chance:2389
type=refreshAndPersist
retry="15 +"
bindmethod=simple
binddn="cn=replicator,dc=example,dc=com"
credentials="asif"
searchbase="dc=example,dc=com"
starttls=no
schemachecking=off
syncrepl rid=003
provider=ldap://freeparking:2389
type=refreshAndPersist
retry="15 +"
bindmethod=simple
binddn="cn=replicator,dc=example,dc=com"
credentials="asif"
searchbase="dc=example,dc=com"
starttls=no
schemachecking=off
mirrormode TRUE
overlay syncprov
syncprov-checkpoint 50 10
syncprov-sessionlog 100
access to attrs=userPassword
by anonymous auth
by self write
by dn.exact="cn=replicator,dc=example,dc=com" read
by * none
access to *
by group="cn=LDAP Admins,ou=Groups,dc=example,dc=com" write
by dn.exact="cn=replicator,dc=example,dc=com" read
by users read
by * none
limits dn.exact="cn=replicator,dc=example,dc=com"
time.soft=unlimited time.hard=unlimited
size.soft=unlimited size.hard=unlimited
### END SLAPD.CONF
I compiled from the following source:
OpenLDAP 2.4.31
OpenSSL 1.0.1b
Cyrus-SASL 2.1.25
I am running in the following environment:
Dell Poweredge 2950; dual-core Intel(R) Xeon(R) CPU 5110 @ 1.60GHz; 8GB RAM
Scientific Linux 5.7
Am I doing something wrong (besides the ACLs for cn=LDAP
Admins,ou=Groups,dc=example,dc=com. I'm still struggling there) ?
Thank you,
Mark
13 years, 2 months
Re: Ubuntu Server 12.04: StartTLS
by Admus
On 11/05/2012 07:41 PM, Khosrow Ebrahimpour wrote:
> Hi,
>
> On November 4, 2012 11:13:27 PM admus wrote:
>> Hello,
>> I'm following
>> https://help.ubuntu.com/12.04/serverguide/openldap-server.html#openldap-tls
>> -replication how to: LDAP serwer starts correctly but when I tries to test
>> StartTLS:
>> ldapsearch -x -H ldap:/// -ZZ -d -1
>> I gets the following error:
>> TLS: peer cert untrusted or revoked (0x42)
>> TLS: can't connect: (unknown error code).
>> ldap_err2string
>> ldap_start_tls: Connect error (-11)
>> additional info: (unknown error code)
>> Any idea?
> Have you verified your certificate? What is the output of :
>
> openssl s_client -connect ldap1.example.com:636 -showcerts
>
> or on the server itself you can dump the cert info
>
> cat ldap-cert.pem | openssl x509 -text
>
>
The certificate info is as follow:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 1352064827 (0x5096df3b)
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=ldap1.example.com
Validity
Not Before: Nov 4 21:33:47 2012 GMT
Not After : Nov 2 21:33:47 2022 GMT
Subject: O=Example Com, CN=ldap1.example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2432 bit)
Modulus:
00:e7:06:b9:1d:19:c7:67:de:93:8e:db:e8:a3:1f:
e2:c7:39:62:20:bb:7d:5b:d3:5a:78:5c:7c:89:5d:
27:00:a8:71:03:73:b0:9a:a9:fe:31:a7:22:f0:ac:
d5:9f:f4:3b:a4:9a:08:95:ba:f7:cf:7d:6e:a6:86:
2d:39:7e:c1:06:aa:27:07:43:78:77:6e:b0:20:a2:
6f:80:4a:cf:39:8b:e3:91:92:c3:9c:ca:84:2a:45:
4f:35:48:87:bd:02:8d:48:04:e0:9b:7a:9d:a8:bd:
7b:f8:e3:6d:64:88:25:ab:2f:66:d6:4a:0e:5c:3b:
47:a9:21:27:5d:0c:f6:47:ac:d1:e0:55:0b:41:27:
a9:9b:b2:97:4e:07:5c:ef:5f:ad:0a:9a:ad:f5:ed:
f0:0f:16:56:2e:54:8e:e9:64:65:47:67:26:69:65:
31:9d:18:74:b7:67:af:72:1c:9a:bb:ad:89:3a:d0:
bb:15:13:88:13:59:e0:cb:61:05:9a:da:a7:d7:88:
15:6b:f2:78:52:be:da:a5:79:a7:bd:cc:94:70:17:
47:58:f3:48:2c:0f:47:7f:bb:ed:05:9c:32:26:1c:
79:f2:4f:b8:2e:82:e4:5c:7f:13:31:92:4a:7e:67:
76:7a:8c:5a:bb:2d:13:31:34:05:2e:19:88:70:dc:
34:db:14:38:18:71:fb:8f:c1:2a:9d:56:75:80:54:
ff:34:e6:b3:ad:9c:96:de:f9:c7:39:df:f1:83:63:
a6:af:47:8b:a8:d2:6e:92:30:e9:94:14:27:9c:18:
0a:08:6d:c7:4d
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints: critical
CA:FALSE
X509v3 Extended Key Usage:
TLS Web Server Authentication
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Subject Key Identifier:
50:88:10:B9:46:9D:61:37:B9:24:2E:A0:33:6A:15:34:23:38:1B:1E
X509v3 Authority Key Identifier:
keyid:8E:98:97:7B:2E:DC:62:92:44:14:55:74:EF:31:E5:BC:60:3F:57:70
12 years, 7 months
consumer state is newer than provider (was "can I replicate several branches to the same slave from one master?")
by Zeus Panchenko
greetings,
alas, but I still face the issue ... :-\
---[ replica log quotation start ]-------------------------------------------
...
Jul 27 12:29:46 ABC slapd[15466]: do_syncrep2: rid=000 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform
Jul 27 12:29:46 ABC slapd[15466]: do_syncrep2: rid=000 (53) Server is unwilling to perform
Jul 27 12:29:46 ABC slapd[15466]: do_syncrepl: rid=000 rc -2 retrying
...
---[ replica log quotation end ]-------------------------------------------
---[ master log quotation start ]-------------------------------------------
...
Jul 27 12:29:46 master slapd[45467]: conn=2610 op=1 BIND dn="uid=replABC,ou=repl,ou=system,dc=example" method=128
Jul 27 12:29:46 master slapd[45467]: conn=2610 op=1 BIND dn="uid=replABC,ou=repl,ou=system,dc=example" mech=SIMPLE ssf=0
Jul 27 12:29:46 master slapd[45467]: conn=2610 op=1 RESULT tag=97 err=0 text=
Jul 27 12:29:46 master slapd[45467]: conn=2611 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Jul 27 12:29:46 master slapd[45467]: conn=2611 op=0 STARTTLS
Jul 27 12:29:46 master slapd[45467]: conn=2611 op=0 RESULT oid= err=0 text=
Jul 27 12:29:46 master slapd[45467]: conn=2610 op=2 SRCH base="cn=example-accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))"
Jul 27 12:29:46 master slapd[45467]: conn=2610 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN
Jul 27 12:29:46 master slapd[45467]: conn=2610 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider!
Jul 27 12:29:46 master slapd[45467]: conn=2610 op=3 UNBIND
...
---[ master log quotation end ]-------------------------------------------
please advise
Quanah Gibson-Mount <quanah(a)symas.com> wrote:
> > slapd[38004]: conn=30116 op=3 SEARCH RESULT tag=101 err=53 nentries=0
> > text=consumer state is newer than provider!
>
> It sounds like your replica was not configured correctly initially and
> self-generated its own CSN that is newer than the one on the provider.
what in replica configuration can lead to that?
I configured replica just as it is described in the documentation
"18.3.2.1. Delta-syncrepl Provider configuration"
> It would be interesting to make a modification on the provider so that
> its CSN is updated (and thus has one newer than on the consumer).
doesn't help ...
helps only deleting consumer DB (in some cases for a several times)
DB replicates but after some time it looses sync again ...
can master configuration cause that as well?
here is (just to remind) how master/replica are configured ...
---[ replica slapd.conf quotation start ]-------------------------------------------
...
syncrepl rid=0
provider=ldap://master.example:389
starttls=critical
searchbase="dc=example"
bindmethod=simple
binddn="uid=replABC,ou=repl,dc=example"
credentials="***"
tls_cacert=/usr/local/etc/openldap/ssl/ca.crt
tls_cert=/usr/local/etc/openldap/ssl/ABC.crt
tls_key=/usr/local/etc/openldap/ssl/ABC.key
tls_reqcert=try
type=refreshAndPersist
retry="60 +"
logbase="cn=example-accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
...
---[ replica slapd.conf quotation end ]-------------------------------------------
---[ master configuration quotation start ]-------------------------------------------
...
access to dn.subtree="cn=example-accesslog"
by dn.onelevel="ou=repl,ou=system,dc=example" read
by * break
###--- ABC
access to dn.regex="^uid=(.*)@foo.bar,authorizedService=(mail|xmpp)@foo.bar,uid=(.*),ou=People,dc=example$"
attrs=entry,entryCSN,entryUUID,objectClass,cn,...
by dn.exact="uid=replABC,ou=repl,ou=system,dc=example" read
by * break
access to dn.regex="ou=ABC,ou=Sendmail,dc=example|ou=ABC,ou=DHCP,dc=example"
by dn.exact="uid=replABC,ou=repl,ou=system,dc=example" read
by * stop
...
---[ master configuration quotation end ]-------------------------------------------
--
Zeus V. Panchenko jid:zeus@im.ibs.dn.ua
IT Dpt., I.B.S. LLC GMT+2 (EET)
7 years, 11 months
Error, ldap_start_tls failed (-11)
by arun.sasi1＠wipro.com
Hello Guillaume Rousse/team,
I am getting below error from the master server when I give 636 port number in my HDB config file
Sep 16 06:41:59 gb0135embldap01 slapd[4672]: conn=349739 fd=39 ACCEPT from IP=163.183.2.145:43965 (IP=0.0.0.0:636)
Sep 16 06:41:59 gb0135embldap01 slapd[4672]: conn=349739 fd=39 closed (TLS negotiation failure)
and When I gibe 389 in my HDB config, I get below message from master server.
Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349046 fd=38 ACCEPT from IP=163.183.2.145:49242 (IP=0.0.0.0:389)
Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349046 op=0 EXT oid=1.3.6.1.4.1.1466.20037
Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349046 op=0 STARTTLS
Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349046 op=0 RESULT oid= err=0 text=
Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349040 op=6 SRCH base="ou=Groups,dc=emb,dc=slb,dc=com" scope=2 deref=0 filter="(&(objectClass=sambaGroupMapping)(gidNumber=443298))"
Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349040 op=6 SRCH attr=gidNumber sambaSID sambaGroupType sambaSIDList description displayName cn objectClass
Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349040 op=6 SEARCH RESULT tag=101 err=0 nentries=0 text=
Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349044 op=2 UNBIND
Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349044 fd=19 closed
Sep 16 06:31:51 gb0135embldap01 slapd[4672]: conn=349037 fd=60 closed (connection lost)
but there is no much data replication happened I get below message from slave server...
for 636
Sep 16 10:47:26 ae0043app05 slapd[10982]: slap_client_connect: URI=ldap://gb0135embldap01.emb.slb.com:636 Error, ldap_start_tls failed (-1)
Sep 16 10:47:26 ae0043app05 slapd[10982]: do_syncrepl: rid=365 rc -1 retrying
for 389
Sep 16 10:31:42 ae0043app05 slapd[10282]: slap_client_connect: URI=ldap://gb0135embldap01.emb.slb.com:389 Error, ldap_start_tls failed (-11)
I dont know how to check TLS manually... could you please help me...
Thanks & Regards,
Arun Sasi Venmalassery
-------------------------------------------------------------------------------------------------------------------------------------
Sr. Engineer - Server Management (UNIX),
Wipro Ltd (Dubai) |Mob: +971 566489491 | E: arun.sasi1(a)wipro.com
________________________________________
From: openldap-technical-bounces(a)OpenLDAP.org [openldap-technical-bounces(a)OpenLDAP.org] on behalf of openldap-technical-request(a)OpenLDAP.org [openldap-technical-request(a)OpenLDAP.org]
Sent: Friday, September 14, 2012 5:30 PM
To: openldap-technical(a)openldap.org
Subject: openldap-technical Digest, Vol 58, Issue 12
------------------------------
Message: 3
Date: Thu, 13 Sep 2012 14:38:20 +0200
From: Guillaume Rousse <guillomovitch(a)gmail.com>
To: openldap-technical(a)openldap.org
Subject: Re: Error, ldap_start_tls failed (-11)
Message-ID: <5051D3BC.3020207(a)gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Le 13/09/2012 14:16, arun.sasi1(a)wipro.com a ?crit :
> Hello Team,
>
> I have an issue with OpenLDAP TLS based replication
>
> Getting below error
> slap_client_connect: URI=ldap://gb0135embldap01.emb.slb.com Error,
> ldap_start_tls failed (-11)
> Sep 13 16:13:34 ae0043app05 slapd[2582]: do_syncrepl: rid=365 rc -11
> retrying
>
> I have openLDAP in Ubuntu 9.04 version 2.4.19 then I thought to updgrade
> it and first I upgraded on my consumer openldap server which I migrated
> to Ubuntu 12.04 and version 2.4.28.
>
> I have created the certificate for my consumer from existing server. but
> when I go for TLS based replication, the database is not syncing and it
> is synching when remove starttls=no
What does the master log say, and did you try a manual connection with
the same credentials from the slave to the master, using TLS ?
--
BOFH excuse #166:
/pub/lunch
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
12 years, 9 months
Re: 2 way SSL configuration in OpenLDAP 2.4
by Philip Guenther
On Wed, 11 Dec 2013, vidya bharadwaj wrote:
> have to implement a 2 way SSL mechanism on a LDAP connector in our
> product. In order to test the implementation, we have chosen openLDAP2.4
> as the data source.
You should *first* get SSL working without client certs. Once you have
that working, *then* add client certs to the config.
Next: is your intent to do
a) "upgrade from cleartext to SSL" (i.e., make an ldap:// connection and
then use the StartTLS extension to negotiate TLS),
OR
b) "SSL on connect" (i.e., make an ldaps:// connection where SSL is
negotiated immediately after connecting)
?
I ask, because your config bits mix the two, which won't work: port 636 is
reserved for ldaps (choice (b)), but you used the -Z option to ldapsearch
(choice (a)). You must pick one.
If you want to do (a), then you should be using ldap:// on port 389 with
the -Z (or -ZZ) option.
If you want to do (b), then you should be using ldaps:// on port 636 and
*not* use the -Z option.
...
> 6. Following changes
> were made in sldap.conf
> TLSCipherSuite MEDIUM:+SSLv2:+SSLv3:RSA
So you want to be completely insecure? Why bother enabling SSL if you're
going to permit SSLv2 and even ciphers that DON'T ENCRYPT.
$ openssl ciphers -v MEDIUM:+SSLv2:+SSLv3:RSA | grep Enc=None
NULL-SHA SSLv3 Kx=RSA Au=RSA Enc=None Mac=SHA1
NULL-MD5 SSLv3 Kx=RSA Au=RSA Enc=None Mac=MD5
$
You should yell at the person or documentation that suggested using that
line and stop trusting them for anything involving security.
...
> On the client side:
> 1. Following changes were made in ldap.conf
> HOST spsdel192
> PORT 636
Do not use the HOST and PORT options. Use the URI option, as that lets
you specify the schema (ldap vs ldaps) in the same line. Next, in order
for the server certificate to be validated, the hostname you connect to
(in the URI) must match what's in the certificate, which should be an
FQDN. I.e., something like:
URI ldaps://spsdel192.YOUR.DOMAIN.GOES.HERE:636/
Philip Guenther
11 years, 6 months
Re: Dovecot can't connect to openldap over starttls
by info＠gwarband.de
Am 2017-03-19 01:09, schrieb Dan White:
> Reformatted:
>
>>>>>> On 03/17/2017 04:27 PM, info(a)gwarband.de wrote:
>>>>>>> Hello guys,
>>>>>>>
>>>>>>> actually I'm trying to configure dovecot to access openldap for
>>>>>>> passwordcheck.
>
>>>>>>> All datalinks:
>>>>>>>
>>>>>>> https://gwarband.de/openldap/dovecot.log
>
> Mar 11 11:18:26 s1 dovecot: auth: Debug: Read auth token secret from
> /var/run/dovecot/auth-token-secret.dat
> Mar 11 11:18:26 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s()
> failed: Connect error
> Mar 11 11:18:26 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s()
> failed: Connect error
> Mar 11 11:18:26 s1 dovecot: auth: Debug: auth client connected
> (pid=27177)
> Mar 11 11:18:33 s1 dovecot: imap-login: Disconnected (no auth
> attempts in 7 secs): user=<>, rip=149.172.171.148, lip=188.68.37.50,
> session=<gcDtzHFKbwCVrKuU>
>
>>>>>>> https://gwarband.de/openldap/dovecot-ldap.conf
>
> uris = ldap://ldap.gwarband.de
> dn = cn=T000000002,ou=tech,dc=gwarband,dc=de
> dnpass = secret
> tls = yes
> tls_ca_cert_file = /etc/ssl/certs/LetsEncrypt.pem
> auth_bind = yes
> ldap_version = 3
> base = dc=gwarband,dc=de
> scope = subtree
> user_attrs =
> mail=maildir:/var/vmail/%{ldap:mailbox},uid=vmail,gid=vmail
> user_filter =
> (&(email=%u)(memberOf=cn=mailbox,ou=application,ou=groups,dc=gwarband,dc=de))
> pass_attrs = email=user
> pass_filter =
> (&(email=%u)(memberOf=cn=mailbox,ou=application,ou=groups,dc=gwarband,dc=de))
>
>>>>>>> https://gwarband.de/openldap/openldap.log
>
> Mar 11 10:48:38 s1 slapd[26962]: conn=1001 fd=14 ACCEPT from
> IP=188.68.37.50:60814 (IP=188.68.37.50:389)
>
> Mar 11 10:48:38 s1 slapd[26962]: conn=1001 op=0 STARTTLS
>
> Mar 11 10:48:38 s1 slapd[26962]: conn=1002 fd=15 ACCEPT from
> IP=188.68.37.50:60815 (IP=188.68.37.50:389)
>
> Mar 11 10:48:38 s1 slapd[26962]: conn=1002 op=0 STARTTLS
>
> Mar 11 10:49:42 s1 slapd[26962]: connection_get(14): got connid=1001
> Mar 11 10:49:42 s1 slapd[26962]: connection_read(14): checking for
> input on id=1001
> Mar 11 10:49:42 s1 slapd[26962]: connection_read(14): TLS accept
> failure error=-1 id=1001, closing
>
> Mar 11 10:49:42 s1 slapd[26962]: connection_get(15): got connid=1002
> Mar 11 10:49:42 s1 slapd[26962]: connection_read(15): checking for
> input on id=1002
> Mar 11 10:49:42 s1 slapd[26962]: connection_read(15): TLS accept
> failure error=-1 id=1002, closing
>
> Mar 11 10:49:42 s1 slapd[26962]: conn=1001 fd=14 closed (TLS
> negotiation failure)
> Mar 11 10:49:42 s1 slapd[26962]: conn=1002 fd=15 closed (TLS
> negotiation failure)
>
>>>>>>> https://gwarband.de/openldap/trace.dump
>
> It appears that the client is sending an unbind request after the
> server
> sends a successful starttls response.
>
>>>>>>> The bugreportinglink from openldap:
>>>>>>>
>>>>>>> http://www.openldap.org/its/index.cgi/Incoming?id=8615
>
>>>>> Am 2017-03-17 22:48, schrieb Tomas Habarta:
>>>>>> been running Dovecot 2.2.27 against OpenLDAP 2.4.40 normally over
>>>>>> the unix socket on the same machine, but tried over inet with
>>>>>> STARTTLS and it's working ok... I would suggest double-checking
>>>>>> key/certs setup on OpenLDAP side; for the test I have used LE
>>>>>> certs,
>>>>>> utilizing following cn=config attributes:
>>>>>>
>>>>>> olcTLSCertificateKeyFile contains private key
>>>>>> olcTLSCertificateFile contains certificate
>>>>>> olcTLSCACertificateFile contains both certs (DST Root CA X3
>>>>>> and Let's Encrypt Authority X3)
>>>>>>
>>>>>> and used the same CA file in Dovecot's tls_ca_cert_file
>>>>>> Is ldapsearch working ok (-ZZ) and only Dovecot has troubles or
>>>>>> ... ?
>
>>>> On 03/18/2017 09:41 AM, info(a)gwarband.de wrote:
>>>>> I have also installed LE certs. But nothing helps, I have
>>>>> double-checking all certs. ldapsearch with -ZZ works see:
>>>>>
>>>>> https://gwarband.de/openldap/ldapsearch.log
>
> ldapsearch -x -ZZ -D "cn=admin,dc=gwarband,dc=de" -W "cn=mailbox"
>
>>>>> I have also uploaded the TLSCACertificateFile, maybe I have a
>>>>> failure
>>>>> in the merge of the two fiels:
>>>>>
>>>>> https://gwarband.de/openldap/LetsEncrypt.crt
>>>>>
>>>>> And also I have uploaded my complete openldap configuration:
>>>>>
>>>>> https://gwarband.de/openldap/openldap.conf
>
> # Certificate
> TLSCACertificateFile /etc/ssl/certs/LetsEncrypt.pem
> TLSCertificateFile /etc/ssl/certs/gwarbandDE_LDAP.pem
> TLSCertificateKeyFile /etc/ssl/certs/gwarbandDE_LDAP.key
> TLSCipherSuite
> SECURE128:-ARCFOUR-128:-CAMELLIA-128-CBC:-3DES-CBC:-CAMELLIA-128-GCM
> TLSProtocolMin 3.1
> TLSVerifyClient never
>
>>>>> All other components can work and communicate with my openldap
>>>>> server. The components are postfix, openxchange, apache
>>>>> (phpldapadmin). My installated software is:
>>>>>
>>>>> Debian 8
>>>>> OpenLDAP 2.4.40
>>>>> Dovecot 2.2.13
>
>>> Am 2017-03-18 12:30, schrieb Tomas Habarta:
>>>> Well, if ldapsearch works, try to replicate its settings for
>>>> dovecot
>>>> client. It's not obvious what settings ldapsearch uses, have a
>>>> look
>>>> at default client settings in /etc/openldap/ldap.conf, there may be
>>>> something set a slightly different way. Also double check
>>>> permissions
>>>> for files used by dovecot, I mean mainly the file listed for
>>>> tls_ca_cert_file as dovecot may not have an access for reading...
>>>> I
>>>> cannot see anything downright bad, just posted CA cert (which is
>>>> ok,
>>>> tested) is *.crt and your config mentions *.pem but I consider it's
>>>> the same file. Finally, I would recommend to enable debug option
>>>> for
>>>> dovecot's client
>>>>
>>>> debug_level = -1 (which logs all available) in your
>>>> dovecot-ldap.conf
>>>>
>>>> to see what the library reports and work further on that. You can
>>>> compare with output from ldapsearch by adding -d-1 switch to it.
>>>> Hard
>>>> to tell more at the moment.
>
> What are the contents of /etc/ldap/ldap.conf?
>
>> On 03/18/2017 01:31 PM, info(a)gwarband.de wrote:
>>> I've replicate the settings from ldapsearch to dovecot but no
>>> success.
>>>
>>> To the certificate:
>>> Yes it's a *.crt file but I have linked the *.pem file to it and
>>> dovecot has read access to that file. I have enabled the debugging
>>> in
>>> dovecot and have uploaded the output:
>>> https://gwarband.de/openldap/dovecot-connect.log
>
> Mar 18 12:43:31 s1 dovecot: auth: Error: ldap_extended_operation_s
> Mar 18 12:43:31 s1 dovecot: auth: Error: ldap_extended_operation
>
> Mar 18 12:43:31 s1 dovecot: auth: Error: ldap_connect_to_host: TCP
> ldap.gwarband.de:389
>
> Mar 18 12:43:31 s1 dovecot: auth: Error: connect success
>
> Mar 18 12:43:31 s1 dovecot: auth: Error: LDAP: ldap_start_tls_s()
> failed: Connect error
>
>>>
>>> And the other site with ldapsearch:
>>> https://gwarband.de/openldap/ldapsearch-connect.log
>>> I'm pretty sure that there is a problem with the sslhandshaking
>>> between
>>> openldap and dovecot, but I can't find the source of the problem.
>>> One
>>> of the steps in the sslhandshaking is not success but in the
>>> debugging
>>> output I can't find any line with a hit to it.
>
> Am 2017-03-18 14:01, schrieb Tomas Habarta:
>> Increase log level on server side as well to see what the server
>> says...
>> You may remove anything in TLSCipherSuite for the purpose of testing
>> too. Hopefully anyone knowing OpenLDAP internals could help you
>> analyse
>> it more deeply.
>
> Your ldapsearch command should reference your ldap.conf config
> (ldap.conf(5)), and your dovecot-ldap.conf (assuming that it uses
> libldap)
> will also, but overwrite any settings using dovecot-ldap.conf. Compare
> any
> differences.
>
> Look for permissions problems. Run your ldapsearch command as the same
> user
> dovecot runs under.
The ldap.conf has no difference to the dovecot-ldap.conf.
See: https://gwarband.de/openldap/ldap.conf
The point "TLS_REQCERT" is in both confs "demand". I've changed it
after that.
The ldapsearch command works also under the user "dovecot"
See: https://gwarband.de/openldap/ldapsearch-dovecot.log
8 years, 3 months
Trouble with delta-syncrepl MMR: delta-sync lost sync on X, switching to REFRESH
by Patrick Lists
Hi,
I'm trying to create a 2-node delta-syncrepl Multi-Master setup with the
help of the Admin Guide, man pages and
tests/scripts/test063-delta-multimaster. I see the following problem
repeat on the "slave" master aka ldap02 which initially syncs with
ldap01 aka the "primary" master:
Oct 28 04:12:14 ldap02 slapd[9998]: do_syncrep2: rid=001 delta-sync lost
sync on (reqStart=20131028012214.000002Z,cn=accesslog), switching to REFRESH
I found ITS#7274 which mentions that some order should be changed
(syncprov before olcServerID) but I have no idea how that applies to my
setup. Being new to all this magic I came up empty. So here's my config.
Hopefully it isn't too messed up :) I would appreciate it if someone
could share a clue or 2 how to make this work. Comments on the config
not related to the problem are also most welcome.
OS: CentOS 6.4 x86_64 - clean install, all OpenLDAP dirs are empty
OpenLDAP version: RE24 git rev f9e417a from around 10/23/2013.
On the initial/"primary" master (note that the config is the same for
the "slave" up to the comment):
$ sudo /usr/local/sbin/slapadd -v -F $LDAP_ETC/slapd.d \
-l ./delta-syncrepl-MMR.ldif -n 0
$ cat ./delta-syncrepl-MMR.ldif
# global configuration settings
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/openldap-2.4/slapd-2.4.args
olcPidFile: /var/run/openldap-2.4/slapd-2.4.pid
olcLogFile: /var/log/openldap-2.4/slapd-2.4.log
olcLogLevel: conns stats stats2 sync
olcTLSCACertificateFile: /etc/pki/tls/certs/DS-CA.crt
olcTLSCertificateFile: /etc/pki/tls/certs/slapd.crt
olcTLSCertificateKeyFile: /etc/pki/tls/private/slapd.key.crt
olcTLSCipherSuite: TLSv1+HIGH:!SSLv2:!aNULL:!eNULL:!3DES:!RC4:@STRENGTH
olcTLSVerifyClient: demand
olcLocalSSF: 256
olcSecurity: ssf=256
olcPasswordCryptSaltFormat: $6$%s
olcPasswordHash: {CRYPT}
olcServerID: 1 ldap://ldap01
olcServerID: 2 ldap://ldap02
# load modules
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulePath: /usr/local/lib64/openldap-2.4
olcModuleload: {0}syncprov.la
olcModuleload: {1}accesslog.la
olcModuleLoad: {2}back_mdb.la
olcModuleLoad: {3}back_monitor.la
olcModuleLoad: {4}memberof.la
olcModuleLoad: {5}refint.la
olcModuleLoad: {6}ppolicy.la
# schema definitions
dn: cn=schema,cn=config
objectClass: olcSchemaConfig
cn: schema
# include the schemas
include: file:///etc/openldap-2.4/schema/core.ldif
include: file:///etc/openldap-2.4/schema/corba.ldif
include: file:///etc/openldap-2.4/schema/cosine.ldif
include: file:///etc/openldap-2.4/schema/duaconf.ldif
include: file:///etc/openldap-2.4/schema/dyngroup.ldif
include: file:///etc/openldap-2.4/schema/inetorgperson.ldif
include: file:///etc/openldap-2.4/schema/java.ldif
include: file:///etc/openldap-2.4/schema/misc.ldif
include: file:///etc/openldap-2.4/schema/nis.ldif
include: file:///etc/openldap-2.4/schema/openldap.ldif
include: file:///etc/openldap-2.4/schema/ppolicy.ldif
include: file:///etc/openldap-2.4/schema/collective.ldif
# global database parameters
dn: olcDatabase=frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: frontend
# setup cn=config (password = 1234)
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootPW: {CRYPT}$6$...
olcSyncrepl: {0}rid=001 provider=ldap://ldap01
binddn="cn=Manager,dc=test"
bindmethod=sasl saslmech=external
searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5"
timeout=1 schemachecking=off
interval=00:00:00:5 retry="5 +"
starttls=critical
tls_cert=/etc/pki/tls/certs/Manager.crt
tls_key=/etc/pki/tls/private/Manager.key.crt
tls_cacert=/etc/pki/tls/certs/DS-CA.crt
tls_reqcert=demand
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
olcSyncrepl: {1}rid=002 provider=ldap://ldap02
binddn="cn=Manager,dc=test"
bindmethod=sasl saslmech=external
searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5"
timeout=1 schemachecking=off
interval=00:00:00:5 retry="5 +"
starttls=critical
tls_cert=/etc/pki/tls/certs/Manager.crt
tls_key=/etc/pki/tls/private/Manager.key.crt
tls_cacert=/etc/pki/tls/certs/DS-CA.crt
tls_reqcert=demand
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
olcMirrorMode: TRUE
olcAccess: to *
by dn.exact="cn=Manager,dc=test" write
by * none
olcLimits: dn.exact="cn=Manager,dc=test" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
# add the syncprov overlay to the cn=config database
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
# setup monitoring
dn: olcDatabase=monitor,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMonitorConfig
olcDatabase: monitor
olcAccess: to dn.subtree=cn=Monitor
by dn.exact="cn=config" write
by dn.exact="cn=Manager,dc=test" write
by * none
# setup Accesslog database definitions
dn: olcDatabase={2}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {2}mdb
olcDbDirectory: /var/lib/ldap-2.4/accesslog
olcSuffix: cn=accesslog
olcAccess: {0}to dn.subtree="cn=accesslog"
by dn.exact="cn=Manager,dc=test" read
olcRootDN: cn=Manager,dc=test
olcDbIndex: objectClass,entryCSN,reqStart,reqEnd,reqResult,reqDN eq
olcDbMode: 0600
# max size in bytes - 1GB = 1073741824 bytes
olcDbMaxsize: 1073741824
# add the syncprov overlay to the cn=accesslog database
dn: olcOverlay=syncprov,olcDatabase={2}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
# up to here ^^^ is also the config for the "slave"
# main mdb database definition
dn: olcDatabase={3}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {3}mdb
olcSuffix: dc=test
olcDbDirectory: /var/lib/ldap-2.4/test
olcRootDN: cn=Manager,dc=test
olcRootPW: {CRYPT}$6$...
olcSyncrepl: {0}rid=003 provider=ldap://ldap01
binddn="cn=Manager,dc=test"
bindmethod=sasl saslmech=external
searchbase="dc=test" type=refreshAndPersist retry="5 5 300 5"
timeout=1 schemachecking=off
interval=00:00:00:5 retry="5 +"
starttls=critical
tls_cert=/etc/pki/tls/certs/Manager.crt
tls_key=/etc/pki/tls/private/Manager_nopass.key.crt
tls_cacert=/etc/pki/tls/certs/DS-CA.crt
tls_reqcert=demand
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
olcSyncrepl: {1}rid=004 provider=ldap://ldap02
binddn="cn=Manager,test"
bindmethod=sasl saslmech=external
searchbase="dc=test" type=refreshAndPersist retry="5 5 300 5"
timeout=1 schemachecking=off
interval=00:00:00:5 retry="5 +"
starttls=critical
tls_cert=/etc/pki/tls/certs/Manager.crt
tls_key=/etc/pki/tls/private/Manager.key.crt
tls_cacert=/etc/pki/tls/certs/DS-CA.crt
tls_reqcert=demand
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
syncdata=accesslog
olcMirrorMode: TRUE
olcDbIndex: cn pres,eq,sub
olcDbIndex: gidNumber pres,eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: memberUid pres,eq
olcDbIndex: objectClass pres,eq
olcDbIndex: ou pres,eq,sub
olcDbIndex: sn pres,eq,sub
olcDbIndex: uid pres,eq
olcDbIndex: uidNumber pres,eq
olcDbIndex: entryCSN,entryUUID eq
olcDbMode: 0600
# max size in bytes - 1GB = 1073741824 bytes
olcDbMaxSize: 5368709120
olcAccess: to attrs=userPassword
by dn.exact="cn=Manager,dc=test" write
by self write
by anonymous auth
by * none
olcAccess: to *
by dn.exact="cn=Manager,dc=test" write
by self read
by * read
olcLimits: dn.exact="cn=Manager,dc=test" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
# add the syncprov overlay to the main mdb database
dn: olcOverlay={0}syncprov,olcDatabase={3}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckPoint: 20 10
# add the accesslog overlay to the main mdb database
dn: olcOverlay={1}accesslog,olcDatabase={3}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAccessLogConfig
olcOverlay: accesslog
olcAccessLogDB: cn=accesslog
olcAccessLogOps: writes
olcAccessLogSuccess: TRUE
olcAccessLogPurge: 01+00:00 04+00:00
# add memberof overlay to mdb database
dn: olcOverlay={2}memberof,olcDatabase={3}mdb,cn=config
objectClass: olcConfig
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: top
olcOverlay: memberof
olcMemberOfDangling: ignore
olcMemberOfRefInt: TRUE
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf
# add refint overlay to mdb database
dn: olcOverlay={3}refint,olcDatabase={3}mdb,cn=config
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcRefintConfig
objectClass: top
olcOverlay: refint
olcRefintAttribute: member memberOf
olcRefintNothing: cn=Manager,dc=test
# add the ppolicy overlay to the main mdb database
dn: olcOverlay={4}ppolicy,olcDatabase={3}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=default,ou=policies,dc=test
olcPPolicyHashCleartext: TRUE
$ sudo /usr/local/bin/ldapadd -v -f ./test-data.ldif x -D
"cn=Manager,dc=test" -w $(cat ./ldap.secret) -d0 -ZZ
# Organization
dn: dc=test
objectClass: dcObject
objectClass: organization
dc: test
o: Test
description: Test LDAP Root
# add ppolicy ou
dn: ou=policies,dc=test
ou: policies
objectClass: top
objectClass: organizationalUnit
# add password policy
dn: cn=default,ou=policies,dc=test
cn: default
objectClass: pwdPolicy
objectClass: pwdPolicyChecker
objectClass: person
objectClass: top
pwdAllowUserChange: TRUE
pwdAttribute: userPassword
pwdCheckQuality: 2
pwdExpireWarning: 600
pwdFailureCountInterval: 30
pwdGraceAuthNLimit: 5
pwdInHistory: 5
pwdLockout: TRUE
pwdLockoutDuration: 0
pwdMaxAge: 0
pwdMaxFailure: 5
pwdMinAge: 0
pwdMinLength: 5
pwdMustChange: FALSE
pwdSafeModify: FALSE
pwdCheckModule: check_password.so
sn: dummy value
...
Thanks!
Regards,
Patrick
11 years, 8 months