Minding the E-Mail

Legal issues aside, here's one way to audit Exchange 5.5 user mailbox usage on the down-low.

• By Bill Boswell
• December 01, 2003

FYI, we modified the user's mailbox and security attributes in many ways, but no luck. What are we missing?
—Marc

Marc: Before getting into the mechanics of mailbox access, I want to make sure that you and your colleagues have discussed the legal ramifications of granting a user access to another user's mailbox. You must be certain that your organization has written policies in place specifically allowing you to do this. You may also want to consult your legal staff, especially if you're an organization that provides medical or financial services.

With that out of the way, there's two ways to accomplish the goal depending on how much you want the "Read-Only" aspect for the permission. If you don't mind giving full control access, then you can configure mailbox permissions from Active Directory Users and Computers as follows:

1. Open the Properties window for the user account.
2. Select the Exchange Advanced tab.
3. Click the Mailbox Rights button. This opens the Permissions window for the user's mailbox.
4. Click Add and select the name of the auditor to whom you want to grant access.
5. Give this user Full Mailbox Access.
6. Verify the auditor can open the user's mailbox in Outlook via File | Open | Other User's Folder.

This procedure also works if you or an IT colleague need to access a user's mailbox. Mailbox access is specifically denied for members of the Domain Admins group, Enterprise Admin group, the domain Administrator account, and any account that has been delegated Exchange Administrator or Exchange Full Administrator permissions. These permissions are set at the Organization level and inherit down to the mailbox stores. You can override the inherited Deny permission by placing a specific Allow permission at the mailbox itself in Active Directory Users and Computers. A directly applied Allow takes precedence over an inherited Deny.

Now, if you really want to keep the access as Read-Only, then you'll need to apply a change directly to the MAPI permissions for the user's Inbox. Here's a snippet of code that I blatantly stole from Microsoft Knowledge Base article 295558, "HOWTO: Add A Delegate To An Exchange Folder with the ACL Component and CDO (1.21)," with changes to make it work with VBScript rather than Visual Basic:

CONST CdoDefaultFolderCalendar = 0
CONST CdoDefaultFolderInbox = 1
CONST CdoDefaultFolderOutbox = 2
CONST CdoDefaultFolderSentItems = 3
CONST CdoDefaultFolderDeletedItems = 4
CONST CdoDefaultFolderContacts = 5
CONST CdoDefaultFolderJournal = 6
CONST CdoDefaultFolderNotes = 7
CONST CdoDefaultFolderTasks = 8
CONST CdoDefaultFolderTotal = 9

CONST ROLE_OWNER = &h5e3
CONST ROLE_PUBLISH_EDITOR = &h4e3
CONST ROLE_EDITOR = &h463
CONST ROLE_PUBLISH_AUTHOR = &h49b
CONST ROLE_AUTHOR = &h41b
CONST ROLE_NONEDITING_AUTHOR = &h413
CONST ROLE_REVIEWER = &h401
CONST ROLE_CONTRIBUTOR = &h402
CONST ROLE_NONE = &h400

' Change this to the display name of the user you want
' to give delegate access.
Const UserA = "Auditor"

'Change this to the display name of the user whose
' calendar you want to give UserA delegate access to.
Const UserB = "User"

'Change server_name to the name of your Exchange server.
strProfile = "server_name" & vbLf & UserB

' Create a new MAPI session and log on.
Set oSession = CreateObject("MAPI.Session")
oSession.Logon , , False, True, , True, strProfile

' Create a MAPI object for UserA
Set oAddrBook = oSession.AddressLists("Global Address List")
Set oDelegate = oAddrBook.AddressEntries.Item(UserA)

' Get the permission list on UserB's inbox
WScript.Echo "Adding " & UserA &
   " to the Inbox permissions for " &
   UserB & " with Reviewer settings."
Set oInbox = oSession.GetDefaultFolder(CdoDefaultFolderInbox)
Set oACLObject = CreateObject("MSExchange.ACLObject")
oACLObject.CDOItem = oInbox
Set oACEs = oACLObject.ACEs

' Add UserA to the permission list and save the result
Set oNewACE = CreateObject("MSExchange.ACE")
oNewACE.ID = oDelegate.ID
oNewACE.Rights = ROLE_REVIEWER
oACEs.Add oNewACE
oACLObject.Update
oSession.Logoff

' Indicate the process is finished.
WScript.Echo "Completed adding " & UserA &
   " to Inbox permissions for " & UserB & "."

You can write another little script to remove the entry once the auditor has finished.

Hope this helps, Marc.

Now, some sage advice from SBS users:

File Under "Boswell, Cure Your Tunnel Vision"
After last week's article describing how to upgrade a 10-user system to Windows Server 2003 and Exchange 2003, several readers immediately took me to the woodshed for neglecting to recommend Small Business Server 2003 as an option. From Craig:

I am really surprised that you did not discuss Small Business Server as a solution for a 10-person shop. Microsoft's SBS would provide the support with a more reasonable costs basis than buying Windows 2003 Server and Exchange 2003 Server with 10 clients.

Craig's absolutely right (and so were the others). Small Business Server 2003 is a fantastic bargain. The Standard Edition includes Windows Server 2003, Exchange Server 2003 and Windows SharePoint Services (WSS). The street price with five Client Access Licenses goes for less than $525. The Premium Edition includes SQL Server and ISA Firewall and goes for less than $1,400 for five CALs. Added bonus: The user limit has been raised to 75 in SBS 2003 (SBS 2000 was limited to 50). More info: http://www.microsoft.com/windowsserver2003/sbs/default.mspx

Speaking of Windows SharePoint Services Dept. ...
Last week, a security vulnerability surfaced concerning the use of Exchange 2003 Outlook Web Access (OWA) along with SharePoint. This vulnerability is documented at www.microsoft.com/exchange/support/e2k3owa.asp. Here's the introductory blurb from that article:

Microsoft has received reports of an issue affecting Exchange Server 2003 and Microsoft Office Outlook Web Access. The problem occurs when a user installs Microsoft Windows SharePoint Services 2.0 on a computer running both Exchange Server 2003 and Microsoft Windows Server 2003. The deployment causes Kerberos authentication to be disabled in Internet Information Services (IIS) and can result in incorrect handling of OWA requests to an Exchange Server.

The article goes on to describe the configuration steps that resolve this issue. If you use WSS or Small Business Server 2003, be sure to read and implement this fix.