{"id":78,"date":"2013-01-24T23:06:09","date_gmt":"2013-01-24T22:06:09","guid":{"rendered":"http:\/\/dizdarevic.ba\/ddamirblog\/?p=78"},"modified":"2013-01-24T23:08:43","modified_gmt":"2013-01-24T22:08:43","slug":"configuring-domain-security-on-exchange-server-2013","status":"publish","type":"post","link":"https:\/\/dizdarevic.ba\/ddamirblog\/configuring-domain-security-on-exchange-server-2013\/","title":{"rendered":"Configuring Domain Security on Exchange Server 2013"},"content":{"rendered":"

A need to protect SMTP traffic is not uncommon. In general, you can\u2019t always protect it. Inside your organization, it\u2019s pretty easy \u2013 you can easily implement digital signatures or encryption for emails, but if you want to go outside, things are becoming more complicated. You can still use digital signing (S\/MIME) on emails, but if your certificate is issued by your internal PKI, it probably won\u2019t be trusted on recipient side. That will not prevent functionality of digital signature, but will affect trust.<\/p>\n

If you want to send encrypted emails outside your organization, things are even more complicated. If you want to use just built-in Outlook features for message encryption, you will need to have public key of any recipient that you want to send encrypted message to. Inside your organization, this is not an issue as you can publish certificates in AD DS. However, outside, on the Internet this is not an easy job. Sure, there are some third party tools for this, but let\u2019s see what we can do without them.<\/p>\n

Domain Security is a feature of Exchange Server (both 2010 and 2013) that can secure SMTP traffic between two Exchange organizations. It is implemented on server level, and it works without configuring any options on user (sender or recipient) side. Domain Security uses mutual TLS authentication to provide session-based authentication and encryption. Mutual TLS authentication is different from TLS as it’s usually implemented. Usually, when you implement TLS, client will verify the server certificate, and authenticate the server, before establishing a connection.<\/p>\n

With mutual TLS authentication, each server verifies the connection with the other server by validating a certificate that’s provided by that other server, so clients are not included at all. We establish secure SMTP channel between two Exchange Servers, usually over the Internet.
\nClients, Outlook and Outlook Web App, will be aware that Domain Security is established. Green icon with check mark will be shown on each messages exchanged between servers on which Domain Security is implemented.<\/p>\n

\"Capture1\"<\/a><\/p>\n

As you can see, Domain Security can be applied between two (or more) known Exchange organizations. Still, it can\u2019t protect whole SMTP traffic that comes and goes from your Exchange organization, but it can efficiently protect SMTP traffic between partner organizations.<\/p>\n

Let\u2019s see how to configure it. I\u2019ll show the procedure for Exchange Server 2013, but most of it can be applied to Exchange Server 2010 also. Let\u2019s assume that we want to establish Domain Security between two Exchange organizations named adatum.com and treyresearch.net (Yes, I\u2019m using domain names from Microsoft Learning courses, but since I write these courses, I just get used to that \"Smile\")<\/p>\n

1. Establish certificate trust between organizations<\/strong><\/p>\n

As said before, Domain Security relies on certificates. Because of this, you should first establish certificate trust between two organizations where you want to implement Domain Security. You can do it on several ways. If both organizations are using publicly trusted certificate on Exchange servers, you are good to go. If that\u2019s not the case you will have to cross-import Root CA certificates on both sides. Alternatively, you can also issue certificates for SMTP for both Exchange organization from a single trusted RootCA. Anyway, the point is that each Exchange server must trust the certificate installed (and assigned to SMTP service) on another Exchange server. Achieve this in any way you like. Besides establishing trust, make sure that certificate common name is same as the name that Exchange server provides in HELO\/EHLO conversation.<\/p>\n

However, it\u2019s important to notice one thing here. In Exchange Server 2010, you would be doing this on Edge Transport server or if you didn\u2019t deploy one, on Hub Transport server. Since these two roles are no more in Exchange 2013, these certificates should be installed on CAS servers which, in Exchange Server 2013, host FrontEnd Transport Service. Also, it is important that certificate you want to use for Domain Security is assigned to SMTP (it can be assigned to other services as well)<\/p>\n

\"Capture2\"<\/a><\/p>\n

2. Configure Domain Security<\/strong><\/p>\n

As both sides\/companies will be sending and receiving emails, following procedure should be done on both sides, but domain names should be used vice-versa.<\/p>\n

First, open Exchange Management Shell and execute this cmdlet :
\n
\nGet-TransportConfig | FL<\/strong><\/p>\n

You will get whole list of transport settings but we want two of them : TLSReceiveDomainSecureList and TLSSendDomainSecureList. If you were not configuring Domain Security so far, you will have these two values empty. To use Domain Security we must populate these parameters with appropriate values.
\nTLSReceiveDomainSecureList – specifies the domains from which you want to receive domain secured email by using mutual Transport Layer Security (TLS) authentication
\nTLSSendDomainSecureList – specifies the domains from which you want to send domain secured email by using mutual TLS authentication<\/p>\n

If we are on adatum.com side, we will execute following:<\/p>\n

Set-TransportConfig -TLSSendDomainSecureList adatum.com <\/strong>and
\nSet-TransportConfig \u2013TLSReceiveDomainSecureList treyresereach.net<\/strong><\/p>\n

After this, when you run the Get cmdlet again you should have these values:<\/p>\n

\"Capture3\"<\/a><\/p>\n

Logically, on treyresearch side we will issue same commands but domains will be inverted. If you have more than one company with requirement for Domain Security, you can provide their domain names too. This cmdlet accepts multivalued parameters.<\/p>\n

3. Configure connectors<\/strong><\/p>\n

Now, we will create dedicated connectors for Domain Security. Let\u2019s first create the send connector. You can use Exchange Admin center for this. Navigate to mail flow, click Send connectors and add new one. In a wizard, type the name of the connector and select Partner type. Don\u2019t use the smart host, but leave MX record as a method to send mail. For connector address space, type the domain name from other Exchange organization. If you are on Adatum.com side, you will type treyresearch.net. On the source server page of wizard, select Mailbox server that you want to use as a source. It doesn\u2019t matter which one you will choose since we will configure connector to proxy through CAS. When you create the connector, double click it and then enable options \u201cProxy through client access server\u201d. You can also configure maximum message size for this connector if you want, and enable protocol logging.<\/p>\n

\"Capture4\"<\/a><\/p>\n

Now back to Exchange Management Shell,and execute :<\/p>\n

Get-SendConnector \u2013identity ConnectorName | <\/em>FL<\/strong><\/p>\n

Look for the value of parameter DomainSecureEnabled. It should be True. If it\u2019s not you can easily set it with Set-SendConnector \u2013identity ConnectorName<\/em> \u2013DomainSecureEnabled:$true<\/strong><\/p>\n

Let\u2019s now configure Receive connector. Back to EAC, click mail flow and then click receive connectors. In Select server drop-down list choose your Client Access server.<\/p>\n

Select Partner for connector type, configure receiving IP address if you want (or just leave all available) but on remote network settings page, you should configure only the IP address assigned to another organization Exchange server. This should be (public) IP from which partner\u2019s Exchange server sends email. After you create the connector double click it, and click on security tab. Make sure that authentication options are set like on following screenshot.<\/p>\n

\"Capture5\"<\/a><\/p>\n

4. Test the Domain Security<\/strong><\/p>\n

Easiest way to test this is to just send email from one organization to another from Outlook. If you get the message with green check mark, you are all set. If not, then you\u2019ll need some troubleshooting. You can enable protocol logging by executing :<\/p>\n

Set-ReceiveConnector Internet -ProtocolLoggingLevel Verbose<\/strong>, and<\/p>\n

Set-SendConnector Internet -ProtocolLoggingLevel Verbose<\/strong><\/p>\n

to verify TLS channel. If message doesn\u2019t arrive to recipient but doesn\u2019t come back as NDR, you should check queue.<\/p>\n

Or you can just wait for my next blog post, where I will discuss some troubleshooting \"Smile\".<\/p>\n","protected":false},"excerpt":{"rendered":"

A need to protect SMTP traffic is not uncommon. In general, you can\u2019t always protect it. Inside your organization, it\u2019s pretty easy \u2013 you can easily implement digital signatures or encryption for emails, but if you want to go outside, things are becoming more complicated. You can still use digital signing (S\/MIME) on emails, but … Continue reading “Configuring Domain Security on Exchange Server 2013”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[6],"tags":[],"class_list":["post-78","post","type-post","status-publish","format-standard","hentry","category-exchsrv"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p33Rch-1g","_links":{"self":[{"href":"https:\/\/dizdarevic.ba\/ddamirblog\/wp-json\/wp\/v2\/posts\/78","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dizdarevic.ba\/ddamirblog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dizdarevic.ba\/ddamirblog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dizdarevic.ba\/ddamirblog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dizdarevic.ba\/ddamirblog\/wp-json\/wp\/v2\/comments?post=78"}],"version-history":[{"count":1,"href":"https:\/\/dizdarevic.ba\/ddamirblog\/wp-json\/wp\/v2\/posts\/78\/revisions"}],"predecessor-version":[{"id":79,"href":"https:\/\/dizdarevic.ba\/ddamirblog\/wp-json\/wp\/v2\/posts\/78\/revisions\/79"}],"wp:attachment":[{"href":"https:\/\/dizdarevic.ba\/ddamirblog\/wp-json\/wp\/v2\/media?parent=78"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dizdarevic.ba\/ddamirblog\/wp-json\/wp\/v2\/categories?post=78"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dizdarevic.ba\/ddamirblog\/wp-json\/wp\/v2\/tags?post=78"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}