When working with external organizations or contractors, you may need to grant access to your resources. However, appropriate management of access privileges is just as important as granting them in the first place. Here’s a guide on setting up external users without compromising your organization’s security.
As a consultant working with many different clients, I often need access to the client’s environment in order to get work done – things like deploying resources or checking existing configurations.
I see this all the time: I get full external guest access which somehow never gets revoked. Managing guests and temporary access accounts are something faced by every company, and yet we fail miserably to manage them well.
We have come a long way as an industry over the past 20 years, which have put us in the public cloud, and yet this still remains an issue. Why?
What’s the problem?
The problem is not in creating a new account and granting access. This is easy and we have been doing it for years.
It has gotten even easier with cloud access.
Need an account? Sure – no problem, do you have your Microsoft Account (or LiveID as we know it)? We will grant you access to our Azure subscription!
Not really – you get assigned as a global admin, and it is solved (based on real-life situations, you’ll be surprised to learn how many external people are granted domain admin and global admin privileges in organizations).
Here lies the issue:
- Managing the lifecycle of these accounts. Do we still need it? Is this person still with us or even working for the same company?
- Controlling access to resources and applications. Granting admin accounts is not a solution. It is a way to get into trouble.
- Monitoring account activities and granting access privileges.
It is a broad subject, so let’s focus on the first task.
How to effectively manage external accounts in an organization for Azure cloud access?
Keys to the Kingdom
First: Understand how access to your Azure subscription is being secured and controlled
The 411 on access:
- Azure Active Directory tenant controls access to every resource in the Azure cloud.
- When you start a new Azure subscription using your Microsoft Account, you are in fact creating a small Azure AD tenant where your subscription is rooted.
- Azure AD is where all authentication and access control happens, that’s why it needs to be created first, followed by assigning the Azure subscription to it.
- It is also the place where you manage all the accounts that have access to your subscriptions.
“But I have an Azure AD tenant already. Can I use it?”
Fair question! Yes, of course, you can. This is actually the first step to get your access under control.
Do not use multiple Azure AD tenants to manage your organization’s resources – unless you need to provide strict separation between services. Get them under a single Azure Active Directory. For existing Azure subscriptions you can do this by changing the default directory for the subscription.
Tip #1: Bring all your Azure subscriptions under the management of a single Azure Active Directory tenant. It will make your life much easier… Make it the second step in your operations after creating the Azure subscription.
In this video, I explain the relationship between Azure subscriptions and Azure AD tenant.
Tom Onyszko explaining the different types of Azure accounts.
Right, that’s the first step – getting your Azure subscriptions under control.
Second: Grant your guests or contractors access to it
To do this, you’ll need to provide them with an account or allow them to use their existing account to access your resources.
Which approach is better? Before we answer that, let’s start with the types of accounts available. Your choices are:
1. Azure AD account for your tenant.
You create a dedicated account in your Azure AD tenant with a local username and password. It is similar to any other user in your tenant; you have to manage it and provide a username and password to your guest.
- Pros: Easy to start with, just create one and you are done.
- Cons: You need to manage it in terms of password and lifecycle. It is also the same as any other user account in your tenant. It will grant access to whatever your users have access to.
2. Azure AD account in another tenant
Your guest might already have an Azure AD account from a different organization. Or you can create one in a dedicated tenant which might be invited to join your tenant.
- Pros: In the case of an existing account you don’t force people to remember a new username and password. That is always good.
- Cons: If you use your dedicated tenant for this purpose you will still need to manage the user lifecycle and, depending on the required functionality, some additional licensing might apply.
3. A consumer grade Microsoft Account
You can invite a user with a Microsoft Account to join your Azure AD tenant. These are consumer accounts, so use it as a last resort only.
- Pros: Easy to use, usually they will have one, and they are familiar with it.
- Cons: A consumer account is beyond your control and that of the organization to which this user belongs. No one will shut it down, because an employee can leave the organization and you won’t know what policies are applied to it. Not to mention, “Funny Bear 13” could appear in your directory.
Clearly, the best choice is always to use the option where you have the most control over accounts.
Tip #2: Always use organizational, Azure AD accounts to grant access to your Azure subscription and don’t use a consumer grade Microsoft Account. By doing it this way, you have more control over the accounts which are getting access to your Azure resources.
Third: Managing organizational accounts
So, we’ve eliminated option three. You will only use organizational accounts to grant access to your Azure subscription (good decision!).
But now the question is, should you use a dedicated Azure AD tenant or invite users with their existing accounts? To answer that, I give you the following decision tree:
- The user has an existing Azure AD account in their organization – use it and invite it to your Azure AD.
- This person doesn’t have an Azure AD account – create one in your dedicated Azure AD tenant.
- If you decide not to use a dedicated tenant for one reason or another, create one in your tenant.
Why this order?
Simple. If the user has an existing Azure AD account, it means it’s managed by another organization. This includes password policies, access methods, lifecycle etc.
- It allows a user to access that organization’s resources, so there is a chance that if needed, it will be closed by the first organization and you will not have to worry about this.
- It also lets the user use the same access credentials – fewer passwords are better for security.
- Creating an account puts the headache of managing this account on your head. Do you need it?
Dedicated tenant vs. your current Azure AD?
You might have noticed that I mentioned a dedicated Azure AD tenant a few times here.
If you remember the separated forests in your on-premises environment for managing accounts of external users, then this is basically the same concept.
You can establish a dedicated tenant for managing external accounts – let’s call it partners.predica.pl – through the standard tenant handling your enterprise users for a domain like predica.pl.
Why do it this way?
Separating your guest users from your production tenant gives you an additional layer of control and a security boundary. These users will not get the same access level as the standard users in your organization. You will have to invite them and assign access.
A little more admin overhead for more control. A good tradeoff, if you ask me.
At the dawn of Azure AD and while using the classic portal for managing Azure there was (and still is) an option available to invite guests in the account creation process.
Go to the classic Azure portal, Azure AD management, and start a new user creation process. The first step is to select the type of user or, better said, the source of authority. Your choices are:
- New user in your organization – self-explanatory, you are creating a user in your tenant.
- A user with an existing Microsoft Account – you are inviting a Microsoft Account to join your organization. You don’t want to do this at scale.
- A user in another Microsoft Azure AD directory – adding a user from another Azure AD (I will cover this in a moment).
- A user at a partner company – this is inviting a guest user with an existing Azure AD account.
What is the difference between the last two options? They look pretty similar.
- A user in another Microsoft Azure AD directory – using this option is the same as directly adding a user over a trust to your tenant. It requires admin rights in both tenants. You’re basically doing it in your tenant, then logging on to another tenant, picking up a user, getting back to your original tenant and creating a “reference” to the user you have picked up.
Sounds simple, but the key problem here is to have admin credentials to both tenants. This is rarely the case.
- A user at a partner company – the second option opens a different world for you. You can invite the user to join your tenant without having any access to it. It is using Azure AD B2B feature of the directory. If you pick it, you are provided with the helpful option of uploading a CSV file (I know, right?).
It is 2017, do we need to use the CSV file? Is this the best we can do? Luckily for us – no! We can do better than this.
Azure AD B2B 101
What is Azure AD B2B? Is it a separate type of directory? No, it is a function of Azure AD built to allow one organization to invite a user from another organization to work on the same applications and resources.
Benefits of using Azure AD B2B:
- When you invite users from other organizations, they are created as objects in your directory. However, all account management stays with the original tenant.
- You can granularly control which resources this account has access to in your tenant.
- There is the possibility to enforce your policies on it. If MFA is required to access your resources and it was not done in the original tenant, you can do it on your side.
- You also have an option to use conditional access to manage these accounts’ access to your resources.
You are allowing the user access to your resources and applying your policies, while leaving the responsibility for managing the account lifecycle in its original organization.
Tip #3: Use Azure AD B2B as a way to invite users into your organization and Azure AD tenant for granting them access to your resources and applications.
In the new Azure portal, you can use Azure AD B2B directly from user management.
Go to: Users and groups in the portal, All users and using New guest user.
In this video, I will guide you through the process and explain different options and processes behind the scenes of Azure AD B2B and how you can control usage of this function in your organization.
How To manage users – Azure AD B2B
Getting back to this CSV file – do we have to use it? As you can see – no. CSV, however, allows us to add users in bulk.
In the final version of Azure AD B2B you can still do this, but through an invitation API rather than a CSV file. You can also integrate it into your on-boarding process.
What? API? That means we need to write code! Don’t worry, for those who are not developers, use PowerShell cmdlet.
In this video, I will demonstrate how to use PowerShell to invite guest users into your organization.
PowerShell rescue – inviting guests to the cloud
Tip #4: Build your procedures around inviting guests.
Use an invitation API and PowerShell to automate this task so you don’t have to rely on the manual actions from administrators.
Wrapping it up – real-world use case
This scenario is not a theoretical one. It is what we use and practice on the daily basis at Predica.
Here’s the lowdown on the project we are working on for a manufacturing company:
- Our consultants are working on the delivery of the project which combines Azure services with IoT, Dynamics CRM, and data analytics.
- To work on a project, they need access to the customer’s Azure subscription, SharePoint files hosted on Office 365 and Visual Studio Team services for work items and source code control.
Instead of creating a new set of accounts for them, they were invited to a target directory with Predica accounts using Azure AD B2B and were granted access to the necessary resources. Bam!
With Azure AD B2B they don’t have to maintain separate accounts, and they get the benefit of full SSO to target resources.
We’ll get there! I’ll be taking on each area bit by bit. If you want more, sign up to get my white paper about App Architecture Design. Meanwhile, stay tuned for my upcoming posts!