Azure for the AWS User (Part 1): Identity
If you've been an AWS fan, you might find yourself taking a peek at Azure's offerings. This handy guide will translate AWS' IAM roles and security into Azurese.
Join the DZone community and get the full member experience.Join For Free
fi've seen a few forum questions lately from aws users who want to (or have to) use azure, and while 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 the other, i'm simply providing the information an aws user needs in order to quickly get a grasp of azure and relate it to what they already know. i'll be keeping things pretty high level, and 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, gpos, 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.
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.
- a 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 exist in a very similar manner to iam, you can add users to groups and then assign rights to groups as required.
further reading: managing access to resources with azure active directory groups
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 yourself 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
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 .
user, 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 manage 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.
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.
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.
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 .
that's a very high-level overview of the identity services in azure ad. hopefully, this gave 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.
Published at DZone with permission of Sam Cogan, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.