Active Directory from onpremises to the cloud

piegazeInternet και Εφαρμογές Web

7 Δεκ 2013 (πριν από 3 χρόνια και 11 μήνες)

587 εμφανίσεις




Active Directory from on
-
premises to
the
c
loud

Microsoft France

Publi
shed
:
January

201
3

Version
:

1.0

Author
:
Philippe Beraud (Microsoft
France)

Contributor
s/Reviewers
:

Arnaud
Jumelet (Microsoft France),
Christophe Leroux (Microsoft
Corporation),
Philippe Maurent (Microsoft Corp
oration
)


Copyright

© 201
3

Microsoft Corporation
.
All right
s

reserved.

Abstract

Identity management, provisioning, role management, and authentication are key services both
on
-
premises and through the (hybrid) cloud. With the Bring Your Own Apps (BYOA) for the cloud
and Software as a Service (SaaS) applications, the desire to better c
ollaborate a la Facebook
with the “social” enterprise, the need to support and integrate with social networks, which lead to
a Bring Your Own Identity (BYOI) trend, identity becomes a service where identity “bridges” in the
cloud talk to on
-
premises direct
ories or the directories themselves move and/or are located in the
cloud.

Active Directory
(AD)
is a Microsoft brand for identity related capabilities. In the on
-
premises
world,
Windows Server
AD
provides a set of identity capabilities and services and is

hugely
popular (88% of Fortune 1000
and 95% of enterprises
use AD)
.
Windows Azure
AD

is AD
reimagined for the cloud, designed to solve for you the new identity and access challenges that
come with the shift to a cloud
-
centric,
multi
-
tenant

world
.

Windows Azure AD can be truly seen as an
Identity

Management

as

a

Service (IDMaaS)
cloud
multi
-
tenant

service
. T
his goes far beyond taking AD and simply running it within a
VM

in
Windows Azure
.

T
his document
is intended for
IT professionals,
system archite
cts
, and developers
who are
interested in understanding

the various options for managing and using identities in their (hybrid)
cloud environment based on the AD foundation and how to leverage the related capabilities
.

AD
,
AD in Windows Azure

and Windows A
zure AD are
indeed
useful fo
r slightly different scenarios.



This document is provided “as
-
is”. Information and views expressed in this document, including URL and
other
Internet Web site references, may change without notice. You bear the risk of using it.

Some examples depicted herein are provided for illustration only and are fictitious. No real association or
connection is intended or should be inferred.

This document
does not provide you with any legal rights to any intellectual property in any Microsoft
product. You may copy and use this document for your internal, reference purposes. You may modify
this document for your internal, reference purposes.

© 201
3

Microsoft

Corporation. All rights reserved.

Microsoft, Active Directory, Internet Explorer, SQL Server, Windows, Windows PowerShell, and
Windows Server are trademarks of the Microsoft group of companies.
All other trademarks are property
of their respective owners





Active Directory from on
-
premises to the cloud


ii

Content



INTRODUCTION

................................
................................
................................
.............................

1

1
1.1

O
BJECTIVES OF THIS PA
PER

................................
................................
................................
....

2

1.2

N
ON
-
OBJECTIVES OF THIS P
APER

................................
................................
............................

4

1.3

O
RGANIZATION OF THIS
PAPER

................................
................................
................................

4

1.4

A
BOUT THE AUDIENCE

................................
................................
................................
.............

5


AD IN WINDOWS AZURE
IS NOT WINDOWS AZURE

AD!

................................
.........................

6

2

WHAT IS WINDOWS AZUR
E AD?

................................
................................
................................

9

3
3.
1

T
YPE OF IDENTITIES

................................
................................
................................
..............

13

3.2

A
NATOMY OF
W
INDOWS
A
ZURE
AD

................................
................................
.......................

15


SYNCHRONIZE YOUR WIN
DOWS AZURE AD DIRECT
ORY TENANT WITH YOUR

ON
-
4
PREMISES DIRECTORY

................................
................................
................................
.......................

31

4.1

S
YNCHRONIZE YOUR DIRE
CTORY TENANT WITH
A
CTIVE
D
IRECTORY ON
-
PREMISES

...................

32

4.2

S
YNCHRONIZE YOUR DIRE
CTORY TENANT WITH NO
N
-
AD

DIRECTORIES ON
-
PREMISES

...............

39


FEDERATE YOUR WINDOW
S AZURE AD DIRECTORY

TENANT WITH YOUR ON
-
PREMISES
5
DIRECTORY

................................
................................
................................
................................
..........

42

5.1

F
EDERATE YOUR DIRECTO
RY TENANT WITH AN ON
-
PREMISES
WS
-
*

BASED
I
DENTITY
P
ROVIDER
45

5.2

F
EDERATE

YOUR DIRECTORY TENAN
T WITH AN ON
-
PREMISES
SAML

2.0

BASED
I
DENTITY
P
ROVIDER

................................
................................
................................
................................
.......

46


ENABLE SINGLE SIGN
-
ON AND WINDOWS AZURE

AD
DIRECTORY SERVICES F
OR
6
CLOUD APPLICATIONS

................................
................................
................................
.......................

48

6.1

L
EVERAGE YOUR
W
INDOWS
A
ZURE
AD

DIRECTORY TENANT WIT
H YOUR
S
AA
S

SUBSCRIPTION

.

48

6.2

L
EVERAGE YOUR
W
INDOWS
A
ZURE
AD

DIRECTORY TENANT WIT
H YOUR
LOB

APPLICATION IN THE
C
LOUD

51

6.3

L
EVERAGE YOUR CUSTOME
R

S
W
INDOWS
A
ZURE
AD

DIRECTORY TENANT WIT
H YOUR
S
AA
S

APPLICATION IN THE
C
LOUD

................................
................................
................................
..............

62


BRING YOUR OWN IDENT
ITY (BYOI) WITH WIND
OWS AZURE AD ACCESS
CONTROL

....

70

7

ENSURE INFORMATION P
ROTECTION AND CONTRO
L (IPC) WITH WINDOWS

AZURE AD
8
RIGHTS MANAGEMENT

................................
................................
................................
.......................

75


Active Directory from on
-
premises to the cloud


1


Introduction


1
The cloud is changing the way in which applications are written. Accelerated market cycles, multi
-
tenancy, pure
cloud solutions and hybrid deployments, Web programmability
,

and the rise of devices
(smartphones, tablets, etc.)
as well as

rich clients as consumption models offer
without any doubt
new
opportunities
.

They also

present
at the same time
new cha
llenges for

the

key services both on
-
premises and through
the (hybrid) cloud

that represent the identity management
,
the
provisioning,
the
role management, and
the
authentication
.

With
:




T
he Bring Your Own Apps (BYOA
) for c
loud and Software as a
Service (SaaS) app
lication
s,



T
he desire to better collaborate a

la Facebook
with the “social” enterprise,



The need to support and integrate with

social networks, which lead
to a Bring Your Own
Identity (BYOI
) trend,



Etc.

Identity becomes a service where identity “bridges” in the
c
loud

talk


to on
-
premise directories or the
directories themselves move and/or are located in the cloud

(see

Gartner report

2013

P
LANNING
G
UIDE
:

I
DENTITY AND
P
RIVACY
1
)
.

Identity, like compute and storage and networking, is an essential platform service. In the same way
that identity played a critical role in the adoption of workgroup computing, identity services will play a
critical role as organ
izations adopt the cloud. Organizations will use cloud services and applications
created by ISVs, Platform as a Service (PaaS) cloud platforms for (Line of Business (LOB)) custom
development,
(
as well as Infrastructure as a Service (IaaS) cloud environmen
t for specific workloads to
onboard the cloud for IT optimization reasons
)
.

Kim Cameron, Microsoft Chief Identity Architect, is convinced
2

that “
o
rganizations will find they need
new identity management capabilities to take full advantage of the cloud.
They will also find that the
most reliable and cost
-
effect way to obtain these capabilities is through Identity Management as a
Service


i.e. using

the cloud to master the cloud.

We can therefore predict with certainty that almost all organizations will s
ubscribe to identity services
that are cheaper, broader in scope and more capable than the sy
stems of today.

Enterprises will use these services to manage authentication and authorization of internal employees,
the supply chain, and customers (including in
dividuals), leads and prospects. Governments will use
them when interacting with other government agen
cies, enterprises and citizens.

Identity Management
as a

Service will require that we move beyond the models of identity
management that have guided our t
hinking to date. A new service
-
based model will emerge combining
more advanced capabilities with externalization of operations to achieve reduction in risk, effort and
cost.






1

2013

P
LANNING
G
UIDE
:

I
DENTITY AND

P
RIVACY
:
http://www.gartner.com/id=2221415

2

I
DENTITY
M
ANAGEMENT AS A
S
ERVICE
:
http://www.identityblog.com/?p=1205


2

Active Directory from on
-
premises to the cloud

1.1

O
bjectives of this
paper

Active Directory
(AD)
is a Microsoft brand for identity
related capabilities. In the on
-
premises world,
Windows Server Active Directory
(Windows Server AD or simply AD)
provides a set of identity
capabilities and services and is hugely popular (88% of Fortune 1000
and 95% of enterprises
use AD)
.

With
the Infra
structure as
a

Service
(IaaS) capability
in the cloud, such as the one offered by

the
Windows Azure platform,

it becomes possible to deploy virtual machines
(VM)
that host AD domain
controller.

Whilst such an approach could
be
more than appropriate for spe
cific workloads on IaaS platforms like
a SharePoint environment, the Microsoft vision for the cloud consists in

recreat
ing

a similar identity
service,
but
one that is optimized to support
c
loud app
lication
s and support modern protocols.


Windows Azure
Active Directory (Windows Azure AD or AAD) is AD reimagined for the cloud

(
see blog
posts
R
EIMAGING
A
CTIVE
D
IRECTORY
FOR THE
S
OCIAL
E
NTERPRISE
(P
ART
1)
3
,
(P
ART
2)
4
)
, designed to
solve for you the new identity and access challenges tha
t come with the shift to a cloud
-
centric,
multi
-
tenant

world
.

Windows Azure AD can be
truly
seen as
an
Identity

Management

as

a

Service (IDMaaS)
cloud
multi
-
tenant

service

that provides a robust and comprehensive cloud identity platform

architected to ope
rate
in the cloud with high scale, high availability, and integrated disaster recovery
. T
his goes far beyond
taking AD and simply running it within a
VM

in a hosted environment

such as the I
aaS capability of
Windows Azure:

Windows Azure AD is
definitely
different than running AD in a Windows Azure VM.

Being
optimized to support cloud services and supports modern protocols

such as REST and OAuth2

for mobile and consumer scenarios
,

Windows Azure AD typically
provides ident
ity and access
capabilities for:



Cl
oud
-
based
applications on Windows Azure
or in other clouds such Amazon Web Services
(AWS),



SaaS applications or
multi
-
tenant

applications such as the
Microsoft Office 365
5
, which relies
on it for its identity

infrastructure,



Mobile applications (with or without a back
-
end in the cloud

like the one proposed through the
Windows Azure Mobile Services
6
),



Etc.

Windows Azure
AD

utilizes the enterprise
-
grade
quality and proven capabilities of
Windows Server AD

on
-
premises
, so you can bring your applications to the cloud easily.
It

offers capabilities that can be
leveraged to centralize the identity management needs of your solut
ions, whether they are
cloud
-
based,
hybrid
, or even on
-
premises
. Windows Azure
AD

is a complete offering that can help you to
take advantage of your on
-
premises existing investment, to fully outsource to the cloud your user’s
management and anything in bet
ween.

By connecting your existing on
-
premises identity infrastructure to Windows Azure AD, you can manage
a hybrid environment that provides unified authentication and access management for both cloud and
on
-
premises services and servers, eliminating the
need to maintain new, independent cloud directories





3

R
EIMAGING
A
CTIVE
D
IRECTORY FOR THE
S
OCIAL
E
NTERPRISE
(P
ART
1)
:
http://blogs.msdn.com/b/windowsazure/archive/2012/05/23/reimagining
-
active
-
directory
-
for
-
the
-
social
-
enterprise
-
part
-
1.aspx

4

R
EIMAGING
A
CTIVE
D
IRECTORY FOR THE
S
OCIAL
E
NTERPRISE
(P
ART
2)
:
http://blogs.msdn.com/b/windowsazure/archive/2012/06/20/reimagining
-
active
-
directory
-
for
-
the
-
social
-
enterprise
-
part
-
2.aspx

5

Microsoft Office 365 provides
secure anywhere access to

professional email, shared calendars,
instant messaging (
IM
), video
conferencing,

and document collaboration
, see
http://office365.microsoft.com/

6

Windows Azure Mobile Services:
http://www.windowsazu
re.com/en
-
us/home/features/mobile
-
services/


Active Directory from on
-
premises to the cloud


3

and thus avoiding to recreate in the cloud identity silos for the applications with all the burden and
hassle that comes with them in terms of operations
.

By leveraging
the Windows Azure AD
c
ore
d
irectory

and
a
uthentication
capabilities

and
beyond
handling a
uthentication requests (e.g. to
(cloud) services and applications

user logins)

that

are sent
from the user and
/or devices to Windows Azure AD,
you can enable:



Single
sign
-
on (SSO) across all your cloud
applications

as well as with your SaaS
subscriptions (provided that they support the integration with Windows Azure AD as it is the
case today for the Microsoft Online Services such as Office 365)
.
SSO is the ability for a user
to login in once and not hav
e to re
-
enter their credentials each time when accessing different
(cloud) or applications.

It

represents

an important part of Windows Azure AD because it delivers a secure, yet simple
and seamless way for the corporate users to connect to their resources

running somewhere in
the cloud
7
.



Simple interoperability with your existing on
-
premises identity infrastructure based on
Windows
Server Active Directory (AD) (or non
-
AD sources)

through federation (and synchronization).

Federation is the ability for
Windows
Azure
AD

and your existing on
-
premise
s

identity
infrastructure to work together

delivering a
federated SSO

experience for
corporate
users while
keeping user passwords on
-
premise
s and related policies on
-
premises
.
(

Federation also gives
the option t
o require multifactor authentication for increased security.)

V
ia
the use of
open standard
s

such as the
OASIS WS
-
Federation
, WS
-
Trust,

and
SAML
2.0
protocol
s, y
ou can
indeed
quickly extend your existing on
-
premises
directory

authentication to
your cloud

applications through
Windows Azure AD
. By using your existing
on
-
premises

identity infrastructure

as the authoritative identity provider, users are
seamlessly
authenticated
to your cloud applications with their existing
corporate
accounts.

At the end,
if you are an organization,
Windows Azure AD
provides
your corporate
users
with
a
seamless,
(federated) SSO

experience across
all
your cloud applications, while simplifying
the
adoption of SaaS subscriptions, as well as
the development of your
own
cloud ap
plications.

Conversely, i
f you are an ISV, you can leverage Windows Azure
AD

to reach a vast user population,
which includes the ever
-
growing user base of the Office 365.


As of today,
since its introduction,
Windows Azure AD

has “
now processed 200 B
illion

authentications
for 50 M
illion

active user accounts. In an average week we receive 4.7 B
illion
authentication requests
for users in over 420 T
housand

different domains.

8

Beyond the support of AD in Windows Azure, t
his paper provides you with

a

tour


of
Windows
A
zure
A
D to learn about its capabilities, interfaces
,

and
to
understand how it works in concert with Windows
Server Active Directory (AD) (or non
-
AD sources).

It discusses

the possible options to perform federated provisioning and synchronization
of identity
information from Active Directory
sources
and non
-
AD
directories
sources to
Windows Azure
AD for
the cloud and SaaS applications. This
document

also introduces the new
Windows Azure

Directory
Graph, a REST
-
based API that enables access to
your Windows Azure
AD

directory tenant
.

It
further presents

the SSO
and the Federation capabilities

for your cloud
(
multi
-
tenant
)
applications

and SaaS subscriptions
.





7

The best user experience for corporate users on the corporate network is provided with domain
-
joined machines.

8

W
INDOWS
A
ZURE
A
CTIVE
D
IRECTORY
P
ROCESSES
200

B
ILLION
A
UTHENTICATIONS
-

C
ONNECTING
P
EOPLE
,

D
ATA AN
D
D
EVICES
A
ROUND
T
HE
G
LOBE
:
http://blogs.msdn.com/b/windowsazure/archive/2012/11/27/windows
-
azure
-
active
-
directory
-
processes
-
200
-
billion
-
authentications
-
connecting
-
people
-
data
-
and
-
devices
-
around
-
the
-
globe.aspx


4

Active Directory from on
-
premises to the cloud

Furthermore, w
ith
Windows Azure AD Access Control

(formerly Windows Azure Access Control

Services or ACS), a
unified federat
ed SSO

experience in the
c
loud

can
now
be planned
.

With the
ongoing dissolution of the boundary between “internal” or at least organizational identities and external
or social identities, it

indeed

has out
-
of
-
the
-
box sup
port for popular web identity providers including
Microsoft Account (formerly known as Windows Live ID), Google, Yahoo!, and Facebook and any
Open ID identity providers.
The interaction between your Windows Azure AD directory tenant and your
namespaces in
Windows Azure AD Access Control is also covered as part of this paper.


Finally, a new capability for Information Protection and Control

(IPC)

is also introduced:
Windows
Azure AD Rights Management
.

This
paper can be seen

a starting point for anyone ch
allenged with identity, provisioning, federation
or
cloud based authentication.

Special thanks to

Alex Simons,
Edward Wu
,

John Shewchuk
,

Kim Cameron,
Stuart Kwan,
Vittorio
Bertocci
, and Yannick Kristofic

for p
roviding valuable content on the
s
e

topics
.

1.2

Non
-
objectives of this paper

This document
doesn’t discuss the deployment and configuration of

Windows Server AD on
-
premises.

This document is intended as an overview document for AD in Windows Azure and Windows Azure
AD
, and as such, it doesn’t provides n
either
in
-
depth

description nor
detailed
step
-
by
-
step instructions
on how to implement a specific covered feature

or capability
. Where necessary, it
instead
refers to
more detailed documents, articles, and blog posts that describe a specific
feature

or
cap
ability
.

Furthermore, this document is part

of a document series on the identity and security features of
Windows Azure AD and Microsoft Office 365. It indeed completes the following whitepapers already
available on the Microsoft Download Center:



M
ICROSOFT
O
FFICE
365

S
INGLE
S
IGN
-
O
N
(SSO)

WITH
AD

FS

2.0
9
;



M
ICROSOFT
O
FFICE
365

S
INGLE
S
IGN
-
ON
(SSO)

WITH
S
HIBBOLETH
2.0
10
;



I
NFORMATION
P
ROTECTION AND
C
ONTROL
(IPC)

IN
O
FFICE
365

P
REVIEW WITH
W
INDOWS
A
ZURE
AD

R
IGHTS
M
ANAGEMENT
11
;



I
NFORMATION
P
ROTECTION AND
C
ONTROL
(IPC)

IN
M
ICROSOFT
E
XCHANGE
O
NLINE WITH
AD

RMS
12
.

1.3

Organization of this
paper

To cover
the aforementioned objectives
,
this document
is organized by themes which are covered in
the following sectio
ns
:



AD

IN
W
INDOWS
A
ZURE IS
NOT

W
INDOWS
A
ZURE
AD!
;



W
HAT IS
W
INDOWS
A
ZURE
AD?
;





9

M
ICROSOFT
O
FFICE
365

S
INGLE
S
IGN
-
O
N
(SSO)

WI
TH
AD

FS

2.0
:
http://www.microsoft.com/en
-
us/download/details.aspx?id=28971

10

M
ICROSOFT
O
FFICE
365

S
INGLE
S
IGN
-
ON
(SSO)

WITH
S
HIBBOLETH
2.0
: http://www.microsoft.com/en
-
us/download/details.aspx?id=35464

11

I
NFORMATION
P
ROTECTION AND
C
ONTROL
(IPC)

IN
O
FFICE
365

P
REVIEW WITH
W
INDOWS
A
ZURE
AD

R
IGHTS
M
ANAGEMENT
:
http://www.microsoft.com/en
-
us/download/details.aspx?id=34768

12

I
NFORMATION
P
ROTECTION AND
C
ONTROL
(IPC)

IN
M
ICROSOFT
E
XCHANGE
O
NLINE WITH
AD

RMS
:
http://www.microsoft.com/en
-
us/download/details.aspx?id=
30139


Active Directory from on
-
premises to the cloud


5



S
YNCHRONIZE YOUR
W
INDOWS
A
ZURE
AD

DIRECTORY TENANT WIT
H YOUR ON
-
PREMISES DIRECTORY
;



F
EDERATE YOUR
W
INDOWS
A
ZURE
AD

DIRECTORY TENANT WIT
H YOUR ON
-
PREMISES DIRECTORY
;



E
NABLE
S
INGLE
S
IGN
-
O
N

AND
W
INDOWS
A
ZURE
AD

D
IRECTORY
S
ERVICES FOR
C
LOUD
APPLICATIONS
;



B
RING
Y
OUR
O
WN
I
DENTITY
(BYOI)

WITH
W
INDOWS
A
ZURE
AD

A
CCESS
C
ONTROL
;



E
NSURE
I
NFORMATION
P
ROTECTION AND
C
ONTROL
(IPC)

WITH
W
INDOWS
A
ZURE
AD

R
IGHTS
M
ANAGEMENT
.

1.4

About the audience

This document is intended for
IT professionals,
system architects
, and developers
who are interested
in understanding

the various options for
managing and using identities

in their (hybrid) cloud
environment based on the AD foundation and how to leverage the related capabilities
.

AD
, AD in Windows Azure

and Windows Azure AD are
indeed
useful for slightly different scenarios.
We recommend using Windows Azure AD in addition t
o on
-
premises AD

(and AD in Windows Azure)

in most cases as one doesn’t replace the other.


6

Active Directory from on
-
premises to the cloud


AD in Windows Azure is NOT Windows Azure AD!

2
Microsoft
announced
13

in June 2012 the
release of
Windows Azure Virtual Machines
14
, an IaaS offering
in
the
Windows Azure

platform in the cloud
.
Such an
offering helps moving (part of)

your
business,
applications and infrastructure to the cloud without changing existing code
in their own unique way, at
their own unique speed.

As its name clearly indicates,
Windows Azure Virtual Machines

provides support fo
r virtual machines
(VM).

At a
glance,
a
VM
consist
s

of
a piece of
infrastructure to deploy an application. Specifically, this
includes a persistent
operating system (
OS
)

disk, possibly some persistent da
ta disks, and
internal/external
networking

glue

/con
nectivity

to hold it all together.
W
ith these infrastructure
ingredients,
it

enable
s

to c
reate a platform where customers and partners can deploy existing
applications to take advantage of the reduced cost and ease of deployment offered in

Windows Azure.

VM
s
indeed

give you application mobility, allowing you to move your virtual hard disks (VHDs) back
and forth between on
-
premises and the cloud.



This enables you
to
migrat
e
your
existing
VM
,
to
bring
your own customized Windows Server

or Linux images, etc
.


As a common virtualization file format,
VHD has been adopted by hundreds of vendors and is a
freely available specification
15

covered under
the
Microsoft Open Specification Promise (OSP)
16
.

The new version
VHDX
17

is also available as a free
specification covered under the OSP.

While

migration


is a simple goal for
an
y

IaaS offering,
the ultimate objective consists in being
able to run the exact same on
-
premises

applications and infrastructure or part of them

in the
cloud

and thus enabling onboarding and offboarding of workloads in order to improve the
agility of the organization, i.e. its ability
to capitalize on new opportunities and respond to
changes in business demands.

Such a

process might involve transferring an entire multi
-
VM workload
, which may require

v
irtual
n
etworks for hybrid connectivity to an on
-
premises deployment.

(This can be seen as a cross
-
premises
deployment.)
This is where Windows Azure Virtual Networks comes
into play.

Windows Azure Virtual Network
, another capability of the
Windows Azure

IaaS offering,

lets you
provision and manage virtual networks (
VNET
) in Windows Azure
.
A
VNET is the ability for the
administrator to create a logical boundary and place into it
VMs
. VNET also provides the capability of
connecting
Windows Azure Cloud Services
18

(we
b roles and worker roles)

that are in the same affinity
group directly with
them
.

N
ote:

An affinity group is a container where you choo
se the location (Windows Azure r
egion) and where you
placed your Windows Azure resources. An affinity group represents a
lso a convenient way to
designate a Windows Azure data center region with the name of your choice. (As of this writing,




13

A
NNOUNCING
N
EW
W
INDOWS
A
ZURE
S
ERVICES TO
D
ELIVER
“H
YBRID
C
LOUD

:
http://blogs.msdn.com/b/windowsazure/archive/2012/06/06/announcing
-
new
-
windows
-
azure
-
services
-
to
-
deliver
-
hybrid
-
cloud.aspx

14

Windows Azure Virtual Machines
:
https://www.windowsazure.com/en
-
us/home/features/virtual
-
machines/

15

V
IRTUAL
H
ARD
D
ISK
I
MAGE
F
ORMAT
S
PECIFICATION
:
http://go.microsoft.com/fwlink/p/?linkid=137171

16

Open Specification Promise
: http://www.microsoft.com/openspecifications/en/us/programs/osp/
default.aspx

17

VHDX

F
ORMAT
S
PECIFICATION V
1.00
:
http://www.microsoft.com/en
-
us/download/details.aspx?id=34750

18

Windows Azure C
loud
S
ervices
:
http://www.windowsazure.com/en
-
us/home/scenarios/cloud
-
services/


Active Directory from on
-
premises to the cloud


7

Windows Azure Cloud Services can be added to an affinity group only at the time of creation of the
service.)
.


Windows Azure Virtual
Network

provides control over network topology, including configuration of IP
addresses, routing tables and security policies
.
A
VNET has its own private address space. The
address space is initially IPv4 only, but could be extended to IPv6 in a future rel
ease.

Windows Azure Virtual Network

allows
securely extending on
-
premises networks into the cloud
.
With
the ability to assign a private address range for
its

VNET,
an organization

can
indeed
treat
it

as an
extension of
its

own corporate private network ad
dress space by establishing appropriate gates (VPN
gateway) between their
on
-
premises
corporate private network and their virtual network
(s)

in Windows
Azure.

For that purpose,
Windows Azure Virtual Network

enables to set up

secure
site
-
to
-
site
connectivit
y
between
the organization’s

corporate VPN gateway and Windows Azure
, and then to
connect
the
organization’s on
-
premises
corporate network to
the organization’s
Windows Azure tenant
by using a VPN gateway

along with
the industry
-
standard IPSEC protocol.


W
ith
such a

capability, IT administrators can easily create a logically isolated private environment in
Windows Azure, and connect it to
the organization’s
on
-
premises
IT infrastructure

by using a secure
VPN tunnel. Once set up, the isolated Windows Azure
environment can be view as a natural extension
of the
on
-
premises
corporate network.

To synthetize,
Windows Azure Virtual Network allow
s

you to create private network
(s)

of
VMs

in
your

Windows Azure
tenant
environment that you can assign IP addresses to
and then connect to your data
cen
ter through a VPN gateway
. Using this method
,

you can
seamlessly
connect on
-
premises
(virtual)
machines to

VMs running in your Windows Azure tenant
.

T
he above capabilities enable

the support
of

t
hree key Microsoft
workloads

to deploy in the cloud
:

1.

Active Directory
:

A
n

hybrid identity solution with extensive networking expectations;

2.

SQL Server
:

A

database workload with expectations for exceptional disk performance;

3.

SharePoint Server
:
A

large
-
scale, multi
-
tier application with

a load
-
balanced front
-
end.
Moreover,
SharePoint Server deployments include
Active Directory
and
SQL Server.

These broad
workload types can

be deployed
either standalone or
as part of a larger application, with
or without on
-
premises connectivity.

In the specific context of this paper,
Windows Azure Virtual Machines

and
Windows Azure Virtual
Network

enable AD in Windows Azure
a reality of today.

The fundamental requirements for deploying Windows Server
AD

on VM
(s)

in Windows Azure differ
very little

from deploying it in VMs (and, to some extent, physical machines) on
-
premises. For example,
if the domain controllers (DCs) that you deploy on WM are replicas in an existing on
-
premises
corporate domain/forest, then the Windows Azure deployment can largel
y be treated in the same way
as you might treat any other additional Windows Server AD site. That is, subnets must be defined in
Windows Server AD, a site created, the subnets linked to that site, and connected to other sites using
appropriate site
-
links.
There are, however, a number of differences that are common to all Windows
Azure deployments and some that vary according to the specific deployment scenario.

The articles
I
NSTALL A NEW
A
CTIVE
D
IRECTORY FOREST IN
W
INDOWS
A
ZURE
19

and
G
UIDELINES FOR
D
EPLOYING
W
INDOWS
S
ERVER
A
CTIVE
D
IRECTORY ON
W
INDOWS
A
ZURE
V
IRTUAL
M
ACHINES
20

cover t
he

fundamental differences and explained in
great

detail
how successfully deploy and operate AD in
Windows Azure. The former deals with a standalone configuration in the cloud whereas the latter




19

I
NSTALL A NEW
A
CTIVE
D
IRECTORY FOREST IN
W
INDOW
S
A
ZURE
:
http://www.windowsazure.com/en
-
us/manage/services/networking/active
-
directory
-
forest/

20

G
UIDELINES FOR
D
EPLOYING
W
INDOWS
S
ERVER
A
CTIVE
D
IRECTORY ON
W
INDOWS
A
ZURE
V
IRTUAL
M
ACHINES
:
http://msdn.microsoft.com/en
-
us/library/windowsazure/jj156090


8

Active Directory from on
-
premises to the cloud

highlights the requirements for deploying AD in a hybrid scen
ario in which Windows Server AD is partly
deployed on
-
premises and partly deployed on VMs in Windows Azure.

Whatever the scenario is,
and a
s you understand, AD in Windows Azure simply means
Windows Server AD running in your VMs in your Windows Azure tenant

for the best
compatibility with existing applications and for hybrid applications.

AD in Windows Azure is NOT Windows Azure AD, a REST
-
based service that provides identity
management and access control capabilities for cloud applications.


Wikipedia
21

defines REST and RESTful service as follows:


Representational State Transfer (REST) is a style of software architecture for distributed
hypermedia systems such as the Wo
rld Wide Web. The term Representational State Transfer was
introduced and defined in 2000 by Roy Fielding in his doctoral dissertation. Fielding is one of the
principal authors of the Hypertext Transfer Protocol (HTTP) specification versions 1.0 and 1.1.

C
onforming to the REST constraints is referred to as being ‘RESTful’.




A RESTful web service (also called a RESTful
web API
) is a simple web service implemented
using HTTP and the
principles of REST. It is a collection of resources, with three defined aspects:



the base URI for the web service, such as http://example.com/resources/



the MIME type of the data supported by the web service. This is often JSON, XML or
YAML but can be any
other valid MIME type.



the set of operations supported by the web service using HTTP methods (e.g., POST,
GET, PUT or DELETE).


With this definition in mind, l
et’s
consider

what
Windows Azure AD
is
all about
in the next section.





21

REST :
http://en.wikipedia.org/wiki/Representational_State_Transfer


Active Directory from on
-
premises to the cloud


9


What is Windows Azure AD?

3
W
indows Azure Active Directory (Windows Azure AD or simply AAD)

was introduced

b
ack in
November
2011 as the cloud service that provides identity and access capabilities for
services

on
Microsoft Office 365.

John Shewchuk,
the Microsoft

Technical Fellow who

plays a key role in getting our cloud identity
offering engineered right
,
describes
22

Windows Azure AD

as follows: “
We have taken Active Directory,
a widely deployed, enterprise
-
grade identity management solution, and made it operate in the cloud as
a
multi
-
tenant

service with Internet scale, high availability, and integrated disa
ster recovery.

Since we first talked abo
ut it in November 2011, Windows Azure
AD

has shown itself to be a robust
identity and access management service for both Microsoft Office 365 and Wi
ndows Azure

based
applications.

In the interim, we have been working to enhance Windows Azure
AD

by adding n
ew, Internet
-
focused
connectivity, mobility, and collaboration capabilities that offer value to applications running anywhere
and on any platform. This includes applications running on mobile devices like iPhone, cloud platforms
like Amazon Web Servic
es, a
nd technologies like Java.

The easiest way to think about Windows Azure
AD

is that Microsoft is enabling an organization’s Active
Directory to operate in the cloud. Just like the Active Directory feature in the Windows Server operating
system that operates

within your organization, the Active Directory service that is available through
Windows Azure is your organization’s Active Directory. Because it is your organization’s directory, you
decide who your users are, what information you keep in your directory
, who can use the information
and manage it, and what applications are allowed to access that information. And if you already have
on
-
premises Active Directory, this isn’t an additional, separate copy of your directory that you have to
manage independently
; it is the same directory you already own that
has been extended to the cloud.

Meanwhile, it is Microsoft’s responsibility to keep Active Directory running in the cloud with high scale,
high availability, and integrated disaster recovery, while fully resp
ecting your requirements for the
privacy and security of your information.

As such,
it

provides easy
-
to
-
use,
multi
-
tenant

identity management services for applications running in
the cloud and on any device and any platform with the Bring Your Own Device (
BYOD) as a resul
t of
the Consumerization of IT.”

Windows Azure AD provides a
multi
-
tenant

cloud
-
based store for directory data and a core set
of identity services including user logon processes, authentication and federation services.
Windows Azure AD is able to scale to millions of customers and billions of objects.

As of today, since its introduction, Windows Azure AD has “
now processed 200 B
illion

authentications
for 50 M
illion

active user accounts. In an average week we receive 4.7 B
illion
authentication requests
for users in over 420 T
housand

different domains. This is a massive workload when you consider
others in the industry are attempting to process 7B logins per year

.

A
number of people
are
surprised to find out that every Office 365 customer already has a
Windows Azure AD directory tenant.



Windows Azure AD is indeed the directory used by Office 365 to store user identities and other tenant
properties.





22

R
EIMAGING
A
CTIVE
D
IRECTORY FOR THE
S
OCIAL
E
NTERPRISE
(P
ART
1)
:
http://blogs.msdn.com/b/windowsazure/archive/2012/05/23/reimagining
-
active
-
directory
-
for
-
the
-
social
-
enterprise
-
part
-
1.aspx


10

Active Directory from on
-
premises to the cloud

If you are a Mic
rosoft Office365 customer
,

y
ou can then navigate to the (preview of the)
Windows
Azure AD Management Portal
23

(
activedirectory.windowsazure.c
om
) and sign in with your
organizational account.


Windows Azure
AD

is used by a number of Microsoft cloud services today, and through the developer
preview
program
it is possible to extend the usage of these directory tenants to other applications.



It’s also possible to obtain a “standalone” directory tenant through
the

provisioning system
.

If you don’t
already have a tenant,
you can set up your own custom Windows Azure AD
“standalone”
directory
tenant for free as part of the developer preview progra
m

by
follow
ing the link

http://g.microsoftonline.com/0AX00en/5
.



If you create a new tenant, the first user you generate as part of the sign
-
up process will also be an
administrator.





23

Preview of the Windows Azure AD Management Portal:
https://activedirectory.windowsazure.com/


Active Directory from on
-
premises to the cloud


11

The
d
eveloper
p
review of Windows Azure AD is currently available as a free preview service. It
is not intended for production use at this time.

At general availability (GA), Windows Azure AD will remain available at NO charge. (
See blog
post
W
INDOWS
A
ZURE
A
CTIVE
D
IRECTORY
:

MAKING IT EASIER TO
ESTABLISH
I
DENTITY
M
ANAGEMENT IN THE
C
LOUD
24
)

Same is true for
Windows Azure AD Access Control (see section §
7

B
RING
Y
OUR
O
WN
I
DENTITY
(BYOI)

WITH
W
INDOWS
A
ZURE
AD

A
CCESS
C
ONTROL
).

The rest of this chapter
describes the main characteristics of Windows Azure AD that organizations
and cloud applications can leverage, and the functionalities that Windows Azure AD provides for

the
users of these applications and

for

the developers of these applications to be successful.

As of today,
Windows Azure AD
is still in preview and
keeps continuing to receive enhancements that
make Windows Azure AD even more useful for IT professionals
and developers.

N
ote:

Please make sure you periodically check the
Windows Azure Active Directory community forum
25

as
well as the MSDN
Windows Azure blog
26

for notification of upcoming
enhancement and
changes

that
relate to Windows Azure AD
.


For a short
look back at the
recent enhancements, the starting point since the initial introduct
ion in
2011 is the announcement of the developer preview

in June 2012

(see blog post
A
NNOUNCING THE
D
EVELOPER
P
REVIEW OF
W
INDOWS
A
ZURE
A
CTIVE
D
IRECTORY
27
). N
ew components have been introduced
with the developer preview
in order to make it easy for developers to take advantage of Windows
Azure
AD

for adding single sign
-
on and directory management capabilities to
W
eb

applications, rich
clients and RESTful services. Specifically, the following capabilities were announced:



Web Single Sign
-
On (SSO) for cloud and SaaS applications

with the support of the WS
-
Federation protocol

(see section §
6

E
NABLE
S
INGLE
S
IGN
-
O
N

AND
W
INDOWS
A
ZURE
AD

D
IRECTORY
S
ERVICES FOR
C
LOUD APPLICATIONS
)
,



Windows Azure Active Directory Graph, a RESTful API to programmatically access identity
relationships in the Windows Azure AD directory to build rich applications

(see section §
3.2.1.4

P
ROGRAMMING
INTERFACE
)
.

The Microsoft Tech
Ed US 2012 session recording
s

A

L
AP
A
ROUND
W
INDOWS
A
ZURE
A
CTIVE
D
IRECTORY
28

and
D
IRECTORY
G
RAPH
API:

D
RILL
D
OWN
29

provide

an intro
duction to these capabilities.

In August 2012 was introduced the
Windows Azure Authentication Library (AAL), a new capability in
the
d
eveloper
p
review

(see blog post
I
NTRODUCING A
N
EW
C
APABILITY IN THE
W
INDOWS
A
ZURE
AD





24

W
INDOWS
A
ZURE
A
CTIVE
D
IRECTORY
:

MAKING IT EASIER TO
ESTABLISH
I
DENTITY
M
ANAGEMENT IN THE
C
LOUD
:
http://blogs.msdn.com/b/windowsazure/archive/2012/11/30/window
s
-
azure
-
active
-
directory
-
making
-
it
-
easier
-
to
-
establish
-
identity
-
management
-
in
-
the
-
cloud.aspx

25

Windows Azure Acti
ve Directory community forum
: http://social.msdn.microsoft.com/Forums/en
-
US/WindowsAzureAD/

26

Windows Azure blog
: http://blogs.msdn.com/b/windo
wsazure/

27

A
NNOUNCING THE
D
EVELOPER
P
REVIEW OF
W
INDOWS
A
ZURE
A
CTIVE
D
IRECTORY
:
http://blogs.msdn.com/b/windowsazure/archive/2012/07/12/announcing
-
the
-
developer
-
preview
-
of
-
windows
-
azure
-
active
-
directory.aspx

28

A

L
AP
A
ROUND
W
INDOWS
A
ZURE
A
CTIVE
D
IRECTORY
:
ht
tp://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/SIA209

29

D
IRECTORY
G
RAPH
API:

D
RILL
D
OWN
: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/SIA322


12

Active Directory from on
-
premises to the cloud

D
EVELOPER
P
REVIEW
:

THE
W
INDOWS
A
ZURE
A
UTHENTICATION
L
IBRARY
30
).

Whilst developers can of
course write di
rectly to the standards based protocols supported in Windows Azure AD, this library is
another option available for developers who are looking for a faster and simpler way to
take advantage
of Windows Azure AD

in high value scenarios, including the ability

to sec
ure access to your cloud
applications (see section §
6.2.2

E
NABLE SINGLE SIGN
-
ON
(SSO)

WITH
W
INDOWS
A
ZURE
AD
)
.

In September 2012,
three major enhancements
have been made available
to
the

developer preview

as
announced in the blog post
M
ORE
A
DVANCES IN THE
W
INDOWS
A
ZURE
A
CTIVE
D
IRECTORY
D
EVELOPER
P
REVIEW
31
:



The ability to create a standalone Windows Azure AD
directory
tenant
,



A preview of
the Windows Azure A
D
Management
portal

that gives a graphical user interface
to manage the directory tenant
,



Write support
in the
Windows Azure Active Directory Graph

API
.


N
ote:

This
latter
update includes support for create, update, delete operations for users, groups, and group
Membership, user license assignments, contact management, and set
JavaScript Object Notation
(
JSON) as the default data format, which is of interest for instance for

mobile applications.


Lastly, i
n November 2012,
and
as described on the blog post
E
NHANCEMENTS TO
W
INDOWS
A
ZURE
A
CTIVE
D
IR
ECTORY
P
REVIEW
32
, t
he
following

enhancements
ha
ve
been
added:



Added graphical user interfaces for registering your cloud application in a directory tenant,



Support for the SAML 2.0 protocol for Web SSO,



Sign out support for the WS
-
Federation protocol in Web

SSO,



Differential query in the
Windows Azure Active Directory Graph

API,



The ability to federate
Windows Azure AD
directory tenants with
Windows Azure AD
Access
Control namespaces

(see section §
7

B
RING
Y
OUR
O
WN
I
DENTITY
(BYOI)

WITH
W
INDOWS
A
ZURE
AD

A
CCESS
C
ONTROL
)
,



And a
n updated version of the Windows Azure Authentication Library

(AAL)
.

Even more
Windows Azure AD
functionalit
ies

will be integrated
this

year

for your identities in the cloud
.

The rest
of the document provides a description for all of the above.







30

I
NTRODUCING A
N
EW
C
APABILITY IN THE
W
INDOWS
A
ZURE
AD

D
EVELOPER
P
REVIEW
:

THE
W
INDOWS
A
ZURE
A
UT
HENTICATION
L
IBRARY
:
http://blogs.msdn.com/b/windowsazure/archive/2012/08/01/introducing
-
a
-
new
-
capability
-
in
-
the
-
windows
-
azure
-
ad
-
developer
-
preview
-
the
-
windows
-
azure
-
authentication
-
library.aspx

31

M
ORE
A
DVANCES IN THE
W
INDOWS
A
ZURE
A
CTIVE
D
IRECTORY
D
EVELOPE
R
P
REVIEW
:
http://blogs.msdn.com/b/windowsazure/archive/2012/09/12/more
-
advances
-
in
-
the
-
windows
-
azure
-
active
-
directory
-
developer
-
preview.aspx

32

E
NHANCEMENTS TO
W
INDOWS
A
ZURE
A
CTIVE
D
IRECTORY
P
REVIEW
:
http://blogs.msdn.com/b/windowsazure/archive/2012/11/07/enhancements
-
to
-
windows
-
azure
-
active
-
directory
-
preview.aspx


Active Directory from on
-
premises to the cloud


13

3.1

Type of i
dentities

Windows Azure AD enables a customer to be able to start using its services with no on
-
premises
footprint. Accordingly, Windows Azure AD provides for hosted
(cloud)
identities

where customers can
create users, groups and other principals for their organization.

The c
loud i
dentities
(
Cloud ID
)
are
mastered in Windows Azure AD.

With cloud identities,

u
sers receive, for signing into Windows Azure AD and any services and
applications that are integrated into Windows Azure AD (see section §
6

E
NABLE
S
INGLE
S
IGN
-
O
N

AND
W
INDOWS
A
ZURE
AD

D
IRECTORY
S
ERVICES FOR
C
LOUD APPLICATIONS
)
,

c
loud credentials
(
that are
separate from other desktop or corporate on
-
premise
s

credentials

if any)
.

Many enterprise customers will want to federate their on
-
premises
identity infrastructure

with Windows
Azure AD

to establish a hybrid corporate identity platform.

I
t’s a more sophisticated approach in the
sense that it

requi
res
setting up

a federation between their on
-
premises identity
infrastructure and
Windows Azure AD

(see section §
5

F
EDERATE YOUR
W
INDOWS
A
ZURE
AD

DIRECTORY TENANT WIT
H YOUR
ON
-
PREMISES DIRECTORY
)
.
Users can then sign into Windows Azure AD or any services and
applications that are integrated
into Windows Azure AD using their own corporate credentials. The
user’s IDs

are mastered on
-
premise
s in the identity infrastructure
and synchronized to the
Windows
Azure AD

in the form of
f
ederated

identities (
f
ederated ID).

Users can gain access to
Window
s Azure AD

or any services and applications that are integrated into
Windows Azure AD

by authenticating to their
Windows Azure AD

user accounts, either through a
prompt to provide valid credentials or through a
federated
single sign
-
on
(SSO)
process. Once
authenticated, user
’s

identities refer to the user names associated with the
Windows Azure AD

accounts.

Considering the above, we have three authentication
/deployment model

types available:

1.

Cloud i
dentit
ies;

2.

Cloud i
dentit
ies

+
d
irectory
s
ynchronization
;

3.

F
ederated i
dentit
ies
+
directory synchronization.

Through d
irectory
s
ynchronization
, organizations can keep their existing on
-
premises identity
infrastructure synchronized with
their
Windows Azure AD

directory tenant
.
The directory
synchronization is discus
sed in section §
4

S
YNCHRONIZE YOUR
W
INDOWS
A
ZURE
AD

DIRECTORY TENANT
WITH YOUR

on
-
premises directory

for larger organization’s that may want to streamline the provisioning
and the synchronization of identities.

The above type of identity (cloud vs. federated) affects the user experience, adm
inistrative
requirements, deployment considerations, and capabilities using Windows Azure AD.

The following is the simplified breakdown of the experience:



User
e
xperience with
c
loud
i
dentities
:

U
sers s
ign in with
their
cloud identity
. Cloud i
dentities
are

authenticated using traditional challenge/response, where users type in their user name
and password.

Authentication happens in the cloud
.
Users
are always prompted for
credentials.

As mentioned above, u
sers
may
have two IDs
, i.e.

C
loud ID

for
Windows Azu
re AD itself and
the services and applications in the cloud that leverage Windows Azure AD and potentially one
for

access
ing

on
-
premises

serv
ices. Consequently, users are prompted for credentials even
when logged into their on
-
premises infrastructure (AD o
r non
-
AD sources) when accessing
Windows Azure AD

itself and the services and applications in the cloud that leverage Windows
Azure AD
.



User
e
xperience with
f
ederated i
dentities
:

U
sers
s
ign in with corporate ID

for access to
online and corporate services. In other words, they

are authenticated transparently using
the
on
-
premises identity infrastructure when accessing Windows Azure AD itself and the services

14

Active Directory from on
-
premises to the cloud

and applications in the cloud that leverage Windows Azu
re AD. Authentication happens on
-
premises

against the organization’s identity provider servers and u
sers get true SSO
.
Furthermore,
multi
f
actor
a
uthentication
(MFA)
can be utilized if it is deployed on
-
premise
s
.

Important n
ote:

M
ultifactor
authentication (
MFA)
support is available is not available for clients other than Web
browsers. Other clients that do not have the capability to prompt users for strong authentication
credentials can therefore not be supported. Strong authentication must only be applied t
o the passive
federation endpoints

on on
-
premises identity provider servers
, as other clients will otherwise not be
able to connect.




Administrator
e
xperience with
c
loud
i
dentities
:

O
rganization’s administrators manage

the
password policy
both
in
the
cloud
and on
-
premises
. The cloud identities password policy is
stored in the cloud with Windows Azure AD.
Password reset

has to be managed for on
-
premises and the cloud identities and
,

hence
,

the users have to change the password as per
the policy for both
. Finally, there is no
MFA

integration
.

N
ote:

With the recent acquisition of
PhoneFactor
33

in October 2012,
MFA support could be introduced in
Windows Azure AD in the
future
.

As
Bharat Shah, corporate vice president, Server and Tools Division
for Microsoft
, said, “The

acquisition of PhoneFactor will help Microsoft bring effective and easy
-
to
-
use
multifactor authentication to our cloud services and on
-
premises applicatio
ns
.


By leveraging a device nearly every user already has


a phone


PhoneFactor enables rapid
deployment of MFA across a wide range of applications. It already works with many Microsoft
products and services, including Outlook Web Access and Internet In
formation Services, and
interoperates with Active Directory




Administrator
e
xperience with
f
ederated i
dentities
:

O
rganization’s administrators manage

the
password policy on
-
premise
s

only

and hence do not need to separately worry about
password reset for f
ederated

identities. The organization’s identity infrastructure stores and
controls the password policy.
Password reset
occurs
for on premise IDs only
. Eventually,
several
on
-
premises
M
FA integration options are offered.

While the “
f
ederated i
dentit
ies
+
d
irectory synchronization” model may require some server
investments and deeper architectural decision making, it does allow support for richer federated single
sign
-
on with the corporate credentials, integration with on
-
premises
M
FA and a configurable pass
word
policy. It enables organization to adequately manage their hybrid environment.

Since organizations usually want to pilot/test something new with a small number of users and then
enable it for

their full end user population,

Windows Azure AD supports s
taged federation to allow a
customer to incrementally deploy or rollback federation
.

For the moment, let’s see how Windows Azure AD supports both cloud identities and federated
identities.





33

M
ICROSOFT
A
CQUIRES
P
HONE
F
ACTOR
:
http://www.microsoft.com/en
-
us/news/Press/2012/Oct12/10
-
04MFAPR.aspx


Active Directory from on
-
premises to the cloud


15

3.2

Anatomy of
Windows Azure
AD

At the simplest level, Windows Azure
AD

(core directory and authentication)

is a scalable directory
infrastructure that provides for storage, data access, replication and synchronization, and security
token services (STS).

Below is a conceptual
diagram

showing the public interfaces, and the
management surface:


3.2.1

Core Directory

The core directory represents the hea
r
t of Windows Azure AD.
As a directory (service in the cloud) and
with the objective to eliminate the need of an application
-
specific store for notably identity information,
Windows
Azure AD aims at supporting data of common interest across the vast majority applications
whether they are cloud, SaaS, mobile, etc. applications as well as the possible relationships between
those data.


3.2.1.1

Data
m
odel

and

schema

Users and groups are typically good examples where organizations want to create them once and
reuse them across their applications or the ones for
which
they buy a subscription
.

Information in the directory should generally have the following characteristi
cs:



Public

in the sense of

something that is useful to share across the organization,
and
not
something private like the salary attribute of a user object,



Mostly static

over the time
,
and
not changed often,



Small, generally pointers to information vs. the

information itself.

Unsurprisingly, Windows Azure AD follows the
Windows Server
AD data model with suitable changes
for cloud use. The core data model is as follows:



The directory is divided into
directory contexts
, one per tenant plus a system context.
Each
directory

context has a
n immutable,

globally unique, non
-
reusable
GUID
-
valued
identi
f
i
er



a
context ID



and contains
a set of
entities (or
objects
)

and
association

(or
links
) between the
entities
. Each object or link belongs to exactly one context.


16

Active Directory from on
-
premises to the cloud



Each object has a
n

object class

or
type
(
ObjectType
)
:
User
,
Contact
,
Group
, etc. and
a
n
immutable,

globally unique, non
-
reusable
GUID
-
valued
identi
f
i
er
, i.e.
an
object ID

(ObjectId)
.



An object contains a set of
properties
:
DisplayName
,
UserPrincipalName
,
JobTitle
,
Department
,
TelephoneNumber
, etc. Each property has a
name

and, if set, contains a
value

or a set of values. The object class determines which properties may appear on the object,
and the property determines the type (string, binary, integer, s
tructure, etc.) and multiplicity of
the values.



An object may contain a set of
navigation

properties

that each corresponds to a
link

(or
association)
.
A
link

is a directional, typed relationship from one object to another object, all in
the same context.

The type of the link is its
link class
:
Manager
,
DirectReports
,
Member
Of
,
Members
,
etc. Links
significantly contribute to establish an enterprise social graph as
discussed in the
John
Shewchuk

blog post
34
. Links
maintain referential integrity: deleting the
source or target object of the relationshi
p implicitly deletes the link.



Object (respectively link) instances may be group into set of

The
Windows Azure AD
directory schema defines the properties, object classes, and link classes;
much of it is a subset of standard LDAP
v3
(
and
Windows Server
A
D
)

schemas.

It however differs from that of LDAP directories in the following ways:



Unlike entries in an LDAP directory, objects do not have distinguished names and are not
arranged into a distinguished multi
-
level hierarchy. Objects can be interpreted as h
aving
various hierarchical relationships based on links and property values.



The directory does not support object class inheritance. In Windows Server AD, such a
capability was used in very limited ways but added significant complexity to the system.

T
he
Windows Azure AD
directory schema is fixed
for a specific version of Windows Azure AD,
and, in particular

for scaling

reasons, it is not per
-
tenant.

The Windows Azure AD directory
schema may evolve with versions of Windows Azure AD as it was the case fo
r the Windows Server AD
directory schema over the time
since its first introduction in

the early 2000.

Generally speaking,
applications
that consume directory information
tend to fall into
the following three

classes

with respect to directory extensibility

requirements
.

1.

A first class of application that corresponds to the vast

majority do
es
n

t need to extend the
directory

and has no extensibility requirements to address.

2.

A second class of applications has very simple extensibility needs where they need to p
ublish
some information about a directory entity, such as a user, to other applications.
As of today,

a
built
-
in extensibility mechanism addresses this kind of extensibility requirements in the specific
and historical context of Microsoft Online Services a
pplications. A similar mechanism for third
-
party applications may be introduced in the future.

3.

The final class of applications
is the one without any surprise that
has
extensive extensibility
needs.

They may maintain significant information about users an
d other objects
, and also

may
have complex query needs based on properties and links. These queries may be in the
mainline high volume path of the application. Exchange is an example of such an application.

The
use of an application
-
specific

local store fo
r extensibility

is probably the best option in this
case
.
With the advent of

the cloud
,
storage
capabilities
are widely

available through services
such as
Windows
Azure Stor
age

and
Windows Azure
SQL
database
.
An

application
that falls
in
to

this model
usua
lly
maintains its own tables in a storage service. A typical model might be
that rows in the table represent
Windows Azure AD
directory entities about which the




34

R
EIMAGING
A
CTIVE
D
IRECTORY FOR THE
S
OCIAL
E
NTERPRISE
(P
ART
2)
:
http://blogs.msdn.com/b/windowsazure/archive/2012/06/20/reimagining
-
active
-
directory
-
for
-
the
-
social
-
enterprise
-
part
-
2.aspx


Active Directory from on
-
premises to the cloud


17

application maintains its information. One of the columns of the table would be a key that
iden
tifies the entity in the directory (i.e. the join key). The other columns represent application
-
specific information. The application can make use of
the differential query capability

supported by the directory to manage the lifecycle of the rows in its ta
bles utilizing the “join
key”.

3.2.1.2

Directory t
enants

As most people know, the forest in Windows Server AD represents the administrative boundary.
Likewise, the
directory
tenant in Windows Azure AD represents an administrative boundary from a
customer viewpoi
nt.

As a
forest contains one or multiple

domains, a directory tenant contains one o
r

multiple domains.

After signing up for Windows Azure AD (or for a Microsoft Online service that leverage Windows Azure
AD such as Microsoft Office 365), the only domain
associated with your subscription account and
created with the directory tenant

is the
<
organization name
>
.onmicrosoft.com

domain chosen during
registration,
for example

idmgt
.onmicrosoft.com
.

This is the default
domain
.

When you create a new user, the user’s sign
-
in name and email address
are assigned to this default domain.


You can
off course
add one or more
customs

domains to a directory tenant rather than retaining the
onmicrosoft.com

domain, and
then

assign users to

sign in with any of the validated domains.

For that purpose, as you can declare enterprise administrator(s) for the forest, there are similarly
tenant wide administrators for the organization’s directory tenant.

Tenant administrators can register mul
tipl
e DNS domain names for the

Windows Azure AD
tenant of
the organization
, for example
demo.
id
mgt.
archims.
fr
.

The directory allows a tenant administrator to
register a DNS domain only after he proves that his organization owns the DNS namespace in the
public internet DNS.
As of this writing, y
o
u can host up to 600 registered

domains in
your directory
tenant
, each
represented by a different
DNS
namespace.

A domain can be
either
a cloud
(standard)
domain or a federated
(
single sign
-
on
)
domain
,

meaning
that a
ll users on a domain
MUST

use the same identity system: either cloud identity or federated
identity

(see secti
on §
3.1

T
YPE OF I
DENTITIES
)
.

For example, you could have one group of users that only needs a cloud identity because they don’t
have an on
-
premises account and/or
access on
-
premises systems, and another group of users who
have an on
-
premises account and/or
use
cloud app
lications

and o
n
-
premises systems. You would use
add two domains to
the directory tenant
, such as
contractors.
demo.
idmgt
.
archims.
fr

and
fte
.
demo.
idmgt
.
archims.
fr
, and only set up
the
federation for one of them

(see section §
5

F
EDERATE
YOUR
W
INDOWS
A
ZURE
AD

DIRECTORY TENANT WIT
H YOUR ON
-
PREMISES DIRECTORY
)
.

A domain can be converted from cloud to federat
ed, or from federated to cloud.

3.2.1.3

Management surface

Windows Azure AD allows administrators to manage information in it through:



The use of the
graphical user interface thanks to a
Web
-
based management portal.



18

Active Directory from on
-
premises to the cloud

N
ote:

When you navigate to the (preview of the) Windows Azure AD Management Portal
(
activedirectory.windowsazure.com
), you will be potentially immediately redirected to the Windows
Azure AD sign
-
in service for authentication. The Windows Azure AD sign
-
in service is part of the
(logical) security token service (STS) of Windows Azure AD (see later in document in section §

3.2.2

STS
).




A

set of Windows PowerShell
cmdlets, that allows for scripting frequent operations
: the
Microsoft Online Services Module

for Windows PowerShell
.



(O
n
-
premises management tools used to manage information in an on
-
premises directory and
then synchronized into Windows Azure AD

with the d
irectory synchronization
.
)


A Windows PowerShell "module" is a package that contains Windows PowerShell commands, cmdlets,
providers, functions, variables, and aliases. The
Microsoft

Online

Services

Module

for

Windows

PowerShell
is a separate installation

package (
AdministrationConfig
-
en.msi
) for
32
-
bit
35

or
64
-
bit
36

Windows platform
s
, which includes cmdlets specifically designed for
Windows Azure AD/Office 365
administration.
I
t
indeed
enables you to connect a Windows PowerShell command shell to your
Windows Azure AD directory tenant and then to perform directory
-
oriented operations
.

The cmdlets
currently
layer on the same SOAP based
task oriented interface that the Web
management portal uses for accessing the directory.

Note:

Windows PowerShell

is a task
-
based command
-
line shell and scripting language that is
designed for system/service administration and automation. It uses adminis
trative tasks called
cmdlets. Each cmdlet has required and optional arguments, called parameters, that identify which
objects to act on or control how the cmdlet performs its task. You can combine cmdlets in scripts to
perform complex functions that give y
ou more control and help you automate the administration of
Windows, applicati
ons and online services in the c
loud. It has become a common way to manage the
latest generation of Microsoft products and services.

For more information about Windows PowerShell, please see the
Windows PowerShell Web site
37
, the
Windows PowerShell online help
38
, and the
Windows PowerShell Weblog
39

Windows PowerShell
Software Development Kit (SDK)
40

that includes a programmer’s guide along with a
full reference
.


Administrative privileges are needed on the local computer in order to install the Microsoft Online
Services Module

for Windows PowerShell
.

As an

illustrat
ion, let’s see

how to

creat
e

custom domains within a directory tenant

with
the cmd
lets
provided by this module.






35

Microsoft Online Services Module for Windows PowerShell (32
-
bit version
)
:
http://go.microsoft.com/fwlin
k/?linkid=236345

36

Microsoft Online Services Module for Windows PowerShell (64
-
bit version
)
: http://go.microsoft.com/fwlink/p/?linkid=236293

37

Windows PowerShell Web site: http://www.microsoft.com/powershell

38

Windows PowerShell online help: http://technet.microsoft.com/en
-
us/library/bb978526.aspx

39

Windows PowerShell Weblog: http://blogs.msdn.com/powershell

40

Windows PowerShell SDK: http://msdn2.microsoft.com/en
-
us/library/aa830112.aspx


Active Directory from on
-
premises to the cloud


19

T
he
New
-
MsolDomain

cmdlet enables to create a standard (managed) domain based on t
he specified
DNS domain names.
After running this command, you have to
prove that
your

organization owns the
DNS namespace in the public intern
et DNS
.

For that purpose, you need to use the
Get
-
MsolDomainVerificationDns

cmdlet in order to get the
DNS record information
required
to create for the new managed domain. To prove that you control the
domain, you then use the output of the command to cr
eate a CNAME record in the
authoritative
DNS
server
for

the
DNS
domain used previously. Windows Azure AD

indeed uses a DNS record that you
create at your registrar to confirm that you
really
own the domain. For additional information, please
refer to the
Microsoft TechNet
articles
A
DD YOUR DOMAIN
41

and
V
ERIFY A DOMAIN AT AN
Y DOMAIN NAME
REGISTRAR
42
.

Once done, you
finally prove
your control of the
DNS namespace

by running the
Confirm
-
MsolDomain

cmdlet.

N
ote:

The
custom
domain can also be added from the
(preview of the)

Windows Azure AD Management
Portal
as well. The steps would be identical and the domain would sti
ll have to be verified in the same
way
.


Similarly,
you can use the
New
-
MsolFederatedDomain

cmdlet
to create of custom federated
(single
sign
-
on)
domain in your directory tenant.
Finally, t
he
Set
-
MsolDomainAuthentication

cmdlet

enables
to convert a standard domain into a single
-
sign on domain
.

Note:

For more information about
the available

cmdlets

and how to use theme
, see the Microsoft TechNet
articles
U
SE
W
INDOWS
P
OWER
S
HELL CMDLETS TO MANA
GE YOUR
W
INDOWS
A
ZURE
AD

TENANT
43

and
W
INDOWS
P
OWER
S
HELL CMDLET DESCRIPT
IONS
44
.

For more information about a cmdlet that you can run in Windows PowerS
hell, at the Windows
PowerShell command prompt, type “Get
-
help” and the name of the cmdlet.


After creating one or multiple custom domains, you can verify that the domains were added correctly
via the
(preview of the) Windows Azure AD Management Portal
.





41

A
DD YOUR DOMAIN
:

http
://technet.microsoft.com/en
-
us/library/hh969247.aspx

42

V
ERIFY A DOMAIN AT AN
Y DOMAIN NAME REGIST
RAR
:
http://technet.microsoft.com/en
-
us/library/jj151803.aspx

43

U
SE
W
INDOWS
P
OWER
S
HELL CMDLETS TO MANA
GE YOUR
W
INDOWS
A
ZURE
AD

TENANT
:

http://technet.microsoft.com/en
-
us/library/jj151805

44

W
INDOWS
P
OWER
S
HELL CMDLET