It is possible to perform successful authentication against an Active
Directory server with the standard JNDIRealm but only if:
a) A bind DN and bind password is supplied to JNDIRealm
b) Anonymous searches (with null credentials) are successful against the
server
(b) is highly unlikely because by default, Active Directory does not
allow searches of the user tree for anonymous users. It is not desirable
to enable this behavior in many cases because it allows any network
client to discover the Active Directory user list without credentials.
For (a) to work, the Active Directory administrator must give bind DN
and password of a user with search permissions to the Tomcat
administrator. This could either be the Administrator password or the
password of a dummy user that is set up for this purpose. However, this
is also undesirable in many cases because it means that the LDAP
administrator is giving out an Administrator-level password that is
likely being stored in plain text inside the Tomcat configuration. This
is more secure than anonymous access but still isn't acceptable for many
users.
My patch changes the behavior so that the credentials provided during
authentication are used during a login to perform the LDAP search.
Seth Leger
Sr. Software Developer
Raritan, Inc.
Henri Gomez wrote:
Did someone as a example LDAP configuration against AD available
against standard JNDIRealm ?
Regards.
2008/4/14, Seth Leger <[EMAIL PROTECTED]>:
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.
[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
