Azure for the AWS user Part 1 : Identity

AWS, Azure, Identity

I’ve seen a few forum questions lately from AWS users who want to (or have to) use Azure and whilst there are a lot of similar services in either platform, the new user experience and terminology can be very confusing if your used to AWS. This article is the first in a series of posts that I’m hoping will help users coming from AWS get to grips with Azure.

To be very clear, I’m not looking to argue about which platform is best or why you should use one or ther other, I’m simply providing the information an AWS user needs to quickly get a grasp of Azure and relate it to what they already know. I’ll be keeping things pretty high level, I’ll also be focussing on the newer Azure Resource Manager stack for the most part, as this is what I would advise anyone coming new to Azure to use, except where there isn’t an ARM version.

So, for the first part in this series we’ll take a look at identity, which is usually one of the first areas you’ll come up against when trying to gain access to do work in Azure.

AWS IAM and Azure Active Directory

AWS users will be familiar with IAM (Identity and Access Management) as the means to provide user access to AWS, permissions to resources, groups and roles. The Azure equivalent of this is Azure Active Directory  (AAD), don’t be fooled by the name however, it’s not a full blown cloud version of Microsoft’s on premises Active Directory. Whilst it does act as an identity store and authentication provider, it doesn’t have the LDAP functionality of AD or many of the other services (machine join, GPO’s etc.). There is an extension to this that we will talk about later that adds some of this, but for now think of it as an identity store for Azure.

As an Azure administrator you can create multiple different AAD identity stores (usually referred to as Tenants) which operate independently. When you create Azure resources they will usually be tied to a specific tenant and you can grant users in that tenant access to manage the resources. It is possible to grant users from other tenants access to resources, we will cover how later.

Users

AAD obviously allows you to store users, each user in a tenant can be one of three types:

  • An AAD user created and “homed” in this tenant
  • An AAD user “homed” in another tenant, who has been added to this tenant to access resources
  • An Microsoft account (formerly Live account) which is granted access to this tenant.

The first type of user is the most commonly used, and is directly equivalent to a user created in IAM. The later two are only really used when you need to grant a user that already exists elsewhere (in another AAD tenant, or an MS account) access to resources rather than create a new user.

There are a few more complex concepts that can create users such as AD Sync and Federation, that will be discussed later.

Further Reading: Managing users in Azure Active Directory

Groups

Groups exist in a very similar manner to IAM, you can add user to groups and then assign rights to groups as required.

Further Reading: Managing access to resources with Azure Active Directory groups

Roles

Roles in the sense of IAM Roles that can be assumed by a VM or similar don’t really exist in Azure. What Azure does have is the concept of applications and service principals. Applications are, as the name suggests, a way to register an application to get access to your identities. These can be both applications you have developed your self and off the shelf applications which are built to work with AAD (Office 365, Salesforce etc.). A service principal is an identity assigned to these applications, that will be used by a specific application (or set of applications) to assume and gain access to Azure resources. An application would use the service principal by supplying either a set of keys or a certificate.

Further Reading: Application and service principal objects in Azure Active Directory

Permissions

Azure provides a Role Based Access Control (RBAC) system to allow granting of permissions to resources. Permissions can be granted at the subscription, resource group, or resource level and can be very granular. It is also possible to create your own RBAC roles if the built in ones are not suitable.

Roles are assigned to users, groups or service principals either through the Azure portal, PowerShell or the various API’s. It should be noted that RBAC is applied through the new portal (portal.azure.com), and requires a resource to have implemented them, but most have now. In the days of using the old portal (manage.windowsazure.com) RBAC did not exist and users could only be granted full administrator rights. If you need a user to manage a service with does not support RBAC you will need to assign them rights through the old portal, see the managing resources section.

Further Reading: Get started with access management in the Azure portal

Managing Resources

Use, Group and Permission management can be undertaken from the Azure Portal. As mentioned before, there are two portals you can access, the new one (portal.azure.com) which you want to use whenever possible, and the old one (manage.windowsazure.com), which unfortunately you may still have to use for some services. Azure AD is one of the last services to move out of the old portal, and some of the services are still there. Fortunately, user and group creation and permission management can all be done through the new portal, simply go to “more services” on the left menu bar and search for “Azure Active Directory”

This will open the AAD blade and from here you can mange users, groups etc.

Should you need to grant users access to manage resources in the old portal, you will need to connect to manage.windowsazure.com, then go to the settings section, click on administrator and then click the Add button. This user will have full admin rights on all resources in that subscription.

Domain Names

By default when you create an AAD tenant you will get a domain name of something.onmicrosoft.com, this will be used as the suffix for all user login accounts. If you would prefer to use a custom domain name you can set-up Azure AD to use this. At the time of publishing this article this needs to be done through the old (manage.windowsazure.com) portal, but I imagine it will be available in the new portal soon.

Programmatic Access

Like IAM, AAD has a programmatic API that can be used to query AAD using REST, including using it as an authentication provider for your own apps. This is referred to as the Graph API.

Further Reading: Operations overview | Graph API concepts

AWS AD Connector and Azure AD Connect

Both AWS and Azure provide a way to bring your on premises identity into the platform rather than manually creating users and groups. Azure does this through Azure AD Connect. AD connect provides a few services:

  • User Sync – the simplest approach is to run this tool on a server and have it regularly sync users and groups from on premises to Azure, this can include password hashes if you wish. Users can then use their on premises credentials when presented with an AAD login.
  • Federation – this is a second, optional, step that can be applied to federate your on premises domain to AAD. This then allows for true single sign on to AAD resources
  • Pass-through – This is a very new preview feature that allows you to pass user authentication requests from AAD straight through to your on prem AD, so no syncing required, passwords always remain on premises.

Further Reading: Integrating your on-premises identities with Azure Active Directory

What is Azure AD Pass-through Authentication

AWS Directory Service and Azure AD Directory Services

I mentioned earlier that AAD does not provide all the services of on premises AD, including LDAP etc. Azure AD Directory Services (AAD DS) is the Azure equivalent of AWS Directory Service, it provides an extension to AAD that adds basic domain controller functionality to AAD, this includes:

  • LDAP Support
  • Machine Join
  • Simple Group Policy
  • Organisational Units

AAD DS does have a number of limitations, which I discuss in more detail in this article, so don’t assume that this can just be a replacement for your on premises domain controllers.

Further Reading: Active Directory Domain Services Documentation

Useful Articles

Azure AD Documentation
What is Azure Active Directory
Enterprise Mobility and Security Blog

That’s a very high level overview of the identity services in Azure AD, hopefully this give you enough information to get started and an idea of the right places to look to get more information.

In part 2 of this series we will look at IaaS and Virtual machine services and how they compare.