Assuming the Identity of a Domain user to access Exchange via CDO

• Download source files - 0.5 Kb

Introduction

Although we all appreciate the need for security, there are times when you would like to avoid the need to login to a web page to view a public or corporate Mailbox/Calendar/Tasklist via Collaborative Data Objects (CDO). This code allows a user to assume the identity of an existing user, and avoids the NT challenge response prompt. It could also be used anywhere that it is desirable to allow for access to a resource accessible via NT authentication. This approach in effect simulates the provision of login details.

If you are not correctly logged into the Exchange Server when you attempt to access a CDO resource, you will receive the following error message:

The information store could not be opened.
[MAPI 1.0 - [MAPI_E_LOGON_FAILED(80040111)]]

Background

Outlook mailboxes are used in my organization to represent meeting rooms. We wanted to allow users to view the availability of meeting rooms from the corporate intranet. I created a simple ASP page which utilized CDO and rendered the calendar to a page, while the user passes parameters to the page to indicate the name of the room, and the date they would like to view. All as simple and straightforward as you would expect. However, because users on our corporate intranet are not authenticated via NT by default, to view the page the user would need to login to the NT challenge response. This was deemed unacceptable for a number of reasons:

• We did not want to give each user access to the mailboxes because we did not want users to be able to access the mailboxes via any other means (their own Outlook client for example).
• We did not want to create a generic login and password as this would allow users to access the calendars directly.
• We felt that user acceptance of this new facility would be inhibited by the fact that the user has to provide a login

I searched high and low to find a solution to this problem, an article I found pointed me in the right direction.......... Use ServerXMLHTTP to add a header to a request for an authenticated user, then collect the calendar and return it to a calling page. The diagram above illustrates the process.

Using the code

In order to find the value needed to pass into the header, use a HTTP sniffer such as MS Fidler to capture the header detail of a request to the page when the user usually provides a login to the page via the NT Challenge Response Prompt. You then take these details and add them to the header of the ServerXMLHTTP request, as shown below. The script is used as a proxy to return the value of the page to the calling page. The process works as follows:

1. The page in which the function sits is called.
2. The page calls the function and adds the header for the page as if the user had provided their login details.
3. The returned result is displayed.

function sendinfo()
Dim myhttp

  datatosend ="id=" & Request("id") & "&d=" & Request("d")
  Set myhttp=CreateObject("Msxml2.ServerXMLHTTP")
  myhttp.open "POST", _
    "{URL to Your page that uses CDO and requires authentication}", false
  myhttp.setRequestHeader "Authorization", _
    "Basic {your value goes here, will be Base64 Encoded eg.ttXUPPt50cmFuZXQ4ODc}"
  myhttp.setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
  myhttp.setRequestHeader "LOCAL_USER", "{the Domain Account alias you are using}"
  myhttp.send datatosend
  sendinfo = myhttp.responseText
  set  myhttp = Nothing
end function

Please note that the server you place this script on should have a copy of MSXML 3.0 installed.

Points of Interest

Be careful of mailboxes and default calendar time zones, make sure that they are all set to one type or you will begin to see some strange variances between the Outlook client and the ASP interface.