microsoft office 365 whitepaper · office 365. it demonstrates to agencies how they can take a...

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

[email protected]

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


iii

Microsoft Office 365 Whitepaper, SEEMail Integration Reference Architecture, Version 7, Final



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


iv




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


v




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


vi




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


vii




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





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

Email

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





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

Email

SEEMail

Office 365

Exchange Online

Internal Sender/Recipient

Email

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

Email

SEEMail

Office 365

Exchange Online

Internal Sender/Recipient

Email

External Sender/RecipientEmail

Figure 3 - Cloud Architecture





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.

http://www.ict.govt.nz/





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.





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.

http://www.ict.govt.nz/





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





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/





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.





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/





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






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


Management


and Operations

A5.02.03 Identity Provisioning Azure AD Connect

Azure AD


Management


and Operations

A5.02.03 Identity Updates Azure AD Connect


Management

A5.03 Authentication

Services7

A5.03.021 Authentication

Brokerage

Active Directory Domain

Services

ADFS

Azure AD


Management

A5.03 Authentication Services A5.03.07 Web Services

Security

Azure AD

ADFS


Management

A5.04 Authorisation and

Access Management Services

A5.04.01 Enterprise SSO ADFS


Management



A5.04.02 Federation Services Azure AD

ADFS


Management



A5.04.03 Access Control Active Directory Domain

Services


Management



A5.04.04 Web Access

Management

Azure AD


Management



A5.04.05 Web SSO Azure AD

ADFS


Management

A5.05 Directory Service n/a Active Directory Domain

Services

Azure AD


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.







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


Services8

A6 Security Services A6.03 Public Key

Infrastructure (PKI) Service

A6.03.02 Digital Signature

Management

SEEMail


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


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.






Azure AD


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





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





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


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






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


Exchange Online Supports SHA 384

Supports AES-256


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





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





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





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





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





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





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





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.





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


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





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.





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





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



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/





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





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





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





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





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





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/





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.





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.





On-Premises Hybrid Cloud

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





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.




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


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





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.


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


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 causes loss of email

service.


SEEMail:

Hybrid Hosted SEEMail Gateway

Option



provider.



SEEMail service is managed by

3rd party on behalf of the

agency, reducing administrative

burden and infrastructure

requirements.


hosted SEEMail and agency


outage.


between agency network and

3rd party provider.






SEEMail:

Hybrid Non-Exchange Option


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.




Must maintain some on-

premises email infrastructure, in

addition to the service costs of

Exchange Online.




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.


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.







outage.


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


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



provider.



SEEMail service is managed by

3rd party on behalf of the

agency, reducing administrative




outage.





burden and infrastructure

requirements.


Exchange Online and SEEMail

will cause email service outage.


between Exchange Online and

3rd party provider.




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






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.






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.




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.




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/





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.





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:





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


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:





IPSEC VPN, TaaS or Managed WAN

Service Provider Network


Provider SEEMailGateway


SMTP Gateway

Optional TLS

Optional TLS

Internet


(optional)

Mandatory TLS

Edge Transport

Server

Optional TLS


SEEMail Message

Email Message

Email Message

Email Message


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.





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)





Optional ExpressRoute Connection

Email Client

Email Client


Mailbox Server

Edge Transport

Server

Internet Office 365


Azure AD

Azure AD

Connect

ADFS (optional)

Exchange Online

Protection

Exchange Online


Admin Client

Agency SEEMailGateway


Internet SMTP


(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


Optional TLS


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


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.





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:


Edge Transport

Server

Internet Office 365

Exchange Online

Protection

Exchange Online




Internet SMTP

Optional TLS

Optional TLS



Email Message

SEEMail Message

Email Message Email Message

Email Message

Mandatory TLS


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.





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


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:



Edge Transport

Server

Internet Office 365

Exchange Online

Protection

Exchange Online



SMTP Gateway

SEEMail PKI

Service

Mandatory HTTPS

Mandatory HTTPS

Optional TLS

Optional TLS




Mandatory TLS


Email Message

Email Message

Email Message

SEEMail Message

Email Message

Mandatory TLS

Email Message


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/





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:


Mailbox Server

SMTP Gateway

Internet Office 365

Exchange Online

Protection

Exchange Online




SMTP Gateway


(optional)

SEEMail PKI

Service

Optional TLS

Mandatory HTTPS

Mandatory HTTPS

Optional TLS

Optional TLS

Optional TLS

Optional TLS



Email Message

Email Message

Email Message Email MessageEmail Message

Email Message

SEEMail Message


Figure 18 - Hybrid Non-Exchange Option

Email traffic between the SMTP Gateway and Exchange Online Protection is either:





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.





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:


Email Client

Email Client


Internet Office 365


Azure AD

Azure AD

Connect

ADFS (optional)

Exchange Online

Protection

Exchange Online


Admin Client


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


Mandatory HTTPS


Optional TLS

SEEMail Message

Email Message

Email Message

Email Message

Email Message

Email Message

Mandatory HTTPS

Mandatory HTTPS


Figure 19 - Exchange Online with SEEMail Pattern





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






Email Client

Email Client

Internet Office 365

Azure AD

Exchange Online

Protection

Exchange Online


Admin Client


Remote SEEMailGateway

SMTP Gateway

SEEMail PKI

Service

Mandatory TLS

Mandatory HTTPS Mandatory HTTPS

Optional TLS

Optional TLS


Optional TLS


Application

Component

Mandatory TLS

SEEMail Message

Email Message

Email Message

Email Message

Email Message

Email Message

Email Message

Mandatory HTTPS

Mandatory HTTPS

Mandatory HTTPS


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


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:






Internet Office 365

Exchange Online

Protection

Exchange Online



SMTP Gateway

SEEMail PKI

Service

Mandatory HTTPS

Mandatory HTTPS

Optional TLSOptional TLS

Mandatory TLS



Mandatory TLS


Email Message

Email Message

SEEMail Message


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.





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





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

http://www.outlook.com/

http://www.outlook.com/





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





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

mailto:[email protected]





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




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


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 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 will loss of service for

cloud-based mailbox users.





Clo

ud

Figure 25 - Exchange Online

Pattern


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 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.




Email Client

Email Client


Mailbox Server

Edge Transport

Server

Agency Secured Network Internet



Admin Client

SMTP Gateway

3rd Party AV/AS

(optional)


Figure 22 - On-Premises Exchange Pattern





Email Client

Email Client


Mailbox Server

Edge Transport

Server

Agency Secured Network Internet Office 365


Azure AD

Azure AD

Connect

ADFS (optional)

Exchange Online

Protection

Exchange Online


Admin Client

SMTP Gateway


Figure 23 - Hybrid Exchange Pattern





Edge Transport

Server

Internet Office 365

Exchange Online

Protection

Exchange Online


SMTP Gateway


(optional)


Figure 24 - Hybrid Exchange Centralised Mail Transport Option





Email Client

Email Client


Internet Office 365


Azure AD

Azure AD

Connect

ADFS (optional)

Exchange Online

Protection

Exchange Online


Admin Client

SMTP Gateway



Figure 25 - Exchange Online Pattern





Email Client

Email Client

Internet Office 365

Exchange Online

Protection

Exchange Online


Admin Client

SMTP Gateway

Azure AD


Figure 26 - Exchange Online Cloud-Based Administration Option





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/





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





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.