Hi Peter, thank you very much for this very helpful information.
Is it now possible, that tomcat checks via JNDI an ActiveDirctory GroupMembership of the detected User (e.g. SAMPLEPC\User1) I'ld try to configure, that my users do not have an login prompt in browser.... Thank you in advice -----Ursprüngliche Nachricht----- Von: peter.crowth...@googlemail.com [mailto:peter.crowth...@googlemail.com] Im Auftrag von Peter Crowther Gesendet: Dienstag, 29. September 2009 18:28 An: Tomcat Users List Betreff: Re: IIS, Tomcat, JNDI and ActiveDirectory 2009/9/29 Buchner, Joerg [T0I] (VW Sachsen) <joerg.buch...@volkswagen.de>: > But the problem is an other: > > The SourceCodes (JSP/Servlets) are secured with NTFS rights on filesystem. > (Windows Server 2003 x64) > > I've tried to secure the whole application with NTFS Rights, > but the NTFS ACL does not work for JSP Files. The NTFS permissions work just fine for JSP files, as they work for all files. However, Tomcat and IIS have different security models, so "just fine" doesn't do what you might expect :-). IIS is a native Windows application, so each thread can impersonate a user. This means that when the thread tries to open a file, the permissions that are tested are the permissions of the user that's being impersonated. Tomcat is a Java application, and has no notion of threads impersonating users - each thread runs as the same user that Tomcat starts as. This means that when the thread tries to open a file, the permissions that are tested are the permissions of the user that Tomcat started as. This is not a "feature" of the ISAPI redirector. It's a core part of any Java application - threads in Java apps cannot impersonate users. You *might* be able to get round it with some nasty JNI code that got hold of the Windows thread correspondingto the Java thread and set the impersonation, but this would be very messy to get right - particularly making sure the impersonation is reset correctly in all error cases. This means that your approach is the correct one. You'll have to do the test in your own code somehow, and obtaining the identity of the user then checking against (a cache of) the AD group memberships seems like a good way to go. Do make sure you cache it, as repeated LDAP lookups will be slow! - Peter --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
