Savoy, Melinda wrote:
Andre,
Without going into a lot of detail I was finally able to, via the help of an
IIS engineer at Microsoft via our TAM,
force NTLM authentication via IIS. What I learned is that by default
IIS is NOT setup to accept NTLM authentication
but only Kerberos. Consequently, I went thru some different commands
with the MS IIS engineer to get NTLM
on IIS to authenticate and now I am getting in the request, per the
ISAPI log, the user info I was looking for (see below).
Eureka!!
So all this time, the problem was between the browser and IIS, and
nothing to do with isapi_redirector or Tomcat.
That is basically what Rainer and I have been telling you since a long time.
As for the rest :
- the fact that you are getting something like TEXAS\user-id is normal.
The first part is the (short) domain name. That is because your LAN
could consist of several domains, and a user-id might be repeated in
different domains (like TEXAS\jsmith and INDIANA\jsmith, being different
users). Specialised Tomcat-level authentication modules like Jespa (and
I suppose Waffle) have parameters allowing you to have the domain part
stripped automatically if you so wish. But since you are not using
these modules, you'll have to do that yourself.
But beware of what I say above : really find out with your network
admins if you do indeed have a single domain where a domain-stripped
user-id is really unique; or if your network has different "trusting"
domains inside of which domain-stripped user-id's may not be unique.
- reduce the log level of isapi_redirector now, please. It is no fun
scanning through hundreds of log lines to find the significant bit.
The (only) significant bit in this case was the very first response,
which indicates a "server error 500" return code. The rest is all
retrieval of error page and links therein (images, css, etc).
- you should temporarily replace your entire webapp (including the
legacy filter) with a very simple one, which does /only/ a
getRemoteUser() and displays it as a response.
Then you will see if the fact that you do not get the user in your
webapp is an issue of your webapp, or maybe of your legacy filter
interfering.
Then re-insert the legacy filter and try again.
It is possible that the legacy filter simply resets the user-id to null
when /it/ cannot authenticate the user (and that it never checks if the
request is already authenticated to begin with).
The easiest way to disable your legacy filter is probably to temporarily
set its <filter-mapping> (in web.xml) to something that never matches.
Here follows a very simple servlet which just echoes back the userid.
I do not know anything about JSP, but I suspect that doing this with a
JSP page is much simpler. Christopher or someone ?
package scimisdev;
import java.io.IOException;
import java.io.PrintWriter;
import java.security.Principal;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
public final class DumpUser extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse
response)
throws IOException, ServletException {
String userName = request.getRemoteUser();
if (userName == null) {
userName = "*null*";
}
response.setContentType("text/plain");
PrintWriter writer = response.getWriter();
writer.println(userName);
}
}
/*
In your web.xml, include the following:
<servlet>
<servlet-name>DumpUser</servlet-name>
<servlet-class>scimisdev.DumpUser</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>DumpUser</servlet-name>
<url-pattern>*.dumpuser</url-pattern>
</servlet-mapping>
*/
and call it as http://servername/scimisdev/xxx.dumpuser
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
