Enrique Rodriguez a écrit :
On 6/4/07, Emmanuel Lecharny <[EMAIL PROTECTED]> 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
soon.
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.
Emmanuel
