Re: knowing which schema(s) to use

[Prentice Bisbal]

On 05/17/2017 05:03 AM, Turbo Fredriksson wrote:

On 16 May 2017, at 20:23, Prentice Bisbal  wrote:


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.

That’s what I do. I agree, on a theoretical level, that that might not be the 
best
way to do it, but it sure is the simplest :). I have way to much to do anyway, 
so
if I can take the easy way for once, I’ll take it.
The way I look at it, it's better to address this problem head-on and 
fix it now (if it in fact needs fixing), than wait until my schemas are 
so old that  when I upgrade my directory clients something breaks 
because my schemas are old and obsolete that they're no longer 
compatible with the client applications like SSSD, etc. In that 
scenario, I see bosses and users screaming at me, asking why the upgrade 
lead to problems...


Although to be honest, I don't think schemas really change very often.


As far as other applications using LDAP and any attribute in there, they are 
(should
be!) configurable. For example, LibNSS-LDAP and LibPAM-LDAP all let you 
configure
what attributes to use for what..
Very true, but I'd rather fix the schema in one place, rather than fix 
all my applications, which could have config files with various syntaxes 
all over /etc.


I’m sure there’s a reason for changing 'krbPrincipal' to ‘krbPrincipalAux’,
but personally I don’t care. The former works for me.
I think Ryan Tandy nailed it - one's for Heimdal Kerberos, the other is 
for MIT kerberos. I need to dig into this further to confirm for myself, 
though,



2. Who/what is the authoritative source for current schema definitions? Are 
they all defined in RFCs?

Probably not all. MINE isn’t. But I do have a registered IANA, so from the 
schemas
attribute or objectless OID, it should be “reasonably” easy to match the two 
and find
out who wrote it and from there you might be able to get a later version.

Re: knowing which schema(s) to use

[Prentice Bisbal]

On 05/16/2017 05:05 PM, Ryan Tandy wrote:


On Tue, May 16, 2017 at 03:23:59PM -0400, Prentice Bisbal wrote:
1. Kerberos attributes in "new" kerberos schema start with 'krb' 
instead of 'krb5'


Are you sure they are only older/newer versions of the same schema? 
That sounds to me like one of them is the MIT schema and the other is 
Heimdal. AFAIK the data formats are not really compatible despite the 
similar names for things.


MIT schema: 
https://github.com/krb5/krb5/blob/master/src/plugins/kdb/ldap/libkdb_ldap/kerberos.schema
Heimdal schema: 
https://github.com/heimdal/heimdal/blob/master/lib/hdb/hdb.schema


No, I can't be 100% sure they're newer/older versions of the same 
schema. The system admins I inherited this directory from are no longer 
working here, and they didn't document any of their work, so I have no 
idea where the older kerberos.schema file originated from.


The newer one that I am using now, the one with 'krb' instead of 'krb5' 
is provided by CentOS 6 as part of the krb5-server-ldap RPM. Querying 
this package indicates that it's from MIT's kerberos. We're actually 
using AD for our KDC, so I should use whatever is compatible with that. 
A quick Google search seems to indicate that AD is compatible with MIT 
kerberos, but I couldn't find any conclusive statements to that fact.


I'll compare both schemas above to what I'm using now.


Worth noting is that MIT has 'krbPrincipal' and 'krbPrincipalAux' but 
in Heimdal, 'krb5Principal' itself is already AUXILIARY.


Hmmm... that would indicate that the old Kerberos schema was Heimdal 
Kerberos.


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?


Right, you can't just go modifying schema without also modifying the 
applications that have the names and expectations baked into them. 
Generally the correct schema to use is the one supplied with the 
software itself - in this case, whichever KDC you are using should 
have a copy of the appropriate schema shipped with it.


That's what scares me. Sure, my changes allowed me to import the 
directory data with slapadd, but what happens when a critical 
application like SSSD is actually looking for the other attribute name?


It looks like I've got some work to do to make sure I'm using the 
correct schemas.


Prentice

Re: ldapcompare vs ldapsearch

[Aaron Richton]

On Wed, 17 May 2017, Roger Szabo wrote:

The goal is to perform frequent periodic calls to check the health of 
OpenLDAP using anonymous bind. 


Someone at 
http://stackoverflow.com/questions/16077473/ldap-bind-vs-search 
suggested that a ldapcompare would perform better than a ldapsearch 
because "there is only a single response per entry (a compare result) 
rather than two (a search result entry and a search result done)".


This explanation makes sense but it would be really great to hear the 
opinion of an expert on this, thank you very much :)


Overall, seems a bit oversimplified. I suppose the common case compare 
would typically be cheaper than a search, but you could just as easily be 
comparing against some dynamic membership where the matching is expensive, 
potentially invoking multiple internal searches (there goes your savings). 
On the other hand, if the search requires access to unindexed data, maybe 
the search is more expensive. If the result set is large, maybe the search 
is more expensive even if it is indexed!


But you're talking about health, so the entire conversation may need to be 
reframed. There's nothing in the RFC that says you have to search nor 
compare. You could do something definitely in-core, i.e. ldapwhoami(1) ... 
or a simple "can I speak the protocol properly?" could be connect, BIND, 
UNBIND, close.


As with most things, you'd have to think through your precise cases and 
plan accordingly. If you're only concerned with general health of 
slapd(8), a back-null or back-monitor would both be fairly cheap 
(back-null literally being as cheap as it gets). But it IS possible to 
have backend(s) fail while the slapd(8) frontend remains operational, so 
monitoring of individual backends may be warranted too. (This is my 
practice -- each backend gets an indexed monitoring search, with a search 
congruent with the common use case for each backend.)





The counterargument to all of this, across any network service, is "if 
your monitoring strains your capacity limits you're probably running too 
hot anyway."

Re: ldapcompare vs ldapsearch

[Dieter Klünter]

Am Wed, 17 May 2017 18:32:29 +0800
schrieb Roger Szabo :

> Hi,
> 
> The goal is to perform frequent periodic calls to check the health of
> OpenLDAP using anonymous bind.
> 
> Someone at
> http://stackoverflow.com/questions/16077473/ldap-bind-vs-search
> suggested that a ldapcompare would perform better than a ldapsearch
> because "there is only a single response per entry (a compare result)
> rather than two (a search result entry and a search result done)".
> 
> This explanation makes sense but it would be really great to hear the
> opinion of an expert on this, thank you very much :)

Indeed, a compare operation requires less time and server load than a
search operation. In order to reduce server load you may search the
monitor backend base object.

-Dieter

-- 
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E

ldapcompare vs ldapsearch

[Roger Szabo]

Hi,

The goal is to perform frequent periodic calls to check the health of
OpenLDAP using anonymous bind.

Someone at http://stackoverflow.com/questions/16077473/ldap-bind-vs-search
suggested that a ldapcompare would perform better than a ldapsearch because
"there is only a single response per entry (a compare result) rather than
two (a search result entry and a search result done)".

This explanation makes sense but it would be really great to hear the
opinion of an expert on this, thank you very much :)

Re: Antw: Re: TLSCACertificateFile directive and multiple CA certificates

[Dameon Wagner]

On Wed, May 17 2017 at 11:19:48 +0200, Ulrich Windl scribbled
 in "Antw: Re: TLSCACertificateFile directive and multiple CA certificates":
> >>> Dameon Wagner  schrieb am 17.05.2017 um 10:34 
> >>> in

> >> 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).
> > 
> > Depending on how you're testing things, the duplicate DN may well
> > be the _an_ issue, but possibly not a real issue...
> 
> I think the duplicate DN is a problem, because the DN (subject) is
> used to find a matching certificate. Then if that seems valid
> (regarding expiration dates), it'll be used. And I think to search
> is terminated here.

Indeed, it's definitely a problem, but I think the main problem is a
misunderstanding about what the TLSCACertificateFile directive is for
(and what Alex wants to achieve in using it).

> From a PKI point of view there's no problem with this algorithm,
> right?

I don't think so.  The documentation is clear that order doesn't
matter in the file pointed at by TLSCACertificateFile, but that mostly
refers to not having to apply the certificate chain in order of
descent, rather than any order of priority -- so long as the chain
can be traversed without gaps using the certificates concatenated in
the file, it should be happy.

(I won't comment on how carefully pedantic sysadmins like myself craft
our chain files :)

Cheers.

Dameon.

-- 
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
Dr. Dameon Wagner, Systems Development and Support
IT Services, University of Oxford
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><

Re: knowing which schema(s) to use

[Turbo Fredriksson]

On 16 May 2017, at 20:23, Prentice Bisbal  wrote:

> 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.

That’s what I do. I agree, on a theoretical level, that that might not be the 
best
way to do it, but it sure is the simplest :). I have way to much to do anyway, 
so
if I can take the easy way for once, I’ll take it.

As far as other applications using LDAP and any attribute in there, they are 
(should
be!) configurable. For example, LibNSS-LDAP and LibPAM-LDAP all let you 
configure
what attributes to use for what..


I’m sure there’s a reason for changing 'krbPrincipal' to ‘krbPrincipalAux’,
but personally I don’t care. The former works for me.

> 2. Who/what is the authoritative source for current schema definitions? Are 
> they all defined in RFCs?

Probably not all. MINE isn’t. But I do have a registered IANA, so from the 
schemas
attribute or objectless OID, it should be “reasonably” easy to match the two 
and find
out who wrote it and from there you might be able to get a later version.


signature.asc
Description: Message signed with OpenPGP

Re: TLSCACertificateFile directive and multiple CA certificates

[Dameon Wagner]

On Wed, May 17 2017 at 00:42:25 +0900, Alexandre Rosenberg scribbled
 in "TLSCACertificateFile directive and multiple CA certificates":
> Hello,

Hi Alex,

> 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.

How are testing to confirm this?

> 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).

Depending on how you're testing things, the duplicate DN may well be
the _an_ issue, but possibly not a real issue...

> 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.

Yes we're successfully using multiple certificates with a
TLSCACertificateFile directive.

It might well be interesting, and useful, for you to explain what
you're trying to accomplish, as it's possible that you're
misunderstanding what the directive is actually there to achieve.

The purpose of a CA Certificate file is to allow you to describe the
path of trust between your TLSCertificateFile (the certificate used to
assert the authentication and identity of your DSA) and the eventually
trusted Root CA certificate that a connecting client will have on
their system.

The reason it's often required is that the path of trust to the Root
CA traverses across several intermediate signing certificates (less
likely to be the case when using a selection of self-signed
certificates) -- each certificate has a "Subject" (the DN you mention
above), and an "Issuer" (which is the Subject of it's "parent" signing
certificate).  A simple(ish) way of showing this is to use the openssl
s_client subcommand to do something like the following:

#---8<-
$ echo | openssl s_client -connect $YOUR_LDAP_HOSTNAME:636 -showcerts
#---8<-

and review the "Certificate chain" output.  You will have to adjust
the command if you're using TLS negotiation over port 389 rather than
the dedicated ldaps port (636).

Cheers.

Dameon.

-- 
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
Dr. Dameon Wagner, Systems Development and Support
IT Services, University of Oxford
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><