In this blog I like to describe some technical steps we may experience in a transition to Microsoft cloud. In this blog I use a virtual company that want to adopt cloud for the transformation and improvements of ICT and decided to utilize modern workspace cloud capabilities for their employees provided by Microsoft.
What is our use case?
A company with two divisions, where division-2 is a separate organization that is added to the company not very long ago. Both divisions still has their separate ICT and there is no trust relationship between existing AD forests. Users experience with this scenario is not very good, having multiple identities, email accounts, etc.. working for both divisions.
How do we get there?
With that in mind, now take a quick look at the adoption path we leveraged for the transformation. Be aware, there is no single cloud adoption path that works for every organization. But overall, the basics are quite similar and Microsoft guide you through this process.
The transformation in our case is divided in three phases which overlap one another at some point or even run parallel. The phases I used for this transformation will be: Learn, Deploy and Adopt.
The first “Learn” phase mainly focuses on learning and experiencing the Microsoft cloud capabilities (like: Exchange, One-drive, Teams and Office SAAS products). In this phase all environments are still separate from one another and we are using cloud identities for a small group of users.
In the second phase “Deploy” we are moving on to production scale, connecting the environments to make a full transition to Microsoft cloud solutions possible including the migration of data to the Microsoft data-centers.
The last one is the “Adopt” phase. This phase provide enhancements to the cloud solutions and resources deployed for the organization. This phase re-evaluate already deployed services and provide further enhancements, for example with: content/device management, the modernizing of current application services, or even plan for third party (cloud) services.
All phases are coordinated from out of a Cloud Center of Expertise (CCoE) working on governance, coaching end-users and supporting the deployment of the Microsoft capabilities within the divisions.
Note: The phases I briefly described have Fast-Track basics and are from a technical perspective. Of course, adopting (Microsoft) Cloud solutions is certainly not a technical only transition, it will most likely change IT procurement and support processes for your organization and the way end-users are productive.
Let the fun start!
So finally, we are at a point to work out a few steps related to the “Learn” phase. Many companies already experience the “Learn” or even the “Deploy” phases, but in our case we are going to look at Role Based Access Control (RBAC) and using a custom domain for the company brand.
At this stage we are signed-up for Microsoft 365 services creating a default Azure tenant utilizing a public account (like outlook.com) with two-factor-authentication. It is sustainable using a name context for the public account that is related to the organization when creating the tenant, rather than using an named account of some employee.
Note: Always handle privilege accounts with care using some sort of privilege account management (PIM). I leave the PIM topic for now, but if you like to know more read the section “additional reading” at the end of this blog.
Now we are off to add a custom domain and some administrators to the Azure tenant. We manage these steps by using powershell, but before we run the commands we need a few things:
- A device (workstation/laptop) that has a connection to internet.
- The ID(GUID) of the default tenant we signed-up before.
- To install AAD PowerShell modules MSOL (Version1) and AzureAD (Version2).
- To have access to DNS for creating a TXT record that allow us to verify the domain name.
And now hands-on...
During the install of the modules on our device, we are connecting to the PS-repo and must confirm if we trust the NuGet provider to be installed. Also we check if powershell is using TLS12 protocols, otherwise the installation of the modules will fail. Run cmdlet:
If the check returns a TLS only value, run:
[PS]..> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Now we only need to install the modules by running the next command and we are good to go: [PS]..> Install-module MSonline, AzureAD -verbose
At this point we made our preparations for the next steps. With the first step we are going to configure a custom domain for which we need to connect to Azure-AD. Thereafter we run some powershell code to create new cloud identities for the administration roles related to the (virtual)person(s) who is responsible for the job.
Note: I can imagine your question why not simply leverage the Microsoft portals? Yes, of course we can leverage the portals too, but I like to show you this using powershell.
The next command is configuring a custom domain and the output shows us the DNS value for a TXT record we need to create in the DNS zone for the custom domain.
[PS]..> Write-host (Get-AzureADDomainVerificationDnsRecord -Name $domain.name | Where-object {$_.recordtype -eq “txt”}).text
Using the text from the command line we need to add a TXT record in the DNS domain zone so, Microsoft can verify if I am the owner of this domain before we proceed adding the company and service admin(s). The record we did add should look like this: “@ MS=ms26741089 3600 corpxyz.com”
Some simple powershell code to..
With the following simple powershell code, we are assigning the administration roles to new cloud Identities. We are assigning the roles in order of a “company administrator” and second, repeating the step running the code, the administrators for the services.
Note: It is recommended to keep top-level administrators to a minimum, for our case we create just one additional “company administrator” account next to the public account.
param(
[Parameter(Mandatory = $true)]
[string]$adminrole,
[Parameter(Mandatory = $true)]
[string]$tenantID,
[Parameter(Mandatory= $true)]
[security.securestring]$password,
[Parameter(Mandatory = $true)]
[string]$upn,
[Parameter(Mandatory = $true)]
[string]$alias,
[Parameter(Mandatory = $true )]
[string]$displayname
)
# logon to Azure
Connect-AzureAD -TenantId $tenantID -Verbose
# create cloud identity and assign admin role
$passwordprofile = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile
$passwordprofile.Password = $password
$roleID = (Get-AzureADDirectoryRole | Where-object {$_.displayname -eq $adminrole }).objectID
IF ($roleID -eq $null) {
Write-host "Default Role definition not found, enable new role definition"
$roleTmpl = (Get-AzureADDirectoryRoleTemplate | Where-object {$_.displayName -eq $adminrole}).ObjectId
Enable-AzureADDirectoryRole -RoleTemplateId $roleTmpl
$roleID = (Get-AzureADDirectoryRole | Where-object {$_.displayname -eq $adminrole}).objectID
}
$usrID = (New-AzureADUser `
-UserPrincipalName $upn `
-AccountEnabled $true `
-DisplayName $displayname `
-PasswordProfile $passwordprofile `
-MailNickName $alias).objectID
Add-AzureADDirectoryRoleMember -ObjectId $roleID -RefObjectId $usrID
# logoff from Azure
Disconnect-AzureAD -Verbose
# clear used variables
$passwordprofile = $null
$roleID = $null
$roletmpl = $null
$usrID = $nullAdditionally, we are now specifying the administrators for the services supported by Azure-AD. For example, create an additional administrator for service support.
A you can see at the figure below the code runs are successful and we did create the administrators. The powershell commands shows an overview of the assigned roles looking at the Azure-AD.
Summary.
With the creation of the administrators I am at the end of this blog session. In this blog we did briefly look at the path used for our transformation, from a technical perspective. Thereafter we configure a custom domain and assigned Role Based Access Control (RBAC) to new cloud identities .
I’m happy to work on this use case and in my next blog I like to show you some more steps belonging to the described phases.
I’ll hope you enjoy reading..
Additional reading:
Office 365 deployment Guide.
Azure Privilege Identity Management.
Beyondtrust Privilege Account & Session Management.
anevci.nl 