RE: JNDIRealm

[albrecht-2]

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@...>
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.

--

working config example,
part of C:\Programme\Apache\Tomcat\conf\server.xml:

   <!--  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" (or "both")
          followRoles="true"
       -->
   <Realm name="ADsso" className="de.a_weinert.realm.ADweRealm"
      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=l****,CN=Users,DC=FB3-MEVA,DC=fh-bochum,DC=de"
      connectionPassword="ld****"

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


----------------------------------------+------------------------------
|
|  Prof. Dr.-Ing. Albrecht Weinert      Fachbereich 3
|  Telefon +49 (0)234 / 32 - 10328      Elektrotechnik und Informatik
|  Hochschule Bochum
|  Lennershofstraße 140                 Labor für Medien  und
|  44801  Bochum                        verteilte Anwendungen
|
|  Startseite:  http://www.a-weinert.de
|  E-Mail:      albrecht@...   albrecht.weinert@...
|
|
----------------------------------------+------------------------------

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

[markt-2]

albrecht@... wrote:

> Brandon DuRette schrieb:
> 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)

No you didn't. You provided the javadocs and the binary but not the source.
Without the source code there is nothing comment on - hence the lack of
reaction.

If you want to contribute your realm then you'll need to provide a source
code patch to the existing Tomcat source.

Having just looked through your jar file it appears that there is more in
there than just a realm. If you have other contributions you could make
that would be great. To make them easier track please open a new bugzilla
item for each and attached the relevant source code patch.

Mark


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

[Seth Leger]

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@... 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@...>
> 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@...
For additional commands, e-mail: dev-help@...

[hgomez]

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

Regards.

2008/4/14, Seth Leger <seth.leger@...>:

> 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@... 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@...>
> > 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@...
>  For additional commands, e-mail: dev-help@...
>
>

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

[Seth Leger]

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 <seth.leger@...>:
>  
>> 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@... 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@...>
>>> 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@...
>>  For additional commands, e-mail: dev-help@...
>>
>>
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
>  

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

[hgomez]

> 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

got that

>  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.

I do some search today and debugged TC 6.0.x trunk from my eclipse.
Authentification works great and the only remaining problem it so
setup roles in AD for users.

I used :

    <Realm   className="org.apache.catalina.realm.JNDIRealm"
         connectionURL="ldap://ldap.mycorp.com:389"
         alternateURL="ldap://ldap.mycorp.com:389"
         connectionName="cn=someldapaccounttobind,ou=MyCorp
Users,dc=mycorp,dc=com"
         connectionPassword="someldapaccounttobindpassword"
           userBase="ou=MyCorp Users,dc=mycorp,dc=com"
           userSearch="(sAMAccountName={0})"
           userSubtree="true"
           referrals="follow"
           userRoleName="memberOf"
           debug="true"
           />

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

[Seth Leger]

Henri Gomez wrote:

> I do some search today and debugged TC 6.0.x trunk from my eclipse.
> Authentification works great and the only remaining problem it so
> setup roles in AD for users.
>
> I used :
>
>     <Realm   className="org.apache.catalina.realm.JNDIRealm"
>          connectionURL="ldap://ldap.mycorp.com:389"
>          alternateURL="ldap://ldap.mycorp.com:389"
>          connectionName="cn=someldapaccounttobind,ou=MyCorp
> Users,dc=mycorp,dc=com"
>          connectionPassword="someldapaccounttobindpassword"
>            userBase="ou=MyCorp Users,dc=mycorp,dc=com"
>            userSearch="(sAMAccountName={0})"
>            userSubtree="true"
>            referrals="follow"
>            userRoleName="memberOf"
>            debug="true"
>            />
>  

Yes, this use case will work with the current Tomcat 6.0.X JNDIRealm
code because your Active Directory administrator has given you search
credentials for the Active Directory server
(cn=someldapaccounttobind,ou=MyCorpUsers,dc=mycorp,dc=com/someldapaccounttobindpassword).
But not all Active Directory administrators are willing to give out a
set of credentials like this (for instance, a strict, enterprise
environment where password access is strictly controlled).

My patch removes that requirement from the JNDIRealm. Instead of relying
on a hard-coded value for authentication, it can fall back to using the
credentials being supplied to the authenticate() call to perform the
JNDI search (which will succeed because users have permissions to view
their own LDAP object instance, as far as I know this is always true).
The password is never stored; it is only transmitted at login time to
the server (and this transmission can be protected from interception
with LDAP over SSL).

It's a pretty minor change, written similarly to the way that the
current JNDIRealm code retries during connection timeouts.

Seth Leger
Sr. Software Engineer
Raritan, Inc.

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

[hgomez]

Do you have a patch against the current JNDIRealm ?

2008/4/22, Seth Leger <seth.leger@...>:

> Henri Gomez wrote:
>
> > I do some search today and debugged TC 6.0.x trunk from my eclipse.
> > Authentification works great and the only remaining problem it so
> > setup roles in AD for users.
> >
> > I used :
> >
> >    <Realm
> className="org.apache.catalina.realm.JNDIRealm"
> >         connectionURL="ldap://ldap.mycorp.com:389"
> >         alternateURL="ldap://ldap.mycorp.com:389"
> >
> connectionName="cn=someldapaccounttobind,ou=MyCorp
> > Users,dc=mycorp,dc=com"
> >
> connectionPassword="someldapaccounttobindpassword"
> >           userBase="ou=MyCorp Users,dc=mycorp,dc=com"
> >           userSearch="(sAMAccountName={0})"
> >           userSubtree="true"
> >           referrals="follow"
> >           userRoleName="memberOf"
> >           debug="true"
> >           />
> >
> >
>  Yes, this use case will work with the current Tomcat 6.0.X JNDIRealm code
> because your Active Directory administrator has given you search credentials
> for the Active Directory server
> (cn=someldapaccounttobind,ou=MyCorpUsers,dc=mycorp,dc=com/someldapaccounttobindpassword).
> But not all Active Directory administrators are willing to give out a set of
> credentials like this (for instance, a strict, enterprise environment where
> password access is strictly controlled).
>
>  My patch removes that requirement from the JNDIRealm. Instead of relying on
> a hard-coded value for authentication, it can fall back to using the
> credentials being supplied to the authenticate() call to perform the JNDI
> search (which will succeed because users have permissions to view their own
> LDAP object instance, as far as I know this is always true). The password is
> never stored; it is only transmitted at login time to the server (and this
> transmission can be protected from interception with LDAP over SSL).
>
>  It's a pretty minor change, written similarly to the way that the current
> JNDIRealm code retries during connection timeouts.
>
>  Seth Leger
>  Sr. Software Engineer
>  Raritan, Inc.
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: dev-unsubscribe@...
>  For additional commands, e-mail: dev-help@...
>
>

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

[Seth Leger]

This patch will have some offset problems because it's off of my working
copy of the JNDIRealm class. But you should be able to get the general
idea of what's going on here.

-- Seth

Henri Gomez wrote:

> Do you have a patch against the current JNDIRealm ?
>
> 2008/4/22, Seth Leger <seth.leger@...>:
>  
>> Henri Gomez wrote:
>>
>>    
>>> I do some search today and debugged TC 6.0.x trunk from my eclipse.
>>> Authentification works great and the only remaining problem it so
>>> setup roles in AD for users.
>>>
>>> I used :
>>>
>>>    <Realm
>>>      
>> className="org.apache.catalina.realm.JNDIRealm"
>>    
>>>         connectionURL="ldap://ldap.mycorp.com:389"
>>>         alternateURL="ldap://ldap.mycorp.com:389"
>>>
>>>      
>> connectionName="cn=someldapaccounttobind,ou=MyCorp
>>    
>>> Users,dc=mycorp,dc=com"
>>>
>>>      
>> connectionPassword="someldapaccounttobindpassword"
>>    
>>>           userBase="ou=MyCorp Users,dc=mycorp,dc=com"
>>>           userSearch="(sAMAccountName={0})"
>>>           userSubtree="true"
>>>           referrals="follow"
>>>           userRoleName="memberOf"
>>>           debug="true"
>>>           />
>>>
>>>
>>>      
>>  Yes, this use case will work with the current Tomcat 6.0.X JNDIRealm code
>> because your Active Directory administrator has given you search credentials
>> for the Active Directory server
>> (cn=someldapaccounttobind,ou=MyCorpUsers,dc=mycorp,dc=com/someldapaccounttobindpassword).
>> But not all Active Directory administrators are willing to give out a set of
>> credentials like this (for instance, a strict, enterprise environment where
>> password access is strictly controlled).
>>
>>  My patch removes that requirement from the JNDIRealm. Instead of relying on
>> a hard-coded value for authentication, it can fall back to using the
>> credentials being supplied to the authenticate() call to perform the JNDI
>> search (which will succeed because users have permissions to view their own
>> LDAP object instance, as far as I know this is always true). The password is
>> never stored; it is only transmitted at login time to the server (and this
>> transmission can be protected from interception with LDAP over SSL).
>>
>>  It's a pretty minor change, written similarly to the way that the current
>> JNDIRealm code retries during connection timeouts.
>>
>>  Seth Leger
>>  Sr. Software Engineer
>>  Raritan, Inc.
>>
>> ---------------------------------------------------------------------
>>  To unsubscribe, e-mail: dev-unsubscribe@...
>>  For additional commands, e-mail: dev-help@...
>>
>>
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>
>  

Index: JNDIRealm.java
===================================================================
@@ -943,7 +943,7 @@
                  curUserPattern < userPatternFormatArray.length;
                  curUserPattern++) {
                 // Retrieve user information
-                User user = getUser(context, username);
+                User user = getUser(context, username, credentials);
                 if (user != null) {
                     try {
                         // Check the user's credentials
@@ -968,7 +968,7 @@
             return null;
         } else {
             // Retrieve user information
-            User user = getUser(context, username);
+            User user = getUser(context, username, credentials);
             if (user == null)
                 return (null);
 
@@ -1001,7 +1001,7 @@
      *
      * @exception NamingException if a directory server error occurs
      */
-    protected User getUser(DirContext context, String username)
+    protected User getUser(DirContext context, String username, String credentials)
         throws NamingException {
 
         User user = null;
@@ -1017,7 +1017,7 @@
 
         // Use pattern or search for user entry
         if (userPatternFormatArray != null) {
-            user = getUserByPattern(context, username, attrIds);
+            user = getUserByPattern(context, username, credentials, attrIds);
         } else {
             user = getUserBySearch(context, username, attrIds);
         }
@@ -1041,6 +1041,7 @@
      */
     protected User getUserByPattern(DirContext context,
                                               String username,
+                                              String credentials,
                                               String[] attrIds)
         throws NamingException {
 
@@ -1056,6 +1057,32 @@
             attrs = context.getAttributes(dn, attrIds);
         } catch (NameNotFoundException e) {
             return (null);
+        } catch (NamingException e) {
+            // If the getAttributes() call fails, try it again with the
+            // credentials of the user that we're searching for
+            try {
+                // Set up security environment to bind as the user
+                context.addToEnvironment(Context.SECURITY_PRINCIPAL, dn);
+                context.addToEnvironment(Context.SECURITY_CREDENTIALS, credentials);
+
+                attrs = context.getAttributes(dn, attrIds);
+            } finally {
+                // Restore the original security environment
+                if (connectionName != null) {
+                    context.addToEnvironment(Context.SECURITY_PRINCIPAL,
+                                             connectionName);
+                } else {
+                    context.removeFromEnvironment(Context.SECURITY_PRINCIPAL);
+                }
+
+                if (connectionPassword != null) {
+                    context.addToEnvironment(Context.SECURITY_CREDENTIALS,
+                                             connectionPassword);
+                }
+                else {
+                    context.removeFromEnvironment(Context.SECURITY_CREDENTIALS);
+                }
+            }
         }
         if (attrs == null)
             return (null);
@@ -1628,7 +1655,7 @@
                                                   String username)
         throws NamingException {
         
-        User user = getUser(context, username);
+        User user = getUser(context, username, null);
         
         return new GenericPrincipal(this, user.username, user.password ,
                 getRoles(context, user));


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