Azure AD for the Rest of Us
You don’t have to travel far to see, hear, smell and even touch Azure making its way into the many layers of Microsoft cloud service offers. One clear result; for cloud-based systems and implementations, is that you don’t need the same in-depth knowledge of Active Directory you did back when clouds just meant rain.
I came to this conclusion by accident, so I decided to journey back and explain why it why it took me four years (!) to bump into Azure Active Directory.
A journey always begins with the first step 😊
On a recent project, I was asked to provide the Organization Tenant Id, which - as with any id in the Microsoft universe is a global unique identifier - difficult to find, difficult to read, yet reliably ensuring uniqueness without you having to check it.
In other areas there are friendly names by which, in plain everyday language, you can easily figure out the exact resource or component you are talking about. Not the case in this particular area of this project.
Another item that I needed to provide was the UPN (User Principal Name), which is a concept I had encountered occasionally when configuring the Active Directory Federation Service on a domain.
However, since none of the business requirements in this project had anything to do with these two elements, I decided to take a second step and ask: What do these elements mean in the cloud context? And how have other Active Directory concepts travelled from internal domains up into the clouds?
The good, old, manual way.
- Login into the Azure portal with your credentials, using portal.azure.com (at the time of writing, 2018).
- Go to the Azure Active Directory service in the left navigation bar.
- In the Azure Active Directory page, click on Properties and copy the Directory ID, which is in fact the Organization Tenant ID. If you are thinking at this very moment that there are so many different names for the same object, think about the Dev and DevOps teams behind these objects and what they must have gone through to ensure that the deployments on the fly are correct. Also note that in the Office 365 realm an organization is a division in a tenant and in Dynamics 365 an organization is an instance of the D365 platform and/or apps. Now you must be thinking the opposite, too many meanings to one name, and here I go again, think DevOps.
- Now on to the UPN steps, the main authentication method used is username + password, which in the case of Office 365 becomes email and password. For on-premise authentication, you may have to peel the layers of the multi-factor authentication onion and maybe dig into Active Directory Federation Services.
In this section, I will translate the Good, Old, Manual Way into PowerShell. If you have never seen PowerShell before, read on and add a new tool to your toolbox. If you already use PowerShell, add a comment to this post and let me know which PowerShell tool is your favourite. I use the Windows PowerShell ISE for its ability to run one or multiple commands at a time (button pictured).
And the option to add comments to the final code, so that anyone else could retrace my path (the blue line is code, the # sign is a commented line).
Here are the steps to get the Organization Tenant ID:
- Login into your Azure account, using the command Connect-AzureAD -AccountID <your account email>. This command will load the password page configured for your Azure AD under the Company Branding section.
- The result of the command comes back in the format:
- Confirm that the Tenant ID is identical to the one obtained through the good, old, manual way.
- If you receive error on the command, drop me a line and I will help figure out what is missing.
Back to the present
For the past four years I have been using the Azure portal for occasional “save the day” type of components. I used virtual machines, SQL databases, service bus apps, logic apps and never once looked at Azure AD. When I finally looked, I was surprised how many services are weaved into the underlying liners of the front-end apps. Even without an Azure-specific subscription there are many services that are used as part of either Office 365 or Dynamics 365 and a lot of steps are executed behind the scenes in Azure AD when using the Office 365 apps on generic tasks.
This is very deep, deep, deep (3 deeps! not a typo!) server-to-server integration, that goes well beyond server-to-server into service-to-service. And beyond, into if-I-have-this-I-also-get-lots-of-other-stuff-along-with-it-without-an-admin-giving-me-special-access territory.
Let me exemplify how my horizontal discovery journey turned into a Mariana Trench vertical dive, with a couple of examples:
Users and Groups
In Office 365 Admin Center, the users are either licensed users, or guests. However, at the Azure AD level, the guest users are further classified as:
- External Azure AD: if they are recognized within the Microsoft Azure realm, as an invited B2B collaboration user from another tenant.
- Microsoft Account: if they are known in the wider Microsoft consumer market realm through a social identity, which triggers the creation of a user profile in Outlook.com.
- Guest: this is a guest in the classical sense of the word, and their credentials are managed within my organization, independently of other authentication services. This type requires similar admin and maintenance tasks as in an internal network domain. For more details guests, see the B2B comments here. Interestingly enough, guest users can also authenticate using Google identities.
- AD sync-ed to Azure AD: these users are authenticated against their corporate domain which is in turn sync-ed to Azure AD, which provides access to my organization.
The ultimate benefit of these constructs is that the collaboration amongst users from different tenants is streamlined to the actions of the end-users, without the intervention of the admins. If, for example, I would like to add an individual to a MS Teams channel, to work with our team in a particular project, I invite them and all they need to do is accept the invitation. Depending on which credentials are used for the invitation, Azure AD decides which one of the guest types above fits the profile and all the underlying authentication mechanisms and permissions to resources are inferred from the initial invite.
This list contains all the services where my Office 365 credentials are recognized, or applications that are configured to authenticate against Azure AD using different mechanisms.
In legacy applications, the mechanism for maintaining access and permissions was tightly coupled to domain policies and custom code. Additionally, each application had specific access requirements and the infrastructure team or help desk departments had complex processes defined to manage their users. If the applications logic was changed or new processes implemented, we had to work with the infrastructure team to ensure that specific Active Directory assets required by a certain application or environment were configured correctly.
The fact that it took me four years before I needed to dig into Azure AD means that the complexity we had to address in internal domains has been deconstructed and automated.
The hidden benefit is that we no longer need to take care of the menial admin and config tasks - setting up individual policies, security, access and permissions - as these have been baked into the provisioning process. We can safely focus on real business requirements without worry, as Azure AD takes care of things behind the scenes. There is certainly a lot more than meets the eye.
For a long time, Microsoft has been consistent in offering three levels of interaction with their tools
- use as is
- customize to fit
- make your own
Azure AD follows this approach: we can use the built-in authentications and permissions features, we can customize them beyond what is built-in, or we can create new artifacts to implement granular requirements that are not available in the Azure portal.