Brian Pendell

Okay, I think I've solved it. It turns out I had to modify a setting in server.xml -- this was in the new file but wasn't in the old version I was copying over.


This did not work:

<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase" digest="md5" />


This DID work:

<!-- Use the LockOutRealm to prevent attempts to guess user passwords
via a brute-force attack -->
<Realm className="org.apache.catalina.realm.LockOutRealm">
<!-- This Realm uses the UserDatabase configured in the global JNDI
resources under the key "UserDatabase". Any edits
that are performed against this UserDatabase are immediately
available for use by the Realm. -->
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase" digest="md5" />
</Realm>


So I had to add "LockOutRealm" to server.xml in order to not get the error 403. Before that, I would get that error even when the roles and passwords were correct. Once added, I was able to get in.

I'll leave this open for a few days so people can comment on what happened, but the issue does appear to be resolved. I'm going to read up on LockOutRealm and associated Tomcat technology. Any comments that might prove enlightening are welcome.

Respectfully,

Brian P.

Hello, Tim, thanks for the response.

Regardless, changes in the user roles made while a user is logged in do not take effect while that user is logged in, not for any Realm. This is for security reasons, since you would otherwise be changing the wheels while the car is driving and potentially creating temporary security loopholes.

Well, yes, but these changes are made before ANY user is logged in. This all happens at installation before Tomcat is even turned on.

Also, note that when you have 2 WARs with the same name in the Tomcat webapps directory (for example, abc.war and an abc directory in exploded WAR format), that the exploded WAR will be the one used, even if the war file is newer.

Noted. However, this is not an issue. I place the .war file in webapps at installation, and it then explodes the .war file and uses the directory structure created from same. Since the two are exactly the same, discrepancies between them are not an issue, at least not on installation.

When you stop tomcat and restart it, it is possible that session information could be cached and restored when tomcat comes back up, so any time you're making changes to the web apps or security configuration and restarting Tomcat, it's a good idea to delete the files and directories under Tomcat's work and temp directories.

Okay.

So here is what I did this morning.
1) Shut down tomcat.
2) Backed up my existing tomcat-users.xml and server.xml.
3) Copied over some old copies of tomcat-users.xml and server.xml from my installer directory into TOMCAT-HOME. These were dated quite some time ago, but the content is almost identical.
4) Started tomcat and attempted to log in. Got error 403.
5) Used touch on both files and restarted. Shut down browser completely and attempted login. Still error 403.
6) Shut down tomcat. Deleted tomcat's \temp and \work directories. Restarted. Shut down browser completely and attempted login. Still error 403.

7) Restored the .xml files backed up in 2). Suddenly it starts working again.

It's almost as if Tomcat somehow tracks the original files and will start throwing error 403 if they are changed.

The realm being used is <Realm className="org.apache.catalina.realm.UserDatabaseRealm">

It may be I do not HAVE to restart tomcat when I make changes to these files, but I do so anyway. Learned reflex from MemoryRealm.

So as you can see, the puzzle is not yet solved. But thanks for your effort so far.

Respectfully,

Brian P.

So let's start with the specifics:
Tomcat 7.0.22
Windows 7 64-bit
All operations being performed with administrator privileges by the same user.
NOT using Eclipse or any other development environment. This is just Tomcat and a text file editor.

What happens: I am preparing a web application which uses Tomcat as the container to run it. So Tomcat installation is performed as part of the overall install.

As part of the install, we 1) Install Tomcat but do NOT activate the service. 2) Automatically copy over custom server.xml and tomcat-users.xml into the conf\ directory, replacing those automatically generated by Tomcat during installation. 3) NOW start Tomcat.

The new files switch the userdatabaserealm over to an MD5 digest from clear text, change the SSL port from 8443 to something else, define three new roles , and several users which have these roles.

What could possibly go wrong?

Well, the problem is that when I attempt to log into the application using the roles (the app's web.xml has these roles defined in it, and restricts access to some pages), I get error 401: Access denied.

I am a little puzzled by this. I know that the server.xml is being correctly read, because HTTPS responds on the new port, not on 8443. And I know tthat the tomcat-user is defined, because if I enter the user name and a deliberately incorrect password, the prompt tells us to try again. But when I enter the user name and the correct password, it goes directly to error 401.

Now, here's the strange thing: I CAN get this to work.

How? Simple. Cut the user names and roles out of tomcat-user.xml, save the file, paste them back in, save the file. Restart Tomcat. Presto, suddenly it works.

Well, okay, one time this DIDN'T work. I was forced to reinstall Tomcat from scratch and make the appropriate changes by hand to both tomcat-users.xml and server.xml. And then it worked.

So I can get the system working, but any good installation package should work properly out of the box, without needing me to cut lines out of the file, then paste them back in.

So what is happening here?

Is there some kind of security feature that prevents files from being copy/pasted?
Is it a permissions issue of some kind? It shouldn't be, because the user performing the operations has administrator privileges, but I can't rule it out.
Is it something to do with the timestamp?
Is Tomcat caching this information somehow? If so, can it be disabled?

Is this a problem that will disappear by upgrading to Tomcat 7.0.52? What about Tomcat 8?

Respectfully,

Brian P.

Checked. Firewall was down, so that wasn't the issue.

Eventually solved the problem by setting System.setSystemProperty("java.rmi.server.hostname" ...) directly in the body of the program. This forced the system to use the IP address I specified in that property.

Strange; I would have thought that passing -Djava.rmi.server.hostname= on the command line would have done that as well, only it didn't.

At any rate, the problem is solved.

Respectfully,

Brian P.

I have a system running Java SE 1.6U7 on Windows 2008 server. This system has several network interface communication (NIC) cards used for ethernet and TCP/IP communication . We have an RMI application that responds to clients communicating on NIC 1. The other NIC (designated NIC2 ) is on a different network.

When only NIC 1 is enabled we have no problems.

However, when NIC 2 is enabled, I get a connection refused RMI exception. Careful examination reveals the following course of events:

1) Client requests connection on <NIC 1 IP address>
2) Connection rejected on <NIC 2 IP address>

It appears that , when the server registers its service on the RMI registry, the RMI registry is recording it as being available on <NIC 2>, which of course the client can't see at all.

I have attempted to hard-code the rebind() call to NIC 1 IP address. I have also used -Djava.rmi.server.name on the command line to force that system property to NIC 1 address. Neither of these operations helped.

I note that this program has been running for years on Windows 2003 Server (equivalent to Windows XP) without a problem. Perhaps it has something to do with the fact that name resolution, especially of 'localhost', has been revised greatly between the Microsoft versions.

Which leads me to the following questions:

1) Has anyone else encountered this?
2) Will upgrading to the latest version of Java solve this problem?
3) Is there a way to configure the server WITHOUT modifying the java program to ensure that the appropriate NIC appears in the RMI registry?
4) Failing that, is there a way to programmatically force this change? As I said, I have already attempted the usual suspects without success.

Respectfully,

Brian P.

Got it to work. First, I restored the password in tomcat-users.xml back to its original state.

Next, I went into manager's web.xml file and commented out the error page entry thus:

<!-- <error-page>
<error-code>401</error-code>
<location>/401.jsp</location>
</error-page> -->


And now it works! Somehow the .JSP which processes error 401 was changing the response in some way such that the authentication wouldn't work. It was obvious what the problem was when
it was forcing the system to use Basic authentication , but I don't understand why it would continue to fail when I had modified the 401.jsp to use digest authentication.

Respectfully,

Brian P.

Okay, that was part of the answer. But we're not out of the woods yet.

Live Headers showed the following:

Expires: Wed, 31 Dec 1969 19:00:00 EST
WWW-Authenticate: Basic realm="Tomcat Manager Application"

To which I replied: "But I changed the name of the realm..."

Well, a bit of industrious grepping revealed that this is also referenced in managers 401.jsp file thus:

response.setHeader("WWW-Authenticate", "Basic realm=\"Tomcat Manager Application\"");

So I could modify the server.xml and web.xml file forever and it would do no good. I also had to correct that as well.

I did so, changing 401.jsp to

response.setHeader("WWW-Authenticate", "DIGEST realm=\"TESTING\"");

This resulted in the following header going across:

Authorization: Digest username="pendell", realm="TESTING", nonce="", uri="/manager/html", response="6a453b0f0dbc4f0351b225e0e2aa4add"

So we are now doing DIGEST authorization, but the hash response sent is not the hash stored in the file.

Deciding to be tricky, I grabbed the "response" above and pasted it directly into tomcat-users as follows:

<user username="pendell" password="6a453b0f0dbc4f0351b225e0e2aa4add" roles="manager"/>

On the assumption that if the response matched the hash in the password table, I would be able to get through. But that didn't work either -- still getting denied access.

Respectfully,

Brian P.

Tim Moores wrote:Does the browser support DIGEST authentication? Is it sending a DIGEST authentication header wit the correct password hash?

Something like the Firefox extension LiveHTTPHeaders can help you with debugging that.

I'll find out. I'm using IE 8.0.6001.18702 and Firefox 3.6.23. I can't imagine them *not* supporting DIGEST authentication but I suppose it's not impossible.

Respectfully,

Brian P.

For my own growth, I am attempting a very simple exercise: To implement digest authentication for tomcat's manager app, the better to apply the lessons to production code.

So I have modified the server set up as follows:

server.xml:

<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="UserDatabase" digest="md5" />


I then modify manager's web.xml as follows:

<!-- Define the Login Configuration for this Application -->
<login-config>
<auth-method>DIGEST</auth-method>
<realm-name>TESTING</realm-name>
<!-- <realm-name>Tomcat Manager Application</realm-name> -->
</login-config>

Next, I generate an MD5 password of the following form:

C:\apache-tomcat-6.0.26\bin>digest -a MD5 pendell:TESTING:password
pendell:TESTING:password:3e62d753e47e1278a74c0d7565dbb254

and plug it into tomcat-users.xml as follows:

<role rolename="manager"/>
<user username="pendell" password="3e62d753e47e1278a74c0d7565dbb254" roles="manager"/>

This doesn't work. I get an error 401 -- invalid access -- when I attempt to log onto the page.

I must be doing something wrong, but internet research has failed to turn up the answer.

Again, I am using apache 6.0.26. Is this a known issue? Does the problem go away in version 7?

Respectfully,

Brian P.