Bug 42579 - [Patch] JNDIRealm fails to parse absolute names
Summary: [Patch] JNDIRealm fails to parse absolute names
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.5.23
Hardware: All Windows XP
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords: PatchAvailable
Depends on:
Blocks:
 
Reported: 2007-06-04 14:13 UTC by Brandon DuRette
Modified: 2009-10-22 07:54 UTC (History)
1 user (show)



Attachments
My patch to fix this issue (3.00 KB, patch)
2007-06-04 14:14 UTC, Brandon DuRette
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Brandon DuRette 2007-06-04 14:13:14 UTC
Active Directory can respond to a query with SearchResult's that are not
relative.  We discovered this happening with a directory hosted across many
servers when the userBase was not sufficient to identify a single server.

In getUserBySearch, JNDIRealm assumes that the SearchResult is relative and goes
about creating a DN for the user by appending together the various bits of names
it gets back.  This is definitely wrong for absolute names which are URL's of
the form:  ldap://server/encoded_user_dn

I discovered this issue in Tomcat 5.5 and a cursory look at the SVN repo for
Tomcat 6.0 reveals that this bug is also present there.  

I have a patch for this issue which I will attach.
Comment 1 Brandon DuRette 2007-06-04 14:14:32 UTC
Created attachment 20310 [details]
My patch to fix this issue
Comment 2 Dr. Albrecht Weinert 2008-02-27 22:48:41 UTC
By the way of JNDI/Tomcat + Active Directory:

As 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), 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 seaches only one way (performance!) from 
(authenticated) users to their groups. It follows 
the quite important group-in-group relations, 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, of which
Google is full of, arised any more.

Sorry, this comment is not quite related to below
bug, bat anybody facing AD problems might as well give
ADweRealm a try. For 6.0.x, just  put 
http://www.a-weinert.de/java/catErgWe.jar
into lib, and configure accordingly:

   <!--  ADweRealm added 17.02.2008, a Realm for Active Directory      
      Special development logging can be switched on by 
       devLog="C:\Programme\Apache\Tomcat\logs\awRe.log"
      or
       devLog=" "
      which gives above as default.           
      Omit for no extra logging by de.a_weinert.realm.ADweRealm.DevLog
      
      Default attributes (can be omitted if value fits) are:
          userRoleName="memberOf" 
          userSubtree="true"
          userSearch="(sAMAccountName={0})"
          shortRoles="true"
          followRoles="true"
       -->
   <Realm name="ADsso" className="de.a_weinert.realm.ADweRealm" debug="999"
      devLog="C:\Programme\Apache\Tomcat\logs\awRe.log"
      allRolesMode="authOnly"
      
      connectionURL="ldap://193.175.115.2:389"
      alternateURL="ldap://193.175.115.4:389"
      connectionName="CN=ldap Leser,CN=Users,DC=FB3-MEVA,DC=fh-bochum,DC=de"
      connectionPassword="mauseSpatz"

      userBase="DC=FB3-MEVA,DC=fh-bochum,DC=de"
      defaultRole="fb3-meva_user"
      shortRoles="short"
    />  



 
 (what
JNDIRealm can'tlinks 
Comment 3 Mark Thomas 2009-04-28 06:42:12 UTC
This has been fixed in 6.0.x and will be included in 6.0.20 onwards.
Comment 4 Mark Thomas 2009-05-25 02:51:41 UTC
This has been fixed in 5.5.x and will be included in 5.5.28 onwards.
Comment 5 Brandon DuRette 2009-10-08 08:55:37 UTC
I looked at the changes that were made in the 6.0 branch and note that you factored the code in my patch into a method, but then failed to invoke it, so the bug still exists. This is in revision 769402. I didn't go check to see if the same mistake was made in the 5.5 branch.
Comment 6 Mark Thomas 2009-10-21 14:54:21 UTC
(In reply to comment #5)
This was corrected in a later commit for 6.0.x. 5.5.x is also fine.