Saturday, 11 February 2017

Offline standalone root CA install, Server 2012 R2 - Part 1

Overview

In this post, we’ll look at how to set up an offline standalone root CA in Windows Server 2012 R2. This is the most secure way to set up your CA because it means you can set up subordinate issuing CAs and power off the root CA when not required to issue subordinate CA certificates.
Having a powered off server means you cannot possibly have it compromised (unless someone has physical access to it or you decide to store the CA private key on an unencrypted USB key and gave it to a friend to get some movies but that’s beside the point!).

How to install an offline standalone root CA

Before we start, make sure you have a clean build of Windows Server 2012 R2 without any other roles installed. Make sure your server is not joined to a domain. The server in this example is called LITCA01 (our root CA in the Litware organization).
  • Install AD CS role and select Certificate Authority role service:
    • Either user Powershell
    Install-WindowsFeature AD-Certificate,ADCS-Cert-Authority
    • Or use the GUI:
 clip_image001
clip_image002
clip_image003 
  • Select Active Directory Certificate Services
clip_image004
  • Click next
clip_image005
  • Click next
clip_image006
  • Select Certificate Authority
clip_image007
  • Click next
clip_image008 
  • Configure CA and select standalone CA:
clip_image009
  • After installation, the wizard prompts you to configure the CA. If you used PowerShell then you can continue CA configuration by opening up Server Manager.
  • Click through the wizard and select defaults and then when prompted, for a CA type, select root CA:
clip_image010
  • Create certificate or use an existing one (if you have one already). In our case, we don't already have one so we create a new one.
  • Accept defaults and complete the wizard. You now have a standalone Certificate Authority.

 

Conclusion

Your standalone CA is now set up. So, that’s great! How do I make sure things will work when it’s offline? How do you get a certificate from an offline CA? How will domain joined clients autoenroll certificates? Well, we’ll need a subordinate CA but first we need to configure our CA and prepare it for a subordinate CA. We’ll go through this in part 2.




Offline standalone root CA install, Server 2012 R2 - Part 2

Introduction

So, in part 1, we installed our offline root CA called LITCA01. In this part, we’ll configure the AIA and CDP settings so that we can create a subordinate CA which will be used to issue certificates to clients and be joined to the domain.

What is a CDP?

First of all, what is a CDP and what is AIA? Yes, good question!
CDP stands for CRL Distribution Point. CRL stands for Certificate Revocation List. Let’s say you issue a certificate to a web server. Your client then connects to the web server and downloads the certificate (public key). It needs to know if this web server certificate has been revoked or not so to do this, it looks at the certificate extensions (properties on the certificate) and looks for the CDP locations. Usually this is an LDAP or HTTP URL and the client can connect to download the CRL and then work out if the web server certificate has been revoked or not.

What is AIA?

The Authority Information Access (AIA) locations are configured on a CA and they are stamped onto certificates issued by the CA. This information is used by an application or service to get the issuing CA certificate to validate the certificate path.

How to configure an offline standalone root CA CDP and AIA extensions

  • Install IIS and the management tools:
Install-WindowsFeature web-server,web-mgmt-console
  • Make a directory in the default website: C:\inetpub\wwwroot\CertEnroll
  • Open up the Certification Authority console
image
  • Right click on your CA (LITCA01-CA in our case) and click on properties
  • Click on the extensions tab and click on Add to add a new CDP:
C:\inetpub\wwwroot\CertEnroll\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
  • Enable Publish CRLs to this location and Publish Delta CRLs to this location
clip_image001
  • Run certutil -crl to create a new CRL and ensure this appears in the folder with the name: C:\inetpub\wwwroot\CertEnroll\LITCA01-CA.crl (your CA name will be different)
  • Configure the http CDP by enabling Include in CRLs. Clients use this to find Delta CRL locations and Include in the CDP extension of issued certificates
clip_image002
  • Now, click on Select extension and choose Authority Information Access (AIA):
    • Add an AIA location:
C:\inetpub\wwwroot\CertEnroll\<ServerDNSName>_<CaName><CertificateName>.crt
clip_image003
  • Enable http AIA by ticking Include in the AIA extension of issued certificates
clip_image004
  • Click OK
  • Copy C:\Windows\System32\CertSrv\CertEnroll\litca01_LITCA01-CA.crt to C:\inetpub\wwwroot\CertEnroll\litca01_LITCA01-CA.crt (your CA name will be different so copy the .crt file for your CA)

Conclusion

We’ve now configured a CDP and AIA location for our offline root CA. These will only be needed for our subordinate CAs when they need to renew or reissue their CA certificates. In the next post, we’ll go through how to set up a subordinate enterprise CA which our domain joined clients can use for certificate requests.


Monday, 1 February 2016

Receive connector logging | Exchange 2013, 2016

Introduction


In this post, we’ll do a walk through on how to enable receive connector logging, where to find the logs or move the receive connector log path.
  • Enable Receive Connector Logging
  • Receive Connector Log Path
  • Change the Receive Connector Log Path and other settings
  • Disable Receive Connector Logging

Enable Receive Connector Logging


To enable receive connector logging for a single receive connector, e.g. Relay 1 on server LITEX01:

Set-ReceiveConnector “LITEX01\Relay 1” -ProtocolLogging Verbose


image_thumb


To enable receive connector logging for all receive connector on a particular server, e.g. server LITEX01:

Get-ReceiveConnector -Server LITEX01 | Set-ReceiveConnector -ProtocolLogging Verbose


image_thumb1


Receive Connector Log Path


If you read the background infromation on receive connectors here, you’ll see that there are two services involved in email transport and each has its own receive connectors:
  • Front End Transport Service
  • Transport Service

They also each have their own receive connector protocol log path.

Front End Transport Service Receive Connector Log Path


The default for the Front End Transport Service is: "C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive"

You can check the Front End Transport Service receive connector log path by running the below command which outputs the path for the server LITEX01:

Get-FrontendTransportService -Identity LITEX01 | fl ReceiveProtocolLogPath

image


Transport Service Receive Connector Log Path


The Transport Service receive connector log path is: "C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive"

You can check the log path by running this command for server LITEX01:

Get-TransportService -Identity LITEX01 | fl ReceiveProtocolLogPath

image

Change the Receive Connector Log Path and other settings


In this section, we’ll look at how to change the log path and other settings for the Front End Transport Service and the Transport Service.

Front End Transport Service


We can confirm the current settings by running the command below:

Get-FrontEndTransportService -Identity LITEX01 | fl Receive*

image

Here we can see that logs are stored for a maximum of 30 days, each log file can grow to 10MB and the maximum log directory size is 250MB. The log path is also listed.

There may be some requirements to store receive connector logs for more than 30 days. In this case, you can increase the maximum directory size to 500MB and the maximum age to 60 days using this command:

Set-FrontEndTransportService -Identity LITEX01 -ReceiveProtocolLogMaxAge 60.00:00:00 -ReceiveProtocolLogMaxDirectorySize 500MB

image

You can also change the log path. For example, this command changes the log path to E:\Logs\Frontend:

Set-FrontEndTransportService -Identity LITEX01 -ReceiveProtocolLogPath E:\Logs\Frontend

image

New logs are now written to the new path without requiring a restart of any services:

image

Transport Service


We can confirm the current settings by running the command below:

Get-TransportService -Identity LITEX01 | fl Receive*

image

Here we can see that logs are stored for a maximum of 30 days, each log file can grow to 10MB and the maximum log directory size is 250MB. The log path is also listed.

There may be some requirements to store receive connector logs for more than 30 days. In this case, you can increase the maximum directory size to 500MB and the maximum age to 60 days using this command:

Set-TransportService -Identity LITEX01 -ReceiveProtocolLogMaxAge 60.00:00:00 -ReceiveProtocolLogMaxDirectorySize 500MB

image

You can also change the log path. For example, this command changes the log path to E:\Logs\Hub:

Set-TransportService -Identity LITEX01 -ReceiveProtocolLogPath E:\Logs\Hub

image

New logs are now written to the new path without requiring a restart of any services:

image

Disable Receive Connector Logging


When you’re done with troubleshooting, you can disable receive connector logging.
To disable receive connector logging for a single receive connector, e.g. Relay 1 on server LITEX01:

Set-ReceiveConnector “LITEX01\Relay 1” -ProtocolLogging None

image

To disable receive connector logging for all receive connector on a particular server, e.g. server LITEX01:

Get-ReceiveConnector -Server LITEX01 | Set-ReceiveConnector -ProtocolLogging None

image


Conclusion


In this post, I’ve demonstrated how to enable receive connector logging, where to find the logs and how to change logging settings such as the log path and the amount of logs that are stored.

Thursday, 28 January 2016

OWA blank page | Exchange 2013, 2016

Symptoms


You try to log into Outlook Web App (or now called Outlook on the Web) using Exchange 2013 or 2016. You’re presented with a login screen then after you sign in, you are presented with a blank screen. This often happens after a restart or an upgrade. See below:

image

After logging in:

image


Cause


The cause of this is that the Exchange Back End site in IIS on your MBX server is no longer bound to a certificate (SSL certificate “Not Selected”). See below:

image

Resolution


To resolve this issue, open up IIS Manager on your Exchange server:

image

Then right click on Exchange Back End and click on Edit Bindings. You’ll be presented with a list of site bindings.

image

Double click on the https entry in the list. You should now see the below window:

image

In the SSL certificate drop down, select the Microsft Exchange certificate:

image

Click OK then click Close.

You should now be able to log into OWA:

image

Repeat for your other servers if needed.

Wednesday, 27 January 2016

Bindings and RemoteIPRanges parameters conflict | Exchange 2013, 2016

Symptoms


When creating a new receive connector on Exchange 2013 or 2016, you may run into this error:

The values that you specified for the Bindings and RemoteIPRanges parameters conflict with the settings on Receive connector "LITEX01\Default Frontend LITEX01". Receive connectors assigned to different Transport roles on a single server must listen on unique local IP address & port bindings.


image


Cause


When creating a receive connector, you choose one of two roles; either a Hub Transport connector or a Frontend Transport connector, as you can see in the screen shot below:


image


The problem is that the Frontend Transport Service is using port 25 for the Default Frontend Proxy <ServerName> receive connector and if you follow the defaults in the wizard, you’ll end up tying to create a new receive connector using the Transport Service which also listens on port 25. These two services run under different windows processes and they therefore cannot listen on the same port.

Resolution


If you want to create a new receive connector that listen on port 25, you can do this but you have to create them it using the Frontend Transport role if you have either an Exchange 2016 server or an Exchange 2013 server with both the CAS and MBX roles installed on the same server.

Tuesday, 26 January 2016

Receive connector selection | Exchange 2013, 2016

Introduction


In this post, we’ll look at how Exchange selects a receive connector for a particular client connection. We’ll break down this post into the below sections:
  • Default receive connectors
  • Receive connector selection
  • Example scenarios

For more information on how to check which receive connector is in use by Exchange for a particular connection, see here.

Default receive connectors


When Exchange is installed, there are a number of receive connectors that are set up by default. In Exchange 2013, there are two roles (CAS and MBX) but in Exchange 2016 the CAS and MBX roles cannot be installed separately and are merged into one role called the MBX role.

Exchange 2013 has a Front End Transport Service as part of the CAS role and a Transport Service as part of the MBX role. Multi-role Exchange 2013 servers have both the services.

Exchange 2016 is similar to a multi-role Exchange 2013 server in that it has both transport services.


Front End Transport Service Receive Connectors


The Front End Transport Service has three receive connectors. These only proxy connections to the Transport Service (running on Exchange 2013 or 2016 MBX servers):
  • Client Frontend <ServerName>: This receive connector listens on port 587 and is used for authenticated SMTP connections from clients such as POP3 clients. Generally little configuration is done on this receive connector.
  • Default Frontend <ServerName>: This receive connector accepts anonymous connections from external SMTP servers on port 25 and is (or should be) the point at which external messages enter the Exchange organization. (No, you should not be using the Transport Service on an Exchange 2013 MBX server to receive external email. It should be proxied through the Front End Transport Service on the CAS server).
  • Outbound Proxy Frontend <ServerName>: Yes, outbound. This receive connector is not involved in inbound email delivery to the Exchange organization. It’s only used if you have configured your Send Connector to proxy through your front end CAS server/service and is use for outbound email from your Exchange organization. You enable this when creating or configuring your send connector by setting the FrontendProxyEnabled parameter to enabled on the Set-SendConnector or New-SendConnector cmdlets. This receive connector listens on port 717 for outbound email from the Transport Service in the MBX role.

Generally it’s best to leave these receive connectors as they are and create new receive connectors for specific scenarios such as if you need to configure anonymous relay for a list of client IPs. See here if you need more information on how to configure this.

These Front End Transport Service receive connectors are bound to all local and remote IPv4 and IPv6 addresses by default which means that Exchange will listen for connections from any client IP and to any IP configured on the Exchange server.


Transport Service Receive Connectors


The Transport Service (part of the MBX role) has two receive connectors. These are not on standard ports and they don't need to be because they don’t receive connections from clients.
  • Client Proxy <ServerName>: This receive connector listens on port 465 and accepts authenticated connections that are proxied from the Client Frontend <ServerName> receive connector which is part of the Front End Transport Service.
  • Default <ServerName>: This receive connector listens on one of two ports. In Exchange 2013 it listens on port 25 if the MBX role has been installed without the CAS role on the same server and it listens on port 2525 if the CAS and MBX roles are installed on the same server. As Exchange 2016 behaves much like a multi-role Exchange 2013 server, this receive connector listens on port 2525. It is used to accept authenticated connections from the Front End Transport Service, the Transport Service on other MBX servers or connections from Edge Transport Servers. Connections are authenticated using the Exchange server’s self-signed certificate and this is why you shouldn’t delete it. See more here.

As with the Front End Transport Service receive connectors, the Transport Service receive connectors are bound to all local and remote IPv4 and IPv6 addresses which means that Exchange will listen for connections from any IP and to any IP configured on the Exchange server.

Now that we have a better understanding about the default receive connector configuration, we can continue on to receive connector selection.


Receive Connector Selection


As we know, each receive connector includes a number of properties but for the purpose of receive connector selection, we only need to focus on these three properties:
  • Port Binding (the TCP on the  Exchange server that the receive connector listens on)
  • IP Binding (the Exchange server IP that the receive connector listens on)
  • Remote IP ranges (the remote IP range that the receive connector accepts connections from)

The Port and IP binding make up the receive connector binding. E.g. a binding of 0.0.0.0:25 means that the receive connector listens on all IPs for connections on port 25.

You cannot have two receive connectors which have all three properties set to be the same – i.e. you cannot have two receive connectors with the same port binding, IP binding and remote IP ranges configured. If you try to do this, you’ll get the error below:

The values that you specified for the Bindings and RemoteIPRanges parameters conflict with the settings on Receive connector "LITEX01\Relay 1". A Receive connector must have a unique combination of a local IP address & port bindings and remote IP address ranges. Change at least one of these values.

image

There needs to be a difference so that Exchange can select the correct receive connector for the incoming client connection.

While we're here, let’s also define what an SMTP client is. SMTP clients include:
  • Other servers relaying through Exchange using authenticated or anonymous relay
  • Other Exchange organizations sending email through to your organization
  • Incoming external email directly from the internet or via a smart host (mail gateway or mail filter)
  • End user clients which are using SMTP to send email using a POP3 client

Now that we have enough background information, we can start to look at the receive connector selection process. This involves the four steps below:
  • Step 1: Get all receive connectors where the network adapter bindings include the port on the Exchange server that the client is connecting to
  • Step 2: Get all receive connectors identified in step 1 where the network adapter bindings include the IP on the Exchange server that the client is connecting to
  • Step 3: If step 2 identifies more than one receive connector, select the receive connector with the most specific remote IP range which includes the client IP
  • Step 4: If step 3 identifies more than one receive connector, select the receive connector with the most specific IP binding


Example scenarios


In order to explain the selection process, I’ve made up some scenarios and I’ll demonstrate how to figure out the receive connector that is used. In each scenario, we have all the default receive connectors as per the default configuration above but we also have a three custom receive connectors with the below settings:

Custom receive connector 1:
  • Name: Relay 1
  • Port Binding: 25
  • IP Binding: All available IPv4 and IPv6 addresses
  • Remote IP Ranges: 10.2.0.10 - 10.2.0.11 (IP range)

Custom receive connector 2:
  • Name: Relay 2
  • Port Binding: 25
  • IP Binding: All available IPv4 and IPv6 addresses
  • Remote IP Ranges: 10.2.0.10 and 10.2.0.11 (individual IPs)

Custom receive connector 3:
  • Name: Relay 3
  • Port Binding: 25
  • IP Binding: 10.2.0.21
  • Remote IP Ranges: 10.2.0.10 and 10.2.0.11 (individual IPs)

In the below scenarios, our server is either an Exchange 2013 CAS server, an Exchange 2013 multi-role server or an Exchange 2016 server as these all behave the same way in these scenarios. In each scenario, our Exchange server has an IP of 10.2.0.21 and hostname LITEX01.


Scenario 1: A client with IP 105.10.10.10 connects to the Exchange server on port 587 and IP 10.2.0.21 (through the firewall using a NAT rule):

Step 1: Get all receive connectors where the network adapter bindings include the port on the Exchange server that the client is connecting to

When we look through all the receive connectors on the server, we can see that there is only one receive connector bound to port 587: Client Frontend LITEX01

Step 2: Get all receive connectors indentified in step 1 where the network adapter bindings include the IP on the Exchange server that the client is connecting to

Our client is connecting to 10.2.0.21 and the Client Frontend LITEX01 receive connector is bound to all IPv4 and IPv6 IPs so this matches.

Step 3: If step 2 identifies more than one receive connector, select the receive connector with the most specific remote IP range which includes the client IP

We only identified one receive connector in step 2 so we skip this step.

Step 4: If step 3 identifies more than one receive connector, select the receive connector with the most specific IP binding

We only identified one receive connector in step 3 so we skip this step.

Result: The receive connector that is selected is the Client Frontend LITEX01 receive connector.


Scenario 2: A client with IP 105.10.10.10 connects to the Exchange server on port 25 and IP 10.2.0.21 (through the firewall using a NAT rule):

Step 1: Get all receive connectors where the network adapter bindings include the port on the Exchange server that the client is connecting to

When we look through all the receive connectors on the server, we can see that there are four receive connectors bound to port 25:
  • Default Frontend LITEX01
  • Relay 1
  • Relay 2
  • Relay 3

Step 2: Get all receive connectors indentified in step 1 where the network adapter bindings include the IP on the Exchange server that the client is connecting to

The client is connecting to the server on IP 10.2.0.21. All of the receive connectors identified in step 1 are bound to either all IPv4 and IPv6 addresses or to just 10.2.0.21 so they all include the IP the client is connecting to:
  • Default Frontend LITEX01
  • Relay 1
  • Relay 2
  • Relay 3

Step 3: If step 2 identifies more than one receive connector, select the receive connector with the most specific remote IP range which includes the client IP

Relay 1 has a remote IP range which only includes 10.2.0.10 - 10.2.0.11  so cannot be used by the client. Relay 2 has a remote IP range which only includes 10.2.0.10 and 10.2.0.11 so also cannot be used by the client. Relay 3 also has a remote IP range which includes 10.2.0.10 and 10.2.0.11 so also cannot be used by the client. This leaves Default Frontend LITEX01 which has a remote IP range which includes all IPv4 and IPv6 addresses so this is the selected receive connector.

Step 4: If step 3 identifies more than one receive connector, select the receive connector with the most specific IP binding

We only identified one receive connector in step 3 so we skip this step.

Result: The receive connector that is selected is the Default Frontend LITEX01 receive connector.


Scenario 3: A client with IP 10.2.0.10 connects to the Exchange server on port 25 and IP 10.2.0.21

Step 1: Get all receive connectors where the network adapter bindings include the port on the Exchange server that the client is connecting to

When we look through all the receive connectors on the server, we can see that there are four receive connectors bound to port 25:
  • Default Frontend LITEX01
  • Relay 1
  • Relay 2
  • Relay 3

Step 2: Get all receive connectors indentified in step 1 where the network adapter bindings include the IP on the Exchange server that the client is connecting to

The client is connecting to the server on IP 10.2.0.21. All of the receive connectors identified in step 1 are bound to either all IPv4 and IPv6 addresses or to just 10.2.0.21 so they all include the IP the client is connecting to:
  • Default Frontend LITEX01
  • Relay 1
  • Relay 2
  • Relay 3

Step 3: If step 2 identifies more than one receive connector, select the receive connector with the most specific remote IP range which includes the client IP

Relay 1 has a remote IP range set to 10.2.0.10 - 10.2.0.11 so this includes the client IP. Relay 2 has a remote IP range which includes 10.2.0.10 and 10.2.0.11. Relay 3 has a remote IP range which also includes 10.2.0.10 and 10.2.0.11. Default Frontend LITEX01 has a remote IP range which includes all IPv4 and IPv6 addresses so can also be used by the client.

We need to select the most specific IP range that includes the client IP. In this case we have a tie between Relay 2 and Relay 3 which both only have two IPs in the remote IP range whereas Default Frontend LITEX01 includes all IPv4 and IPv6 addresses. Now, your question is “why is Relay 1 not included in this tie? Surely it also includes the same two remote IPs as Relay 2 and Relay 3?” The answer is that you need to look at the range that the IP is in. For receive connector Relay 1 the IP 10.2.0.10 is in a range of two IPs (10.2.0.10 - 10.2.0.11) whereas for receive connectors Relay 2 and Relay 3, the IP 10.2.0.10 is in a range of just one IP (i.e. the two IPs are added as two IP ranges of one IP each). This makes Relay 2 and Relay 3 more specific than Relay 1. So, now we are down to these two receive connectors:
  • Relay 2
  • Relay 3

Step 4: If step 3 identifies more than one receive connector, select the receive connector with the most specific IP binding

Now, which receive connector is actually being used? Well, this is where we look at the IP binding. Relay 2 is bound to all IPv4 and IPv6 addresses whereas Relay 3 is bound to only 10.2.0.21 making it more specific.

Result: The receive connector that is selected is the Relay 3 receive connector.


Conclusion


In this post, we’ve looked at the default receive connectors that are configured when you first install your Exchange 2013 or 2016 server. We’ve also discussed how a receive connector is selected according to client IP and receive connector IP and port bindings.

Monday, 25 January 2016

Which receive connector? | Exchange 2013, 2016

Introduction


In this post, I’ll show you how to work out which receive connector is being used for a particular client SMTP connection in Exchange 2013 and 2016.

Which receive connector is a client SMTP connection using?


To figure this out, we will use receive connector logging. To view the receive connector logs, we first need to enable verbose logging as it's not enabled by default. This is enabled per receive connector so enable logging on each receive connector that you think may be in use.

Enable receive connector logging


To enable receive connector logging for a single receive connector, e.g. Relay 1 on server LITEX01:

Set-ReceiveConnector “LITEX01\Relay 1” -ProtocolLogging Verbose

image

To enable receive connector logging for all receive connector on a particular server, e.g. server LITEX01:

Get-ReceiveConnector -Server LITEX01 | Set-ReceiveConnector -ProtocolLogging Verbose

image

Once enabled, you will start to see log files created in this path for the Front End Transport Service (runs on Exchange 2013 CAS and multi-role servers and also on Exchange 2016 servers): 

"C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive"

And this path for the Transport Service logs (runs on Exchange 2013 MBX and multi-role servers and also on Exchange 2016 servers):

"C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive"

Below is an example of an email sent from mark@domain.com to administrator@litwareinc.com:

2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,0,10.2.0.21:25,10.2.0.10:64590,+,,
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,1,10.2.0.21:25,10.2.0.10:64590,>,"220 litex01.litwareinc.com Microsoft ESMTP MAIL Service ready at Sun, 24 Jan 2016 23:36:55 +0000",
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,2,10.2.0.21:25,10.2.0.10:64590,<,EHLO litdc01,
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,3,10.2.0.21:25,10.2.0.10:64590,>,250  litex01.litwareinc.com Hello [10.2.0.10] SIZE 36700160 PIPELINING DSN ENHANCEDSTATUSCODES STARTTLS 8BITMIME BINARYMIME CHUNKING,
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,4,10.2.0.21:25,10.2.0.10:64590,<,MAIL FROM:<mark@domain.com>,
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,5,10.2.0.21:25,10.2.0.10:64590,*,08D311385B77F991;2016-01-24T23:36:56.545Z;1,receiving message
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,6,10.2.0.21:25,10.2.0.10:64590,>,250 2.1.0 Sender OK,
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,7,10.2.0.21:25,10.2.0.10:64590,<,RCPT TO:<administrator@litwareinc.com>,
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,8,10.2.0.21:25,10.2.0.10:64590,>,250 2.1.5 Recipient OK,
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,9,10.2.0.21:25,10.2.0.10:64590,<,DATA,
2016-01-24T23:36:56.545Z,LITEX01\Relay 3,08D311385B77F991,10,10.2.0.21:25,10.2.0.10:64590,>,354 Start mail input; end with <CRLF>.<CRLF>,
2016-01-24T23:36:56.560Z,LITEX01\Relay 3,08D311385B77F991,11,10.2.0.21:25,10.2.0.10:64590,*,,Proxy destination(s) obtained from OnProxyInboundMessage event


You can see from the above output that the receive connector in use is called LITEX01\Relay 3 (well, you should be able to because it’s highlighted enough times!).

Conclusion


In this post, I’ve demonstrated how you can work out which receive connector is in use by enabling receive connector logging.

Thursday, 21 January 2016

Require SPF Pass for selected senders | Exchange 2013 - 2016

Introduction


In this post, I’ll show you how to partially enable SPF checks by requiring that the SenderID/SPF check is a pass for incoming email from a specified list of domains in Exchange 2013 and Exchange 2016. This is particularly useful if you receive legitimate email from financial institutes or other organizations which may request sensitive information and where these domains are often spoofed but you don't yet want to reject all email that fails the SPF check.

SPF is not a new way of detecting spoofed email but SenderID/SPF checks on incoming mail has not yet been enabled by many of the mail servers across the internet. This may be due to a lack of understanding or confidence in the system. If this includes you then have a read of these posts to get a better understanding:


Ensure that you have completed these steps from How to prevent spoofed email part 1 before continuing:

  • Configure the InternalSMTPServers property on your transport servers
  • Install the Anti-Spam agents on Exchange

How to require an SPF pass for email from particular domains


To do this, we will create a new transport rule to look at the Received-SPF header on incoming email from outiside the organisation that is from our list of domains for which we only want to receive email if they pass the SPF check.

The email headers for an email that passes the SPF check looks like this:

Received-SPF: Pass (svr01.domain.co.uk: domain of reply@sender.com designates 108.14.3.148 as permitted sender)

We will configure our rule to look for the text pattern “Pass ” in the Received-SPF header. Note the additional space on the end to prevent a false positive for any email addresses that include the string “pass”.

First, log into the Exchange Admin Center using an account which is a member of the Organization Management group then click on mail flow in the left pane:

image

Next, click on the + icon, select create a new rule and provide a name for your new rule like “Require SPF Pass”:

image

Once done, click on More options… to make the additional conditions and options visible. We will apply the rule if the sender’s domain is contoso.com or tailspintoys.com. Click on the Apply this rule if… drop down and select the senders’s domain is… then add your domains in the list:

image

Click OK when done. 

Our next step is to apply these rules to only email from outside the organization. To do this, click add condition and then select the sender is external/internal… Select Outside the organization:

image

Click OK. In this next part we’ll configure an action for email that is not an SPF pass. You can select one of many actions:

  • Redirect the email to another mailbox (e.g. a spam mailbox)
  • Forward the message for approval (by an administrator or other)
  • BCC the message to another address
  • Prepend the subject of the message with a string (to notify the user that this email is not from a trusted source)
  • Block the message (with or without an NDR)

In this example, we’ll block the message without sending an NDR to the sender. If you go with this approach, ensure that this sender is always sending email from IPs on their SPF record otherwise you will start to reject legitimate email. If they are not then it’s best to go with one of the less drastic approaches above.

Under the do the following heading, select Block the message…delete the message without notifying anyone as below:

image

Now this blocks all messages from tailspintoys.com and contoso.com originating from outside the organization. We now want to make an exception so that we allow only those emails that have a Pass in the Received-SPF header field. To do this, click on add exception then select A message header…matches these text patterns

image

Click on Enter text… and enter Received-SPF to provide the header name:

image

Click OK then click on Enter text patterns…. Set the text pattern to “Pass ” (yes, there is a space after the word Pass) then click the + icon:

image

Click OK then click on Save.

Conclusion


In this post, I’ve demonstrated how to set up a new transport rule in Exchange to ensure email from particular domains are only delivered if they pass the SPF checks.