Outlook 2007 Will Continue To Work With Office 365 After October 31, 2017

Microsoft has recently changed text on their RPC over HTTP End-Of-Life page that originally claimed it will not allow Outlook 2007 to connect to Office 365. The new text has been updated to say

RPC over HTTP, also known as Outlook Anywhere, is a legacy method of connectivity and transport between Outlook for Windows and Exchange. In May 2014, Microsoft introduced MAPI over HTTP as a replacement for RPC over HTTP.

Starting on October 31, 2017, RPC over HTTP will no longer be a supported protocol for accessing mail data from Exchange Online. Starting on this date, the following conditions will apply:

  1. Microsoft will not provide support for RPC over HTTP issues (regular or custom).
  2. No code fixes or updates to resolve problems that are unrelated to security will be released.

Additionally, for Office versions that support MAPI over HTTP, Microsoft may elect to override existing registry keys that customer are using in order to force RPC over HTTP use.

Keyword here: support. This essentially means that nothing will happen to users of Outlook 2007 and Office 365, but Microsoft will no longer support the protocol (AKA they won’t support Outlook 2007 connections)

It is still a good idea to move users away from Outlook 2007. We feel any calls to Office 365 with Outlook 2007 running will be met with resistance from the support staff. Additionally, Microsoft may change their stance on this in the future.

Use this Powershell script to check all your tenants for Outlook 2007 connections.


CSSI provides businesses with IT services including Office 365 support and migrations. Contact CSSI for more information on how you can improve your Office 365 infrastructure!

Example of how SonicWall Prevents Ransomware For Businesses

Bad Rabbit Ransomware Automatically Mitigated by SonicWall Capture Advanced Threat Protection

On Tuesday, Oct. 24, a new strand of ransomware named Bad Rabbit appeared in Russia and the Ukraine and spread throughout the day.

SonicWall Capture Labs threat researchers investigated Bad Rabbit and the proficiency of the SonicWall Capture Advanced Threat Protection (ATP) sandboxing service against the previously unknown ransomware. Analyzing three different Bad Rabbit samples, the multi-engine Capture ATP successfully stopped all three attacks.

The SonicWall Capture ATP sandboxing service is designed to provide real-time protection against new strains of malware even before signatures are available on firewalls.

In addition, the SonicWall Capture Labs released signatures to protect customers against Bad Rabbit malware. These signatures are available to SonicWall firewall customers with an active Gateway Security subscription (GAV/IPS) and are applied automatically. More info here.


CSSI is a SonicWall Partner and has many customers with SonicWall firewalls and active security subscriptions. CSSI technicians have training in SonicWall networking and have Certified SonicWall Security Administrator (CSSA). Contact us today to protect your business from ransomware!

 

Fix For Ctrl Shift V to Move Outlook Emails Stopped Working

Today I ran into a small issue where I couldn’t use ctrl+shift+v to move emails. Instead of giving me the move dialog, I was getting a new email with pasted text in it.

It turns out, this was because I recently installed, Clipdiary, a clipboard history utility for Windows.

To fix this, go to File – Options – Hot Keys. Put a check next to ‘Win’ on ‘Paste current clipboard contents as plain text’. As you can see, what you are doing is telling Clipdiary to not use Ctrl+Shift+V for pasting the clipboard contents as plain text (stealing the hotkey from Outlook), instead use Win+Ctrl+Shift+V.

Shopify breaks email for whole domain

Shopify and Google G Suite broke everything email:

Today we had a client that reported ALL internal email from one user to another user was going to SPAM folder.  Our monitoring had caught the issue as well, and we were working on fixing the issue.  So what happened to break all the email? First, the client’s email is hosted by G Suite.  After a bit of tracking, found out that Shopify SPF broke everything.  How exactly is it possible that Shopify broke the client’s G Suite internal user to user email?

SPF and DMARC

Our customer’s SPF record was: “v=spf1 include:shops.shopify.com include:_spf.google.com include:sendgrid.net ~all”  and our DMARC record was: “v=DMARC1; rua=mailto:secretkey@cssi.us; ruf=mailto:secretkey@cssi.us; p=quarantine; sp=none; fo=1;”

Earlier this week (up to yesterday) shops.shopify.com had an SPF record.  Today it does not.  Earlier this week, everything email was working well.  Today is not.  So what was happening today:

  1. One G Suite user would send email to another internal G Suite user (at the same company and same domain).
  2. The outgoing G Suite server would send it ‘out’ to the incoming G Suite server.
  3. The incoming G Suite server would then receive the email, look up the SPF record.
  4. Then it gets a little more complex – G Suite would “permerror” the entire SPF record lookup, just because one of the includes did not resolve.
  5. The receiving G Suite server would lookup the Dmarc – see our Quarantine policy and put the email in the spam folder.

Should G Suite have created a “permerror” and flagged the email (from G Suite mind you) just because one unrelated record (from Shopify) did not look up?  In my opinion NO!  RFC 7208 also has recommendations about ‘void’ lookups (aka RCODE 0 or 3), and the RFC does recommend limiting ‘void’ lookups to TWO before giving a “permerror”.  But it appears that G Suite is limiting to a single ‘void’ lookup before completely giving up and issuing a “permerror”.  Not good in this case!!

Of course the root problem was the Shopify SPF record disappearing and that record is required for the Internet to receive validated email.  But G Suite is still fragile as demonstrated by being broken so easily.  Still annoying that I had to a spend a couple of hours on this just to keep email flowing and inform everyone what was going on.  Shopify has to fix their problem, but it would be nice if Google updated code so it does not break G Suite when an external company makes a mistake.

 

 

Troubleshooting

We monitor all records and email, allowing us to catch the records issue quickly – but not before a few internal emails went to spam.  Worse is that some emails to customers (from GSuite, sendgrid.net and Shopify) were rejected outright – like purchase receipts!  This effected all email for the domain – how it was treated depended on the receiving email servers – some put it in Junk, some rejected the email outright.

Especially ironic that internal emails within the same domain were put in Spam folder.

Temporary Resolution

We removed Shopify from our SPF record and I recommend you do the same.  Then we had to set our DMARC record policy to “none”.  The first fixed the issue with receiving G Suite email.  The second is a fix for Shopify (otherwise those emails would have been sent to spam).  So for the moment that domain’s email sending is not as secure as we would like, but we have to wait for Shopify to fix things.

Permanent fix

I guess we have to keep checking the Shopify record and see if it gets fixed.  We will check it every day and see when they fix it.  (We also opened a ticket with Shopify which they said got ‘escalated’.)

As for Google – there is no easy way for us to externally know if they have updated the void lookup problem – but hopefully they will so this is not such a problem in the future.

Shopify Response

Update: Shopify got back to us and told us it was our fault and said the order of our SPF TXT record elements was wrong.  This is non-sense, email receivers evaluate all SPF “includes:”, regardless of order.  SHOPIFY has their SPF record for shops.shopify.com MISSSING IN ACTION and they need to put it back or everything will remain broken.

Why are some large companies that rely on email as a core part of their business so clueless about what is these days just basic functionality?

How To Connect to Sonicwall VPN With NetExtender

 

Likely you are on this page because you are trying to connect to NetExtender, Sonicwall’s preferred VPN software. Below are the steps to connect to your Sonicwall’s VPN.

SonicWall NetExtender Login Screen

    1. Download and install NetExtender. This can be downloaded through mysonicwall.com or via a link we sent you.
    2. After installing, run NetExtender.
    3. For Server: enter the server name provided for you by your technician. This is typically followed by a :portnumber, which by default is 4433.
    4. For Username: enter the server name provided for you by your technician.
    5. For Password: enter the password provided for you by your technician.
    6. For Domain: enter the domain name provided for you by your technician. This is commonly LocalDomain.
    7. Click Connect.
    8. You will likely get a Security Alert. You can accept or Always Trust this alert in most cases. (If you click Always Trust you will not receive a Security Alert in the future.)Optional Step (skip if not necessary): An extra (unnecessary) step for further validation before accepting this certificate, you can click on View Certificate, click Details, and click on Issuer. You should see “HTTPS Management Certificate for SonicWALL (self-signed)“.

      A common security alert from SonicWall NetExtender.

    9. Click Connect again.
    10. You should now be connected to your network!

Powershell Script to Check if Office 365 Tenants (Partners) Are Using Outlook 2007 – Run Before October 31, 2017

UPDATE: Microsoft has softened their stance and are not going to cut-off Outlook 2007 connections. More info here.

Microsoft recently announced ‘RPC over HTTP reaches end of support in Office 365 on October 31, 2017‘. “MAPI over HTTP was not backported to Outlook 2007 or earlier versions. If you’re using Outlook 2007, you will be in an unsupported state on October 31, 2017. If you want to continue to access Exchange Online mailboxes through the Office 365 portal (portal.office.com), we recommend that you move to a current version of Outlook that is under mainstream support, or use Outlook on the web.”

This basically means if anyone is using Outlook 2007, they need to upgrade their Outlook to a newer version to continue using Outlook with Office 365.

Microsoft provided some Powershell scripts to help with checking your organization for Outlook 2007 connections. This is clearly documented in the section titled ‘How can I identify which Outlook version and build number my users are connecting with?‘ If you only have one organization to manage, these Powershell commands are your best bet.

But what about if you manage multiple organizations as a partner/delegated admin? Microsoft doesn’t offer a solution for this. Since we manage multiple Office 365 tenants and want our customers to get email on November 1st we wrote a little script to check all tenants for Outlook 2007 connections.

Show Auditing

The first step is to document who has auditing turned on or off. This way, you can return auditing back to the client’s preferred setting if necessary. Auditing is turned off by default in Office 365. For this, we wrote the function “ShowAuditing”.

function ShowAuditing{
    foreach($Domain in $Domains){
        # Connect to partner domain
        Write-Host "Connecting to $Domain"
        $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell-liveid?DelegatedOrg=$Domain -Credential $UserCredential -Authentication Basic -AllowRedirection
        Import-PSSession $Session
        Write-Host "Session connect complete"
        Get-Mailbox | Select-Object Identity, AuditEnabled, AuditOwner
        Get-PSSession | Remove-PSSession
    }
}

Enable Auditing

The next step is to enable auditing on every mailbox. For this, we wrote the function “EnableAuditing”. After enabling auditing you will have to wait a few days for users to connect to Office 365 and have their connections logged. Microsoft says auditing may take 24 hours to turn enable.

# Function to enable auditing on every mailbox on every domain.
function EnableAuditing{
    foreach($Domain in $Domains){
        # Connect to partner domain
        Write-Host "Connecting to $Domain"
        $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell-liveid?DelegatedOrg=$Domain -Credential $UserCredential -Authentication Basic -AllowRedirection
        Import-PSSession $Session
        Write-Host "Session connect complete"

        Get-Mailbox | Set-Mailbox -AuditOwner MailboxLogin -AuditEnabled $true
        Get-PSSession | Remove-PSSession
    }
}

Search Through All Tenants, Find Users Using Outlook 2007

At this point, you should have waiting 24 hours for auditing to turn on and 2-3 days for users to connect to Office 365 and have their connections logged in auditing. Finally, we can loop through each tenant and see who is using Outlook 2007. This will create a file called “UnsupportedOutlookConnections.csv” in the same folder you are running this script from.

# Function to check each partner managed domain for unsupported Outlook connections (2003 and 2007), dump to UnsupportedOutlookConnections.csv in current folder
function SearchOutlookUnsupported{
    # Create a new CSV/wipe out the old one
    Write-Host "" | export-csv .\UnsupportedOutlookConnections.csv

    foreach($Domain in $Domains){
        # Connect to partner domain
        Write-Host "Connecting to $Domain"
        $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell-liveid?DelegatedOrg=$Domain -Credential     $UserCredential -Authentication Basic -AllowRedirection
       Import-PSSession $Session
        Write-Host "Session connect complete"
       # Dig through the audits and look for version 12.x
       # Outlook 2007 is 12.x - bad
       # Outlook 2010 is 14.x - good
       Get-Mailbox | Search-MailboxAuditLog -LogonTypes owner -ShowDetails | ? { $_.ClientInfoString -like "*Outlook 12*" } | select MailboxOwnerUPN,Operation,LogonType,LastAccessed,ClientInfoString | export-csv -Append .\UnsupportedOutlookConnections.csv
       Get-PSSession | Remove-PSSession
    }
}

The Full Script

Now that you have read through the code and have an understanding of what it will do – show you who has auditing turned on, enable auditing on all mailboxes, and check each mailbox to see if the user is connecting with Office 2007 – you can run it. We have run this on our clients without issue. CSSI provides no warranty. Run at your own risk.

# Office 365 Parter Outlook Unsupported Checker
#
# cssi.us
#
# By default this script does nothing but connect to MSOL. Go to the bottom of the script to uncomment appropriate lines.
# Microsoft says it can take up to 24 hours for auditing to be enabled. You should enable auditing and wait a few days so you can log the connections.

#### Functions ####
# Function to check if tenants have Auditing Enabled. Good for documenting before/after.
function ShowAuditing{
    foreach($Domain in $Domains){
        # Connect to partner domain
        Write-Host "Connecting to $Domain"
        $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell-liveid?DelegatedOrg=$Domain -Credential $UserCredential -Authentication Basic -AllowRedirection
       Import-PSSession $Session
       Write-Host "Session connect complete"
       Get-Mailbox | Select-Object Identity, AuditEnabled, AuditOwner
       Get-PSSession | Remove-PSSession
    }
}

# Function to enable auditing on every mailbox on every domain.
function EnableAuditing{
    foreach($Domain in $Domains){
        # Connect to partner domain
        Write-Host "Connecting to $Domain"
        $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell-liveid?DelegatedOrg=$Domain -Credential $UserCredential -Authentication Basic -AllowRedirection
        Import-PSSession $Session
        Write-Host "Session connect complete"

        Get-Mailbox | Set-Mailbox -AuditOwner MailboxLogin -AuditEnabled $true
        Get-PSSession | Remove-PSSession
    }
}

# Function to check each partner managed domain for unsupported Outlook connections (2003 and 2007), dump to UnsupportedOutlookConnections.csv in current folder
function SearchOutlookUnsupported{
    # Create a new CSV/wipe out the old one
    Write-Host "" | export-csv .\UnsupportedOutlookConnections.csv

    foreach($Domain in $Domains){
        # Connect to partner domain
        Write-Host "Connecting to $Domain"
        $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell-liveid?DelegatedOrg=$Domain -Credential $UserCredential -Authentication Basic -AllowRedirection
        Import-PSSession $Session
        Write-Host "Session connect complete"

        # Dig through the audits and look for version 12.x
        # Outlook 2007 is 12.x - bad
        # Outlook 2010 is 14.x - good
        Get-Mailbox | Search-MailboxAuditLog -LogonTypes owner -ShowDetails | ? { $_.ClientInfoString -like "*Outlook 12*" } | select MailboxOwnerUPN,Operation,LogonType,LastAccessed,ClientInfoString | export-csv -Append .\UnsupportedOutlookConnections.csv
        Get-PSSession | Remove-PSSession
        }
}

#### MAIN Procedure ####
# Connect to MSOL
Import-Module MSOnline
$UserCredential = Get-Credential
Connect-MsolService –Credential $UserCredential

# Get the list of partner managed clients
$Clients = (Get-MSOLPartnerContract)

# Get the default domain name from each client
$Domains = $Clients.defaultdomainname

# Uncomment the next line to show if users have auditing turned on or not (Suggested to do on day 1)
#ShowAuditing

# Uncomment the next line to enable Auditing on each client (Suggested to do on day 1)
#EnableAuditing

# Uncomment the next line to export multiple CSVs so you can see if there are any Outlook 2007 connections (Suggested to do on day 3+)
#SearchOutlookUnsupported

Send from Office 365 Shared Mailbox with Thunderbird

We have a client that wanted to authenticate with SMTP to send out from a shared mailbox. noreply was the name of the shared mailbox. Below is the configuration. User has to have full access and send-as permissions for the mailbox. Hopefully this helps someone trying to accomplish the same thing.


Exchange Configuration:
USER EMAIL: user@domain.com
PASSWORD: password

SHARED MAILBOX: shared@domain.com
SHARED MAILBOX ALIAS: noreply

Settings for IMAP Configuration:
EMAIL ADDRESS: noreply@domain.com (shared mailbox)
IMAP SERVER: outlook.office365.com
SMTP SERVER: smtp.office365.com (port 587)
USERNAME: user@domain.com\noreply (user\shared mailbox alias)
PASSWORD: password (user’s password)
SMTP LOGIN IS DIFFERENT (!)
USERNAME: user@domain.com (users email)
PASSWORD: password (user’s password)

Source for information

PDF Attachments Phishing Attacks

Recently we’ve seen an influx in spam emails containing PDF documents. The PDFs contain a link, which when clicked  takes the victim to a website prompting them for usernames and passwords. By entering the username and password, the victim is giving the thieves their email password – compromising the account. This type of attack is called phishing.

Phishing
noun
the fraudulent practice of sending emails purporting to be from reputable companies in order to induce individuals to reveal personal information, such as passwords and credit card numbers.



What Can Be Done?

Please be on guard for emails with PDF attachments, especially those from unknown senders. Even if the email comes from a trusted sender, that person’s account may be compromised. Above are some common templates for gathering credentials.

Additionally, some email systems (Office 365, G Suite) can be configured to warn users whenever a PDF attachment with a link is included in an email, as seen in the Office 365 rule below.

 

 

 

Tracking Down Repeat Failed Login Attempts to Domain Controller

One of our clients kept getting repeat failed login attempts on their domain controller. Usually this is an issue with a port being open on the firewall and brute-force attacks being run to guess the password, but ports were closed on the firewall and it didn’t look like a dictionary attack. Instead, it looked like something was running every 2 minutes, attempting to use the guest account.

The first thing we did was filter the security log in the Event Log by keyword: Audit Failure. This allowed us to see how often all the audit failures were. Conveniently, they were about every 2 minutes. (Convenient because we have a few chances to catch the culprit!) We could see that the source port was changing every time, adding complexity to the issue.

The audit log provided the IP address of the workstation as well as the username that was trying to authenticate.

We were interested in what the hostname was of the workstation, so we ran ping -a 192.168.10.15 and got the hostname. Now we know the PCs name and the account that is failing authentication. We have found the offender!

We used our remote support tools to connect to the PC, then wrote a script to monitor the port traffic. This script is just an infinite loop, dumping out the output of netstat -ano.

:loop
netstat -ano >> ports.txt
goto loop

We saved this as monitor.bat and ran on the offending machine. Then we went to the domain controller and watched for the event to happen. Once we had the Source Port from the new event, we went back to the offending machine, pressed Ctrl+C, terminated the script, and opened the ports.txt file. We were able to search the text file for the Source Port and get the Process ID of the offending process.

With this information, we were able to open a command prompt and find the offending process.

tasklist /v | findstr /i "54042"

From there we were able to make changes to the process to allow it to authenticate correctly, if necessary, or remove the process if not necessary.

Guide Realty Mixer at Lexington Beerworks

Last night we went to a Guide Realty mixer hosted by Raquel Carter. Special thanks to Lexington Beerworks for hosting the event!