“Security trimming” – removing options the user  doesn’t have access to is a V3 thing. All you could do is remove the out of box components and replace them with your own – for everyone.

There are both PDF files and Word files in a document
library. On IE 6, Clicking a PDF file automatically
opens the file, but clicking a Word prompts a login
window. Needlessly to say, this is very anoying.

I have IE 6.0.2900 and MS Office Professional 2003
Word 2003 (11.6359.6360) SP1.

This behavior doesn't occur with Firefox.

Apparently there is something special about IE.

Does anyone know a workaround? Some ways to configure
IE or MS Office or SharePoint portal?

It looks like a simple IIS security setting can easily
fix the problem:
support.microsoft.com/default.aspx

But will this "Integrated windows authentication"
impact how Impersonation works? I have a few web parts
that need impersonation.

More importantly, if I switch to Integrated without Basic, can I then NOT use local or LDAP accounts?
And what will happen when I log in from home using my home PC (which is not a member of the domain and not using a domain account). WIll I be able to use my domain account by keying it in?

My experience is that Basic Authentication works thru proxy servers and
firewalls whereas NTLM Integrated Authentication requires some ports
that are often not open. Note that Basic Authentication passes your
credentials in plain text so you will want to implement SSL if you are
using this outside of your own network (over the Internet - like from
your home).

Not sure about Kerberos Integrated Authentication (requires SharePoint
SP2) but that may be another option  to consider.

This is what I have experienced after I changed the
setting to "Integrated Windows Authentication":
From my desktop PC, getting the Word document sails
through without re-authentication - desired behavior.
However, from the computer where the SPS server
locates, a Security Alert pops up: Revocation
information for the security certificate for this site
is not available. It then asks for re-authentication.
From the third computer, which is under the same
domain as my desktop, it also asks for
re-authentication.

The SPS server has its own active directory (a domain
controller itself). The web site  is SSL enabled  and
SSL certificate has been installed.

Same weird behavior after I changed the security
setting to Basic+Integrated.

On our production server, we have a similar setting.
The server is on its own domain and all invited users
are given accounts to the domain - not their regular
accounts under the general company domain.

Is there an easy way to solve this reauthentication
problem?

It’s not ports… some organizations make a decision not to allow NTLM through the proxy because of the potential issues related to the user’s internal network password being transmitted to a remote server. NTLM isn’t nearly as secure as SSL. The proxy looks at the outbound request and if the NTLM auth is in the request it either strips it or cancels the request entirely (depending upon the proxy server.)

I would do SSL only, Basic+NTLM because it’s secure and offers some flexibility in allowing local clients to connect without being password prompted. Plus, I’ve never seen anyone fully test all of the command line utilities to make sure that they’re OK w/ NTLM being removed.

As for Kerberos, it’s an option  but getting Kerberos setup correctly is more than most folks want to deal with right now.

(Occasionally, it comes in handy to have a former Windows Server-Networking MVP around, eh?)

There are no easy answers to this. The only reason why NTLM works is because the workstation already has the credentials. With the other domain this isn’t the case. Is there any reason why you don’t have the production domain trust the resource (user) domain?

No I haven't
try that yet. Do you think having the SPS domain trust
the user  domain will solve the problem?

As long as the user  who is logged into their workstation is on the same domain as the domain user account that is setup within sharepoint  you should not have authentication problems as long as you are using the internal name of the sharepoint site. If you goto the sharepoint site  using a fully qualified domain name (FQDN) such as sharepoint.domain.com then you will most likely have to authenticate to the site, and also authenticate multiple times opening a document library depending on your IE settings  (since it is considered a FQDN you must go to tools>>internet options>>security. Then click on Internet (because it is considered an internet address even if you are actually on your intranet if you are using sharepoint.domain.com) and click on custom level and goto the bottom. If User Authentication is not marked to automatic logon with current username and password then it will not authenticate automatically using your domain credentials on a FQDN.

Note however you should not have this option  marked on the internet. It should normally be automatic logon only in intranet zone so you are not giving out your credentials to every internet site you visit.

Therefore for automatic logon to work properly in the intranet you should not be using the FQDN (sharepoint.domain.com) but instead just http://sharepoint for example. Hope that makes sense. That should fix everything for users who are logged onto the appropriate domain in the intranet (I think you can also setup trust relationships between the domain controllers as well if you don’t want to logon to the exact domain, never tried this however).

For all users that are outside of the domain, or accessing it from the internet there is no way to avoid the multiple authentication issues on the current version of sharepoint. On the next version this will be remedied through the user of forms authentication and cookies.

The problem lies in the fact that you can not pass credentials from one application (IE) to another application (Microsoft Word/Excel, etc). The only option is to authenticate multiple times when opening/editing documents because the credentials are not passed between processes/applications (and will probably never be, because of the security issues in doing so).