Re: Antw: Re: TLSCACertificateFile directive and multiple CA certificates
by Dameon Wagner
On Thu, May 18 2017 at 20:17:16 +0900, Alexandre Rosenberg scribbled
in "Re: Antw: Re: TLSCACertificateFile directive and multiple CA certificates":
> Hello,
>
> I test and the issue only happen if 2 CA have the same DN.
> I regenerated the new CA with a different DN and it's working.
>
> As I am mentioned I am not sure what the proper behavior of
> OpenLDAP/OpenSSL should be in case 2 CA have the same DN.
>
> I am not sure I misunderstanding what TLSCACertificateFile is used
> for. The main use it to let OpenLDAP though which CA if should trust
> when validating certificate. That is clearly what is in the doc.
>
> Best,
>
> Alex
Hi Alex,
Glad you got it working.
I think the proper behaviour would be to not have 2 CAs with the same
DN, as the first-match-wins. As the DN is used to identify the issuer
of the certificate you're attempting to authenticate, it would make
little sense to have a naming collision.
I realise the docs say that order doesn't matter, but that assumes
that all included certificates would have clearly distinguished
subject names (hence "DN").
Cheers.
Dameon.
--
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
Dr. Dameon Wagner, Systems Development and Support
IT Services, University of Oxford
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
6 years
knowing which schema(s) to use
by Prentice Bisbal
Over the past few days or weeks, I've asked a number of questions
related to schemas as I move my LDAP directory to a newer OS and newer
version of OpenLDAP. As has happened in the past, I have run into schema
issues when importing the database (LDIF file) into the new directory
with slapadd.
This time I got the following errors:
1. Kerberos attributes in "new" kerberos schema start with 'krb' instead
of 'krb5'
2. I got a schema structural error because user accounts have both
objectclasses "account" and "krbPrincipal", which is not good.
3. We were using solaris.schema on the old system, which CentOS 6
doesn't provide, but it does provide duaconf.schema, which seemed be be
similar if not identical to solaris.schema.
Both of these are easy to fix - just use sed to change 'krb5' to 'krb',
and then change 'krbPrincipal' to 'krbPrincipalAux', but is this really
the best/safest way to make these changes. Also, what happens to apps
that are looking for the 'krb5' instead of 'krb' and vice-versa?
I think many system admins would say just copy the schemas from the old
server to the new server and forget about it, but I don't think this is
a good approach. After doing that several times, I imagine the newer
applications on the newer OS versions will be looking for different
objectclass or attribute names (like krb instead of krb5), and things
will eventually break, anyway.
So my questions are this:
1. How do the rest of you handle situations like this?
2. Who/what is the authoritative source for current schema definitions?
Are they all defined in RFCs?
In an earlier e-mail, regarding my kerberos schema issues, Michael
Ströder wrote
> You should use the current schema file shipped with your particular Kerberos installation.
That's exactly what I'm trying to do, which led to the kerberos schema
issues. And in the past there have been times when the current version
of the OS didn't provide the same schemas as the old version, and I was
left searching the Internet to find the modern equivalent of the schema
from the old system.
--
Prentice
6 years
TLSCACertificateFile directive and multiple CA certificates
by Alexandre Rosenberg
Hello,
Using multiple CA certificates with the TLSCACertificateFile directive
is not working in my setup. The man page (1) clearly states that
multiple certificates can be appended to the file.
Only the first CA in the file appear to be used. I confirmed this by
changing the order of the certificate in the file.
I am using self-signed CA Certificate which is used for validating the
provider server certificate during replication. I see this behaviour in
both the latest OpenLDAP release and an older release. In both case I am
using OpenSSL.
I just realized one important point abound my setup: Both CA certificate
have the same DN. Other that that they are completely different
certificate (different key, expiry date). Both CA certificate are valid
(not expired).
I will test tomorrow if appending another CA certificate with a
different CN makes a difference.
I am wondering if some people are successfully using multiples
certificates with the TLSCACertificateFile directive. Thanks.
Best,
Alex
(1) http://www.openldap.org/software/man.cgi?query=slapd.conf
6 years
invalid structural object class chain (account/krbPrincipal)
by Prentice Bisbal
So with you help, I managed to fix my initial issues of adding some
additional schemas to my system. Now, when I try to add the directory
data from my old LDAP servers with slapcat, I'm getting the following
structural error:
(line=168): (65) invalid structural object class chain
(account/krbPrincipal)
The relevant portions for the offending dn look like this:
objectClass: top
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
objectClass: krbPrincipal
structuralObjectClass: account
I should point out that I recently inherited this LDAP directory, and
now I'm upgrading the LDAP servers to new hardware and a new OS with a
much new version of OpenLDAP. I've never seen the stucturalObjectClass
attribute before. From my experience, when you get errors like this,
it's because either the schemas have changed, or someone used the -c
switch when adding new entries to the directory. Usually it's the latter.
I have googled my error and found many discussions for 'invalid
structural object chain' on this list, but none of them seem to apply to
this case. Most problem seemed be caused by having multiple conflicting
STRUCTURAL object classes in one entry, but that doesn't seem to be the
case since krbPrincipal is not STRUCTURAL. It's also not AUXILIARY:
objectclass ( 2.16.840.1.113719.1.301.6.9.1
NAME 'krbPrincipal'
SUP top
MUST ( krbPrincipalName )
MAY ( krbObjectReferences ) )
account is STRUCTURAL:
objectclass ( 0.9.2342.19200300.100.4.5 NAME 'account'
SUP top STRUCTURAL
MUST userid
MAY ( description $ seeAlso $ localityName $
organizationName $ organizationalUnitName $ host )
)
but posixAccount and shadowAccount are AUXILIARY :
objectclass ( 1.3.6.1.1.1.2.0 NAME 'posixAccount'
DESC 'Abstraction of an account with POSIX attributes'
SUP top AUXILIARY
MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory )
MAY ( userPassword $ loginShell $ gecos $ description ) )
objectclass ( 1.3.6.1.1.1.2.1 NAME 'shadowAccount'
DESC 'Additional attributes for shadow passwords'
SUP top AUXILIARY
MUST uid
MAY ( userPassword $ shadowLastChange $ shadowMin $
shadowMax $ shadowWarning $ shadowInactive $
shadowExpire $ shadowFlag $ description ) )
Any ideas for how to fix this? Could I just remove the account
objectClass? I'm not sure whether or not we're using any of it's
attributes.
--
Prentice
6 years
Help with assertion control
by Sudhindra M R
Hi
I am facing problem sending Assertion Control with LDAP DelRequest
message.
I am getting this error:
591950a9 begin get_filter
591950a9 conn=1004 op=1 DISCONNECT tag=120 err=2 text=error decoding filter
591950a9 conn=1004 op=1 DISCONNECT tag=120 err=2 text=error decoding filter
591950a9 conn=1004 op=1 do_delete: get_ctrls failed
My code snippet looks like below:
std::string keyy = "(&(cn=Manager)(givenName=Sudhi))";
struct berval * berEncodedFilter = ber_bvstr(keyy.c_str());
LDAPControl* serverControl[2];
return_code = ldap_control_create(LDAP_CONTROL_ASSERT, 0,
berEncodedFilter, 0, &(serverControl[0]));
serverControl[1] = NULL;
return_code = ldap_delete_ext(m_connection, dn.c_str(),
serverControl, 0, &msgID);
ber_bvfree(berEncodedFilter);
ldap_control_free(serverControl[0]);
Is there an issue in this code?
Please help.
Thanks
Sudhi
6 years
2.4.44 reproducible segfault via ldap search operation
by Karsten Heymann
Hi,
some hours ago I found a way to instantly kill our (production -sigh-
) slapd processed with a simple unauthenticated ldap search operation.
We are running 2.4.40 (from debian wheezy-backports) in production but
I was able to reproduce exactly the same behaviour with 2.4.44 (taken
from debian jessie-backports). While I'm building a minimal testcase
without internal information so I can provide it to the project (are
there more bug submission guidelines than
http://www.openldap.org/faq/data/cache/59.html ?), I wanted to ask how
you want me to handle this in my eyes quite serious incident. Should I
just post it to the mailing list or do you prefer a non-public
transmission first so the bug does not get exploited in a denial of
service use case before you had the chance to come up with a fix? I
will also try to verify if the problem is still existing in the
current git master or self compiled 2.4.44.
Best regards,
Karsten
6 years
Re: Client binding to a specific local address
by Quanah Gibson-Mount
Be sure and raise it for discussion on the -devel list before starting work.
--Quanah
> On May 15, 2017, at 7:13 PM, Daniel Le <daniel.le(a)exfo.com> wrote:
>
> I filed http://www.openldap.org/its/index.cgi?findid=8654 and will be working on it as well.
>
> Daniel
>
> -----Original Message-----
> From: Michael Ströder [mailto:michael@stroeder.com]
> Sent: Saturday, May 13, 2017 6:58 AM
> To: Daniel Le <daniel.le(a)exfo.com>
> Cc: openldap-technical(a)openldap.org
> Subject: Re: Client binding to a specific local address
>
> Daniel Le wrote:
>> Thanks Quanah and Michael. I much appreciate your help.
>>
>> I am new to this list. How do I submit an enhancement request? Or would you be willing
>> to do it on behalf of the community?
>
> You can file a RFE request here:
> http://www.openldap.org/its/
>
> Ciao, Michael.
>
6 years
Re: Client binding to a specific local address
by Quanah Gibson-Mount
--On Thursday, May 11, 2017 5:24 PM -0500 Quanah Gibson-Mount
<quanah(a)symas.com> wrote:
> Ah I see. No such option at this time that I am aware of.
Yeah, looking at os-ip.c in libldap, we have no option to use bind(2), and
purely use connect(2). I suppose this could be seen as an enhancement
request.
do{
osip_debug(ld, "attempting to connect: \n", 0, 0, 0);
if ( connect(s, sin, addrlen) != AC_SOCKET_ERROR ) {
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years
Transaction log files generated too frequently and DB_LOG_AUTOREMOVE setting does not remove old log files
by Joanne Yan Fu
I have a relatively small OpenLDAP DB (ldif backup file is less than 7M and total size of *bdb files is less than 20M),
that handles mostly read requests and few write requests. The servers are configured to run
in a cluster env using master-master replication. Recently, the servers ran out of space as the transaction log files accumulated. We deleted the old log files manually (as attemp on using "DB_ARCHIVE -d" failed) and were able to restart one of the servers, however noticed the transaction log files (with default size of 10M) were created too frequently ever since (can be 80 files a day). In peak hours, the 10M transaction log files was generated every min I am sure there were not so many write activities.
Does anyone know what could cause the creation of the tranaction log files so frequently? In addition, I had set "set_flags DB_LOG_AUTOREMOVE" flag along with check point settings in one of the servers running in cluster, but the log files were not removed automatically. Am I supposed to set the configurations on each server in the cluster to make it working on any of the servers?
Here are some settings and server information:
- OpenLDAP: slapd 2.4.23 on linux
- In slapd.conf:
database bdb
...
checkpoint 1024 15
- In DB_CONFIG
#the cache size is a little too big, we will tune it down later. Hope this will not be an issue
set_cachesize 0 268435456 1
set_lg_regionmax 262144
set_lg_bsize 2097152
set_flags DB_LOG_AUTOREMOVE
- a sublist of log files:
-rw------- 1 ldap ldap 10485760 May 11 14:50 log.0000000068
-rw------- 1 ldap ldap 10485760 May 11 14:52 log.0000000069
-rw------- 1 ldap ldap 10485760 May 11 14:53 log.0000000070
-rw------- 1 ldap ldap 10485760 May 11 14:54 log.0000000071
-rw------- 1 ldap ldap 10485760 May 11 14:55 log.0000000072
Thanks,
Joanne
6 years
Re: Client binding to a specific local address
by Michael Ströder
Ralf,
please stay on the mailing list.
Ralf Mattes wrote:
> Am Freitag, 12. Mai 2017 08:03 CEST, Michael Ströder <michael(a)stroeder.com> schrieb:
>
>> Quanah Gibson-Mount wrote:
>>> Ah I see. No such option at this time that I am aware of.
>>
>> I'd also see this as a useful feature.
>
> Admitedly more out of curiosity than need: why?
> [..]
> The only time a TCP connection can have more than one source IP is when there are
> multiple _routes_ to the same target IP - not something very common (and often a sign
> of miss- configuration).
I have such a configuration (for SMTP) and it's not a misconfiguration.
Ciao, Michael.
6 years
