Identities are key, especially in an online or hybrid world. We create more and more valuable and secure cloud resources, yet we find ourselves with only one method to access them alltogether: our user accounts. The more we build, the better we need to protect our user accounts. Now before I get into a discussion about security and user accounts in general, let’s set our scope of this blog. Today I would like to talk about Microsoft’s new security principal when it comes to our most beloved accounts: our administrative accounts, or better even: the way Microsoft changes our perception about security.
As you know I’m a very visual person and I like to use example scenarios, so let’s set our example for today which is a real world example of any cloud consultant out there: imagine a cloud consultant persona that performs implementations, performs deep technical troubleshooting and provides consultancy work for not one, but 10 customers at the same time. You obviously need some kind of permissions in a customers’ tenant in order to do your job. Especially for deep technical troubleshooting operations, you’re likely to span cloud service scopes, so a service administrator level permission wouldn’t suffice. You understand where I’m getting at: customers have an endless trust in their cloud consultants and grant them ‘Global Administrator’-permissions. But, who has infinite knowledge and properly carries the responsibility of handling global administrator permissions for another organization? Let alone 10 organizations at the same time! There are three major issues we need to address here:
- The only global administrator is the account used to create the tenant and shouldn’t be used for daily operations;
- If an (external) expert gains access to a customer tenant, the existence of their account shouldn’t be infinite; There are customers who never remove admin accounts, resulting in a lot of post-project permissions. Of course we inform customers about this, but not everyone does, most people aren’t even aware;
- Administrative accounts themselves should be as secure as possible, meaning: MFA-enabled.
What can Privileged Identity Management do and why do I need it?
Skipping the formalities, PIM can do everything that’s part of our problem. According to Microsoft, PIM is really all about auditing of and control over administrative features in Azure:
- See which users are Azure AD administrators
- Enable on-demand, “just in time” administrative access to Microsoft Online Services like Office 365 and Intune
- Get reports about administrator access history and changes in administrator assignments
- Get alerts about access to a privileged role
Privileged Identity Mangement is a solution that’s built on top of Azure Active Directory and manageable through Azure, not Office 365. Since you’re likely not the only global tenant administrator in your organization, you do need this solution. Given Azures rich statistics gathering process, you are right to expect some kind of statistics overview here as well. You can get an easy overview of who has some kind of administrative privilege in your tenant and how much of the time those users actually use their administrative privileges. You’d be surprised to see the amount of administrative users who rarely use their privileges. You could say that if a user used their privileges at least once, they do actually need their privileges. But, ask yourself: do they only need their permissions for a specific task, or throughout the entire day? And are their privileges spot on, or am I giving my users way too many privileges just to make my job easier?
How to configure Privileged Identity Management?
The first user in any tenant is the global tenant administrator. This user has the choice to either use PIM or not to use PIM. This user is able to create Privileged Identity Management delegations, so step one is to log in to Azure using the new portal with the global tenant administrator account and using the ‘more services’ menu option in the far left blade to find ‘Azure AD Privileged Identity Management’:
Click the little star to pin it to your menu while you’re at it. Next up, you’re presented with an introduction message and a hyperlink that will take you to the Privileged Identity Mangement administrative console. Click it to open yet another prompt:
So here we click the ‘Azure AD Privileged Identity Management’ part and a pane appears on the right where you can click the Create button, hit it! Because we’re all about security, the site wants to verify our account, but since we’re already signed-in with a MFA-enabled account, you shouldn’t have to do anything and get a nice green message. After which, at the bottom of the blade, click the Create button.
Now we can start discovering what we’re dealing with. Click the ‘1. Discovered Privileged Roles’ button to get an overview of all accounts with somekind of administrative privilege in the tenant:
Here you can see the status of my test tenant. There are two global administrators, one security administrator and one privileged role administrator. One of those accounts is my Microsoft-based initial global administrator account, the second and third are two cloud-only accounts created afterwards. This basically tells us that all admin accounts are global administrators. The ‘Security Administrator‘ and ‘Privileged Role Administrator‘ roles are automatically designated to the user account used to install Privileged Identity Mangement. You can also see these permissions are granted permanently. This means you have granted these user accounts the role of ‘global administrator’ at some point after creating the user accounts. These were granted outside of Privileged Identity Management and are therefore considered ‘permanent’, a.k.a.: “the old way“. In my environment, there is one neglected account, my MS account. Another one is an Exchange administrator and the third one is my actual global admin account. As you can see there is no Exchange administrator service role, so perhaps our Exchange administrator is wrongfully assigned global administrator.
In the overview click Next to start converting users to socalled ‘eligible users’. An eligible user is a user who is eligible to a certain privilege, but not permanently granted with these privileges. They are ‘eligible’ to use the privileges in comparison to other users who aren’t eligible to those privileges. Select the permissions who should be converted to eligible admins and click next. Note that not every user account can be converted at all times. There are a number of reasons for this, one of them is you cannot convert your currently logged in context account to eligble account, for obvious reasons:
In our example, let’s convert the ‘jeroen exchange’ account to eligible account instead of being permanent, this can be reviewed in the review screen. Click OK to commit the changes.
After committing the changes, go back to your Azure portal dashboard where you’ll find a Privileged Identity Management shortcut created by default. Click that and drill down to administrative users. You will see the jeroen exchange admin user now being an eligible user instead of a permanent administrative user. While you’re here, feel free to check out all the neat statistics gathered by Azure AD and the auditing features to help you further determine which users actually use their administrative privileges and how:
Gaining access to services from an eligible admin point of view
Now since Privileged Identity Management is set-up, go and tell an administrator he is now an eligible admin, instead of a permanent admin. Remember this was an Exchange administrator account (despite having global admin privileges, but we’ll cover that later). This user would log on to portal.office.com to do do his job. However, after having configured Privileged Identity Management, the user finds no ‘Admin’-tile after loggin in:
This user will come back to you and go like ‘you must have done something wrong, because now I can’t access my administrative portal anymore, the icon is gone’. Then, you should ask the following question: ‘Did you enable your newly created privileged identity yet?’. The answer is problably ‘no’ and this is where things get a bit cumbersome (this may be improved in the (near) future by Microsoft though…). Tell him to go to the Azure portal > Privileged Identity Management > Activate my roles > [ROLE] > activate account (if the user has never logged on before).
Once done, the activate button becomes active and the eligible user must enter a motive to get these privileges:
This is as easy as it gets. After the expiration date, a new request has to be made in order to get the privileges and the user will get these as long as he is an eligible user. Please note that you have rich auditing options that are well worth exploring:
Last but definately not least, you have the option to get e-mail notifications on privilege activation and you can configure access review durations if you go into the PIM settings on the first configuration blade:
Frequently Asked Questions
MFA doesn’t work when setting up Privileged Identity Management, what do I do?
This happens if the account you’re using is not a true tenant account, but a Microsoft account. This can happen for MSDN-based subscriptions. While susceptible to Microsoft MFA when logging on to Azure, the enabling of Privileged Identity Management seems to rely solely on Azure MFA. To work around this: create a temporary tenant global tenant administrator account to configure Privileged Identity Management.
Is the first global administrator the only person who is able to create PIM delegations?
No, the above example actually happened to me, so I had to work around it using a secondary global tenant admin account as well. Feel free to use an additional account for that.
What subscription level do i need to use Privileged Identity Management?
Azure AD Premium Plan P2
Can I increase the time for the granted privileges?
Yes, but be aware this is a per-role setting. All defaults are set to 1 hour, but can be reconfigured and will affect the users based on their current administrative role assignment.
Can I use Privileged Identity Management to request privileges as a user without them being preconfigured for me?
No, see the bullet above, the users’ current role assignment is converted from permanent to eligible. New role assignment is no feature of Privileged Identity Management
Privileged Identity Management is activated earlier on, but now I would like to do a rediscovery of my current administrative user landscape, is this possible?
Yes, go to Privileged Identity Mangement > Manage Privileged Roles > Wizard (in the top bar)