Sunday, June 30, 2013

Exchange 2010 - Security - S/MIME. Part 1

In most cases, we send and receive email with little concern about the messages being intercepted, manipulated and read by unauthorized persons. More often than not, the nature of the content does not warrant taking significant measures to protect the message. We may just want to tell a friend "Hey, take a look at this video".
In other cases, more commonly in the business world, we may be required to address three aspects of email security:
  • Message Authentication: we want to ensure that the sender is the person they claim to be.
  • Message Integrity: we want to ensure that the message has not been manipulated in transit.
  • Message Confidentiality: we want to prevent unauthorized persons from viewing the message (and possibly associated content - essentially attachments).
We can acheive this goal with S/MIME, a standard for signing and encrypting email messages.
  • Signing an email ensures both message authentication and message integrity.
  • Encrypting an email ensures message confidentiality.
In some circumstances, we may want both: a message that is signed but not encrypted could be read by a third party.
Note: S/MIME is compatible with both Outlook and OWA in Exchange 2007 and 2010 (although with OWA, a "control" must be added). In Exchange 2013, support for S/MIME in OWA has been discontinued.
S/MIME uses certificates for signing and encrypting messages and certificates require a Public Key Infrastructure (PKI) to function. The organization wanting to use S/MIME can either install Active Directory Certificate Services (or an equivalent system) and create its own certificates or request them from a 3rd party provider such as Comodo, Digicert, GoDaddy or Verisign.
This choice does have consequences: internally issued certificates (by AD CS) will generally not be trusted outside the organization while certificates issued by a 3rd party provider will be trusted outside the organization.
So the use of S/MIME requires the following steps:
1. Creation of an appropriate certificate.
2. Distribution of the certificate to authorized users.
3. Configuration of Outlook or OWA for use of S/MIME
In this post, I'll address the first of those three steps.
Creation of an appropriate certificate
For this post, we will use AD CS to create the certificate. I have already configured the certificate authority (this pre-requisite is outside the scope of this post).
I will also assume that a custom MMC has been created with the following snap-ins:
  • Certificates (Local Computer)
  • Certificate Templates
  • Certification Authority (Local)
Note: if this custom console is not already created, it can be by entering "mmc" in the Start | Search Box and opening as administrator. Using File | Add/Remove Snap-ins, add the snap-ins mentioned above, selecting "Local" or "Local Computer" whenever there is a choice. Save the console. Call it something appropriate such as "Certificate Management" or "Certificate Authority".
Next, go to the "Certificate Templates" snap-in.
Certificate templates are not issued directly to users and computers . The certificate administrator must "duplicate" one or more of the templates for distribution to users.
Which template should we use?
The "User" template comes to mind. It can be used for:
  • Encrypting File System (EFS)
  • Secure Email
  • Client Authentication
However, I happened to read that Brian Komar, PKI expert and Microsoft MVP, does not consider that template to be the best choice and in fact recommends either "Exchange Signature Only" or "Exchange User".
Note: he even recommends a separate template for signing and encryption. "If your organization implements key archival of the e-mail cetificate, it is possible that another person could gain access to the private signing key associated with the e-mail certificate".
Komar, Brian. Windows Server 2008 PKI and Certificate Security. Microsoft Press. Remond WA, 2008.
Post started on Monday January 26th, 2009 by "Ploni Almony".

If we opt for dual certificates, this is how we could proceed:
  • For signing, we should use: Exchange signature only
  • For encryption, we should use: Exchange user

In our scenario, a single certificate seems the most appropriate. We will simply use the Exchange User template and enable both signing and encryption.
a. Right-click on "Exchange User" and select the option "Duplicate Template".
b. Select Windows 2003 Enterprise.
c. Configure properties of the new template.
There's a multitude of options here. We need to make the following changes.
General Tab
  • I'll name the certificate "S-MIME"
  • I'll leave the "Validity period" at 1 year with a "Renewal period" of 6 weeks.
  • I'll have the certificate published in Active Directory.
Request Handling tab
Since we have opted for a single certificate, we have to change the "Purpose" parameter to "Signature and Encryption". The other settings can remain as is for our scenario. In reality, they would be configured in accordance with company policy (export of private key allowed or not, for example). Minimum key size of 2048 is certainly sufficient for our scenario.
Subject Name tab
Select the option "Build from Active Directory information". If autoenrollment is used, the user does not make a (manual) request and therefore cannot "Supply in the request".
Subject Name format should be: "Fully Distingushed Name".
Check the options:
  • Include e-mail name in subject name.
I'll check the following option - although it is probably unnecessary since we checked the option above.
  • Include this information in alternate subject name: E-mail name.
Security tab
We can allow autoenrollment in which the user automatically receives a certificate without having to request one manually, usually with Internet Explorer - or force each user to request the certificate manually.
We can create (in AD DS) a specific security group and only allow members of that group to request (and be granted) the certificate in question.
In this case, I will allow autoenrollment and in a later step, activate autoenrollment using a Group Policy setting. I will allow any authenticated domain member (user) to be granted a certificate based on the "S-MIME" template.
Check the following permissions for "Authenticated Users":
  • Read (note: checked by default already)
  • Enroll
  • Autoenroll
I will not make changes under any of the other tabs. In particular, I will not configure any "Issuance Requirements" since we intend to use autoenrollment.
Click OK.
We now have a new template called "S-MIME".
We have almost finished but still have one more step.
The custom template has been created but is not available for users. In the MMC we created to manage certificates, we have to go to "Certification Authority (Local)" and expand the folder structure to the folder "Certificate Templates".
Click on this folder, select "New" and then "Certificate Template to Issue".
In the resulting window, highlight the "S-MIME" template we created earlier.
This makes the S-MIME certificate available to users.
However, although it is available, it has not been issued to anyone. We still need to configure autoenrollment (for our scenario) in conjunction with Group Policy. That will be the subject of my next post.

Saturday, June 22, 2013

Exchange 2010 - Recoverable Items Folder - Dumpster 2.0 - Single Item Recovery

In some discussions on Microsoft Technet (Exchange sections), there seemed to be some confusion about what elements are included in the size of a mailbox. Messages in the deleted items folder? What about messages in the "dumpster"? Is the dumpster part of the user's mailbox? Do messages in the dumpster count against the user's quota?

I wanted to clarify this for myself.

First, I want to review the structure of the various deleted items containers in an Exchange mailbox. This has become somewhat more complicated with the Recoverable Items folder, otherwise known as Dumpster 2.0, in Exchange 2010, and its subfolders, some of which are used only if certain features are enabled.

What subfolders? What features?

Let's take a look.

Dumpster 1.0 (Exchange 2007)

What I'll call the "deletion process" in Exchange 2007 was rather simple. This is how it worked:
  1. User deletes a message from the "Inbox" or "Sent Items" folder (etc.). The message goes to the "Deleted Items" folder. This is still part of the user's mailbox and counts against their quota.
  2. User empties the "Deleted Items" folder. The message goes to the "Dumpster". Items in this location apparently do not count against the mailbox quota (more on this below).
  3. The item remains in the Dumpster  for the duration of the retention policy configured for the mailbox database. By default, it is 14 days.

That's how it works in appearence...
In fact, the deleted items remain in the folders from which they were (in appearence) deleted. Exchange 2007 simply stamps them with the "ptagDeletedOnFlag" marker. This flag conceals the item so it is invisible in common user interfaces such as Outlook and OWA.
Therefore, one could argue that in Exchange 2007, the dumpster does not really exist! It is a sort of illusion, a virtual view of deleted messages that remain, though hidden, in the exact same folders where they were deleted.
Several comments:
  • The Exchange 2007 dumpster is not "searchable" which is a significant disadavantage for mailbox discovery and compliance.
  • Users can permanently purge items in the dumpster (if they know where to look). That too represents a disadvantage with respect to mailbox searches and compliance.
Soft Deletes and Hard Deletes

In the following sections of this post, I'll refer to different types of deletions. For clarity, let's review the difference between a "soft" delete and a "hard" delete. 

Soft delete
This is the most common type of deletion. The user selects the item and either clicks on the "black X" icon or right-clicks on the item and selects "Delete" in the menu options. They can also press the Delete key on their keyboard. No lack of choices here.
The deleted item goes to the "Deleted Items" folder. Most users can easily recover an item from this location by dragging it back to the original location or right-clicking on the item and selecting the "Move to Folder" option. Here again, they would move the item to the previous location (Inbox, Sent Items, etc.).
Hard Delete
In this case, the user selects the item, holds down the "Shift" key and then presses the "Delete" key. The item in question goes directly to the dumpster. It does NOT go to the Deleted Items folder first.

Dumpster 2.0 (Exchange 2010)

In Exchange 2010, the dumpster exists as a "non-IPM" folder, called "Recoverable Items". Each user's mailbox contains one of these "Recoverable Items" folders.

But just what is a "non-IPM" folder?

A non-IPM folder does not appear in common user interfaces like Outlook and OWA. 

It is invisible to the eyes of the end-user.
However, the "Recoverable Items" folder is a "real" folder that even includes 3 subfolders:

  • Deletions
  • Purges
  • Versions

What are these subfolders? What do they do? What must be done, if anything, to enable them?


This subfolder contains items that were deleted from the "Deleted Items" folder or hard-deleted from other folders. These items are retained, by default, for 14 days.
Users can purge items in the Deletions subfolder, just like they could for the dumpster (version 1.0) in Exchange 2007, unless... a feature called "Single Item Recovery" is enabled. In that case, users cannot purge the Deletions subfolder (or only purge it in appearence). More on that in the next section.

The "Purges" subfolder is inactive - unless "Single Item Recovery" is enabled.

If "SIR" is not enabled, deleted items simply go to the Deletions subfolder as described above and stay there until removed at the end of the retention period (14 days by default).
If "SIR" is enabled, messages removed from the Deletions subfolder (before the expiration of the retention period) are placed in the Purges subfolder until the retention period does expire.
So... what's the difference? The item in question just sits in the Purges subfolder instead of the Deletions subfolder before being eliminated anyway by the mailbox cleanup process, right?
Here's the difference. End users cannot access the Purges subfolder. Even if they empty the Deletions folder, the deleted items remain in the Purges subfolder.
But only for the duration of the (14 day by default) retention period, right?
Yes, but if legal considerations require that a company retain mail for a longer period of time, a feature called "Litigation Hold" can be enabled. When this feature is enabled, items in the Purges folder will NOT be removed at the end of the 14 day retention period and users cannot permanently delete them either, since they cannot access this "Non-IPM" subfolder.

So there's no way to right-click and delete that incriminating message!
That's the primary difference with the Exchange 2007 "Dumpster 1.0".
The Versions subfolder is used when "Single Item Recovery" or "Litigation Hold" is enabled. The deletion of a legally significant item is not the only problem an organization might face. Users could potentially modify an item without deleting it altogether.
When "Litigation Hold" is enabled, a copy of any modified item is sent to the Versions subfolder.
Note: with or without Single Item Recovery, calendar items are retained in the "Recoverable Items" subfolders for 120 days - unless... "Litigation Hold" is enabled, in which case they would be retained as long as necessary.

Questions and answers and more questions.

So the following types of questions have come up in Exchange Technet forum discussions:

  • Is the dumpster part of the mailbox?
  • Do the items in the dumpster count against the users mailbox quota?
  • What is the relationship between the cmdlet "Get-MailboxStatistics", the "TotalItemsize" parameter and the "TotalDeletedItemSize" parameter.
First of all, Microsoft documentation states that the dumpster is part of the mailbox:

"Dumpster in Exchange 2010 is implemented as a folder called the Recoverable Items and is located within the Non-IPM subtree of the user's mailbox."

Indeed, corresponding illustrations show the dumpster as part of the mailbox


Single Item Recovery in Exchange Server 2010

This was also the case with Exchange 2007, though in a different form.
On the other hand, it appears that items in the dumpster (version 1.0 or version 2.0) do not count against the user's mailbox quota.

What follows is the result of my own "experiments" on the subject. I've tested the above assumption in both Exchange 2007 (SP3) and Exchange 2010 (SP3). 

Exchange 2007

Here's the plan.

I'm going to:

  1. Delete items
  2. then delete them from the Deleted Items folder
  3. and then the dumpster...
Observing how these operations affect the size of the mailbox.

I started with this command but the output is not very readable:

[PS] C:\>Get-MailboxStatistics | fl *size*

TotalDeletedItemSize : 3 310 038B

TotalItemSize : 115 069 436B

(Yes, I added those spaces).

So let's try this instead:





Let's also consider the size of the mailbox as shown in Outlook:

Note: for some reason, there is a slight difference between 109 MB and 112 MB. However, the resolution of this enigma is outside the scope of this blog post.

1. Delete Items

Now... John Smith deletes 20 MB + of messages in Outlook. What happens to the statistics?





Nothing... no change.
Conclusion: the deleted items folder is part of the mailbox AND the items in the deleted items folder are included in the calcuation of "total item size" or total mailbox size. That was expected.

2. Empty Deleted Items folder ("trash")

Now John Smith empties the "Deleted Items" folder. What happens?





The size of the mailbox decreases while the size of the dumpster increases.

Note: "totaldeleteditemsize" measures the size of the dumpster. I'll make some clarifications on this point in my conclusion below.

When I delete items from the Deleted Items folder, the value of "TIS" decreases (87 MB versus 109 MB).

On the other hand, "TDIS" increases (25 MB versus 3 MB).

If "TDIS" was part of "TIS", those numbers would not change, just as they do not change when items are moved from the Inbox or Sent Items to the Deleted Items folder.
This seems to confirm that "totaldeleteditemsize" is not included in "totalitemsize".

So... it does appear that although the dumpster is part of the mailbox (as a virtual view of deleted items), the contents of the dumpster do NOT count against the user mailbox quota.

This is what we see in Outlook:

Total size has decreased from 112 MB (in the previous screenshot) to 89 MB.

3. Purge the Dumpster

Now what happens if we empty the dumpster?

John Smith goes to Recover Deleted Items but instead of recovering them, he highlights them all and click on the black X (Purge selected items):


What happens to the mailbox statistics?





So, purging the dumpster in Exchange 2007 affects the TDIS value but not the TIS value.

We can then conclude that "TIS" measures the size of the mailbox, all folders except the dumpster (as it exists in E2K7) and "TDIS" measures the size of the dumpster and the dumpster alone.

Exchange 2010

In the following lines, I'll reproduce the experiments above but this time with a pair of users on an Exchange 2010 server.

This is the size of the respective mailboxes before any deletions have been made:


Get-MailboxStatistics | fl *size*

TotalDeletedItemSize : 1.406 KB (1,440 bytes)
TotalItemSize        : 7.24 MB (7,591,386 bytes)

Get-MailboxStatistics | fl *size*

TotalDeletedItemSize : 0 B (0 bytes)
TotalItemSize        : 6.951 MB (7,288,535 bytes)

Note: Outlook shows 7211 KB for Aisha and 7035 KB for Alannah, not quite exactly the same as the Get-MailboxStatistics output.
1. Simple deletion of items from Inbox
Now Aisha and Alannah will delete about 6 MB of messages.
What changes?
The "Total Item Size"? Mailbox minus the dumpster?
The "Total Deleted Item Size"? Just the "Recoverable Items" folder or dumpster?

Note: remember, we are testing the assumption that the dumpster, while residing inside the user mailbox, does not count against the quota.

Get-MailboxStatistics | fl *size*

TotalDeletedItemSize : 1.406 KB (1,440 bytes)
TotalItemSize        : 7.24 MB (7,591,526 bytes)

Get-MailboxStatistics | fl *size*

TotalDeletedItemSize : 0 B (0 bytes)
TotalItemSize        : 6.951 MB (7,288,535 bytes)

OK... nothing changed.

So deleting an item and (essentially) moving it to the deleted items folder has no effect whatsoever on the two values.
2. Empty Deleted Items folder ("trash")

Now... Aisha and Alannah will empty their Deleted Items folder.

What happens?

Get-MailboxStatistics | fl *size*

TotalDeletedItemSize : 6.677 MB (7,001,758 bytes)
TotalItemSize        : 579.8 KB (593,765 bytes)

As we can see, the TIS value decreases from 7.24 MB to around 580 KB.
On the other hand, the TDIS value increases from 1.4 KB to around 6.7 MB.
What about Alannah? Does the same thing happen to her?

Get-MailboxStatistics | fl *size*

TotalDeletedItemSize : 6.627 MB (6,949,415 bytes)
TotalItemSize        : 333.7 KB (341,691 bytes)

Sure enough!

Here are the Outlook results for mailbox size (after the above operations):

Aisha: 929 KB
Alannah: 685 KB

Once again, as we saw for Exchange 2007, there is an apparent discrepancy in the value displayed by Outlook and the value produced by the Get-MailboxStatistics cmdlet.
This might be an interesting subject for another blog post but, for the time being, our test demonstrates that the items in the Recoverable Items folder do not count against the user's mailbox quota.
3. Purge Recoverable Items folder

What happens when Aisha and Alannah purge their Recoverable Items folder?
In this scenario, neither Single Item Recovery or Litigation Hold have been enabled.

Get-MailboxStatistics | fl *size*

TotalDeletedItemSize : 5.536 KB (5,669 bytes)
TotalItemSize        : 579.8 KB (593,765 bytes)

Get-MailboxStatistics | fl *size*

TotalDeletedItemSize : 4.155 KB (4,255 bytes)
TotalItemSize        : 333.7 KB (341,691 bytes)

There's nothing but some residue left - roughly 5 KB of something, perhaps metadata (there are no items displayed in any case). Reminder: "TDIS" value was previously between 6 and 7 MB.

  1. Items in the dumpster (Exchange 2007 or Exchange 2010) do NOT count against the mailbox quota.
  2. The "Get-MailboxStatistics" "TotalItemsize" parameter counts all items in the mailbox, deleted items included, but does NOT count items in the dumpster (Recoverable Items folder in Exchange 2010).
  3. The "TotalDeletedItemSize" counts all the items in the dumpster - and only those items.

General Reference:

Jagott, S. & Stidely, J., et. al. (2010). Microsoft Exchange Server 2010 - Best Practices. Remond, WA: Microsoft Press

Friday, June 14, 2013

Exchange 2010 - Discovery Mailbox - Multi-Mailbox Search

The multi-mailbox search is an Exchange 2010 feature that persons delegated with the "Discovery Mailbox" role can perform to insure compliance with various regulations or company policies.

Here are the steps we can take to grant a particular user the right to conduct a mailbox search and then access the results.
1. Create a Discovery Search Mailbox

Results can be sent to a "discovery search mailbox" for consultation by persons having access to that mailbox. One is created by default at the installation of Exchange 2010. As it has a rather cumbersome name, I'm going to create another. Multiple discovery mailboxes can exist for that matter.

New-Mailbox DiscoveryResults -Discovery -UserPrincipalName DiscoveryResults@mynet.lan


In fact, having more than one discovery mailbox allows access to be granted differently, as needed, on a case by case basis. Based on their duties, certain users will access "Discovery Search Mailbox A" while others will access "Discovery Search Mailbox B".

2. Add a user to the Mailbox Discovery role

(This was demonstrated in an earlier blog post).

3. Perform the search(es)

Navigating to the location below (in the Exchange Control Panel - ECP), the user can configure various searches:

Mail | Options: Manage My Organization | Mail Control | Discovery | Multi-Mailbox Search
Note: you access the ECP by entering the URL appropriate for your organization and then entering your logon credentials:
3.a Click on "New":
3.b Note the various options:

3.c Enter a keyword:


3.d Instead of searching the entire mailbox database, one can concentrate on specific users:

3.e And on a specific date range:

3.f All mailboxes can be searched - or a subset of mailboxes:

3.g Finally, we need to name the search and direct the results to a discovery mailbox:

We then save the search (click on "Save").

The search executes...

Once the search finishes, we can go to the discovery mailbox to view the results. In this case, the user Teresa Woods goes to her email and can view the results by opening the appropriate discovery mailbox:

We can see that the search found two instances of our keyword "confidential".
Note: Teresa cannot access the results unless:

1. She is granted access to the Discovery Mailbox:

2. She adds the mailbox to her Outlook profile:

Wednesday, June 12, 2013

Exchange 2010 - RBAC (Role Based Access Control)

Before 2010: delegation in Exchange 2007

Until Exchange 2010, delegation was rather simple and somewhat limited. Exchange 2007, for example, included only four administration groups to which one could be assigned:
Exchange Organization Administrators
These have full control over the Exchange organization.
Exchange Recipient Administrators
These can manage recipients: mailbox users, mail enabled users, contacts and distribution groups. But there's a catch: to modify Active Directory user, contact or group objects, they must also belong the the Active Directory "Account Operators" group or (preferable option when possible) have delegated control over a particular OU (organizational unit). Some might argue that "Account Operator" membership is excessive since members could modify all kinds of objects (even computer objects) and violate the principal of least power.
Exchange View-Only Administrators
As its name implies, this allows members to view the entire Exchange organization but not make changes.
Exchange Public Folder Administrators
Exchange 2010 and RBAC
Exchange 2010 implements "RBAC", a far more flexible and granular  method of assigning necessary permissions - and only necessary permissions -  to administrators and even to the point where one can create custom roles affecting only a particular property of a user.
The RBAC delegation framework also exists in Exchange 2013 and Exchange Online with Office 365. So it is a useful system to know. Now, much has already been written on the subject, from Technet articles to blogs by various Exchange MVPs. Therefore, I will not present RBAC point by point but relate some experiments I performed for myself.
For reference, however, I'm providing this link:
Role Groups, Roles and Role Entries

In Exchange 2010 there are 11 predefined "Role Groups" which include various "Roles" which in turn are composed of various "Role Entries". The Role Entries are the very specific actions that an administrator, when added to a Role Group, can perform on an object. I've listed the 11 roles below with a brief explaination:
  • Delegated Setup (install Exchange servers)
  • Discovery Management (search mailboxes for compliance reasons)
  • Help Desk (manage limited user properties - but NOT resetting passwords)
  • Hygiene Management (manage spam filtering)
  • Organization Management (includes almost all rights by default)
  • Public Folder Management
  • Recipient Management
  • Records Management (compliance features, retention, transport rules)
  • Server Management
  • UM Management (for Unified Messaging)
  • View-Only Organization Management (read-only access to the entire organization)
Better yet, roles can be customized. If the primary Exchange administrator wanted to delegate only the right to manage transport rules (and nothing else) a custom role could be created for this purpose, based on the Records Management role.
So let us demonstrate how delegates can be added to various Role Groups and thus perform various tasks based on the Roles (and in turn the Role Entries) assigned to these groups.
We first need to access the ECP (Exchange Control Panel), logged in as an Organization Administrator.
1. Enter the URL for the ECP:
2. Enter your logon credentials:
3. Go to "Manage My Organization" (if not already selected) and then "Roles & Auditing".
4. You'll see the 11 Role Groups:
5. Select "Help Desk".
Note the details. The members of the group can manage only certains aspects of a user's mailbox:
6. Now "Trevor Reece" will manage users via the ECP, once he is member of the group in question.
Note that without this status, Trevor cannot even access the ECP at all:
7. So we add Trevor to the group by double-clicking on the group and selecting his name (we can search for it as I have done here).
Click "OK" and then "Save".
Now Trevor can not only access the ECP but can access particular user properties. Let's pretend he needs to manage Teresa Wood's mailbox.
Once in the ECP, he selects the option "Another User" and opens Teresa's user properties (with a double-click) after highlighting her name:

He can edit her account information...
Organize or troubleshoot Inbox Rules or Automatic Replies...
And manage various settings, like the Show BCC or show From...
Unfortunately, the Help Desk specialist cannot change passwords via the ECP.

Will making Trevor a member of the Recipient Administrator Role Group make a difference?
In theory, "Members of this mangement role group have the rights to create, manage, and remove Exchange recipient objects..." In reality, there is no option to create a new mailbox user, although delegates can create distribution lists:
I attempted to create a custom group with the "Security Group Creation and Membership" role, thinking it might allow something necessary to happen in the background. But no luck!
It looks like the Exchange development team simply removed what seems like a fundamental feature:
Finally, let's delegate the "Discovery Management" role to someone. This role allows the delegate to search the entire mailbox database (all the mailboxes) for compliance with whatever policy may be in effect in the organization. By default, no one has this role assigned to them, not even administrators.
So, if the user has not been granted the Discovery Management role, the Mail Control | Discovery option does not even appear:
On the other hand, Teresa Woods has been granted this role. When she connects, the Discovery option is available:
This concludes my post on RBAC. I intend to follow up with a post about conducting a mailbox search once granted the Mailbox Discovery role.