You are confusing Windows domains with "real" domains.
When you use the "file:" protocol in your web browser URL, what you are doing, in effect, is making a local filesystem request (in this particular context, LAN shares count as local). Internally, the browser calls the OS open() function, reads the file, sends it through the browser's page formatter and renders the formatted results in the browser window. Unless of course you're running IE and the format is an external program such as Excel or PDF, where because of legal constraints an external application must be opened instead.
When you use the "http:" or "https:" protocol, an entirely different mechanism is used and the security rules are different at well. In this case, instead of a filesystem open(), a network socket pair is opened. On one of those sockets, an HTTP-formatted data stream is sent to the socket's destination port, which is a DNS domain name (NOT a Windows domain name) and a port number extracted from the URL. If no port number is explicitly given, a default port is assumed: 80 for http, 443 for https. The web server processes the request, generates an HTTP-format response output stream and sends it back to the other port that the client opened - its response port. The browser will then send the response data to the page formatter and at that point, everything is just like it was if it had come through a file.
Normally, the security system used on an Internet domain is not secured by Windows security because except in rare cases, Windows security doesn't work on the Internet, only on a LAN. You wouldn't really want it to, anyway. Your LAN security administrator would not be amused at the thought of having to create and maintain Active Directory accounts for everybody in the world that ever wanted to visit your public webservers. Especially since I run Linux, not Windows. So instead, webservers have their own security managers, usually on a per-application basis. In the case of
J2EE, that would be the container managed security Realm system unless some "clever" person had designed their app to do roll-your-own security.
Despite all these differences, it is possible to reconcile, although it's not quite a walk in the park. There is a Tomcat Realm that can hook into Windows LAN security and use it as Single Signon security, although each user's browser requires a registry tweak to use it. If you don't need Single Signon, you can also just use the LDAP realm and authenticate against Active directory.
Having said all that, however, your
real problem is not quite the same thing. Just because the client has LAN file access to a file, doesn't mean that the Tomcat server does. The Tomcat server is operating as a completely different user with its own set of security privileges, and that's even more important than whether or not it's in the same Windows Domain or not. Windows allows Domains to be friends with each other, but if the file in question doesn't have compatible access, Tomcat still cannot open it and use it, friend or not.
Finally, one last note. A web page does not usually get all its content from a single server. Each external javascript, CSS, image, and so forth has its own independent URL and is resolved by an independent request. If the client has direct file access guaranteed, you can put a "file:////server/share/path" URL in a hyperlink and the client will obtain that file directly, regardless of whether Tomcat has rights (or an access path) to it or not.