Next, Crash Test Dummies (users and groups)

Clueless at the portal

A curmudgeon's guide to Azure.

A person in the clouds is poking a blue lgogo with a stick, while looking nervous. Artwork by maxtrella

Welcome to the very first post of my irregular Azure blog.

These posts are about "How to do stuff with Microsoft Azure".

I've split this first post up into 4 parts, feel free to ignore the parts you think you already know (they'll still be here if you get stuck).

The state of it all

About 25 years ago there were still paper publications about computing topics, and one of them was called "The Linux Journal". It was there that Mike List wrote a column entitled "Clueless at the Prompt, A Column for New Users".

Back before ChatGPT, the word "prompt" in computing had nothing to do with AI. Instead, it usually referred to a shell prompt running in a terminal.

Mike's articles were aimed at people who had installed Linux and then found themselves confronted by that mysterious shell prompt for the first time.

These days, I usually have a fairly good idea what to type at that prompt, but the world has moved on, and now I need to interact with other systems, about some of which I am still Clueless.

Why Azure?

Do not buy Azure, do not give Microsoft money.

This is not legal advice, I am not a porcupine.

That said...

(Yes, this makes me a bootlicker / sellout / class traitor / insert expletive here, you got me! Hopefully someone can save some time by learning from my experience, or Future Me can use this to jog my memory about what worked.)

Why Azure?

  • You need users and groups.
  • Entra ID gives them to you.
  • Azure is the only platform that gives you Entra ID.

It's therefore "the only game in town" for "corporate IT".

Allow me to elaborate.

Ever since ancient protohumans first gazed upon the Linux root prompt in wonder, the world of IT has been using some version of Microsoft Active Directory. This is because their users want to use Windows, and Active Directory gives IT administrators an easy way of managing logins to those Windows computers.

Now, more than ever, businesses care about things like user IDs, and groups, and permissions, and multifactor authentication, and role based access control, and all that sort of stuff. And everyone already has a system that does it already: their Active Directory.

Sure, you might have something else driving the data in your Active Directory, managing your business processes, and so on. But the lowest-common-denominator technical interface is pretty much guaranteed to be Active Directory for must business systems in any reasonably large organistaion.

So Microsoft's killer app isn't Windows, or Office, any more. It's Active Directory.

Lucky for us though, Microsoft also play the Public Cloud game. You can buy your VMs and containers and computer and whatnot from them, using Azure, in just the same way as you can from Google or Amazon. But if you buy Microsoft, you can also have Active Directory in the form of Entra ID. You don't even need to run Windows servers any more!

If you buy GCP or AWS or any other public cloud, you can't have Entra ID.

So you are buying Microsoft and running Entra ID. At this point, trying to interact with anything else is a waste of time. Just start talking directly to Entra ID for all your AAA requirements and get on with the stuff in life that you care about.

Ground rules

These are the basics that we'll be working with.

The "non-cloudy" bits we'll be doing will all be based on Python and/or Apache (or similar) running on something Linux-ish.

The dream is to be able to use Azure Entra ID as our login and permissions system, while still running our own open source software on a free platform wherever we want.

Entra ID

Entra ID is the new name for Microsoft's Active Directory running as a service in the Azure public cloud.

You don't have to run the servers yourself, you just click things in the Azure portal (or perhaps do something more devops-y) to set it up.

Entra ID is the focus of my initial Azure investigations, because it's going to underpin user authentication and authorisation for everything else that I do.

For now, we only really care about three things in Entra ID.

  • Users are objects that represent people. That's a slight simplification, but just know that one of the things that exists in Entra ID is a list of users. For example, if you were running a company and you employed staff, each member of staff would probably have a corresponding user object in the Entra ID. There are several possible characteristics by which a user might be identified, but we're going to use an attribute called "User Principal Name" or "UPN". You can think of this as the username. In my Entra ID, all of the users have unique UPNs so we can use this to identify them. I have to enforce this, as an administrator.

  • Groups are sets of users. Groups have their own IDs. A group can contain zero or more users. A user can be in zero or more groups. It is common for a user to be in multiple groups. For example, I might have an employee who is in a "Web Site Updaters" group and also in a "Software Developers" group. We can make up new groups any time we wannt to represent a new set of users, so if we buy a sound system to play music in the office we can create a new "DJs" group and add users to that.

  • Applications. If you want to write an application that will be allowed to interact with your Entra ID, you need to create a registration for that application within the Entra ID itself. We'll use these to create client IDs and client secrets for applications that we want to be able to access information about uers and groups in our Entra ID. Note, this is not "running an app in Azure". That's out of the scope of these first blog posts. In fact, you could set up a beautiful app in Azure without having anything to do with Entra ID, and it would work great, but it wouldn't be able to do any of the things that we want to do with user authentication and authorisation until you also created an Application Registration for it within your Entra ID.

(There's also a type of thing that can exist in Entra ID called a Device but we're going to ignore that for now.)

Tenant

Your Entra Id lives within a Tenant.

A Tenant is an instance of the full stack of Microsoft Azure systems, which has its own control panel - the aforementioned Portal. It is identified by a Tenant ID.

You probably want exactly one tenant per organistaion. For example, a University would ideally have one tenant, and all of the members of the university would use services managed in that one tenant. They might also have a testing tenant as a separate subscription, allowing them to explore configuration changes they want to make before making changes to the production tenant.

From Microsoft's point of view, a Tenant has a one-to-one relationship with an instance of Entra ID. Your tenant has only got one Entra ID directory in it. When you make changes to Entra ID within your tenant, you are making changes that apply to everything else in the tenant.

I paid Microsoft for an Azure tenant of my very own. This is a monthly subscription, and doesn't cost a huge amount, but isn't free either. It's critically important to have full administrator access to a tenant to learn and experiment with all of the features you'll want to use so I strongly encourage you to subscribe to Azure for this reason. Your organisation might well have their own tenant, but if you don't have superuser priviliges to that then you will likely hit roadblocks when developing for Azure.

(I might talk about this some more in a separate post because people generally don't seem to understand why I say this. To summarise: you might well be able to work out the set of permissions needed to perform a certain task in Azure, but you can only generally do that after you've done the task once already so you know what you'll need to do. We're not carrying out well-understood processes according to a checklist here, we're inventing the process and writing the checklist.)

Don't make lots of users and groups in your tenant, because at the time of writing it is billed based on how many of those you have.

The plan is, we'll identify configurations that work in our own private tenant, and then be able to share them with the administrators of the real tenant to which we want to deploy them.

(One other note here: it's possible to make additional (at least more than one) Tenants within the Azure portal while logged in as the same user. I'm going to ignore that. Just always make sure you're connected to your "testing tenant" with your "testing superuser" if you have more than one of either of those.)

Agenda

  • Set up a new, empty Tenant with minimal data to test user and group stuff.
  • Configure an Application Registration to allow us to make queries against the bits of Entra Id that we want to llok at.
  • Query user and group information from Entra ID with Python. We'll use the Graph API to do this, which is possibly the single most important thing you need to know about to do anything useful with Entra ID.

Future work

I've previously used OpenID Connect to allow Entra ID users to log in to our web site. It's probably more fundamentally useful to most people than Graph so I'll probably write that up here next.

To complete a useful setup, we should really tie everything together so that users can log in to our web site and then act according to the permissions that correspond to the groups that they are in. I'd like to cover two different ways of accessing the users' groups to make authorisation decisions.

For extra credit, I'll maybe look at how this can be moved from "click ops" to a more "devops-y" setup using some kind of configuration files, scripting, or other appropriate automation. And / or how best to implement a user sessions framework for a web site that uses Entra ID.

Next, Crash Test Dummies (users and groups)