Forcing Transport Level Secure Email With Exchange Online

Posted on Leave a commentPosted in EOP, exchange online, Exchange Online Protection, Exchange Server, Office 365, security, starttls, TLS

In Exchange Online there are a few different options for forcing email to require an encrypted connection. These depend upon the level of licence you have, and some of them are user based (Office 365 Message Encryption for example), but there are two ways to force TLS (transport layer security) for the email between when the message leaves Office 365 and arrives with the recipient email system.

The first of these is a Mail Flow rule, and the second of these is a Conditional Connector. Only the second of these works!

The first, just for clarity, appears to work but it is not 100% reliable and will end up with stuck emails unless you configure the rule 100% correct. The second option is the recommended option ongoing.

For completion, we will also look at forcing TLS inbound to Exchange Online

Force TLS with Mail Flow Rules

This option relies on a Transport Rule (or mail flow rule) setting called “Require TLS”. This below example shows a UK Government requirement that states that emails to certain government departments (by domain name) should enforce the use of TLS:

image

This rule uses the condition “if the recipient address includes” and the list of UK Government domains that should be secured. This list is found at https://www.gov.uk/guidance/set-up-government-email-services-securely#configure-cloud-or-internet-based-email-services and for test purposes I have added my own domains to the list. The action for this rule is “to require TLS encryption”.

As mentioned above, this rule is not 100% reliable, and the the issue is when you have a Hybrid Exchange Online environment back to on-premises Exchange, though that connector back to on-premises uses TLS, the rule to force TLS conflicts and the email stays in Exchange Online in a pending state and is never delivered.
To avoid this issue, an exception is required to the rule to exempt it for your on-premises domains.

Force TLS with Conditional Connectors

This is the recommended route for forcing TLS. It requires two settings created. The first is a Conditional Connector as shown:

image

You must select “Only when I have a transport rule set up that redirects messages to this connector” on the connector use page.

image

MX delivery is the most likely option, and then either any digital certificate or issued by a trusted third party depending upon your requirements.

image

If you have more than one domain to force TLS to, then do not enter the end certificate info here, as it will be different for each domain.

Now that you have the connector in place, which will only be used is rules route the emails to that connector, you can create the rule.

image

We have purposely excluded the domains we had an issue with when using “Require TLS”, but Microsoft say that workaround should not be needed – I will update this post once I know that for sure! Also, as the rule shown in the screenshots adds a disclaimer so that we can check that the rule is being executed.

Inbound Required TLS with Connectors

To force inbound TLS requirements, so that email from given domains are rejected if they do not open a TLS session with your organization to send an email you create a Partner to Office 365 connector. This connector will force TLS or reject the email inbound if that cannot happen:

image

image

image

And then choosing “Reject email messages if they aren’t sent over TLS” as part of the connector conditions:

image

image

Securing Your Windows 10 Login With Yubikey

Posted on 2 CommentsPosted in MFA, MVP, security, yubikey

The Yubikey is a small USB connected hardware device that can generate a variety of security codes. Being virtually indestructible and easy to clip to a key ring (Yubikey 4) or leave inside your only device (Yubikey 4 Nano) you can now use this token to login to Windows. Once you have got your token from Yubico (via Amazon or other resellers) for around £40 you start the very simple Windows Hello authentication registration process by downloading the Yubikey app from Windows App Store.  Signing in after a restart requires full credentials (password or PIN), which means a stranger who steals your PC and the YubiKey can’t use it to access your device

Open the Store app, search for Yubikey and click the logo for the app.

image

Click the Get button to install the app then then launch to start it. In a corporate environment you can push the app to your devices with MDM solutions like Intune.

Launch the app. You will need to have a PIN login enabled for the device to work and so you will see a warning if you do not have this enabled.

image

If you need to set up a PIN then close the Yubikey app and type “PIN” in the search box in Windows and choose “Setup PIN sign-in”

image

Scroll down and click Add under PIN. You will need to reenter your password so other people cannot set up a PIN on your behalf.

Enter a PIN and confirm the same PIN

image

You will now be able to use a PIN to sign in. The PIN setup process will continue and you will be asked to confirm your PIN again. You can now use your PIN to sign into your computer, which as it is tied to the computer hardware, is more secure than your password. But we are not stopping there – we can now restart the Yubikey app. Either launch it from the Store app, from the search box on the Start Menu or From the Start menu, select All Apps >Start > YubiKey for Windows Hello

image

Click Register to start the process of pairing your Yubikey to your computer

image

Insert your Yubikey into any USB port on the PC and press Continue

image

Name the Yubikey, as at login it will ask you to insert this named key. Click Continue once you have a name

image

At this point it should register the device and all is good!

If you find that Windows Companion Devices are disabled then you will get this error:

image

It reads “Oh no! An error occurred during registration. Windows companion devices are disabled on this system. Contact your system administrator”. This is because the local security policy on your computer or network via your Active Directory and IT driven polices does not allow companion devices. On systems running Windows Pro or Windows Enterprise systems, you must enable the option to Allow companion device for secondary authentication in the Local Security Policy. If your organization manages your security policy, contact your IT administrator and request this change before installing this app. You cannot change local security policy on systems running Windows Home, however this option is enabled by default. Note that you will also get this on domain joined systems as well, as secondary auth is not supported on domain joined machines (even for individual users) at this time.

To modify local security policy

  1. Open the Local Group Policy Editor. To do this, press the Windows key, type R, and then type gpedit.msc.
  2. In the Local Group Policy Editor, from the top level Local Computer Policy, navigate to Computer Configuration > Administrative Templates > Windows Components > Microsoft Secondary Authentication Factor.
  3. In the right pane, click the link to Edit policy setting. (You can also double-click the setting to Allow companion device for secondary authentication.) The default state is Not configured.
  4. In the setting screen, select the option for Enabled, and click OK. If this option is already selected, your policy is set and you can click Cancel.
  5. Exit the Local Group Policy Editor and the Management Console.