Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of henri.gomez@gmail.com
 designates 209.85.200.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=f+lk3Qf55ZvTdLui6r5UoCdUci0d91nT49/v3Vlc8IZcscyGgK2nAVwHzko3PKjfElCLmsWD5u/cgtum0yuO7lQed4OG344JfA1V1NxETnNM/EHLagEvphWgRi2XP+p4fIgpSiazRmiaZuWHCQOi97j/yGZcdC5e+z6jvE0T8to=
Message-ID: <6291fc850804211431y69d16732ke9be5b97d4a3fc56@mail.gmail.com>
Date: Mon, 21 Apr 2008 23:31:49 +0200
From: "Henri Gomez" <henri.gomez@gmail.com>
To: "Tomcat Developers List" <dev@tomcat.apache.org>
Subject: Re: JNDIRealm
In-Reply-To: <4803678D.6000208@raritan.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <24661977.120271207897852556.JavaMail.servlet@kundenserver>
	 <4803678D.6000208@raritan.com>

Did someone as a example LDAP configuration against AD available
against standard JNDIRealm  ?

Regards.

2008/4/14, Seth Leger <seth.leger@raritan.com>:
> When working on this, I would appreciate if bug 44645 could also be
> resolved. It's a fairly trivial patch.
>
>  https://issues.apache.org/bugzilla/show_bug.cgi?id=44645
>
>  I also have additional fixes for JNDIRealm that address problems in
> connecting to Active Directory. The biggest issue is that during the
> authenticate() call, an LDAP search is performed. The current implementation
> uses the bind DN/bind password to perform the search or null credentials (if
> the bind DN/bind password is not provided). However, it should also use the
> credentials being supplied to the authenticate() call; adding code to do
> this resolves a giant hurdle in getting AD authentication to work properly
> with most Active Directory setups.
>
>  There is also a lifecycle bug in the JNDIRealm that causes authentication
> problems if stop() -> start() calls are issued against it.
>
>  I was waiting to open bugs and supply patches for these additional issues
> until bug 44645 was resolved (since that would give me a new base for
> patching). Bug 44645 is a much more severe issue since it affects all LDAP
> servers that use invalid or expired SSL certificates. I'll paste the
> description I gave in the bug in case anyone sees this message via search
> engines:
>
>  "This [bug 44645 patch] is necessary so that you can perform customized SSL
> negotiation on the connection. For instance, it allows you to connect to an
> SSL server with an invalid, expired, self-signed, or otherwise untrusted
> certificate. To do this, you just need to write a
> javax.net.ssl.SSLSocketFactory that does not perform the normal certificate
> validation during the SSL handshake and then specify the classname on the
> new setSocketFactory() call added by this patch."
>
>  Seth Leger
>  Sr. Software Engineer
>  Raritan, Inc.
>
>
>  albrecht@a-weinert.de wrote:
>
> > Brandon DuRette schrieb:
> >
> >
> > > While trying to track down an issue with logins taking a very long time,
> I
> > > just discovered in the 5.5.26 source code/Javadoc for JNDIRealm
> (likewise in
> > > the 6.0 documentation) that there's a big bold TODO to support
> connection
> > > pooling in the JNDIRealm.  I think this may be part of the login problem
> I'm
> > > seeing.
> > >
> > > Looking over the current source code, I can see that it's going to
> require a
> > > fairly extensive refactoring of the JNDIRealm code.  I'm willing to take
> a
> > > shot at fixing it, but wanted to first check with the list on a couple
> of
> > > ::::
> > > Thanks in advance for any pointers.
> > >
> > > Regards,
> > > Brandon
> > >
> > >
> >
> > Dear Brandon,
> >
> > re-doing JNDIRealm seems to me very necesary, but for an other
> > reason as yours, mentioned above.
> >
> > As I said in my mail (27 Feb 2008 to bug 42579) JNDIRealm is hardly
> > useable with (Windows Server 2003) Active Directory Domains  --
> > except for very small / trivial cases.
> >
> > After a long history of frustrations, I solved all the
> > Tomcat+AD-issues by an own ADweRealms. Experiences are, so far,
> > 100% good (with Apache Tomcat/6.0.16 on JDK1.6.0_05 and before
> > also with 5.5.x od 1.5.0_y). I offered the solution, already, in
> > mentioned mail. (got nil reactions)
> >
> > Perhaps, you could make your newly designed JNDIRealm realy fit for
> > Active Directory. It would be warmly welcomed by all who tried to
> > use / would have liked to use (but, as I know from some, gave up)
> > Tomcat with AD.
> >
> > Good luck
> >    Albrecht
> >
> > --------------
> >
> > PS.: For your convinience follows part of mentioned mail, in the
> >     hope of giving some pointers, you asked for in your mail.
> >
> > --- Comment #2 from
> > Dr. Albrecht Weinert <albrecht@a-weinert.de>
> > 2008-02-27 22:48:41 ---
> > By the way of JNDI/Tomcat + Active Directory:
> >
> > JNDIRealm is/was never quite happy with Active
> > Directory for a variety of reasons. After a bunch
> > of frustrations (of which the lying isUserInGruop()
> > was one of the worst), some time ago, I decided to
> > write a new Realm class, which I may contribute.
> >
> >
> http://www.a-weinert.de/java/docs/aWeinertBib/de/a_weinert/realm/ADweRealm.html
> >
> > ADweRealm searches only one way (performance!) from the
> > (authenticated) user to his groups. It follows
> > the quite important group-in-group relations (to
> > any depth), and so on.
> >
> > Experiences in a Windows Server 2003 domain (3000+ user
> > accounts, hundreds of groups etc.) are quite encouraging.
> > None of the Tomcat + Active Directory problems, which
> > Google is full of, arised any more.
> >
> >
> >
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>  For additional commands, e-mail: dev-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org