Azure Active Directory

Using Multiple Azure Identities Simultaneously


Many Azure end users and developers have to deal with the challenges of holding multiple Microsoft and/or Azure Active Directory identities.  At a minimum, you might be like me and have an MSDN account as well as a 1 or more corporate accounts.  There may also be situations where you have development or test tenants and those use separate logins as well.  Another use case is when doing testing and having different users with different roles (i.e. Admin users, basic user, user with no access, etc.) In these situations, it can be painful (or at least annoying) to switch contexts when using those identities on the web since web browsers can only log you into one identity at a time when using sites such as  Have you ever gone to the Azure portal only to realize you last logged in with a different account and then you need to logout and back in with different credentials?  This is a common situation for me, and although it only takes 10 seconds or so to login with different credentials, the frequency this happens makes it quite a hassle.

One solution is to use different browsers for different identities (i.e. one login in Firefox, one login in Chrome).  This may work for 2 or 3 different identities, but it's not ideal since every browser will behave differently and may have different conventions.

The solution I use, which I will detail below is to utilize named profiles within Chrome, which allows for logging into as many identities as needed all at the same time.  No more logout/login hassle!

Step-by-step Guide

Here are the steps to add additional profiles to Chrome:

  1. Within Chrome, click your named profile and select Manage people
  2. Click Add Person on the dialog
  3. Type a name for the profile, select an identifying icon if desired, check or uncheck creating a desktop shortcut and then save
  4. Repeat for as many profiles you wish to utilize.  For example, I have my default which uses corporate production login, a secondary corporate development login as well as my MSDN/Microsoft login
  5. Now when you click on your profile, you have the option of opening a new window for each profile and each window maintains it's own set of cookies, browser history, etc.
  6. Here is an example of all 3 of my profiles being logged into the Azure portal all at the same time

Hope you find this useful!

Claims-to-Windows Identity Translation Solutions and "Considerations" when using AD Application Proxy

Problem Statement:

At one of my consulting engagement this year my team were unable to communicate from a claims aware azure web application via client browser to an on-premise, windows authenticated SOAP endpoint.  To overcome the identity endpoint mismatch, Claims and Windows, we were using the Azure Application Proxy to perform the identity translation. Our problems primarily occur in communicating between the browser and the Azure Application Proxy.  We found multiple potential solutions to solve this problem, but each one has a fatal flaw.  We do not need to solve for every solution, rather we only need 1 to work.

AAD Proxy Problem statement

Solution 1:

Hide an iframe in the page that authenticates to the proxy by hitting a proxy endpoint and performing the redirect dance.  Because the user must first log-in to the application, the iframe can reuse these credentials.

AAD Solution 1


Process Flow Description:

  1. Iframe makes a request to the proxy endpoint (without authentication)
  2. Proxy returns a 302 redirect
  3. Iframe is redirected to AAD login page. Login cookies are submitted to AAD login because application requires authentication.
  4. Login successful returning token
  5. Sends token to proxy
  6. Proxy returns cookie that is valid for the proxy.
  7. Any future calls to the proxy can use the proxy cookie and make successful calls.

This solution works for the majority of cases except…

Fatal flaw: During step 3, if the user has multiple logins to Azure AD the user can not automatically be logged in because AAD returns an HTML to the hidden iframe asking which to use for login.

AAD Solution 1 Multiple login

Potential fixes:

  • Enable home realm discovery (Domain_Hint) for the Application Proxy
    • When enabling domain hints, step 2 will return an updated redirect URL to include an extra parameter, ‘&’. With this extra information in Step 3, the AAD login page can automatically determine which user to login as.  Now the iframe can successfully login and the requests going forward will succeed.
    • Blocker: this feature is not available yet for App Proxy.
  • Use a Smart Link

Solution 2:

Use ADAL.js to retrieve a bearer token for authentication to the Application Proxy endpoint.

AAD Solution 2 Process Flow Description:

  1. ADAL.js calls AcquireToken to requesting a bearer token for the Application Proxy Endpoint.
  2. AAD returns an authentication token.
  3. We make JavaScript calls adding the header “authentication: bearer [token]” so we are properly authenticated to the endpoint.

This solution works for Internet Explorer but in any other browser it fails

Fatal Flaw: When making requests in step 3 with the authentication header, the browser sends a CORs preflight request.  The proxy is not handling the OPTIONS request properly and is returning a 302.

Potential Fixes:

  • Enable CORs on the Application Proxy so that Preflight requests are handled gracefully.
    • Blocker: this feature is not available yet for App Proxy.



We communicated these shortcomings of AAD Application Proxy to Microsoft and hope they would prioritize this feature in next release.  Hope you would be able to customize your design keeping the above solutions and it's shortcomings in mind.

Azure Role-Based Access Control, Part 1


  One of the advantages of the Azure Resource Management (ARM) deployment model is being able to delegate administration, something we couldn’t do under the Azure Service Management (ASM or RDFE) deployment model (see the previous posts on subscriptions and resource groups).  By delegating administrative authority, we can keep the number of subscription admins low and grant access in accordance with the principle of Least Privilege.  This post will walk through using Azure role-based access control (RBAC) to achieve all of this.

Azure RBAC Basics

Built-In Roles

There are three general roles that apply to all resource types:

  • Owner has full access to the in-scope resources
  • Contributor has the same access to in-scope resources as Owner but cannot manage access
  • Reader can only view in-scope resources

In addition to these general roles, there are other built-in roles that are resource-specific.  Microsoft has a list of those roles, but because Azure is changing regularly it’s best to use PowerShell to query for the roles:


# list all of the RBAC roles in the subscription (Get-AzureRmRoleDefinition).Name

# see the actions a specific role is allowed to perform (Get-AzureRmRoleDefinition -Name '<Role Name>').Actions

# see the actions a specific role is *not* allowed to perform (Get-AzureRmRoleDefinition -Name '<Role Name>').NotActions


Azure Active Directory (AD) users and groups can be assigned to any Azure RBAC role.  The Azure AD tenant to which the subscription belongs is the source tenant for users and groups.

Custom Roles

If you find that the built-in roles aren’t sufficient, you can create custom roles which will be the topic of Part 2.

Resource Hierarchy

There is a hierarchy to containers and resources:

  • The subscription is the top-level container that can house resources
  • A resource group (RG) can belong to a single subscription (and can’t span subscriptions)
  • A resource can belong to a single resource group

Any access granted to a parent container is inherited by all children.  For example, an account granted read access at the subscription level can see all resources in the subscription.  By the way, there is no concept of denying access in Azure RBAC, so be very careful and deliberate about granting wide-spread access.

ARM/New Portal vs. ASM/Classic Portal/RDFE

Back in the ASM days, to access an Azure subscription one needed to be a subscription admin (or co-admin).  Those admins are automatically granted subscription owner access in ARM.  However, accounts granted owner access in ARM are not automatically granted subscription co-admin access.  If you have resources that you need to manage that are not yet available in ARM you will still need to manage the co-admins list.  In either case the recommendation is still the same: keep the number of subscription admins (granted either through Azure RBAC or directly through subscription admins) as low as possible.

Azure RBAC in Practice

Recommendations for a resource group strategy were discussed in a previous post, so I won’t rehash that content.  What I do want to talk about is how to implement your strategy.

Creating RGs and Delegating Admin

RGs must be created by an account with subscription owner role.  Once the RG is created an RG owner must be assigned to a user who is the actual owner of the RG (owner as in someone who is responsible for the resources that the RG will contain).  Once that owner has been established additional roles can be added by the new owner.  The advice for RGs is the same as subscriptions: keep the number of owners as low as possible – not everyone who needs access to the RG needs to be an owner of the RG – use Contributor instead.

Managing Roles

To keep the administrative overhead as low as possible, use Azure AD groups to manage role membership.  Create a group and add user accounts to the group.  If you’re syncing your on-premises AD Domain Services (DS) with Azure AD create the group in AD DS and let it sync to Azure AD.  Manage these groups using your existing on-premises user and group management process.

Infrastructure RGs

Contra much of the advice published on the Internet not every service or application should get its own VNet and not every virtual machine (VM) should get its own storage account.  VNets and storage accounts for VM disks (VHDs) are infrastructure resources and need to be managed as such.


Create an RG for the VNets and place all the VNets into that RG.  Create a group, name it something descriptive like Network Consumers, and grant it the Reader and Virtual Machine Contributor roles to the VNet RG.  Any user account in that group will be able to attach VMs to any of the VNets in the VNet RG.

VHD Storage Accounts

Create an RG for the VHD storage accounts and place all the VHD storage accounts into that RG.  Create a group, name it something descriptive like Storage Consumers, and grant it the Reader and Virtual Machine Contributor roles to the VHD storage account RG.  Any user account in that group will be able to use any of the storage accounts in the RG to store a VM’s VHDs.

Saving money in the cloud?


One of the cloud’s big selling points is the promise of lower costs, but more often than not customers who move servers to the cloud end up paying more for the same workload.  Have we all been duped?  Is the promise a lie? Over the past several years the ACE team (the group of experts behind the AzureFieldNotes blog) has helped a number of customers on their Azure journey, many of whom were motivated by the economic benefits of moving to the cloud.  Few take the time to truly understand the business value as it applies to their unique technology estate and develop plans to achieve and measure the benefits.  Most simply assume that running workloads in the cloud will result in lower costs - the more they move, the more they will save.  As a result, management establishes a "Cloud First" initiative and IT scrambles to find workloads that are low risk, low complexity candidates.  Inevitably, these end up being existing virtual machines or physical servers which can be easily migrated to Azure.  And here is where the problems begin.

When customers view Azure as simply another datacenter (which just happens to be in the cloud) they apply their existing datacenter thinking to Azure workloads and they negate any cost benefit.  To realize the savings from cloud computing customers need to shift into consumption-based models and this goes far beyond simply migrating virtual machines to Azure.  When server instances are deployed just like those in the old datacenter and left running 24x7, the same workload will most likely end up costing more in Azure.  In addition, if instances aren't decommissioned when no longer needed it leads to sprawl, environment complexity, and costs that quickly get out of control.

Taking it a step further, customers must also consider which services should continue to be built and maintained in-house, and which should simply be consumed as a service.  These decisions will shape the technical cloud foundations for the enterprise.  Unfortunately, many of these decisions are made based on early applications deployed to Azure.  We call this the "first mover" issue.  Decisions made to support the first app in the cloud may not be the right decisions for subsequent apps or for the enterprise as a whole, leading to redundant and perhaps incompatible architecture, poor performance, higher complexity, and ultimately higher cost.  Take identity as an example:  existing identity solutions deployed in-house are often sacred cows because of the historical investment and specialized skills required to maintain the platform.  Previously, these investments were necessary because the only way to deliver this function was to build your own.  But (with limited exception) identity doesn't differentiate your core business and customers don't pay more or buy more product because of your beloved identity solution.  With the introduction of cloud-based identity, such as Azure Active Directory, companies can now choose to consume identity as a service, eliminate the complexity and specialized skills required to support in-house solutions, and focus talent and resources on higher value services which can truly differentiate the business.

Breaking it down, there are a handful of critical elements that must be addressed for any customer to realize value in the cloud:

  • Business Case:  understand what is valuable to your business, how you measure those things, and how you will achieve the value.  The answers to these questions will be different for every customer, but the need to answer them is universal.  Assuming the cloud will bring value - whether you view value as speed to market, cost reduction, evergreen, simplification, etc. - without understanding how you achieve and measure that goal is a recipe for failure.
  • Cloud Foundations:  infrastructure components that will be shared across all services need to be designed for the Enterprise, and not driven based on the first mover.  Its not unusual for Azure environments to quickly evolve from early Proof of Concept deployments to running production workloads, but the foundations (such as subscription model, network, storage, compute, backup, security, identity, etc.) were never designed for production - you need to spend the time early to get these right or your ability to realize results from Azure will be negatively impacted.
  • Ruthless automation:  standardization and automation underpin virtually every element of the cloud's value proposition and you must embrace them to realize maximum benefit from the cloud.  This goes beyond systems admins having scripts to automate build processes (although that is a start).  It means build and configuration become part of the software development practice, including version control, testing, and design patterns.  In other words, you write code to provision and manage cloud resources and the underlying infrastructure is treated just like software:  infrastructure as code.
  • Operating Model: workloads running in the cloud are different from those in your datacenter and supporting these instances will require changes to the traditional operating model.  As you move higher into the as-a-Service stack (IaaS -> PaaS -> SaaS -> BPaaS etc.) the management layer shifts more and more to the cloud provider.  Introduce DevOps in the equation and the impact to traditional operating models is even greater.  When there is an issue, how is the root cause determined when you don't have a single party responsible for the full stack?  Who is responsible for resolution of service and how will hand-offs work between the cloud provider and your in-house support teams?  What tools are involved, what skills are required, and how is information tracked and communicated?  In the end, much of the savings from cloud can come from transformation within the operating model.
  • Governance and Controls:  If you thought keeping a handle on systems running in your datacenter was a challenge, the cloud can make it exponentially worse.  Self-service and near instantaneous access to resources is the perfect storm for introducing server sprawl without proper governance and controls.  In addition, since cloud resources aren't sitting within the datacenter where IT has full control of the entire stack, how can you be sure data is secure, systems are protected, and the company is not exposed to regulatory or legal risk?

In future posts I'll cover each one of these in more detail to help frame how you can maximize the value of Azure (and how Azure Stack can play an important role) in your cloud journey.




Azure Subscription commercials and layout best practices - From the Vault: Part 1


First, whats an Azure subscription really?

An Azure subscription is the base container into which related resources (similar business and/or technical needs) are grouped together for usage and billing purposes. The key thing about a subscription is its a billing boundary in Azure. See, Microsoft rolls up all the resources in a subscription and sends a single bill for the entire subscription. There is no ability to sub define payment information below the subscription level. Additionally, a subscription is an administration boundary. A subscription co-admin can access any resource within the subscription, and then delegate that access through role based access control as needed.

Now, a little history. Originally a subscription was the only role based access control boundary. either everyone was an administrator of everything in the subscription, or they were a reader, or they had no access at all. This led to a school of thought where subscriptions were created, one for each working group/access boundary. This superuser or nothing access was one of the consistent early failures of the old Azure ASM console approach in a major enterprise. Having to receive 100 bills from 100 subscriptions and reconcile that, as well as have all or nothing access didn't sit well in the enterprise customer market. It didn't help that to separate resources between dev and production (and access rights) meant you separated subscriptions. Further, separate subscriptions meant new networking infrastructure and shared services setup. Each time. This didn't seem right. People started placing brokers and cloud management platforms in front of azure, looking for ways to automate subscription creation, tear down, and bill reconciliation. This waters down the platform to a least common denominator, and doesn't fit well with PaaS.

Fast forward a few years, and azure is picking up steam, and also has a new look and API. In the ARM console (the new portal), this was solved. Azure introduced granular RBAC into not just the console, but the underlying ARM API. The model chosen allows delegation of individual rights and permissions down to the lowest node in the tree (any ARM object) and still allows use of the full API, etc. Further, you can apply policy to any level of the ARM API (we'll cover this in a future post). This switch changes our guidance dramatically, and in fact makes it possible for us to go with a fewer subscription policy.

Less is more

Overall the number of subscriptions should be kept to a minimum, and in many cases a single subscription is adequate and only adding more when it makes sense. Fewer subscriptions means less complexity and overhead.

Several ARM features facilitate a reduced number of subscriptions, especially Role Based Access Control (RBAC), Tagging, NETs/VNET Peering, ARM Policy, and Azure Active Directory (AAD).

  • RBAC allows creation of different access control security models within one subscription.
  • Tagging permits flexibility for billing to be segregated as needed within a single subscription.
  • VNETs and NSGs allow you to segregate traffic within a subscription
  • VNET peering allows you to connect those segregated vnets as needed to a central vnet or an express route connection.
  • ARM Policy allows you to setup restrictions for naming conventions, resource and region usage, images, etc.
  • AAD can be used to grant permissions within the RBAC framework

With the new Azure Resource Model, fewer subscriptions are needed resulting in fewer billing invoices, top level administrators and lower overall complexity. Less is better.

Best Practices

What you should do:

  • Keep subscriptions to a minimum to reduce complexity
  • Segment bills by leveraging Tagging instead of creating more subscriptions (See our tagging post here)
  • Use Resource Groups as a application life cycle container
  • Use Resource Groups to define security boundaries
  • Use RBAC to grant access and delegate administration

What you shouldn't do:

  • Do not create a subscription for each environment Dev/Test/Prod to protect quota and enforce security.
    • Instead leverage the feature Azure Dev/Test Labs capability to ring-fence pools of IaaS capacity for specific dev teams/users if necessary. (Understand the limitations of Dev/Test Labs in its current state)
    • Consider if enforcing quota is necessary. Using ARM Policy, or even an advanced billing system can have the same outcome without the complexity/business pain.
    • Resource limits can modified by Microsoft up to a point, but most limits are well beyond what a typical client would require. For example one current limit is 10,000 VM cores per region per subscription. At present, Storage accounts is the limit most customers hit first, at 250 per subscription. Spend some time on careful management of this resource, but don't go crazy locking it down, 250 is still a lot and that change someday.
  • Do not create multiple subscriptions just to have separate bills for each department.
    • Tagging can be used to separate out cost
    • Separate subscriptions introduces the need for a second set of networking infrastructure, or cross subscription Vnets thru site to site VPNs. While it is possible to do it does increase complexity.
  • Do not use a subscription as the primary method of delegating administration.
    • Subscriptions should be as a very high level administrative container, but that’s it. (e.g. one subscription per IT department in a company with multiple IT departments might make sense).
  • Avoid spanning applications across multiple subscriptions with a single app, even with multiple environments, because it reduces your ability to view and manage all the related items from one place and on one bill.
    • If you must have multiple subscriptions, don't split by dev/test/prod, instead split by groups of apps with the entire app and its related apps contained within a single subscription.
  • Do not proactively split subscriptions based an "eventually" needing more resources.
    • Resource limits are always increasing so by the time you may get close to a limit it would have likely been increased.


A single bill per client is best, leverage tagging to segment the bill

There is a 1:1 relationship between an Azure subscription and its corresponding bill so knowing how IT related expenses are handled internally will be a major factor to consider. For most clients the IT department handles the bill from a central budget. While other clients require the bill to be broken down in order to charge back costs to each business unit. Utilize tags to achieve the desired result.

Be mindful that only the Account administrator can manage billing.

Plans and Offers/Commercials

If you have an Enterprise Agreement with Microsoft, an EA subscription will be the best choice.  

There are many different types of Azure tenant types available (Enterprise, MSDN, Pay-As-You-Go, Free, Sponsorship, etc.). The recommended subscription type applicable to most customers is Enterprise.

Be aware some tenants do not have access to certain service types. For example an EA tenant can not purchase AAD Basic or Premium through the Azure portal, it must be purchased separately thru the EA portal (because it is a per user based service). The same is also true of certain third party services available only through specific tenant type. Before moving forward with a subscription, ensure the commercial construct of the subscription matches the intended use. Sponsorship subscriptions should not be used as the main subscription as you'll need to migrate the resources to another subscription at some point. This is because Sponsorship subscriptions usually have a hard usage cap or time limit. When they reach that cap/limit, they revert to Pay-As-You-Go with no discounts.

Resource Limits

Do not create additional subscriptions planning on growing beyond current resource limits.

Resource limits in Azure change frequently.  Do not use current limits and your anticipated growth to determine the number of subscriptions to deploy. Always have the mindset to have as few subscriptions as possible (ideally one), for as long as possible. Defer adding complexity that may never be needed or not needed for a while.

There are hard limits on how many of a given resource can exist within a subscription. These limits can be raised by Microsoft to a point, but once this point is reached additional subscriptions are required. It is important to note that ARM limits supersede the subscription limits, for example ARM is unlimited number of cores, but the limit is 10,000 VMs per region per subscription. Be aware that many quotas for resources in Azure Resource Groups are per-region, not per-subscription (as service management quotas are).

It is important to keep current on Azure Subscription Limits, and expect them to change frequently. Azure Subscription Limit information is available here.

When you have to separate into multiple subscriptions

Each application should be wholly contained within a single subscription whenever possible. e.g. the Dev/Test/Production environments for an app, across all regions should exist in a single subscription. Next try to place adjacent applications in a single subscription, particularly if they are managed and/or billed with the same people. If you split the app between subscriptions it reduces your ability to view and manage all the related items from one place, and see them on one bill. We have seen cases where clients have separated test/dev/production into separate subscriptions, which adds complexity without value. We don't recommend this now that RBAC and tagging are available.


Again, goal is as few subscriptions as possible. Only add new subscriptions as you need them. Do not proactively split subscriptions based an "eventually" needing more resources. Odds are by the time "eventually" comes the limits will have increased.


A Quick note on Azure Administrators and Co-Administrators

They still exist. Co-Administrators (limit 200 per subscription for ASM, no limit for ARM) - This role has the same access privileges as the Service Administrator, but can’t change the association of subscriptions to Azure directories. Minimize the number of co-admins as much as possible, and use RBAC to grant access on the principle of least privilege. Think of them as the domain admins of your azure account. E.g. they should be restricted to specific tasks that need them.

A Final note on Azure Stack and Azure Pack

Windows Azure Pack uses the ASM/Co-Administrator model, and since you own the whole thing, its not that detrimental to give each group its own subscription.

Windows Azure Stack uses the ARM model. Wile you could give everyone their own subscription, we don't see a reason to deviate from the guidance here within a business unit. Azure Stack subscriptions still need networking, etc. just like an azure subscription. There is a concept of delegated subscriptions (basically nesting) in Stack, but since it doesn't currently translate to Azure, and because RBAC/Resource Group based rights management works well, we simply don't see the need. Instead use multiple subscriptions in stack to peel off resources for groups you truly don't trust, like partners and 3rd party organizations.

This is the first in a series of blog posts discussing the subscription and resource group layout we recommend for large enterprise customers. Wile smaller customers may not hit some of the limits discussed here, its certainly equally relevant and applicable.

Wile this content is primarily written by the author, some guidance is the work of a collection of people within Avanade's Azure Cloud Enablement group.