I have a file share (Windows, SMB, AD) that requires authentication to access. Accessing it manually in Windows Explorer (\\ip\share) will query me for user/pass. That is fine. The client computer accessing the server share is not in the same domain as the server, and it is not an option to change that.
However using this from other users (such as IIS AppDomain user) will not work. This problem is the same as for shared folders (say image upload folder) in IIS. (Note: I need local access, it is not enough to have IIS mapped virtual folder.)
Is there any way to globally mount a share in Windows? Making it accessible for all users. Or is there any other approach to the problem?
What you're describing is anonymous access, which is about as undesirable as giving people your admin password. You really should be setting appropriate permissions for the user accounts that will be accessing the share and have the users use appropriate accounts if their own doesn't have permission.
One way: If one matches username+pass on client/server the auth would work. User can be assigned in IIS. The logged on credentials in Windows will automatically be used when accessing the share belonging to the other AD.
It solves my current problem, but it would be nice to hear if there is any way to globally mount a disk in Windows.
The work-around you identified is the only way to make that work.
As for why this won't, and can't work:
Remote authentication in Windows is done in the specific user context of the local user. When your user session maps a drive to something like M:, that drive mapping is only available in your session itself. Other accounts on the machine, such as in a Terminal Server context, do not also get an M: mapping.
In a Domain context, an individual computer can access remote services without a user, but it does so through the computer's domain account. This access is not inherited by users of that computer. Microsoft keeps authentication tokens rather firmly in user-space.
When an access is made to a remote resource that doesn't already have an associated login session, windows will supply the username and password of the accessing user in the off chance that such credentials will work on the remote system. If they don't (and sometimes even if they do, such as when the supported security protocols are different enough) it'll throw up a prompt for the user. This hand synchronized username/password method is the only way to get 'seamless' authentication in a Workgroup context without resorting to the Guest/Anonymous sharing methods.