Java Mailing List Archive

http://www.junlu.com/

Home » users-digest.tomcat »

users Digest 14 Mar 2013 14:55:18 -0000 Issue 11295

users-digest-help

2013-03-14


Author LoginPost Reply

users Digest 14 Mar 2013 14:55:18 -0000 Issue 11295

Topics (messages 240354 through 240376)

Caching of resources in META-INF/resources folder
 240354 by: Martin Grigorov
 240355 by: Martin Grigorov

Re: JNDI property roleSearchAsUser not working as expected
 240356 by: Felix Schumacher

Re: Can Tomcat 8 snapshots be published to Maven?
 240357 by: Mark Thomas
 240361 by: Martin Grigorov
 240363 by: Nick Williams

Re: tomcat 6.0.35 in production maintaince
 240358 by: fachhoch
 240367 by: fachhoch
 240368 by: Daniel Mikusa
 240370 by: fachhoch
 240372 by: Daniel Mikusa
 240374 by: David kerber
 240375 by: Hassan Schroeder

Re: Running a binary program from a JSP
 240359 by: Daniel Mikusa

Re: AJP suddenly Stopps acting: ajp on 7009 and 9009 : connections keept open
 240360 by: André Warnier
 240364 by: David Kumar

RE:JNDI property roleSearchAsUser not working as expected
 240362 by: Eugène Adell
 240365 by: Felix Schumacher

RE:RE:JNDI property roleSearchAsUser not working as expected
 240366 by: Eugène Adell
 240371 by: Felix Schumacher

RE:tomcat 6.0.35 in production maintaince
 240369 by: Eugène Adell
 240373 by: Eugène Adell

RE:RE:RE:JNDI property roleSearchAsUser not working as expected
 240376 by: Eugène Adell

Administrivia:

---------------------------------------------------------------------
To post to the list, e-mail: users@(protected)
To unsubscribe, e-mail: users-digest-unsubscribe@(protected)
For additional commands, e-mail: users-digest-help@(protected)

----------------------------------------------------------------------


Attachment: users_240354.eml (zipped)
Hi,

I'm experiencing troubles with updating CSS/JS resources in
META-INF/resources during development.
My application is a multi module Maven project. Some of the 'jar' modules
(i.e. the ones that are packed in WEB-INF/lib/**) have META-INF/resources
with some CSS/JS files inside.

Deploying the project in Tomcat 7.0.37 in the IDE (Intellij IDEA) as
"exploded-war" allows me to edit my .java files and the resources which end
in the context root (in Maven terminology - src/main/webapp) then do
"update classes and resources" in the IDE and I can see my changes in the
browser.

Unfortunately this doesn't work for META-INF/resources (Servlet 3.0)
because it seems Tomcat very aggressively caches these resources.
I've stepped with the debugger thru various **DirContext implementations
and I see that the lastModificationTime is cached in JNDI Attributes and
the file content itself
in org.apache.naming.resources.Resource#binaryContent.

Am I correct to assume that there is no way to archive the short
development cycle with META-INF/resources ?

Thanks
Martin

Attachment: users_240355.eml (zipped)
On Thu, Mar 14, 2013 at 10:43 AM, Martin Grigorov <mgrigorov@(protected):

> Hi,
>
> I'm experiencing troubles with updating CSS/JS resources in
> META-INF/resources during development.
> My application is a multi module Maven project. Some of the 'jar' modules
> (i.e. the ones that are packed in WEB-INF/lib/**) have META-INF/resources
> with some CSS/JS files inside.
>
> Deploying the project in Tomcat 7.0.37 in the IDE (Intellij IDEA) as
> "exploded-war" allows me to edit my .java files and the resources which end
> in the context root (in Maven terminology - src/main/webapp) then do
> "update classes and resources" in the IDE and I can see my changes in the
> browser.
>
> Unfortunately this doesn't work for META-INF/resources (Servlet 3.0)
> because it seems Tomcat very aggressively caches these resources.
> I've stepped with the debugger thru various **DirContext implementations
> and I see that the lastModificationTime is cached in JNDI Attributes and
> the file content itself
> in org.apache.naming.resources.Resource#binaryContent.
>
> Am I correct to assume that there is no way to archive the short
> development cycle with META-INF/resources ?
>
> Thanks
> Martin
>

I just realized that the IDE does the update of the resources and a quick
search led me to http://youtrack.jetbrains.com/issue/IDEA-72577
I'm not sure how they do this for the resources in the context root but I
guess they use some Tomcat internal APIs, or reflection to clean the caches.
If you think you know how this may be improved please comment in this
ticket.

Thank you!

--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>

Attachment: users_240356.eml (zipped)
Am 13.03.2013 21:46, schrieb Eugène Adell:
> Hello
>
> I am running the following :
>  java version "1.6.0_25"
>  Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
>  Java HotSpot(TM) Client VM (build 20.0-b11, mixed mode, sharing)
>  Tomcat 7.0.37
>  CentOS release 6.3
>
> with this REALM configuration in server.xml :
>                 <Realm
> className="org.apache.catalina.realm.JNDIRealm"
>                  connectionURL="ldap://***.***.***.***:389"
>                  
> userPattern="cn={0},ou=users,dc=example,dc=com"
>                  roleBase="ou=groups,dc=example,dc=com"
>                  roleSubtree="true"
>                  roleNested="true"
>                  roleName="cn"
>                  roleSearchAsUser="true"
>                  roleSearch="(uniqueMember={0})" />
>
> and this triggers this error during the startup :
> Mar 13, 2013 8:14:49 PM org.apache.catalina.realm.JNDIRealm open
> WARNING: Exception performing authentication
> javax.naming.AuthenticationNotSupportedException: [LDAP: error code
> 48 - anonymous bind disallowed]
>      at com.sun.jndi.ldap.LdapCtx.mapErrorCode (LdapCtx.java:3032)
>      at
> com.sun.jndi.ldap.LdapCtx.processReturnCode (LdapCtx.java:2987)
>      at
> com.sun.jndi.ldap.LdapCtx.processReturnCode (LdapCtx.java:2789)
>      at com.sun.jndi.ldap.LdapCtx.connect (LdapCtx.java:2703)
>      at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:293)
>      at
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURL (LdapCtxFactory.java:175)
>      at
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs (LdapCtxFactory.java:193)
>      at
> com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance (LdapCtxFactory.java:136)
>      at
> com.sun.jndi.ldap.LdapCtxFactory.getInitialContext (LdapCtxFactory.java:66)
>      at
> javax.naming.spi.NamingManager.getInitialContext (NamingManager.java:667)
>      at
> javax.naming.InitialContext.getDefaultInitCtx (InitialContext.java:288)
>      at javax.naming.InitialContext.init (InitialContext.java:223)
>      at javax.naming.InitialContext.<init>(InitialContext.java:197)
>      at
> javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:82)
>      at
> org.apache.catalina.realm.JNDIRealm.open (JNDIRealm.java:2150)
>      at
> org.apache.catalina.realm.JNDIRealm.startInternal (JNDIRealm.java:2241)
...
>      ... 27 more
> Mar 13, 2013 8:14:49 PM org.apache.catalina.startup.Catalina start
> INFO: Server startup in 34 ms
>
>
> From what I understand, roleSearchAsUser property was designed for
> people who need to bind on any LDAP where anonymous bind is not
> authorized. But it's just impossible to do this if the JNDI Realm
> tries to authenticate anonymously by itself during the startup.

I read the docs as follows:

If your directory server does not allow to scan for roles as anonymous
user and you don't want to configure a technical user (by specifying
connectionName and connectionPassword) you can delegate the credentials
of the user that is currently logging in.

It is not intended to set the user credentials for all ldap operations.

The easiest way to fix it, is to setup an technical user inside your
directory, which has no right other than to login and lookup your users,
which would be the next operation.

Regards
Felix
>
> I suppose it's necessary to investigate further this bug :
> https://issues.apache.org/bugzilla/show_bug.cgi?id=19444
>
>
> Thanks
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)


Attachment: users_240357.eml (zipped)
>https://repository.apache.org/content/repositories/snapshots/org/apache/tomcat/
>>
>> Mark
>
>Sweet! Thanks! So will I need to add https://repository.apache.org/ as
>a custom repository in my POM, or will Maven Central eventually pick up
>the change?

I thought central did pick these up but a re-read of the docs says not.

Mark


Attachment: users_240361.eml (zipped)
On Thu, Mar 14, 2013 at 12:49 PM, Mark Thomas <markt@(protected):

> >
> https://repository.apache.org/content/repositories/snapshots/org/apache/tomcat/
> >>
> >> Mark
> >
> >Sweet! Thanks! So will I need to add https://repository.apache.org/ as
> >a custom repository in my POM, or will Maven Central eventually pick up
> >the change?
>

Yes, you will need to add this repository to your pom.xml.

See
https://github.com/apache/wicket/blob/master/archetypes/quickstart/src/main/resources/archetype-resources/pom.xml#L173
This is the pom.xml we use for Apache Wicket archetype for -SNAPSHOT
versions.

When Tomcat developer release the modules they will go to
https://repository.apache.org/content/repositories/RELEASES/org/apache/tomcat/<https://repository.apache.org/content/repositories/releases/org/apache/tomcat/>
and this will be sync-ed to Maven central repository.


>
> I thought central did pick these up but a re-read of the docs says not.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>
>


--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com <http://jweekend.com/>

Attachment: users_240363.eml (zipped)

On Mar 14, 2013, at 7:25 AM, Martin Grigorov wrote:

> On Thu, Mar 14, 2013 at 12:49 PM, Mark Thomas <markt@(protected):
>
>>>
>> https://repository.apache.org/content/repositories/snapshots/org/apache/tomcat/
>>>>
>>>> Mark
>>>
>>> Sweet! Thanks! So will I need to add https://repository.apache.org/ as
>>> a custom repository in my POM, or will Maven Central eventually pick up
>>> the change?
>>
>
> Yes, you will need to add this repository to your pom.xml.
>
> See
> https://github.com/apache/wicket/blob/master/archetypes/quickstart/src/main/resources/archetype-resources/pom.xml#L173
> This is the pom.xml we use for Apache Wicket archetype for -SNAPSHOT
> versions.
>
> When Tomcat developer release the modules they will go to
> https://repository.apache.org/content/repositories/RELEASES/org/apache/tomcat/<https://repository.apache.org/content/repositories/releases/org/apache/tomcat/>
> and this will be sync-ed to Maven central repository.
>
>
>>
>> I thought central did pick these up but a re-read of the docs says not.
>>
>> Mark

Yea, I figured out after sending this email that I just needed the following in my POM:

  <repositories>
    <repository>
       <id>apache-snapshots</id>
       <name>Apache Snapshots Repository</name>
       <url>https://repository.apache.org/content/repositories/snapshots</url>
       <layout>default</layout>
       <snapshots>
          <enabled>true</enabled>
       </snapshots>
    </repository>
  </repositories>

Attachment: users_240358.eml (zipped)
I added all my jsp  with <%@(protected)
is increasing , is there any session listner which will debug all session
creation  ,time ,ipaddress etc and session destroy  atleast I can see
where the session are coming from.




--
Sent from the Tomcat - User mailing list archive at Nabble.com.


Attachment: users_240367.eml (zipped)
every few seconds a new session is begin created from an ipaddress , I have
no clue who owns that ipaddress , how can I find more about that
ipaddress?





--
Sent from the Tomcat - User mailing list archive at Nabble.com.


Attachment: users_240368.eml (zipped)
On Mar 14, 2013, at 10:13 AM, fachhoch wrote:

> every few seconds a new session is begin created from an ipaddress , I have
> no clue who owns that ipaddress , how can I find more about that
> ipaddress?
>

Block it and see who complains that they can no longer access your server?

Dan

>
>
>
>
> --
> View this message in context: http://tomcat.10.n6.nabble.com/tomcat-6-0-35-in-production-maintaince-tp4995740p4995895.html
> Sent from the Tomcat - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)


Attachment: users_240370.eml (zipped)
how can I block it , can I do it from my app or server setting or  os
setting , please advice me .



--
Sent from the Tomcat - User mailing list archive at Nabble.com.


Attachment: users_240372.eml (zipped)
On Mar 14, 2013, at 10:27 AM, fachhoch wrote:

> how can I block it , can I do it from my app or server setting or  os
> setting , please advice me .

If your OS has a firewall, you could use that. Otherwise, you can configure a Remote Address Filter in Tomcat. Configuration of the filter is pretty simple, but if you need an example you should be able to find one on Google pretty quickly.

https://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Remote_Address_Filter

Dan


>
>
>
> --
> View this message in context: http://tomcat.10.n6.nabble.com/tomcat-6-0-35-in-production-maintaince-tp4995740p4995898.html
> Sent from the Tomcat - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)


Attachment: users_240374.eml (zipped)
On 3/14/2013 10:27 AM, fachhoch wrote:
> how can I block it , can I do it from my app or server setting or  os
> setting , please advice me .

Firewall or OS-level.


>
>
>
> --
> View this message in context: http://tomcat.10.n6.nabble.com/tomcat-6-0-35-in-production-maintaince-tp4995740p4995898.html
> Sent from the Tomcat - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>
>



Attachment: users_240375.eml (zipped)
On Thu, Mar 14, 2013 at 7:39 AM, Daniel Mikusa <dmikusa@(protected):

>> how can I block it

> If your OS has a firewall, you could use that.

If you're on a *nix system, see the man page for 'iptables' and/or
'tcp_wrappers'.

--
Hassan Schroeder ------------------------ hassan.schroeder@(protected)
http://about.me/hassanschroeder
twitter: @hassan


Attachment: users_240359.eml (zipped)
On Mar 14, 2013, at 12:34 AM, Tim Gross wrote:

> Hi,
>
> I want to know if it is possible to execute a binary program (written in C)
> from within a JSP.

Yes.

> I would like to do this on the server side, not the
> browser, in Tomcat6. If it is possible, can somebody provide an example.

Use...

http://docs.oracle.com/javase/6/docs/api/java/lang/Runtime.html

or

http://docs.oracle.com/javase/6/docs/api/java/lang/ProcessBuilder.html

Google can give you examples.

Dan

> Sorry if I am using the wrong mailing list. Feel free to redirect me if
> that is the case.
>
> Thanks,
>
> Tim.
>
>
>


Attachment: users_240360.eml (zipped)
David Kumar wrote:
> Hey,
>
> I'm using:
>
> lsof -u tomcat
>

example of "netstat" output on one of our own systems right now :

1) first one

vovm1:~# netstat -t -pan | grep -v ESTAB
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address       Foreign Address      State
PID/Program name
tcp     0    0 0.0.0.0:32032       0.0.0.0:*          LISTEN    2999/usbsrvd
tcp     0    0 0.0.0.0:20224       0.0.0.0:*          LISTEN    2965/inetd
tcp     0    0 0.0.0.0:11022       0.0.0.0:*          LISTEN    9179/perl
tcp     0    0 127.0.0.1:111       0.0.0.0:*          LISTEN    2172/portmap
tcp     0    0 0.0.0.0:54321       0.0.0.0:*          LISTEN    18279/python
tcp     0    0 0.0.0.0:4949        0.0.0.0:*          LISTEN
23225/munin-node
tcp     0    0 0.0.0.0:22         0.0.0.0:*          LISTEN    2431/sshd
tcp     0    0 0.0.0.0:23         0.0.0.0:*          LISTEN    2965/inetd
tcp     0    0 0.0.0.0:43961       0.0.0.0:*          LISTEN    -
tcp     0    0 192.168.20.43:25     0.0.0.0:*          LISTEN    2946/exim4
tcp     0    0 127.0.0.1:25        0.0.0.0:*          LISTEN    2946/exim4
tcp     0    0 0.0.0.0:11002       0.0.0.0:*          LISTEN    2965/inetd
tcp     0    0 0.0.0.0:46911       0.0.0.0:*          LISTEN    2183/rpc.statd
tcp     0    0 127.0.0.1:11002      127.0.0.1:40739      TIME_WAIT  -
tcp     0    0 127.0.0.1:11002      127.0.0.1:40735      TIME_WAIT  -
tcp     0    0 127.0.0.1:11002      127.0.0.1:40728      TIME_WAIT  -
tcp     0    0 127.0.0.1:11002      127.0.0.1:40724      TIME_WAIT  -
tcp     1    0 127.0.0.1:54321      127.0.0.1:37916      CLOSE_WAIT 18279/python
tcp     0    0 127.0.0.1:43797      127.0.0.1:8009       TIME_WAIT  -
tcp     0    0 192.168.20.43:56603   192.168.20.80:111     TIME_WAIT  -
tcp6     0    0 :::8009           :::*             LISTEN    9206/jsvc
tcp6     0    0 :::80             :::*             LISTEN    10730/apache2
tcp6     0    0 :::8180           :::*             LISTEN    9206/jsvc
tcp6     0    0 :::22             :::*             LISTEN    2431/sshd
tcp6     0    0 :::11100           :::*             LISTEN    9133/java
tcp6     0    0 :::11101           :::*             LISTEN    9160/java
tcp6     0    0 127.0.0.1:11100      127.0.0.1:38143      TIME_WAIT  -
tcp6     0    0 127.0.0.1:40725      127.0.0.1:11002      TIME_WAIT  -
tcp6     0    0 127.0.0.1:11101      127.0.0.1:54664      TIME_WAIT  -
tcp6     1    0 127.0.0.1:8009       127.0.0.1:35156      CLOSE_WAIT 9206/jsvc
tcp6     0    0 212.85.38.148:80     62.99.208.50:49516    TIME_WAIT  -
tcp6     0    0 212.85.38.148:80     62.155.235.89:50654   TIME_WAIT  -
tcp6     0    0 127.0.0.1:11101      127.0.0.1:54649      TIME_WAIT  -
tcp6     1    0 127.0.0.1:8009       127.0.0.1:33159      CLOSE_WAIT 9206/jsvc
tcp6     1    0 127.0.0.1:8009       127.0.0.1:60682      CLOSE_WAIT 9206/jsvc
tcp6     1    0 127.0.0.1:8009       127.0.0.1:33138      CLOSE_WAIT 9206/jsvc
tcp6     0    0 127.0.0.1:40743      127.0.0.1:11002      TIME_WAIT  -
tcp6     0    0 127.0.0.1:40733      127.0.0.1:11002      TIME_WAIT  -
tcp6     0    0 127.0.0.1:40740      127.0.0.1:11002      TIME_WAIT  -
tcp6     0    0 127.0.0.1:11100      127.0.0.1:38136      TIME_WAIT  -
tcp6     0    0 127.0.0.1:11101      127.0.0.1:54656      TIME_WAIT  -
tcp6     0    0 127.0.0.1:11101      127.0.0.1:54652      TIME_WAIT  -
tcp6     0    0 127.0.0.1:11100      127.0.0.1:50778      TIME_WAIT  -
tcp6     0    0 127.0.0.1:40732      127.0.0.1:11002      TIME_WAIT  -
tcp6     0    0 127.0.0.1:40742      127.0.0.1:11002      TIME_WAIT  -
tcp6     0    0 127.0.0.1:11101      127.0.0.1:54667      TIME_WAIT  -
tcp6     0    0 127.0.0.1:40729      127.0.0.1:11002      TIME_WAIT  -
tcp6     0    0 127.0.0.1:40736      127.0.0.1:11002      TIME_WAIT  -
tcp6     0    0 127.0.0.1:11100      127.0.0.1:38140      TIME_WAIT  -
vovm1:~#

(The "grep -v ESTAB" is to eliminate the "ESTABLISHED" connections, which are maybe
irrelevant here).

The "jsvc" process here is the wrapper which wraps the JVM and Tomcat to allow them to use
ports below 1024 and still run as non-root. For practical purposes, consider it as "tomcat".

As you can see, there are some AJP connections (local port 8009) in the CLOSE_WAIT state
also. It is a normal state of a TCP connection.
What is less normal, is that they would remain in that state for a long time. That means
that one of the sides of the TCP connection is not doing what it should do.

In my experience, under Linux, this can become a problem if you have hundreds of these.
At some point, the TCP stack becomes unresponsive and does not allow any new connection.

Sometimes, it can happen because the "client" side in the connection (the one who
initially creates the connection to a server's "listening" socket), discards a Java object
which contains an open low-level OS socket object with a connection still open, without
explicitly "closing" this connection first.
The discarded (and unreachable) Java object is then still sitting in the heap for a while,
and only a GC will actually destroy it and as a side-effect close the underlying connection.

That is why I was asking you to force a GC, to see if this made your CLOSE_WAIT
connections disappear. Apparently in your case it doesn't, which mean that yours is
another case.

Now, instead of restarting Tomcat or doing a GC, have you tried to restart Apache ?
or maybe just do a /etc/init.d/apache2 reload. That may kill off and restart the Apache
children processes, and clean up their mod_jk connections to Tomcat.



Attachment: users_240364.eml (zipped)
Hey André,


André Warnier wrote:

>The "jsvc" process here is the wrapper which wraps the JVM and Tomcat to >allow them to use
>orts below 1024 and still run as non-root. For practical purposes,
>consider it as "tomcat".
>
>As you can see, there are some AJP connections (local port 8009) in the >CLOSE_WAIT state
>also. It is a normal state of a TCP connection.
>What is less normal, is that they would remain in that state for a long >time. That means
>that one of the sides of the TCP connection is not doing what it should do.
>
>In my experience, under Linux, this can become a problem if you have >hundreds of these.
>At some point, the TCP stack becomes unresponsive and does not allow any >new connection.
>
>Sometimes, it can happen because the "client" side in the connection (the >one who
>initially creates the connection to a server's "listening" socket), >discards a Java object
>which contains an open low-level OS socket object with a connection still >open, without
>explicitly "closing" this connection first.
>The discarded (and unreachable) Java object is then still sitting in the >heap for a while,
>and only a GC will actually destroy it and as a side-effect close the >underlying connection.
>
>That is why I was asking you to force a GC, to see if this made your >CLOSE_WAIT
>connections disappear. Apparently in your case it doesn't, which mean that >yours is
>another case.
>
>Now, instead of restarting Tomcat or doing a GC, have you tried to restart >Apache ?
>or maybe just do a /etc/init.d/apache2 reload. That may kill off and >restart the Apache
>children processes, and clean up their mod_jk connections to Tomcat.

I tried to just restart the Apache, didn't work. As suggested I tried to use the option -DisableReuse. That did make our situation a lot more horrible instead of days / week we it took just minutes to shut all AJP ports down.



Mit freundlichen Grüßen
David Kumar
Softwareentwickler, B. Sc.
Abteilung Infotech - Interaktiv
TELESTAR-DIGITAL GmbH
Am Weiher 14
D-56766 Ulmen

http://www.telestar.de/


Attachment: users_240362.eml (zipped)

This doc is self-contradictory because it suggests "to setup a technical user" when we "don't want to configure a technical user", and it doesn't give any solution when we are not the admin of the directory.

Here we learn that Tomcat JNDI Realm only works in "Administrator Login Mode" with an administrator login/password (in fact the "technical user" discussed above) :

http://tomcat.apache.org/tomcat-7.0-doc/funcspecs/fs-jndi-realm.html

From this, it seems that roleSearchAsUser is only usefull when the anonymous bind is allowed. It's another contradiction here, because it seems logical to use this parameter especially when anonymous is not allowed.



________________________________________
De : Felix Schumacher [felix.schumacher@(protected)]
Envoyé : jeudi 14 mars 2013 12:03
À : Tomcat Users List
Objet : Re: JNDI property roleSearchAsUser not working as expected

Am 13.03.2013 21:46, schrieb Eugène Adell:
> Hello
>
> I am running the following :
>  java version "1.6.0_25"
>  Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
>  Java HotSpot(TM) Client VM (build 20.0-b11, mixed mode, sharing)
>  Tomcat 7.0.37
>  CentOS release 6.3
>
> with this REALM configuration in server.xml :
>                 <Realm
> className="org.apache.catalina.realm.JNDIRealm"
>                  connectionURL="ldap://***.***.***.***:389"
>
> userPattern="cn={0},ou=users,dc=example,dc=com"
>                  roleBase="ou=groups,dc=example,dc=com"
>                  roleSubtree="true"
>                  roleNested="true"
>                  roleName="cn"
>                  roleSearchAsUser="true"
>                  roleSearch="(uniqueMember={0})" />
>
> and this triggers this error during the startup :
> Mar 13, 2013 8:14:49 PM org.apache.catalina.realm.JNDIRealm open
> WARNING: Exception performing authentication
> javax.naming.AuthenticationNotSupportedException: [LDAP: error code
> 48 - anonymous bind disallowed]
>      at com.sun.jndi.ldap.LdapCtx.mapErrorCode (LdapCtx.java:3032)
>      at
> com.sun.jndi.ldap.LdapCtx.processReturnCode (LdapCtx.java:2987)
>      at
> com.sun.jndi.ldap.LdapCtx.processReturnCode (LdapCtx.java:2789)
>      at com.sun.jndi.ldap.LdapCtx.connect (LdapCtx.java:2703)
>      at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:293)
>      at
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURL (LdapCtxFactory.java:175)
>      at
> com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs (LdapCtxFactory.java:193)
>      at
> com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance (LdapCtxFactory.java:136)
>      at
> com.sun.jndi.ldap.LdapCtxFactory.getInitialContext (LdapCtxFactory.java:66)
>      at
> javax.naming.spi.NamingManager.getInitialContext (NamingManager.java:667)
>      at
> javax.naming.InitialContext.getDefaultInitCtx (InitialContext.java:288)
>      at javax.naming.InitialContext.init (InitialContext.java:223)
>      at javax.naming.InitialContext.<init>(InitialContext.java:197)
>      at
> javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:82)
>      at
> org.apache.catalina.realm.JNDIRealm.open (JNDIRealm.java:2150)
>      at
> org.apache.catalina.realm.JNDIRealm.startInternal (JNDIRealm.java:2241)
...
>      ... 27 more
> Mar 13, 2013 8:14:49 PM org.apache.catalina.startup.Catalina start
> INFO: Server startup in 34 ms
>
>
> From what I understand, roleSearchAsUser property was designed for
> people who need to bind on any LDAP where anonymous bind is not
> authorized. But it's just impossible to do this if the JNDI Realm
> tries to authenticate anonymously by itself during the startup.

I read the docs as follows:

If your directory server does not allow to scan for roles as anonymous
user and you don't want to configure a technical user (by specifying
connectionName and connectionPassword) you can delegate the credentials
of the user that is currently logging in.

It is not intended to set the user credentials for all ldap operations.

The easiest way to fix it, is to setup an technical user inside your
directory, which has no right other than to login and lookup your users,
which would be the next operation.

Regards
Felix
>
> I suppose it's necessary to investigate further this bug :
> https://issues.apache.org/bugzilla/show_bug.cgi?id=19444
>
>
> Thanks
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)





Attachment: users_240365.eml (zipped)
Am 14.03.2013 13:40, schrieb Eugène Adell:
> This doc is self-contradictory because it suggests "to setup a
> technical user" when we "don't want to configure a technical user",
> and it doesn't give any solution when we are not the admin of the
> directory.

I can't read that out of the docs for roleSearchAsUser as stated on
http://tomcat.apache.org/tomcat-7.0-doc/config/realm.html#JNDI_Directory_Realm_-_org.apache.catalina.realm.JNDIRealm

It is just a mechanism to switch from the credentials when searching
for roles.

That way you can restrict the rights to the anonymous/admin user, so
that it doesn't need to be able to lookup groups/roles for a user.

>
> Here we learn that Tomcat JNDI Realm only works in "Administrator
> Login Mode" with an administrator login/password (in fact the
> "technical user" discussed above) :
>
> http://tomcat.apache.org/tomcat-7.0-doc/funcspecs/fs-jndi-realm.html

I believe the "Administrator Login Mode" is used for retrieving
attributes out of an users object and comparing the values to some given
credentials. The "User Login Mode" is used when a bind is performed to
check the credentials. But either way, you will have to setup a
technical user, or open the directory server to allow anonymous binds
and searches for the user dn's.

>
> From this, it seems that roleSearchAsUser is only usefull when the
> anonymous bind is allowed. It's another contradiction here, because it
> seems logical to use this parameter especially when anonymous is not
> allowed.

You will not get to the point where the role is being searched, since
before that there are two points, where your directory is being
accessed.
1. initial test of connection (which you reported in your first mail)
2. look up of the user, which wants to login (and since the username
to bind with is not known, it will be hard to guess)

So as stated before the easiest thing is to just use a technical user
to connect to the directory.

Regards
Felix
>
>
>
> ________________________________________
> De : Felix Schumacher [felix.schumacher@(protected)]
> Envoyé : jeudi 14 mars 2013 12:03
> À : Tomcat Users List
> Objet : Re: JNDI property roleSearchAsUser not working as expected
>
> Am 13.03.2013 21:46, schrieb Eugène Adell:
>> Hello
>>
>> I am running the following :
>>  java version "1.6.0_25"
>>  Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
>>  Java HotSpot(TM) Client VM (build 20.0-b11, mixed mode, sharing)
>>  Tomcat 7.0.37
>>  CentOS release 6.3
>>
>> with this REALM configuration in server.xml :
>>                 <Realm
>> className="org.apache.catalina.realm.JNDIRealm"
>>                  connectionURL="ldap://***.***.***.***:389"
>>
>> userPattern="cn={0},ou=users,dc=example,dc=com"
>>                  roleBase="ou=groups,dc=example,dc=com"
>>                  roleSubtree="true"
>>                  roleNested="true"
>>                  roleName="cn"
>>                  roleSearchAsUser="true"
>>                  roleSearch="(uniqueMember={0})" />
>>
>> and this triggers this error during the startup :
>> Mar 13, 2013 8:14:49 PM org.apache.catalina.realm.JNDIRealm open
>> WARNING: Exception performing authentication
>> javax.naming.AuthenticationNotSupportedException: [LDAP: error code
>> 48 - anonymous bind disallowed]
>>      at com.sun.jndi.ldap.LdapCtx.mapErrorCode (LdapCtx.java:3032)
>>      at
>> com.sun.jndi.ldap.LdapCtx.processReturnCode (LdapCtx.java:2987)
>>      at
>> com.sun.jndi.ldap.LdapCtx.processReturnCode (LdapCtx.java:2789)
>>      at com.sun.jndi.ldap.LdapCtx.connect (LdapCtx.java:2703)
>>      at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:293)
>>      at
>> com.sun.jndi.ldap.LdapCtxFactory.getUsingURL (LdapCtxFactory.java:175)
>>      at
>> com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs (LdapCtxFactory.java:193)
>>      at
>> com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance (LdapCtxFactory.java:136)
>>      at
>> com.sun.jndi.ldap.LdapCtxFactory.getInitialContext (LdapCtxFactory.java:66)
>>      at
>> javax.naming.spi.NamingManager.getInitialContext (NamingManager.java:667)
>>      at
>> javax.naming.InitialContext.getDefaultInitCtx (InitialContext.java:288)
>>      at javax.naming.InitialContext.init (InitialContext.java:223)
>>      at
>> javax.naming.InitialContext.<init>(InitialContext.java:197)
>>      at
>> javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:82)
>>      at
>> org.apache.catalina.realm.JNDIRealm.open (JNDIRealm.java:2150)
>>      at
>> org.apache.catalina.realm.JNDIRealm.startInternal (JNDIRealm.java:2241)
> ...
>>      ... 27 more
>> Mar 13, 2013 8:14:49 PM org.apache.catalina.startup.Catalina start
>> INFO: Server startup in 34 ms
>>
>>
>> From what I understand, roleSearchAsUser property was designed for
>> people who need to bind on any LDAP where anonymous bind is not
>> authorized. But it's just impossible to do this if the JNDI Realm
>> tries to authenticate anonymously by itself during the startup.
>
> I read the docs as follows:
>
> If your directory server does not allow to scan for roles as anonymous
> user and you don't want to configure a technical user (by specifying
> connectionName and connectionPassword) you can delegate the
> credentials
> of the user that is currently logging in.
>
> It is not intended to set the user credentials for all ldap
> operations.
>
> The easiest way to fix it, is to setup an technical user inside your
> directory, which has no right other than to login and lookup your
> users,
> which would be the next operation.
>
> Regards
>  Felix
>>
>> I suppose it's necessary to investigate further this bug :
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=19444
>>
>>
>> Thanks
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@(protected)
>> For additional commands, e-mail: users-help@(protected)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)


Attachment: users_240366.eml (zipped)

Thanks Felix,

I will choose the easy way by allowing the anonymous to bind the directory, against all security logics, and strengthen the ACL to forbid anonymous search.

Anyway, the bug 19444 is closed saying the new parameter (introduced in 7.0.9 and corrected in 7.0.30) allows role searching with the authenticating user. That's true, but we still need either the anonymous or a technical user for the startup binding. It's not really compliant to real-life LDAP management.

best regards



________________________________________
De : Felix Schumacher [felix.schumacher@(protected)]
Envoyé : jeudi 14 mars 2013 14:22
À : Tomcat Users List
Objet : RE:JNDI property roleSearchAsUser not working as expected

Am 14.03.2013 13:40, schrieb Eugène Adell:
> This doc is self-contradictory because it suggests "to setup a
> technical user" when we "don't want to configure a technical user",
> and it doesn't give any solution when we are not the admin of the
> directory.

I can't read that out of the docs for roleSearchAsUser as stated on
http://tomcat.apache.org/tomcat-7.0-doc/config/realm.html#JNDI_Directory_Realm_-_org.apache.catalina.realm.JNDIRealm

It is just a mechanism to switch from the credentials when searching
for roles.

That way you can restrict the rights to the anonymous/admin user, so
that it doesn't need to be able to lookup groups/roles for a user.

>
> Here we learn that Tomcat JNDI Realm only works in "Administrator
> Login Mode" with an administrator login/password (in fact the
> "technical user" discussed above) :
>
> http://tomcat.apache.org/tomcat-7.0-doc/funcspecs/fs-jndi-realm.html

I believe the "Administrator Login Mode" is used for retrieving
attributes out of an users object and comparing the values to some given
credentials. The "User Login Mode" is used when a bind is performed to
check the credentials. But either way, you will have to setup a
technical user, or open the directory server to allow anonymous binds
and searches for the user dn's.

>
> From this, it seems that roleSearchAsUser is only usefull when the
> anonymous bind is allowed. It's another contradiction here, because it
> seems logical to use this parameter especially when anonymous is not
> allowed.

You will not get to the point where the role is being searched, since
before that there are two points, where your directory is being
accessed.
1. initial test of connection (which you reported in your first mail)
2. look up of the user, which wants to login (and since the username
to bind with is not known, it will be hard to guess)

So as stated before the easiest thing is to just use a technical user
to connect to the directory.

Regards
Felix
>
>
>
> ________________________________________
> De : Felix Schumacher [felix.schumacher@(protected)]
> Envoyé : jeudi 14 mars 2013 12:03
> À : Tomcat Users List
> Objet : Re: JNDI property roleSearchAsUser not working as expected
>
> Am 13.03.2013 21:46, schrieb Eugène Adell:
>> Hello
>>
>> I am running the following :
>>  java version "1.6.0_25"
>>  Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
>>  Java HotSpot(TM) Client VM (build 20.0-b11, mixed mode, sharing)
>>  Tomcat 7.0.37
>>  CentOS release 6.3
>>
>> with this REALM configuration in server.xml :
>>                 <Realm
>> className="org.apache.catalina.realm.JNDIRealm"
>>                  connectionURL="ldap://***.***.***.***:389"
>>
>> userPattern="cn={0},ou=users,dc=example,dc=com"
>>                  roleBase="ou=groups,dc=example,dc=com"
>>                  roleSubtree="true"
>>                  roleNested="true"
>>                  roleName="cn"
>>                  roleSearchAsUser="true"
>>                  roleSearch="(uniqueMember={0})" />
>>
>> and this triggers this error during the startup :
>> Mar 13, 2013 8:14:49 PM org.apache.catalina.realm.JNDIRealm open
>> WARNING: Exception performing authentication
>> javax.naming.AuthenticationNotSupportedException: [LDAP: error code
>> 48 - anonymous bind disallowed]
>>      at com.sun.jndi.ldap.LdapCtx.mapErrorCode (LdapCtx.java:3032)
>>      at
>> com.sun.jndi.ldap.LdapCtx.processReturnCode (LdapCtx.java:2987)
>>      at
>> com.sun.jndi.ldap.LdapCtx.processReturnCode (LdapCtx.java:2789)
>>      at com.sun.jndi.ldap.LdapCtx.connect (LdapCtx.java:2703)
>>      at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:293)
>>      at
>> com.sun.jndi.ldap.LdapCtxFactory.getUsingURL (LdapCtxFactory.java:175)
>>      at
>> com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs (LdapCtxFactory.java:193)
>>      at
>> com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance (LdapCtxFactory.java:136)
>>      at
>> com.sun.jndi.ldap.LdapCtxFactory.getInitialContext (LdapCtxFactory.java:66)
>>      at
>> javax.naming.spi.NamingManager.getInitialContext (NamingManager.java:667)
>>      at
>> javax.naming.InitialContext.getDefaultInitCtx (InitialContext.java:288)
>>      at javax.naming.InitialContext.init (InitialContext.java:223)
>>      at
>> javax.naming.InitialContext.<init>(InitialContext.java:197)
>>      at
>> javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:82)
>>      at
>> org.apache.catalina.realm.JNDIRealm.open (JNDIRealm.java:2150)
>>      at
>> org.apache.catalina.realm.JNDIRealm.startInternal (JNDIRealm.java:2241)
> ...
>>      ... 27 more
>> Mar 13, 2013 8:14:49 PM org.apache.catalina.startup.Catalina start
>> INFO: Server startup in 34 ms
>>
>>
>> From what I understand, roleSearchAsUser property was designed for
>> people who need to bind on any LDAP where anonymous bind is not
>> authorized. But it's just impossible to do this if the JNDI Realm
>> tries to authenticate anonymously by itself during the startup.
>
> I read the docs as follows:
>
> If your directory server does not allow to scan for roles as anonymous
> user and you don't want to configure a technical user (by specifying
> connectionName and connectionPassword) you can delegate the
> credentials
> of the user that is currently logging in.
>
> It is not intended to set the user credentials for all ldap
> operations.
>
> The easiest way to fix it, is to setup an technical user inside your
> directory, which has no right other than to login and lookup your
> users,
> which would be the next operation.
>
> Regards
>  Felix
>>
>> I suppose it's necessary to investigate further this bug :
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=19444
>>
>>
>> Thanks
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@(protected)
>> For additional commands, e-mail: users-help@(protected)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)





Attachment: users_240371.eml (zipped)


"Eugène Adell" <Eugene.Adell@(protected):

>
>Thanks Felix,
>
>I will choose the easy way by allowing the anonymous to bind the
>directory, against all security logics, and strengthen the ACL to
>forbid anonymous search.
>
>Anyway, the bug 19444 is closed saying the new parameter (introduced in
>7.0.9 and corrected in 7.0.30) allows role searching with the
>authenticating user. That's true, but we still need either the
>anonymous or a technical user for the startup binding. It's not really
>compliant to real-life LDAP management.
>

I still wonder, why you are so reluctant to use a technical user. Especially since you have security concerns about the anonymous user.

Regards
Felix

>best regards
>
>
>
>________________________________________
>De : Felix Schumacher [felix.schumacher@(protected)]
>Envoyé : jeudi 14 mars 2013 14:22
>À : Tomcat Users List
>Objet : RE:JNDI property roleSearchAsUser not working as expected
>
>Am 14.03.2013 13:40, schrieb Eugène Adell:
>> This doc is self-contradictory because it suggests "to setup a
>> technical user" when we "don't want to configure a technical user",
>> and it doesn't give any solution when we are not the admin of the
>> directory.
>
>I can't read that out of the docs for roleSearchAsUser as stated on
>http://tomcat.apache.org/tomcat-7.0-doc/config/realm.html#JNDI_Directory_Realm_-_org.apache.catalina.realm.JNDIRealm
>
>It is just a mechanism to switch from the credentials when searching
>for roles.
>
>That way you can restrict the rights to the anonymous/admin user, so
>that it doesn't need to be able to lookup groups/roles for a user.
>
>>
>> Here we learn that Tomcat JNDI Realm only works in "Administrator
>> Login Mode" with an administrator login/password (in fact the
>> "technical user" discussed above) :
>>
>> http://tomcat.apache.org/tomcat-7.0-doc/funcspecs/fs-jndi-realm.html
>
>I believe the "Administrator Login Mode" is used for retrieving
>attributes out of an users object and comparing the values to some
>given
>credentials. The "User Login Mode" is used when a bind is performed to
>check the credentials. But either way, you will have to setup a
>technical user, or open the directory server to allow anonymous binds
>and searches for the user dn's.
>
>>
>> From this, it seems that roleSearchAsUser is only usefull when the
>> anonymous bind is allowed. It's another contradiction here, because
>it
>> seems logical to use this parameter especially when anonymous is not
>> allowed.
>
>You will not get to the point where the role is being searched, since
>before that there are two points, where your directory is being
>accessed.
> 1. initial test of connection (which you reported in your first mail)
> 2. look up of the user, which wants to login (and since the username
>to bind with is not known, it will be hard to guess)
>
>So as stated before the easiest thing is to just use a technical user
>to connect to the directory.
>
>Regards
> Felix
>>
>>
>>
>> ________________________________________
>> De : Felix Schumacher [felix.schumacher@(protected)]
>> Envoyé : jeudi 14 mars 2013 12:03
>> À : Tomcat Users List
>> Objet : Re: JNDI property roleSearchAsUser not working as expected
>>
>> Am 13.03.2013 21:46, schrieb Eugène Adell:
>>> Hello
>>>
>>> I am running the following :
>>>  java version "1.6.0_25"
>>>  Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
>>>  Java HotSpot(TM) Client VM (build 20.0-b11, mixed mode, sharing)
>>>  Tomcat 7.0.37
>>>  CentOS release 6.3
>>>
>>> with this REALM configuration in server.xml :
>>>                 <Realm
>>> className="org.apache.catalina.realm.JNDIRealm"
>>>                  connectionURL="ldap://***.***.***.***:389"
>>>
>>> userPattern="cn={0},ou=users,dc=example,dc=com"
>>>                  roleBase="ou=groups,dc=example,dc=com"
>>>                  roleSubtree="true"
>>>                  roleNested="true"
>>>                  roleName="cn"
>>>                  roleSearchAsUser="true"
>>>                  roleSearch="(uniqueMember={0})" />
>>>
>>> and this triggers this error during the startup :
>>> Mar 13, 2013 8:14:49 PM org.apache.catalina.realm.JNDIRealm open
>>> WARNING: Exception performing authentication
>>> javax.naming.AuthenticationNotSupportedException: [LDAP: error code
>>> 48 - anonymous bind disallowed]
>>>      at com.sun.jndi.ldap.LdapCtx.mapErrorCode (LdapCtx.java:3032)
>>>      at
>>> com.sun.jndi.ldap.LdapCtx.processReturnCode (LdapCtx.java:2987)
>>>      at
>>> com.sun.jndi.ldap.LdapCtx.processReturnCode (LdapCtx.java:2789)
>>>      at com.sun.jndi.ldap.LdapCtx.connect (LdapCtx.java:2703)
>>>      at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:293)
>>>      at
>>>
>com.sun.jndi.ldap.LdapCtxFactory.getUsingURL (LdapCtxFactory.java:175)
>>>      at
>>>
>com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs (LdapCtxFactory.java:193)
>>>      at
>>>
>com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance (LdapCtxFactory.java:136)
>>>      at
>>>
>com.sun.jndi.ldap.LdapCtxFactory.getInitialContext (LdapCtxFactory.java:66)
>>>      at
>>>
>javax.naming.spi.NamingManager.getInitialContext (NamingManager.java:667)
>>>      at
>>>
>javax.naming.InitialContext.getDefaultInitCtx (InitialContext.java:288)
>>>      at javax.naming.InitialContext.init (InitialContext.java:223)
>>>      at
>>> javax.naming.InitialContext.<init>(InitialContext.java:197)
>>>      at
>>>
>javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:82)
>>>      at
>>> org.apache.catalina.realm.JNDIRealm.open (JNDIRealm.java:2150)
>>>      at
>>>
>org.apache.catalina.realm.JNDIRealm.startInternal (JNDIRealm.java:2241)
>> ...
>>>      ... 27 more
>>> Mar 13, 2013 8:14:49 PM org.apache.catalina.startup.Catalina start
>>> INFO: Server startup in 34 ms
>>>
>>>
>>> From what I understand, roleSearchAsUser property was designed for
>>> people who need to bind on any LDAP where anonymous bind is not
>>> authorized. But it's just impossible to do this if the JNDI Realm
>>> tries to authenticate anonymously by itself during the startup.
>>
>> I read the docs as follows:
>>
>> If your directory server does not allow to scan for roles as
>anonymous
>> user and you don't want to configure a technical user (by specifying
>> connectionName and connectionPassword) you can delegate the
>> credentials
>> of the user that is currently logging in.
>>
>> It is not intended to set the user credentials for all ldap
>> operations.
>>
>> The easiest way to fix it, is to setup an technical user inside your
>> directory, which has no right other than to login and lookup your
>> users,
>> which would be the next operation.
>>
>> Regards
>>  Felix
>>>
>>> I suppose it's necessary to investigate further this bug :
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=19444
>>>
>>>
>>> Thanks
>>>
>>>
>---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@(protected)
>>> For additional commands, e-mail: users-help@(protected)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@(protected)
>> For additional commands, e-mail: users-help@(protected)
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@(protected)
>> For additional commands, e-mail: users-help@(protected)
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@(protected)
>For additional commands, e-mail: users-help@(protected)
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@(protected)
>For additional commands, e-mail: users-help@(protected)




Attachment: users_240369.eml (zipped)

Maybe a monitoring tool (NAGIOS/PATROL/..) which is checking if the site is available ?
________________________________________
De : fachhoch [fachhoch@(protected)]
Envoyé : jeudi 14 mars 2013 15:13
À : users@(protected)
Objet : Re: tomcat 6.0.35 in production maintaince

every few seconds a new session is begin created from an ipaddress , I have
no clue who owns that ipaddress , how can I find more about that
ipaddress?





--
Sent from the Tomcat - User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)





Attachment: users_240373.eml (zipped)

Sure,

you can block any IP by configuring a VALVE in the main config file (server.xml) :

http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html#Remote_Address_Filter


Or if you are running Linux, you can configure the IPTABLES. This one is more expensive to do.

________________________________________
De : fachhoch [fachhoch@(protected)]
Envoyé : jeudi 14 mars 2013 15:27
À : users@(protected)
Objet : Re: tomcat 6.0.35 in production maintaince

how can I block it , can I do it from my app or server setting or  os
setting , please advice me .



--
Sent from the Tomcat - User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)





Attachment: users_240376.eml (zipped)

>I still wonder, why you are so reluctant to use a technical user. Especially since you have security concerns about the anonymous user.

To find someone's roles, LDAP only requires a bind + a search in groups. It is a simple ldapsearch command for the ones using command lines.
But when connecting through Tomcat we also need extra either one more account or allowing anonymous bind. This is not logical to add extra work to anything which could stay simple.

About security, we can ask any user to change its password on a monthly or quarterly basis. The technical account should be under the same security control with expiring passwords and it is not good practice to stop client applications especially when there are many, or in production environment. The anonymous bind is free from such problem, and it's not much worse than a password stored in a config file.



________________________________________
De : Felix Schumacher [felix.schumacher@(protected)]
Envoyé : jeudi 14 mars 2013 15:28
À : Tomcat Users List
Objet : RE:RE:JNDI property roleSearchAsUser not working as expected

"Eugène Adell" <Eugene.Adell@(protected):

>
>Thanks Felix,
>
>I will choose the easy way by allowing the anonymous to bind the
>directory, against all security logics, and strengthen the ACL to
>forbid anonymous search.
>
>Anyway, the bug 19444 is closed saying the new parameter (introduced in
>7.0.9 and corrected in 7.0.30) allows role searching with the
>authenticating user. That's true, but we still need either the
>anonymous or a technical user for the startup binding. It's not really
>compliant to real-life LDAP management.
>

I still wonder, why you are so reluctant to use a technical user. Especially since you have security concerns about the anonymous user.

Regards
Felix

>best regards
>
>
>
>________________________________________
>De : Felix Schumacher [felix.schumacher@(protected)]
>Envoyé : jeudi 14 mars 2013 14:22
>À : Tomcat Users List
>Objet : RE:JNDI property roleSearchAsUser not working as expected
>
>Am 14.03.2013 13:40, schrieb Eugène Adell:
>> This doc is self-contradictory because it suggests "to setup a
>> technical user" when we "don't want to configure a technical user",
>> and it doesn't give any solution when we are not the admin of the
>> directory.
>
>I can't read that out of the docs for roleSearchAsUser as stated on
>http://tomcat.apache.org/tomcat-7.0-doc/config/realm.html#JNDI_Directory_Realm_-_org.apache.catalina.realm.JNDIRealm
>
>It is just a mechanism to switch from the credentials when searching
>for roles.
>
>That way you can restrict the rights to the anonymous/admin user, so
>that it doesn't need to be able to lookup groups/roles for a user.
>
>>
>> Here we learn that Tomcat JNDI Realm only works in "Administrator
>> Login Mode" with an administrator login/password (in fact the
>> "technical user" discussed above) :
>>
>> http://tomcat.apache.org/tomcat-7.0-doc/funcspecs/fs-jndi-realm.html
>
>I believe the "Administrator Login Mode" is used for retrieving
>attributes out of an users object and comparing the values to some
>given
>credentials. The "User Login Mode" is used when a bind is performed to
>check the credentials. But either way, you will have to setup a
>technical user, or open the directory server to allow anonymous binds
>and searches for the user dn's.
>
>>
>> From this, it seems that roleSearchAsUser is only usefull when the
>> anonymous bind is allowed. It's another contradiction here, because
>it
>> seems logical to use this parameter especially when anonymous is not
>> allowed.
>
>You will not get to the point where the role is being searched, since
>before that there are two points, where your directory is being
>accessed.
> 1. initial test of connection (which you reported in your first mail)
> 2. look up of the user, which wants to login (and since the username
>to bind with is not known, it will be hard to guess)
>
>So as stated before the easiest thing is to just use a technical user
>to connect to the directory.
>
>Regards
> Felix
>>
>>
>>
>> ________________________________________
>> De : Felix Schumacher [felix.schumacher@(protected)]
>> Envoyé : jeudi 14 mars 2013 12:03
>> À : Tomcat Users List
>> Objet : Re: JNDI property roleSearchAsUser not working as expected
>>
>> Am 13.03.2013 21:46, schrieb Eugène Adell:
>>> Hello
>>>
>>> I am running the following :
>>>  java version "1.6.0_25"
>>>  Java(TM) SE Runtime Environment (build 1.6.0_25-b06)
>>>  Java HotSpot(TM) Client VM (build 20.0-b11, mixed mode, sharing)
>>>  Tomcat 7.0.37
>>>  CentOS release 6.3
>>>
>>> with this REALM configuration in server.xml :
>>>                 <Realm
>>> className="org.apache.catalina.realm.JNDIRealm"
>>>                  connectionURL="ldap://***.***.***.***:389"
>>>
>>> userPattern="cn={0},ou=users,dc=example,dc=com"
>>>                  roleBase="ou=groups,dc=example,dc=com"
>>>                  roleSubtree="true"
>>>                  roleNested="true"
>>>                  roleName="cn"
>>>                  roleSearchAsUser="true"
>>>                  roleSearch="(uniqueMember={0})" />
>>>
>>> and this triggers this error during the startup :
>>> Mar 13, 2013 8:14:49 PM org.apache.catalina.realm.JNDIRealm open
>>> WARNING: Exception performing authentication
>>> javax.naming.AuthenticationNotSupportedException: [LDAP: error code
>>> 48 - anonymous bind disallowed]
>>>      at com.sun.jndi.ldap.LdapCtx.mapErrorCode (LdapCtx.java:3032)
>>>      at
>>> com.sun.jndi.ldap.LdapCtx.processReturnCode (LdapCtx.java:2987)
>>>      at
>>> com.sun.jndi.ldap.LdapCtx.processReturnCode (LdapCtx.java:2789)
>>>      at com.sun.jndi.ldap.LdapCtx.connect (LdapCtx.java:2703)
>>>      at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:293)
>>>      at
>>>
>com.sun.jndi.ldap.LdapCtxFactory.getUsingURL (LdapCtxFactory.java:175)
>>>      at
>>>
>com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs (LdapCtxFactory.java:193)
>>>      at
>>>
>com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance (LdapCtxFactory.java:136)
>>>      at
>>>
>com.sun.jndi.ldap.LdapCtxFactory.getInitialContext (LdapCtxFactory.java:66)
>>>      at
>>>
>javax.naming.spi.NamingManager.getInitialContext (NamingManager.java:667)
>>>      at
>>>
>javax.naming.InitialContext.getDefaultInitCtx (InitialContext.java:288)
>>>      at javax.naming.InitialContext.init (InitialContext.java:223)
>>>      at
>>> javax.naming.InitialContext.<init>(InitialContext.java:197)
>>>      at
>>>
>javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:82)
>>>      at
>>> org.apache.catalina.realm.JNDIRealm.open (JNDIRealm.java:2150)
>>>      at
>>>
>org.apache.catalina.realm.JNDIRealm.startInternal (JNDIRealm.java:2241)
>> ...
>>>      ... 27 more
>>> Mar 13, 2013 8:14:49 PM org.apache.catalina.startup.Catalina start
>>> INFO: Server startup in 34 ms
>>>
>>>
>>> From what I understand, roleSearchAsUser property was designed for
>>> people who need to bind on any LDAP where anonymous bind is not
>>> authorized. But it's just impossible to do this if the JNDI Realm
>>> tries to authenticate anonymously by itself during the startup.
>>
>> I read the docs as follows:
>>
>> If your directory server does not allow to scan for roles as
>anonymous
>> user and you don't want to configure a technical user (by specifying
>> connectionName and connectionPassword) you can delegate the
>> credentials
>> of the user that is currently logging in.
>>
>> It is not intended to set the user credentials for all ldap
>> operations.
>>
>> The easiest way to fix it, is to setup an technical user inside your
>> directory, which has no right other than to login and lookup your
>> users,
>> which would be the next operation.
>>
>> Regards
>>  Felix
>>>
>>> I suppose it's necessary to investigate further this bug :
>>> https://issues.apache.org/bugzilla/show_bug.cgi?id=19444
>>>
>>>
>>> Thanks
>>>
>>>
>---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@(protected)
>>> For additional commands, e-mail: users-help@(protected)
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@(protected)
>> For additional commands, e-mail: users-help@(protected)
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@(protected)
>> For additional commands, e-mail: users-help@(protected)
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@(protected)
>For additional commands, e-mail: users-help@(protected)
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@(protected)
>For additional commands, e-mail: users-help@(protected)



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)




©2008 junlu.com - Jax Systems, LLC, U.S.A.