directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enrique Rodriguez" <>
Subject Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Date Tue, 05 Jun 2007 00:23:28 GMT
On 6/4/07, Emmanuel Lecharny <> wrote:
> ...
> FYI, I usually used "uid=admin, ou=system"k. This is with this value
> that I get the exception. Of course, I'm using SIMPLE authentication, as
> many does... (simply because there was no way to test it with SASL as we
> didn't had it before the merge).
> Tests are to be done for at least the most common configurations, the
> admin user being obviously the most important.

OK, I was able to reproduce this and I will do two things:  (1)  I
will handle it better in the code and (2)  I will write a more
advanced configuration doc for setting up the GSSAPI mechanism.

Bear with me here but IMO this is a mis-configured server and,
therefore, it should warn.  Hopefully this will be clear from a new
Confluence page.  In short, pointing the GSSAPI configuration to the
admin user is inadequate config.  When LDAP is configured to use
GSSAPI, it must have a Kerberos service principal available to act as
the GSSAPI accept context.  So, a simple username/password user is not
sufficient; the service principal the LDAP protocol is to run as must
have Kerberos credentials.  Incidentally, this is why I expanded the
scope of the work here to include the KeyDerivationService.  The
KeyDerivationService is required to automatically maintain keys for
the service principal.  Furthermore, these keys should be random,
which the KeyDerivationService also supports.  Moreover, the service
principal MUST be of the name-form "ldap/<fqdn>@<realm>."  LDAP
clients will request service tickets from Kerberos for the LDAP
service using this name.  I will put this all in new doco tonight.

This may sound complicated but, trust me, with combined LDAP+Kerberos
at the Directory project, this is way easier than with LDAP and
Kerberos separate.

What, from my perspective, is a legitimate bug is that ConfigureChain
is supposed to warn only once and then remove GSSAPI from the list of
supported mechanisms, but it isn't.  When the exception is caught, the
line (88):

activeMechanisms.remove( "GSSAPI" );

is supposed to remove the mechanism but the list of mechanisms is
simply re-read from config.  Bone-headed on my part.  As noted in
another thread, I was hoping to eventually move the chain config to
the handler and set it once when the session is created.

Also, I should probably rename the "supportedMechanisms" in the
configuration (bean and server.xml) to "enabledMechanisms."  Since
GSSAPI appears in the list of enabled mechanisms, it is legitimate
(IMO) for the server to expect to find a proper service principal
under the searchBaseDn and to warn when it is not found.  Note that
the list of mechanisms that are enabled in the LDAP protocol config
have no relation to the list of "supportedSASLMechanisms" that are
returned from queries to the root nexus.

The work-around for this issue is to remove GSSAPI from the list of
enabled mechanisms, until such time as a proper Kerberos service
principal is configured.

    <property name="supportedMechanisms">
        <!-- <value>GSSAPI</value> -->

I apogize profusely since no one should be expected to magically know
how Kerberos (via GSSAPI) interacts with LDAP.  The doco is lacking


View raw message