SSL and Exchange Server

Posted on 2 CommentsPosted in 2008 R2, 2012 R2, 2013, certificates, exchange, https, IAmMEC, JetNexus, load balancer, Load Master, loadbalancer, mobile phones, SSL, TLS, windows server, xp

In October 2014 or thereabouts it became known that the SSL protocol (specifically SSL v3) was broken and decryption of the encrypted data was possible. This blog post sets out the steps to protect your Exchange Server organization regardless of whether you have one server or many, or whether or not you use a load balancer or not. As load balancers can terminate the SSL session and recreate it, it might be that changes are needed on your load balancer or maybe directly on the servers that run the CAS role. This blog post will cover both options and looks at the settings for a Kemp load balancer and a JetNexus load balancer.

Of course being an Exchange Server MVP, I tend to blog about Exchange related stuff, but actually this is valid for any server that you publish to the internet and probably valid of any internal server that you encrypt traffic to via the SSL suite of protocols. Microsoft outline the below configuration at https://technet.microsoft.com/en-us/library/security/3009008.aspx.

The steps in this blog will look at turning off the SSL protocol in Windows Server and turning on the TLS protocol (which does the same thing as SSL and is interchangeable for SSL, but more secure at the time of writing – Jan 2015). Some clients do not support TLS (such as Internet Explorer on Windows XP Service Pack 2 or earlier, so securing your servers as you need to do may stop some home users connecting to your Exchange Servers, but as XP SP2 should not be in use in any business now, these changes should not affect desktops. You could always use a different browser on XP as that might mitigate this issue, but using XP is a security risk in an of itself anyway! To disable clients from connecting to SSL v3 sites requires a client or GPO setting and this can be found via your favourite search engine.

Note that the registry settings and updates for the load balancers in this blog post will restrict client access to your servers if your client cannot negotiate a mutual cipher and secure channel protocol. Therefore care and testing are strongly advised.

Testing and checking your changes

Before you make any changes to your servers, especially internet facing ones, check and document what you have in place at the moment using https://www.ssllabs.com/ssltest. This service will connect to an SSL/TLS protected web site and report back on the issues found. Before running any of the changes below see what overall rating you get and document the following:

  • Authentication section: record the signature algorithm. For the signature algorithm its possible the certificate authority signature will be marked “SHA1withRSA WEAK SIGNATURE”. This certificate, if rekeyed and issued again by your certificate authority might be replaced with a SHA-2 certificate. The Google Chrome browser from September 2014 will report sites secured with this SHA-1 certificate as not fully trustworthy based on the expiry date of the certificate. If your certificate expires after Jan 1st 2017 then get it rekeyed as soon as possible. As 2015 goes on, this date will move closer in time. From early 2015 this cut off date becomes June 1st 2016 and so on. Details on the dates for this impact are in http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually-sunsetting-sha-1.html. You can also use https://shaaaaaaaaaaaaa.com/ to test your certificate if the site is public facing, and this website gives details on who is now issuing SHA-2 keyed certificates. You can examine your external servers for SHA-1 certificates and the impact in Chrome (and later IE and Firefox) at https://www.digicert.com/sha1-sunset/. To do the same internally, use the DigiCert Certificate Inspector at https://www.digicert.com/cert-inspector.htm.
  • Authentication section: record the path values. Ensure that each certificate is either in the trust store or sent by the server and not an extra download.
  • Configuration section: document the cipher suites that are provided by your server
  • Handshake simulation section: Here it will list browsers and other devices (mobile phones) and what their default cipher is. If you do not support the cipher they support then you cannot communicate. Note that you typically support more than one cipher and the client will often support more than one cipher to, so though it is shown here as a mismatch this does not mean that it will not work and if this client is used by your users then click the link for the client and ensure that the server offers at least one of the the ciphers required by the client – unless all the ciphers are insecure in which case do not use that client!

Once you have a document on your current configuration, and a list of the clients you need to support and the ciphers they need you to support, you can go about removing SSL v3 and insecure ciphers.

Disabling SSL v3 on the server

To disable SSL v3 on a Windows Server (2008 or later) you need to set the Enabled registry value at “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Server” to 0. If this value does not exist, the create a DWORD value called “Enabled” and leave it at 0. You then need to reboot the server.

If you are using Windows 2008 R2 or earlier you should enable TLS v1.1 and v1.2 at the same time. Those versions of Windows Server support TLS v1.1 and v1.2 but it is not enabled (only TLS v1.0 is enabled). To enable TLS v1.1 and v1.2 use set the Enabled value at “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.1\Server” to 1. Change the path to “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.2\Server” and the same setting to support TLS v1.2. If these keys do not exist, create them. It is also documented that the “DisabledByDefault” key is required, but I have seen this noted as being the same as the “Enabled” key – just the opposite value. Therefore as I have not actually checked, I set both Enabled to 1 and DisabledByDefault to 0.

To do both the disabling of SSL v2 and v3 (v2 can be enabled on older versions of Windows and should be disabled as well) I place the following in a .reg file and double click it on each server, followed by a reboot for it to take effect. This .reg file contents also disables the RC4 ciphers. These ciphers have been considered insecure for a few years and when I configure my servers not to support SSL v3 I also disable the RC4 ciphers as well.

Windows Registry Editor Version 5.00

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0]

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Client]

"Enabled"=dword:00000000

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 2.0\Server]

"Enabled"=dword:00000000

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0]

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Client]

"Enabled"=dword:00000000

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\SSL 3.0\Server]

"Enabled"=dword:00000000

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Ciphers\RC4 128/128]

"Enabled"=dword:00000000

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Ciphers\RC4 40/128]

"Enabled"=dword:00000000

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Ciphers\RC4 56/128]

"Enabled"=dword:00000000

Then I use the following .reg file to enabled TLS v1.1 and TLS v1.2

Windows Registry Editor Version 5.00

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.1]

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.1\Client]

"Enabled"=dword:00000001

"DisabledByDefault"=dword:00000000

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.1\Server]

"Enabled"=dword:00000001

"DisabledByDefault"=dword:00000000

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.2]

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.2\Client]

"Enabled"=dword:00000001

"DisabledByDefault"=dword:00000000

 

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols\TLS 1.2\Server]

"Enabled"=dword:00000001

"DisabledByDefault"=dword:00000000

 

Once you have applied both of the above sets of registry keys you can reboot the server at your convenience. Note that the regkeys may set values that are already set, for example TLS v1.1 and v1.2 are enabled on Exchange 2013 CAS servers and SSL v2 is disabled. For example the first of the below graphics comes from a test environment of mine that is running Windows Server 2012 R2 without any of the above registry keys set on them. You can see that Windows Server 2012 R2 is vulnerable to the POODLE attack and supports the RC4 cipher which is weak.

image

The F grade comes from patched but un-configured with regards to SSL Windows Server 2008 R2 server

image

After setting the above registry keys and rebooting, the test at https://www.ssllabs.com/ssltest then showed the following for 2012 R2 on the left (A grade) and Windows Server 2008 R2 on the right (A- grade):

image image

Disabling SSL v3 on a Kemp LoadMaster load balancer

If you protect your servers with a load balancer, which is common in the Exchange Server world, then you need to set your SSL and cipher settings on the load balancer, unless you are only balancing at TCP layer 4 and doing SSL pass through. Therefore even for clients that have a load balancer, you might not need to make the changes on the load balancer, but on the server via the above section instead. If you do SSL termination on the load balancer (TCP layer 7 load balancing) then I recommend setting the registry keys on the Exchange servers anyway to avoid security issues if you need to connect to the server directly and if you are going to disable SSL v3 in one location (the load balancer) there is no problem in disabling it on the server as well.

For a Kemp load balancer you need to be running version 7.1-20b to be able to do the following, and to ensure that the SSL code on the load balancer is not susceptible to issues such as heartbleed as well. To configure your load balancer to disable SSL v3 you need to modify the SSL properties of the virtual server and check the “Support TLS Only” option.

To disable the RC4 weak ciphers then there are a few choices, but the easiest I have seen to do is to select “Perfect Forward Secrecy Only” under Selection Filters and then add all the listed filters. Then from this list remove the three RC4 ciphers that are in the list.

If you do not select “Support TLS Only” and leave the ciphers at the default level then your load balancer will get an C grade at the test at https://www.ssllabs.com/ssltest because it is vulnerable to the POODLE attack. Setting just the “Support TLS Only” option and leaving the default ciphers in place will result in a B grade, as RC4 is still supported. Removing the RC4 ciphers (by following the instructions above to add the perfect forward secrecy ciphers and remove the RC4 ciphers from this list) as well as allowing only the TLS protocol will result in an A grade.

image

Kemp 7.1-22b does not support SSL v3 for the API and web interface as well as completing the above to protect the virtual services that the load balancer offers.

Kemp Technologies document the above steps at https://support.kemptechnologies.com/hc/en-us/articles/201995869, and point out the unobvious setting that if you filter the cipher list with the “TLS 1.x Ciphers Only” setting then it will only show you the TLS 1.2 ciphers and not any TLS 1.1 or TLS 1.0 ciphers. THerefore selecting “TLS 1.x Ciphers Only” rather than filtering using “Perfect Forward Secrecy Only” will result in a reduced client list, which may be an issue.

I was able to achieve an A grade on the SSL Labs test site. My certificate uses SHA-1, but expires in 2015 so by the time SHA-1 is reported an issue in the browser I will have changed it anyway.

image

Disabling SSL v3 on a JetNexus ALB-X load balancer

If you protect your servers with a load balancer, which is common in the Exchange Server world, then you need to set your SSL and cipher settings on the load balancer, unless you are only balancing at TCP layer 4 and doing SSL pass through. Therefore even for clients that have a load balancer, you might not need to make the changes on the load balancer, but on the server via the above section instead. If you do SSL termination on the load balancer (TCP layer 7 load balancing) then I recommend setting the registry keys on the Exchange servers anyway to avoid security issues if you need to connect to the server directly and if you are going to disable SSL v3 in one location (the load balancer) there is no problem in disabling it on the server as well.

For a JetNexus ALB-X load balancer you need to be running build 1553 or later. Build 1553 is a version 3 build, so any version 4 build is of a higher, and therefore valid build. This build (version 3.54.3) or later is needed to ensure Heartbleed mitigation and to allow the following configuration changes to be applied.

To configure the JetNexus  you need to upload a config file to turn off SSL v3 and RC4 ciphers. The config file is .txt file that is uploaded to the load balancer. In version 4, the primary cluster node can have the file uploaded to it, and the changes are replicated to the second node in the cluster automatically.

Before you upload a config file to make the changes required, ensure that you backup the current configuration from Advanced >> Update Software and click the button next to Download Current Configuration to save the configuration locally. Ensure you backup all nodes in a v4 cluster is appropriate.

Then select one of the three config file settings below and copy it to a text file and upload it from Advanced >> Update Software and use the Upload New Configuration option to install the file. The upload will reset all connections, do do this at during a quiet period of time.

The three configs are to reset the default ciphers, to disable SSL v3 and RC4, and to disable TLS v1.0 and SSL v3 and RC4

JetNexus protocol and cipher defaults:

#!update

 

[jetnexusdaemon]

Cipher004="ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH"

Cipher1=""

Cipher2=""

CipherOptions="CIPHER_SERVER_PREFERENCE"

JetNexus protocol and cipher changes to disable SSL v3 and disable RC4 ciphers:

#!update

 

[jetnexusdaemon]

Cipher004="ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:HIGH:!MD5:!aNULL:!EDH:!RC4"

Cipher1=""

Cipher2=""

CipherOptions="NO_SSLv3,CIPHER_SERVER_PREFERENCE"

JetNexus protocol and cipher changes to disable TLS v1.0, SSL v3 and disable RC4 ciphers:

#!update

 

[jetnexusdaemon]

Cipher004="ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:HIGH:!MD5:!aNULL:!EDH:!RC4"

Cipher1=""

Cipher2=""

CipherOptions="NO_SSLv3,NO_TLSv1,CIPHER_SERVER_PREFERENCE"

On my test environment I was able to achieve an A- grade with the SSL Test website and the config to disable TLS 1.0, SSL3 and RC4 enabled. The A- is because of a lack of support for Forward Secrecy with the reference browsers used by the test site.

image

Browsers and Other Clients

There too much to discuss with regards to clients, apart from they need to support the same ciphers as mentioned above. A good guide to clients can be found at https://www.howsmyssl.com/s/about.html and from there you can test your client as well.

Additional comment 23/1/15 : One important comment to make though comes courtesy of Ingo Gegenwarth at https://ingogegenwarth.wordpress.com/2015/01/20/hardening-ssltls-and-outlook-for-mac/. This post discusses the TLS Renegotiation Indication Extension update at RFC 5746. It is possible to use the AllowInsecureRenegoClients registry key at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL to ensure that only clients with the update mentioned at http://support.microsoft.com/kb/980436 are allowed to connect. If this is enabled (set to Strict Mode) and the above to disable SSL 2 and 3 is done then Outlook for Mac clients cannot connect to your Exchange Server. If this regkey is deleted or has a non-zero value then connections to SSL 2 and 3 can be made, but only for a renegotiation to TLS. Therefore ensure that you allow Compatibility Mode (which is the default) when you disable SSL 2 and 3, as Outlook for Mac and Outlook for Mac for Office 365 both require SSL support to then be able to start a TLS session.

How to Clear Password Policy on workstation after removing it from domain

Posted on Leave a commentPosted in domain, password, policy, workstation, xp

I needed to set up a few machines for a client in an internet cafe type scenario, but the client provided me with computers that had been added to the domain. The domain had a password requirement which meant I could not configure the default login on the cafe machines to have no password.
To reset the domain policy without adding the computer back into the domain and actually changing the policy for a short while you can reset the security settings on an XP computer to that at install time using the following command:

 secedit /configure /cfg %windir%\repair\secsetup.inf /db secsetup.sdb /verbose

This resets lots of settings back to the default installation configuration, but meant that I did not need to reinstall the operating system.
For full details on the limitations of the above command see http://support.microsoft.com/default.aspx?scid=kb;en-us;313222

Windows XP Mode and McAfee AntiVirus

Posted on Leave a commentPosted in xp

Windows XP Mode is a new feature of Windows 7 Professional, Enterprise and Ultimate Editions. It allows you to run a copy of Windows XP on the same machine at the same time as Windows 7 to allow you to run software that does not work on Windows 7 Though support for hardware virtualization is needed for the software to run, all business class PC’s with Intel or AMD processors available at Windows 7 launch (except the AMD Sempron) will have this hardware support.

Microsoft recommends that anti-virus software be installed on the Windows XP Mode installation, which is wise advice because this is a standard Windows XP SP3 machine with all its inherent flaws. Tall three bits (antivirus, firewall and browser protection). Installing the firewall component breaks the component that allows the software that is installed on the XP machine to integrate seamlessly with Windows 7.

Your get the following error on starting either the full window version of XP Mode or any of the applications you have installed on XP Mode.

Could not enable integration features.

Ensure that the remote access and Group Policy settings in the virtual machine operating system allow remote connections. Please contact your administrator for more details.

You can continue without these features.

Currently Kaspersky and Symantec anti-virus products are supported in Windows XP Mode. Nothing yet on whether you need two licences though!

Fixing Error 1324.The path xxx contains an invalid character.

Posted on 3 CommentsPosted in xp

When installing software I have now seen a number of times the following error “Error 1324.The path My Documents contains an invalid character.”. My Documents could be replaced by a number of other special folders, and I have seen this issue on Windows XP and Windows Vista.

The problem seems to stem from having UNC paths for folders (i.e. \\server\share\user\my documents). So, to fix the issue you need to temporarily change the path to a local path and change it back after installation. These steps will help (based on Vista, but XP is similar):

  1. Click Start
  2. Right-click Documents (or Pictures etc.)
  3. Choose Properties
  4. Make a note of the path currently used
  5. Change path to the Default by clicking Restore Default button
  6. Click OK
  7. If prompted about creating folder say Yes
  8. When prompted about moving all your files say no (you are going to move the folder back shortly) and then wait a bit – this might take some time.
  9. Install your application
  10. Repeat above instructions to move the folder back again, but this time do move the files. This will merge changes to the folder back to your actual folder.

Unable to Delete Active Directory Object

Posted on 1 CommentPosted in exchange, windows server, xp

Whilst doing some tests on an Active Directory to do with permissions I removed all the permissions apart from SYSTEM. This proved what I wanted to prove, but I then could not delete the object or reset its permissions etc. to tidy up my test environment.

A search on the web for the problem returned one page and they had not solved it either. This was found here. Though they had deleted a user object and I had set permissions on an Exchange Server address list object I think the answer might be the same.

The problem in Exchange System Manager was “The specified directory service attribute or value does not exist” and “8007200a” when I tried to delete the object. Opening ADSI Edit would not let me delete the object (which appears as a notepad icon and not the folder icon it is supposed to be). Opening the object returns “An invalid directory pathname was passed” and deleting the object returns “This folder or one of its children has one or more property sheets up. Please close the property sheet before continuing with this action.

So taking the advice in the above link, and going a few steps further I managed to delete the object.

The key (in Windows Server 2003) is to use a command line tool called DSRM. This deletes active directory objects, but before it can be deleted the permissions need to be reset using another command line tool called DSACLS.

  1. Determine the distinguished name of the object. This is easiest to do in ADSI Edit by opening the parent item and copying the value of the distinguishedName property.
  2. Paste the copied distinguished name into Notepad and prepend to the text the name of the child object in the form of CN=child,distinguishedname.
  3. On the command line enter DSACLS “Distinguished Name” /A. The quotes are needed if there are spaces within the distinguished name. This will display the current permissions on the object for your interest.
  4. Repeat the above command but change the ending to /G Everyone:GA (remove the /A). This will grant full control to Everyone to this object. Remember that you are deleting this item so these permissions are temporary. This should be successful.
  5. Finally you can delete the object using DSRM if the object is a leaf object, but if not a leaf object then DSRM distinguishedName -subtree. It might also be possible to use ADSI Edit or the valid Active Directory administration tool to delete the object if the permission fix has worked.

Dell Notebook System Software (NSS) Failure to Install

Posted on 1 CommentPosted in 2003, xp

I recently had to rebuild a Dell Latitude D610 as it was not working properly on purchase. The reinstall instructions for Windows XP SP2 included installing the relevant Dell drivers from the Dell CD (or internet download if they were later versions). The Notebook System Software (NSS) always failed to install – it would crash upon starting the program.

After phoning Dell Technical Support to fix this problem, the answer was to run the software whilst in Windows XP Safe Mode. To get to this reboot your computer and press F8 just before the Windows logo appears (easiest thing to do is press F8 repeatedly as soon as the computer boots and you are sure to get the option for Safe Mode).

After installing it in Safe Mode you can reboot into normal Windows XP.

Start Menu and Multiple Monitors

Posted on 6 CommentsPosted in xp

When you enable multiple monitor on Windows XP, which I did by installing an ATI Radeon card in addition to my existing Nvidia card I found that after changing some of the settings (like which is the primary display), the Start Menu and Task Bar appears on the secondard display. What seemed to happen was the Start Menu etc. moved to one of the display’s managed by the ATI card and then I set the primary display back to the Nvidia card it became the primary display (programs and dialog boxes opened on that display) but the Task Bar did not move back.

Eventually, after much reconfiguration and reseting/rebooting I decided to see if I could drag the Task Bar across. Now this is not supposed to work (maybe it has been added in SP2 for XP). So I unlocked the Task Bar and dragged it first to the side of the current screen (the displays are lined up left to right) and then across to the other display – you cannot drag it straight across the bottom of the displays.

This worked a treat, so I relocked the Task Bar and all works now.

Hotfix Files

Posted on Leave a commentPosted in xp

When an update to Windows is installed, if that update is a GDR (general distribution release) update, the possibility exists that a hotfix exists for the same files but in an earlier version. This hotfix would have been developed separatly within Microsoft for the specific customer problem that the hotfix fixes, but as it is not part of the service pack/security update cycle it does not have an obvious version number, and so could easily be installed out of sequence. Therefore the, the hotfix files for that GDR are copied to the %windir%\$hf_mig$ folder. This allows migration to the appropriate files if you later install a hotfix or service pack that includes earlier versions of these files. For example, consider the following scenario:

  1. You apply a security update that installs a GDR version of File.dll with a version number of 5.2.3790.1000 and copies a hotfix version of File.dll with a version number of 5.2.3790.1000 to the %windir%\$hf_mig$ folder.
  2. You apply a hotfix that includes a hotfix version of File.dll with a version number of 5.2.3790.0000.

For more click here.

Two Logins To Install Software

Posted on 4 CommentsPosted in windows server, xp

With Windows XP you sometimes see that your Group Policy settings take two reboots or two logins to work. This is because Windows XP operates (by default) in a mode called Fast Logon Optimization. This means that the computer boots and logs in quicker, but it does mean that events that should occur during the computers boot or login will be delayed until the second boot or login.

Examples of events that this effects are software installations via Group Policy and folder redirection (i.e. home folders). During (or usually just after) the first boot/logon XP sets a flag and then during the second boot/logon Windows operates one time only without the Fast Logon enabled.

An example of the two events that appear in the event log (in chronological order) are:

Event Type: Warning
Event Source: Application Management
Event Category: None
Event ID: 108
Date:
Time:

Event Type: Warning
Event Source: Application Management
Event Category: None
Event ID: 101
Date:
Time:

This behaviour can be changed by turning the Fast Logon Optimization off. This can be switched on and off via Group Policy and the following setting:

Computer Configuration
Administrative Templates
System
Logon
Always wait for the network at computer startup and logon

More on Fast Logon Optimization can be found in article 305293 at Microsoft Support.