On Wed, 27 Oct 2004 13:56:48 -0300, Andreas <andreas@xxxxx> wrote:
> Has anybody been able to use luma-1.4-r1 with gssapi authentication?
> I keep getting this error in the browser plugin:
>
> GSSAPI
> SASL/GSSAPI authentication started
> Error during LDAP bind request
> Reason: {"info": "SASL(0): successful result: ", "desc": "Local error"}
>
> The kerberos ticket is fine and sasl gssapi auth works with ldapsearch
> from openldap.
Hi Andreas, Wido, and other list members-
I just noticed on the Luma home page that SASL support (including GSSAPI)
is now included and I therefore excitedly installed v1.4 but found that
it didn't seem to work. :-(
I then checked the archive, saw this post, and decided to subscribe and follow
up
(thus the reference headers won't line up and I doubt that my follow up will
appear in the same thread that Andreas and Wido already made, but at least it
has the same subject).
In any case, I have the following behavior to report.
I too configured Luma to use GSSAPI for authentication to the server and tried
it.
I first obtained a krbtgt as the rootdn, then tried to bind to the server with
Luma and I saw this error in the console used to invoke Luma:
GSSAPI
SASL/GSSAPI authentication started
Error during LDAP bind request
Reason: {'info': 'SASL(0): successful result: ', 'desc': 'Local error'}
This looks almost identical to the error that Andreas reported.
Although I did connect to the server, in looking in my server logs, I noticed
that it was an anonymous bind.
I checked my credentials cache after attempting the GSSAPI bind, but there was
only my krbtgt ticket (I'm using MIT Kerberos 5 v1.3.5). I also checked my kdc
logs and it looks like there was no request for an ldap ticket made at all.
After reading this thread, I also tried DIGEST-MD5, and it does seem to work
with no problems. I modified an entry in the directory after authenticating
as the only LDAP Directory entry with authorization to make changes and
everything
seemed to work. Looked over my OpenLDAP logs and it looks like everything
worked
fine.
I will point out one thing that I noticed though.
I originally had my server listening only on port 389 for ldap and ldaps
connections and Luma had a problem with this. First off, it only grudgingly
allowed me to have the "SSL" box checked combined with the port "389"
selected. If I typed in 389 (replacing the 636) and then clicked the "Apply"
button, it flipped 389 back to 636. It did this several times. I finally
found some combination of actions that made 389 stick with the SSL block
checked, but then it wouldn't work. The only thing I could do to get it
to succeed this way was reconfigure my server to listen on both 389 and 636,
then checked SSL and left the 636 in the port box and all was well.
BTW Andreas, you wrote that:
> but those were minor. The important thing is that it worked and
> the communication was even encrypted (not just the password).
May I ask, how did you determine this with certainty? I've been trying
to convince myself that this connection is encrypted also, but I don't
see anything definitive in my server logs.
Wido, I think Luma is really a nice tool. I've been mostly using GQ and
Directory Administrator, but I think that Luma surpasses them in many
ways (specifically SASL support, but also some others). I think it has
a very nice UI and I'm going to start using it as my primary directory
browser.
Also, I noticed your comment:
On Wed, Oct 27, 2004 at 08:29:41PM +0200, Wido Depping wrote:
> Hi Andreas,
> As I have stated in the release notes for Luma 1.4, it was not
> possible for me to test SASL support. I took some sample code from
> python-ldap and modified it a little bit.
and
> It would take too much time to set up a Kerberos server and stuff,
> since I"m currently very busy with exams.
I do have a working kerberos system and I have been considering the notion
of modifying GQ to support SASL binds (in particular GSSAPI), but it looks
to me like Luma has more working code for SASL and GSSAPI than does GQ (which
claims to support SASL and GSSAPI but when I queried the mailing list I learned
that this code is broken and the author has no plans to fix it).
Anyway, I'm now considering the notion of trying to fix Luma's GSSAPI code.
Has anyone else mentioned this to you? If not, what would you suggest I do
to get started (aside from get your sources)? Are all the latest sources
available through sourceforge CVS? Which module(s)? I would obviously
need write access to the CVS server to incorporate any changes, but I'm
nowhere near needing that now. I don't have much experience programming
in Python, so if you have thoughts on getting up to speed I'd welcome them.
Feel free to write me off-list on this.
Thanks for making Luma. It's a very nice product, and hopefully I can help
to improve upon it somewhat.
-Kevin
--
Kevin
http://www.gnosys.us
-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
|
