Upload
others
View
10
Download
1
Embed Size (px)
Citation preview
SEEMail Integration Reference Architecture
Prepared for
Department of Internal Affairs – Office of the GCIO
3/3/2016
Version 7 Final
Prepared by
Greg Hunt
Architect
Microsoft Office 365
Whitepaper
Prepared for Department of Internal Affairs
MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under
copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted
in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose,
without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering
subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, our
provision of this document does not give you any license to these patents, trademarks, copyrights, or other
intellectual property.
The descriptions of other companies’ products in this document, if any, are provided only as a convenience to
you. Any such references should not be considered an endorsement or support by Microsoft. Microsoft cannot
guarantee their accuracy, and the products may change over time. Also, the descriptions are intended as brief
highlights to aid understanding, rather than as thorough coverage. For authoritative descriptions of these products,
please consult their respective manufacturers.
© 2014 Microsoft Corporation. All rights reserved. Any use or distribution of these materials without express
authorization of Microsoft Corp. is strictly prohibited.
Microsoft and Windows are either registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
ii
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Draft
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Prepared for Department of Internal Affairs
iii
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Revision and Signoff Sheet
Change Record
Date Author Version Change Reference
12 Jan, 2016 Greg Hunt 1 Initial draft for review/discussion
13 Jan, 2016 Greg Hunt 2 Peter Haigh review changes
18 Jan, 2016 Greg Hunt 3 GCIO Office Productivity team review changes
29 Jan, 2016 Greg Hunt 4 Final GCIO review changes
10 Feb, 2016 Greg Hunt 5 Internal CoE Review
16 Feb 2016 Greg Hunt 6 Document acceptance review changes
03 Mar 2016 Greg Hunt 7 Final acceptance review changes
Reviewers
Name Version Approved Position Date
Peter Haigh 1 Technology Strategist, Microsoft 13 Jan, 2016
Ahmed Elashmawy 1 Security Consultant, Axenic 17 Jan, 2015
Richard Bourne 1 Chief Technology Officer, Liverton 14 Jan, 2016
Sandeep Dalvi 1 Product Manager, DIA 18 Jan, 2016
Albert Sauz 2 Premier Field Engineer, Microsoft 21 Jan. 2016
Philip Cutforth 3 AoG Enterprise Architect, DIA 28 Jan, 2016
Ed Van Beek 3 Architecture Consultant, Equinox IT 28 Jan, 2016
Michael Price 3 Security Consultant, Axenic 28 Jan, 2016
Kieron Darley 3 Senior Consultant, Office 365 Centre of Excellence,
Microsoft
9 Feb, 2016
James Collier 5 Chief Enterprise Architect, Office of the GCIO, DIA 15 Feb, 2016
Prepared for Department of Internal Affairs
iv
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Table of Contents
1. Executive Summary .............................................................................................................................. 9
2. Introduction .......................................................................................................................................... 12
1.1 Background .................................................................................................................................................. 12
1.2 About this Document ............................................................................................................................... 12
1.2.1 Alignment with other GCIO Guidance............................................................................ 13
1.2.2 Alignment with the UK Government Guidance ............................................................ 14
1.3 Users of this Document ........................................................................................................................... 14
2 Government ICT Context .................................................................................................................. 15
2.1 Government ICT Strategy and Action Plan to 2017 ...................................................................... 15
2.2 Government Enterprise Architecture for New Zealand (GEA-NZ) ........................................... 17
2.3 Information Security in New Zealand Government ...................................................................... 21
2.3.1 New Zealand Government Security Classification System ........................................ 21
2.3.2 New Zealand Information Security Manual (NZISM) .................................................. 22
2.3.3 Cloud Computing Risk and Assurance Framework .............................................................. 25
2.4 Microsoft Cloud Standards .................................................................................................................... 27
2.4.1 Security and Privacy Principles ........................................................................................ 27
2.4.2 Compliance and Assurance .............................................................................................. 28
3 Reference Architecture Technologies .......................................................................................... 30
3.1 SEEMail .......................................................................................................................................................... 30
3.1.1 Service Description ............................................................................................................. 30
3.1.2 Message Security Features ............................................................................................... 32
3.2 Exchange and Exchange Online ........................................................................................................... 34
3.2.1 Service Description ............................................................................................................. 34
3.2.2 Message Security Features ............................................................................................... 35
4 Architecture Patterns ......................................................................................................................... 43
4.1 Architecture Approach ............................................................................................................................. 43
4.1.1 Cloud Services ..................................................................................................................... 44
Prepared for Department of Internal Affairs
v
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
4.2 Pattern Summary ....................................................................................................................................... 46
4.3 Solution Building Blocks .......................................................................................................................... 50
4.4 Network Security Considerations ........................................................................................................ 53
4.5 On-Premises Architectures ..................................................................................................................... 54
4.5.1 On-Premises Exchange with SEEMail Pattern ............................................................... 54
4.6 Hybrid Architectures ................................................................................................................................. 56
4.6.1 Hybrid Exchange Pattern .................................................................................................. 57
4.7 Cloud Architectures .................................................................................................................................. 62
4.7.1 Exchange Online with SEEMail Pattern .......................................................................... 62
5 Integration Considerations .............................................................................................................. 67
5.1 Outlook Integration .................................................................................................................................. 67
5.2 Outlook on the Web ................................................................................................................................. 67
5.3 ActiveSync .................................................................................................................................................... 68
5.4 On-Premises Applications ...................................................................................................................... 69
5.4.1 Printers and Multifunction Devices ................................................................................ 70
5.4.2 SEEMail Application Whitelisting .................................................................................... 70
5.5 Web Services Integration ........................................................................................................................ 70
5.5.1 Exchange Web Services ..................................................................................................... 70
5.5.2 Exchange Online Web Services ........................................................................................ 71
6 Appendix A – Non-SEEMail Patterns ........................................................................................... 72
7 Appendix B – Azure AD Connect ................................................................................................... 79
7.1 Planning Syncronisation .......................................................................................................................... 79
7.2 Prerequisites for Deployment ............................................................................................................... 80
Prepared for Department of Internal Affairs
vi
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Tables
Table 1 - Architecture Pattern Summary ............................................................................................................. 11
Table 2 - Strategic Alignment.................................................................................................................................. 17
Table 3 - Enterprise Architecture Alignment ..................................................................................................... 18
Table 4 – Approved Crypto Algorithms ............................................................................................................... 23
Table 5 - Legacy Crypto Algorithms ..................................................................................................................... 23
Table 6 - Crypto Algorithm Impacts ..................................................................................................................... 24
Table 7 - Crypto Protocol Impacts ......................................................................................................................... 25
Table 8 – Cloud Adoption Impact .......................................................................................................................... 26
Table 9 - Microsoft Cloud Principles ..................................................................................................................... 27
Table 10 - Cloud Computing Considerations Scope ...................................................................................... 28
Table 11 - Email Protection Technology Summary ......................................................................................... 30
Table 12 - SEEMail Capability Overview .............................................................................................................. 31
Table 13 - Architecture Pattern Summary .......................................................................................................... 46
Table 14 - Solution Building Blocks ...................................................................................................................... 50
Table 15 –TLS Configuration Guidelines ............................................................................................................. 53
Table 16 - Application Mail ...................................................................................................................................... 69
Table 17 - Non-SEEMail Architecture Patterns ................................................................................................. 72
Prepared for Department of Internal Affairs
vii
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Table of Figures
Figure 1 - On-Premises Architecture ....................................................................................................................... 9
Figure 2 - Hybrid Architecture ................................................................................................................................ 10
Figure 3 - Cloud Architecture .................................................................................................................................. 10
Figure 4 - Government ICT Strategy 2015 .......................................................................................................... 15
Figure 5 - GEA-NZ 3.1 Structure and Dimensions ........................................................................................... 17
Figure 6 - SEEMail Message Protection ............................................................................................................... 32
Figure 7 - Office 365 S/MIME .................................................................................................................................. 35
Figure 8 – EOP ............................................................................................................................................................... 36
Figure 9 - Office 365 Message Encryption ......................................................................................................... 39
Figure 10 - EOP ATM .................................................................................................................................................. 40
Figure 11 – ExpressRoute .......................................................................................................................................... 41
Figure 12 - Email Service Transition ...................................................................................................................... 44
Figure 13 - On-Premises Exchange with SEEMail Pattern............................................................................. 55
Figure 14 – Hosted SEEMail Gateway Option ................................................................................................... 56
Figure 15 - Hybrid Exchange Central Transport with SEEMail Pattern .................................................... 58
Figure 16 – EOP Email Protection Option ........................................................................................................... 59
Figure 17 - Hybrid Hosted SEEMail Option ........................................................................................................ 60
Figure 18 - Hybrid Non-Exchange Option ......................................................................................................... 61
Figure 19 - Exchange Online with SEEMail Pattern ......................................................................................... 63
Figure 20 - Cloud-Based Administration Option ............................................................................................. 65
Figure 21 - Exchange Online with Hosted SEEMail Option .......................................................................... 66
Figure 22 - On-Premises Exchange Pattern ....................................................................................................... 74
Figure 23 - Hybrid Exchange Pattern.................................................................................................................... 75
Figure 24 - Hybrid Exchange Centralised Mail Transport Option .............................................................. 76
Figure 25 - Exchange Online Pattern .................................................................................................................... 77
Figure 26 - Exchange Online Cloud-Based Administration Option .......................................................... 78
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Prepared for Department of Internal Affairs
Page 9
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
1. Executive Summary
New Zealand public sector Agencies that use the SEEMail service to protect the contents of
email messages need to make specific design considerations as they look to deploy Microsoft
Exchange Online as part of a wider migration to Microsoft Exchange Online.
Most agencies manage their own SEEMail and Microsoft Exchange email infrastructure (network,
hardware and software). Typically, this infrastructure is hosted in a datacentre directly managed
by the agency, or an agencies behalf by a third-party service provider.
Exchange Online and Office 365 are cloud services from Microsoft. With cloud services, the
infrastructure is provided as an end-to-end service that an agency consumes in much the same
way as other utility services like telecommunications or electricity. Microsoft manages all aspects
of the service, including hosting and underlying network, hardware and software.
Agencies that are interested in leveraging the benefits of Exchange Online and Office 365 need
to understand how they can continue to use the SEEMail service as they migrate from their on-
premises deployment of Microsoft Exchange to Exchange Online.
Microsoft has been asked to provide the Office of the Government CIO with guidance on how
SEEMail can be used with Microsoft Exchange and Exchange online. The guidance in this
document demonstrates that SEEMail can continue to provide its message protection functions
as agencies adopt Exchange Online and Office 365. Microsoft has identified the following
architecture patterns that agencies can base their own agency-specific designs upon:
On-premises architecture for SEEMail and Microsoft Exchange. Most agencies will have
already implemented a variation of this pattern as part of their existing email
environment.
On
-Pre
mis
es
Envi
ron
me
nt
Microsoft Exchange
SEEMail
Email Sender/Recipient
Figure 1 - On-Premises Architecture
Hybrid architecture where an agency is using their on-premises SEEMail and Microsoft
Exchange in conjunction with Exchange Online. This allows an agency to migrate to
Exchange online gradually, and manage Exchange Online using existing management
tools and processes. Agencies need to connect their on-premises Exchange servers to
Prepared for Department of Internal Affairs
Page 10
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Exchange Online. Inbound/outbound email can be routed through the on-premises
infrastructure, or through Exchange Online. O
n-P
rem
ises
En
viro
nm
en
t
Microsoft Exchange
SEEMail
Office 365
Exchange Online
Internal Sender/Recipient
External Sender/RecipientEmail
Figure 2 - Hybrid Architecture
Cloud architecture for agencies that wish to move all user mailboxes to Exchange
Online while continuing to interoperate with SEEMail. Agencies will retain a small amount
of on-premises Exchange infrastructure to support email administration.
On
-Pre
mis
es
En
viro
nm
en
t
Exchange Administra
tion
SEEMail
Office 365
Exchange Online
Internal Sender/Recipient
External Sender/RecipientEmail
Figure 3 - Cloud Architecture
Prepared for Department of Internal Affairs
Page 11
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Table 1 - Architecture Pattern Summary
The guidance provided in this document informs agencies as they deploy Exchange Online and
Office 365.
It demonstrates to agencies how they can take a gradual approach to Office 365
migration, and continue to support existing SEEMail and Microsoft Exchange services.
The document helps guide the design decisions of individual agencies and supports the
design of secure, robust and scalable email services for agencies.
The guidance in this document reduces the amount of up-front planning and decision-
making required of each agency as they undertake the design and planning process for
Exchange Online and Office 365 adoption.
This document compliments the Office 365 adoption guidance provided by the
Department of Internal Affairs Office of the Government CIO. Once completed, this
guidance will be available on the www.ict.govt.nz site.
Pattern Name Pattern Description Agency Profile
On-Premises
Exchange with
SEEMail
Traditional Exchange deployment with SEEMail
running in agency environment.
A SEEMail participating agency in either the
restricted or standard group.
Needs to realise the benefit of a recent investment
in on-premises email services.
Needs all email to stay on-premises for regulatory
or security compliance purposes.
Hybrid Exchange
with SEEMail
(Central Transport)
Agency adopts Exchange Online, but retains on-
premises Exchange environment for subset of
users.
Mail routed through existing SEEMail and
Exchange infrastructure instead of Exchange
Online to retain protection of all messages.
A SEEMail participating agency in either the
restricted or standard group.
Needs to support hybrid identity management and
configuration of cloud-based services.
Needs to maintain some on-premises mailboxes to
support business rules or non-functional
requirements like network latency.
Requires the flexibility of on-premises exchange
instances (e.g branch offices) but wants to leverage
benefits of cloud-based email services.
Has no restrictions relating to the use of offshore
email services.
Exchange Online
with SEEMail
Agency adopts Exchange Online with SEEMail and
moves all mailboxes to the cloud.
Some Exchange components are retained to
support centralised management of users and
mailboxes through AD.
A SEEMail participating agency in the standard
group.
Wants to minimise Exchange footprint and
leverage the benefits of Exchange Online.
Prepared for Department of Internal Affairs
Page 12
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
2. Introduction
1.1 Background
The world of productivity and collaboration is changing. Organisations that have previously
deployed and operated their own ICT services are taking advantage of Software as a Service
(SaaS) and other cloud-based offerings. SaaS provides significant benefits to organisations
including increased speed of innovation, better ways of working and collaborating, and the
ability for organisations to reduce the time and effort maintaining their own ICT services.
Office 365 is a SaaS offering from Microsoft that provides a range of communications and
collaboration services typically deployed and operated by an organisation’s own ICT department
or their contracted service provider. New Zealand government agencies of all sizes are actively
adopting or investigating the use of Office 365 as a replacement for their existing
communications and collaboration services, or as a way of quickly and easily providing
additional communications and collaboration capabilities to their current portfolio of services.
New Zealand government agencies operate a diverse range of ICT communications and
collaboration services, using a combination of products from Microsoft and other vendors. One
important component of many agencies communications and collaboration services is the ability
to protect email messages being sent between agencies. SEEMail is the service used to protect
these messages.
SEEMail is a technology used by many agencies to maintain the integrity and confidentiality of
email messages sent between participating government agencies. In the absence of specific
guidance relating to SEEMail integration with Office 365 the transition path to Office 365 is
uncertain for many agencies. In order for agencies to plan for and adopt Office 365 successfully,
this uncertainty must be removed.
1.2 About this Document
This document is a reference architecture that provides agencies with the patterns and guidance
necessary to plan for the adoption of the Exchange Online component of Office 365 in
conjunction with SEEMail version 3.1. Communications and collaboration products other than
Exchange Online, Microsoft Exchange 2010, 2013, 2016 and SEEMail version 3.11 are not
addressed in this reference architecture.
1 SEEMail version 3.0 certificates will be revoked in August 2016, existing SEEMail 3.0 deployments will
need to be upgraded to SEEMail 3.1 by this point.
Prepared for Department of Internal Affairs
Page 13
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
The document will provide a foundation for agencies to develop their own solution architectures
as part of Exchange Online adoption, reducing the effort required to adopt Office 365. It will not
however, provide an architecture specific to any one agency, or group of agencies.
The document will identify the critical design elements and considerations necessary to plan for
the adoption of Exchange Online in conjunction with SEEMail, but it will not provide exhaustive
design, configuration or deployment for Exchange Online or SEEMail. The document will
reference relevant Exchange Online and other Microsoft documentation for agencies looking for
this level of detail.
SEEMail is a service designed to protect email classified as IN-CONFIDENCE, SENSITIVE or
RESTRICTED. The reference architecture will not provide patterns for email data above
RESTRICTED.
This document contains a number of sections that provide specific information:
Government ICT Context – aligns the information in this document with broader New
Zealand government ICT strategy, architecture and information security standards.
Reference Architecture Technology – describes the services and the fundamental
security capabilities of these services, to provide additional context to the reference
architecture patterns.
Architecture Patterns – describes the high-level architecture patterns that agencies can
adopt when integrating SEEMail with on-premises, hybrid or cloud-based deployments
of Microsoft Exchange. Guides the implementation and operation of these services.
Integration Considerations – specific guidance on how integration with the on-
premises version of Microsoft Exchange is impacted by migration to a hybrid or cloud-
native deployment architecture.
1.2.1 Alignment with other GCIO Guidance
This document compliments the Office 365 adoption guidance provided by the Department of
Internal Affairs Office of the Government CIO. Once completed, this guidance will be available
on the www.ict.govt.nz site. The site contains a range of information about government ICT
policy, services, standards and guidelines.
Prepared for Department of Internal Affairs
Page 14
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
1.2.2 Alignment with the UK Government Guidance
The UK Government’s National Technical Authority for Information Assurance (CESG), advises
organisations on how to protect their information and information systems against today’s
threats.2
The CESG has worked with Microsoft in the UK to develop a document that provides
deployment security considerations when configuring email and hybrid deployments with the
Microsoft Office 365 (O365) web service. The secure configuration of this cloud-hosted service
aligns with the UK Government’s guidance on implementing the Cloud Security Principles.3
The CESG security guidance relates specifically to use of Office 365 (including Exchange Online)
by UK government agencies. The CESG security guidance describes specific security
configuration options for the email architectures described in this document (on-premises,
hybrid and cloud). It is beyond the scope of this document to provide a detailed analysis or
comparison of the CESG security guidance with the architecture patterns and guidance in this
document.
1.3 Users of this Document
This document is targeted at people responsible for the architecture and design of agency email
services. It provides the information necessary to develop robust email service architectures that
incorporate the SEEMail service. Agencies can use this document to select the pattern that best
suits their needs, and then develop an agency-specific email solution architecture.
Agency staff responsible for architecture and design can also use this document as a starting
point for finding out more about Microsoft email products and services.
It is assumed that readers of this document are familiar with technical terminology, processes
and solution design relating to general ICT, cloud and email services.
2 https://www.gov.uk/government/organisations/cesg 3 https://www.gov.uk/government/publications/microsoft-office-365-security-guidance/microsoft-office-
365-security-guidance-email
Prepared for Department of Internal Affairs
Page 15
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
2 Government ICT Context
2.1 Government ICT Strategy and Action Plan to 2017
The Government ICT Strategy and Action Plan to 2017 was approved by Cabinet in June 2013.
The Government ICT Strategy was revised in 2015 to ensure that, in a dynamic technology
environment, it can achieve the government’s aim of an ICT-enabled transformation of public
services to New Zealanders.4
Figure 4 - Government ICT Strategy 2015
This reference architecture contributes to the following elements of the strategy:
Category Element Contribution
Opportunities Exploit emerging technologies Exchange Online is part of Office 365, which is an emerging
cloud service model known as “Software as a Service” (SaaS).
This model allows consumers to easily procure and consume
ICT services without the burden of purchasing and
maintaining the underlying assets.
4 https://www.ict.govt.nz/strategy-and-action-plan/strategy/
Prepared for Department of Internal Affairs
Page 16
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Opportunities Unlocking the Value of Information Exchange Online make it easier than ever for agencies to
collaborate internally, with each other, with partners and with
the public. Exchange Online integrates with other Office 365
technologies unlock collaboration across different channels,
while securing information against unauthorised or
unintended disclosure.
Opportunities Leveraging Agency Transformation Moving to cloud-based ICT services will help agencies
respond to change more quickly and enable new ways of
working and interacting with the public. Over time, cloud
based services will reduce the cost of delivering ICT services.
Opportunities Partnering with the Private Sector Both SEEMail and Exchange Online are provided by private
sector organisations. Microsoft has a long history of
partnering with the New Zealand government to equip it
with the tools necessary for good public services, and this
partnership continues and Microsoft moves to a cloud first,
mobile-first world.
Focus Areas – Digital
Services
Common Service Components are re-
used by agencies.
Exchange Online represents a standard, re-usable
architecture building block that can be adopted across the
public sector to provide best of breed managed email
services.
Focus Areas –
Information
Open Data and sharing by default
supported by security and privacy
settings.
Exchange Online and the wider Office 365 suite offers a
range of tools to share information, while keeping the access
to shared information in the control of the agency. Rights
Management, Data Loss Protection and encryption are key
features of Exchange Online and Office 365.
Focus Areas –
Information
Public Trust and Confidence permits
sharing and reuse of information.
Security controls built into Exchange Online and Office 365
prevent the unintended disclosure of information, and
ensures that information that is disseminated remains in
control of the agency, regardless of the recipient.
Focus Area –
Technology
Agencies have easy access to
innovations from the ICT industry.
Exchange Online and Office 365 are delivered as SaaS,
meaning that regular service updates are part of the
subscription price. Agencies no longer need to factor in
product version upgrade activity.
Focus Area -
Investment
Maximise value from technology
investments.
By adopting a SaaS model, agencies can remove the costs
associated with managing hardware and software, and
redirect this towards productive investment in enabling new
functionality and services.
Focus Area -
Leadership
Agencies look to industry and 3rd parties
for sources of innovation.
Exchange Online and Office 365 continually innovate and
deliver new functionality, delivering incremental value to
subscribers over time. The features of Exchange Online and
Office 365 can help unlock new ways of working and new
business models.
Prepared for Department of Internal Affairs
Page 17
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Outcomes Adoption of information and technology
innovations is accelerated and value is
being created.
Exchange Online and Office 365 help deliver best in class
collaboration and communication services to customers. The
SaaS models ensures that subscribers continue to benefit
from future innovations.
Table 2 - Strategic Alignment
2.2 Government Enterprise Architecture for New Zealand
(GEA-NZ)
The Government Enterprise Architecture New Zealand (GEA-NZ) v3.1 framework is a significant
update that supports the delivery of the outcomes defined in the Government ICT Strategy and
Better Public Services. It also draws out concerns of customer focus, interoperability,
security/privacy and information reuse. The focus is now on how ICT can enable system
transformation across government, not just efficiency and effectiveness. 5
The GEA-NZ v3.1 framework is structured around eight top level dimensions. Each dimension
has a reference model which has a set of AoG artefacts, and agency related artefacts. This
reference architecture is aligned with the Application and ICT Services dimension.
Figure 5 - GEA-NZ 3.1 Structure and Dimensions
5 https://www.ict.govt.nz/guidance-and-resources/architecture/enterprise-architecture/
Prepared for Department of Internal Affairs
Page 18
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
GEA-NZ Application and ICT Services describes the business applications, including ‘Software as
a Service’, that support the business processes of the enterprise. It includes core business
applications, COTS corporate applications and end user computing applications.6
The GEA-NZ Application and ICT Services Reference Model include nine domains that can be
used as a common language to classify Application and ICT Services. This Reference Architecture
includes components in seven of these domains:
1. Corporate Applications - These are standard corporate applications within government
to support internally facing functions.
2. End User Computing - brings together the various applications and ICT services needed
to support a range of end user computing devices.
3. Data and Information Management - Software and or services that support
management of government data and information.
4. Identity and Access Management - Software and services to support Identity and
access management (IAM), identifying, controlling and auditing interactions with
government assets.
5. Security Services - defines the methods of protecting information and information
systems from unauthorised access, use, disclosure, disruption, modification or
destruction.
6. ICT Components, Services and Tools - Software and services for operational
management and maintenance of applications, ICT components and services
7. Interfaces and Integration - refers to the collection of software and services that
support how agencies will interface and integrate both internally and externally.
The relationship between specific applications and the products used in this architecture are
defined in the table below:
Table 3 - Enterprise Architecture Alignment
Domain Application Application Function Aligned Product
A1 Corporate Applications A1.10 Unified Communication
and Collaboration
A1.10.01 Calendaring Microsoft Exchange
Exchange Online
A1 Corporate Applications A1.10 Unified Communication
and Collaboration
A1.10.04 Email Server Microsoft Exchange
Exchange Online
A3 End User Computing A3.02 End Use Tools A3.02.11 Web Browser Microsoft Outlook
Web Browser
A3 End User Computing A3.04 Productivity Suite A3.04.02 Email Clients Microsoft Outlook
6 https://www.ict.govt.nz/assets/Guidance-and-Resources/GEA-NZ-v3.1-Application-and-ICT-Services-
Reference-Model-and-Taxonomy.pdf
Prepared for Department of Internal Affairs
Page 19
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Domain Application Application Function Aligned Product
Web Browser
A4 Data and Information
Management
A4.05 Data Protection A4.05.02 Data Archiving Exchange Online
A5 Identity and Access
Management
A5.02 Identity Administration
and Operations
A5.02.01 Role Management Active Directory Domain
Services
Azure AD
A5 Identity and Access
Management
A5.02 Identity Administration
and Operations
A5.02.03 Identity Provisioning Azure AD Connect
Azure AD
A5 Identity and Access
Management
A5.02 Identity Administration
and Operations
A5.02.03 Identity Updates Azure AD Connect
A5 Identity and Access
Management
A5.03 Authentication
Services7
A5.03.021 Authentication
Brokerage
Active Directory Domain
Services
ADFS
Azure AD
A5 Identity and Access
Management
A5.03 Authentication Services A5.03.07 Web Services
Security
Azure AD
ADFS
A5 Identity and Access
Management
A5.04 Authorisation and
Access Management Services
A5.04.01 Enterprise SSO ADFS
A5 Identity and Access
Management
A5.04 Authorisation and
Access Management Services
A5.04.02 Federation Services Azure AD
ADFS
A5 Identity and Access
Management
A5.04 Authorisation and
Access Management Services
A5.04.03 Access Control Active Directory Domain
Services
A5 Identity and Access
Management
A5.04 Authorisation and
Access Management Services
A5.04.04 Web Access
Management
Azure AD
A5 Identity and Access
Management
A5.04 Authorisation and
Access Management Services
A5.04.05 Web SSO Azure AD
ADFS
A5 Identity and Access
Management
A5.05 Directory Service n/a Active Directory Domain
Services
Azure AD
A5 Identity and Access
Management
A5.06 Identity Functional
Core Components
A5.06.01 – A5.06.05 Active Directory Domain
Services
Azure AD
ADFS
7 Additional functionality like adaptive authentication and multi-factor authentication is available for
customers that upgrade from Azure AD to Azure AD Premium.
Prepared for Department of Internal Affairs
Page 20
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Domain Application Application Function Aligned Product
A5 Identity and Access
Management
A5.07 Identity Interoperability A5.07.01 – A5.07.05 Azure AD
ADFS
A6 Security Services A6.01 Encryption Service A6.01.01 Crypto Key
Management
SEEMail
A6 Security Services A6.01 Encryption Service A6.01.03 Information
Encryption
SEEMail
A6 Security Services A6.01 Encryption Service A6.01.04 Network Encryption SEEMail
Microsoft Exchange
Exchange Online
A6 Security Services A6.01 Encryption Service A6.02.04 Secure Multipurpose
Internet Mail Extensions
(S/MIME)
SEEMail
A6 Security Services A6.01 Encryption Service A6.02.07 Transport Layer
Security (TLS)
SEEMail
Microsoft Exchange
Exchange Online
A6 Security Services A6.03 Public Key
Infrastructure (PKI) Service
A6.03.01 Digital Certificate
Management
SEEMail
Active Directory Domain
Services8
A6 Security Services A6.03 Public Key
Infrastructure (PKI) Service
A6.03.02 Digital Signature
Management
SEEMail
Active Directory Domain
Services
A6 Security Services A6.04 Security Controls A6.04.02 Content Security
Control
SEEMail
Microsoft Exchange
Exchange Online
A6 Security Services A6.04 Security Controls A6.04.08 Virus Protection Microsoft Exchange
Exchange Online
A6 Security Services A6.06 Enterprise Security
Management
A6.06.01 – A6.06.08 Exchange Online9
A7 ICT Components, Services
and Tools
A7.05 Cloud Services A7.05.01 Cloud Computing
Services
Exchange Online
Azure AD
A7 ICT Components, Services
and Tools
A7.05 Cloud Services A7.05.04 Software as a
Service (SaaS)
Exchange Online
8 Required to support specific configurations (Outlook S/MIME, Azure Rights Management) that are
beyond the scope of this document. 9 Provided as part of the underlying service management framework for Exchange Online/Office 365.
Prepared for Department of Internal Affairs
Page 21
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Domain Application Application Function Aligned Product
Azure AD
A7 ICT Components, Services
and Tools
A7.06 Server Configuration
Types
A7.06.06 Mail Server Microsoft Exchange
Exchange Online
A8 Interfaces and Integration A8.02 Data Interoperability A8.02.02 Data Transformation
Service
Azure AD Connect
A8 Interfaces and Integration A8.03 Interface A8.03.03 API Exchange Online
Azure AD
A8 Interfaces and Integration A8.03 Interface A8.03.05 RESTful APIs Exchange Online
Azure AD
A8 Interfaces and Integration A8.03 Interface A8.03.06 Web API Exchange Online
Azure AD
A8 Interfaces and Integration A8.04 Gateways A8.04.04 Informal Messaging SEEMail
Microsoft Exchange
Exchange Online
2.3 Information Security in New Zealand Government
2.3.1 New Zealand Government Security Classification System
New Zealand government agencies rely on the information security classifications defined in the
Government’s Protective Security Requirements (PSR) to identify and establish the protection
requirements for official information. 10 The PSR defines the following security classifications:
The security classifications for material that should be protected because of public interest or
personal privacy are:
IN CONFIDENCE
SENSITIVE
The security classifications for material that should be protected because of national security are:
RESTRICTED
CONFIDENTIAL
SECRET
10 https://www.protectivesecurity.govt.nz/home/information-security-management-protocol/new-
zealand-government-security-classification-system/?reset=1
Prepared for Department of Internal Affairs
Page 22
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
TOP SECRET
Official information that does not meet the threshold for a security classification is referred to as
unclassified information.
The PSR provides guidance to assist organisations with information risk profiling through use of
a Business Impact Levels (BIL) assessment11, in order to articulate the impact resulting from the
compromise of confidentiality, loss of integrity or unavailability of agency assets they hold or
generate. Use of the PSR BIL framework helps determine the criticality of agency assets,
including people, information and technology.
Using a BIL is part of an agency’s risk assessment and should include consultation on the agency
classification policy, the Information Security Management Protocol and the New Zealand
Government Security Classification System. Typically, BIL Levels 1-3 cover from UNCLASSIFIED to
RESTRICTED information assets, which cover the SEEMail operational spectrum12.
2.3.2 New Zealand Information Security Manual (NZISM)
The New Zealand Information Security Manual (NZISM) is the New Zealand Government’s
manual on information assurance and information systems security. The NZISM details
processes and controls for the protection of all New Zealand Government information systems.13
A single set of essential baseline controls have been defined in the NZISM for all
information that is marked INCONFIDENCE, SENSITIVE or RESTRICTED.
Information classified CONFIDENTIAL, SECRET or TOP SECRET has further controls
specified in the NZISM.
The category “All Classifications” includes any information that is Official Information, IN-
CONFIDENCE, SENSITIVE, RESTRICTED, CONFIDENTIAL, SECRET, TOP SECRET.
It is beyond the scope of this document to provide a detailed assessment of SEEMail, Exchange
Online and Microsoft Exchange against all NZISM controls. Relevant components of the NZISM
and their applicability to SEEMail, Exchange Online and Microsoft Exchange are provided below:
11 https://protectivesecurity.govt.nz/home/protective-security-governance-requirements/business-impact-
levels/#using-business-impact-levels-bils 12 Alternatively, SEEMail should not be used where BIL Levels 4, 5, or 6 apply. 13 http://www.gcsb.govt.nz/news/the-nz-information-security-manual
Prepared for Department of Internal Affairs
Page 23
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Approved Cryptographic Algorithms
There is no guarantee or proof of security of an algorithm against presently unknown attacks.
However, the algorithms listed in this section have been extensively scrutinised by government,
industry and academic communities in a practical and theoretical setting and have not been
found to be susceptible to any feasible attacks.14
Table 4 – Approved Crypto Algorithms
Crypto Function Crypto Algorithm or Protocol Minimum Strength Notes
Encryption Advanced Encryption Standard
(AES)
256-bit key SHOULD use the Galois/Counter Mode
(GCM).
SHOULD NOT use electronic codebook
mode
Hashing Secure Hash Algorithm (SHA) SHA-384 MUST use the SHA-2 family before
using SHA-1
Digital Signature Elliptic Curve Digital Signature
Algorithm (ECDSA)
NIST P-384
Key exchange Elliptic Curve Diffie-Hellman
(ECDH)
NIST P-384
SHA-1, 3DES, DH, DSA and RSA MUST NOT be used for new implementations but are approved
only for current legacy systems already running these algorithms. Legacy devices which are NOT
capable of implementing required key lengths MUST be reconfigured with the longest feasible
key length as a matter of urgency.
Table 5 - Legacy Crypto Algorithms
Crypto Function Crypto Algorithm or Protocol Minimum Strength Notes
Encryption SHA-1 SHA-384 MUST use the SHA-2 family before using
SHA-1
Encryption 3DES 3 keys MUST use either two distinct keys in the
order key 1, key 2, key 1 or three distinct
keys
Encryption DH 4096 bit
Encryption DSA 1024 bit
Encryption RSA 1024 bit MUST ensure that the public keys used
for passing encrypted session keys are
14 http://www.gcsb.govt.nz/assets/GSCB-NZISM/NZISM-Part-Two-v2.4-November-2015.pdf
Prepared for Department of Internal Affairs
Page 24
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Crypto Function Crypto Algorithm or Protocol Minimum Strength Notes
different to the keys used for digital
signatures.
The controls have the following impacts on components used in this reference architecture:
Table 6 - Crypto Algorithm Impacts
Component Impact
SEEMail Gateway Supports SHA 384
Supports AES256 (with GCM)
Supports ESDSA P-38415
Microsoft Exchange Supports SHA 384
Supports AES-256
Supports ESDSA P-38416
Exchange Online Supports SHA 384
Supports AES-256
Supports ESDSA P-38417
Weak ciphers are being
withdrawn
Cryptographic Protocols
The NZISM defines specific cryptographic protocols that are approved for use.18 Of specific note
for SEEMail, Exchange and Exchange Online are the following protocols and guidelines:
Transport Layer Security (TLS)
Email transport between organisations and agencies is usually over the internet or other
unsecured public infrastructure so it is important that email interception is carefully managed
and suitable controls applied. One effective measure is to use TLS to encrypt the email traffic
between email servers.
Agencies MUST enable opportunistic TLS encryption as defined in IETF’s RFC 3207 on
email servers that make incoming or outgoing email connections over public
infrastructure.
15 SEEMail v3.1 Technical Specification document 16 https://msdn.microsoft.com/library/aa374757%28VS.85%29.aspx?f=255&MSPPError=-2147217396 17 https://technet.microsoft.com/en-us/library/mt163898.aspx 18 http://www.gcsb.govt.nz/assets/GSCB-NZISM/NZISM-Part-Two-v2.4-November-2015.pdf
Prepared for Department of Internal Affairs
Page 25
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Agencies SHOULD implement TLS between email servers where significant volumes of
classified information are passed via email to other agencies.
Agencies SHOULD use the current version of TLS (version 1.2). Agencies SHOULD NOT
use any version of SSL.
SEEMail v3.1 Gateways use TLS v1.2 only.
Secure Multipurpose Internal Mail Extension (S/MIME)
When using a product that implements S/MIME, the approved cryptographic protocols
in the NZISM will need to be used.
Agencies MUST NOT allow versions of S/MIME earlier than 3.0 to be used.
The controls have the following impacts on components used in this reference architecture:
Table 7 - Crypto Protocol Impacts
Component Impact
SEEMail Gateway Supports TLS 1.2 (mandated for SEEMail v3.1)
Supports S/MIME 3.219
Microsoft Exchange Supports TLS 1.220
SSL needs to be disabled
Exchange Online Supports TLS 1.221
SSL v3.0 has been withdrawn from support
2.3.3 Cloud Computing Risk and Assurance Framework
The Government’s approach to cloud computing22 was introduced in August 2012 by the
Minister of Internal Affairs of the time. The approach established a ‘cloud first’ policy and an All-
of-Government (AoG) direction for the use, development and deployment of cloud services.23
19 SEEMail v3.1 Technical Specification document 20 https://technet.microsoft.com/en-us/library/dn786418.aspx?f=255&MSPPError=-2147217396 21 https://technet.microsoft.com/en-us/library/mt163898.aspx 22 http://ict.govt.nz/assets/Uploads/Documents/CabMin12-cloud-computing.pdf 23 https://www.ict.govt.nz/guidance-and-resources/information-management/requirements-for-cloud-
computing/#Cloud
Prepared for Department of Internal Affairs
Page 26
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Along with great benefits, using cloud services also has risk. In October 2013, Cabinet agreed to
a Cloud Computing Risk and Assurance Framework24 for government agencies. All State Service
agencies are expected to follow the process in line with Cabinet direction.25
All cloud computing adoption decisions need to be made on a case-by-case basis after a proper
risk assessment. State Service agencies are expected to follow the process issued by the GCIO,
including an initial cloud services information risk assessment of each cloud solution and
obtaining sign-off from their agency’s Chief Executive or formal delegate attesting to the
completeness and adequacy of the risk assessment, including the acceptance of any residual
risk.26
Agencies are expected to understand and fulfill their obligations with respect to the
classification and protection of their information when considering the adoption of cloud
services as part of the Cloud Computing Risk and Assurance Framework. Agencies are permitted
to use cloud computing services provided that they follow the process in line with the Cloud
Computing Risk and Assurance Framework, Cabinet direction and the NZISM. The Cabinet
direction states that no data above RESTRICTED can be stored in an onshore or offshore public
cloud service.
Agencies should follow the Office 365 adoption guidance provided by the Office of the GCIO to
determine if and how they should undertake the procurement of Office 365 in accordance with
the Cloud Computing Risk and Assurance Framework.
The cloud adoption framework has the following impacts on components used in this reference
architecture:
Table 8 – Cloud Adoption Impact
Component Impact
SEEMail Gateway Need to be in the SEEMail Restricted
group to process SENSITIVE or
RESTRICTED email.
Cannot be used for email classified
CONFIDENTIAL or above.
Microsoft Exchange -
24 https://www.ict.govt.nz/assets/Cabinet-Papers/Cab-Minute-Cloud-Computing-Risk-and-Assurance-
Framework-Oct-2013.pdf 25 https://www.ict.govt.nz/guidance-and-resources/information-management/requirements-for-cloud-
computing/#Framework 26 https://www.ict.govt.nz/guidance-and-resources/information-management/requirements-for-cloud-
computing/#Agencies
Prepared for Department of Internal Affairs
Page 27
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Component Impact
Exchange Online Cannot be used to store or process
email classified CONFIDENTIAL or
above.
2.4 Microsoft Cloud Standards
Microsoft cloud services, including Exchange Online and Office 365 are built and operated under
the principle of customer control and ownership over their data. Microsoft are custodians of this
customer information, and it is our ongoing responsibility to ensure that security and privacy are
maintained at all times.
2.4.1 Security and Privacy Principles
The Office 365 Trust Centre27 and Azure Trust Centre28 provide a one-stop shop for agencies
wishing to understand how Microsoft maintains the security and privacy of customer data stored
in Microsoft cloud services. Some of the key ways in which Microsoft and Office 365 secure
customer information include:29
Table 9 - Microsoft Cloud Principles
ID Principle
1 We restrict physical data center access to authorised personnel and have implemented multiple layers of physical
security.
2 We enable encryption of data both at rest and via the network as it is transmitted between a data center and a user.
3 We don't mine or access your data for advertising purposes.
4 We use customer data only to provide the service; we don't otherwise look in your mailbox without your permission.
5 We regularly back up your data.
6 We won't delete all the data in your account at the end of your service term until you have had time to take advantage
of the data portability that we offer.
7 We host your customer data in-region.30
27 https://products.office.com/en-us/business/office-365-trust-center-welcome 28 https://azure.microsoft.com/en-us/support/trust-center/ 29 https://products.office.com/en-us/business/office-365-trust-center-top-10-trust-tenets-cloud-security-
and-privacy 30 Some services that do not store information (such as EOP) may only be hosted in specific sub-regions
Prepared for Department of Internal Affairs
Page 28
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
ID Principle
8 We enforce "hard" passwords to increase security of your data.31
9 We allow you to turn off and on privacy impacting features to meet your needs.
10 We contractually commit to the promises made here with the data processing agreement (DPA).
2.4.2 Compliance and Assurance
Azure and Office 365 meet a broad set of international and industry-specific compliance
standards, as well as country-specific standards. Microsoft was also the first to adopt the
uniform international code of practice for cloud privacy, ISO/IEC 27018, which governs the
processing of personal information by cloud service providers (CSPs).32 Of particular relevance to
the New Zealand public sector are the following:
New Zealand Cloud Computing Considerations - The New Zealand Office of the
Government CIO (GCIO) was charged with developing and managing a risk-and-
assurance approach to cloud computing. His office developed a uniform step-by-step
process to assess cloud services that state services agencies would be required to use
when considering cloud solutions. To assist NZ government agencies in conducting
robust due diligence on potential cloud solutions, Microsoft New Zealand produced the
Microsoft Response to Cloud Computing Information Security and Privacy
Considerations.33 The services in the scope of this response is as follows:
Table 10 - Cloud Computing Considerations Scope
Service Components
Office 365 Exchange Online, SharePoint Online, and Skype for Business Online
Azure Virtual Machines, Cloud Services, Batch, Web Apps, Mobile Services, Notification Hub,
Storage, SQL Database, HDInsight, Virtual Network, Traffic Manager, ExpressRoute, Service
Bus, BizTalk Services, Active Directory, Multi-Factor Authentication, Rights Management
Service, Media Services, Scheduler.
Intune Intune
Azure AD A specific response for these services is currently being produced.
31 Depending on the implementation of Azure Active Directory, the agency retains control over user
password policy through their current AD deployment. 32 https://azure.microsoft.com/en-us/support/trust-center/compliance/ 33 http://www.microsoft.com/en-us/trustcenter/compliance/nzcc
Prepared for Department of Internal Affairs
Page 29
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
ISO/IEC 27001 - This family of standards outlines hundreds of controls and control
mechanisms to help organisations of all types and sizes keep information assets secure.
ISO/IEC 27001 is one of the most widely recognised certifications for a cloud service and
a foundation of Microsoft’s approach to information security.34
ISO/IEC 27018:2014 - Microsoft’s cloud services were the first to adopt ISO/IEC
27018:2014, the first international code of practice for cloud privacy. It gives specific
guidance to cloud service providers (CSPs) acting as processors of personally identifiable
information (PII) on assessing risks and implementing state-of-the-art controls for
protecting PII.35
SOC 1 & 2 Type 2 Reports - Service Organisation Controls (SOC) are a series of
accounting standards that measure the control of financial information for a service
organisation. Azure’s SOC 1 and SOC 2 Type 2 audit reports attest to the effectiveness of
the design and operation of its security controls.36
CCSL (IRAP) - The Certified Cloud Services List identifies cloud services that have
successfully completed an IRAP assessment by the Australian government, and have
been awarded certification by the Australian Signals Directorate (ASD).
FedRAMP - The Federal Risk and Authorization Management Program (FedRAMP) is a
mandatory US government program that provides a standardized approach to security
assessment, authorization, and monitoring for cloud services used by federal agencies.
UK G-Cloud - Government Cloud (G-Cloud) is a UK government initiative to promote
government-wide adoption of cloud computing. The Crown Commercial Service (an
agency that works to improve commercial and procurement activity by the government)
renewed the classification of Microsoft’s in-scope cloud services to G-Cloud v6.
CSA STAR37 – the industry’s most powerful program for security assurance in the cloud.
STAR encompasses key principles of transparency, rigorous auditing, harmonization of
standards, with continuous monitoring also available in late 2015. STAR certification
provides multiple benefits, including indications of best practices and validation of
security posture of cloud offerings. Microsoft cloud services are included in the CSA
STAR registry for self-assessment.
34 http://www.microsoft.com/en-us/trustcenter/compliance/iso-iec-27001 35 http://www.microsoft.com/en-us/trustcenter/compliance/iso-iec-27018 36 https://www.microsoft.com/en-us/TrustCenter/Compliance/SOC1-and-2 37 https://cloudsecurityalliance.org/star/#_overview
Prepared for Department of Internal Affairs
Page 30
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
3 Reference Architecture Technologies
The table below provides a summary of the key email protection capabilities of SEEMail,
Microsoft Exchange, and Exchange Online/Office 365.
Table 11 - Email Protection Technology Summary
Capability SEEMail Exchange 2010-2016 Exchange Online/Office 365
S/MIME Digital Signatures and Encryption
(includes non-repudiation) Y Y Y
Any-Any Message Encryption N N Y
Data Loss Prevention Y Y‡ Y
Anti-Spam/Anti-Virus Y* Y Y
Transport Encryption Y Y Y
Information Rights Management N/A Y Y**
Advanced Threat Protection N/A Y‡‡ Y
* Verification of other SEEMail gateways for inbound email provides limited anti-spam protection.
** Azure IRM and right-enabled office applications required to provide capability.
‡ DLP not available in Exchange 2010.
‡‡ EOP ATP can be used with on-premises Exchange.
3.1 SEEMail
3.1.1 Service Description
SEEMail secures email traffic over the internet between participating New Zealand government
agencies. The system is a gateway-to-gateway encrypted email service where the email is
encrypted and decrypted by the agency’s SEEMail server and not at the end device.38
An e-mail containing a SEEMail trigger word within square brackets [ ] or braces { } will only ever
be sent securely to another SEEMail Participating Agency or Trusted Partner. The trigger word
can be in either the SUBJECT, BODY or ATTACHMENT of the e-mail. SEEMail will prevent an
email with a trigger word from being sent to a non-SEEMail organisation. The trigger words are:
SEEMAIL
TRUSTED
IN-CONFIDENCE / IN CONFIDENCE
38 https://www.ict.govt.nz/services/show/SEEMail
Prepared for Department of Internal Affairs
Page 31
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
SENSITIVE
RESTRICTED
Use of trigger words without the use of square brackets or braces will not prevent the email
from being sent to a non-SEEMail recipient.
Organisations that participate in the SEEMail service fall into one of two groups. Each group has
two levels of security:
1. Government agencies and public sector organisations:
a. SEEMail Restricted: Government agencies that have been formally accredited to
handle classified documents up to and including RESTRICTED and SENSITIVE.
b. SEEMail Standard: All government agencies without a formal accreditation and
able to handle classified documents up to and including IN CONFIDENCE.
2. Non-government ‘trusted partner’ organisations:
a. Trusted Partner Restricted: Organisation, sponsored by a SEEMail Restricted
agency, that have been formally accredited to handle classified documents up
to and including RESTRICTED and SENSITIVE.
b. Trusted Partner Standard: Organisation, sponsored by a SEEMail agency, and
able to handle classified documents up to and including IN CONFIDENCE.
Table 12 - SEEMail Capability Overview
IN C
ON
FID
EN
CE
SEN
SIT
IVE
RESTR
ICTED
CO
NFID
EN
TIA
L
SEC
RET
TO
P S
EC
RET
Agencies Yes
(Non-Accredited)
Yes
(Accredited Only)
Yes
(Accredited Only) No No No
Partners Yes
(Non-Accredited)
Yes
(Accredited Only)
Yes
(Accredited Only) No No No
A SEEMail-specific accreditation process ensures that SEEMail infrastructure and software has
been installed and configured to the required SEEMail specification. Once accreditation has
been achieved, agencies are able to send and receive messages marked SENSITIVE and/or
RESTRICTED.
Prepared for Department of Internal Affairs
Page 32
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Agencies are able to install and operate their own SEEMail service, or they can transfer this
responsibility to a third-party service provider. Some service providers host their own shared
SEEMail gateway that can service multiple agencies.
3.1.2 Message Security Features
The SEEMail solution protects email sent between participating agency email gateways. This
provides both sender and recipient assurance that a message has not been viewed or modified
in transit between two SEEMail gateways. To ensure that agencies are compliant with the
SEEMail specification, all inbound and outbound email must flow through the SEEMail gateway.
This requirement is a key consideration for the architecture of email services that incorporate
Exchange Online.
There is no constraint on the software products that are able to operate as SEEMail gateways, as
long as they meet the SEEMail specifications and pass the SEEMail SMARTS tests.
Agency 1SEEMail Gateway
Agency 2SEEMail Gateway
Agency 1eMail
System
Agency 2eMail
System
Agency 2eMail Client
Agency 1eMail Client
SEEMail Protected Message
Unencrypted MessageUnencrypted MessageUnencrypted MessageUnencrypted Message
Figure 6 - SEEMail Message Protection
Secure Multipurpose Internet Mail Extensions (S/MIME)
Multipurpose Internet Mail Extensions (MIME) is a format for transmitting email messages
between Simple Mail Transfer Protocol (SMTP) servers over the internet. S/MIME is a public key-
based standard for protecting MIME messages. S/MIME provides two primary security services -
Digital signatures and Message encryption.39 Gateways that send and receive SEEMail email use
S/MIME for message encryption and signing.
Digital Signatures
Digital signatures are the digital counterpart to the traditional, legal signature on a paper
document. Digital signatures provide the following security capabilities:
Authentication - Because there is no authentication in SMTP email, there is no way to
know who actually sent a message. Authentication in a digital signature solves this
39 https://technet.microsoft.com/en-us/library/aa995740(v=exchg.65).aspx
Prepared for Department of Internal Affairs
Page 33
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
problem by allowing a recipient to know that a message was sent by the person or
organisation who claims to have sent the message.
Non-repudiation - Because SMTP email does not provide a means of authentication, it
cannot provide nonrepudiation. The uniqueness of a digital signature prevents the owner
of the signature from disowning the signature. This capability is called nonrepudiation.
Data integrity - When the recipient of a digitally signed message validates the digital
signature, the recipient is assured that the email that is received is the same message
that was signed and sent, and has not been altered while in transit. Any alteration of the
message while in transit after it has been signed invalidates the signature.
Message Encryption
An SMTP internet email message can be read by anyone who sees it as it travels or views it
where it is stored. These problems are addressed by S/MIME through the use of encryption.
Message encryption provides two specific security capabilities:
Confidentiality - Only the intended recipient can view the contents, and the contents
remain confidential and cannot be known by anyone else who might receive or view the
message.
Data integrity – Encryption of the message prevents the data from being read and then
modified, preserving the integrity of the information. As with digital signatures, message
encryption provides data integrity services as a result of the specific operations that
make encryption possible.
Sender Verification
SEEMail provides additional non-repudiation of messages by verifying that an email from a user
in another SEEMail agency has been sent by that agencies SEEMail gateway. If an email from a
user in another SEEMail agency does not originate from that agency’s SEEMail gateway, the
message is delivered to the recipient as an attachment within a WARNING email.40
Public Key Infrastructure
S/MIME relies on access to a Public Key Infrastructure (PKI) service that is responsible for issuing,
validating and revoking the certificates used for digital signatures and message encryption.
40 This behavior will affect notification emails from Office 365 services like OneDrive for Business and
SharePoint Online when files are shared between users. The email appears to be sent by the user sharing
the file, but originates from the Office 365 service. Agencies need to create Outbound Connector from
Exchange Online Protection (EOP) to the agency’s email gateway and then configuring a transport rule to
redirect notification messages from OneDrive/SharePoint Online to that Outbound Connector.
Prepared for Department of Internal Affairs
Page 34
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
SEEMail includes a private New Zealand Government PKI service that is managed on behalf of all
agencies by the Department of Internal Affairs (DIA). DIA have in turn contracted a 3rd party
(Liverton) to provide day-to-day operation and maintenance for the PKI service.
All agencies running a SEEMail gateway requires access to the public keys of every other SEEMail
participating agency in order to sign and validate S/MIME digital signatures and encrypt/decrypt
S/MIME data. After downloading the keys from an LDAP server, the keys are typically cached on
the SEEMail gateway itself and are checked periodically to ensure that they have not expired or
been revoked by the PKI.
Transport Layer Security
Once an email is processed by the SEEMail gateway it will be sent unencrypted to the agency
email server. If the email passes through public network or shared network infrastructure, then
appropriate encryption MUST be used to protect the information during such transit or
storage.41
TLS v1.2 where both ends can authenticate themselves and where a minimum level of
encryption is enforced.
Secured tunnels using a VPN protocol such as IPSec. Such tunnels may be established
by hardware or software module.
An implementation of S/MIME, simpler than SEEMail, on a border mail gateway within an
Agency’s trusted network.
3.2 Exchange and Exchange Online
3.2.1 Service Description
Microsoft Exchange
Microsoft Exchange is Microsoft’s on-premises email and collaboration platform. It enables
email, calendaring, task tracking, contact and other core collaboration features across a range of
end-user devices. This reference architecture applies to Exchange 2010, 2013 and 2016 unless
explicitly noted.
Exchange Online
Microsoft Exchange Online is component of Office 365. It is a hosted messaging solution that
delivers the capabilities of Microsoft Exchange Server as a cloud-based service. It gives users
41 SEEMail v3.1 Technical Specification document, page 50
Prepared for Department of Internal Affairs
Page 35
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
access to email, calendar, contacts, and tasks from PCs, the web, and mobile devices. It
integrates fully with Active Directory, enabling administrators to use group policies, as well as
other administration tools, to manage Exchange Online features across their environment.
Organisations that subscribe to Exchange Online retain control over the messaging services they
offer to users, but they do not have the operational burden of on-premises server software. With
the Exchange Online, email is hosted on servers that support multiple customers simultaneously.
These servers are housed in Microsoft data centers and are accessible to users from inside a
corporate network or over the Internet.42
3.2.2 Message Security Features
Exchange and Exchange Online provide a number of features to ensure the security and privacy
of customer information. These features complement the protections available to SEEMail
participating agencies. As part of developing a secure email architecture, agencies considering
adoption of Exchange Online and/or Office 365 should look to incorporate these additional
capabilities.
Features that are relevant to the security of email messages are described in the following
subsections.
S/MIME Digital Signatures and Message Encryption
Exchange and Exchange Online provide the same S/MIME technology as SEEMail, however the
implementation differs. Exchange and Exchange Online S/MIME provides end-to-end message
protection between sender and recipient email clients. Exchange and Exchange Online S/MIME
messages can be sent between any parties that hold the appropriate customer-generated
certificates.43
Agency 1eMail
Gateway
Agency 2eMail
Gateway
Agency 1eMail
System
Agency 2eMail
System
Agency 2eMail Client
Agency 1eMail Client
S/MIME Protected Message
S/MIME Protected MessageS/MIME Protected MessageS/MIME Protected MessageS/MIME Protected Message
Figure 7 - Office 365 S/MIME
42 https://technet.microsoft.com/library/jj819276.aspx 43 https://blogs.office.com/2014/02/26/smime-encryption-now-in-office-365/
Prepared for Department of Internal Affairs
Page 36
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Exchange and Exchange Online S/MIME is a per-message, user-initiated activity driven from the
Outlook client, and it can be difficult to enforce across consistent use across the user
community. Users can manually select the S/MIME digital signature and/or encryption options
prior to sending, or Outlook can be configured to encrypt and sign all outgoing messages.
Recipients will need to hold a copy of the appropriate keys in order to decrypt and verify the
message.44
Exchange Online Protection
Microsoft Exchange Online Protection (EOP) is a cloud-based email filtering service included as
part of Exchange Online and includes features to safeguard your organisation from malware and
messaging-policy violations. EOP can simplify the management of agency messaging
environments and alleviate many of the burdens that come with maintaining on-premises
hardware and software.
EOP runs on a worldwide network of datacenters that are designed to provide the best
availability. For example, if a datacenter becomes unavailable, email messages are automatically
routed to another datacenter without any interruption in service.45 For New Zealand customers,
the Office 365 tenancy, including EOP is hosted in Australian datacentres.
Figure 8 – EOP
EOP includes the ability to define policy-based transport rules that use connectors to
automatically route email between EOP and other specified endpoints. This includes both
external senders/recipients, and an organisations own on-premises email infrastructure. These
44 https://support.office.com/en-us/article/Encrypt-messages-by-using-S-MIME-in-Outlook-Web-App-
2e57e4bd-4cc2-4531-9a39-426e7c873e26?CorrelationId=276a2ce4-d59a-4afd-a7a3-
71434c4422a3&ui=en-US&rs=en-US&ad=US#__toc381088759 45 https://technet.microsoft.com/en-us/library/jj723119(v=exchg.150).aspx
Prepared for Department of Internal Affairs
Page 37
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
connectors support the hybrid Exchange architectures described later in this document.46 They
can also be used to enforce TLS communications with other SMTP servers. Other policy features
include: 47
Comprehensive anti-malware and anti-spam protection
The Ability to audit inbound and outbound messages.
Use Data loss prevention (DLP) to identify, monitor, and protect sensitive information
through deep content analysis.
Automatically send and receive encrypted messages with any party – even if they are not
a SEEMail organisation.
Anti-Spam and Anti-Malware
If you’re a Microsoft Exchange Online or Exchange Online Protection (EOP) customer, your email
messages are automatically protected against spam and malware. Spam is unsolicited (and
typically unwanted) email messages. The majority of spam is deleted via connection filtering,
which is based on the IP address of the sender. The service then inspects the contents of the
message. By default, content-filtered spam is sent to the recipient’s Junk Email folder.48
Microsoft Exchange Online Protection helps combat malware in your email messaging
environment (Exchange Online Protection helps protect your on-premises mailboxes and is also
the malware filtering solution for cloud-hosted mailboxes in Exchange Online). The service offers
multi-layered malware protection that’s designed to catch all known malware traveling inbound
to or outbound from your organisation.49
Data Loss Prevention
Exchange and EOP DLP policies are made up of transport rules, actions, and exceptions used to
filter email messages and attachments. One important new feature of transport rules is a new
approach to classifying sensitive information. This new DLP feature performs deep content
46 EOP protects message flowing between the on-premises and cloud-based email infrastructures used by
an agency in a hybrid architecture.
47 Messages protected by SEEMail must pass through EOP unencrypted in order for anti-spam, anti-
malware and other content-based filtering features to function correctly.
48 https://support.office.com/en-us/article/Office-365-Email-Anti-Spam-Protection-6a601501-a6a8-4559-
b2e7-56b59c96a586?ui=en-US&rs=en-US&ad=US 49 https://technet.microsoft.com/en-us/library/jj200669(v=exchg.150).aspx
Prepared for Department of Internal Affairs
Page 38
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
analysis through keyword matches, dictionary matches, regular expression evaluation, and other
content examination to detect content that violates organisational DLP policies.50
Exchange and EOP DLP features (including interactive warnings in Microsoft Outlook that can be
optionally overridden) can identify and monitor many categories of sensitive information
defined within the conditions of policies, such as private identification numbers or credit card
numbers. You can define custom policies and transport rules or use pre-defined DLP policy
templates provided by Microsoft. With Exchange 2013/2016 and Exchange Online Protection,
you can use Document Fingerprinting to easily create a sensitive information type based on a
standard form.51
Office 365 Message Encryption
Office 365 Message Encryption is an additional service that allows users to send encrypted email
messages to people either inside or outside their organisation. Designated recipients can easily
view their encrypted messages and return encrypted replies regardless of the destination email
service they use.
Office 365 Message Encryption is built on Microsoft Azure Rights Management (Azure RMS).
Administrators can enable message encryption by defining transport rules that determine the
conditions for encryption. A rule can require the encryption of all messages addressed to a
specific recipient, for example. 52 This service allows agencies to send encrypted messages to any
recipient, regardless of whether or not they are a SEEMail participating agency.
The following diagram summarises the passage of an email message through the encryption
and decryption process.
50 Although DLP cannot be used to enforce S/MIME on inbound/outbound messages, Office 365
Encryption and Azure Rights Management are supported. 51 https://technet.microsoft.com/en-us/library/jj150527(v=exchg.150).aspx 52 https://technet.microsoft.com/library/dn569286.aspx
Prepared for Department of Internal Affairs
Page 39
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Figure 9 - Office 365 Message Encryption
TLS Secure Mail Transport
TLS is a standard protocol that is used to provide secure communications on the Internet or
intranet. It enables clients to authenticate servers or, optionally, servers to authenticate clients. It
also provides a secure channel by encrypting communications.
Exchange and Exchange Online support opportunistic TLS. This enables any sending system to
encrypt an inbound SMTP session. By default, Exchange and Exchange Online also attempt TLS
for all outbound SMTP connections.53
Exchange and Exchange Online also support mutual TLS. With mutual TLS authentication, each
server verifies the identity of the other server by validating a certificate that's provided by that
other server.54
For agencies with a hybrid Exchange/Exchange Online deployment, messages sent between
Exchange and Exchange Online are configured to use forced TLS.
53 Connector properties define the type of TLS (opportunistic or forced) used by inbound and outbound
connections. This applies to all messages passing through the connector. 54 https://technet.microsoft.com/en-us/library/bb430753(v=exchg.150).aspx
Prepared for Department of Internal Affairs
Page 40
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Information Rights Management
Azure Rights Management and Active Directory Rights Management use permissions and
authorisation to help prevent sensitive information in files and emails from being printed,
forwarded, or copied by authorised users, or accessed by unauthorised people.
After permission for a document or message is restricted by using this technology, the usage
restrictions travel with the document or email message as part of the contents of the file.
Microsoft Office implements support for these technologies by using Information Rights
Management (IRM) features.55 56
Active Directory RMS and Azure RMS manage licensing and other server functions that work
with IRM to provide rights management to client applications such as Office 2013. An RMS-
enlightened client program, such as Office 2013, lets users create and view rights-protected
content.
Advanced Threat Management
Exchange Online Advanced Threat Protection protects email in real time against unknown and
sophisticated attacks. It protects against unsafe attachments and expands protection against
malicious links by providing real-time, time-of-click protection against malicious links in
messages. By complementing the security features of Exchange Online Protection in these ways,
it provides agencies with better zero-day protection for email messaging.57
Figure 10 - EOP ATM
55 https://technet.microsoft.com/en-us/library/cc179103.aspx 56 https://technet.microsoft.com/en-us/library/jj585016.aspx 57 https://products.office.com/en-us/exchange/online-email-threat-protection
Prepared for Department of Internal Affairs
Page 41
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
ExpressRoute
ExpressRoute lets you extend your on-premises networks into the Microsoft cloud (Azure, CRM
Online and Office 365) over a dedicated private connection facilitated by a connectivity provider.
ExpressRoute connections do not go over the public Internet. This allows ExpressRoute
connections to offer more reliability, faster speeds, lower latencies, and higher security than
typical connections over the Internet.58
Figure 11 – ExpressRoute
ExpressRoute has a constantly growing ecosystem of connectivity providers and SI partners. The
nearest ExpressRoute locations for New Zealand is Sydney/Melbourne. 59 The current list of
providers are:
Equinix
Megaport
NEXTDC
Microsoft uses industry standard layer 3 dynamic routing protocol (BGP) to exchange routes
between your on-premises network, your instances in Azure, and Microsoft public addresses.
ExpressRoute establishes multiple BGP sessions with customer networks for different traffic
profiles.
Each ExpressRoute circuit consists of two connections to two Microsoft Enterprise edge routers
(MSEEs) from the connectivity provider / customer network edge. Microsoft will require dual
58 https://azure.microsoft.com/en-us/documentation/articles/expressroute-introduction/ 59 https://azure.microsoft.com/en-us/documentation/articles/expressroute-locations/
Prepared for Department of Internal Affairs
Page 42
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
BGP connection from the connectivity provider / customer side – one to each MSEE. You may
choose not to deploy redundant devices / Ethernet circuits at your end. However, connectivity
providers use redundant devices to ensure that your connections are handed off to Microsoft in
a redundant manner. A redundant Layer 3 connectivity configuration is a requirement for the
ExpressRoute SLA to be valid.
ExpressRoute is available to agencies through the Telecommunications as a Service (TaaS)
Service Catalogue.
Prepared for Department of Internal Affairs
Page 43
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
4 Architecture Patterns
The architecture patterns in this documented are intended primarily for architects and technical
staff involved in the planning, deployment and operation of email services. An agency may
undertake these activities using their own staff, or they may use an external IT services provider
with specific expertise to assist them with some or all of these activities.
4.1 Architecture Approach
This section defines agency-agnostic architecture patterns for Microsoft Exchange, SEEMail and
Exchange Online. Other Microsoft or 3rd party components may be included where they are
required to support the implementation of these products.
The architecture patterns described in this section address three key scenarios:
Agencies with on-premises email deployment.
Agencies with a hybrid deployment (both on-premises and cloud).
Agencies exclusively consuming cloud-based email services.
Each architecture includes patterns to help agencies understand how SEEMail gateways impacts
their email architecture. Many patterns include options (variants) that may be implemented in
order to meet the needs of specific agencies. The architectures provide a transition roadmap for
agencies looking to move email services to the cloud.
1. The on-premises architecture describes the current state agency email environment
where exchange is deployed and running in their own network environment and
managed by the agency or their ITSM partner.
2. The hybrid architecture describes a transition state that many agencies will find
attractive as they begin to migrate email services to Exchange Online. Some agencies will
retain a hybrid architecture for an extended period of time to meet technical and/or
business requirements of their organisation.
3. The cloud architecture is a target state in which email services are delivered entirely
through Exchange Online. An agency can elect to manage user mailboxes and Exchange
Online configuration through their on-premises Active Directory, or directly in Exchange
Online.
The architecture patterns describe logical interactions between components, and should not be
confused with state or flow architecture diagrams.
Prepared for Department of Internal Affairs
Page 44
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
On-Premises Hybrid Cloud
Email Service Transition
Email Service Transition
Email Service Transition
Figure 12 - Email Service Transition
In relation to the TOGAF architecture continuum, this reference architecture can be considered
an “industry architecture” which guides the integration of common systems components with
industry-specific components, and guides the creation of industry solutions for targeted
customer problems within a particular industry.60
4.1.1 Cloud Services
Today, most agencies host their email infrastructure in agency datacentres. This infrastructure is
managed by an agencies own IT operations staff. Some agencies have elected to use 3rd party
providers to provide datacentre facilities, infrastructure, IT operations services (or a combination
of these). Both agency and 3rd party hosting and management approaches are referred to by
this reference architecture as “on-premises” email deployments since the agency retains
ownership and control over the email service.
This approach requires an agency being responsible for a number of capital and operational
costs associated with the email service. Examples of such costs include the following:
Procurement and operation of server, storage and network infrastructure.
Facilities to host infrastructure and the utility costs associated with power and cooling.
Costs of operating managed data network links between agency locations.
Procurement and maintenance for servers, storage network and hardware.
Licenses and technical support agreements for operating systems and email software.
Staff costs and ongoing training to ensure they perform their duties effectively.
60 http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap39.html#tag_39_04_02
Prepared for Department of Internal Affairs
Page 45
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Management of the service, including problem resolution and enhancements to the
current service.
Information Security capabilities to protect agency systems from email-borne threats,
and prevent the unauthorised dissemination of agency data.
Cloud services are an attractive model for agencies that do not wish to continue with the day to
day responsibility of maintaining the infrastructure and service management aspects of an email
service. Instead, the Cloud Service Provider (CSP) runs the email service on behalf of the
organisation.
The service incorporates the hardware, facilities, procurement, licenses and operational
costs of the service – overdue, expensive and disruptive server upgrades are no longer
need to be tolerated.
The customer does not need to deploy additional storage to support expanding mailbox
sizes or mail archive stores.
Email service enhancements are provided as part of the service subscription,
automatically enabling new security or accessibility features for users.
The service runs on sophisticated platforms and is protected by security controls that
many agencies would not be able to provide themselves.
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
4.2 Pattern Summary
The section provides an overview of the different patterns and options defined in this reference architecture. The patterns for
Exchange Online deployments without SEEMail are provided in Appendix A – Non-SEEMail Patterns.
Table 13 - Architecture Pattern Summary
Pattern Name Pattern Description Agency Profile Key Benefits Key Considerations
On
-Pre
mis
es
4.5.1 - On-Premises Exchange
with SEEMail
Traditional Exchange
deployment with SEEMail
running in agency environment.
A SEEMail participating agency
in either the restricted or
standard group.
Needs to realise the benefit of a
recent investment in on-
premises email services.
Needs all email to stay on-
premises for regulatory or
security compliance purposes.
Maintain complete control over
the email service. Internal mail
flow stays within the agency
network.
Must maintain and update the
hardware, software and service
management elements of the
email service.
4.5.1.1 - On-Premises Exchange
with SEEMail:
Hosted SEEMail Gateway Option
Based on pattern in 4.5.1, but
with SEEMail hosted by 3rd party
provider.
Does not want to maintain their
own SEEMail gateway.
Hosted SEEMail service is
managed by 3rd party on behalf
of the agency, reducing
administrative burden and
infrastructure requirements.
Changes to hosted SEEMail
service require coordination
with agency to prevent
disruptions to email service.
Network link failure between
hosted SEEMail and agency
network will cause email service
outage.
Appropriate protection of link
between agency network and
3rd party provider.
Hyb
rid
4.6.1 - Hybrid Exchange with
SEEMail (Central Transport)
Agency adopts Exchange
Online, but retains on-premises
A SEEMail participating agency
in either the restricted or
standard group.
Balance benefits of cloud-based
service with control and
Does not leverage built-in
benefits of cloud-based service
Prepared for Department of Internal Affairs
Page 47
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Exchange environment for
subset of users.
Mail routed through existing
SEEMail and Exchange
infrastructure instead of
Exchange Online to retain
protection of all messages.
Needs to support hybrid
identity management and
configuration of cloud-based
services.
Needs to maintain some on-
premises mailboxes to support
business rules or non-functional
requirements like network
latency.
Requires the flexibility of on-
premises exchange instances
(e.g branch offices) but wants to
leverage benefits of cloud-
based email services.
Has no restrictions relating to
the use of offshore email
services.
flexibility of on-premises
Exchange.
Route inbound/outbound email
through agency mail services to
maintain control and visibility.
Less disruption to on-premises
configuration.
like anti-malware and anti-spam
for inbound internet email.
Must maintain existing on-
premises Exchange
infrastructure, in addition to the
service costs of Exchange
Online.
Network link failure between
Exchange Online and agency
network results in loss of service
for cloud-based mailbox users
4.6.1.1 - Hybrid Exchange with
SEEMail:
EOP Email Protection Option
Based on pattern in 4.6.1, but
with EOP providing internet
email protection, hosted in
O365.
Does not want to maintain on-
premises anti-virus and anti-
spam.
Can reduce on-premises
complexity and infrastructure.
Able to leverage built-in
benefits of cloud-based services
like anti-malware and anti-
spam.
Network link failure between
Exchange Online and agency
network causes loss of email
service.
4.6.1.2 - Hybrid Exchange with
SEEMail:
Hybrid Hosted SEEMail Gateway
Option
Based on pattern in 4.6.1, but
with SEEMail hosted by 3rd party
provider.
Does not want to maintain their
own SEEMail gateway.
SEEMail service is managed by
3rd party on behalf of the
agency, reducing administrative
burden and infrastructure
requirements.
Network link failure between
hosted SEEMail and agency
network will cause email service
outage.
Appropriate protection of link
between agency network and
3rd party provider.
Prepared for Department of Internal Affairs
Page 48
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
4.6.1.3 - Hybrid Exchange with
SEEMail:
Hybrid Non-Exchange Option
Based on pattern in 4.6.1, but
with Exchange Online
supporting a non-Exchange on-
premises email environment.
Wants to leverage Office 365,
but also needs to maintain their
existing non-Microsoft email
environment.
Balance benefits of cloud-based
service with control and
flexibility of on-premises email.
Route inbound/outbound email
through agency mail services to
maintain control and visibility.
Must maintain some on-
premises email infrastructure, in
addition to the service costs of
Exchange Online.
Network link failure between
Exchange Online and agency
network will cause email service
outage.
Clo
ud
4.7.1. - Exchange Online with
SEEMail
Agency adopts Exchange Online
with SEEMail and moves all
mailboxes to the cloud.
Some Exchange components
are retained to support
centralised management of
users and mailboxes through
AD.
A SEEMail participating agency
in the standard group.
Wants to minimise Exchange
footprint and leverage the
benefits of Exchange Online.
Managed email service that
removes the need for agency
management of most email
service components.
Route inbound/outbound email
through agency mail services to
maintain control and visibility.
Network link failure between
Exchange Online and agency
network will cause email service
outage.
Appropriate protection of link
between Exchange Online and
SEEMail gateway.
Requires agency strategy for
the monitoring, logging and
auditing of email messages to
identify vulnerabilities and
threats.
4.7.1.1 - Exchange Online with
SEEMail:
Cloud-Based Administration
Option
Based on pattern in 4.7.1, but
without the need to retain on-
premises Exchange
management components.
Wants to manage email
through Exchange Online EAC,
and potentially retire on-
premises Active Directory.
A cloud-centric agency that is
not using AD or Azure AD
hybrid identity.
Removes all on-premises
Exchange infrastructure from
agency network.
Requires remediation activity to
migrate mailbox administration
from Active Directory to
Exchange Online.
4.7.1.2 - Exchange Online with
SEEMail:
Exchange Online with Hosted
SEEMail Option
Based on pattern in 4.7.1, but
with SEEMail hosted by 3rd party
provider.
Does not want to maintain their
own SEEMail gateway.
SEEMail service is managed by
3rd party on behalf of the
agency, reducing administrative
Network link failure between
Exchange Online and agency
network will cause email service
outage.
Prepared for Department of Internal Affairs
Page 49
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
burden and infrastructure
requirements.
Network link failure between
Exchange Online and SEEMail
will cause email service outage.
Appropriate protection of link
between Exchange Online and
3rd party provider.
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
4.3 Solution Building Blocks
The architectures, patterns and options are all built from common solution building blocks
(SBBs) that allow the differences between each architecture to be easily compared.
Solution Building Blocks are reusable, inter-dependent packages of functionality defined to
meet one or more business needs.61 Solution Building Blocks (SBBs) are a subtype of building
blocks that define (amongst other things), what products and components will implement
specific functionality.
Table 14 - Solution Building Blocks
Component Description Notes
Agency DNS MX Record DNS Mail Exchanger (MX) record that resolves
front-end host for delivery of SMTP email to
the agency. The MX record can be held by an
agency’s own DNS service, or a DNS service
maintained by a 3rd party.
In this pattern, the MX record is hosted
by the agency and points to the
agencies own front-end AV service that
inspects all incoming email prior to any
other processing.
3rd Party AV/AS Many agencies have a 3rd party front-end anti-
virus and anti-spam service that performs
initial processing of incoming email to prevent
malware from propagating in the agency
environment, and to prevent spam from
consuming agency email resources.
Some agencies place anti-spam and
anti-virus services in front of the SEEMail
gateway and point their MX record at
this component. This allows agencies to
screen email at the earliest possible
point, but encrypted SEEMail messages
are not able to be scanned for malware.
Agencies not running a 3rd-party AV/AS
service can use the Edge Transport
Server.
Agencies that have subscribed to
Exchange Online can use the AV/AS
capabilities of Exchange Online
Protection, even if they retain an on-
premises or hybrid email architecture.
Edge Transport Server The Microsoft Exchange Server Edge Transport
server role is deployed in the agency DMZ and
handles all Internet-facing mail flow, providing
protection against spam and viruses.
In a hybrid architecture, the Edge Transport
component is the interface between the on-
premises environment and the cloud-based
Exchange Online environment.
Agencies not using the Edge Transport
Server will typically run a 3rd-party AV/AS
service.
Edge transport Servers also run a local
Active Directory Lightweight Directory
Service that relies on data replicated
from an Agency Active Directory
instance.
Client Access Server (CAS) The Client Access Server functions much like a
front door, admitting all client requests and
routing them to the correct active Mailbox
database. The Client Access server provides
network security functionality such as Secure
Client Access servers are not supported
in perimeter networks, and they must be
deployed within the internal Active
Directory environment. Every Active
Directory site that contains a Mailbox
61 http://pubs.opengroup.org/architecture/togaf9-doc/arch/chap37.html
Prepared for Department of Internal Affairs
Page 51
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Component Description Notes
Sockets Layer (SSL) and client authentication,
and manages client connections through
redirection and proxy functionality.
server must also contain a Client Access
server.
In a cloud email architecture, the CAS
component is retained to support
administration of Exchange Online users
and mailboxes.
In Exchange Server 2016, the Mailbox
server role includes the Client Access
Server functions.
Mailbox Server The Mailbox server role hosts both mailbox
and public folder databases and also provides
email message storage.
The Mailbox server role interacts directly with
Active Directory, the Client Access server, and
Microsoft Outlook clients
In Exchange Server 2016, the Mailbox
server role includes the Client Access
protocols, Transport service, mailbox
databases, and Unified Messaging
components.
Active Directory Domain Services When you install Exchange, changes are made
to the Active Directory forest and domains.
Exchange does this so that it can store
information about the Exchange servers,
mailboxes, and other related objects.
Most agencies will continue to manage
user objects and mailboxes from Active
Directory, even if all mailboxes are
hosted in Exchange Online.
Email Client Client software interacts with Exchange
services and provides user access to email,
calendar and other functions.
Clients include Microsoft Outlook, Outlook
Web App (formally Outlook Web Access) and
ActiveSync clients for mobile devices.
Administration Client Administrative activity is driven through
Exchange Admin Centre (EAC). EAC is a web-
based management console which replaces
the Exchange Management Console (EMC) and
the Exchange Control Panel (ECP) used to
manage Exchange Server 2010.
EAC is accessed through CAS servers.
Can be configured to support
administrative access from external
networks, although this is not
recommended.
Agency SEEMail Gateway An SMTP Gateway that has been configured to
support the SEEMail S/MIME encryption
configuration, and has passed the SEEMail
SMARTS test.
In this pattern, the SEEMail gateway is
the front-end mail component with
malware and spam services sitting
behind the gateway.
Remote SEEMail Gateway An external SMTP Gateway that has been
configured to support the SEEMail S/MIME
encryption configuration. The Agency gateway
will send/receive SEEMail protected messages
from these gateways.
Service Provider SEEMail Gateway An externally-managed SMTP Gateway that
has been configured to support the SEEMail
S/MIME encryption configuration, and has
passed the SEEMail SMARTS test.
Dimension Data, Datacom and others
operate such services on behalf of
agencies. Can be single or multi-tenant.
Prepared for Department of Internal Affairs
Page 52
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Component Description Notes
SEEMail PKI Service The service that publishes the certificates used
to protect and read SEEMail-protected S/MIME
messages. Also provides certificate revocation
and lookup services.
SMTP Gateway An SMTP server that relays mail to agency
recipients, and is used by agency email
systems to send email to external recipients.
Can be SMTP server managed by
another agency, or 3rd party SMTP relay.
Azure AD Connect This component manages syncronisation of
specified directory objects (including users and
optionally, password hashes) to Azure Active
Directory.62
Replaces previous Dirsync, Azure AD
Sync and FIM connector syncronisation
products. Uses the Azure AD Graph API
and Azure Service Bus.
This component is used in both hybrid
and cloud email architectures to support
management of Exchange Online.
ADFS Active Directory Federation Service (ADFS) is
required to provide single sign-on (SSO) to
Office 365 and cloud for agencies that do not
synchronise password hashes between their
on-premises AD and Azure AD.
If neither ADFS or AD Connect password
synch are used, Azure AD and AD-DS
must maintain separate passwords.
This component is used in both hybrid
and cloud email architectures to support
management of Exchange Online.
Azure AD Azure AD provides authentication,
authorisation and identity management
services for Office 365 components and any 3rd
party cloud applications that are integrated
with Azure AD.
This component is used in both hybrid
and cloud email architectures to support
management of Exchange Online.
Exchange Online Protection EOP is an O365 cloud service that protects
Exchange Online and on-premises Exchange
against spam and malware. Includes content-
based routing and filtering policies for
inbound and outbound email.
In a hybrid architecture, the EOP
component is the interface between the
on-premises environment and the cloud-
based Exchange Online environment.
Exchange Online Exchange Online is a managed email software
as a service (SaaS) product that is part of the
Office 365 suite of services. Email is stored in
the cloud and managed by Microsoft on behalf
of agencies.
Application Component An agency application that needs to send
SMTP email to internal users or the internet.
Can be cloud based or hosted by a 3rd
party. This reference architecture shows
an internally-hosted application.
62 https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-topologies/
Prepared for Department of Internal Affairs
Page 53
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
4.4 Network Security Considerations
One of the most important considerations for agencies looking to implement Exchange Online
in conjunction with SEEMail is the ability to retain the confidentiality and integrity of email
messages while they are in-transit.63
TLS uses encryption to establish a secure communication channel over a computer network. To
conform to the SEEMail and NZISM standards, TLS v1.2 must be used with the approved
cryptographic algorithms defined in the NZISM (SHA 384/AES-256/ESDSA P-384).
This architecture defines two types of TLS connections between hosts:
MANDATORY TLS – A connection between two interfaces that requires TLS.
Implementing mutual TLS will further increase the security of these connections.
OPTIONAL TLS – A connection between two interfaces where TLS is desirable, but not
required. The sending server can use opportunistic TLS for these connections.
These guidelines are intended to maintain the confidentiality and integrity of messages and
identity data as they flow across untrusted networks (like the internet).
Table 15 –TLS Configuration Guidelines
Host a Host b TLS Guidelines
Agency SEEMail Gateway Remote SEEMail Gateway Optional TLS ‡
Agency SEEMail Gateway SMTP Gateway Optional TLS
Agency SEEMail Gateway Edge Transport Server Optional TLS
Agency SEEMail Gateway Exchange Online Protection64 Mandatory TLS
Service Provider SEEMail Gateway Remote SEEMail Gateway Mandatory TLS
Service Provider SEEMail Gateway SMTP Gateway Optional TLS
Service Provider SEEMail Gateway Edge Transport Server Mandatory TLS
Service Provider SEEMail Gateway Exchange Online Protection65 Mandatory TLS
Exchange Online Protection SMTP Gateway Optional TLS
Exchange Online Protection Edge Transport Server Mandatory TLS
Edge Transport Server Mailbox Server Optional TLS
Mailbox Server Client Access Server Optional TLS
63 Client network security is not addressed in this section. The Exchange or Exchange Online endpoint that
a client connects to is not impacted by backend mail infrastructure integration between SEEMail,
Exchange and Exchange Online. 64 Or the optional 3rd party AV/AS service. 65 Or the optional 3rd party AV/AS service.
Prepared for Department of Internal Affairs
Page 54
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Host a Host b TLS Guidelines
Application Component Client Access Server Optional TLS
Application Component Exchange Online Protection Mandatory TLS
Email Client Client Access Server Optional TLS
Email Client Edge Transport Server Mandatory TLS
Email Client Exchange Online Mandatory TLS
Azure AD Connect Azure AD Mandatory TLS
ADFS Azure AD Mandatory TLS
SEEMail PKI Service Any SEEMail Gateway Mandatory HTTPS
‡ All messages between SEEMail gateways are protected by SEEMail S/MIME, so transport-layer TLS is not mandatory.
Agencies may further enhance email message security by implementing IRM, S/MIME or other
protection technologies in addition to transport-layer protections.
4.5 On-Premises Architectures
4.5.1 On-Premises Exchange with SEEMail Pattern
Many agencies are users of the SEEMail secure email service described earlier in this document.
Most of these agencies maintain their own SEEMail infrastructure in conjunction with their own
on-premises Exchange environment, as shown in Figure 13 below:
Prepared for Department of Internal Affairs
Page 55
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Email Client
Email Client
Client Access Server (CAS)
Mailbox Server
Edge Transport
Server
Internet
Active Directory Domain Services
Agency DNS MX Record
Admin Client
Agency SEEMail Gateway
Remote SEEMail Gateway
SMTP Gateway
3rd Party AV/AS Service
(optional)
SEEMail PKI
Service
Optional TLS
Optional TLS
Optional TLS
Mandatory HTTPSMandatory HTTPS
Optional TLS
Optional TLS
Optional TLS
Optional TLS
Mandatory TLS
Optional TLS
Agency Secured Network
Application Component
Optional TLS
Email Message
SEEMail Message
Email Message
Email Message
Email Message
Email Message
Email Message
Email Message
Email Message
Agency Secured Network
Figure 13 - On-Premises Exchange with SEEMail Pattern
Hosted SEEMail Gateway Option
Some agencies use hosted SEEMail gateways managed by 3rd parties outside of their own
network. For these agencies, the location of the SEEMail gateway differs, but the relationship to
other components remains unchanged. The relevant portion of this pattern is shown in Figure
14 below:
Prepared for Department of Internal Affairs
Page 56
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
IPSEC VPN, TaaS or Managed WAN
Service Provider Network
Agency DNS MX Record
Provider SEEMailGateway
Remote SEEMail Gateway
SMTP Gateway
Optional TLS
Optional TLS
Internet
3rd Party AV/AS Service
(optional)
Mandatory TLS
Edge Transport
Server
Optional TLS
Agency Secured Network
SEEMail Message
Email Message
Email Message
Email Message
Agency Secured Network
Figure 14 – Hosted SEEMail Gateway Option
Email traffic between the SEEMail gateway and Exchange is either:
a) An opportunistic TLS connection between the Service Provider’s SEEMail Gateway over
an IPSEC VPN or Telecommunications as a Service (TaaS) connection.
b) An opportunistic TLS connection between the Service Provider’s SEEMail Gateway over a
managed WAN connection such as the One.govt network.
4.6 Hybrid Architectures
A hybrid deployment provides the seamless look and feel of a single Exchange deployment
between an on-premises Exchange 2010, 2013 or 2016 Server environment and Exchange
Online. A hybrid deployment can serve as an intermediate step to moving completely to an
Exchange Online organisation. A hybrid deployment offers organisations the ability to extend
the features and administrative control of their existing on-premises Microsoft Exchange
environment to the cloud.
Most public sector agencies in New Zealand have existing Exchange environments. Most
agencies will continue to maintain these environments in parallel with Exchange Online so that
administrative controls and ‘source of authority’ can be driven from an agency’s own Active
Directory, which subsequently replicates data to Azure AD. Once a hybrid architecture has been
implemented, an agency can migrate mailboxes to Exchange Online as required. Some agencies
will retain a mixture of on-premises mailboxes and cloud-based mailboxes to support specific
business rules or non-functional requirements (e.g network latency at branch office locations).
The hybrid architecture allows an agency to select the mailbox hosting environment that best
fits the requirements of different user segments.
Prepared for Department of Internal Affairs
Page 57
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
When directory synchronisation is enabled for a tenant and a user is synchronised from on-
premises, most of the attributes cannot be managed from Exchange Online and must be
managed from on-premises. This is not due to the hybrid configuration, but it occurs because of
directory synchronisation. In addition, even if you have directory synchronisation in place
without running the Hybrid Configuration Wizard, you still cannot manage most of the recipient
tasks from the cloud.66
4.6.1 Hybrid Exchange Pattern
Instead of routing inbound and outbound email through EOP, agencies can deploy a hybrid
architecture where the agency MX record remains pointed at an on-premises SMTP server.
Known as centralised mail transport, all mail is routed through the on-premises email service,
except for intra-agency messages where both mailboxes reside in Exchange Online67. This
approach is helpful in compliance scenarios where all mail to and from the Internet must be
processed by on-premises servers.
Agencies that host their own SEEMail gateways, and are also considering a hybrid architecture
with Exchange Online will need to implement a Centralised Mail Transport architecture. This will
allow existing SEEMail gateways to remain in operation with no disruption to existing agency
SEEMail architecture, while unlocking the benefits of Office 365. This architecture is shown in
Figure 15 below:
66 https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150).aspx 67 Exchange Online can be alternatively configured to deliver messages for external recipients directly to
the Internet (https://technet.microsoft.com/en-us/library/jj659055(v=exchg.150).aspx)
Prepared for Department of Internal Affairs
Page 58
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Optional ExpressRoute Connection
Email Client
Email Client
Client Access Server (CAS)
Mailbox Server
Edge Transport
Server
Internet Office 365
Active Directory Domain Services
Azure AD
Azure AD
Connect
ADFS (optional)
Exchange Online
Protection
Exchange Online
Agency DNS MX Record
Admin Client
Agency SEEMailGateway
Remote SEEMail Gateway
Internet SMTP
3rd Party AV/AS Service
(optional)
SEEMail PKI
Service
Optional TLS
Optional TLS
Optional TLS
Mandatory HTTPS
Mandatory HTTPS
Optional TLS
Optional TLS
Optional TLS
Optional TLS
Mandatory TLSMandatory TLS
Mandatory TLS
Mandatory HTTPS
Mandatory HTTPS
Mandatory HTTPS
Optional TLS
Mandatory TLS
Application Component
Optional TLS
Agency Secured Network
Mandatory HTTPS
Email Message
SEEMail Message
Email Message
Email Message
Email Message
Email Message
Email Message
Email Message Email Message
Email Message
Email Message
Email Message
Mandatory HTTPS
Mandatory HTTPS
Agency Secured Network
Figure 15 - Hybrid Exchange Central Transport with SEEMail Pattern
There can be no other SMTP hosts or services between the on-premises Exchange Edge
Transport Server and EOP. Information added to messages that enables hybrid transport
features is removed when they pass through a non-Exchange server or an SMTP relay.68 Email
traffic between Exchange Online and Exchange is either:
a) A TLS connection between the Edge Transport Server and EOP over the internet.
b) A TLS connection between the Edge Transport Server and EOP over ExpressRoute. This
will also provide ExpressRoute connectivity between Azure AD Connect and Azure AD.69
Azure AD Connect uses TLS over ExpressRoute or internet connections to protect directory data
replicated to Azure AD.70
68 https://technet.microsoft.com/en-us/library/jj659055(v=exchg.150).aspx 69 https://azure.microsoft.com/en-us/services/expressroute 70 Subscribers that use Azure AD in conjunction with other Azure services can also use Site to Site (S2S)
and point to site (P2S) VPN connections to connect to Azure AD.
Prepared for Department of Internal Affairs
Page 59
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
EOP Email Protection Option
Agencies can retire their on-premises email anti-virus and anti-spam services by routing
inbound and outbound mail through Exchange Online protection. This ‘trombones’ mail
between the Agency SEEMail Gateway and Exchange Online for all inbound and outbound
messages.71 The relevant portion of this pattern is shown in Figure 16 below:
Optional ExpressRoute Connection
Edge Transport
Server
Internet Office 365
Exchange Online
Protection
Exchange Online
Agency DNS MX Record
Agency SEEMailGateway
Remote SEEMail Gateway
Internet SMTP
Optional TLS
Optional TLS
Mandatory TLSMandatory TLS
Agency Secured Network
Email Message
SEEMail Message
Email Message Email Message
Email Message
Mandatory TLS
Agency Secured Network
Figure 16 – EOP Email Protection Option
Email traffic between the SEEMail Gateway and, Exchange and Exchange Online is either:
71 MX records can be pointed to EOP to direct inbound flow from EOP to the SEEMail gateway, however
any SEEMail-protected messages cannot be scanned by EOP. SEEMail would then route to Edge Transport
(using a central mail transport architecture) or ‘trombone’ email records back to EOP. Outbound mail
would still need to flow from EOP to the SEEMail gateway, otherwise recipient SEEMail gateways will
detect that email from another SEEMail agency has not originated from that agencies SEEMail Gateway,
and will be marked with a WARNING.
Prepared for Department of Internal Affairs
Page 60
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
a) A TLS connection between the Edge Transport Server and EOP over the internet.
b) A TLS connection between the Edge Transport Server and EOP over ExpressRoute.
Hybrid Hosted SEEMail Gateway Option
Some agencies use hosted SEEMail gateways managed by 3rd parties outside of their own
network.
Mail can be routed to/from either Edge Transport (in a centralised transport architecture) or
to/from EOP through the use of bi-directional connectors. Outbound mail is automatically
routed over TLS to the Provider SEEMail gateway using a Microsoft-supplied certificate. The
SEEMail Gateway will automatically route inbound email to Edge Transport/EOP post-processing
over TLS using an agencies SEEMail certificate.72
The relevant portion of this pattern is shown Figure 17 below:
Optional ExpressRoute Connection
Optional ExpressRoute Connection
Edge Transport
Server
Internet Office 365
Exchange Online
Protection
Exchange Online
Agency DNS MX Record
Remote SEEMail Gateway
SMTP Gateway
SEEMail PKI
Service
Mandatory HTTPS
Mandatory HTTPS
Optional TLS
Optional TLS
Mandatory TLSMandatory TLS
Service Provider Network
Provider SEEMailGateway
Mandatory TLS
Agency Secured Network
Email Message
Email Message
Email Message
SEEMail Message
Email Message
Mandatory TLS
Email Message
Agency Secured Network
Figure 17 - Hybrid Hosted SEEMail Option
With this pattern, email traffic between Edge Transport Servers and EOP may use a TLS
connection over the internet, or TLS over an ExpressRoute connection. Email traffic between the
SEEMail gateway and Exchange Online Protection is either:
a) A TLS connection between EOP and the Service Provider’s SEEMail gateway over the
internet.
72 https://blogs.technet.microsoft.com/eopfieldnotes/2014/06/06/tls-connectors-and-you/
Prepared for Department of Internal Affairs
Page 61
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
b) A TLS connection between EOP and the Service Provider’s SEEMail gateway over
ExpressRoute.
Hybrid Non-Exchange Option
Some public sector agencies in New Zealand use Novell GroupWise, Lotus Domino or other
collaboration platforms to provide email services. Exchange Online supports the use of bi-
directional TLS connectors to route mail between these platforms and Exchange Online,
including those non-Exchange agencies that are SEEMail participants. This allows these agencies
to migrate from their legacy email environments to Exchange Online.
The relevant portion of this pattern is shown in Figure 18 below:
Optional ExpressRoute Connection
Mailbox Server
SMTP Gateway
Internet Office 365
Exchange Online
Protection
Exchange Online
Agency DNS MX Record
Agency SEEMailGateway
Remote SEEMail Gateway
SMTP Gateway
3rd Party AV/AS Service
(optional)
SEEMail PKI
Service
Optional TLS
Mandatory HTTPS
Mandatory HTTPS
Optional TLS
Optional TLS
Optional TLS
Optional TLS
Mandatory TLSMandatory TLS
Agency Secured Network
Email Message
Email Message
Email Message Email MessageEmail Message
Email Message
SEEMail Message
Agency Secured Network
Figure 18 - Hybrid Non-Exchange Option
Email traffic between the SMTP Gateway and Exchange Online Protection is either:
Prepared for Department of Internal Affairs
Page 62
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
a) A TLS connection between the SMTP Gateway and EOP over the internet.
b) A TLS connection between the SMTP Gateway and EOP over ExpressRoute.
4.7 Cloud Architectures
4.7.1 Exchange Online with SEEMail Pattern
While the intent of any cloud migration is to simplify on-premises services and architecture,
most agencies will continue to support on-premises desktops, servers and applications that are
integrated with Active Directory. They will also need to maintain hybrid identity replication from
Active Directory to Azure AD to support Office 365, Azure, CRM and 3rd party cloud applications.
Once an agency has migrated all of their services to the cloud, they can look to retire their on-
premises Active Directory environment.
This dependency means that a small amount of Exchange infrastructure will need to be retained
on-premises, even with the Exchange Online with SEEMail Pattern. This is the only supported
way to manage on-premises Exchange attributes in Exchange Online. The following components
are required:
Client Access Server to support administration Exchange Online mailboxes and
configuration options via the Exchange Admin Centre (EAC) web interface. Two CAS
servers will provide higher levels of availability, should the agency require this level of
service for email administration activity. Loss of the CAS server will not affect user access
to Exchange Online mailboxes. The Exchange Online version of the EAC is used to modify
Exchange Online-specific configuration options not available through the on-premises
EAC.73
Active Directory Domain Services to store user and mailbox configuration information.
Most agencies will have other ICT services that will need to source user and identity
information from AD-DS, so maintaining Exchange Online through AD-DS prevents
identity fragmentation and reduces administrative overhead. It is recommended that AD-
DS be deployed in a highly-available configuration.
Active Directory Federation Services to support Exchange Online user authentication
(for agencies that do not wish to synchronise password hashes to Azure AD). It also
allows the identity and authentication control point to remain within the on-premises
environment, which is attractive for many agencies. ADFS should be deployed in a
73 In Exchange Server 2016, the Mailbox Server role includes the Client Access Server functions, so
agencies on this version of Exchange will need to retain at least one Mailbox server in place of the CAS
component.
Prepared for Department of Internal Affairs
Page 63
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
highly-available configuration, including the ADFS servers themselves and any front-end
proxy servers in an agency DMZ that receive traffic from untrusted networks, like the
Windows Server Web Application Proxy.
Azure AD Connect to synchronise user objects between AD-FS and Azure AD. This
component should be deployed in a highly-available configuration. Although loss of the
Azure AD Connect will not prevent user access to Exchange Online mailboxes, changes in
AD-DS will not be reflected in Azure AD until the service is restored. If replicated user
attributes are modified in Azure AD, they will be overwritten the next time replication
occurs.
An architecture where all mailboxes reside in Exchange Online, while retaining the necessary
management infrastructure on-premises is shown in Figure 19 below:
Optional ExpressRoute Connection
Email Client
Email Client
Client Access Server (CAS)
Internet Office 365
Active Directory Domain Services
Azure AD
Azure AD
Connect
ADFS (optional)
Exchange Online
Protection
Exchange Online
Agency DNS MX Record
Admin Client
Agency SEEMailGateway
Remote SEEMailGateway
SMTP Gateway
SEEMail PKI
Service
Mandatory TLS
Mandatory HTTPS Mandatory HTTPS
Optional TLS
Optional TLS
Mandatory TLS
Mandatory HTTPS
Mandatory HTTPS
Mandatory HTTPS
Optional TLS
Optional TLS
Agency Secured Network
Mandatory HTTPS
Application Component
Optional TLS
SEEMail Message
Email Message
Email Message
Email Message
Email Message
Email Message
Mandatory HTTPS
Mandatory HTTPS
Agency Secured Network
Figure 19 - Exchange Online with SEEMail Pattern
Prepared for Department of Internal Affairs
Page 64
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Cloud-Based Administration Option
Agencies that have moved all mailboxes to Exchange Online may wish to remove their
remaining on-premises Exchange servers. However, it is not simple to move from a hybrid
configuration to the cloud. This option should only be considered if an agency no longer
requires syncronisation to Azure AD. Such a scenario would only occur once an agency has
retired all of their on-premises services that require Active Directory Domain Services. For nearly
all agencies, AD-DS will be required for the foreseeable future to support user objects, line of
business applications, desktops/servers and other resources.74
Once replication to Azure AD has ceased, Exchange Online can be managed using the Exchange
Online EAC or PowerShell.75 This architecture is shown in Figure 26 below:
74 https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150).aspx 75 https://technet.microsoft.com/en-us/library/exchange-online-administration-and-management.aspx
Prepared for Department of Internal Affairs
Page 65
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Optional ExpressRoute Connection
Email Client
Email Client
Internet Office 365
Azure AD
Exchange Online
Protection
Exchange Online
Agency DNS MX Record
Admin Client
Agency SEEMailGateway
Remote SEEMailGateway
SMTP Gateway
SEEMail PKI
Service
Mandatory TLS
Mandatory HTTPS Mandatory HTTPS
Optional TLS
Optional TLS
Mandatory TLSMandatory TLS
Optional TLS
Agency Secured Network
Application
Component
Mandatory TLS
SEEMail Message
Email Message
Email Message
Email Message
Email Message
Email Message
Email Message
Mandatory HTTPS
Mandatory HTTPS
Mandatory HTTPS
Agency Secured Network
Figure 20 - Cloud-Based Administration Option
Email traffic between Exchange Online and SEEMail is either:
a) A TLS connection between the SEEMail Gateway and EOP over the internet.
b) A TLS connection between the SEEMail Gateway and EOP over ExpressRoute. This will
also provide ExpressRoute connectivity between Azure AD Connect and Azure AD.
Exchange Online with Hosted SEEMail Option
Some agencies use hosted SEEMail gateways managed by 3rd parties outside of their own
network. For these agencies, the network location of the SEEMail gateway differs, but the
relationship to other components remains unchanged. The relevant portion of this pattern is
shown Figure 21 below:
Prepared for Department of Internal Affairs
Page 66
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Optional ExpressRoute Connection
Internet Office 365
Exchange Online
Protection
Exchange Online
Agency DNS MX Record
Remote SEEMail Gateway
SMTP Gateway
SEEMail PKI
Service
Mandatory HTTPS
Mandatory HTTPS
Optional TLSOptional TLS
Mandatory TLS
Service Provider Network
Provider SEEMailGateway
Mandatory TLS
Agency Secured Network
Email Message
Email Message
SEEMail Message
Agency Secured Network
Figure 21 - Exchange Online with Hosted SEEMail Option
Email traffic between the Exchange Online and SEEMail is either:
a) A TLS connection between the Service Providers SEEMail Gateway and EOP over the
internet.
b) A TLS connection between the SEEMail Gateway and EOP over ExpressRoute.
Prepared for Department of Internal Affairs
Page 67
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
5 Integration Considerations
For organisations that are looking to implement hybrid or cloud architectures, there are some
integration considerations that will ensure that users and applications dependent on email
services continue to function without incident.
5.1 Outlook Integration
Outlook Anywhere enables Outlook users to access their Exchange Server accounts over the
Internet without using virtual private network (VPN) connections when they travel or when they
work outside the organisation firewall. Autodiscover automatically configures client settings so
that users don't need to know server names or other technical details to configure their mail
profiles.
Hybrid Architecture
By default, Exchange pushes down the Outlook Anywhere settings by using the Autodiscover
service the first time that Outlook is started.76 In a hybrid deployment, the Autodiscover DNS
record needs to be pointed to the on-premises Exchange. Autodiscover record on the agency
public DNS needs to be created. A DNS record for the Exchange Online Protection (EOP) service
also needs to be created to support the connector to the on-premises Edge Transport host.77 78
Cloud Architecture
Unless an agency is completely removing the CAS and other Exchange components from their
organisation, they can continue to manage Outlook integration as per the hybrid model.
Otherwise, simply specifying the user’s email address in the account setup wizard should resolve
to the Exchange Online service correctly.
5.2 Outlook on the Web
Also known as Outlook Web Access, or the Outlook Web App, Outlook on the Web lets users
access their Exchange mailbox from almost any Web browser.
76 https://technet.microsoft.com/en-us/library/cc179036.aspx?f=255&MSPPError=-2147217396 77 https://community.office365.com/en-us/f/156/t/187656 78 Run the analyser tool for more information http://technet.microsoft.com/en-
us/exdeploy2010/default(EXCHG.150).aspx#Index
Prepared for Department of Internal Affairs
Page 68
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Hybrid Architecture
Providing a single, common URL to access Exchange mailboxes using Microsoft Office Outlook
Web App can help to make transitioning to a hybrid deployment easier and less confusing for
users. 79 By enabling the hybrid server to automatically redirect Outlook Web App requests to
the on-premises mailbox server or to provide a link to users for their mailbox in the cloud-based
organization, users only need to remember one URL to access Outlook Web App no matter
where their mailbox is located.
For on-premises Exchange mailbox users, Outlook Web App requests made to the CAS or Edge
Transport server are redirected directly to the on-premises mailbox server. For mailboxes
located in Exchange Online, the hybrid server displays a Web page that provides users with a
link to the Outlook Web App endpoint for the cloud-based organisation.80
Cloud Architecture
Unless an agency is completely removing the CAS and other Exchange components from their
organisation, they should continue to manage Outlook integration as per the hybrid model.
Otherwise, using the www.outlook.com URL will allow access to agency mail over the web.
5.3 ActiveSync
Any of the patterns in this document support SEEMail message protection, regardless of the
client device type used. SEEMail keywords can be used in ActiveSync clients as they do with the
Outlook desktop client.
Hybrid Architecture
Exchange ActiveSync clients will be seamlessly redirected to Office 365 when a user's mailbox is
moved to Exchange Online. To support this, Exchange ActiveSync clients need to support HTTP
451 redirect. When a client is redirected, the profile on the device is updated with the URL of the
Exchange Online service. This means the client will no longer attempt to contact the on-
premises server when trying to find the mailbox.
79 Exchange Online mailbox users by default can access the www.outlook.com URL and sign in with their
agency credentials. 80 https://technet.microsoft.com/en-us/library/gg476092.aspx
Prepared for Department of Internal Affairs
Page 69
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Cloud Architecture
EAS devices may automatically discover the correct mailbox forest based on the user’s email
address if the device supports the EAS Autodiscover command. The user may also configure the
device to access the specific m.outlook.com URL.81
5.4 On-Premises Applications
Many applications need to send email via SMTP. Most agencies will retain a CAS or Edge
Transport server that can act as an SMTP relay for these applications, even when they implement
a cloud architecture.
For agencies without an on-premises SMTP relay, or those who wish to relay through Exchange
Online, there are a number of approaches to the integration of these applications. All these
approaches support the requirement that all outbound agency email must flow via SEEMail,
since Exchange Online automatically routes outbound messages through SEEMail.82
Table 16 - Application Mail
Approach Description Considerations
SMTP Client Submission Send authenticated SMTP email. Each device or
application must be able to authenticate with
Office 365. Each device or application can have
its own sender address, or all devices can use
one address, such as [email protected]
Requires management of one or more no-
human email accounts.
Encryption is supported. Sending application
must support TLS v1.0 or above.
Direct Send Send email direct to Office 365 without
authentication. The application or device in your
organisation’s network uses the Office 365 mail
exchange (MX) endpoint to email recipients in
your organisation.
If your device sends an email to Office 365 that is
for a recipient outside your organisation, the
email will be rejected.
Messages will traverse the internet in clear text
unless ExpressRoute is used.
SMTP relay Similar to direct send except that it can send
mail to external recipients. Due to the added
complexity of configuring a connector, direct
send is recommended over Office 365 SMTP
relay, unless you must send email to external
recipients.
Sending service must have a static IP.
Messages will traverse the internet in clear text
unless ExpressRoute is used.
81http://blogs.technet.com/b/exchange/archive/2012/02/07/cross-site-redirection-exchange-activesync-
clients-in-office-365.aspx 82 https://technet.microsoft.com/en-us/library/dn554323%28v=exchg.150%29.aspx?f=255&MSPPError=-
2147217396#summary
Prepared for Department of Internal Affairs
Page 70
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
5.4.1 Printers and Multifunction Devices
You can use SMTP client submission, direct send, or SMTP relay to allow a multifunction device,
printer, or application to send email using Office 365 and Exchange Online, for example:
You have a scanner, and you want to email scanned documents to yourself or someone
else.
You have a line-of-business (LOB) application that manages appointments, and you want
to email reminders to clients of their appointment time.
If you have mailboxes in Office 365 and an email server that you manage (also called an on-
premises email server), always configure your devices and applications to use your local network
and route email through your own email server. If all of your mailboxes are in Office 365, here
are the options for sending email from an application or device:
Option 1 (recommended): Authenticate your device or application directly with an Office
365 mailbox, and send mail using SMTP client submission
Option 2: Send mail direct from your printer or application to Office 365 (direct send)
Option 3: Configure a connector to send mail using Office 365 SMTP relay
5.4.2 SEEMail Application Whitelisting
The concept of Application “whitelisting” that existed in versions of SEEMail prior to v3.1 will no
longer be supported in SEEMail v3.1 onwards. SEEMail agencies that have also subscribed to
external Software as a Service (SaaS) providers like SurveyMonkey will find email messages from
a SaaS provider that appear to come from an agency email address (e.g [email protected]) will
be delivered to recipients in other SEEMail agencies as an attachment to a WARNING message.
To overcome this, the SaaS provider will need to configure their outbound email to relay via the
sending agencies SEEMail gateway.
5.5 Web Services Integration
5.5.1 Exchange Web Services
Exchange Web Services (EWS) API provides the functionality to enable client applications to
communicate with the Exchange server via the Client Access Server, and is the recommended
interface for developing client applications that use EWS and Autodiscover to communicate with
Prepared for Department of Internal Affairs
Page 71
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Exchange. The EWS Managed API EWS clients can integrate Outlook data into Line-of-Business
(LOB) applications.83
For Exchange 2010, SOAP provides the messaging framework for messages sent between
the client application and the Exchange server. The SOAP messages are sent by HTTP.84
Exchange 2013 and above support RESTful web services.85
5.5.2 Exchange Online Web Services
Exchange Online provides many of the same app-development capabilities that are available for
on-premises Exchange Server. Exchange Online supports the same RESTful web services as
Exchange 2013/2016.
REST APIs provide a powerful, easy-to-use way to access and manipulate Exchange data. These
APIs are based on open standards: OAuth version 2.0 for authentication, and OData version 4.0
and JSON for data abstraction.86
83 https://msdn.microsoft.com/en-us/library/office/dd877012(v=exchg.150).aspx 84 https://msdn.microsoft.com/en-us/library/office/aa579369(v=exchg.140).aspx 85 https://msdn.microsoft.com/en-us/library/office/jj162981.aspx 86 https://msdn.microsoft.com/en-us/library/office/dn776319.aspx?f=255&MSPPError=-2147217396
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
6 Appendix A – Non-SEEMail Patterns
Some agencies do not have a SEEMail implementation. The following patterns describe the email architecture for on-premises, hybrid
and Cloud-based email deployments. These patterns can be used to guide agency migration from Exchange to Exchange Online.
Table 17 - Non-SEEMail Architecture Patterns
Pattern Name Pattern Description Agency Profile Key Benefits Key Considerations
On
-Pre
mis
es
Figure 22 - On-Premises
Exchange Pattern
Traditional Exchange
deployment running in agency
environment.
Needs to realise the benefit of
a recent investment in on-
premises email services.
Needs all email to stay on-
premises for regulatory or
security compliance purposes.
Maintain complete control
over the email service. Internal
mail flow stays within the
agency network.
Must maintain and update the
hardware, software and service
management elements of the
email service.
Hyb
rid
Figure 23 - Hybrid Exchange
Pattern
Agency adopts Exchange
Online, but retains on-
premises Exchange
environment for subset of
users.
Requires the flexibility of on-
premises exchange instances
(e.g branch offices) but wants
to leverage benefits of cloud-
based email services.
Has no restrictions relating to
the use of offshore email
services for at least a subset of
users.
Balance benefits of cloud-
based service with control and
flexibility of on-premises
Exchange.
Can retire on-premises anti-
malware and anti-spam
systems, as this is provided by
Exchange Online Protection.
Must maintain existing on-
premises Exchange
infrastructure, in addition to
the service costs of Exchange
Online.
Network link failure between
Exchange Online and agency
network will cause email
service outage.
Figure 24 - Hybrid Exchange
Centralised Mail Transport
Option
As above, with mail routed
through existing Exchange
infrastructure instead of
Exchange Online.
Can route through EOP for
spam/malware protection.
Needs to support processing
or routing of email above
what is provided by EOP’s
content-based routing and
AV/AS capabilities.
Route inbound/outbound
email through agency mail
services to maintain control
and visibility.
Network link failure between
Exchange Online and agency
network will loss of service for
cloud-based mailbox users.
Prepared for Department of Internal Affairs
Page 73
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Clo
ud
Figure 25 - Exchange Online
Pattern
Agency adopts Exchange
Online and retires existing on-
premises Exchange
infrastructure.
Some Exchange components
are retained (without having
to be a hybrid configuration)
to support centralised
management of users and
mailboxes through AD.
Wants to retire existing email
services and move completely
to the cloud.
Managed email service that
removes the need for nearly
all agency management of
email service and associated
infrastructure.
Network link failure between
Exchange Online and agency
network will cause email
service outage.
Figure 26 - Exchange Online
Cloud-Based Administration
Option
As above, without the need to
retain on-premises Exchange
management components.
Wants to manage email
through Exchange Online EAC,
and potentially retire on-
premises Active Directory.
Removes all on-premises
Exchange infrastructure from
agency network.
Requires remediation activity
to migrate mailbox
administration from Active
Directory to Exchange Online.
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Email Client
Email Client
Client Access Server (CAS)
Mailbox Server
Edge Transport
Server
Agency Secured Network Internet
Active Directory Domain Services
Agency DNS MX Record
Admin Client
SMTP Gateway
3rd Party AV/AS
(optional)
Application Component
Figure 22 - On-Premises Exchange Pattern
Prepared for Department of Internal Affairs
Page 75
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Email Client
Email Client
Client Access Server (CAS)
Mailbox Server
Edge Transport
Server
Agency Secured Network Internet Office 365
Active Directory Domain Services
Azure AD
Azure AD
Connect
ADFS (optional)
Exchange Online
Protection
Exchange Online
Agency DNS MX Record
Admin Client
SMTP Gateway
Application Component
Figure 23 - Hybrid Exchange Pattern
Prepared for Department of Internal Affairs
Page 76
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Edge Transport
Server
Internet Office 365
Exchange Online
Protection
Exchange Online
Agency DNS MX Record
SMTP Gateway
3rd Party AV/AS Service
(optional)
Agency Secured Network
Figure 24 - Hybrid Exchange Centralised Mail Transport Option
Prepared for Department of Internal Affairs
Page 77
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Email Client
Email Client
Client Access Server (CAS)
Internet Office 365
Active Directory Domain Services
Azure AD
Azure AD
Connect
ADFS (optional)
Exchange Online
Protection
Exchange Online
Agency DNS MX Record
Admin Client
SMTP Gateway
Application Component
Agency Secured Network
Figure 25 - Exchange Online Pattern
Prepared for Department of Internal Affairs
Page 78
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Email Client
Email Client
Internet Office 365
Exchange Online
Protection
Exchange Online
Agency DNS MX Record
Admin Client
SMTP Gateway
Azure AD
Agency Secured Network
Figure 26 - Exchange Online Cloud-Based Administration Option
Prepared for Department of Internal Affairs
Page 79
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
7 Appendix B – Azure AD Connect
Azure AD Connect is the directory syncronisation tool used to integrate agency on-premises
Active Directory Domain Services (AD-DS) with Azure Active Directory. Azure AD Connect
replaces older versions of identity integration tools such as DirSync and Azure AD Sync. Azure
AD Connect incorporates the components and functionality previously released as Dirsync and
AAD Sync. These tools are no longer being released individually, and all future improvements
will be included in updates to Azure AD Connect.87
Once Azure AD Connect has been deployed, agencies can continue to manage users through
AD-DS. Changes in AD-DS will automatically be synchronised to Azure AD. A user object that
has been synchronised with Azure AD, it allows single sign-on (SSO) access to subscribed
Microsoft Cloud services like Office 365 (including Exchange Online), Azure and CRM Online.
Users can also use SSO to access any 3rd party cloud applications that the agency has subscribed
to.88
7.1 Planning Syncronisation
There are a number of considerations for agencies that are deploying Azure AD Connect, some
of the more important ones being:
Filtering is used when you want to limit which objects are synchronised to Azure AD. By
default all users, contacts, groups, and Windows 10 computers are synchronised, but you
can limit this based on domains, OUs, or attributes.89
Password synchronisation will synchronise the password hash in Active Directory to
Azure AD. This allows the user to use the same password on-premises and in the cloud
but only manage it in one location. Since it will use your on-premises Active Directory it
will also allow you to use your own password policy.90
87 https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-get-started-
tools-comparison/ 88 https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect/ 89 https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-configure-
filtering/ 90 https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-
implement-password-synchronization/
Prepared for Department of Internal Affairs
Page 80
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
Federation between ADFS and Azure AD for agencies that do not wish to synchronise
password hashes to Azure AD. Federation will allow user SSO to cloud applications.91
7.2 Prerequisites for Deployment
There are a number of prerequisites that must be met in order to successfully deploy Azure AD
Connect. Agencies should review installation material carefully, and be aware of the following
high-level requirements92:
The ability of the agency Active Directory environment to support Office 365 integration
should be verified by running the IDFix tool.93 IdFix identifies errors such as duplicates
and formatting problems in your directory before you synchronise to Office 365. The
computer where you install IdFix needs to be joined to the same Active Directory domain
from which you want to synchronise users to Office 365. The computer also needs to
have .NET Framework 4.0 installed. IDFix is free tool available for download from
Microsoft.94
The AD schema version and forest functional level should be Windows Server 2008 or
later. The domain controllers can run any version as long as the schema and forest level
requirements are met. If you plan to use the password write-back feature, the Domain
Controllers must be on Windows Server 2008 (with latest SP) or later.
Azure AD Connect must be installed on Windows Server 2008 or later. This server may
be a domain controller or a member server if using express settings. If you use custom
settings, the server can also be stand-alone and does not have to be joined to a domain.
If you plan to use the password synchronisation feature, the Azure AD Connect server
must be on Windows Server 2008 R2 SP1 or later.
The Azure AD Connect server must have .NET Framework 4.5.1 or later and Microsoft
PowerShell 3.0 or later installed.
If Active Directory Federation Services is being deployed, the servers where AD FS or
Web Application Proxy will be installed must be Windows Server 2012 R2 or later.
Windows remote management must be enabled on these servers for remote installation.
Azure AD Connect requires a SQL Server database to store identity data. The default SQL
Server 2012 Express LocalDB has a 10GB size limit that enables you to manage
91 https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-user-signin/ 92 https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-prerequisites/ 93 https://support.office.com/en-us/article/Install-and-run-the-Office-365-IdFix-tool-f4bd2439-3e41-
4169-99f6-3fabdfa326ac?ui=en-US&rs=en-US&ad=US 94 https://www.microsoft.com/en-au/download/details.aspx?id=36832
Prepared for Department of Internal Affairs
Page 81
Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final
Prepared by Greg Hunt
"DIA-GCIO Office 365 Whitepaper - SEEMail Integration Reference Architecture", Template Version 4
approximately 100,000 objects. If you need to manage a higher volume of directory
objects, you need to point the installation wizard to a different installation of SQL Server.