Virtualization - Cloud

Author: Ram Prasad (Page 4 of 8)

What is Azure Role Based Access Control (RBAC) and how it works

What is RBAC?

When it comes to identity and access, most organizations that are considering using the public cloud are concerned about two things:

  1. Ensuring that when people leave the organization, they lose access to resources in the cloud.
  2. Striking the right balance between autonomy and central governance – for example, giving project teams the ability to create and manage virtual machines in the cloud while centrally controlling the networks those VMs use to communicate with other resources.

Azure Active Directory (Azure AD) and Role-Based Access Control (RBAC) work together to make it simple to carry out these goals.

Azure subscriptions

First, remember that each Azure subscription is associated with a single Azure AD directory. Users, groups, and applications in that directory can manage resources in the Azure subscription. The subscriptions use Azure AD for single sign-on (SSO) and access management. You can extend your on-premises Active Directory to the cloud by using Azure AD Connect. This feature allows your employees to manage their Azure subscriptions by using their existing work identities. When you disable an on-premises Active Directory account, it automatically loses access to all Azure subscriptions connected with Azure AD.

What is RBAC?

Role-based access control (RBAC) is an authorization system built on Azure Resource Manager that provides fine-grained access management of resources in Azure. With RBAC, you can grant the exact access that users need to do their jobs. For example, you can use RBAC to let one employee manage virtual machines in a subscription while another manages SQL databases within the same subscription.

What is role-based access control?

You grant access by assigning the appropriate RBAC role to users, groups, and applications at a certain scope. The scope of a role assignment can be a subscription, a resource group, or a single resource. A role assigned at a parent scope also grants access to the child scopes contained within it. For example, a user with access to a resource group can manage all the resources it contains, like websites, virtual machines, and subnets. The RBAC role that you assign dictates what resources the user, group, or application can manage within that scope.

The following diagram depicts how the classic subscription administrator roles, RBAC roles, and Azure AD administrator roles are related at a high level. Roles assigned at a higher scope, like an entire subscription, are inherited by child scopes, like service instances.

In the preceding diagram, a subscription is associated with only one Azure AD tenant. Also note that a resource group can have multiple resources but is associated with only one subscription. Although it’s not obvious from the diagram, a resource can be bound to only one resource group.

What can I do with RBAC?

RBAC allows you to grant access to Azure resources that you control. Suppose you need to manage access to resources in Azure for the development, engineering, and marketing teams. You’ve started to receive access requests, and you need to quickly learn how access management works for Azure resources.

Here are some scenarios you can implement with RBAC.

  • Allow one user to manage virtual machines in a subscription and another user to manage virtual networks
  • Allow a database administrator group to manage SQL databases in a subscription
  • Allow a user to manage all resources in a resource group, such as virtual machines, websites, and subnets
  • Allow an application to access all resources in a resource group

RBAC in the Azure portal

In several areas in the Azure portal, you’ll see a pane named Access control (IAM), also known as identity and access management. On this pane, you can see who has access to that area and their role. Using this same pane, you can grant or remove access.

The following shows an example of the Access control (IAM) pane for a resource group. In this example, ramtest has been assigned the Backup Operator role for this resource group.

How does RBAC work?

You control access to resources using RBAC by creating role assignments, which control how permissions are enforced. To create a role assignment, you need three elements: a security principal, a role definition, and a scope. You can think of these elements as “who”, “what”, and “where”.

1. Security principal (who)

security principal is just a fancy name for a user, group, or application that you want to grant access to.

2. Role definition (what you can do)

role definition is a collection of permissions. It’s sometimes just called a role. A role definition lists the permissions that can be performed, such as read, write, and delete. Roles can be high-level, like Owner, or specific, like Virtual Machine Contributor.

Azure includes several built-in roles that you can use. The following lists four fundamental built-in roles:

  • Owner – Has full access to all resources, including the right to delegate access to others.
  • Contributor – Can create and manage all types of Azure resources, but can’t grant access to others.
  • Reader – Can view existing Azure resources.
  • User Access Administrator – Lets you manage user access to Azure resources.

If the built-in roles don’t meet the specific needs of your organization, you can create your own custom roles.

3. Scope (where)

Scope is where the access applies to. This is helpful if you want to make someone a Website Contributor, but only for one resource group.

In Azure, you can specify a scope at multiple levels: management group, subscription, resource group, or resource. Scopes are structured in a parent-child relationship. When you grant access at a parent scope, those permissions are inherited by the child scopes. For example, if you assign the Contributor role to a group at the subscription scope, that role is inherited by all resource groups and resources in the subscription.

Role assignment

Once you have determined the who, what, and where, you can combine those elements to grant access. A role assignment is the process of binding a role to a security principal at a particular scope, for the purpose of granting access. To grant access, you create a role assignment. To revoke access, you remove a role assignment.

The following example shows how the Marketing group has been assigned the Contributor role at the sales resource group scope.

RBAC is an allow model

RBAC is an allow model. What this means is that when you are assigned a role, RBAC allows you to perform certain actions, such as read, write, or delete. So, if one role assignment grants you read permissions to a resource group and a different role assignment grants you write permissions to the same resource group, you will have read and write permissions on that resource group.

RBAC has something called NotActions permissions. Use NotActions to create a set of allowed permissions. The access granted by a role, the effective permissions, is computed by subtracting the NotActions operations from the Actions operations. For example, the Contributor role has both Actions and NotActions. The wildcard (*) in Actions indicates that it can perform all operations on the control plane. Then you subtract the following operations in NotActions to compute the effective permissions:

  • Delete roles and role assignments
  • Create roles and role assignments
  • Grants the caller User Access Administrator access at the tenant scope
  • Create or update any blueprint artifacts
  • Delete any blueprint artifacts

Difference between Active Directory Domain Services (AD DS), Azure Active Directory(Azure AD) and Azure Active Directory Domain Services (Azure AD DS)

To provide applications, services, or devices access to a central identity, there are three common ways to use Active Directory-based services in Azure. This choice in identity solutions gives you the flexibility to use the most appropriate directory for your organization’s needs. For example, if you mostly manage cloud-only users that run mobile devices, it may not make sense to build and run your own Active Directory Domain Services (AD DS) identity solution. Instead, you could just use Azure Active Directory.

Although the three Active Directory-based identity solutions share a common name and technology, they’re designed to provide services that meet different customer demands. At high level, these identity solutions and feature sets are:

Active Directory Domain Services (AD DS) 

Enterprise-ready lightweight directory access protocol (LDAP) server that provides key features such as identity and authentication, computer object management, group policy, and trusts.

AD DS is a central component in many organizations with an on-premises IT environment, and provides core user account authentication and computer management features.

For more information, see Active Directory Domain Services overview in the Windows Server documentation.

The Active Directory Domain Services (AD DS), is the traditional on-premises version of domain services provided by AD. Organizations use AD DS to centrally manage all their resource objects, such as users, computers, printers, shared folders, groups, organizational units (OUs), etc. These objects are part of the Active Directory domain, which allows the administrators to securely manage them through Group Policies. Some of the key features offered by AD DS includes:

  1. One-premises identity & authentication
  2. User and computer management
  3. Group Policies
  4. Domain trusts

AD DS is managed by the organizations on-premises. The Enterprise Administrators are responsible for managing AD DS domain controllers, AD sites, trust relationships between the domains, Group Policies, backing up and restoring AD DS, etc.

NOTE: In this article, the terms traditional AD and traditional AD DS, refer to the on-premises deployment of Active Directory and Active Directory Domain Services.

Azure Active Directory (Azure AD)

Azure Active Directory (Azure AD) is the Azure solution for identity and access management. Azure AD is a multitenant, cloud-based directory and identity management service from Microsoft. It combines core directory services, application access management, and identity protection into a single solution.

Cloud-based identity and mobile device management that provides user account and authentication services for resources such as Office 365, the Azure portal, or SaaS applications.Azure AD can be synchronized with an on-premises AD DS environment to provide a single identity to users that works natively in the cloud.

Azure AD offers some of the same features in the cloud, as AD DS offers on-premises. However, just because they both have AD in their names, doesn’t mean they are identical services. Azure AD is a cloud-based identity service that offers the following:

  1. Cloud-based identification & authentication
  2. User and computer management
  3. Mobile Device Management (MDM)
  4. Access to Software as a service (SaaS) applications, Microsoft Azure portal, and Office 365 services

Because Azure AD is hosted and managed by Microsoft in the cloud, organizations don’t have direct access to AD domain controllers the way they do in their on-premises environment. Microsoft exposes parts of the Azure AD to organizations through the web-based interface so they have enough control to run and customize the services, but Microsoft is responsible for managing the services and servers behind the scenes in its datacenters across the globe.

Azure Active Directory Domain Services (Azure AD DS) 

Provides managed domain services with a subset of fully-compatible traditional AD DS features such as domain join, group policy, LDAP, and Kerberos / NTLM authentication.

Azure AD DS integrates with Azure AD, which itself can synchronize with an on-premises AD DS environment. This ability extends central identity use cases to traditional web applications that run in Azure as part of a lift-and-shift strategy.

The Azure AD DS is a managed AD DS service in the cloud. In other words, if you want the traditional AD DS running in the cloud, you can take advantage of the Azure AD DS service by running AD DS under Azure AD. This means that you will be able to use traditional AD DS features, such as Kerberos and NTLM authentication, Group Policies (which aren’t supported in Azure AD), LDAP, etc.

For organizations who are interested in running traditional AD DS services in the cloud, Microsoft offers a couple of methods. You can either use a managed domain or a self-managed domain. Here’s the difference.

Managed Domain

managed domain is something that you will create in the cloud using AD DS and Microsoft will create and manage the associated resources as necessary.

Self-Managed Domain

self-managed domain is an AD DS environment that you can create in the cloud using the traditional tools. For example, you will use Virtual Machines (VMs) to install the AD DS domain controllers, member servers, etc. This is a self-managed domain so you (not Microsoft) will be responsible for managing the domain just like you do in your on-premises environment.

With Azure AD DS, the core service components are deployed and maintained for you by Microsoft as a managed domain experience. You don’t deploy, manage, patch, and secure the AD DS infrastructure for components like the VMs, Windows Server OS, or domain controllers (DCs).

Azure AD DS provides a smaller subset of features to traditional self-managed AD DS environment, which reduces some of the design and management complexity. For example, there’s no AD forests, domain, sites, and replication links to design and maintain. For applications and services that run in the cloud and need access to traditional authentication mechanisms such as Kerberos or NTLM, Azure AD DS provides a managed domain experience with the minimal amount of administrative overhead.

When you deploy and run a self-managed AD DS environment, you have to maintain all of the associated infrastructure and directory components. There’s additional maintenance overhead with a self-managed AD DS environment, but you’re then able to do additional tasks such as extend the schema or create forest trusts.

Azure AD DS and Azure AD

Azure AD lets you manage the identity of devices used by the organization and control access to corporate resources from those devices. Users can also register their personal device (a bring-your-own (BYO) model) with Azure AD, which provides the device with an identity. Azure AD then authenticates the device when a user signs in to Azure AD and uses the device to access secured resources. The device can be managed using Mobile Device Management (MDM) software like Microsoft Intune. This management ability lets you restrict access to sensitive resources to managed and policy-compliant devices.

Traditional computers and laptops can also join to Azure AD. This mechanism offers the same benefits of registering a personal device with Azure AD, such as to allow users to sign in to the device using their corporate credentials.

Azure AD joined devices give you the following benefits:

  • Single-sign-on (SSO) to applications secured by Azure AD.
  • Enterprise policy-compliant roaming of user settings across devices.
  • Access to the Windows Store for Business using corporate credentials.
  • Windows Hello for Business.
  • Restricted access to apps and resources from devices compliant with corporate policy.

On an Azure AD-joined or registered device, user authentication happens using modern OAuth / OpenID Connect based protocols. These protocols are designed to work over the internet, so are great for mobile scenarios where users access corporate resources from anywhere.

With Azure AD DS-joined devices, applications can use the Kerberos and NTLM protocols for authentication, so can support legacy applications migrated to run on Azure VMs as part of a lift-and-shift strategy

AspectAzure AD-joinedAzure AD DS-joined
Device controlled byAzure ADAzure AD DS managed domain
Representation in the directoryDevice objects in the Azure AD directoryComputer objects in the Azure AD DS managed domain
AuthenticationOAuth / OpenID Connect based protocolsKerberos and NTLM protocols
ManagementMobile Device Management (MDM) software like IntuneGroup Policy
NetworkingWorks over the internetMust be connected to, or peered with, the virtual network where the managed domain is deployed
Great for…End-user mobile or desktop devicesServer VMs deployed in Azure
FeatureAzure AD DSSelf-managed AD DS
Managed service
Secure deploymentsAdministrator secures the deployment
DNS server (managed service)
Domain or Enterprise administrator privileges
Domain join
Domain authentication using NTLM and Kerberos
Kerberos constrained delegationResource-basedResource-based & account-based
Custom OU structure
Group Policy
Schema extensions
AD domain / forest trusts (one-way outbound forest trusts only)
Secure LDAP (LDAPS)
LDAP read
LDAP write (within the managed domain)
Geo-distributed deployments

Ref: https://docs.microsoft.com/en-us/azure/active-directory-domain-services/compare-identity-solutions

Create Azure RBAC for Admins to manage Windows Virtual Desktop

Most of us have years of experience with Active Directory and delegating rights to Administrators that control the environment. Some enterprises don’t grant Domain Admin rights to all the Administrators.  How does one set up just the right amount of access in Azure for Admins to manage the WVD Spring release?

To answer this question, I started with Role Base Access Control (RBAC). In this scenario, the Administrators will have the Contributor role on the Azure subscription, and the Admin should have the ability to manage other users’ permissions both in Azure and WVD.

Azure uses RBAC to manage resources. A role is a group of permissions.

Azure has many built-in roles; some of the main are Owner, Contributor, and Reader. See here for a list of built-in roles. You can also use PowerShell to get a list with the command: Get-AzRoleDefinition | FT Name,Description

The Owner role has full access to everything, including the ability to delegating access to users.  The Contributor role has the permissions to create and manage resources, even create a new tenant but, cannot delegate access to users. The Reader role can view all but make now changes.

If the Administrator has Owner, the person would have full access to manage all resources, but we don’t want that for our Administrator in this case. We know the Administrator has the Contributor role. However, that means the Administrator does not have the right to delegate access to users. The Administrator will need the ability to add and remove users/groups to WVD.

There are multiple ways to solve this; you can grant the Administrator rights on the individual resource groups.

You can add a custom role. If you are more comfortable with the GUI, select Subscriptions, Access control (IAM), Add custom role.

To make it easier, you can choose to clone a role as a starting point.

The predefined permissions already defined will give you a good starting point.

However, to accomplish the requirements, it will need to be adjusted.

You can add permissions and exclude permissions from the above page, but there are limitations. The better method would be to edit the JSON.

Below is a JSON example:

{
“properties”: {
“roleName”: “Custom_Admins”,
“description”: “Custom Role to allow contribution and access control”,
“assignableScopes”: [
“/subscriptions/subscriptionID”
],
“permissions”: [
{
“actions”: [
“Microsoft.Authorization/roleAssignments/delete”,
“Microsoft.Authorization/roleAssignments/write”,
“Microsoft.DesktopVirtualization/*”
],
“notActions”: [
“Microsoft.Blueprint/blueprintAssignments/write”,
“Microsoft.Blueprint/blueprintAssignments/delete”,
],
“dataActions”: [],
“notDataActions”: []
}
]
}
}

For a list of operations see here

To use the PowerShell to create the custom role using a json file:

New-AzRoleDefinition –InputFile “C:\CustomRoles.json”

This solution is granular and most secure, but it will involve some research and knowledge of JSON. If you are new to Azure, this can be challenging.

So, for this use case since the granular security is not a requirement, the Administrator will be granted two built-in roles that allow for the access needed, not just for WVD but Azure as well.

Windows Virtual Desktop (WVD) Reference Architectures

Below are Azure Windows Virtual Desktop (WVD) Reference conceptual architectures.

WVD Reference Architecture’s -ARM

Reference Architecture -Classic (Non-ARM)

Reference Architecture -Classic (Non-ARM)

Reference Architecture -Classic (Non-ARM)

Reference Architecture -Classic (Non-ARM)

Reference Architecture -Classic (Non-ARM)

Networking Basics: Bits/Subnets/Network Masks

To understand subnetting, you should first understand the decimal and binary structure of an IP address.

Let’s start with the basics. Here’s what an IP address looks like: 192.168.1.20

An IPv4 address is a 32-bit number. To make addresses more straightforward, they are divided into four 8-bit numbers — or octets — separated by a decimal point. These octets range in number from zero to 255.

Why do octets only go up to 255? Because they’re binary.

The biggest IP address possible is 255.255.255.255

In binary, this IP address looks like this: 11111111.11111111.11111111.11111111

Note that there are eight numbers between the decimal points. Each number represents a bit. Hence the term octet or the 8-bit number grouping.

Binary corresponds to this table:

1286432168421

Let’s use this binary number, for example: 10000001

Every 1 in a binary number “turns on” the number in its position. So, 1 in the first and last positions “turn on” 128 and 1.

1286432168421
10000001

Add up all the positions to get the decimal number: 128 + 1 = 129

When all the positions are “turned on,” they add up to 255.

You can see how it works here. These are the most common octets you’ll encounter in subnetting:

1286432168421
25511111111
25411111110
25211111100
24811111000
24011110000
22411100000
19211000000
12810000000

How to define the network portion of a subnet IP address

During the early stages of the internet, organizations assigned IP addresses like crazy until we nearly ran out. Luckily, the designers of IP addressing came up with a way to end this wasteful practice: Dividing networks using subnetting.

The process of taking an extensive network and splitting into smaller networks is known as subnetting — and it’s freeing up more public IPv4 addresses.

There are two parts to an IP address: The network portion and the host portion.

It’s like the address for a house. The network portion is like the city, state, and zip code. The host portion is like the house and street number.

A subnet defines the number of bits, out of 32, used for the “network portion” of the address. Subnet masks can also be defined in a more common ‘slash’ representation, known as CIDR notation. In the following table, the red digits represent the bits used for the network. The black digits will be used for device IP addresses. Note that the 255.0.0.0 mask can also be represented as a ‘/8’ because it reserves 8 bits of the overall 32 bits used to describe an IPv4 address as the network portion.

Bits used for maskDefault netmaskSubnet binary
/8255.0.0.011111111.00000000.00000000.00000000
/16255.255.0.011111111.11111111.00000000.00000000
/24255.255.255.011111111.11111111.11111111.00000000

For example, you might have a network with devices (known as hosts) with the following IP addresses:

Network: 172.16.56.0
Computer 1: 172.16.56.40
Computer 2: 172.16.56.55
Printer 1: 172.16.56.100

In this case, we’re using 24 bits (or three octets) for the network. Notice that every host device in the network has the same first three octets. That’s the network portion of the IP address with a /24 mask.

IP address: 172.16.56.40
Mask: 255.255.255.0
Binary mask: 11111111.11111111.11111111.00000000

The last octet is the host portion of the IP address. That’s where you’d assign your devices. In this case, you could assign up to 254 hosts. (More on that later.)

IP address: 172.16.56.40
Mask: 255.255.255.0
Binary mask: 11111111.11111111.11111111.00000000

Let’s look at the table again. If it were /16, then the first two octets would be the network portion, and the host portion would occupy the last two octets.

/16255.255.0.011111111.11111111.00000000.00000000

If it were an /8 network, then only the first octet would be the network portion.

/8255.0.0.011111111.00000000.00000000.00000000

These are the most common masks because they’re the simplest, but when you need more than one network, you have to subnet. Subnetting enables you to choose the number of bits to use for the Network portion. You can even steal bits from the host portion for the network.

Here’s what the full subnet mask table looks like. In this table, 1s represent the network portion, and 0s represent the host portion.

SlashNetmask1st Octet2nd Octet3rd Octet4th Octet
/30255.255.255.25211111111111111111111111111111100
/29255.255.255.24811111111111111111111111111111000
/28255.255.255.24011111111111111111111111111110000
/27255.255.255.22411111111111111111111111111100000
/26255.255.255.19211111111111111111111111111000000
/25255.255.255.12811111111111111111111111110000000
/24255.255.255.011111111111111111111111100000000
/23255.255.254.011111111111111111111111000000000
/22255.255.252.011111111111111111111110000000000
/21255.255.248.011111111111111111111100000000000
/20255.255.240.011111111111111111111000000000000
/19255.255.224.011111111111111111110000000000000
/18255.255.192.011111111111111111100000000000000
/17255.255.128.011111111111111111000000000000000
/16255.255.0.011111111111111110000000000000000
/15255.254.0.011111111111111100000000000000000
/14255.252.0.011111111111111000000000000000000
/13255.248.0.011111111111110000000000000000000
/12255.240.0.011111111111100000000000000000000
/11255.224.0.011111111111000000000000000000000
/10255.192.0.011111111110000000000000000000000
/9255.128.0.011111111100000000000000000000000
/8255.0.0.011111111000000000000000000000000
/7254.0.0.011111110000000000000000000000000
/6252.0.0.011111100000000000000000000000000
/5248.0.0.011111000000000000000000000000000
/4240.0.0.011110000000000000000000000000000
/3224.0.0.011100000000000000000000000000000
/2192.0.0.011000000000000000000000000000000
/1128.0.0.010000000000000000000000000000000

What are IP address classes?

To complicate things further, IP addresses have five classes, but only three are applicable to subnetting — A, B, C.

Here are the IP address ranges by class:

Class A = 1.0.0.0 to 127.0.0.0

Class B = 128.0.0.0 to 191.255.0.0

Class C = 192.0.0.0 to 223.255.255.0

Remember these IP addresses are represented in binary.

Here are the largest subnet IP addresses in these ranges:

Class A127.0.0.001111110000000000000000000000000
Class B191.255.0.010111111111111110000000000000000
Class C223.255.255.011011111111111111111111100000000

This is important to know because it affects the number of hosts and subnets available in a network.

Notice that Class A addresses provide the most room for host addresses (the black digits). That’s because the network portion only occupies the first octet. Most large enterprises use Class A IP addresses for this reason. You can connect more devices to a Class A network than a Class C.

Class A127.0.0.001111111000000000000000000000000

In every class, you can steal bits from the hosts to create more subnets, but you’re also reducing the number of hosts. Notice how stealing just one bit for the network drops the number of hosts significantly.

Class A Subnet Netmasks and Hosts

Network BitsSubnet MaskNumber of SubnetsNumber of Hosts
/8255.0.0.0016,777,214
/9255.128.0.008,388,606
/10255.192.0.024,194,302
/11255.224.0.062,097,150
/12255.240.0.0141,048,574
/13255.248.0.030524,286
/14255.252.0.062262,142
/15255.254.0.0126131,070
/16255.255.0.025465,534
/17255.255.128.051032,766
/18255.255.192.01,02216,382
/19255.255.224.02,0468,190
/20255.255.240.04,0944,094
/21255.255.248.08,1902,046
/22255.255.252.016,3821,022
/23255.255.254.032,766510
/24255.255.255.065,534254
/25255.255.255.128131,070126
/26255.255.255.192262,14262
/27255.255.255.224524,28630
/28255.255.255.2401,048,57414
/29255.255.255.2482,097,1506
/30255.255.255.2524,194,3022

Class B IP addresses offer fewer hosts than Class A because its network portion occupies the first two octets.

Class B191.255.0.010111111111111110000000000000000

Class B Subnet Netmasks and Hosts

Network BitsSubnet MaskNumber of SubnetsNumber of Hosts
/16255.255.0.0065,534
/17255.255.128.0032,766
/18255.255.192.0216,382
/19255.255.224.068,190
/20255.255.240.0144,094
/21255.255.248.0302,046
/22255.255.252.0621,022
/23255.255.254.0126510
/24255.255.255.0254254
/25255.255.255.128510126
/26255.255.255.1921,02262
/27255.255.255.2242,04630
/28255.255.255.2404,09414
/29255.255.255.2488,1906
/30255.255.255.25216,3822

Class C IP addresses offer the fewest hosts because the network portion occupies three octets.

Class C223.255.255.011011111111111111111111100000000

You might notice that the default IP address your home router uses falls into the Class C category. This is a special subnet reserved for private IP addresses, you can read why in the Network Address Translation article.

Class C Subnet Netmasks and Hosts

Network BitsSubnet MaskNumber of SubnetsNumber of Hosts
/24255.255.255.00254
/25255.255.255.1280126
/26255.255.255.192262
/27255.255.255.224630
/28255.255.255.2401414
/29255.255.255.248306
/30255.255.255.252622

These standards make subnetting a little easier. For example, if you choose a Class ‘C’ address, you know that it uses at least 24 bits (/24) of the 32 available bits for the network portion of the address.

How to subnet in IPv4

Now that we know about classes, binary, and subnets. Let’s dive into a subnet.

Here’s the IP address we’ll use: 43.17.255.71/27

Here’s what it looks like in binary:

00101011.000100011.111111.01000111

From the IP address we already know two things:

  • It’s a Class A IP Address
  • It must have at least eight network bits, but we’re giving it 27 bits

In that case, we know the network portion of the subnet will occupy these bits:

/27255.255.255.22411111111111111111111111111100000

Let’s reverse engineer this last octet to determine the network portion of the address or what the subnet is for this address.

Here’s what we want to do:

  1. Determine the number of allowed subnets using the /27 network mask
  2. Determine what subnet the address lies in

Here’s an example:

1. Determine number of allowed subnets using /27 network mask.

Here’s the binary representation of the possibilities for the last octet with a /27 mask:

000|0 0000001|0 0000010|0 0000011|0 0000100|0 0000101|0 0000110|0 0000111|0 0000
0326496128160192224

This gives us eight possible subnets with the /27 mask.

2. How to determine what subnet your IP address lives

Now, let’s find the subnet address where this IP address resides.

Remember that the IP address is 43.17.255.71

We are only looking at the last octet because the first three octets are the network portion.

43.17.255.71

We just have to take a look at our table again. 71 falls above the 43.17.255.64 subnet and below the 43.17.255.96 subnet. So it belongs in the 43.17.255.64 subnet.

SubnetLast OctetBlock sizeIP Address
10+3243.17.255.0
232+3243.17.255.32
364+3243.17.255.64
496+3243.17.255.96
5128+3243.17.255.128
6160+3243.17.255.160
7192+3243.17.255.192
8224+3243.17.255.224

We now have the subnet for 43.17.255.71: 43.17.255.64.

CIDR Subnets and Calculation

Prefix sizeNetwork maskUsable hosts per subnet
/1128.0.0.02,147,483,646
/2192.0.0.01,073,741,822
/3224.0.0.0536,870,910
/4240.0.0.0268,435,454
/5248.0.0.0134,217,726
/6252.0.0.067,108,862
/7254.0.0.033,554,430
Class A  
/8255.0.0.016,777,214
/9255.128.0.08,388,606
/10255.192.0.04,194,302
/11255.224.0.02,097,150
/12255.240.0.01,048,574
/13255.248.0.0524,286
/14255.252.0.0262,142
/15255.254.0.0131,070
Class B  
/16255.255.0.065,534
/17255.255.128.032,766
/18255.255.192.016,382
/19255.255.224.08,190
/20255.255.240.04,094
/21255.255.248.02,046
/22255.255.252.01,022
/23255.255.254.0510
Class C  
/24255.255.255.0254
/25255.255.255.128126
/26255.255.255.19262
/27255.255.255.22430
/28255.255.255.24014
/29255.255.255.2486
/30255.255.255.2522
/31255.255.255.2540
/32255.255.255.2550
CIDR Subnets/NetMask/Available Hosts
Visual Subnet Calculator – Good One

http://www.davidc.net/sites/default/subnets/subnets.html

Azure AD/Accounts/Tenants/Subscriptions

This post aims to add some sense to the whole Azure account, subscription, tenant, directory layout as well as Azure AD (Azure Active Directory) across both ASM (Classic) and ARM. I will discuss the different administrator roles from an ASM (Azure Service Management) perspective and then take a look at the new changed/updated administrator roles with ARM (Azure Resource Manager).

Access control in Azure starts from a billing perspective. The actual owner of an Azure account – accessed by visiting the Azure Accounts Center – is the Account Administrator (AA). Subscriptions are a container for billing, but they also act as a security boundary. No matter ASM or ARM, every Azure subscription has a trust relationship with at least one Azure AD instance. This means that a subscription trusts that directory to authenticate users, services, and devices. Multiple Azure subscriptions can trust the same directory, but a subscription trusts only one directory.

As for the directory, the directory that Azure uses is Azure AD. Azure AD is a separate service on its own which sits by itself and is used by all of Azure (ASM & ARM) and also Office 365. Even though there is one Azure AD, there are two subscription/authentication modes of Azure.

If you signed up to Azure using a Microsoft account, then you will get Azure with a Default Directory which you can see in the classic portal.

2016-06-01

This Default Directory is just like normal Azure AD, however you can’t add anyone to any ASM/ARM Azure administrator role picked from this Default Directory itself, you can only add people to ASM/ARM Azure administrator roles using their Microsoft Accounts.

The opposite to this, if you signed up to Azure using the alternative methods then you can add people to ASM/ARM Azure administrator roles using both their Microsoft Accounts and/or Organisational Accounts. Until recently, you could only sign up for a new Microsoft Azure subscription using your Microsoft account (Windows Live ID). Azure now supports using either of the following two account methods to sign up: Microsoft Accounts or Work or school accounts, see https://azure.microsoft.com/en-us/documentation/articles/sign-up-organization/

2016-05-31_1505

However if you do have the limited Default Directory, you can create a new Azure AD directory under the subscription, then you can change the default directory in which the Azure subscription uses. This will then allow you to add both Work/School and Microsoft Accounts. How? See https://support.microsoft.com/en-au/kb/2969548

There are separate roles for Azure AD as follows, remember these have nothing to do with Azure itself. The following are the different Directory Administrator roles.

  • Global Administrator
  • Billing Administrator
  • Service Administrator
  • User Administrator
  • Password Administrator

Then there’s Azure itself. With Azure there’s the subscription to Azure itself which is more of a billing thing, this is where Azure based roles come in.

The Azure based roles are slightly different considering what Azure platform you are using, whether ASM(Azure Service Management (Classic)) or ARM (Azure Resource Management).

ASM (Azure Service Management (Classic))

Remember, depending on how you signed up with Azure, you can add both Organisational Accounts to these roles as well as Microsoft Accounts, or just Microsoft Accounts.

  • Account Administrator
  • Service Administrator
  • Co-Administrator

Each subscription has a Service Administrator (SA) who can add, remove, and modify Azure resources in that subscription. The default SA of a new subscription is the AA, but the AA can change the SA in the Azure Accounts Center.

Subscriptions have an association with a directory. The directory defines a set of users. These can be users from the work or school that created the directory or they can be external users e.g. Microsoft Accounts. Subscriptions are accessible by a subset of those directory users who have been assigned as either Service Administrator (SA) or Co-Administrator (CA); the only exception is that, for legacy reasons, Microsoft Accounts (formerly Windows Live ID) can be assigned as SA or CA without being present in the directory.

Azure Subscription Layout

This diagram takes a step above the Azure Account / Tenant level into the Enterprise EA level just so you can see the overall perspective from the entire hierarchy. However, many of you would be setup with Azure in the middle (account) level by possibly using a credit card or other type of licensing. Or some might be setup with the bottom level only in the case of CSP licensing.

Here’s the reference URLs I got the information from:

How Azure subscriptions are associated with Azure Active Directory
Understanding resource access in Azure

ARM (Azure Resource Management)

How does the above ASM based Classic roles tie in with Azure Resource Manager roles? Remember, Azure AD remains the same with the same Directory Administrator roles, the difference being the different administrator roles on the Azure ARM platform.

2016-05-27_1656

The built-in core roles are as follows and have no affiliation or access to ASM:

Owner: Let’s you manage everything, including access to resources

  • Closest ASM match: Service Administrator

Contributor: Let’s you manage everything except access to resources

  • Closest ASM match: Co-Administrator

Reader: Let’s you view everything, but not make any changes

AzureARMroles

Azure Enterprise Enrolment – Hierarchy

The Enrolment

Managed using http://ea.azure.com

At the very top-level from a licensing perspective, you can have multiple Azure Enrolments, here you can select the enrolment you want to work with. You need to be an Enterprise Administrator to access this. There can be an unlimited number of Enterprise Administrators.

Azure Enrollment

The other thing you need to do is change the Enrollment Authentication Level to ‘Mixed Account‘ so that you have the ability to add both Microsoft Accounts and/or Work or School accounts as Account Administrators.

Azure EA Auth Level
2016-06-03_1056

The Department

Also managed using http://ea.azure.com

Once you select the Enrolment you are working with, you then select ‘Department‘ at the top. This is where you can see all the departments in which you are the Department Administrator for and you can setup more departments which can be setup as a logical segmentation of a company or application.

The Department

The Account

The Account

To save some confusion, this part is not a generic account (like what a department and subscription is), but more so an individual account for a person, who will ultimately become the Azure Account Administrator. The AA can manage and setup Azure subscriptions, at which point will also become – by default – the Service Administrator for the subscription as well at the time of subscription creation.

Notice, this part is managed using two portals.

You will use http://ea.azure.com only to first setup the Account Administrator under the relevant department, whether it be a Microsoft Account or a Work/School (Organisational) account, this is where you do it.

2016-06-03_1015

At this stage, once you add in the account, it can take up to 24 hours for it to actually add itself in and will sit at ‘pending‘ for a while.

2016-06-03_1010

Once it goes through and gets setup, the email you used when adding the Azure account administrator, that person will get an email to acknowledge being added as an Azure account administrator with a link to logon to the Azure Account portal.

20181017-azure-account-administrator-addition.png

You can speed up the process, if you get the new Azure account administrator to logon to http://ea.azure.com with their account, it will ask them to confirm – with a warning. If the new Azure account administrator has other subscriptions anywhere else e.g. Pay-As-You-Go, then these will all get transferred to under the EA at this time including all billing for the Azure subscription, so be careful!!! If the new Azure account administrator doesn’t manage any Azure subscriptions, then you don’t really need to worry about the warning.

Please note: at this point, even through that adding a work/school account from an Azure AD directory is an option, the ‘directory‘ doesn’t have to have any affiliation with the EA, nor does the Microsoft Account. In saying this, you can use an account from a new Azure AD directory, or an existing Azure AD directory, e.g. if you are using Office 365 and AD Connect to sync on-prem accounts to Azure AD, you can use any of these accounts.

Once the account has been completed being setup, the Account Administrator will get an email.

The Subscription

All Azure subscriptions can then be created and managed by the Account Administrator and this is all done by using the Azure Account portal  http://account.windowsazure.com  then by clicking on ‘Account‘ at the top.

Azure Account

From here you will notice you have the option of adding a new subscription.

Or, you can edit an existing subscription. If you click on an existing subscription, by default all Azure Enterprise based subscriptions are named ‘Microsoft Azure Enterprise‘. You have the option to ‘Edit Subscription Details‘.

2016-06-03_1031

Here you can rename the Azure subscription or rename the Azure subscription in the Azure portal. Also under ‘Edit Subscription Details‘ you change the Service Administrator to someone else. Remember that with all new Azure subscriptions which are created by the Account Administrator, Azure stamps the Account Administrator as the Service Administrator by default, this is where you change that.

The Azure Hierarchy

And this is the whole thing visually.

Enterprise Enrollment Hierarchy

A few pointers:

As long as you remember that an Azure directory (also referred to as AAD/Tenant) is totally separate to the Azure subscription.

Imagine you wanted to transfer an Azure Subscription from PAYG to an EA while keeping the existing directory.

  • You would follow this article, tick Retain this subscription within my Azure AD – however the account owner you are transferring it to, this person would need to exist in the current tenant attached to the incoming subscription otherwise they would get another error The requester has specified that the subscription be retained within their organization. Please contact the requester and ask them to either update their request or add you to their organisation….

Imagine you had your EA set to Microsoft Account mode and you wanted to add a new Accountwhich was a Work or School account.

  • You would get an error like this: The login information provided is not a valid user. If you believe you have received this message in error, please contact customer support. Simply change the EA to be set for Work or School Account Cross Tenant authentication. If you have Microsoft accounts already setup as other account owners, this won’t break these accounts.

MS SQL AlwaysOn Availability Groups Implementation: Step by Step Process

An availability group supports a failover environment for a discrete set of user databases, known as availability databases that fail over together. An availability group supports a set of primary databases and one to eight sets of corresponding secondary databases. Secondary databases are not backups. Continue to back up your databases and their transaction logs on a regular basis.

Always ON Availability Group technology is based on Mirroring Technology. Availability Group is improved version of Mirroring. Availability Group is a HA (High Availability) and DR (Disaster Recovery) solution.

Prerequisites required to enable SQL Server 2012 Always On Availability Groups

  • Dedicated domain user account be created for use by the SQL Server service. This should just be a regular or domain account 
  • Having separate accounts for SQL Agent service, SSRS, SSIS & SSRS. Having separate account is more secure and resilient, since a problem with one account won’t affect all of the SQL Server Services 
  • Both SQL & OS Editions, Versions should be at same level on all participating nodes
  • Always on availability groups is only supported in Enterprise edition starting from SQL server 2012 ( except SQL 2016 it supports basic availability group in standard edition)
  • Recommend to have same collation on all replicas
  • Create shared network share on all participating nodes
  • Make sure your databases are in Full Recovery Mode, not Simple or Bulk Logged
  • Databases included in your AlwaysOn group must be user databases. System databases cannot participate in AlwaysOn Availability Groups.
  • Make sure full backups of each of your databases are made prior to installing AlwaysOn
  • No cluster shared volume is required for Always on, it can be configured in local disks
  • Make sure you have a seperate NIC’s for public and private communication
  • Additional NIC is required if you want to isolate always on replication traffic to dedicated NIC
  • Make sure you have two free IP’s each for windows cluster IP and Always on listener IP

Note: (Additional Points to consider)

  • Nodes in cluster (Ex: here 2 servers) must have drives of the same size and with the same name. There must be the same paths inside the drives. The reason is that; To get a database to SQL Server Availability Group, it is more convenient to have the same drives and paths on the secondary server
  • The Windows Cluster Account (Windows Cluster’s name) installed on these 2 servers needs to be granted the Create Computer Object privilege in the OU (Organization Unit) where these 2 servers reside in Active Directory.
  • If you do not give Create Computer Object permission to Windows Cluster, you will get an error as below when creating a listener. The WSFC cluster could not bring the Network Name resource with DNS name ‘XXXXX’ online. The DNS name may have been taken or have a conflict with existing name services, or the WSFC cluster service may not be running or may be inaccessible. Use a different DNS name to resolve name conflicts, or check the WSFC cluster log for more information
  • Create file share for backups and replicas: If you’ve ever setup log shipping you know you have to have a file share on a server and this is the same for this new feature. Create a file share on one of the servers and give read/write access to all your service accounts. Once clustering is setup, 2012 is installed and configured, we can create our first Availability Group for Always On.

AlwaysOn Availability Groups require a Windows Server Failover Cluster, we first need to add the Windows Failover Cluster Feature to all the nodes running the SQL Server instances that we will configure as replicas

We have two node windows failover cluster SQL1 & SQL2 already setup as shown in below screenshot.

Once you have installed failover cluster we can now proceed with enabling the AlwaysOn Availability Groups feature in SQL Server 2012. This needs to be done on all of the SQL Server instances that you will configure as replicas in your Availability Group.

First, we need to enable Always ON Availability Group on two instances. If you do not activate, you will receive an error as follows.

The AlwaysOn feature must be enabled for the server instance” before you can create an availability group on this instance..

To enable Always On Availability Group, we open SQL Server Configuration Manager with Run As Administrator. In SQL Server Services, we right-click on the instance and click properties.

In the tab that opens, select AlwaysOn High Availability, click Enable AlwaysOn Availability Groups and click OK to activate Always On Availability Group. We need to perform this process on the two servers for Always On Availability Group. This will require a service restart. You can restart your sql server services in a controlled manner.

After activating Always On Availability Group in two servers, we click New Availability Wizard from AlwaysOn High Availability on SSMS as follows.

We need to give a name to AG in the incoming screen. I named it “IlkAG”. We’re moving forward by clicking next.

In the incoming screen, we select the databases that we will include in AG. The status of the databases that are suitable for receiving AG appears in the form of “Meets prerequisities”. We’re choosing TestDB.

On the next screen, in the Replicas section, click Add to connect to the second instance of Availability Group. Make sure that the instance names are the same. For example, if your primary server is “Server1\Instance1”, your secondary server should be “Server2\Instance1”. In other words, the name of the named instance on both servers is Instance1.

After the connection is complete, you should see a screen as follows.

Since we want to set the AG to be synchronous and automatic failover, we mark the required fields as follows.

For now, we leave Readable Secondary as “No”.

After performing the operations on the Replicas tab, we switch to the Endpoints tab and a screen like the one below is displayed.

.

To set Always On Availability Group, if you use more than one instance on the same server, you will need to use a different endpoint port for each instance. The default endpoint port is 5022.

For example, you have 3 instances. When creating the availability group for the first instance, the default port is 5022. You must change the port from the Enpoint URL when you create a availability group for your second instance. You can use 5023 for the second instance and 5024 for the third instance. We will use port 5023 for the instance in our example.

Then we go to the Backup Preferences tab and we see a screen like the following. This screen asks for the preferred instance to get Backups. You must choose one of them.

Prefer Secondary If there is an active secondary server, automated backups are performed from the secondary server. If there is no active secondary, it is performed from the primary server.
Secondary only All automated backups must be performed from the secondary server.
Primary All automated backups must be performed from the primary server.
Any Replica Backups can be performed from primary and secondary.

I just select Primary and I’m going to the Listener tab without any further changes.

What is Listener?

There should be minimum 2 instance in Always On Availability Group architecture. The application must always go to the server where the database is active. It is the listener that provides this. Listener has a virtual name and a virtual IP. The application does not know the physical names and physical IPs of 2 servers in the Always On Availability Group architecture. The application only knows the listener name or IP.

When the Listener screen opens, we give a virtual name from the “Listener DNS Name” section as follows.

In the Port section, I give the port information that the application will connect to the databases on this AG. In Network Mode, select Static IP and click Add on the bottom and write my virtual IP. Applicants will know this IP as their database IP.

You can ask your network unit for IP. If you give IP that someone else uses, you will have trouble.

I’m proceeding by clicking Next. In the next screen, it asks us how to do the synchronization with the secondary database in the first stage.

If we choose Full;

It will automatically take the full backup and log backup of each database we selected and transfer these backups to the secondary server itself.

This requires a shared folder. Two instance’s SQL server service accounts must have read and write privileges on this shared folder.

If we choose Join only;

We need to manually take full backup and log backup of each database we selected and transfer it to the secondary server before passing this step.

 If we choose Skip initial data synchronization;

We need to manually take full backup and log backup of each database we selected and transfer it to the secondary server.

But we can do this later. I’ve never used this option until now. We’re choosing Full and click next.

On the next screen, necessary checks are performed. If there is a problem, you can solve the problem and click Re-run validation. To solve the problem, you can go back by clicking the Back button and correct the setting you made wrong and click next. There was no problem with our installation.


Click Next and then Finish. In my example, everything except the listener was created correctly.

When we click on Error near to ‘Create Availability Group Listener’ testAG ”, we can see the detail of the error as follows.

I usually set the port of the availability group to be the same as the instance’s port.

In our example, I set a different port to see what would happen if we set a different port from instance to the availability group.

You can see the error below.

Creating availability group listener resulted in an error.

Although it could not create Listener, it created AG. We can define it as described above by clicking Add Listener from the Availability Group Listeners.

The access information you will give to application developers (the database access information that they write to connection strings) is as follows: TestAG,1435 or “IP address you specify when defining a listener”, 1435

You can also connect via SSMS with this way. After the process is complete, you can see that the database is synchronized.

« Older posts Newer posts »

© 2024 Tech Blog

Theme by Anders NorenUp ↑