Internet Explorer Authentication

This note deals with issues surrounding the authentication of Internet Explorer in the context of Outlook and OWA in an ArtiSan installation.

Issue Resolved:

When the user clicks on a link in an Outlook message, they have to authenticate themselves again.

Background

When a user logs in to a web site, the web server and the browser establish a Session. The browser will identify itself at each new page request, so the server can be sure that it is serving pages to a browser with an authorised user. On the browser's side, the Session data is stored in what are called Session Cookies in Internet Explorer.

Sessions are maintained on a per process basis. If you open an Internet Explorer and use its menus or click a link to open a new window, the new window is part of the same process and has the same Session data.

Many programs that wish to display web-style data do it by hosting a mini-Explorer within their own windows. The ReadingPane and Inspector windows in Outlook are two relevant examples. These mini-browsers share security settings with the main Internet Explorer, but they run in different processes (Outlook), and have their own Session data.

When you click on a link in the ReadingPane and Inspector windows, what happens is that the user's default browser is launched as a new process (or if one is already running, it is directed to display the new page). The browser does not share the Session data, so the user is prompted to logon again. In fact, there there is not much that can be done about this. The trick is to use a configuration where the authentication process is invisible to the end user.

Resolution

This solution works if the user's default browser is IE5 (SP4), IE 6.0, IE 6.0 (SP1), IE 6.0 (SP2) and Netscape 7.0. It will not work with Netscape 4.8, Netscape 6.1, Netscape 7.1 and Firefox. It has been tested on the browsers mentioned above.

Both the ArtiSan and ArtiSanManager web sites authenticate the user using variants of Integrated Windows Authentication. Now, what happens during the login sequence depends on the settings for the Zone that the web server belongs to.

If you look at the Security tab of the Internet Options dialog in an Internet Explorer, you will see three zones: Trusted Site, Local Intranet and Internet (Restricted Site is for barred sites). Generally, you want to get the ArtiSan servers into the Local Intranet Zone because you can relax the security settings here.

Establish the zone

The first step is to establish which Zone is being used.

   http://webserver/ArtiSan/request_msg.asp

This should return a blank page (or, in some versions, a message indicating that the site is accessible). In the bottom right of IE (make sure the Status Bar is visible), you should see an icon that tells you which Zone the server is in.

Add the Servers to the Local Intranet Zone

During installation (or when troubleshooting) you can add the site to the Local Intranet manually on the installed server machine.

   http://webserver/ArtiSan/request_msg.asp

again. It should now show Local Intranet in the bottom right hand corner.

Larger organisations should make this change for all their desktop users by setting up a Group Policy Object at the Domain level (as this will force the server to be seen as an Intranet resource by all members of the domain).

Change the Intranet Login settings

Now, the settings for Local Intranet determine how IE reacts when it is challenged for a user name and password. (These settings can be rolled out to users under the GPO.)

There are two interesting settings in the User Authentication section at the end of the list. One is Automatic logon only in the Intranet zone and the other is Automatic logon with current username and password. I use the former under the Local Intranet Zone and the latter in the Trusted Sites Zone.

Zone Logon Setting
Local Intranet Automatic logon only in the Intranet zone
Trusted Sites Automatic logon with current username and password

Now what should happen, if you select the former is that you will not be prompted for credential information (assuming the login account is the domain account you are using to authenticate yourself). I think this is safe enough because you have already said it is a in the local intranet.

Setting up Remote Access

When it comes to using the Remote Access stuff things change a little. In v1, the remote access is achieved through a pair of web sites called the proxy site and the redirection site. The redirection site is anonymous and nothing here has any impact on that. The proxy site expects some form of login to authenticate the user. This might be basic or integrated or digest.

It is likely that the user's IE will perceive the proxy site to be on the Internet as opposed to Intranet. If this is the case, you should add the proxy site to the Trusted Sites list (if the customer's security policy permits it). The version 1 remote access does not force end-to-end permissioning.

The version 2 remote access uses a cut-down version of RAProxy, another Saxonite product. This takes the form of a combined IIS Filter and ISAPI application. As far as IE authentication is concerned, it really does not matter how the web server is set up, because RAProxy enforces end-to-end user permissioning over and above what is required by IIS and IE.

General Points

There are three further points that need to be made:

© Saxonite Limited, 2003-2006.