You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Enrique Rodriguez <en...@gmail.com> on 2007/06/04 21:44:15 UTC
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
On 6/3/07, elecharny@apache.org <el...@apache.org> wrote:
> Author: elecharny
> Date: Sun Jun 3 07:32:02 2007
> New Revision: 543905
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=543905
> Log:
> Replaced the server.xml which has been committed this week with
> something that can be used to launch the server. The two added
> interceptors have been committed, because they introduced some problem
> in the server. I'm sure this has not been tested *at all*.
PasswordPolicyService is tested by PasswordPolicyServiceITest and
KeyDerivationService is tested by KeyDerivationServiceITest, both in
server-unit.
HTH,
Enrique
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Emmanuel Lecharny <el...@apache.org>.
Emmanuel Lecharny a écrit :
> <snip/>
> .... You then get a message about the principal not being found in the
> baseSearchDN, which is by default (was ?)
Was. I fixed it in server.xml yesturday :
http://svn.apache.org/viewvc?view=rev&rev=543905
Emmanuel
>
>
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/4/07, Emmanuel Lecharny <el...@apache.org> wrote:
> Enrique Rodriguez a écrit :
> >
> > Where are you putting that value and what exception are you getting?
>
> It's in server.xml :
>
> beans>
> <bean id="environment" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
> <property name="properties">
> <props>
> <!-- JNDI security properties used to get initial contexts. -->
> <prop key="java.naming.security.authentication">simple</prop>
> <prop key="java.naming.security.principal">uid=admin,ou=system</prop>
> ...
> This is a warning, but when you get it in the console, you immediatly
> think that something is wrong (hopefully, this user is bound, because
> later in the chain threr is the handleSimple class which deal with this
> user).
The security.principal set in the props bean is only used for when the
LDAP protocol provider binds to the back-end, ie it is for internal
binds. The Kerberos service principal in question is for the LDAP
protocol provider to "run as" during secure connections over the wire
to the user's LDAP client, ie the bind from the user's perspective.
Though the security.principal DN can have Kerberos service credentials
and thus be used for the server-side of GSSAPI, it doesn't need to be.
In fact, in a multi-realm scenario you will want the LDAP protocol to
switch the server-side service principal, in which case you'll have to
have more than one DN with Kerberos credentials, each with its own
service principal name.
Enrique
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Emmanuel Lecharny <el...@apache.org>.
Enrique Rodriguez a écrit :
> On 6/4/07, Emmanuel Lecharny <el...@apache.org> 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).
>
>
> Where are you putting that value and what exception are you getting?
It's in server.xml :
beans>
<bean id="environment" class="org.springframework.beans.factory.config.PropertiesFactoryBean">
<property name="properties">
<props>
<!-- JNDI security properties used to get initial contexts. -->
<prop key="java.naming.security.authentication">simple</prop>
<prop key="java.naming.security.principal">uid=admin,ou=system</prop>
...
I get the exception in logs. When you call the ConfigureChain.execute()
method, as now the GSSAPI method is into the activeMechanisms, the method
Subject saslSubject = getSubject( config )
is called. You then get a message about the principal not being found in
the baseSearchDN, which is by default (was ?) set to ou=users,
dc=example, dc=com.
This is a warning, but when you get it in the console, you immediatly
think that something is wrong (hopefully, this user is bound, because
later in the chain threr is the handleSimple class which deal with this
user).
> Are you logging in with that user using simple authentication?
It's a warning, the default level for logs.
Emmanuel
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/4/07, Emmanuel Lecharny <el...@apache.org> 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).
Where are you putting that value and what exception are you getting?
Are you logging in with that user using simple authentication?
Enrique
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Emmanuel Lecharny <el...@apache.org>.
Enrique Rodriguez a écrit :
> On 6/5/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> We had two threads, called "[SASL] SASL configuration" and "[SASL]
> SASL configuration, part 2." I ask, respectfully, that you re-read
> those threads. In both threads we discuss changes to the Ldap
> configuration, such that there would be an LdapConfiguration bean
> under the StartupConfiguration bean. In fact, in the lead message of
> "[SASL] SASL configuration" I ask about moving maxSizeLimit and
> maxTimeLimit to StartupConfiguration. I don't think there should have
> been any surprise here.
Do you expect that a micro modification buried in hundred of lines of
code and dozens of mails will immediatly be remembered ?
> Moreover, during the review of the SASL
> branch there were positive comments made about the new protocol
> configuration.
We were positive, because it's a good idea. However, we asked to differ
the configuration modification, until SASL code was stable.
Alex asked you months ago to add one features after another, to be sure
that everything was ok. We are working on a 400 KLOC server, with 8
committers interacting and working on different parts, and each time we
inject some new code, we have to be extremelly cautious about the
consequences of those changes. The more changes at the same time, the
worst it can goes if something is wrong. I think Alex was right, and
that it should apply to all of us.
> I really tried to be open, and on the public mailing
> list, to discuss my changes before I made them.
And we appreciate that.
> In end result of
> these threads still appears to me to be positive concensus for an
> LdapConfiguration bean.
>
> http://mail-archives.apache.org/mod_mbox/directory-dev/200703.mbox/%3c568753d90703121820n76021567m551e604a1f6031c7@mail.gmail.com%3e
>
>
> http://mail-archives.apache.org/mod_mbox/directory-dev/200703.mbox/%3c568753d90703132036g3f387f58paa5cb1c87cb1c91e@mail.gmail.com%3e
>
>
Yes, but we also told you the next day that we should wait before
include it :
http://mail-archives.apache.org/mod_mbox/directory-dev/200703.mbox/%3ca32f6b020703151725t1a6c2425tc7d3ebd23b8726fd@mail.gmail.com%3e
http://mail-archives.apache.org/mod_mbox/directory-dev/200703.mbox/%3c45F9E74F.20804@gmail.com%3e
Again, it's not about the fact that your modifications were bad per se,
but it was bad timing.
Consider that adding one feature after the other one, step by step, is a
better way to go.
Anyway, we can discuss ad nauseam about configuration, exhibit mails
going in both directions, but I want to remind you that my original mail
was about something totally different, and I was stuck by these
modifications too. It was a little bit too much for me to handle at this
point.
I'm just trying to avoid such problems to arise again, because I have
lost a lot of time to understand what has happened, and without the doco
you posted on monday, plus the numerous mails we have exchanged, I would
have been stuck more longer.
Small modifications, limited modifications are better.
The timing was wrong, too. Maybe we should have told you to wait for
1.5.1 to be released (or close to be), but this is not expected before
at least one month.
Anyway, sh*t happens. Let clean the place now, and switch to the next
step. We can spend hours on such mails, I'm not sure they carry a lot of
added value (mine included, of course)
The problem is over, let's move on !
Emmanuel
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/5/07, Emmanuel Lecharny <el...@gmail.com> wrote:
>
> - I suggest that the Ldap configuration remains as simple as possible, and
> as close as it was previously.
>
> We will discuss further about which will be the next configuration scheme,
> considering that a lot of work have been done related to this part of the
> server. Not only your work, but also the guys working on LdapStudio (and the
> ServerConfiguration editor plugin), but also the current discussion about
> storing the configuration in the DIT.
>
> We didn't want to include this new configuration before the SASL dust has
> settled, this is why we asked for a delay before including it.
We had two threads, called "[SASL] SASL configuration" and "[SASL]
SASL configuration, part 2." I ask, respectfully, that you re-read
those threads. In both threads we discuss changes to the Ldap
configuration, such that there would be an LdapConfiguration bean
under the StartupConfiguration bean. In fact, in the lead message of
"[SASL] SASL configuration" I ask about moving maxSizeLimit and
maxTimeLimit to StartupConfiguration. I don't think there should have
been any surprise here. Moreover, during the review of the SASL
branch there were positive comments made about the new protocol
configuration. I really tried to be open, and on the public mailing
list, to discuss my changes before I made them. In end result of
these threads still appears to me to be positive concensus for an
LdapConfiguration bean.
http://mail-archives.apache.org/mod_mbox/directory-dev/200703.mbox/%3c568753d90703121820n76021567m551e604a1f6031c7@mail.gmail.com%3e
http://mail-archives.apache.org/mod_mbox/directory-dev/200703.mbox/%3c568753d90703132036g3f387f58paa5cb1c87cb1c91e@mail.gmail.com%3e
Enrique
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 6/5/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 6/5/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > ...
> > 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?
>
> Sorry, you confused me by including a snippet of the "props" bean from
> the Spring XML, so I thought this was related to the back-end bind.
>
> That a remote client attempts a SIMPLE bind and sees the warning about
> GSSAPI not being properly configured is simply because the GSSAPI
> principal is re-tried on EVERY bind until one is found. The idea was
> you'd see this warning and think "I need to obey the warning and add a
> service principal." This would allow you to add the principal and
> have it get used without restarting the server.
Ok, I get it now. But nothing in the code nor in the javadoc explain this
behaviour, which is anything but trivial. Your last doco (
http://cwiki.apache.org/confluence/display/DIRxSRVx11/HOWTO+do+SASL+GSSAPI+Authentication+to+ApacheDS)
helped me a lot, and I wish I have it when I had all those problems, last
sunday.
I agree that seeing a GSSAPI warning on a remote SIMPLE bind is
> misleading. But, it is not the case that SIMPLE binds "pass through
> GSSAPI," only that binds are the trigger for re-checking the presence
> of a GSSAPI service principal. I can add a conditional to only re-try
> finding a GSSAPI principal with GSSAPI requests.
Now that I understand what happens, I agree that the excpetion and the bind
are unrelated, or that they are simply related because you check the service
principal during a bind.
What I would suggest is :
- first of all, and even if it's a minor modification, just don't send a
full stack trace in the logs. It kills performance, and is not a good idea
for a warning level (when I see a stack trace, my brain immediately raise
the "BUG !" flag)
- I suggest that the Ldap configuration remains as simple as possible, and
as close as it was previously.
We will discuss further about which will be the next configuration scheme,
considering that a lot of work have been done related to this part of the
server. Not only your work, but also the guys working on LdapStudio (and the
ServerConfiguration editor plugin), but also the current discussion about
storing the configuration in the DIT.
We didn't want to include this new configuration before the SASL dust has
settled, this is why we asked for a delay before including it.
In the future, I want it to be clear that we need to avoid huge
modifications before everyone has evaluated the consequences on their parts,
as we now are a big team (we are now 8 active committers, 4 on Studio, 4 on
the server). This is not anymore easy to manage, and need more
communication, more documentation, and more carefull integration.
I know this will slow down the process, but I think it's almost impossible
to avoid having more rigid rules. I will try to set them up in the next few
weeks, if the PMCs aggreed.
Thanks,
Emmanuel
Enrique
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/5/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> ...
> 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?
Sorry, you confused me by including a snippet of the "props" bean from
the Spring XML, so I thought this was related to the back-end bind.
That a remote client attempts a SIMPLE bind and sees the warning about
GSSAPI not being properly configured is simply because the GSSAPI
principal is re-tried on EVERY bind until one is found. The idea was
you'd see this warning and think "I need to obey the warning and add a
service principal." This would allow you to add the principal and
have it get used without restarting the server.
I agree that seeing a GSSAPI warning on a remote SIMPLE bind is
misleading. But, it is not the case that SIMPLE binds "pass through
GSSAPI," only that binds are the trigger for re-checking the presence
of a GSSAPI service principal. I can add a conditional to only re-try
finding a GSSAPI principal with GSSAPI requests.
Enrique
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 6/5/07, Enrique Rodriguez <en...@gmail.com> wrote:
>
> On 6/5/07, Emmanuel Lecharny <el...@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
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/5/07, Emmanuel Lecharny <el...@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. 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.
Enrique
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Emmanuel Lecharny <el...@apache.org>.
Enrique Rodriguez a écrit :
> On 6/4/07, Emmanuel Lecharny <el...@apache.org> 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
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/4/07, Enrique Rodriguez <en...@gmail.com> wrote:
> ...
> 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.
I put a new draft of SASL GSSAPI-specific config instructions here:
http://cwiki.apache.org/confluence/display/DIRxSBOX/SASL+GSSAPI+Authentication+to+ApacheDS
> ...
> 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.
I removed GSSAPI from the server.xml's list of enabled authentication
mechanisms.
Enrique
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/4/07, Emmanuel Lecharny <el...@apache.org> 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">
<list>
<value>SIMPLE</value>
<value>CRAM-MD5</value>
<value>DIGEST-MD5</value>
<!-- <value>GSSAPI</value> -->
</list>
</property>
I apogize profusely since no one should be expected to magically know
how Kerberos (via GSSAPI) interacts with LDAP. The doco is lacking
here.
Enrique
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Emmanuel Lecharny <el...@apache.org>.
Enrique Rodriguez a écrit :
> On 6/4/07, Alex Karasulu <ak...@apache.org> wrote:
>
>> ...
>> Yes I agree. Did you try this after the merge Enrique?
>
>
> Of course I did. I continue to use the server.xml on a daily basis.
> I think the issue here is that I always LDIF load a set of users into
> an example.com partition, resulting in an ou=users,dc=example,dc=com
> that always has the entries I need for SASL and Kerberos. I believe
> my mistake is not adequately testing when the server.xml is configured
> to find users in a certain place (for LDAP, CP, or Kerberos) and not
> actually having the users there. I will re-test from now on for
> various mismatched configuration scenarios.
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.
Emmanuel
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Enrique Rodriguez <en...@gmail.com>.
On 6/4/07, Alex Karasulu <ak...@apache.org> wrote:
> ...
> Yes I agree. Did you try this after the merge Enrique?
Of course I did. I continue to use the server.xml on a daily basis.
I think the issue here is that I always LDIF load a set of users into
an example.com partition, resulting in an ou=users,dc=example,dc=com
that always has the entries I need for SASL and Kerberos. I believe
my mistake is not adequately testing when the server.xml is configured
to find users in a certain place (for LDAP, CP, or Kerberos) and not
actually having the users there. I will re-test from now on for
various mismatched configuration scenarios.
Enrique
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Alex Karasulu <ak...@apache.org>.
On 6/4/07, Emmanuel Lecharny <el...@apache.org> wrote:
>
> Enrique Rodriguez a écrit :
>
> > On 6/3/07, elecharny@apache.org <el...@apache.org> wrote:
> >
> >> Author: elecharny
> >> Date: Sun Jun 3 07:32:02 2007
> >> New Revision: 543905
> >>
> >> URL: http://svn.apache.org/viewvc?view=rev&rev=543905
> >> Log:
> >> Replaced the server.xml which has been committed this week with
> >> something that can be used to launch the server. The two added
> >> interceptors have been committed, because they introduced some problem
> >> in the server. I'm sure this has not been tested *at all*.
> >
> >
> > PasswordPolicyService is tested by PasswordPolicyServiceITest and
> > KeyDerivationService is tested by KeyDerivationServiceITest, both in
> > server-unit.
> >
> > HTH,
> >
> > Enrique
> >
> I was talking about the whole server. I got some nasty exceptions when
> running it . Unit tests just test some aspects of the server. Sometime,
> it's good to launch the server, and check that it's still working,
> especially when the modifications are huge.
Yes I agree. Did you try this after the merge Enrique?
Alex
Emmanuel
>
Re: svn commit: r543905 - /directory/apacheds/trunk/server-main/server.xml
Posted by Emmanuel Lecharny <el...@apache.org>.
Enrique Rodriguez a écrit :
> On 6/3/07, elecharny@apache.org <el...@apache.org> wrote:
>
>> Author: elecharny
>> Date: Sun Jun 3 07:32:02 2007
>> New Revision: 543905
>>
>> URL: http://svn.apache.org/viewvc?view=rev&rev=543905
>> Log:
>> Replaced the server.xml which has been committed this week with
>> something that can be used to launch the server. The two added
>> interceptors have been committed, because they introduced some problem
>> in the server. I'm sure this has not been tested *at all*.
>
>
> PasswordPolicyService is tested by PasswordPolicyServiceITest and
> KeyDerivationService is tested by KeyDerivationServiceITest, both in
> server-unit.
>
> HTH,
>
> Enrique
>
I was talking about the whole server. I got some nasty exceptions when
running it . Unit tests just test some aspects of the server. Sometime,
it's good to launch the server, and check that it's still working,
especially when the modifications are huge.
Emmanuel