Thursday, July 6, 2017

Restricting Auto-Forwarding

Office 365 Messaging – Automatic Forwarding of Emails

Purpose
Outline scenarios involving auto-forwarding email messages and providing controls to maintain security compliance. Securing message traffic through the use of transport and other rules that can circumvent the ability to audit and track messaging.

Scenarios
Users have the ability to enable “Automatic Forwarding” of all messages. There are two general methods that allow forwarding:
Ø  OWA - Enable Automatic Forwarding of all Emails (with the option to enable keeping a copy in the users’ mailbox).
Ø  Creating and enabling a rule that would forward all messages to another messaging application (i.e. Yahoo!, Gmail, etc.) after the message arrived within the users’ mailbox.
Managing destination domains with transport rules, preventing the forwarding of *any* messages to these domains, or the blocking of *ALL* auto-forwarded messages with exceptions based on group membership.

(1) Outlook Web Access (OWA) Auto-Forward
OWA has a feature that enables the forwarding of all messages that are destined for delivery to a users’ mailbox without delivering it to the mail store where that user’s mailbox lives thereby bypassing legal auditing and compliance.  The user does have the option to enable the feature which creates a copy of the forwarded message (a check box).
This risk can be mitigated by creating and applying a policy that removes this feature, and then a script created to programmatically remove any existing destination addresses currently configured for each user.
EXAMPLE:
User John Doe has a mailbox and has configured OWA to automatically forward all of his mail to Gmail.  The user has a device already configured to organize and sort mail using Gmail and does not have one configured for accessing messaging through O365 (OWA/Outlook/EWS/ActiveSync).  The user may have a legitimate business use for forwarding messages outside of the company to other addresses (Partner Resources, Purchasing, etc.); however, because this user does not have the checkbox selected to keep a copy in their O365 mailbox, there is no way for our tools to audit and track messaging information for this users’ mailbox (except for the configured destination address that all messages are being forwarded to).
To prevent this user from using the ‘Auto Forward Email’ feature of OWA, we have a policy that removes that as an option for OWA mailboxes.

(2) Creating and Using Rules to Auto-Forward
Outlook desktop client and OWA have the ability to create and enable “rules” which take effect after a message arrives WITHIN the users’ mailbox. A user can create a rule that automatically forwards all messages to another location, but because of how rules work, the message gets delivered to the information store and then gets forwarded to the destination set in the rule.  This allows for auditing and compliance tools to be used.
EXAMPLE:
Jane Smith has a rule in her Outlook client that automatically forwards a copy of every message she gets to an external email address. Because of how rules work, all messaging information is retained within the mailbox that can be audited and tracked for compliance.
Rules cannot be easily managed by policy or programmatically making any controls to manage rules in Outlook difficult/costly.

(3) Using Transport Rules
We can create transport rules that will explicitly prevent the delivery of ANY messages to a destination domain (i.e. Yahoo.com, google.com, aol.com, etc.) or based on the type of message (in this case, Auto-Forwarded messages), block delivery.  A transport rule is applied during transit and can include response messages notifying users of the policy that is blocking auto-forwarding.
EXAMPLE:
Create a transport rule that blocks all auto-forwarded messages (configured through OWA, where the message does not get delivered to the mailbox by default when Auto-Forwarding is enabled).
Create New Rule with conditions:
-          The sender is located “Inside the organization”
-          The recipient is located “Outside the organization”
-          The message type is “Auto-Forward”
-          Action <define_action>
-          Exception:  The sender is a member of this group <define_exception_group>
Using this method, it would be advised to still run the scripts to remove the ability to configure “Auto-Forwarding” through OWA and clear the attributes users already have configured.  This would be a secondary layer to ensuring auto-forwarded messages are managed.

Recommendation:

We can move forward by implementing scenarios 1 and 3.  Client side rules (#2) would be difficult and costly to implement.

Implementation:

Disable Autoforward for Users

Testaag sample:
1.       Create a new Management Role which will restrict the following Set-Mailbox abilities for end users.
a.       DeliverToMailboxAndForward
b.       ForwardingAddress
c.       ForwardingSmtpAddress
2.       With these de-scoped from a user’s Access Control Entry, they will no longer be available in OWA.
3.       Make the new custom Management Role the default in the Default Role Assignment Policy.
PS > New-ManagementRole -Name "MyBaseOptions-noforward_TAAG" -Parent MyBaseOptions

Name                                                        RoleType
----                                                        --------
MyBaseOptions-noforward_TAAG                                MyBaseOptions

PS > Set-ManagementRoleEntry mybaseoptions-noforward_taag\Set-Mailbox -RemoveParameter -Parameters DelivertoMailboxandForward,ForwardingAddress,ForwardingSmtpAddress


End result:
PS > Get-ManagementRoleAssignment -RoleAssignee "Default Role Assignment Policy" | FT Name,Role -AutoSize

Name                                                         Role
----                                                         ----
MyRetentionPolicies-Default Role Assignment Policy           MyRetentionPolicies
MyProfileInformation-Default Role Assignment Policy          MyProfileInformation
MyTextMessaging-Default Role Assignment Policy               MyTextMessaging
MyMailSubscriptions-Default Role Assignment Policy           MyMailSubscriptions
MyVoiceMail-Default Role Assignment Policy                   MyVoiceMail
MyContactInformation-Default Role Assignment Policy          MyContactInformation
MyTeamMailboxes-Default Role Assignment Policy               MyTeamMailboxes
My Marketplace Apps-Default Role Assignment Policy           My Marketplace Apps
MyDistributionGroups-Default Role Assignment Policy          MyDistributionGroups
MyDistributionGroupMembership-Default Role Assignment Policy MyDistributionGroupMembership
My ReadWriteMailbox Apps-Default Role Assignment Policy      My ReadWriteMailbox Apps
My Custom Apps-Default Role Assignment Policy                My Custom Apps
MyBaseOptions-noforward_TAAG-Default Role Assignment Policy  MyBaseOptions-noforward_TAAG


Note that the default MyBaseOptions role ACE is missing from the list entirely, and the substitute “no forward” policy is in its place.


Enable auditing of autoforward in Exchange Transport for compliance










Exception scenarios:

Define exception group for reporting of autoforward instances.  

Keep Default Role Assignment Policy flat for everyone.  Exception users can submit Service Requests to the Exchange team





Wednesday, December 16, 2015

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.  

Friday, September 18, 2015

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

Wednesday, July 22, 2015

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.

Friday, May 1, 2015

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.

Monday, April 13, 2015

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.

Thursday, January 29, 2015

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.