directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Date Tue, 05 Jun 2007 08:07:03 GMT
Enrique Rodriguez a écrit :

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

Thanks for taking care of that.

> Bear with me here but IMO this is a mis-configured server and,
> therefore, it should warn.  

IMO, this is not really a mis-configured server. The admin user is 
expicitely described as using SIMPLE authentication, thus we should not 
get any warning.

If I don't get completely wrong, the LDAP protocol allows a user to bind 
on a server using three kind of authentication scheme :
- anonymous
- simple
- sasl

        AuthenticationChoice ::= CHOICE {
             simple                  [0] OCTET STRING,
                                     -- 1 and 2 reserved
             sasl                    [3] SaslCredentials,
             ...  }

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.

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

Ok, thanks. I also think we must have a clear discussion about the 
configuration, and about the way the server handle the different kinds 
of authentication schemes. I still have to analyze what you did, and 
what we can do in respect whith the various RFCs around there.

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

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.

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

Ok, that's true that we are brand new to SASL and Kerberos, but because 
we are new to that, you must be carefull with such changes. This is the 
main issue we have here. Hopefully, I will be soon working on Kerberos 
in the next few weeks, so you and Alex won't be alone in the battlefield 

I will create a new thread to address the other technical points which 
does not deserve to be burried in a complaint thread.

Thanks for having responded, Enrique. I appreciated that.


View raw message