Determining Mailbox Delegates

Executive Summary:

In an environment running Microsoft Exchange Server 2003 or later and Microsoft Office Outlook 2003 or later, delegates are users who have been granted permission to access another user’s mailbox or folders therein. In most situations, delegate access is configurable by the mailbox owner. Assigning delegate access requires that the delegate is connected to Exchange via Messaging API (MAPI) and resides in the same Exchange organization as the accounts to which he or she is being granted access. In Outlook, you'll find the Delegate tab under Tools, Options, as Figure 1 shows. At this point, the administrator is probably not aware of a change in mailbox folder access, although if the Application event log diagnostics logging is set to at least minimum for Information Store logons, it will log when users access other users' folders. When delegate access is granted, basic configuration information is updated in Active Directory (AD).

If an administrator wants to know to what extent delegate access is being used across an Exchange organization, he or she can use ADSI Edit to view certain user attributes in AD. If a user's mailbox has delegates, the names of the delegates will be listed in the multivalue attribute called publicDelegates. If the user is a delegate, then the mailboxes for which the user is a delegate are listed in the publicDelegatesBL attribute. Figure 2 shows the ADSI Edit attribute listing for my mailbox. The publicDelegates value shows that Kevin Miller is a delegate.

ADSI Edit isn't the best tool for querying a large number of attributes. To check all the mailboxes in the organization, you can use the Ldifde command-line utility to export the AD values queried from all mailboxes. The following sample command shows how to do so:

C:>ldifde -f delegates.txt -d "ou=users,dc=domain,dc=com" -l name,publicDelegates,publicDelegatesBL -r "(|(publicDelegates=*)(publicDelegatesBL=*))" 

In this command, -f assigns the output to the file named delegates.txt, -d isolates the organizational unit (OU) in the directory to query, -l determines which attributes to list in the output, and -r filters for objects with the attribute values you specify. Running this command took about 10 seconds on an AD with 320 objects (users and resources). Larger enterprises likely will have third-party tools, such as Quest Software's Quest Spotlight on Active Directory, for this kind of effort.

The command output will provide general information about how much delegate access is being used in the organization and can show who is a delegate and who has delegates. The following sample output shows that Kevin Miller is a delegate of William Lefkovics, as identified by the value in publicDelegates, and that William Lefkovics is a delegate of Kevin Miller, as the publicDelegatesBL attribute shows.

dn: CN=William Lefkovics,OU=Recipients,OU=Users,DC=wlkmmas,DC=orgchangetype: addpublicDelegatesBL: CN=Kevin Miller,OU=Recipients,OU=Users,DC=wlkmmas,DC=orgname: William Lefkovics

dn: CN=Kevin Miller,OU=Recipients,OU=Users,DC=wlkmmas,DC=orgchangetype: addpublicDelegates: CN=William Lefkovics,OU=Recipients,OU=Users,DC=wlkmmas,DC=orgname: Kevin Miller

The command returns only delegate use and doesn't identify folder-specific permissions granted by users. Folder-specific permissions are stored in Exchange as MAPI permissions for each folder. You can retrieve those permissions through scripting with the ACL.dll tool from the Windows software development kit (SDK) or with PFDavAdmin. The documentation accompanying PFAdmin.exe, which you'll find at http://download.microsoft.com/download/2/f/0/2f0d72e2-a97a-49b6-879a-3b405cab017e/PFDAVAdmin.EXE explains how to export mailbox permissions to a text file. The Microsoft article "How To Use ACL Object and CDO (1.21) to List Folder Permissions for a MAPI Folder" (http://support.microsoft.com/kb/240911) shows how to use the ACL.dll tool.

AD supports LDAP standards, and therefore any language or script that can assemble and call an LDAP query can access these attributes. Among these options is Windows PowerShell, which is supported on Windows 2003 SP1 or later. PowerShell uses a directory searcher class (System.DirectoryServices.DirectorySearcher) to store an LDAP filter and uses Active Directory Service Interfaces (ADSI) to query AD. The properties of this class let you determine where to start your search and what values to return. Third party PowerShell extensions are also available to make this task easier. Using PowerShell for this task will be the topic for a future tip, but in the meantime, you can see an example of using PowerShell to query AD in the article "Searching the Active Directory with PowerShell." (http://blogs.technet.com/benp/archive/2007/03/26/searching-the-active-directory-with-powershell.aspx.)