Using PIM Groups and Azure Key Vault as a Secure, Just in Time, Password Management Solution

As an MSP, CSP, general IT Service Provider or even a regular IT department, we generate a huge number of login credentials for different systems to keep everything running. While it is best practice to maintain a single source of identity using LDAP integrations, ADFS and delegation, sometimes the systems we work with don’t support this. Things like Certificate Authority logins, root passwords to non-Windows machines, local admin passwords etc. all need to be stored securely and potentially made available to a large team when needed.

This problem is very common, with many third party solutions such as LastPass having decent offerings around credential access management. One relatively low cost tool we have at our disposal in the Microsoft Cloud is Azure Key Vault. Key Vault allows us to securely store a range of sensitive credentials like secrets/passwords, keys and certificates and allow the other technologies in Azure to help us with access management. It also allows for logging of activity, backup and versioning of credentials which goes a long way towards making the solution scalable and secure.

We can create a Key Vault in our Azure Subscription very easily and start using it to store credentials for anyone with access, this is fine but persistent access to this secure data probably isn’t required and shouldn’t be in place.

To provide access to the keys we want to publish, we create a security group in Azure which will be granted permissions in the access policy to just the Keys required. As we want to make access available as ‘just in-time’ ensure to tick the option for “Azure AD roles can be assigned to the group (Preview)”.

When our group is created we can enable it for privileged access from the group settings under “Activity”.

Once enabled, we add our users who require access as eligible to the group.

Now that our group is ready, the last step is to assign access to the group. From the Key Vault we created, create a new Access Control policy, granting appropriate access to the Key Vault for our group. For this group I am granting the “Reader” permissions to the vault but this can be tailored to the specific group needs.

If required, we can customize the settings of the eligible role to put in any approval or notification requirements.

Now that the role is assigned, we can test with our user account.

Requesting Access

When our user requires access, they can navigate to the Privileged Identity Management section of the Azure portal and under Privileged Access Groups can request the access to the group providing justification for logging purposes and subject to any approval / notification settings etc.

The request will process with any notifications or approval we have specified.

Once activated, the role will allow our user to access to Key Vault for the time specified in the request. When this time expires they will need to activate the role again.

Summary

Key Vault and PIM work together to form an extremely secure workflow for secret management. While we can’t get granular for different individual objects, it’s recommended that a tiered approach using multiple vaults is taken to ensure segregation of permissions. Key Vault is also extremely cheap to run and using this model, is highly scalable.

Some other ideas would be to integrate something like Logic Apps to remind the Key Vault owners to rotate any stale passwords and update them in the vault. For certain services this rotation can even be automated with Logic Apps and/or Azure automation.

Azure AD Group Role Assignment – Exchange Online Access Denied

Azure AD Group Role Assignment is a great new preview feature that provides a lot of flexibility and governance to assigning admin roles in Azure AD / Office 365. When combined with Privileged Identity Managements new Privileged Access Groups (Preview) feature, we can begin to set up a really slick permission eligibility structure that is both easy to manage and easy to administer.

I recently came across an issue when testing this set up. I had requested and activated my Global Admin role via a dedicated global admin role group and got into the Admin Portal without issue. I then opened the Exchange Online Admin Portal and was greeted with this message:

Very strange considering I was now logged in as a Global Admin and could see pretty much everything in the Admin Portal. I tried the usual signing out and clearing cookies etc. but couldn’t get it to work.

Finally I did some digging into the documentation and sure enough found my problem within the known issues section of the ‘Assign Roles to Groups‘ section.

“Use the new Exchange Admin Center for role assignments via group membership. The old Exchange Admin Center doesn’t support this feature yet. Exchange PowerShell cmdlets will work as expected.”

https://docs.microsoft.com/en-us/azure/active-directory/roles/groups-concept

From the documentation I could see that the regular Exchange Admin Center doesn’t support Group Based role assignments yet. Ok, no problem, except the link in the Admin Portal takes me directly to the old Admin Center, with no option for the new until you are logged in.

To work around this we can just go directly to https://admin.exchange.microsoft.com and gain access with our group based role assignment.

Luckily Microsoft documentation is miles ahead of where it used to be and this was quickly found and resolved, even if I felt a bit stupid for not realizing this limitation in the first place. Can’t really complain considering it’s a preview feature currently.

There are a few other known issues to be aware of with Group Based role assignments but for the most part I have found the perform very well and are a welcome addition:

Group Based Role Assignments Known Issues

  • The Enable staged rollout for managed user sign-in feature doesn’t support assignment via group.
  • Azure AD P2 licensed customers only: Don’t assign a group as Active to a role through both Azure AD and Privileged Identity Management (PIM). Specifically, don’t assign a role to a role-assignable group when it’s being created and assign a role to the group using PIM later. This will lead to issues where users can’t see their active role assignments in the PIM as well as the inability to remove that PIM assignment. Eligible assignments are not affected in this scenario. If you do attempt to make this assignment, you might see unexpected behavior such as:
    • End time for the role assignment might display incorrectly.
    • In the PIM portal, My Roles can show only one role assignment regardless of how many methods by which the assignment is granted (through one or more groups and directly).
  • Azure AD P2 licensed customers only Even after deleting the group, it is still shown an eligible member of the role in PIM UI. Functionally there’s no problem; it’s just a cache issue in the Azure portal.
  • Use the new Exchange Admin Center for role assignments via group membership. The old Exchange Admin Center doesn’t support this feature yet. Exchange PowerShell cmdlets will work as expected.
  • Azure Information Protection Portal (the classic portal) doesn’t recognize role membership via group yet. You can migrate to the unified sensitivity labeling platform and then use the Office 365 Security & Compliance center to use group assignments to manage roles.