220 BL2FFO11FD032.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Mon, 28 Mar 2016 22:55:58 +0000

ehlo smtp.contoso.com

250-BL2FFO11FD032.mail.protection.outlook.com Hello [167.220.148.211] 250-SIZE 157286400

250-PIPELINING

250-DSN

250-ENHANCEDSTATUSCODES

250-STARTTLS

250-8BITMIME

250-BINARYMIME

250 CHUNKING

MAIL FROM: <>

250 2.1.0 Sender OK

RCPT TO: UserMailbox@contoso.com

250 2.1.5 Recipient OK

data

354 Start mail input; end with <CRLF>.<CRLF>

Hello World!

.

550 5.7.512 Access denied, message must be RFC 5322 section 3.6.2 compliant and include a valid From address

Last updated January 6th 2016

=================================================================

 Combating email spoofing can be tricky, what is right for another organization may not necessarily be right for your organization; moreover, it’s always important to understand you will never be able to block 100% of spoof attacks 100% of the time.

We recommend, when developing the strategy that is best for you, to look at these four areas:

SPF/DKIM/DMARC

The link below provides guidance on Using DMARC in Office 365

https://blogs.msdn.com/b/tzink/archive/2014/12/03/using-dmarc-in-office-365.aspx 

DKIM outbound signing is now enabled for your default onmicrosoft.com domain. But in order to enable for vanity domains in which you manage the DNS you must add the two CNAME records as outlined in the article below.

External DNS records required for SPF

   https://support.office.com/en-us/article/External-Domain-Name-System-records-for-Office-365-c0531a6f-9e25-4f2d-ad0e-a70bfef09ac0#BKMK_SPFrecords

Customize an SPF record to validate outbound email sent from your domain

https://technet.microsoft.com/en-us/library/dn789058(v=exchg.150).aspx

User Education

Even with the most restrictive settings it is import to educate your user community to be able to spot red flags of spoofing attempts. If for whatever reason your user gets an email from itsupport@cont0so.com     they should be able to identify it does not look like legitimate email from your IT support staff.

Connection/SPAM Filters/Transport Rules

The links below provide in depth guidance on configuring your SPAM filters and advanced features that can help fine tune them to your specific needs

Configure the connection filter policy

** You can add IP  here to bypass filtering for email from these trusted sources if, and only if, those sources are already scanning/filtering mail before sending it on.

https://technet.microsoft.com/en-us/library/jj200718(v=exchg.150).aspx

Configure your spam filter policies

https://technet.microsoft.com/en-us/library/jj200684(v=exchg.150).aspx 

Advanced Spam Filtering Options

**Proceed with caution setting some of the features and they can be very restrictive and generate a lot of false positives, especially the option to quarantine SPF hard fail.

https://technet.microsoft.com/en-us/library/jj200750(v=exchg.150).aspx  

(Not) Using the Additional Spam Filtering option for SPF hard fail to block apparently internal email spoofing

https://blogs.msdn.com/b/tzink/archive/2015/07/21/not-using-the-additional-spam-filtering-option-for-spf-hard-fail-to-block-apparently-internal-email-spoofing.aspx

Contingency/Action plans

As stated earlier you will never be able to block 100% of malicious email 100% of the time. When malicious/spoofed email does get though, develop an action plan including but not limited to:

•        Resetting the password on any compromised accounts

•        Running Malware/virus scans on affected machines

•        Using the Search-Mailbox to seek out and delete identified malicious email - https://technet.microsoft.com/en-us/library/dd298173(v=exchg.150).aspx   

•        Using Transport rules to help suppress the subsequent delivery of identified messages.

•        Using transport rules to block executable content:  https://blogs.msdn.com/b/tzink/archive/2014/04/08/blocking-executable-content-in-office-365-for-more-aggressive-anti-malware-protection.aspx 

•        Submit sample messaged to Microsoft for analysis https://technet.microsoft.com/en-us/library/jj200769.aspx

•        Submit suspected malware to our protection center https://www.microsoft.com/security/portal/submission/submit.aspx

Some additional related links:

Anti-spam and anti-malware protection

https://technet.microsoft.com/en-us/library/jj200731(v=exchg.150).aspx

Best practices for configuring EOP

https://technet.microsoft.com/en-us/library/jj723164(v=exchg.150).aspx

Terry Zink: Security Talk. Terry is one of our program managers EOP.

https://blogs.msdn.com/b/tzink/

As stated the sample below is very basic and will Impersonate the desired mailbox and list some very basic information on the inbox It is a great start or foundation for any script you need to write where impersonation is necessary.

## Define UPN of the Account that has impersonation rights

$AccountWithImpersonationRights = "AccountWithImpersonationRights@contoso.onmicrosoft.com"

##Define the SMTP Address of the mailbox to impersonate

$MailboxToImpersonate = "MailboxToImpersonate@contoso.onmicrosoft.com"

## Load Exchange web services DLL

## Download here if not present: https://go.microsoft.com/fwlink/?LinkId=255472

$dllpath = "C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll"

Import-Module $dllpath

## Set Exchange Version

$ExchangeVersion = [Microsoft.Exchange.WebServices.Data.ExchangeVersion]::Exchange2013

## Create Exchange Service Object

$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService($ExchangeVersion)

#Get valid Credentials using UPN for the ID that is used to impersonate mailbox

$psCred = Get-Credential

$creds = New-Object System.Net.NetworkCredential($psCred.UserName.ToString(),$psCred.GetNetworkCredential().password.ToString())

$service.Credentials = $creds

## Set the URL of the CAS (Client Access Server)

$service.AutodiscoverUrl($AccountWithImpersonationRights ,{$true})

##Login to Mailbox with Impersonation

Write-Host 'Using ' $AccountWithImpersonationRights ' to Impersonate ' $MailboxToImpersonate

$service.ImpersonatedUserId = New-Object Microsoft.Exchange.WebServices.Data.ImpersonatedUserId([Microsoft.Exchange.WebServices.Data.ConnectingIdType]::SmtpAddress,$MailboxToImpersonate );

#Connect to the Inbox and display basic statistics

$InboxFolder= new-object Microsoft.Exchange.WebServices.Data.FolderId([Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox,$ImpersonatedMailboxName)

$Inbox = [Microsoft.Exchange.WebServices.Data.Folder]::Bind($service,$InboxFolder)

Write-Host 'Total Item count for Inbox:' $Inbox.TotalCount

Write-Host 'Total Items Unread:' $Inbox.UnreadCount

https://msdn.microsoft.com/en-us/library/jj984325.aspx

A lot of these reports can be very useful in troubleshooting your environment. Especially the connection oriented ones for troubleshooting application connectivity into Office 365. Which is a big generator of support calls we see into Tier 3 support!

I will be adding some PowerShell snippets to this blog post soon...

Once the DIRSYNC tool was installed (which is downloaded from your admin account for O365) I ran the configuration wizard to setup directory synchronization.

After clicking the next button the tool failed, and give me a very informative error.  :)

So I took its advice and went and checked the Windows application log. Low and behold, the problem stuck out like a sore thumb. The forward proxy/TMG 2010 server, or as it’s referred to in the description “Remote Server”, I was connecting through has HTTPS inspection turned on. I will talk a bit more later why this is an issue.

Log Name:      Application

Source:        Directory Synchronization

Date:          12/20/2013 11:44:55 AM

Event ID:      0

Task Category: None

Level:         Error

Keywords:      Classic

User:          N/A

Computer:      DIRSYNC.xxxxx-xxxxxxxx.com

Description:

The remote server returned an unexpected response: (502) Proxy Error ( The Web site requires a client certificate, but a client certificate cannot be supplied when HTTPS inspection is applied to the request.   ).

Event Xml:

<Event xmlns="https://schemas.microsoft.com/win/2004/08/events/event">

<System>

<Provider Name="Directory Synchronization" />

<EventID Qualifiers="0">0</EventID>

<Level>2</Level>

<Task>0</Task>

<Keywords>0x80000000000000</Keywords>

<TimeCreated SystemTime="2013-12-20T17:44:55.000000000Z" />

<EventRecordID>1248</EventRecordID>

<Channel>Application</Channel>

<Computer>DIRSYNC.xxxxx-xxxxxxxx.com</Computer>

<Security />

</System>

<EventData>

<Data>The remote server returned an unexpected response: (502) Proxy Error ( The Web site requires a client certificate, but a client certificate cannot be supplied when HTTPS inspection is applied to the request.   ).</Data>

</EventData>

</Event>

Below you can also see the error in the TMG log as well

Denied Connection

12/20/2013 11:44:55 AM

Log type: Web Proxy (Forward)

Status: 12229 The Web site requires a client certificate, but a client certificate cannot be supplied when HTTPS inspection is applied to the request.

Rule: Anonymouse Access To Web Source: Internal (10.10.10.9:51269)

Destination: External (157.56.55.72:443)

Request: POST adminwebservice.microsoftonline.com

Filter information: Req ID: 0a18f9a4; Compression: client=No, server=Yes, compress rate=0% decompress rate=0%

Protocol: https-inspect

User: anonymous

Object source: Internet (Source is the Internet. Object was added to the cache.)

Cache info: 0x0

Processing time: 63 MIME type: -

This is more like it. As you can see the error clearly states this is a proxy configuration issue, and HTTPS inspection needs to be turned off. HTTPS inspection is not compatible with servers that require a client certificate. So be armed with this error (and this blog post) when you go request that your proxy admin remove HTTPS inspection.

Removing HTTPS inspection on TMG 2010

So while this talks specifically about TMG, most 3^rd party proxy solutions will allow you to make HTTPS inspection exceptions.

• Log into TMG and open the management console and click "configure HTTPS" inspection" in the right pane.

  

   

   

• You have two ways to tackle this, by source host or by destination address. I chose by source exceptions because my many years of supporting Exchange and TMG have emphasized the cliché of an “ounce of prevention is worth a pound of cure.” Keep in mind either method will work, but if you choose or your company’s policy is to make exceptions by remote domain, should any of those remote domain names change in the future (which is outside of your control) your DIRSYNC may break if you do not actively go in once you get notice said change may occur and update your remote exceptions.

  

   

• Add your source host in the list. Click “Ok” and then click the “Apply” button to commit the change to the TMG configuration database.

  

   

• One more thing before you swing back to your DIRSYNC server is to check to make sure the TMG CSS has been updated. Select the monitoring in the left pane, and then select configuration. Make sure the status is “Synced” and the description is “Server configuration matches the stored configuration.” If you have an array make sure all array members have sync’d with the CSS.

  

   

   

• Now jump back to your DIRSYNC server, re-run the wizard and bam! It works!!

  

   

   

   

  So why does HTTPS inspection on a Forward Proxy not allow the DIRSYNC tool to work?

   

  Long story short here, the certificate on the remote web server you are (DIRSYNC tool in this case) connecting to states “Client Authentication (1.3.6.1.5.5.7.3.2)”   in the Enhanced Key Usage field of its certificate. So HTTPS inspection breaks this because of the way it works.

  

  In order for TMG to inspect the clients HTTPS request it must be able to decrypt it. So in order to do this TMG establishes a new HTTPS connection between itself and the client using a certificate signed by its own CA. (See picture below). Once this happens it is then able to read the contents of the clients request and apply filtering rules based on the policy setup by proxy administrator. If TMG determines everything looks good it will then establish a second HTTPS session with the remote web server which will allow it to inspect the return traffic. Because the remote web server requires client authentication to prove the identity of the client the web server is talking with TMG will not continue the SSL session. Therefore disabling HTTP inspection creates an SSL tunnel directly between the Server and client allowing the two way authentication and establishing a highly secure link between the two systems to synchronize your directory with your Azure/O365 directory.

  

Further Reading

RFC 2459

Windows PKI Documentation Reference and Library

Planning for HTTPS inspection