User Principal name: John
Display name: John Brown
Password: JBrown26 (or can autogenerate)
Click on "Review+Create"
Click on "Create"
A prompt will appear that reads "Successfully created User, John Brown"
John Brown is now a recognized User with a unique Azure identity.
TASK 2: SIGNING INTO THE NEWLY CREATED USER ACCOUNT
As before, type "Microsoft Entra ID" in the search box to open the "Default Directory | Overview" window
Click on "Users" then "All Users"
The arrow shows John Brown as a new profile
Excited, John Brown attempts to log into his account
Username: John@richardochuksgmail.onmicrosoft.com
Current Password: JBrown26
Next, follow the prompts
Now, our intern John Brown is logged into his Microsoft Azure account
He immediately attempts to fiddle with the new platform by creating a Resource group
Oops! Error message
At this point, John existed in the organization’s identity directory, but had no administrative authority yet. This demonstrated an important distinction: Authentication isn't Authorization.
Feeling a little redundant, John approached Richard, the company's Cloud Engineer with his concerns. "Don't worry", Richard said, as he proceeded to grant John administrative access. "Such a well mannered guy, he thought...perhaps a Global Administrator role?....that'll make him the envy of his friends"
PS: From a security perspective, this is one of the most privileged roles available in Microsoft Entra ID.
How was it done?
TASK 3: GRANTING THE NEW USER GLOBAL ADMINISTRATOR ACCESS
Richard with Username : richardochuksgmail.onmicrosoft.com logs back into Microsoft Azure
He types "Microsoft Entra ID" in the search box on Azure, clicks on "All Users", selects "John Brown" and clicks on "Assigned roles"
Next, "Add Assignments" then selects "Global Administrator"
And voila! John Brown is now courtesy of Richard, a Global Administrator.
He informs John, who then attempts to test his newly assigned role.
Unfortunately, that’s where things started going wrong.
TASK 4: THE NEW USER (JOHN BROWN) CREATES ANOTHER USER
Rather than directing new employee Peter Parker to the cloud engineering team, John decided to "save everyone time." Using his elevated privileges, he created another user account for his friend directly inside Entra ID.
At first glance, it looked harmless but the cloud engineer immediately recognized the risk: if one intern could create identities freely, nothing stopped him from onboarding every colleague, assigning unauthorized permissions, or accidentally exposing company resources again. The issue was no longer identity creation. It was authorization control.
TASK 5: REVOKING THE GLOBAL ADMINISTRATOR ACCESS FROM THE FIRST USER'S ACCOUNT (John Brown)
Richard logs into his Account again, clicks on "Users" then "All Users"
Selects John Brown's profile then "Assigned roles"
Checks the "Global Administrator" option then clicks "Remove assignments"
Using RBAC Principles, the cloud engineer removed John’s privileged role assignment and replaced it with a lower-privileged role aligned with his actual responsibilities. This followed the Principle of Least Privilege where users only receive the minimum access required to perform their tasks. Instead of permanent administrative access, onboarding responsibilities were returned to authorized IT personnel. In summary, balance was once again restored in the land of Richard Inc.