When is an Azure Arc Server; not an Arc Server? A look at Azure Arc Server Resource types and the lack of feature parity between them
Walk through how to collect SQL counter using Data collection Rule and displaying the results on a workbook an Azure Dashboard.
A look into Azure Arc SQL Extension and how best practices assessment and what it can extract from an Azure Arc enabled SQL Server.
I do understand distributed management and delegation, but this seems like a step too far. There is a new setting that allows users to be able to create their own Azure AD tenants. While it is a great privilege and setting to have, why ‘Yes’ would be the default choice is an interesting default and I would like to understand the rationale behind that.
Save your future self from a number of headaches, just select no.
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 portal.azure.com. 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!
Here are the steps to add additional profiles to Chrome:
Hope you find this useful!
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.
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.
Process Flow Description:
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.
Potential fixes:
Use ADAL.js to retrieve a bearer token for authentication to the Application Proxy endpoint.
Process Flow Description:
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:
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.
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.
There are three general roles that apply to all resource types:
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:
[powershell]
# 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
[/powershell]
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.
If you find that the built-in roles aren’t sufficient, you can create custom roles which will be the topic of Part 2.
There is a hierarchy to containers and resources:
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.
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.
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.
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.
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.
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.
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.
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:
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.
