Tag Archives: Azure

Step-by-Step guide to manage Azure Storage using Azure CLI 2.0 – Part 02

This is last part of my blog post series which is covering Azure CLI 2.0 functions. If you didn’t read part 01 yet please read it before start on this. You can find it on http://www.rebeladmin.com/2017/10/step-step-guide-manage-azure-storage-using-azure-cli-2-0-part-01/ 

In my demo setup, I have two VM running. One is created using Azure Managed disks. In part 01 I explained how to add additional disk. It is currently having a 100GB additional disk attached. 

Expand Disks

Let’s see how we can expand disks using Azure CLI. Before do this, make sure you log in to Azure CLI using az login

let’s start with expanding azure managed disks. First, we can verify the VM’s storage configuration using, 

az vm show --resource-group rebeladminrg01 --name REBLEVM101

clistore1

In there I have two disks. One is for OS called osdisk_6469626e28 and the other data disk called DataDisk01

We can’t increase the disk on a running VM. Not even a data disk. So first we need to deallocate the VM. We can do it using. 

az vm deallocate --resource-group rebeladminrg01 --name REBLEVM101

in above command –resource-group defines resource group VM belongs to. –name defines the VM name. 

clistore2

once it is completed we can increase the disk sizes. 

I need to expand os Disk size to 150 GB. I can do it using,

az disk update --resource-group rebeladminrg01 --name osdisk_6469626e28 --size-gb 150

clistore3

I also like to expand data disk to 150 GB. I can do it using,

az disk update --resource-group rebeladminrg01 --name DataDisk01 --size-gb 150

clistore4

in above commands, –resource-group defines resource group disks belongs to. –name defines the disk’s name. 

after finish, we can start the VM using,

az vm start --resource-group rebeladminrg01 --name REBLEVM101

once VM is up we can go in and expand the disk in OS level. 

clistore5

if you looking to expand disk for unmanaged disks it can be done via interface or Azure CLI 1.0. more info can find in https://docs.microsoft.com/en-us/azure/virtual-machines/linux/expand-disks-nodejs

the document itself for Linux vm but expand part work same way. 

Snapshots

We also can take snapshots of disk as quick recovery option. It is full copy of a disk in the time it’s taken. It can keep as a backup or attach to another machine for troubleshooting. 

In my demo, I am going to take snapshot of an azure managed OS disk. Before do that I need to find the disk ID. It can be done using

az vm show --resource-group rebeladminrg01 --name REBLEVM101

clistore6

then we can take snapshot using,

az snapshot create -g rebeladminrg01 --source "/subscriptions/xxxxx/resourceGroups/REBELADMINRG01/providers/Microsoft.Compute/disks/osdisk_6469626e28" --name vm101osDisk-backup

clistore7

in above –source defines the disk id and –name defines the snapshot name.

if it is a unmanaged disk, snapshot works on different way. You can read more about it from https://docs.microsoft.com/en-us/azure/virtual-machines/linux/incremental-snapshots 

Convert to Managed Disks

if required we can convert vm with unmanaged disks to managed disk. To do that first we need to deallocate the VM.

az vm deallocate --resource-group rebeladminrg01 --name REBELVM102

then we can start the converting process using,

az vm convert --resource-group rebeladminrg01 --name REBELVM102

once process is finished it will start the VM. 

clistore8

clistore9

Manage blobs

We also can create, manage and delete blobs using Azure CLI. 

To create a container we can simply use,

az storage container create --name datastorage01 --connection-string "DefaultEndpointsProtocol=https;EndpointSuffix=core.windows.net;AccountName=rebelstorage01;AccountKey=xxxxxxx/ixi+FKRr3YUS9CgEhCciGVIyI9+6CtqjTIiPvbXkmpFDK9sINE28jdbIwLLOUZyiAtQ3Edzx2y89RPQ=="

in above –name defines the container name. AccountName specify the storage account name and AccountKey specify the auth key for the storage account. 

By default, the container data is set to private. If need it can set to public read access for blobs (blob) or public read and list access to whole container (container). It can define using –public-access

Once container is created we can upload blob using,

az storage blob upload --file C:\myzip1.zip --container-name datastorage01 --name myzip1.zip --connection-string "DefaultEndpointsProtocol=https;EndpointSuffix=core.windows.net;AccountName=rebelstorage01;AccountKey=xxxxxx/ixi+FKRr3YUS9CgEhCciGVIyI9+6CtqjTIiPvbXkmpFDK9sINE28jdbIwLLOUZyiAtQ3Edzx2y89RPQ=="

in above, –file defines the local file path. –container-name defines the container name it is uploading to. –name defines the blob name once it is uploaded. 

clistore10

to verify, we can list down the files in blob using,

az storage blob list --container-name datastorage01 --output table --connection-string "DefaultEndpointsProtocol=https;EndpointSuffix=core.windows.net;AccountName=rebelstorage01;AccountKey=xxxxxx/ixi+FKRr3YUS9CgEhCciGVIyI9+6CtqjTIiPvbXkmpFDK9sINE28jdbIwLLOUZyiAtQ3Edzx2y89RPQ=="

clistore11

we can download blob to local storage using,

az storage blob download --container-name datastorage01 --name myzip1.zip --file C:\myzip2.zip --connection-string "DefaultEndpointsProtocol=https;EndpointSuffix=core.windows.net;AccountName=rebelstorage01;AccountKey=xxxx/ixi+FKRr3YUS9CgEhCciGVIyI9+6CtqjTIiPvbXkmpFDK9sINE28jdbIwLLOUZyiAtQ3Edzx2y89RPQ=="

in above, –file defines the path and name it will have when downloaded to the local storage.

clistore12

we can delete a blob using command similar to,

az storage blob delete --container-name datastorage01 --name myzip1.zip --connection-string "DefaultEndpointsProtocol=https;EndpointSuffix=core.windows.net;AccountName=rebelstorage01;AccountKey=1WzgTd/ixi+FKRr3YUS9CgEhCciGVIyI9+6CtqjTIiPvbXkmpFDK9sINE28jdbIwLLOUZyiAtQ3Edzx2y89RPQ=="

clistore13

This marks the end of the blog post and hope it was useful. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Step-by-Step guide to manage Azure Storage using Azure CLI 2.0 – Part 01

This is another part of my blog post series which was covering Azure CLI 2.0 functions. If you not read those yet you can find it with following links.

Step-by-step guide to start with azure cli 2.0http://www.rebeladmin.com/2017/08/step-step-guide-start-azure-cli-2-0/

Step-by-step guide to create azure vm using azure cli 2.0http://www.rebeladmin.com/2017/08/step-step-guide-create-azure-vm-using-azure-cli-2-0/

In part 01 of this blog post, we are going to look in to managing disks using Azure CLI. 

First thing first, I am going to log in to Azure CLI with a privileged account. This can be done using az login

I have a windows VM setup under my subscription. I can view its details using az vm show --resource-group rebeladminrg01 --name REBLEVM101

In above --resource-group defines the resource group name and –name defines the VM name. 

sto1

In this VM, I have a disk with size of 128 GB. It is azure managed disk. 

sto2

I like to add couple of disks in to this VM. Adding “Azure Managed” disk is the simplest way. It simplifies the disk management process. The only thing you need to worry is disk type and size. 

az vm disk attach -g rebeladminrg01 --vm-name REBLEVM101 --disk DataDisk01 --new --size-gb 100

above creates a managed disk called DataDisk01 under rebeladminrg01 resource group. it is 100 GB in size. It also attached to REBLEVM101 VM.

We can verify it by running,

az disk show --name DataDisk01 --resource-group rebeladminrg01

sto4

if need we can also use “unmanaged” disks. First, I am going to create a new storage account for it. 

az storage account create --location westus --name rebelstorage01 --resource-group rebeladminrg01 --sku Standard_LRS

sto5

above creates a storage account called rebelstorage01 under westus region. Its created under rebeladminrg01 resource group. its Standard_LRS storage. 

Before configure the storage, first we need to set environment variables so the it can be use with commands. 

To do that need to type

az storage account show-connection-string --name rebelstorage01 --resource-group rebeladminrg01

then copy the connection string value and use it with

az storage container create --name data --connection-string "DefaultEndpointsProtocol=https;EndpointSuffix=core.windows.net;AccountName=rebelstorage01;AccountKey=oJOjFskwKlDBisEiGREBEsMRWnDbOA+q6stySqXKT1MsBiPZeJPThnfnkGgG9AgudKmJ/5CCl65cGcMIAZGQhg=="

above will create a container called data under the storage account. 

Let’s go ahead and add a new unmanaged disk to a VM. 

Note – You cannot add unmanaged disk to a VM created with managed disk. 

az vm unmanaged-disk attach -g rebeladminrg01 --vm-name REBELVM3 --new -n DataDisk6 --vhd-uri https://rebelstorage01.blob.core.windows.net/data/2.vhd --size-gb 100

in above rebeladminrg01 is the resource group where azure VM located. REBELVM3 is the VM name. I am creating a new disk called DataDisk6 on data/2.vhd path. Its size is 100 GB. 

sto6

In order to detach disk from VM we can use following commands. 

If its unmanaged disk we can use,

az vm unmanaged-disk detach --name DataDisk6 --resource-group rebeladminrg01 --vm-name REBELVM3

above command will detach unmanaged disk called DataDisk6 from REBELVM3 VM.

sto7

If its managed disk we can use,

az vm disk detach -g rebeladminrg01 --vm-name REBLEVM101 -n DataDisk02

above will remove data disk called DataDisk02 from REBLEVM101 VM.

sto8

This is the end of the part 01 of this post. Hope this was useful and if you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts.

Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO)

I am sure most of you aware what is single sign-on (SSO) in Active Directory infrastructure and how it works. When we extend identity infrastructures to Azure by using Azure AD, it also allows to extend Single Sign-On capabilities to authenticate in to cloud workloads. it can be done using on-premises ADFS farm. Password Hash Synchronization or Pass-through Authentication allow users to use same user name and password to log in to cloud applications but this is not a “Seamless” access. Even they are using same user name and password, when log in to Azure workloads it will prompt for password. 

In my below example, I have an Azure AD instance integrated with on-premises AD using Pass-through Authentication. In there I have a user R272845. I logged in to a domain joined computer with this user and try to access application published using Azure. when I type the URL and press enter, it redirects me to Azure AD login page.

sso1

sso2

Azure Active Directory Seamless Single Sign-On is a feature which allow users to authenticate in to Azure AD without providing password again when login from domain join/ corporate device. This can be integrated with Password Hash Synchronization or Pass-through Authentication. This is still on preview which means cannot use in production environment yet. However, if it doesn’t work in environment, it will always issue the typical Azure AD authentication page, so it will not prevent you from accessing any application. This feature is not supported if you using ADFS option already.

According to Microsoft, following can list as key features of Azure Active Directory Seamless Single Sign-On (Azure AD Seamless SSO)

Users are automatically signed into both on-premises and cloud-based applications.

Users don't have to enter their passwords repeatedly.

No additional components needed on-premises to make this work.

Works with any method of cloud authentication – Password Hash Synchronization or Pass-through Authentication.

Can be rolled out to some or all your users using Group Policy.

Register non-Windows 10 devices with Azure AD without the need for any AD FS infrastructure. This capability needs you to use version 2.1 or later of the workplace-join client.

Seamless SSO is an opportunistic feature. If it fails for any reason, the user sign-in experience goes back to its regular behavior – i.e, the user needs to enter their password on the sign-in page.

It can be enabled via Azure AD Connect.

It is a free feature, and you don't need any paid editions of Azure AD to use it.

It is supported on web browser-based clients and Office clients that support modern authentication on platforms and browsers capable of Kerberos authentication

According to Microsoft, following environments are supported. 

OS\Browser

Internet Explorer

Edge

Google Chrome

Mozilla Firefox

Safari

Windows 10

Yes

No

Yes

Yes, additional config required

N/A

Windows 8.1

Yes

N/A

Yes

Yes, additional config required

N/A

Windows 8

Yes

N/A

Yes

Yes, additional config required

N/A

Windows 7

Yes

N/A

Yes

Yes, additional config required

N/A

Mac OS X

N/A

N/A

Yes

Yes, additional config required

Yes, additional config required

The current release (at the time this blog post was written) do not support edge browser. Also this feature will not work when users use private browser mode on Firefox or when users have Enhanced Protection mode enabled in IE. 

How it works?

Before we look in to configuration, let’s go ahead and see how it’s really works. In following example, user is trying to access cloud based application (integrated with azure) using his on-premises username, password and domain joined device. 

Also, it is important to know what happen in corporate infrastructure when seamless SSO enabled.

System will create AZUREADSSOACCT computer object in on-premises AD to represent Azure AD

AZUREADSSOACCT computer account’s Kerberos decryption key is shared with Azure AD.

Two Kerberos service principal names (SPNs) are created to represent two URLs that are used during Azure AD sign-in which is https://autologon.microsoftazuread-sso.com and https://aadg.windows.net.nsatc.net 

sso3

1. User is accessing the application URL using his browser. He is doing it using his domain joined device in corporate network.

2. If user is not sign in already, it is pointed to Azure AD sign in page and then user type his user name.

3. Azure AD challenge back user via browser using 401 response to provide Kerberos ticket.

4. Browser request a Kerberos ticket for AZUREADSSOACCT computer object from on-premises AD. This account will be created in on premise AD as part of the process in order to represent Azure AD. 

5. On-premises AD locate the AZUREADSSOACCT computer object and return the Kerberos ticket to the browser encrypted using computer object’s secret. 

6. The browser forwards Kerberos ticket to Azure AD.

7. Azure AD decrypts the Kerberos ticket using Kerberos decryption key (This was shared with azure AD when SSO feature enable)

8. After evaluation, Azure AD pass the response back to the user (if required additional steps such as MFA required).

9. User allowed to access the application. 

Prerequisites

In order to implement this feature, we need the following,

1. Domain Admin / Enterprise Admin account to install and configure Azure AD Connect in on-premises 

2. Global Administrator Account for Azure subscription – in order to create custom domain, configure AD connect etc.

3. Latest Azure AD Connect https://www.microsoft.com/en-us/download/details.aspx?id=47594 – if you have older Azure AD connect version installed, you need to upgrade it to latest before we configure this feature.

4. Azure AD Connect can communicate with *.msappproxy.net URLs and over port 443. If connection is control via IP addresses, the range of azure IP addresses can find in here https://www.microsoft.com/en-us/download/details.aspx?id=41653 

5. Add is https://autologon.microsoftazuread-sso.com and https://aadg.windows.net.nsatc.net to browser intranet zone. If users are using IE and chrome, this can be done using group policy. I have written blog post before how to create policy targeting IE. You can find it here

6. Firefox need above URL added to the trusted Kerberos site list to do Kerberos authentication. To do that go to Firefox browser > Type about:config in address bar > in list look for network.negotiate-auth.trusted-uris > right click and select modify > type “https://autologon.microsoftazuread-sso.com, https://aadg.windows.net.nsatc.net" and click ok

7. if its MAC os, device need to be joined to AD. More details can be found in here

Configure Azure AD Seamless SSO
 
Configuration of this feature is straight forward, basically it’s just putting a one tick box. 
 
If its fresh Azure AD connect installation, select the customize option under express settings.
 
sso4
 
Then in User Sign-in page select the appropriate sign-in option and then select Enable single sign-on option.
 
sso5
 
If you have existing Azure AD connect instance running, double click on Azure AD connect short cut. In initial window click on Configure.
 
sso6
 
In additional task page click on Change user sign-in and then click on Next.
 
sso7
 
In next window, type the Azure AD sync account user name and password and click on Next.
 
sso8
 
Then under the User Sign-in page select Enable single sign-on option and then click Next
 
sso9
 
In next page, enter the credentials for on-premises domain admin account and click Next.  
 
sso10
 
At the end click on Configure to complete the process. 
 
sso11
 
This completes the configuration and next step is to verify if its configured SSO. First thing is to check if its create computer object called AZUREADSSOACCT under on-premises AD. You will be able to find it under default Computers OU.
 
sso12
 
Then log in to Azure Portal and go to Azure Active Directory > Azure AD Connect then under the user sign-in option we can see seamless sign-on option is enabled. 
 
sso13
 
This means it’s all good. Next step is to check if its working as expected. in order to do that I am login to corporate device with same user I used earlier which is R272845 and try to access same app url. 
 
This time, all I needed to type was the user name and it log me in. nice!!!!
 
sso14
 
Note – before testing make sure you added the two Azure AD urls to intranet zone as I mentioned in prerequisites section. 
 
Hope this information was useful and if you have any questions feel free to contact me on rebeladm@live.com

Step-By-Step guide to create Azure VM using Azure CLI 2.0

In my previous blog post I have explain what is Azure CLI and how we can integrate it with windows system. If you didn’t read it yet please look in to it before we continue on this post. You can find it on http://www.rebeladmin.com/2017/08/step-step-guide-start-azure-cli-2-0/

In this blog post I am going to demonstrate how we can create Azure VM using Azure CLI. 

1) Log in to Azure CLI using az login (This is explained on my first blog. If you using cloud shell this is not necessary. All you need to do is launch it on the portal)

clivm1

2) Next step on process is to create resource group. before we create we need to know the available locations. So, we can create resource group under relevant geographical location. To list down the locations, run az account list-locations

clivm2

In my demo I am going to create resource group called “rebeladminrg01” under west us. The command for that task will be az group create --name rebeladminrg01 --location westus. In above –name specify the resource group name and –location specifies the geographical location. 

clivm3

3) Next step is to create a virtual network under my new resource group. for that I am going to use 

az network vnet create --name rebeladminVNet --resource-group rebeladminrg01 --location westus --address-prefix 10.10.0.0/16

In above command –name specify the virtual network name. in sample, it is rebeladminVNet. --resource-group defines the resource group it belongs to. In above –location specify the geographical location it belongs to. --address-prefix specify the address space associated with the virtual network.

clivm4

4) Now we have virtual network, next step is to create subnet 10.10.20.0/24 under the virtual network rebeladminVNet. In order to do that I am going to use,

az network vnet subnet create --address-prefix 10.10.20.0/24 --name rebeladminsub1 --resource-group rebeladminrg01 --vnet-name rebeladminVNet

in above, --address-prefix specify the address space for the subnet. –name specify the name of the subnet. --resource-group specify the resource group new subnet belongs to. --vnet-name specify the virtual network it is belongs to. 

clivm5

5) let’s also associate a new public IP address with virtual network, so we can use it to connect from external to new vm that we about to create. 

az network public-ip create --name rebeladminpubip1 --resource-group rebeladminrg01 --location westus --allocation-method dynamic

In above –name specify the name of the public IP instance. --resource-group defines the resource group name it belongs to. –location specifies the georgical location resource belongs to. --allocation-method specifies the public IP allocation method. It can be static IP or dynamic Ip assignment. In this demo, I am going to use dynamic method. 

clivm6

6) Next step on the process to create NIC so we can attach it to VM. 

az network nic create --resource-group rebeladminrg01 --name rebeladminNic1 --vnet-name rebeladminVNet --subnet rebeladminsub1 --public-ip-address rebeladminpubip1

in above sample, --resource-group defines the resource group name it belongs to. --vnet-name specify the virtual network it is belongs to. –subnet specify the subnet it associated with. --public-ip-address specify the public ip address this NIC will associate with. 

clivm7

Now we have components needed for the vm (except storage, I will cover storage on different post. In here I will be using Azure managed disks). We can review the details about the resource we created using az resource list -g rebeladminrg01 this will list down the resource under resources group rebeladminrg01

clivm8

Some data such as subnet info will not display by using above command. Those can view using list command combine with resources group and parent resources. as an example, to view subnet info under the virtual network we can use,

az network vnet subnet list --vnet-name rebeladminVNet -g rebeladminrg01

in above --vnet-name specify the virtual network name and -g specify the resource group name. 

clivm9

7) Now it’s all ready, lets create first windows VM using the resource we created on previous steps. 

az vm create --resource-group rebeladminrg01 --location westus --nics rebeladminNic1 --name REBLEVM101 --image win2016datacenter --admin-username rebeladmin --admin-password Pa$$w0rd123456

in above, --resource-group specify the resources group VM belong to. –nics specify the network interface associated with the VM. –name is the VM name. –image specify the virtual machine image going to use with VM. You can get list of entire image list using az vm image list --output table –all

in sample --admin-username defines the admin user name for the new vm and --admin-password defines the VM password. 

clivm10

this creates the VM successfully. 

clivm11

In this demo, I explain how to create VM using azure cli. Hope this was useful and in next post on Azure CLI I will cover about storage. If you have any questions, feel free to contact me on rebeladm@live.com 

Step-by-Step Guide to Start with Azure CLI 2.0

There are many ways to create, manage, remove resources from Azure subscription. For the users who prefer GUI has Azure Classic portal and Azure Resource Manager. For PowerShell lovers Azure has Azure PowerShell module. Apart from that there are other methods such as terraform (I already wrote articles about it, if you want to know more about it, search for “terraform” in the blog) which simplifies Azure resource management. Azure CLI is also a command-line tool introduced by Microsoft which can use to manage azure resources. This is allowing to use from multiple platform such as Linux, Mac OS and Windows. This blog post is to explain how we can configure windows system to use Azure CLI. 

There are two ways which we can use to connect to Azure CLI. 

Using Azure Portal

Azure also allow to use web based version of Azure CLI with name of “Cloud Shell”. This is easily can open through the browser. In order to access it,

1) Log in to Azure Portal

2) Click on Cloud Shell icon on top right-hand side

cli1

3) When you do this for first time it will ask to create Azure file share. You can select relevant subscription and click on “Create Storage

cli2

4) Once it is created the storage, it will load up the shell access through the browser. 

cli3

Using Windows Computer

We also can use Azure CLI from the local computer. as I said this is not only supported to use with windows systems. it is supported to use with Linux and Mac OS. In this demo, I am going to demonstrate how to configure it with windows system. 

Azure CLI uses python so out configuration will be based on python installation. 

1) Log in to computer as an administrator

2) Go to https://www.python.org/downloads/ and download python

cli4

3) Once file is downloaded, run it as administrator to install. During the installation, make sure to select option “Add Python 3.6 to PATH” option. Then it will allow to use python commands without navigating to installation location. 

cli5

4) Once installation completed, open windows command-line and type python –version. this will confirm the python installation. (it is recommended to open command line as administrator, otherwise it will say PATH records are not added as we ran the installation as Administrator) 

cli6

5) Next step is to install Azure CLI libraries. In order to do that run pip install –user azure-cli

cli7

6) Once it is completed, move to C:\Users\[Admin User]\AppData\Roaming\Python\Python36\Scripts and run command az . This will verify the Azure CLI integration. If it needs to run from anywhere add it to the PATH. 

cli8

7) Now let’s try to log in to Azure using Azure CLI. In order to do that we can use az login -u azureusername -p password. the problem on this method is that password need to type in as clear text. Instead of that we can use browser based more secure login. To do that type az login in command-line. 

The it gives a link and code to use for authentication. 

cli9

8) Once it is open in browser it asks for the verification code. Once its enter click on Continue

cli10

In next page, it verifies the Azure login and then confirm the connection.

cli11

When we go back to Azure CLI, we can see its successfully logged in and showing the subscription data. 

cli12

This confirms the successful connection to Azure using Azure CLI. This is the end of this post and in next post let’s see how we can add, manage, remove azure resources via Azure CLI. Hoep this was helpful and if you have any questions feel free to contact me on rebeladm@live.com

Setting up Azure Virtual Machines with Terraform

In my previous article about terraform, I explain what is terraform and what it can do. Also, I explain how to set it up and how we can use it with Azure to simplify infrastructure configuration. If you didn’t read it before you can view it using this link  

In this post, we are going to look further in to Azure infrastructure setup using terraform.

Before that lets look in to sample configuration of an Azure resource and see how syntax been used.

resource "azurerm_resource_group" "test" {

  name     = "acctestrg"

  location = "West US"

}

 resource "azurerm_virtual_network" "test" {

  name                = "acctvn"

  address_space       = ["10.0.0.0/16"]

  location            = "West US"

  resource_group_name = "${azurerm_resource_group.test.name}"

}

Above code is to create an Azure resource group and Azure virtual network. In the code azurerm_resource_group and azurerm_virtual_network defines the azure resource type. The text test defines the name for that resource instance. This is not the azure resource group or azure virtual network name. This is the instance name. so, if you have another resource group it can be test2. Actual resource names are defined using name attribute. So, in above code the actual resource name for resource group is acctestrg and for virtual network its acctvn.

In above example, new virtual network is need placed under the acctestrg resource group. in the code it is defined using,

resource_group_name = "${azurerm_resource_group.test.name}"

in there, by azurerm_resource_group.test it defines the related resource group instance. In our example, it is test. Then using .name it calls for the attribute value of name under that particular resource group.

In the plan stage terraform creates the execution plan. It does not process the code top to bottom. It evaluates the code and then build the plan logically. There for it no longer consider the resource order. Let’s try it with an example, 

resource "azurerm_virtual_network" "test" {

  name                = "acctvn"

  address_space       = ["10.0.0.0/16"]

  location            = "West US"

  resource_group_name = "${azurerm_resource_group.test.name}"

}

 resource "azurerm_resource_group" "test2" {

  name     = "acctestrg2"

  location = "West US"

}

 resource "azurerm_virtual_network" "test2" {

  name                = "acctvn2"

  address_space       = ["11.0.0.0/16"]

  location            = "West US"

  resource_group_name = "${azurerm_resource_group.test2.name}"

}

 resource "azurerm_resource_group" "test" {

  name     = "acctestrg"

  location = "West US"

}

In above example, I am creating two resources group and two virtual networks. If you look in to highlighted sections, I placed the code related to virtual network before creating resources group. But when I run terraform plan it creates the execution plan in correct order.

tf1 

And once it is executed, it creates the expected resources.

tf2

As next step on demo, let’s see how we can create virtual machines in Azure using terraform.

resource "azurerm_virtual_machine" "testvm" {

  name                  = "acctvm"

  location              = "West US"

  resource_group_name   = "${azurerm_resource_group.test.name}"

  network_interface_ids = ["${azurerm_network_interface.test.id}"]

  vm_size               = "Standard_A0"

above code is an example to create a VM in azure. In code sample, azurerm_virtual_machine defines the resource type. testvm is the resource instance name. acctvm is the name of the virtual machine. According to code the resource will deploy under West US region. resource_group_name defines the resource group it belongs to. network_interface_ids defines the network interface id for the VM. vm_size defines the Azure VM template. The template list for the region can list down using following Azure CLI command.

az vm list-sizes --location west-us

This will list down the all available VM sizes in West US region.

tf3

Azure VM also need other components such as virtual network, storages, operating system so on. Let’s see how we can add these to the configuration.

In earlier on the post, I share samples for creating a resources group and virtual network. The next step of it will be to add a subnet under the virtual network.

resource "azurerm_subnet" "sub1" {

  name                 = "acctsub1"

  resource_group_name  = "${azurerm_resource_group.test.name}"

  virtual_network_name = "${azurerm_virtual_network.test.name}"

  address_prefix       = "10.0.2.0/24"

}

In above I am creating a subnet 10.0.2.0/24 under virtual network and resources group I already have. In code, azurerm_subnet defines the resource type. sub1 is the instance name and acctsub1 is the subnet name. resource_group_name defines on which resources group it belongs to. virtual_network_name defines which azure virtual network it associated with. address_prefix specifies the subnet value.

Now we have subnet also associated with network. We also need public IP address in order to connect to VM from internet. 

resource "azurerm_public_ip" "pub1" {

  name                         = "pub1"

  location                     = "West US"

  resource_group_name          = "${azurerm_resource_group.test.name}"

  public_ip_address_allocation = "dynamic"

}

According to above, I am creating public IP instance called pub1 under same resource group. it’s IP allocation is set to Dynamic. If need it can be static as well.

Next step is to create network interface for the VM.

resource "azurerm_network_interface" "ni1" {

  name                = "acctni1"

  location            = "West US"

  resource_group_name = "${azurerm_resource_group.test.name}"

ip_configuration {

    name                          = "lan1"

    subnet_id                     = "${azurerm_subnet.test.id}"

   private_ip_address_allocation = "dynamic"

   public_ip_address_id  = "${azurerm_public_ip.pub1.id}"

  }

In above azurerm_network_interface is the resource type for the network interface. the interface name we are creating is acctni1. the second part of code which starts with ip_configuration defines the IP configuration for the network interface. subnet_id defines the subnet it belongs to. private_ip_address_allocation defines the ip allocation method. It can be Dynamic or Static. public_ip_address_id associates with the public ip created in the previous step. If this is not done you will not be able to connect to VM remotely once it is deployed.    

Next thing we need for the VM is storage. Let’s start with creating a Storage Account 

resource "azurerm_storage_account" "asa1" {

  name                = "accsa"

  resource_group_name = "${azurerm_resource_group.test.name}"

  location            = "westus"

  account_type        = "Standard_LRS"

 }

azurerm_storage_account is the resource type and accsa is the name for the account. account_type defines the storage account type. it can be Standard_LRS, Standard_GRS, Standard_RAGRS, Standard_ZRS, or Premium_LRS. More info about these account types can find from https://docs.microsoft.com/en-us/azure/storage/storage-introduction .

as next step, we can create a new storage container under the storage account.

resource "azurerm_storage_container" "con1" {

  name                  = "vhds"

  resource_group_name   = "${azurerm_resource_group.test.name}"

  storage_account_name  = "${azurerm_storage_account.test.name}"

  container_access_type = "private"

}

In above azurerm_storage_container is the resource type and it name is vhds. resource_group_name defines the resource group it belongs to and storage_account_name defines storage account it belongs to. container_access_type can be private, blob or container. More info about these container types can find from https://docs.microsoft.com/en-us/azure/storage/storage-introduction

Following image shows what it looks like when using GUI option. 

tf4

By now we have most of the resources ready for the VM. Next step is to define image for the VM.

  storage_image_reference {

    publisher = " MicrosoftWindowsServer"

    offer     = " WindowsServer"

    sku       = " 2016-Datacenter"

    version   = "latest"

  }

In above I am using windows server 2016 datacenter as image for the VM. Publisher, offer, sku and version info need to provide in order to select correct image. For windows servers, you can find these info in https://docs.microsoft.com/en-us/azure/virtual-machines/windows/cli-ps-findimage. For Linux, this info available at https://docs.microsoft.com/en-us/azure/virtual-machines/linux/cli-ps-findimage

Next step is to add a hard disk,

storage_os_disk {

    name          = "myosdisk1"

    vhd_uri       = "${azurerm_storage_account.test.primary_blob_endpoint}${azurerm_storage_container.test.name}/myosdisk1.vhd"

    caching       = "ReadWrite"

    create_option = "FromImage"

  }

  storage_data_disk {

    name          = "datadisk0"

    vhd_uri       = "${azurerm_storage_account.test.primary_blob_endpoint}${azurerm_storage_container.test.name}/datadisk0.vhd"

    disk_size_gb  = "60"

    create_option = "Empty"

    lun           = 0

  }

Above create two disks. one is for OS and one is for data. vhd_uri defines the path for the VHD which is saved under the storage account created.

Last but not least we need to define the OS configuration data such as hostname and administrator account details.

  os_profile {

    computer_name  = "rebelpro1"

    admin_username = "rebeladmin"

    admin_password = "Password1234!"

  }

In above, computer_name specify the hostname of the VM. admin_username specify the local administrator name and admin_password specify the local administrator password.

Now we have all the components ready to deploy a new VM. Some of the components we just need to create one time. as example virtual networks, subnets, storage accounts not need to create for each VM unless there is valid requirement. Let’s put all these together in to a one script so it will make more sense. 

# Configure the Microsoft Azure Provider

provider "azurerm" {

  subscription_id = "d7xxxxxxxxxxxxxxxxxxxxxx"

  client_id       = "d9xxxxxxxxxxxxxxxxxxxxxx"

  client_secret   = "f1xxxxxxxxxxxxxxxxxxxxxx "

  tenant_id       = "05xxxxxxxxxxxxxxxxxxxxxx "

}

resource "azurerm_resource_group" "rg1" {

  name     = "acctestrg"

  location = "West US"

}

resource "azurerm_virtual_network" "vn1" {

  name                = "vn1"

  address_space       = ["10.0.0.0/16"]

  location            = "West US"

  resource_group_name = "${azurerm_resource_group.rg1.name}"

}

resource "azurerm_public_ip" "pub1" {

  name                         = "pub1"

  location                     = "West US"

  resource_group_name          = "${azurerm_resource_group.rg1.name}"

  public_ip_address_allocation = "dynamic"

}

resource "azurerm_subnet" "sub1" {

  name                 = "sub1"

  resource_group_name  = "${azurerm_resource_group.rg1.name}"

  virtual_network_name = "${azurerm_virtual_network.vn1.name}"

  address_prefix       = "10.0.2.0/24"

}

resource "azurerm_network_interface" "ni1" {

  name                = "ni1"

  location            = "West US"

  resource_group_name = "${azurerm_resource_group.rg1.name}"

 

  ip_configuration {

    name                          = "config1"

    subnet_id                     = "${azurerm_subnet.sub1.id}"

    private_ip_address_allocation = "dynamic"

    public_ip_address_id  = "${azurerm_public_ip.pub1.id}"

  }

}

 resource "azurerm_storage_account" "storevm123" {

  name                = "storevm123"

  resource_group_name = "${azurerm_resource_group.rg1.name}"

  location            = "westus"

  account_type        = "Standard_LRS"

 

  tags {

    environment = "demo"

  }

}

 resource "azurerm_storage_container" "cont1" {

  name                  = "vhds"

  resource_group_name   = "${azurerm_resource_group.rg1.name}"

  storage_account_name  = "${azurerm_storage_account.storevm123.name}"

  container_access_type = "private"

}

 resource "azurerm_virtual_machine" "vm1" {

  name                  = "vm1"

  location              = "West US"

  resource_group_name   = "${azurerm_resource_group.rg1.name}"

  network_interface_ids = ["${azurerm_network_interface.ni1.id}"]

  vm_size               = "Standard_DS2_v2"

 

   storage_image_reference {

    publisher = "MicrosoftWindowsServer"

    offer     = "WindowsServer"

    sku       = "2016-Datacenter"

    version   = "latest"

  }

   storage_os_disk {

    name          = "osdisk1"

    vhd_uri       = "${azurerm_storage_account.storevm123.primary_blob_endpoint}${azurerm_storage_container.cont1.name}/osdisk1.vhd"

    caching       = "ReadWrite"

    create_option = "FromImage"

  }

   storage_data_disk {

    name          = "datadisk1"

    vhd_uri       = "${azurerm_storage_account.storevm123.primary_blob_endpoint}${azurerm_storage_container.cont1.name}/datadisk1.vhd"

    disk_size_gb  = "60"

    create_option = "Empty"

    lun           = 0

  }

     os_profile {

    computer_name  = "rebelpro1"

    admin_username = "rebeladmin"

    admin_password = "Password1234!"

  }

   tags {

    environment = "demo"

  }

}

Let’s verify the resources using Azure portal.

As we can see it is created all the expected resource under the resource group acctestrg.

tf5

Also, we can see it is created the VM as expected.

tf6

In this post, we went through the process of creating Azure VM and related components using terraform. Hope this was useful and if you have any questions feel free to contact me on rebeladm@live.com

Azure resource setup simplified with terraform

This week I was testing Terraform , a simple tool which can use to automate Azure resource deployment.

It will be easier to explain terraform with a real-world example. I am developing a web application and as my resource provider I am using Azure. my first requirement is to setup a development environment. For that I need at least one web server, one database server and connectivity between these two servers. to setup the environment, I log in to the portal and then setup resource group, storage account and virtual network. After that I start to build servers. after I complete it, I setup web server application and database server. so even its looks like straight forward, its takes time. later on, in the development process I also required a test platform where I can try my application with different operating systems. Also, I like to test application by adding more components such as load balancers, web servers to the environment. These testing environments are temporally. So, each and every time I need to setup environment with all the different components and once testing process completes, needs to destroy it. when I need to sell it as a solution to people, I face another challenge as not everyone wants to run it on Azure. Even if it’s another service provider or on-premises environment, application should test in similar environment prior to sell as a solution. Each provider has their own way of setting up things.

On this given scenario I faced few challenges,

To setup required resources for application takes time as each component need to configure in certain way. 

To setup integration between components, I need to log in to different systems and adjust the settings. A single mistake can cause hours of disruptions to the project. 

Due to the complexity of setting up environments, I may end up keep running test environments longer which probably increase my development cost. 

How Terraform can help?

Using Terraform I can deploy the whole environment by executing a single script file. This script is basically a set of instructions explaining how to setup each and every component. If I need to setup a new server in azure from scratch there is a procedure for it. we need to setup relevant resource groups, network components, storage accounts before we start to build the server. terraform itself understand these dependencies and build the environment according to that. This also helps to standardize the resource setup process.

Terraform also can use to configure application settings as part of the environment setup. That means we do not need to log in to systems to make initial software configurations. This will prevent the human errors.

Once we setup an environment using terraform we can change it, destroy it using a single command. As an example, let’s assume we setup a test environment with two web servers (using terraform). I have a new requirement to add new web server to the same environment. To do that all I need to do is modify the same script and add new entry for new webserver. once I execute it, it will automatically detect the current environment and only add the missing components. When destroy, it is again a single command and it will remove each component in the proper order. As example, it will understand that before remove resource group, it need to remove all other components under it.

As setup and destroy process of resources is easy with terraform, we do not need to keep running non-critical resources. As an example, if I need to give a POC or show a demo to a customer, all I need to do is to execute the pre-created terraform script when needed and destroy it afterwards.

Terraform support different service providers. It is not only for cloud based solutions. It also supports on-premises solutions. As an example, terraform can use with Azure Pack and Azure stack to do the same thing in on-premises Hyper-V environment. It also supports to SaaS application configurations. The supported providers list can be found in here https://www.terraform.io/docs/providers/index.html

Terraform mainly have three functions.

Plan – Before execute the configuration, it should go for the planning stage. In here terraform will build the execution plan based on the configuration provided by the engineer. It will explain what will be created when configuration is executed.

Apply – In this phase it will apply execute the execution plan created on the “planning” stage. It will also report back once its completed the resource setup. If there were errors, it will also explain it in details.

Destroy – This is basically to undo the execution plan. By calling this, we can destroy all the resource created by a particular terraform configuration file.

I think it’s enough with the theory, let’s see why it’s so cool.

In my demo, I am going to show how to setup terraform and how to use it to create resource in azure. 

Setup Terraform

In my demo, I am going to use windows 10 as the system. Terraform also supported on Linux, Mac and solaris systems.

1) Go to this link and download the file relevant to windows architecture. 

2) Then create a folder and move the downloaded terraform.exe file. 

3) Next step is to setup the Binary path for the terraform so system knows when we use the terraform commands. To do that, run the PowerShell console as Administrator and then type

$env:Path += ";C:\terraform"

In here C:\terraform is the folder where I saved the terraform.exe

terra1

4) As next step, we can confirm terraform setup by running terraform in the PowerShell console. 

terra2
 
This confirms the Terraform setup and next step to configure Azure side to support terraform. 
 
Retrieve Required info from Azure

Terraform uses Azure ARM API to connect and manage azure resources. To connect to Azure, terraform need to provide following Azure ARM environment variables using configuration file.

ARM_SUBSCRIPTION_ID

ARM_CLIENT_ID

ARM_CLIENT_SECRET

ARM_TENANT_ID

To get ARM_CLIENT_ID, ARM_CLIENT_SECRET and ARM_TENANT_ID we need to create a Service Principal in Azure.

To do the we can use Azure Cloud Shell.  

1) Log in to Azure Portal ( https://portal.azure.com ) as a Global Administrator

2) Click on Cloud Shell Button. 

terra3

3) Then it will open the shell in the same window. If it’s your first time using this feature, it will ask to create a storage account. 

terra4

4) Next step is to fine the Subscription Id. To do that type following and press enter. 

az account list

Then it will provide an output like following. In there “id” represent the Subscription ID we required. 

terra5

5) Next step is to create the Service Principal. In order to do that use,

az ad sp create-for-rbac –role="Contributor" –scopes="/subscriptions/xxxxxxxxxxxx"

in above command xxxxxxxxxxxx should replace with the Subscription ID we found in the previous step. 

Then it gives an output similar to following

terra6

In above image 

appId is equal to Client ID.

Password is equal to Client Secret

Tenant is equal to Tenant ID

Now we have all the information we need in order to connect to Azure trough terraform. 

Create first configuration

Next step is to create first terraform configuration file. The file is using the extension of .tf. You can use your favorite text editor to create the file. I am using Visual Studio code and it can be download from https://code.visualstudio.com/

The file no need to save on the same folder where your terraform.exe file. However, you need to navigate to that folder before execute the terraform commands. In my demo, it is C:\terraform

My first configuration is following

 

# Configure the Microsoft Azure Provider

provider "azurerm" {

  subscription_id = "xxxxxxx"

  client_id       = " xxxxxxx "

  client_secret   = " xxxxxxx "

  tenant_id       = " xxxxxxx "

}

resource "azurerm_resource_group" "myterrapro1" {

  name     = "myterrapro1"

  location = "West US"

}

resource "azurerm_virtual_network" "myterrapro1network" {

  name                = "myterrapro1vn"

  address_space       = ["10.11.12.0/24"]

  location            = "West US"

  resource_group_name = "${azurerm_resource_group.myterrapro1.name}"

}

In above code,

provider "azurerm"

define the service provider as Azure ARM.

 subscription_id = "xxxxxxx"

                client_id       = " xxxxxxx "

                client_secret   = " xxxxxxx "

                tenant_id       = " xxxxxxx "

the above values should replace by the values we found through the Azure.

resource "azurerm_resource_group" "myterrapro1" {

  name     = "myterrapro1"

  location = "West US"

}

The above saying to create new azure resource group called myterrapro1 in West US region.

resource "azurerm_virtual_network" "myterrapro1network" {

  name                = "myterrapro1vn"

  address_space       = ["10.11.12.0/24"]

  location            = "West US"

  resource_group_name = "${azurerm_resource_group.myterrapro1.name}"

in the next section, it is creating an Azure Virtual Network called myterrapro1vn. It got address space allocated as 10.11.12.0/24. This will create under resource group called myterrapro1. This virtual network also will be created under West US region.

Once script is ready, save it with .tf extension.

Then launch PowerShell as Administrator. Then change the folder path to where script file is saved. In my demo, its C:\terraform. After that type following,

terraform plan

This is step where terraform build the execution plan.

terra7

This output shows what will happen when apply the execution plan.

To apply the plan type following and press enter.

terraform apply

once process is started, it will also show the progress of setting up resources.

terra8

according to above image we can see its successfully created the resources. we can confirm it using the Azure portal.

terra9

terra10

Now we know how to create resource. Let’s see how to destroy the resources we created.

In order to do that you do not need to change anything in the script. All you need to do is to issue the command,

terraform destroy

once we run the command it will ask to confirm. Type yes and press enter to proceed with the destroy process.

terra11

As we can see it remove all the resource in the configuration file. Once it done we can also log in to azure portal and confirm.

Isn’t this cool?

In this blog post I explained what is terraform and how we can use it to simplify resource setup in azure. in next blog post I will share more examples to show its capabilities.

Hope this was useful and if you have any questions feel free to contact me on rebeladm@live.com

Conditional Access Policies with Azure Active Directory

When it comes to manage access to resources in infrastructure, there are two main questions we usually ask.

  1. “Who” is the user and “What” resources?
  2. Is it allow or deny access? 

Answers to above questions are enough to define the base rules. But depending on the tools and technologies that can use to manage the access, we will have additional questions which will help us define accurate rules. As an example, Sales manager walks up to the IT department and says “Peter need to access “Sales” folder in the file server”. So, based on the statement, we know the user is “Peter” and resources is “Sales” folder in the “File Server”. Also, we know the user “Peter” needs to “Allow” access to the folder. However, since we are going to use NTFS permission, we know that we can make the permissions more accurate than that. When sales manager says “Allow” peter to access “Sales” folder he didn’t define it as “Read & Write” or “Read Only”. He didn’t also define if he need same permission to all the sub folders in the “Sales” folder. Based on answer to those, we can define more granular level rules.

Access control to resource in an infrastructure happens in many different levels with many different tools and technologies. The first level of control happens in the network perimeter level. Using firewall rules, we can handle “in” and “out” network traffic to/from company infrastructure. If user pass that level, then it will verify the access based in users and groups. After that it comes to applications and other resources. But problem we have as engineers is to manage all these separately. Let’s go back to our previous example. In there we only consider about NTFS permission. If “Peter” is a remote worker and he connect to internal network using Remote desktop services, first we need to define firewall rules to allow his connection. Then if multi-factor authentication required for remote workers, I need to configure and defines rules in there. Also, when user logs in, he will not have same permission he has in company workstation. So, those session host permissions need to be adjusted too. So, as we can see even its sounds simple, we have to deal with many different systems and rules which cannot combine in to “one”.

So far, we looked in to on-premises scenarios. When it comes to cloud, the operation model is different. We cannot apply the same tools and technologies we used to manage access in on-premises. Microsoft Azure’s answer for simplifying access management to workloads is “Conditional Access”. This allow manage access to applications based on “Conditions”.  When it comes to public cloud mostly we allowing access to applications from networks we do not trust. There for, using “Conditions” we can define policies for users which they need to comply, in order to get access to the applications.

In Condition Access Policy, there are two main section.

Assignments –  This is where we can define conditions applying to user environment such as users and groups, applications, device platform, login locations etc.

Access Control –  This is to control access for the users and groups when they comply with the conditions specified in the “assignments” section. it can be either allow access or deny access.

cac1

Let’s see what conditions we can applies using conditional access policies. 

Assignments 

Under the assignment section there are three main options which can use to define conditions. 

1) Users and Groups

2) Cloud apps

3) Conditions 

User and Groups

Under the user and groups option we can define the users and groups targeted by the condition access policy. 

We can select define target as “All” or selected number of users and groups. 

cac2

We also can explicitly select groups and exclude individuals from it. 

cac3

  

Cloud Apps

  

Under the cloud app option we can select the applications which is targeted for the policy. these applications can be Azure apps or on-premises applications which is published via Azure Active Directory using Azure App Proxy. Similar to users and groups, we also can explicitly allow access to a large group and exclude specific entities. 

cac4

Condition 

Using options under this category we can specify the conditions related to user’s login environment. This category has 4 sub-categories. 

1) Sign-in risk

2) Device Platforms

3) Locations

4) Client Apps

It is not required to use all these sub-categories for each and every policy. By default, all these are in disabled mode. 

 

Sign-in risk

Azure Active Directory monitor user login in behavior based on six types of risk events. These events are explained in details on https://docs.microsoft.com/en-us/azure/active-directory/active-directory-reporting-risk-events#risk-level . As an example, I am usually login to azure from IP addresses belongs to Canada. I log in to azure at 8am from Toronto. After 5 minutes, its detects a login from Germany. In typical scenario, it’s not possible unless I use a remote login. From Azure point of view, it will detect as malicious activity and will rate as “Medium” risk event. In this sub-category, we can define what level of sign-in-risks need to consider. 

cac5

Note – If you need enable the policy, you need to first click on “Yes” under configure option.

cac6

Device Platforms

Device platforms are categorized based on the operating systems. it can be,

Android

iOS

Windows Phone

Windows

cac7

We also can explicitly allow all and then exclude specific platforms.

Locations

Locations are defined based on IP addresses. If it’s only for “trusted” IP addresses, make sure to define trusted IP addresses using the given option.

cac8

Client Apps

Client apps are the form that users access the apps. It can be using web, mobile apps or desktop clients. Exchange ActiveSync is available when Exchange Online is the only cloud app selected. 

cac9

Access Controls 

There are two categories which can use to add the access control conditions to the policies. 

1) Grant

2) Session

Grant

In this category, we can specify the allow or deny access. Under the allow access, we can add further conditions such as,

Require multi-factor authentication

Require device to be marked as compliant

Require domain joined device

cac10

MFA

Multi-factor authentication is additional layer of security to confirm the authenticity of the login attempt. Even policy set to allow access, using this option we still can force user to use MFA. This is allowed to use Azure MFA or on-premises MFA solution (via ADFS).

 

Compliant

 

Using Microsoft Intune, we can define rules to categorize the user devices are compliant or not according to company standards. if this option is used, only the devices which is compliant will consider.

 

Domain Joined

 

If this option is used, it will only consider connection from Azure Active Directory domain joined devices.

Once you define the options, it can either force to use all the options or only to consider “one” of the selected. 

cac11

Sessions

This is still on preview mode. This is basically to provide additional information about session to the cloud app so it can confirm authenticity of the session. Not every cloud app supports this option yet. 

cac12

Demo

By now we know what are the conditions we can use to define a condition access policy. Let’s see how we can configure a policy with a real-world example. Before we start, we need to look in to prerequisites for the task. In order to setup condition access policies we need following.

1. Valid Azure Active Directory Premium Subscription

2. Azure Administrator Account to create policies

In my demo, I have a user called “Berngard Saller”. He is allowed to access an on-premises application which is published using Azure Application Proxy (http://www.rebeladmin.com/2017/06/azure-active-directory-application-proxy-part-02/). 

cac13
 
I need a condition access policy to block his access to this app if he is login from a device which use “Android OS”. 
So, let’s start,
 
1. Log in to the Azure portal as Administrator.
2. Click on Azure Active Directory | Conditional Access
 
cac14
 
3. In new page, Click on + New Policy
 
cac15
 
4. In next window, first provide a Name for the policy
 
cac16
 
5. Then click on Users and Groups | Select Users and Groups | Select. Then from the list of users select the appropriate user (in my demo its user Berngard Saller) and then click on Select button. 
 
 
cac17
 
6. Then in next window click on Done
 
cac18
 
7. Next step is to define the App. To do that, Click on Cloud Apps | Selected Apps | Select. Then from the list select the relevant app (in my demo its webapp1) and then click on Select button. 
 
cac19
 
8. Then in next window click on Done
 
9. As next step, go to Conditions | Device Platforms | Click on Yes to enable Condition | Select Device Platforms | Android. then click on Done button. 
 
cac20
 
10. Then in next window click on Done
 
11. Next step is to define Access Controls. To do that Click on Grant | Block Access. Then click on Select button. 
 
cac21
 
12. Now we have the condition policy ready. Click On under Enable Policy and click on Create button to create the policy. 
 
cac22
 
Now we have the policy ready. The next step is to test. 
 
cac23
 
When I access the app from windows system, I have allowed access. 
 
cac24
 
But when I do it from android mobile it denied access as expected. 
 
cac25
 
As we can see conditional access simplifies the access control to workloads in Azure. 
 
This is the end of this post and if you have any questions feel free to contact me on rebeladm@live.com

MANAGE AZURE ACTIVE DIRECTORY WITH POWERSHELL – PART 02

In previous part of this blog serious, I have explained how we can install Azure AD PowerShell module and how it can use it to manage Azure Active Directory directly using PowerShell Commands. If you not read it yet you can find it using http://www.rebeladmin.com/2017/02/manage-azure-active-directory-powershell-part-01/

In this post, I am going to explain about another set of cmdlets and the ways to use.

Some of the commands which we use for on-premises Active Directory Management works for Azure Active Directory too. only difference is the cmdlet itself. As an example, in on-premises AD, we use New-ADUser to add user, in Azure AD it becomes New-​Msol​User. If you like to know further about command and its use, easiest way to start is using following commands.

More information about a command can view using,

Get-Help New-​Msol​User -Detailed

Technical Information about thecommand can view using,

Get-Help New-​Msol​User -Full

Online information about the command can view using,

Get-Help New-Msol​User -Online

We also can view some example for the command using,

Get-Help New-Msol​User -Example

power1

We can simply create new user using,

New-MsolUser -UserPrincipalName "jeffm@therebeladmin.com" -DisplayName "Jeff Mak" -FirstName "Jeff" -LastName "Mak" -PasswordNeverExpires $true

power2

In order to create a user, you need to connect to Azure AD with a user who has “Global Admin” role.

In above command UserPrincipalName specify the UPN and user password s set not to expire.

It is obvious sometime we need to change password of an existing account.

Set-MsolUserPassword -UserPrincipalName "jeffm@therebeladmin.com" -NewPassword "pa$$word"

The above command will reset the password for the jeffm@therebeladmin.com in to new password.

Instead of specifying password, following command will generate random password and force user to reset it on next login.

Set-MsolUserPassword -UserPrincipalName "jeffm@therebeladmin.com" -ForceChangePassword $true

power3

Azure Active Directory does have predefined administrative roles with different capabilities. This allows administrators to assign permissions to users to do only certain tasks.

More details about these administrative roles and their capabilities can found on https://docs.microsoft.com/en-us/azure/active-directory/active-directory-assign-admin-roles

We can list down these administrative roles using

Get-MsolRole

power4

According to requirements, we can add users to these administrative roles.

Add-MsolRoleMember -RoleName "User Account Administrator" -RoleMemberObjectId "e74c79ec-250f-4a47-80dd-78022455e383"

Above command will add user with object id e74c79ec-250f-4a47-80dd-78022455e383 to the role.

In order to view existing members of different administrator roles, we can use command similar to below.

$RoleMembers = Get-MsolRole -RoleName "User Account Administrator"

Get-MsolRoleMember -RoleObjectId $RoleMembers.ObjectId

This will list down the users with User Account Administrator role assigned.

power5

Apart from the roles, AD also have security groups.

New-MsolGroup -DisplayName "HelpDesk" -Description "Help Desk Users"

Above command creates a group called HelpDesk

power6

power7

A group contains members. We can add members to group using commands similar to below.

Add-MsolGroupMember -GroupObjectId a53cc08c-6ffa-4bd6-8b03-807740e100f1 -GroupMemberType User -GroupMemberObjectId e74c79ec-250f-4a47-80dd-78022455e383

This will add user with object id e74c79ec-250f-4a47-80dd-78022455e383 to group with object id a53cc08c-6ffa-4bd6-8b03-807740e100f1.

We can list down the users of the group using

Get-MsolGroupMember -GroupObjectId a53cc08c-6ffa-4bd6-8b03-807740e100f1

power8

We can view all the groups and their group ids using

Get-MsolGroup

power9

In order to remove member from the security group we can use Remove-MsoLGroupMember cmdlet.

Remove-MsoLGroupMember -GroupObjectId a53cc08c-6ffa-4bd6-8b03-807740e100f1 -GroupMemberType User -GroupmemberObjectId e74c79ec-250f-4a47-80dd-78022455e383

In order to remove a user from administrator role we can use Remove-MsolRoleMember cmdlet.

Remove-MsolRoleMember -RoleName "User Account Administrator" -RoleMemberType User -RoleMemberObjectId "e74c79ec-250f-4a47-80dd-78022455e383"

Above command will remove user with object id e74c79ec-250f-4a47-80dd-78022455e383 from the group User Account Administrator

This is the end of the part 2 of this series. In next part, we will look further in to Azure AD management with PowerShell.

If you have any questions feel free to contact me on rebeladm@live.com

Step-by-Step guide to configure site-to-site VPN Gateway connection between Azure and on-premises network

When you are in hybrid cloud setup with azure, using site-to-site VPN gateway you can have better continuity for your workloads. in this post, I am going to demonstrate how to set up site-to-site VPN Gateway.

Requirements 

Before start make sure you have following in place. 

1) VPN device – you need to have VPN device in on-premises to create the VPN connection with azure. the supported list of devices can found on here. Also, you need to have the relevant knowledge to configure it on your device. I am not going to cover it in details here as settings are different based on the vendor. 

2) Static Public IP address – your VPN device should have external public IP address and it shouldn’t be NAT. 

3) Valid Azure Subscription – Of because you need active Azure subscription. It can be paid or free trial. 

Create Virtual Network 
 
If you already have virtual network setup in your azure subscription, you will not need to do this step but make sure the settings are correct. 
 
1) Log in to the azure portal.
2) Go to New > Networking > Virtual Network 
vpn1
 
3) Then click on create 
vpn2
 
4) In next page, it will open up the wizard with the VNet information. In their fill the information to match with your configuration.
vpn3
 
Name – Name for the VNet
Address Space – IP range for the VNet. If you have multiple Address ranges, it can add later. 
Subnet name – Name for the subnet you like to add 
Subnet Address range – Subnet IP range (it must be within the Address Space listed before)
Resource Group – Can create new group or select existing group
Location – location of the VNet
 
After that click on create continue.
5) Once VNet created, can modify the address ranges and subnets.
vpn4
 
Create Gateway Subnet 
 
Next step is to create gateway subnet for the VNet. It is recommended to use /28 or /27 for gateway subnet. This need to be done before connecting VNet to the gateway. 
 
1) Log in to the Azure Portal
2) Then go to More Services > Virtual Networks 
vpn5
 
3) Then click on the VNet, created on previous step and click on subnets. Then click on gateway subnet 
vpn6
 
4) In the next window define the subnet for the gateway and click OK
vpn7
vpn8
Create Virtual Network Gateway
 
Next step is to create virtual network gateway. 
 
1) Log in to azure portal 
2) Go to New > Networking > Virtual Network Gateway 
vpn9
 
3) In next window fill the relevant information and click on Create
vpn10
 
Name – Name for the virtual network gateway
Gateway Type – For our VPN it will be VPN 
VPN Type – Type of the VPN and regular VPN will be route-based
SKU – SKU for the VPN type
Virtual Network – in here select the VNet you have created following previous step
Public IP Address – VPN need to have public IP address. Select public IP from here or if you don’t have, once you click on the option it will allow you to add new one. 
Location – make sure you select the correct region to match with VNet region. 
 
4) It can take up to 45 minutes to complete the task. Once it’s done can see the public IP address details. You need this to configure the VPN device in yours on premises device. 
vpn11
 
Create Local Network Gateway
 
The next step is to create local gateway which represent your local network. To create it,
 
1) Log in to azure portal
2) Go to New > Networking > Local network gateway
vpn12
 
3) Then it will open new wizard and fill the relevant information. After that click on create to proceed
vpn13

Name – Name for the local gateway 
IP Address – Public IP address to represent your VPN device. It should not behind NAT. 
Address Space – This is yours on premises address ranges. You can add multiple ranges.
Resource Group – you can create new resource group or use the same one you were using. 
vpn14
 
Create Site-to-Site VPN
 
Then next step is to create Site-to-Site VPN connection between your VPN device and the virtual network gateway. To create it,
 
1) Log in to azure portal
2) Go to More Services > Virtual network gateways 
vpn15
 
3) Then click on the virtual network gateway you created and, under the settings tab, click on connection
vpn16
 
4) Then click on add
vpn17
 
5) In the wizard fill the relevant information and click ok
vpn18

Name – Name of the connection 
Connection Type – Type of the VPN. Most of the time its site-to-site
Virtual Network Gateway – you need to select the relevant virtual network gateway
Local Network Gateway – in here need to select the relevant local network gateway for your connection
Shared Key – This is the pre-shared key you going to use for the VPN configuration
 
6) Once its created it’s all about configuring the VPN in your VPN device. 
7) Once connected you can see the status in same page by clicking on connection
vpn19

 
 
Hope this was helpful and if you have any questions feel free to contact me on rebeladm@live.com