Enabling Legal Hold on Exchange 2010

How do you enable legal hold on a mailbox?

Pretty simple, right?  There are multiple ways to do it as can be seen here:  Place a Mailbox on Legal Hold

Is there another way to do this?

However, if for some reason you cannot use any of these common methods, then that means you need to understand what happens behind the scenes when any of these methods are performed.

In my case, I wanted the ability to:

1. write directly to the attribute(s) using a third party provisioning tool instead of  the common methods previously mentioned
2. have more control on what values are written to the attributes

What now?

I pulled out the handy freeware tool, adfind, created by Joe Richards and did an LDIF export for a sample mailbox before and after enabling legal hold.   Voila!

The LDIF diff showed that the following attributes are modified:

• msexchELCMailboxFlags

Like the useraccountcontrol attribute, this attribute is a bitwise enumeration of various flags that indicate where certain mailbox features are enabled or disabled.  One of the features that are stored in this this attribute is whether legal hold is enabled or not. The 4th bit in this attribute, counting from the right, toggles legal hold on (1) or off(0).  A little bit more information here:  msexchELCMailboxflags

When you enable legal hold using 1 of the common methods mentioned above, it sets bit 4 to 1.

• msexchLitigationHoldOwner

This attribute contains the name of the administrator who enabled legal hold.   From what I could discern, this takes the cn value of the user or account used to enable legal hold, by default.  However, you can write your own custom value in this attribute.

• msexchLitigationHoldDate

This attribute contains the timestamp when legal hold was enabled.  The timestamp is stored in UTC format (Zulu time).  Again, this is automatically populated when you enable legal hold the usual way.

Putting it all together

Of these three attributes, only msexchELCMailboxFlags is mandatory.  However, when you enable legal hold in the usual manner, the 2 other fields are automatically populated for you.

As for me, here is how I did implemented the legal hold process:

• First, check if legal hold is already enabled

Do a bitwise AND comparison between msexchELCMailboxFlags value and 8 (decimal representation of 1000).

• Enable legal hold if needed

Perform a bitwise OR comparison between msexchELCMailboxFlags value and 8 (decimal representation of 1000) and write the result to msexchELCMailboxFlags

• Write value to msexchLitigationHoldOwner

You can write any string value to this attribute. You can customize this value as you like.  My recommendation is to write the value to make searches/filtering for legal hold reports more efficient.

• Write timestamp to msexchLitigationHoldDate

Get the timestamp and write it to the msexchLitigationHoldDate

That’s it folks!

Useful Utilities

This is  a living document thet will list useful tools

Meeting/Videoconference

• join.me – free basic, organizer can share desktop, but not attendees.  making other attendees as presenter part of pro, paid package
• meetingburner.com – free accounts includes 15 attendees, organizer and presenter can share, non-toll free phone number

Active Directory

• joeware – adfind, admod, etc.

Text Editor

• notepad++

Script IDE

• Powergui

Text Utilities

• Winmerge

Powershell – References

E-Book by Dr. Tobias Weltner

Tread Lightly – Kerberos Encryption Types

Or better yet, make sure you know what you are doing before you make any changes.  Otherwise, you could be in for a world of hurt.

Why all the fuss?

One of the major changes with Windows 7 and Windows Server 2008 R2 is disabling DES encryption support by default.  While DES encryption of Kerberos tickets is still supported, these encryption types  have been disabled by default.   

Repeat after me, DES encryption is disabled by default for Windows 7 and Windows 2008 R2.  This knowledge is critical as changing the encryption types without consideration for the rest of the infrastructure (domain controller operating system versions) could cause massive outage to your environment.

Based on a table provided by Ned Pyle‘s from his post titled, Hunting down DES in order to securely deploy Kerberos, in the Ask the Directory Services Team, I have listed the supported encryption types for each operating system.

Operating System Version	Enabled Encryption Types	Supported Encryption Types
Windows 7, Windows Server 2008 R2	RC4-HMAC AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96	DES-CBC-CRC DES-CBC-MD5 RC4-HMAC AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96
Windows Vista, Windows Server 2008	DES-CBC-CRC DES-CBC-MD5 RC4-HMAC AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96	DES-CBC-CRC DES-CBC-MD5 RC4-HMAC AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96
Windows 2000, Windows 2003, Windows XP	DES-CBC-CRC DES-CBC-MD5 RC4-HMAC	DES-CBC-CRC DES-CBC-MD5 RC4-HMAC

Why is this information critical?

If your environment  runs on 100%  newer versions of Microsoft operating systems  (Windows 7, Windows 2008 Server and newer) with no third-paty software or user accounts that use DES encryption, then you can ignore this warning.  Anyone have that pristine environment?  I thought so.  So, read the rest of the article.

Changing the supported encrytion types may be a consideration when you have Windows 7 or Server 2008 R2 machines in your environment and there are third-party applications  that have not been updated to use newer and more secure encryption types for Kerberos.  These application would require DES encryption to be enabled on Windows 7 and Server 2008 R2 machines.

As a quick background, DES encryption is a legacy encryption type which is very insecure in this day and age.  While older versions of the Windows operating systems still have DES support, these operating systems negotiate the most secure encryption level supported, RC4-HMAC or AES for newer versions, before falling back to DES.

If you have any applications that still use DES encryption, raise hell and bug the vendor to update it to start using RC4-HMAC encryption at the very least.

Ok, but can you provide a doomsday scenario?

Yes, I can.

Environment background

Domain Controllers:  all running Server 2003

Member Machines: Windows XP, Server 2003, Windows 2008, Windows 2008 R2

Existing GPO to enable all supported encryption types on Windows 7 and Server 2008 R2 machines.

Policy Change

Policy change made to disable support for RC4-HMAC encryption on Windows 7, Windows 2008 & Windows 2008 R2 machines. 

Once the change is in place, Windows 7, Server 2008, Server 2008 R2 machine would only have DES-CBC-CRC, DES-CBC-MD5, AES256-HMAC-SHA1-96 & AES128-HMAC-SHA1-96 encryption types enabled.

After group policy refresh and LSASS reload intervals, you will start seeing the following issues:

• Users getting kicked out of Outlook client, unable to reload and repeatedly being prompted for credentials

• Users unable to logon (remote desktop or local logon)  to Windows 7, Windows Server 2008, Windows Server 2008 R2 machines using their domain accounts.  Repeatedly getting prompted for credentials. Local account log on still working.
• If your Exchange servers are running on Server 2008 or R2, you will get error messages in the event log about failure to communicate with domain controllers/global catalogs.
• Server 2008, Windows 7, Server 2008 R2 unable to access SYSVOL share
• Group policy refresh failures
• Kerberos errors being logged on Windows 7, Server 2008, Server 2008 R2 machines

Why does it break?

If you look at the table listing supported encryption types, disabling RC4-HMAC support on the targeted machines should not break the communication channels between the domain controllers running on Server 2003 & the affected member machines running win7, server 2008, server 2008 R2.  That’s because DES encryption is still supported by the domain controllers and the affected member machines.

There is a twist to this however.  The answer can be found by reading MS KB article 833708.  In the symptoms section, it states:

The Microsoft Windows Server 2003 Key Distribution Center (KDC) uses the strongest encryption type (etype) available to encrypt service tickets. If a client requests etype DES-CBC-CRC, the KDC encrypts tickets with RC4_HMAC_NT. If the client does not understand this etype, the service ticket is unusable.

Well, doh!  Yes, affected machines will be able to request for a Kerberos ticket from the domain controllers.  However, the default behavior on the Server 2003 domain controllers is to encrypt the DES-CBC-CRC ticket using the most secure encryption type supported which is RC4_HMAC.  In short, the ticket given to the affected machine is now unusable since we disabled support for RC4_HMAC.

And from this point forward, communication between the affected machines and the domain controllers is not possible.

How can we fix this?

Some of the actions you can try:

Reverting the change and re-enabling the RC4-HMAC encryption using  group policy will not resolve the issue.  Since the affected machines are still not able to communicate with the domain controllers, the group policy update will  not apply to the affected machines.

Adding the registry value on domain controllers as specified in MS KB article 833708 forces the domain controller to use the requested encryption type for tickets instead of using the most secure encryption type.

• This change will restore the ability to log on to affected machines using domain accounts but still does resolve the issue of communicating with the domain controllers.

Manually changing the registry value for affected machines to the value specified in MS KB 977321 allowed the affected machine to communicate with the domain controllers.

• After the reboot, group policy update successfully completed and reverted the encryption type support.
• Further testing showed that a reboot is not required for the change to take effect. However, you will have to wait for the LSASS reload interval.

Lessons Learned

• Test and test before making these kinds of changes
• Scope your testing to limit possible impact
• Learn and understand what kerberos encryption types are.

References

The security principals and the services that use only DES encryption for Kerberos authentication are incompatible with the default settings on a computer that is running Windows 7 or Windows Server 2008 R2

KDC does not allow clients to specify an etype in Windows Server 2003

Hunting down DES in order to securely deploy Kerberos

Importing a PFX File Using CertUtil.Exe

Instead of using the GUI (Certificate Services Snapin), you can use certutil.exe to import a pfx file (private and public key combined).

 

certutil.exe -importPFX pfxfilename

 

You’ll get prompted for the password.

 

More information from the Windows PKI blog which can be found here:

 

http://blogs.technet.com/pki/archive/2007/07/29/marking-private-keys-as-non-exportable-with-certutil-importpfx.aspx

 

 

LDAPS: Combining Private and Public Key for 3rd Party Certs

After receiving the crt file from 3rd party CA, using the Certificates snap-in will not properly combine the private key with the public cert issued the 3rd party CA.  So, you will find that you do not have the option to export out the private key when exporting the certificate.   The proper way is to use certreq to accept and install the response file from the 3rd party CA.  Here is the syntax:

 

certreq -accept nameofresponsefile

 

Once complete, you will now have the option to export the private key.

 

IE Zero Day Exploit

A compilation of information about the IE zero day exploit used to hack Google and other companies:

 

Microsoft Security Advisory (979352)

KB article 979352 – Provides a tool for enablng or disabling software DEP

KB article 875352 – Description of Data Execution Prevention (DEP)

KB article 912923 – How to determine that hardware DEP is available and configured on your computer

 

 

 

AD: Find and Check Names… What’s the Difference?

 

What is the difference between Find and "Check Names" capabilities in Active Directory Users and Computers?

 

You normally use "Check Names" when adding members to a group (Members) or  modifying user’s group membership (MemberOf tab).  We needed to understand the difference between the two as different result sets were being generated when using the same search criteria and we had to have the same result set to provide friendlier administrative experience.

 

At the start, I knew that the Find feature performs an Ambiguous Name Resolution (ANR) search.  This is the same functiionly provided within the Outlook client when you click on  "Check Names".    For more details on ANR, see MS KB Article 243299.

 

By default, the following attributes are set for ANR:

 

• GivenName
• Surname
• displayName
• LegacyExchangeDN
• msExchMailNickname
• RDN
• physicalDeliveryOfficeName
• proxyAddress
• sAMAccountName

"Check Names" on other hand, does not make use of the ANR capability.  Rather it is a directed LDAP search using the OR operator for one the following attributes:

 

• displayName
• samaccountname
• name

 

How did I find the answer?

 

Using ADInsight which is a Sysinternals (now MS) tool.   After firing up ADInsight, I was able to see the exact LDAP queries being issued for the search operations perofrmed.   The trace for the Find feature showed the LDAP search using the anr keyword confirming my earlier understanding of this capability.  The "Check Names" feature on the other hand, showed the LDAP search filter containing the portion listed below.  Thus, it performs a search (using the OR operator) for objects where one of the 3 attributes listed below matches the search criteria. 

 

|(name=searchstring)(displayname=searchstring)(samaccountname=searchstring)

 

This trace gave me the answer.  For "Check Names" to provide the same answer to the "Find" feature, one of the 3 attributes of the object, displayname, samaccountname or name, must match the search string being used in the ANR search for Find. 

 

 

 

 

 

 

AD: Logging all LDAP searches in AD

Here are the steps to follow if you would like your domain controller to log all LDAP searches in the Directory Service log.  This is very useful when troubleshooting LDAP connections and  searches performed by your clients or applications against Active Directory.  Of course, once you are done with troubleshooting, you should revert to the default settings.

 

1.  Set the value for "15 Field Engineering" to 5 (default is 0)

 

–  This value can be found in HKLM\System\CurrentControlSet\Services\NTDS\Diagnostics

 

2.  After changing the value, you will start seeing entries for expensive and inefficient LDAP searches.

 

– Not this will not log all LDAP searches.

– The reason, the default threshold for inefficient and expensive search results are set to 1000 and 10000 respectively.

 

3.  To log all LDAP searches, you need to change the default tresholds for either inefficient and expensive searches to 1.  Follow the instructions below:

 

– Inefficient Search Results Threshold (create value as it is not present by default)

   HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Inefficient Search Results Threshold:DWORD

 

– Expensive Search Results Threshold (create value as it is not present by default)

   HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Expensive Search Results Threshold:DWORD

 

Once you have completed these steps, all entries will be logged.  I normally just set the Expensive Search Results Threshold to 1

 

 

To revert back,  you need to delete the Inefficient or Expensive Search Results values that you created and set the "15 Field Engineering" value to 0.

 

To deploy to multiple DCs, consider using GPO by way of ADM templates or Group Policy Preferences.

 

 

TS: Locking Down Terminal Servers

Some whitepapers…

 

http://www.microsoft.com/downloads/thankyou.aspx?familyId=7f272fff-9a6e-40c7-b64e-7920e6ae6a0d&displayLang=en

http://support.microsoft.com/kb/278295