Office 365 DKIM Going Live

DKIM signing for outbound messages has been available (with some issues) in Office 365 for a couple of months now.  It is now beginning to roll out into standard release tenants in production, and this post will attempt to break down what this means.

For those who are Office 365 (Exchange Online) Admins, and aren't familiar with SPF, DKIM and DMARC, I recommend referencing Terry Zink's blog.  In my view, this is the best practice.

DKIM Goes Online

Exchange admins can check the current status of DKIM in their tenant through the Get-DkimSigningConfig cmdlet.  Note that if any results return, then keys have been setup for the listed domain(s).  It will return blank if nothing has been setup in a tenant.

In my experience, the primary sending domain tenant.onmicrosoft.com is now set to Enabled.  The other domains in my tenant were configured with key pairs generated, but the domains were not yet enabled because CNAMEs were not found in DNS.

The result is that all messages coming from my O365 domain are now signed with DKIM!  My test tenant as well as Gmail give me a Pass for DKIM evaluation, even though the envelope.from domain (vanity domain) is not yet enabled.

Issues

I have not yet seen any issues, but there is word that some automatic replies such as OOF messages can fail DKIM evaluation by some services.  As I understand it, this is being worked on.  

Office 365 Click to Run: Delay Upgrade to Office 2016

To date, it has been tough to find info on how to do this.  Perhaps my Google-fu is waning.

Overview

Many organizations will not want to jump on the bandwagon to get onto Office 2016 when it launches on the "Business" track in October February 2016 (GA release to the public is September 22nd, next week). There are Group Policy settings available in recent vintage ADMX which control this behavior.

Background

Historical knowledge seems to be retconned out of existence, but it's a good idea to use the latest ADMX templates for Office.  Hopefully this link is permanent: https://www.microsoft.com/en-us/download/details.aspx?id=35554.

This guide will reference the May 2015 updates for the Office 2013 (office15) ADMX templates.

In the latest ADMX, there is a Machine policy under Updates, named Enable Automatic Upgrade.

The description is as follows:

This policy setting controls whether Office upgrades automatically to newer major versions.  This policy applies to Office products installed via Click-to-Run. This policy has no effect on Office products installed via Windows Installer.If you enable or do not configure this policy setting and Office automatic updates are not disabled, Office will check if a new major version upgrade is available during automatic updates. If eligible, Office will download the new major version upgrade in the background and prompt the user when it is ready for installation.If you disable this policy setting, Office will not automatically detect or download a major version upgrade.

That's the winner!

Disable this setting in GPO and you are safe to continue on Office 2013 in your Click to Run deployment.  Reminder: Office 2013 Click to Run will only be supported for 12 months, so get on the 2016 migration bandwagon already!

As noted above in the GPO description... if you are using version control elsewhere in policy, you won't be affected by this roll-out until you specify a 16.x TargetVersion in your policy.  This policy is for those in the Automatic Updates cycle already.

Recap

1. Install the latest ADMX templates into your PolicyDefinitions folder in SYSVOL in your domain.
• If you haven't done it since May 2015, plan on doing this step!
2. Configure the following GPO: Computer Configuration\Administrative Templates\Microsoft Office 2013/2016 (Machine)\Updates\Enable Automatic Upgrade.  Set it to Disabled.
3. Scope this Machine GPO to your workstations!

• If you are already using Target Version version control, this is not needed.  Simply keep specifying 15.x version numbers.
• Keep an eye out for the Office 2013 Click to Run End of Life.
• Make sure you configure the Office 2013 GPO, so your Office 2013 client doesn't upgrade to '16

Block Microsoft SEND App in EWS policy

Note:  This post is super-fast publish, and will be changing.  Turns out its going to be gnarly to totally change the Exchange OrganziationalConfig to block EWS that we don't want.  I'm working with the SEND product team to identify User Agent strings for blocking in EWS, etc.

Identified!  User Agent string for blocking Send in EWS policy is "MicrosoftSend/*"


Reference is here: http://blogs.technet.com/b/matabra/archive/2012/08/23/block-mobile-apps-that-use-exchange-web-services.aspx

Background:

Today (nice late birthday present, btw), Microsoft Garage released an App for iOS that mimics IM/Texting functionality, but really just uses Exchange Web Services and some special handling.

As such, it does not require ActiveSync, and therefore has no security policy. See the FAQ here (requires Yammer, unfortunately)

So basically, this app is out there and is a giant hole (and honestly, anyone could write an EWS application that blows past ActiveSync security policies). But this has Microsoft's name on it, so we're going to get proactive.

So, I've got my iPad with no device partnership in ActiveSync (I just removed it, I had the Outlook app installed).  I've also cleared the passcode which was an ActiveSync policy requirement.

Now I install SEND on the iPad (it's technically an iPhone app, but I'm not making all of these policy changes on my main phone).  Sign in with my O365 creds, and Voila! an email client using EWS and no passcode/lock policy.  There is no ActiveSync partnership for this device, and therefore not putting in device restrictions, and I can still send "Send" messages freely using EWS.

I also removed the Outlook App from the device entirely, and I can still execute Directory searches using EWS.  With no device security policy in place, I can query the name of my org's CEO and Send him a short diatribe about what I think of his mother. No bueno.

So, what do we do?

The SEND app needs to be blocked in EWS policy, which can be set per-user using Set-CASMailbox, or org-wide using Set-OrganizationalConfig.  Here, an important decision needs to be made.  Do you whitelist or blacklist applications in EWS?  Well, this is going to vary based on your organization.  There are some built-in properties for Outlook, MacOutlook, and Entourage.  Otherwise, use EWSApplicationAccessPolicy [EnforceBlockList | EnforceAllowList].  

To test all of this nonsense, I set my own mailbox to disallow the Send App.  Set-CASMailbox -Identity mailbox@domain.com -EwsApplicationAccessPolicy EnforceBlockList -EwsBlockList @{Add="MicrosoftSend/*", "LinkedInEWS"} .  (I won't go into why I'm blocking LinkedIn, but I do suggest you search it).

Success!  Now my iPad reports frowny face when an attempt is made to use Send.

Yeah, well, it makes me sad when products are released and hyped on Yammer when they are not on the roadmap, break security policies, and make my life harder.

Troubleshooting hybrid Exchange UM and bad voicemail behavior with Lync 2010

That's not a succinct title, but I certainly couldn't find any info when I was trying to research the issue I was having.  

I administer an environment consisting of Lync 2010 on-premises with Exchange 2010 in a hybrid configuration with Office365.  We were facing problems with users accessing voicemail.  In some cases, a call going to voicemail would simply drop.  In a few others, a call would transfer to voicemail, but then prompt for user interaction in the form of pressing pound [#].

To spoil the story, we had an issue with provisioning user accounts.  Our process was roughly:

1. Create AD user
2. Enable Exchange Mailbox in on-premises environment.
3. Enable Lync 2010
4. Migrate Exchange mailbox to O365

We had a critical step missing in the scripted provisioning of the Lync account.

In this environment, Lync user provisioning has three separate steps: 

1. Enable-CSUser from AD account, specify registrarpool -sipaddress, -lineURI
2. Grant-CSHostedVoicemailPolicy  Specify the name of your Hosted UM Policy
3. Set-CSUser [identity] -HostedVoiceMail $True 

Here, Step 3 is critical.  It must come after a hosted voicemail policy is set, and in our case it was not.  In fact, it was being skipped entirely.  Our provisioning team had to go back and enable the flag, but in some cases it was too late, O365 Exchange UM was already causing strange issues for users who had attempted to setup their voicemail without the correct Lync user configuration.  Most notably, a Voicemail transfer from Lync on-premises would go through, but Exchange UM in O365 wouldn't handle the transfer gracefully, so a user was prompted to press pound [#]

About UM-enable:

After enabling Lync, you will need to re-run Dirsync, to ensure the SIP address gets into O365.  From there, Enable-UMMailbox will work properly, assuming you also set the UMMailboxPolicy to your Hosted UM policy as appropriate.  Unfortunately we are also missing this step in provisioning.

FCC Protecting and Promoting the Open Internet summary

I posted this bit over on Ars Technica's comments section, and thought it was worth reposting here.  The FCC released the formal rules around the Open Internet Order today.

https://www.federalregister.gov/articles/2015/04/13/2015-07841/protecting-and-promoting-the-open-internet#h-14

Here is my TL;DR version of the meat of the Open Internet Order:

1. No Blocking - A broadband provider may not block access to legal services on the internet, subject to reasonable network management.

2. No Throttling - A broadband provider may not "impair or degrade lawful internet traffic," subject to reasonable network management.

3. No Paid Prioritization - Direct or indirect favoring of traffic of one kind over another is prohibited. This rule is not subject to the caveat of reasonable network management, because as is described below, the caveat applies to technical aspects, not business process.

4. No Unreasonable interference or disadvantage between customers and edge services - This is the catch all, for anyone trying to find a way around the three rules above. The clause recognizes that an ISP may exert its position as gatekeeper between subscribers and internet services, and hedges against that eventuality that the power will be abused.

5. Broadband providers must transparently report - Codifying a 2010 rule, providers must disclose network management practices, performance, and commercial terms of their broadband services.

6. Establishes regulatory domain over interconnection - Acknowledges that it is subject to action, but makes no rules at this time.

7. Defines reasonable network management - Reasonable network management (as italicized above and throughout) is strictly defined as a technical process, and does not apply to business practices, such as the example of a carrier throttling "unlimited" plans after an amount of usage.

8. Mobile networks are subject to the same rules as wired - 'Nuff said.

9. Services such that are not broadband internet access services are not subject to these Orders - The example given is bundled VOIP phone service. Since the service itself does not talk across the internet, it is not subject to the rules. This is a clear example of the type of other services that must be reported upon as per section 5.

Microsoft Outlook for Apple iOS Technical First Look

A notice on Yammer leads us to the general availability of the Microsoft Outlook for iOS app. This is apparently the outcome of Microsoft's Acompli acquisition.

First impressions:

On iPad and iPhone, the experience feels a lot like Google's Inbox.  Swipe right on a message to Schedule (Snooze), Swipe Left to Archive.  The motions are reversed from Inbox however they can be customized in Settings.  The iPad app gives a reading pane, much like the experience in every other iPad version of a mail app.

Mailbox experience:

I'm on an O365 E3 plan with online Archiving, and the experience is much like Exchange ActiveSync.  No Online Archive is available (I'm not really sure what the Archive action is able to accomplish in this regard, it certainly can't send something to the online Archive, and that's not how that's supposed to work anyway).  Also, I'm unable to open another user's mailbox.  For a variety of use cases, OWA is more functional for me.  I think the Outlook App will shine when adding multiple accounts and using a single pane of glass.

I will say that Autodiscover worked in SECONDS with using my userPrincipalName and password, which Apple's Mail app typically chokes on (have to specify O365 server endpoint, specify username format)

So what is this App using, really?

I'm an O365 admin, so I am naturally curious how this App ticks with regard to Exchange.

In the Exchange Admin Center (O365), under Mobile, we can set Device Access Rules.  The Outlook App is a Device Family and Model, as shown:

Hooray, now what service is the Outlook App using?

From what I can tell, the Outlook App is an Exchange ActiveSync Device.  It should be using the default EAS policy (assuming you don't have some sort of rule that applies a different policy by device model/family).  Get-MobileDeviceStatistics clearly identifies the Outlook App as ClientType: EAS.  It also shows DevicePolicyApplicationStatus: AppliedInFull (Yay!)


I tested by setting a Wipe on my Outlook, Outlook for iOS and Android "Device" in EAC:

This first exhibited itself as an authentication failure in the app (on both devices, strangely enough).  I closed the App (swipe up to kill), and re-opened it, to be greeted by a Deleting... action and then the initial setup wizard.  Sounds like Device Wipe works well enough! It didn't touch the actual device, naturally, making this perfectly suitable for BYOD.  Even though both devices I had using this "profile" are wiped, the wipe still says pending in the console.  I've cancelled it so I can move on.