MS Cloud Foundation

Architecture Foundation





Company / Organization: 

Scope: 0.0 {language={en}; document-type={ott}; organization={}; interest={business}; domain={architecture}; level={foundation}; technology={ms-cloud,azure,office-365,dynamics-365}}

Version: 1.3.0

File-name: becke-ch--ms-cloud--s0-v1--foundation.odt


Copyright © 2019 – All rights reserved


Document Version History







Raoul Becke

Initial version



Raoul Becke

Additional chapters: “Login PowerShell“, “Login & Select Subscription”, Data Factory


Extended the list of IMPORTANT CHANGES that need to be considered to guarantee a smooth deployment



Raoul Becke

Changes according to requirements see table below version 1.2.0



Raoul Becke

Changes according to requirements see table below version 1.3.0



Work-Product Version History





Components Changed



Raoul Becke

MS Cloud Overview




Raoul Becke

Add documentation on: Deployment, PowerShell, Data Factory




Raoul Becke

Update copyright year, Basics chapter - added information on CaaS, new chapter "Command Line Interface: Azure CLI", new appendix-chapter "My Vsiual Studio: Developer License (MSDN): Activate Azure Benefit on Alternate Account", new appendix-chapter "Azure Data Factory – V2: ETL: Extract, Transfrom & Load: SSIS", new appendix-chapter "Azure Container Instance (ACI)", new appendix-chapter "Azure Cloud Services"




Raoul Becke

Moved entire appendix into separate document see [38].

Entirely reworked chapter: XaaS: IaaS, CaaS, PaaS, SaaS

Updated information on: CaaS

Updated information on: VPN or Expressroute, SaaS>PaaS>CaaS>IaaS, DevOps

Updated information on: PowerBI

Added information on: Management Group and Hierarchy

Updated information on: Subscription Handling, Pros and Cons







Table of Contents

1. Introduction

2. Basics

2.1. XaaS: IaaS, CaaS, PaaS, SaaS

2.2. Migration

2.3. Microsoft Cloud Offerings & Hierarchy

2.3.1. Microsoft Cloud Offerings: Microsoft SaaS Services, Microsoft Azure PaaS & CaaS & IaaS Microsoft SaaS Services Microsoft Azure SaaS, PaaS, CaaS & IaaS Notes

2.3.2. Microsoft Cloud Hierarchy: Organization, Subscription, License, User Account Azure Best Practice Naming Convention Notes

2.3.3. Processes Sign-up

3. Security

3.1. Identity Management & Authentication

3.1.1. Login PowerShell

3.2. Access Management & Authorization

3.2.1. Group Management Create Group

3.2.2. Database Azure Active Directory Admin

3.2.3. Notes

4. Operations

4.1. Scripting: Azure & PowerShell

4.2. Command Line Interface: Azure CLI

4.3. Configuration & Deployment

4.3.1. Azure Deployment Models Deploy resources with Resource Manager templates and Azure PowerShell Login & Select Subscription Automation Scripts & Deployment History Resource Manager and PowerShell Policies

4.3.2. Deployment

4.4. Logging, Monitoring, Alerting

5. Integration

5.1. ETL – Extract Transform Load

6. Landscape

7. References and glossary

7.1. References

7.2. Glossary (terms, abbreviations, acronyms)

A. Appendix

A.1. My Vsiual Studio: Developer License (MSDN): Activate Azure Benefit on Alternate Account

A.1.1. Error: Oops: It appears that you have already used your MSDN benefit for a Microsoft Azure Subscription



Illustration Index

Illustration Index

Illustration 1: Microsoft SaaS Services        9

Illustration 2: Microsoft Azure PaaS        9

Illustration 3: Microsoft Azure IaaS        9

Illustration 4: Integration of MS Cloud Offerings with Azure AD        14

Illustration 5: MS Cloud Hierarchy (ERD)        15

Illustration 6: MS Cloud Hierarchy (Directed Relations)        16

Illustration 7: Azure Scaffold        18

Illustration 8: Functional Pattern        18

Illustration 9: Business Unit Pattern        18

Illustration 10: Geographic Pattern        18

Illustration 11: Functional, Geographic, Business Unit Pattern (for organizations that have no enterprise agreement)        19

Illustration 12: Contoso Corporation: Subscriptions, Licenses and User Accounts        20

Illustration 13: Contoso Corporation: Azure Enterprise Hierarchy        20

Illustration 14: Azure Resource-Group Deployment History        39

Illustration 15: Azure Resource-Group Deployment – Automation Script        40

Illustration 16: Azure Resource-Group Deployment – Automation Script - Error        40



Index of Tables

Index of Tables

Table 1: XaaS: IaaS, CaaS, PaaS, SaaS        6

Table 2: References        46

Table 3: Glossary        46


1. Introduction

This document gives an overview of the MS cloud offerings with a focus on MS Azure. It is a summary of many different Microsoft Cloud articles spread over the Internet.


2. Basics

2.1. XaaS: IaaS, CaaS, PaaS, SaaS

In the MS Cloud most XaaS services, where X stands for: Infrastructure, Container, Platform or Software, are available in datacenters connected all over the globe – see [2] and the user can implement and offer his application built on top of these services in the datacenter(s) located closest to the end-user respective the datacenter(s) which fulfills the legal requirements of the corresponding country.















Server (HW&SW)

Storage (HW&SW)

Network (HW&SW)

Table 1: XaaS: IaaS, CaaS, PaaS, SaaS


2.2. Migration

Some aspects and drivers that should be considered when moving to the cloud are:


2.3. Microsoft Cloud Offerings & Hierarchy

Microsoft Cloud Offerings – see [6]: Microsoft provides a hierarchy of organizations, subscriptions, licenses, and user accounts for consistent use of identities and billing across its cloud offerings.

Enterprise Agreement – see [7]: The Microsoft Enterprise Agreement offers the best value to organizations with 500* or more users or devices that want a manageable volume licensing program that gives them the flexibility to buy cloud services and software licenses under one agreement.

2.3.1. Microsoft Cloud Offerings: Microsoft SaaS Services, Microsoft Azure PaaS & CaaS & IaaS

Microsoft provides the following cloud offerings:

Microsoft SaaS Services


Microsoft Azure PaaS


Microsoft Azure IaaS


Microsoft Azure CaaS

MS Azure offers different kind of container solutions: non-managed and managed. Managed containers solutions e.g. AKS (Azure Kubernetes Service) or ACI (Azure Container Instance) are SaaS: MS manages the software and patches and the user only needs to perform some configurations and can focus on building and deploying the application image.  Un-managed containers solutions e.g. ACS (Azure Container Service – deprecated 2018) are IaaS and the user needs to manage the infrastructure, container-software and -patches. If the additional flexibility (and overhead) with un-managed containers is not required, then managed container solutions should be preferred. A big advantage of containers (and as well IaaS) is that the image is self-contained and therefore the application is easily portable between different cloud providers. Microsoft SaaS Services

Looking at the XaaS definition we gave initially and the customization and development capabilities some Microsoft SaaS Services offer (for example Microsoft Dynamics 365); they rather qualify as (Enterprise) PaaS Services and not SaaS but as already mentioned the classification is not always easy respective crystal clear.

Microsoft Office 365 (see [8]): There exist 3 different MS Office offerings: “Office Home & Business”, “Office 365 Business”, and “Office 365 Business Premium”. The difference between them is the pricing and the number of applications and services they offer. In total Office 365 offers the following (end-user) applications and (shared) services:


Microsoft Dynamics 365 (see [11]): Dynamics 365 offers different licenses with different functionalities:

For detailed feature and license information see [17] (Dynamics CRM Online Licensing and Pricing guide). And to make sure that all aspects are covered it is recommended to consult with your Microsoft Dynamics Certified Partner or your Microsoft account team!


Microsoft Power BI (see Power BI is a reporting service that provides offline data integration, as well as a wide range of connectors for different data sources, as basis for data modeling and dashboard visualizations. The access to data within a report can be restricted using RLS (Row Level Security) a combination of DAX (Direct Analysis Expression) rules per table assigned to single Azure Active Directory (AAD) Users, AAD Security Groups or Distribution Lists. The access to workspaces and published reports can be restricted to: Azure Active Directory (AAD) Users, AAD Security Groups, Office 365 Groups and Distribution Lists.


Azure DevOps (formerly known as Visual Studio Team Services) (see ): Azure DevOps is Microsoft’s Cloud offering for CI (Continuous Integration) and CD (Continuous Delivery). DevOps builds on Git, a distributed version control system and integrates with different artifact repositories: .... Microsoft Azure SaaS, PaaS, CaaS & IaaS

Microsoft Azure (see [9]): Microsoft Azure provides a continuously growing list of products – see [10]. Unfortunately there exists no mapping of Azure services to XaaS classification but as a rule of thumb, based on chapter 2.1: Whenever you have to care for the O/S or if the Azure services is directly related, respective on top of Storage and Network then it is IaaS, if you build your application or service from scratch and deploy this to a run-time of the cloud provider then the corresponding Azure service classifies for PaaS and last but not least if you start with a running, production ready application or service and have (or have not) the possibility to customize it, then this offering is called SaaS. Everything that is (Docker) Container related is CaaS, BUT as already mentioned in chapter 2.1 we have either managed container services (ACI, AKS, etc.) which classify themselves as PaaS or we have unmanaged containers which classify as IaaS.




IaaS: Notes

Microsoft Office 365: Some further important aspects to consider:

Microsoft Dynamics 365: Some further important aspects to consider:


2.3.2. Microsoft Cloud Hierarchy: Organization, Subscription, License, User Account

Microsoft Cloud Hierarchy - see [6]: The Microsoft cloud offerings can be mapped into the following hierarchy of organizations, subscriptions, licenses, and user accounts



Illustration 4: Integration of MS Cloud Offerings with Azure AD


In the logical class diagram below is shown a high level overview of the MS Cloud Hierarchy including all relevant objects and relations. This diagram includes as well objects and relations from chapters further below.


Illustration 5: MS Cloud Hierarchy (ERD)


Again same diagram but this time instead of showing the association ends in crow feet notation it shows the direction of the relation:

Illustration 6: MS Cloud Hierarchy (Directed Relations) Azure

Azure has some additional hierarchy elements that do not exist in the other MS Cloud Offerings.

Enterprise Agreement (see [7]) / Enterprise Portal (see [21]): An Enterprise Agreement (EA) falls under the Microsoft Products and Services Agreement (MPSA) and provides for licensing of software and services through a single agreement. This agreement contractually locks a company into a 36-month agreement and requires them to “true-up” their licenses each year. The EA is designed for companies with 250+ seats (changing to 500+ in July 2016) who want to standardize their Microsoft products, have the rights for the most-current version of the software, and only want to account for additional seats once a year.
Via the Enterprise Agreement Microsoft also gives customers access to the Azure Enterprise Portal, a resource for customers managing multiple accounts or subscriptions. The following hierarchy elements can be managed in the enterprise portal:

Management Group (GA Mid 2018): Azure management groups provide a level of scope above subscriptions. Subscriptions are organized into containers called "management groups" and governance conditions: policies & RBAC (Role Based Access Control) can be applied to these management groups. All subscriptions within a management group automatically inherit the conditions applied to the management group. Management groups give enterprise-grade management at a large scale no matter what type of subscriptions the user might have.

Azure Resource Manager (see [21]): Azure Resource Manager is the deployment and management service for Azure. Azure Resource Manager enables you to work with the resources (virtual machine, storage account, and virtual network, or a web app, etc.) in your solution as a group. You can deploy, update, or delete all the resources for your solution in a single, coordinated operation. You use a template for deployment and that template can work for different environments such as testing, staging, and production. Resource Manager provides security, auditing, and tagging features to help you manage your resources after deployment.
See []: Azure originally provided only the classic deployment model. In this model, each resource existed independently; there was no way to group related resources together. Instead, you had to manually track which resources made up your solution or application, and remember to manage them in a coordinated approach. In 2014, Azure introduced Resource Manager, which added the concept of a resource group. A resource group is a container for resources that share a common lifecycle. To simplify the deployment and management of resources, Microsoft recommends that you use Resource Manager for all new resources. If possible, Microsoft recommends that you redeploy existing resources through Resource Manager. ONLY Cloud Services1 does not support Resource Manager deployment model and therefore I recommend not to use it but instead use azure app services, otherwise the complexity of deployment and management increases significantly when mixing 2 deployment models.
    1. a.Define and deploy your infrastructure through the declarative syntax in Resource Manager templates, rather than through imperative commands. 

    2. b.Define all deployment and configuration steps in the template. You should have no manual steps for setting up your solution. 

    3. c.Run imperative commands to manage your resources, such as to start or stop an app or machine. 

    4. d.Arrange resources with the same lifecycle in a resource group. Use tags for all other organizing of resources. Best Practice

Azure enterprise scaffold - prescriptive subscription governance (see [23]): The following image describes the components of the scaffold. The foundation relies on a solid plan for departments, accounts, and subscriptions. The pillars consist of Resource Manager policies and strong naming standards. The rest of the scaffold comes from core Azure capabilities and features that enable a secure and manageable environment:


Illustration 7: Azure Scaffold


Azure Enrollment Patterns: Based on the hierarchy diagrams shown in the previous chapter, Microsoft suggests three common patterns for Azure Enrollments

The functional pattern

The business unit pattern

The geographic pattern


Illustration 8: Functional Pattern


Illustration 10: Geographic Pattern



But two important hierarchy levels were forgotten when drawing these 3 different patterns: “management group (GA mid 2018) andresource group” (which was introduced with the new deployment model in 2014). These additional layers above respective below a subscription especially support organizations that have no Enterprise Agreement and therefore no possibility to group their subscription on: Enterprise, Department and Account level. The resource group is predestined to group related resources to an application respective solution – see pros and cons below.

Management Group & Resource Group “Pattern”: Applying management groups and resource groups to a functional, geographic or business unit pattern (for organizations that have no enterprise agreement) the result could look as follows:




Illustration 11: Functional, Geographic, Business Unit Pattern (for organizations that have no enterprise agreement)


Pros and Cons of having applications respective solutions grouped on resource group level (and not on subscription level):

Recommendation: Resource Group per Application: Based on the arguments listed above the recommendation is to use one resource group per application and to use different subscriptions only where we need to enforce a separation on billing level, where we need to overcome subscription limitations and/or where we require different AADs respective IAMs for different application (groups)!

Azure Best Practices Example: Contoso Corporation: Subscriptions, Licenses and User Accounts: See [28]:

Contoso Corporation:  Subscriptions, Licenses and User Accounts

Contoso Corporation: Azure Enterprise Hierarchy


  Naming Convention

Before defining a naming-convention the following should be considered:

Element/Application/Solution characteristics and definition – see ...:

Element/Application/Solution: Structure (Interface), Behavior: Every element (application, solution, artifact, module, component, work-product, etc.) is declared and defined through its structure and behavior. The structure consists of an external and an internal part. The external part is called the interface and is exposed externally for interaction whereas the internal part can only be accessed internally.

Element: Composition: Atomic Element: Elements are normally composed of other elements and the way they are composed determines their structure and behavior. Some elements are contained in respective internal part of the composition and accordingly deployed together with the composed element while other elements are located outside respective external to the composition, can be shared between different instances, copies and potentially different compositions and are not necessarily deployed together with the composition. Furthermore some elements are exclusively dedicated for this composition while others can be reused in other compositions. Elements that are exclusively dedicated for this composition have the same life-cycle as the composed element whereas elements reused in other compositions have an own life-cycle driven by the compositions where they are used. The composition ends once we reach the atomic element level. Through composition new elements are created.

Scope and Version convention – see …:

While versioning is a well known and established concept it only covers the time-dimension related validity of an element/application/solution/work-product/etc. and is often not enough to differentiate similar, coexisting elements that have the same purpose and were therefore given the same name respective identifierentirely comprise its validity. Therefore further dimensions respective scopes are required to comprise & describe the boundaries & validity of an element. These dimensions respective scopes enable the differentiation and comprehensive realization of concepts like: multi-client capability (Mandantefähigkeit), language support, etc.
Element boundaries are based on the elements they consist of (composition) and the scope of the (group of) people creating and modifying the element. Structure and behavior They determine whether other elements (composition) and/or people can use it or not. To differentiate elements with the same name respective the same point of origin and purpose also known as element branches, two identifiers (IDs) are used: Version ID and Scope ID. The version ID helps to differentiate changes done by the same (group of) people over time whereas the scope ID helps to differentiate changes done by different (groups of) people (at the same time)

Element: Scope: The structure and behavior of an element have a certain scope they cover respective boundaries they are restricted to and this scope correlates to the “scope” of the group of people i.e. (their mindsetcapabilities specifying, designing and implementing the element. The people specifying the requirement say WHAT they want and the people designing and implementing the element decide HOW it's done. This (build-time) scope information should be assigned to the element to differentiate it from other elements that have the same name respective the same point of origin and serve the same purpose but that were specified, designed and implemented by a different group of people2. This scope information is then used during build- respective run-time to determine whether it matches the scope of the related elements (composition) respective user and to be able to act accordingly. In addition the people specifying, designing and implementing the element together with their function: business analyst, requirements engineer, architect, developer, etc. and time-stamp of last modification could be assigned to the element as well. The time-stamp of last modification is required to retrieve the scope of the people at the time they specified, designed and implemented the element. This function-holder information cannot replace the scope information because the scope of the function-holders normally is larger and only a part of it is realized into the element during specification, design and implementation.

Based on the azure best practices naming-conventions in [29] I’ve done some modifications and extensions that can be found below.

Domain Name: Most resources have a (dynamic) IP address and a corresponding DNS entry how they can be reached. Therefore all names should follow the DNS naming convention – see :

Hyphen “-” and double Hyphens “--”:  Besides the dot “.” which has a special meaning the only character that can be used for separation of words is the hyphen “-” character. In order to be able to copy an artifact/resource to a different location and/or naming system without conflicts respective collisions the company / organization name plus all (relevant) parts of the FQN should be prepended or appended to the artifact name. This adds redundancy (duplication) to the final FQN but enables the element to be copied to other directories and/or naming systems without naming conflicts respective collisions. In order to be able to prepend or append the FQN nodes the path-delimiters need to be replaced with (double) word-delimiters i.e. double hyphens “--”.

Multi Entity Capability / scope:  Based on the multi-entity-capability respective scope description in [39]Error: Reference source not found, “the structure and behavior of an element have a certain scope they cover respective boundaries they are restricted to and this scope correlates to the “scope” of the group of people (their mindset) specifying, designing and implementing the element. This scope information should be assigned to the element to differentiate it from other “identical” elements i.e. elements serving the same purpose but that were specified, designed and implemented by a different group of people. This scope information is then used during run-time to determine whether it matches the scope of the user and to be able to act accordingly.Therefore this scope information should be part of the element name to differentiate it from other “identical” elements i.e. elements with the same name that are serving the same purpose but that were specified, designed and implemented by a different group of people.

Versioning: During build-time (modification cycle) the structure, behavior and/or scope of an element respective artefact change. Therefore an element should have a version assigned to differentiate it from other coexisting elements that have the same point of origin and serve the same purpose but due to changes have different structure, behavior and/or scope.

Composition: Normally an application is composed of several artifacts respective elements.

The resulting resource name looks as follows: organizationName“--”applicationName”--s”majorScopeId”-v”majorVersionNumber[”--”useCase]

Based on the best practices in the previous chapter I suggest to include Notes

Microsoft Cloud Administration & Portals: The different hierarchy elements for the different cloud offerings are administered using different web portals:

PaaS: Custom Domain Names (CDN): Limited: Only a few Azure PaaS components support custom domain names (CDN) (Q2 2018: Azure Cloud Service, Azure Web Apps, Azure Blob Storage).

2.3.3. Processes Sign-up


Sign up for Azure as an organization:



3. Security

Microsoft Cloud Security: See [Microsoft Cloud Security for Enterprise Architects:]: The security of the Microsoft cloud services is a partnership between the customer (C) and Microsoft (MS).






Security strategy, governance, and operationalization: Provide clear vision, standards, and guidance for your organization.

  • Develop cloud security policies: Document security policies, Balance security and usability, Document protocols and processes, Embrace “Shadow IT”. 

  • Manage continuous threats: Establish operational capabilities (monitor, investigate & initiate), Build external context (threat intelligence feeds, Information Sharing and Analysis Centers (ISACs)), Validate your security posture (authorized red team see White paper: Microsoft Enterprise Cloud Red Teaming: and/or penetration testing) 

  • Manage continuous innovation: Define a monthly cadence, Prevent configuration drift with periodic reviews (stay in compliance with your policies and protocols) 

  • Contain risk by assuming breach: Identifying your most critical assets, Enhancing isolation between security zones (increase rigor of exception management, apply threat modeling techniques to all authorized exceptions), Focus containment within a security zone (preserving integrity of the administrative model rather than on network isolation) 





Administrative control: Defend against the loss of control of your cloud services and on-premises systems

  • Least privilege admin model: Limit the number of administrators or members of privileged groups, Delegate less privileges to accounts, Provide privileges on demand, Have existing administrators perform tasks, Provide processes for emergency access 

  • Harden security dependencies: Security dependencies for cloud services commonly include identity systems 

  • Use strong authentication: Use credentials secured by hardware, Multi-Factor Authentication (MFA), and conditional access for all identities with administrative privileges 

  • Use dedicated admin accounts and workstations: Use dedicated accounts for privileged administrative roles, Use dedicated, hardened workstations for administration, Do not use high privilege accounts on devices where email and web browsing take place 

  • Enforce stringent security standards: Rigorously measure and enforce stringent security standards on administrative accounts and systems 

  • Monitor admin accounts: And configure alerts. See: What is conditional access in Azure Active Directory? 

  • Educate and empower admins 

Data: Identify and protect your most important information assets: Establish information protection priorities, Protect High Value Assets (HVAs), Find and protect sensitive assets, Set organizational minimum standards

User identity and device security: Strengthen protection of accounts and devices:

  • Use Strong Authentication: Use credentials secured by hardware or Multi-Factor Authentication (MFA) for all identities. 

  • Manage trusted and compliant devices: Apply configuration standards and rapidly install security updates. See Identity and device access configurations: 

  • Educate, empower, and enlist users: Educate users on likely threats and their role in protecting business data, Increase adversary cost to compromise user accounts, Explore gamification 

  • Monitor for account and credential abuse: detect anomalous activity of an account. 





Application security: Ensure application code is resilient to attacks:

  • Secure applications that you acquire: Review the security development processes and operational practices of vendors, follow security configuration guidance and recommendations provided by the vendor, apply all vendor security updates, discontinue your use of software before it reaches end of support status 

  • Follow the Security Development Lifecycle (SDL) 

Network: Ensure connectivity, isolation, and visibility into anomalous behavior:





Microsoft Security Certifications:

Microsoft Cloud Security for Enterprise Architects: What is an Azure AD directory?

What is Azure Active Directory?

Microsoft Cloud Identity for Enterprise Architects:

3.1. Identity Management & Authentication

Microsoft Cloud Identity & Azure Active Directory: See [Microsoft Cloud Identity for Enterprise Architects:]: Integrating your identities with the Microsoft cloud provides access to a broad range of services and applications. Azure Active Directory (Azure AD) integration provides:

(*) - these features are only available in AAD Basic and Premium edition – furthermore only available in these editions: “Group-based access management and provisioning”, “Self-service password reset for cloud users”, “Company branding (logon pages, Access Panel customization)”, “Enterprise SLA of 99.9%”

(**) - these features are only available in AAD Premium edition – furthermore only available in this edition: “Self-service group and app management, self-service application additions, dynamic groups”, “Self-service password reset, change, unlock with on-premises write-back”, “MIM CAL + MIM Server”, “Automatic password rollover for group accounts”

User Account (see [14]): Microsoft Account (Microsoft Live ID) versus Work / School Account (see [14]): There exist two types: a Microsoft account (formerly known as Microsoft Live ID) and a work or school account, which is an account stored in Azure AD.
Although Azure originally allowed access only by Microsoft account users, it now allows access by users from both systems. This was done by having
all the Azure properties trust Azure AD for authentication, having Azure AD authenticate organizational users, and by creating a federation relationship where Azure AD trusts the Microsoft account consumer identity system to authenticate consumer users. As a result, Azure AD is able to authenticate “guest” Microsoft accounts as well as “native” Azure AD accounts.
ut basically users can be added

Authentication: Azure Active Directory (AAD) versus Proprietary: All MS SaaS solutions support AAD based authentication. Regarding PaaS we have to differentiate between Management Access and Data Access – see .… All Management Access is authenticated against AAD whereas Data Access is often authenticated proprietary in the corresponding component itself.

Using Work or School Accounts Frequently Asked Questions (FAQ):

Merge office365 and live accounts that use the same email address:

Work account vs Microsoft account: how to use them properly? OneNote:

Add new users or users with Microsoft accounts to Azure Active Directory:

Add users from other directories or partner companies in Azure Active Directory:


Compare B2B collaboration and B2C in Azure Active Directory:


Making Office 365 Work with an External SAML Identity Provider:

Use a SAML 2.0 identity provider to implement single sign-on:



Authorize access to web applications using OAuth 2.0 and Azure Active Directory:

What is application access and single sign-on with Azure Active Directory?

Customizing claims issued in the SAML token for pre-integrated apps in Azure Active Directory:

Authentication Scenarios for Azure AD:

Azure AD token reference:


Microsoft Graph or the Azure AD Graph:

Azure AD Graph API reference:


3.1.1. Login PowerShell

Perform the following steps to login with PowerShell:

  1. 1.Precondition: PowerShell ist installed see chapter 4.1. 

  2. 2.Sign in to the Azure portal: Login-AzureRmAccount  

    1. a.Click “N” and do not allow to start data collection: 

    2. b.Login: 

    3. c.Password: E... 

PS C:\Users\raoul-becke--s0-v1> Login-AzureRmAccount

WARNING: Microsoft Azure PowerShell collects data about how users use PowerShell cmdlets and some problems they encounter.  Microsoft uses this information to improve our PowerShell cmdlets.  Participation is voluntary and when you choose to participate your device automatically sends information to Microsoft about how you use Azure PowerShell.

If you choose to participate, you can stop at any time by using Azure PowerShell as follows:

1. Use the Disable-AzureDataCollection cmdlet to turn the feature Off. The cmdlet can be found in the AzureRM.Profile


To disable data collection: PS > Disable-AzureDataCollection

If you choose to not participate, you can enable at any time by using Azure PowerShell as follows:

1. Use the Enable-AzureDataCollection cmdlet to turn the feature On. The cmdlet can be found in the AzureRM.Profile


To enable data collection: PS > Enable-AzureDataCollection

Select Y to enable data collection [Y/N]:

WARNING: You choose not to participate in Microsoft Azure PowerShell data collection.

WARNING: The setting profile has been saved to the following path 'C:\Users\raoul-becke—s0-v1\AppData\Roaming\Windows Azure Powershell\AzureDataCollectionProfile.json'.



Environment           : AzureCloud

Account               :

TenantId              : af081cc6-...

SubscriptionId        : 35dc9a55...

SubscriptionName      : Pay-As-You-Go

CurrentStorageAccount :


  1. 3.Do a quick check that everything is OK: View all the subscriptions for this account: Get-AzureRmSubscription 

PS C:\Users\raoul-becke--s0-v1> Get-AzureRmSubscription

Name     : Pay-As-You-Go

Id       : 35dc9a55-...

TenantId : af081cc6-...

State    : Enabled



3.2. Access Management & Authorization

Subscription & Access Control (see [15]): Access control in Azure starts from a billing perspective:

Directory Users & Roles: As with subscription administrators, the Azure AD administrative roles can be either Microsoft accounts or work or school accounts. Azure AD administrative roles are also used by other services such as Office 365 and Microsoft Intune. Azure subscription admins can manage resources in Azure and can view the Active Directory extension in the Azure classic portal (because the Azure classic portal is an Azure resource). Directory admins can manage properties in the directory. Azure AD has a different set of administrative roles to manage the directory and identity-related features – see [19] (important roles are underlined or bold, deprecated or reserved roles are strike-through): “Billing Administrator”, “Compliance Administrator”, “Conditional Access Administrator”, “CRM Service Administrator”, “Device Administrators”, “Directory Readers”, “Directory Synchronization Accounts”, “Directory Writers”, “Exchange Service Administrator”, “Global Administrator / Company Administrator”, “Guest Inviter”, “Intune Service Administrator”, “Mailbox Administrator”, “Partner Tier 1 Support”, “Partner Tier 2 Support”, “Password Administrator / Helpdesk Administrator”, “Power BI Service Administrator”, “Privileged Role Administrator”, “Security Administrator”, “Security Reader”, “Service Support Administrator”, “SharePoint Service Administrator”, “Skype for Business / Lync Service Administrator”, “User Account Administrator”  .


Get started with Role-Based Access Control in the Azure portal:

Built-in roles for Azure Role-Based Access Control:

Create custom roles for Azure Role-Based Access Control:


Add or change Azure administrator roles that manage the subscription or services:

Transfer ownership of an Azure subscription to another account:

About Office 365 admin roles:

Assign admin roles in Office 365:


3.2.1. Group Management

Groups in the MS Cloud: see [ ]: Create Group

We create a new security group (NOT office 365 group) containing the DB Administrators:

One of the features of Azure Active Directory (Azure AD) user management is the ability to create groups of users. You use a group to perform management tasks such as assigning licenses or permissions to a number of users at once. You can also use groups to assign access permission to

Membership Type: “Assigned”

Dynamic memberships for groups require an Azure AD Premium license to be assigned to

Enable Office features? NO

Make sure you don’t select the “Enable Office features” when creating the group. In that case it’s not a security group and you won’t be able to select this group when setting the licenses.

The Azure AD Admin UI allows you to create the following:


And add the DB AD Admin User to this group.


3.2.3. Database

This chapter is related to the steps described in the chapter database in appendix document [38] Error: Reference source not found. Azure Active Directory Admin

Azure Active Directory admin: One Azure Active Directory account, either an individual or security group account, can also be configured as an administrator. It is optional to configure an Azure AD administrator, but an Azure AD administrator must be configured if you want to use Azure AD accounts to connect to SQL Database. For more information about configuring Azure Active Directory access, see Connecting to SQL Database or SQL Data Warehouse By Using Azure Active Directory Authentication ( ) and SSMS support for Azure AD MFA with SQL Database and SQL Data Warehouse ( ).

Precondition is that a corresponding group has already been created see chapter

  1. 1.Open database server: becke-ch--app--s0-v1