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 19:05:27 GMT
On 6/5/07, Emmanuel Lecharny <> wrote:
> ...
> If the BindRequest contains a specific information about which one of
> those three scheme is to be used, which was the case with the
> configuration I used, then it should not be assumed that it should go
> through GSSAPI if the SIMPLE authentication scheme is used, right ? I'm
> not a SASL specialist, but wfrom what I read, and from the code you
> wrote, I assumed that a SIMPLE authentication can be handled beside SASL.

There are 2 binds happening in the LDAP protocol provider, (1) the
bind by the LDAP protocol provider to the backend and (2) the bind of
the remote user.  The env properties you used to set "simple" and the
admin DN in (1) are being used by the LDAP protocol provider to bind
to the backend to search for users in an effort to authenticate them.

It is during (2), the bind from the remote user to the LDAP server,
that GSSAPI is being used.  Thus, the env configuration (1) is
separate from the "external" simple or SASL binds (2).  So, you are
correct to put the admin DN in the env properties.  But, since GSSAPI
was listed in the Spring XML list of enabled mechanisms, the server
was expecting to find a service principal with Kerberos credentials.
When it didn't, it logged a warning.

You are correct that SIMPLE and the SASL mechanisms can be used, but
that is intended for remote ("external") binds.  SIMPLE and the SASL
mechanisms are enabled by inclusion in the list of enabled
authentication mechanisms.

> ...
> I'm not sure that it will be easier for our users to have a mixed
> Kerberos+LDAP server, when they are used with LDAP alone right now.
> Before pushing them to use Kerberos, a lot of evanfelisation must be
> done. I perfectly agree that Kerberos is simply almost totally ignored
> except by a few big companies, and that i's a pity, but we must accept
> this fact. Remember that ADS was written to be an LDAP server first, and
> then a Kerberos server. Up to this point, the decision to mix those two
> configurations must be a common decision of the project. I strongly
> suggest that we discuss the consequences of this move before doing it.

It is simply not true that Kerberos is "almost totally ignored except
by a few big companies."  But, you are right that we should ask the
users.  Every SASL configuration I've ever seen (with other LDAP
servers) was totally based on the GSSAPI mechanism and the example
configs that have crossed this list were all GSSAPI.

I'm getting the same feeling that it would be better for users who
just want an embeddable LDAP server, possibly with the LDAP protocol
provider, to have that as a default configuration.  I've always felt
that TripleSec should be the realm controller, which leaves "Apache
Directory" as a focused directory server.


View raw message