directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Date Tue, 05 Jun 2007 19:36:52 GMT
On 6/5/07, Enrique Rodriguez <enriquer9@gmail.com> wrote:
>
> On 6/5/07, Emmanuel Lecharny <elecharny@apache.org> 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.


This distinction is supefluous. From the user perspective, and as specified
by the LDAP RFCs, there are two kind of possible binds : SIMPLE or SASL.
(the *or* is important here)

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.


I'm also using it when using  Apache Directory Studio (previously named
LdapStudio), and it's still using SIMPLE authn.

It is during (2), the bind from the remote user to the LDAP server,
> that GSSAPI is being used.


This is where I don't understand. The LDP request specify thet the bind is
SIMLPLE, not SASL, so I don't see a reason to pass through GSSAPI.May be I'm
plain wrong, maybe then the PLAIN mechanism should be used, but I don't
think this is the way to go. Can you elaborate a little bit?

 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.


I understand that the server logs a warning *if* GSSAPI is to be used, but
my point is that as the bind is specifically using SIMPLE, we should not go
through GSSAPI. Am I totally wrong on this ?

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.


But SIMPLE is not a negotiable algorithm ... You can still use SASL and use
PLAIN if you want to use plain text passwords (not the best idea on earth
...), but then, the bindRequest should specify you want a SASL bind, with
the PLAIN mechanism. This is not the case here. Maybe there is a confusion
about that.


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


You know that we are a little bit retarded here in "old europ"... Here, the
Kerberos usage is still in its infancy, which is quite a pity. And when you
are looking for 'kerberized' services (like tomcat, for instance), then this
is a total desert. Which leads me to think that not so much companies are
using Kerberos... But I might be totally wrong.

  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.


Mybe because you are body and soul into kerberos, so you only see people
using SASL only. I'm registred on a few french Ldap related ML, and all the
questions are about Samba, LDAPS, etc. A very few of them are about SASL and
Kerberos. But this is changing slowly.

I'm 100% convinced that Kerberos is the way to go. Using plain text password
is really an heresy, but when the main religion is to do so ... It takes
time to established an new church :)

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.


Our current users are starting to use ADS to write unit tests (a java
embeddable LDAP server is really a good thing to have to do that, because it
eliminate the burden to have to launch a server when launching your tests).
This is a first step. We also have a few users who are using it, and
sometime in production ( YEAH !!! ), but it's still the beginning of the
story. let's focus on having a stable server, and then we can slowly improve
it. The good thing about what we currently have is that using ADS as a LDAP
server only is possible, and it's also possible to use it as a Kerberos
server, in the same time. I also believe that we can have one configuration
to handle both situations without any kind of problem.

This is what we wanted to address after your SASL commits : cleaning the
configuration. Obviously, we will have to do it know, which is not exactly
the perfect timing for us (lot of side work atm...) Anyway...

Emmanuel

-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com

Mime
View raw message