[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
password policies not functioning as expected
Just found the problem and the solution.
It occurred that there was also a (probably mistakenly) second config module activated.
The module I had configured with ppolicy, was not used. The extra module that was active, did not have the ppolicy overlay loaded.
After correcting this, all seems to work as expected.
-----Oorspronkelijk bericht-----
Van: openldap-technical [mailto:openldap-technical-bounces@openldap.org] Namens openldap-technical-request@openldap.org
Verzonden: donderdag 28 juli 2016 14:00
Aan: openldap-technical@openldap.org
Onderwerp: openldap-technical Digest, Vol 104, Issue 21
Send openldap-technical mailing list submissions to
openldap-technical@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@openldap.org
You can reach the person managing the list at
openldap-technical-owner@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@openldap.org
When replying, please edit your Subject: header so it is more specific than "Re: openldap-technical digest..."
Today's Topics:
1. Re: need to recover slapd password and upgrade openldap
(Dan Hyatt)
2. Re: Antw: Intermediate certificates not being sent (Nat Sincheler)
3. Re: sizelimit (Maily Peng)
4. Missing user entries after restoring a backup ldif
(Matt Spaulding)
5. password policies not functioning properly (Kruger, P (Justid))
6. Re: sizelimit (Dieter Kl?nter)
7. Re: Antw: Intermediate certificates not being sent (Ulrich Windl)
----------------------------------------------------------------------
Message: 1
Date: Tue, 26 Jul 2016 12:15:00 -0500
From: Dan Hyatt <dhyatt@dsgmail.wustl.edu>
To: Aaron Richton <richton@nbcs.rutgers.edu>, dhyatt@wustl.edu
Cc: openldap-technical@openldap.org
Subject: Re: need to recover slapd password and upgrade openldap
Message-ID: <b5a9dc49-8420-ef20-0779-d65ddfcdcad7@dsgmail.wustl.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
So, a more simple question...
Can I install a current version of OpenLDAP on a current RedHat/Centos server (specially built for this purpose.
Then use slapcat to export the information from the old server, import it to the new server, where the admin password is not corrupt.
Can I import the schemas or are there likely substantial changes to the schemas across versions?
My goals are to create a new LDAP server running Centos/Redhat, transfer
20 users and allow them to keep their existing passwords, allow them to access my servers, and allow them authentication to samba.
and create an LDAP slave (or cluster)
not sure if syncrepl is the current way to go.
I have root to the server, but I do not have the admin password to the Openldap 2.2 as it became corrupted somehow.
On 07/24/2016 09:15 PM, Aaron Richton wrote:
> On Fri, 22 Jul 2016, Dan Hyatt wrote:
>
>> My admin openLDAP 2.2 password became corrupt in the last week and I
>> cannot
> [...]
>> I found some instructions which seem simple risky and no backout
>> strategy. Simply running
>> http://techiezone.rottigni.net/2011/12/change-root-dn-password-on-openldap/
>>
>
> That link (apparently from 2011) doesn't apply to your software from
> 2003. There's no back-config in OpenLDAP 2.2. So don't try that...
@(#) $OpenLDAP: slapd 2.2.13 (Nov 26 2010 07:45:22) $
mockbuild@x86-003.build.bos.redhat.com:/builddir/build/BUILD/openldap-2.2.13/openldap-2.2.13/build-servers/servers/slapd
>
> [...]
>> Having the LDAP on two separate hyper visors (with local disks) to
>> avoid the storage/authentication chicken/egg
>> Is there a better upgrade plan
>
> Are you saying that your one and only LDAP server uses itself for its
> own A&A?
Authentication and Authorization?
The server provides authentication and authorization for my group. The
server only does LDAP and home dirs.
I want to upgrade it to Centos 6.8 or Centos 7 (that is equal to redhat
6.8 or redhat 7) on a hypervisor with a slave running the current
favored release.
>
> [...]
>> I have the log files, is there a way to backout to last week without
>> the admin password (which became corrupt last week).
>
> I'm not sure what you're referring to by "log files." The general-case
> OpenLDAP backup tool is slapcat(8). Hopefully you have been running it
> routinely. The resulting LDIF can be easily inspected; if you have
> enough backups, you might even be able to find one without corruption.
We took over responsibility the LDAP in December, there was not a happy
handoff... no documenation..just the password and had to move it to the
new VLAN.
------------------------------
Message: 2
Date: Tue, 26 Jul 2016 08:20:14 -0700
From: Nat Sincheler <fai1107@macrotex.net>
To: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>,
openldap-technical@openldap.org
Subject: Re: Antw: Intermediate certificates not being sent
Message-ID: <991f77f9-fd05-eb9b-7f07-f350c4a7bc68@macrotex.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 7/25/2016 11:24 PM, Ulrich Windl wrote:
>>>> Nat Sincheler <fai1107@macrotex.net> schrieb am 25.07.2016 um 19:06 in
> Nachricht <c19c2a3a-3c90-5baa-43c7-800b050ea5b7@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".
It appears that OpenLDAP is not sending the intermediate or root
certificates.
However, if I put all the intermediate and root certificates into a
single file and point olcTLSCACertificateFile at this file, those
intermediate certificates _are_ sent.
So, it appears that olcTLSCACertificateFile sends the certificates but
but olcTLSCACertificatePath does not.
Am I misunderstanding the purpose olcTLSCACertificatePath?
Thanks.
>
> Regards,
> Ulrich
>
>>
>> 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?
>
>
>
>
------------------------------
Message: 3
Date: Tue, 26 Jul 2016 19:47:27 +0200
From: Maily Peng <mpeng@keyyo.com>
To: Frank Swasey <Frank.Swasey@uvm.edu>
Cc: openldap-technical@openldap.org
Subject: Re: sizelimit
Message-ID: <6fedd3fe-f1c4-9897-0eae-3c77159add6d@keyyo.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Hello Frank,
Nope, the limits directive are unlimited on the provider.
First of all, I need to have access to all of the entries on the
consumers , in order to check EntryCSN between provider and consumers. I
use the python script : check_syncrepl_extended that needs to bind
provider and consumer via the same dn. That's why I could not use rootdn
. ( not the same between slapd servers) .
thank you
Le 26/07/2016 ? 19:09, Frank Swasey a ?crit :
> You have shown us what the syncrepl, sizelimit and limits look like on
> your consumer. Have you got that limits directive also set up on your
> provider? It is the provider that needs to allow your replication DN
> to obtain unlimited entries.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.openldap.org/lists/openldap-technical/attachments/20160726/391713f4/attachment.html>
------------------------------
Message: 4
Date: Tue, 26 Jul 2016 22:16:24 -0700
From: Matt Spaulding <mspaulding06@gmail.com>
To: openldap-technical@openldap.org
Subject: Missing user entries after restoring a backup ldif
Message-ID:
<CAF8MFWUJo=5su_RyF0YUHv3hJjRJ6fdHCs7WbhYxqB_y=WFkXg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.openldap.org/lists/openldap-technical/attachments/20160726/76b0d94a/attachment.html>
------------------------------
Message: 5
Date: Wed, 27 Jul 2016 14:48:03 +0000
From: "Kruger, P (Justid)" <p.kruger@justid.nl>
To: "'openldap-technical@openldap.org'"
<openldap-technical@openldap.org>
Subject: password policies not functioning properly
Message-ID:
<0225C0718C172540817182B2E2B3160C20343C2A@JSTD-PSEXCH02.ad.minjus.nl>
Content-Type: text/plain; charset="us-ascii"
I've set password policies on my OpenLDAP 2.4.
Unfortunately things do not work as expected and although extensively searched on forums and Google, I cannot get the proper results. What am I missing in what I did or should have done?
What goes wrong:
- Password policies seem not to be validated or I do get a failure message
The failures depend on pwdinHistory setting to zero (no failure) to > 0 failure like given below
5798c94a <= acl_access_allowed: granted to database root
5798c94a bdb_modify_internal: replace userPassword
5798c94a bdb_modify_internal: replace pwdChangedTime
5798c94a bdb_modify_internal: add pwdHistory
5798c94a bdb_modify_internal: replace pwdChangedTime
5798c94a bdb_modify_internal: add pwdHistory
5798c94a bdb_modify_internal: 20 modify/add: pwdHistory: value #0 already exists
5798c94a hdb_modify: modify failed (20)
5798c94a send_ldap_result: conn=1000 op=18 p=3
5798c94a send_ldap_result: err=20 matched="" text="modify/add: pwdHistory: value #0 already exists"
5798c94a send_ldap_response: msgid=62 tag=103 err=20
ber_flush2: 61 bytes to sd 15
0000: 30 3b 02 01 3e 67 36 0a 01 14 04 00 04 2f 6d 6f 0;..>g6....../mo
0010: 64 69 66 79 2f 61 64 64 3a 20 70 77 64 48 69 73 dify/add: pwdHis
0020: 74 6f 72 79 3a 20 76 61 6c 75 65 20 23 30 20 61 tory: value #0 a
0030: 6c 72 65 61 64 79 20 65 78 69 73 74 73 lready exists
ldap_write: want=61, written=61
0000: 30 3b 02 01 3e 67 36 0a 01 14 04 00 04 2f 6d 6f 0;..>g6....../mo
0010: 64 69 66 79 2f 61 64 64 3a 20 70 77 64 48 69 73 dify/add: pwdHis
0020: 74 6f 72 79 3a 20 76 61 6c 75 65 20 23 30 20 61 tory: value #0 a
0030: 6c 72 65 61 64 79 20 65 78 69 73 74 73 lready exists
5798c94a conn=1000 op=18 RESULT tag=103 err=20 text=modify/add: pwdHistory: value #0 already exists
5798c94a slap_graduate_commit_csn: removing 0x7f8a0c107960 20160727144634.392449Z#000000#000#000000
This makes, as far as I tested, no difference with just using a default policy or when using a default and specific policy with pwdPolicySubentry attribute in the user.
I've used ACL's on my LDAP schema.
My purpose:
Use a default policy which basically says to use no policy
Add a specific policy for users in a subtree.
Below are the steps and LDAP LDIF files used to build the OpenLDAP.
Included here are the LDIF files for:
config, base and sub part of tree, replication ou and user, application users (service accounts), ldap managers ou, ACL's, OU's needed for application specific content, policy.
Excluded here (but done) are the LDIF files for: enable logging, replication, TLS/SSL.
The LDIF files first line contains the LDIF filename and the command used to apply them
# ldapadd -Y EXTERNAL -H ldapi:/// -f 01_addrootpw.ldif
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootPW
olcRootPW: {SSHA}hashhashhashhashhashhash
# ldapadd -Y EXTERNAL -H ldapi:/// -f 02_root-base.ldif
# change olcRootPW to your Root password
# change domain parts to your domain
dn: olcDatabase={1}monitor,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.base="cn=Manager,ou=ldapbeheerders,dc=example,dc=nl" read by * none
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=example,dc=nl
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=Manager,ou=ldapbeheerders,dc=example,dc=nl
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA} hashhashhashhashhashhash
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=Manager,ou=ldapbeheerders,dc=example,dc=nl" write by anonymous auth by self write by * none
olcAccess: {1}to dn.base="" by * read
# ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 03_ldap-manager.ldif
dn: dc=example,dc=nl
objectClass: top
objectClass: dcObject
objectclass: organization
o: example nl
dc: example
dn: ou=ldapbeheerders,dc=example,dc=nl
objectclass: organizationalUnit
ou: ldapbeheerders
dn: cn=Manager,ou=ldapbeheerders,dc=example,dc=nl
objectclass: organizationalRole
cn: Manager
description: Directory Manager
# ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 04_replication_user.ldif
dn: ou=replicatie,dc=example,dc=nl
objectclass: organizationalUnit
ou: replicatie
description: replicatie groep
dn: cn=replicator,ou=replicatie,dc=example,dc=nl
cn: replicator
sn: user
objectClass: person
userPassword: passwordincleartext
# ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 05_applications.ldif
# Create ou generic application scheme
dn: ou=applicaties,dc=example,dc=nl
objectclass: organizationalUnit
ou: applicaties
# Aanmaak ou APP1 applicatieschema
dn: ou=APP1,dc=example,dc=nl
objectclass: organizationalUnit
ou: APP1
# Aanmaak ou APP2 applicatieschemas
dn: ou=APP2,dc=example,dc=nl
objectclass: organizationalUnit
ou: APP2
# ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 06_ServiceAccounts.ldif
dn: ou=ServiceAccounts,dc=example,dc=nl
objectclass: organizationalUnit
ou: ServiceAccounts
description: Service Accounts Applicaties
#Service account APP1
dn: cn=SAAPP1,ou=ServiceAccounts,dc=example,dc=nl
cn: SAAPP1
sn: user
objectClass: person
userPassword: {SSHA}hashedpassword
description: Service Account APP1
#Service account APP2
dn: cn=SAAPP2,ou=ServiceAccounts,dc=example,dc=nl
cn: SAAPP2
sn: user
objectClass: person
userPassword: {SSHA} hashedpassword
description: Service Account APP2
# ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 07_ACL.ldif
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: to attrs=userPassword
by anonymous auth
by self write
by * break
olcAccess: to dn="ou=replicatie,dc=example,dc=nl"
by self write
by * none
olcAccess: to *
by dn.base="cn=replicator,ou=replicatie,dc=example,dc=nl" read
by * break
olcAccess: to dn.subtree="cn=default,ou=policies,dc=example,dc=nl"
by dn.children="ou=ldapbeheerders,dc=example,dc=nl" write
by * none
olcAccess: to dn="ou=ldapbeheerders,dc=example,dc=nl"
by dn.children="ou=ldapbeheerders,dc=example,dc=nl" write
by * none
olcAccess: to dn="ou=ServiceAccounts,dc=example,dc=nl"
by self search
by * none
olcAccess: to dn.subtree="ou=applicaties,dc=example,dc=nl"
by dn.children="ou=ServiceAccounts,dc=example,dc=nl" write
by * none
olcAccess: to dn.subtree="ou=APP1,dc=example,dc=nl"
by dn.base="cn=SAAPP1,ou=ServiceAccounts,dc=example,dc=nl" write
by * none
olcAccess: to dn.subtree="ou=APP2,dc=example,dc=nl"
by dn.base="cn=SAAPP2,ou=ServiceAccounts,dc=example,dc=nl" write
by * none
olcAccess: to dn.children="dc=example,dc=nl"
by * read
olcAccess: to dn.children="dc=nl"
by * read
# ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 08_Add-testusers.ldif
dn: uid=APP1_1,ou=APP1gebruikers,ou=APP1,dc=example,dc=nl
objectClass: inetOrgPerson
objectClass: organizationalPerson
ObjectClass: person
objectClass: top
uid: APP1_1
cn: APP1_1 gebruiker
sn: gebruiker
pwdPolicySubentry: cn=default,ou=policies,ou=APP1,dc=example,dc=nl
dn: uid=APP1_2,ou=APP1gebruikers,ou=APP1,dc=example,dc=nl
objectClass: inetOrgPerson
objectClass: organizationalPerson
ObjectClass: person
objectClass: top
uid: APP1_2
cn: APP1_2 gebruiker
sn: gebruiker
pwdPolicySubentry: cn=default,ou=policies,ou=APP1,dc=example,dc=nl
dn: cn=APP2_1,ou=APP2gebruikers,ou=APP2,dc=example,dc=nl
objectClass: inetOrgPerson
objectClass: organizationalPerson
ObjectClass: person
objectClass: top
uid: APP2_1
cn: APP2_1 gebruiker
sn: gebruiker
dn: cn=APP2_2,ou=APP2gebruikers,ou=APP2,dc=example,dc=nl
objectClass: inetOrgPerson
objectClass: organizationalPerson
ObjectClass: person
objectClass: top
uid: APP2_2
cn: APP2_2 gebruiker
sn: gebruiker
dn: cn=APP2_3,ou=gebruikers,ou=applicaties,dc=example,dc=nl
objectClass: inetOrgPerson
objectClass: organizationalPerson
ObjectClass: person
objectClass: top
uid: APP2_3
cn: APP2_3 gebruikercat
sn: gebruiker
dn: cn=APP2_4,ou=gebruikers,ou=applicaties,dc=example,dc=nl
objectClass: inetOrgPerson
objectClass: organizationalPerson
ObjectClass: person
objectClass: top
uid: APP2_4
cn: APP2_4 gebruiker
sn: gebruiker
Below is the part where the password policies are configured.
# ldapadd -Y EXTERNAL -H ldapi:/// -f P01_ppolicymodule.ldif
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModuleLoad: ppolicy.la
olcModulePath: /usr/lib64/openldap
# ldapadd -Y EXTERNAL -H ldapi:/// -f P02_ppolicyoverlay.ldif
dn: olcOverlay=ppolicy,olcDatabase={2}hdb,cn=config
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=default,ou=policies,dc=example,dc=nl
olcPPolicyUseLockout: TRUE
olcPPolicyHashCleartext: TRUE
# ldapadd -x -D 'cn=Manager,ou=ldapbeheerders,dc=example,dc=nl' -W -f P03_default_ppolicy.ldif
dn: ou=policies,dc=example,dc=nl
objectClass: top
objectClass: organizationalUnit
ou: policies
dn: cn=default,ou=policies,dc=example,dc=nl
objectClass: top
objectClass: device
objectClass: pwdPolicyChecker
objectClass: pwdPolicy
cn: default
pwdAttribute: userPassword
pwdInHistory: 8
pwdMinLength: 8
pwdMaxFailure: 5
pwdFailureCountInterval: 1800
pwdCheckQuality: 1
pwdMustChange: TRUE
pwdGraceAuthNLimit: 0
pwdMaxAge: 7776000
pwdExpireWarning: 1209600
pwdLockoutDuration: 900
pwdLockout: TRUE
pwdSafeModify: FALSE
# ldapadd -x -D 'cn=Manager,ou=ldapbeheerders,dc=example,dc=nl' -W -f P04_APP1_ppolicies.ldif
dn: ou=policies,ou=APP1,dc=example,dc=nl
ou: policies
objectClass: top
objectClass: organizationalUnit
dn: cn=default,ou=policies,ou=APP1,dc=example,dc=nl
objectClass: top
objectClass: device
objectClass: pwdPolicy
cn: default
pwdAttribute: userPassword
pwdAllowUserChange: TRUE
pwdCheckQuality: 0
pwdExpireWarning: 374400
pwdFailureCountInterval: 1800
pwdGraceAuthNLimit: 5
pwdInHistory: 12
pwdLockout: TRUE
pwdLockoutDuration: 0
pwdMaxAge: 2592000
pwdMaxFailure: 5
pwdMinAge: 0
pwdMinLength: 8
pwdMustChange: TRUE
pwdSafeModify: FALSE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.openldap.org/lists/openldap-technical/attachments/20160727/75163e93/attachment.html>
------------------------------
Message: 6
Date: Wed, 27 Jul 2016 23:36:29 +0200
From: Dieter Kl?nter <dieter@dkluenter.de>
To: openldap-technical@openldap.org
Subject: Re: sizelimit
Message-ID: <20160727233629.44b6c236@pink.avci.de>
Content-Type: text/plain; charset=UTF-8
Am Mon, 25 Jul 2016 13:23:50 +0200
schrieb Maily Peng <mpeng@keyyo.com>:
> 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".
[...]
read slapd.conf(5), section GENERAL DATABASE OPTIONS
within a database declaration you may set
limits dn.base=cn=replicator,.....
size=unlimited
time=unlimited
and within a syncrepl configuration
sizelimit=unlimited
timelimit=unlimited
Note that syncrepl is a ldap client, thus some parameters from
ldap.conf(5) might be applicable.
-Dieter
--
Dieter Kl?nter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53?37'09,95"N
10?08'02,42"E
------------------------------
Message: 7
Date: Thu, 28 Jul 2016 08:19:43 +0200
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: <fai1107@macrotex.net>,<openldap-technical@openldap.org>
Subject: Re: Antw: Intermediate certificates not being sent
Message-ID: <5799C01F020000A100022217@gwsmtp1.uni-regensburg.de>
Content-Type: text/plain; charset=US-ASCII
>>> Nat Sincheler <fai1107@macrotex.net> schrieb am 26.07.2016 um 17:20 in
Nachricht <991f77f9-fd05-eb9b-7f07-f350c4a7bc68@macrotex.net>:
>
> On 7/25/2016 11:24 PM, Ulrich Windl wrote:
>>>>> Nat Sincheler <fai1107@macrotex.net> schrieb am 25.07.2016 um 19:06 in
>> Nachricht <c19c2a3a-3c90-5baa-43c7-800b050ea5b7@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
Regards,
Ulrich
>
> It appears that OpenLDAP is not sending the intermediate or root
> certificates.
>
> However, if I put all the intermediate and root certificates into a
> single file and point olcTLSCACertificateFile at this file, those
> intermediate certificates _are_ sent.
>
> So, it appears that olcTLSCACertificateFile sends the certificates but
> but olcTLSCACertificatePath does not.
>
> Am I misunderstanding the purpose olcTLSCACertificatePath?
>
> Thanks.
>
>
>>
>> Regards,
>> Ulrich
>>
>>>
>>> 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?
>>
>>
>>
>>
------------------------------
Subject: Digest Footer
_______________________________________________
openldap-technical mailing list
openldap-technical@openldap.org
http://www.openldap.org/lists/mm/listinfo/openldap-technical
------------------------------
End of openldap-technical Digest, Vol 104, Issue 21
***************************************************