Entra ID - Access Packages
Objective
To create an access package that applies Entra Role Access to the user requesting
Outcome
You should see an automated access package that will be assigned to anyone in the apps department
In this entry I made an access package inside Microsoft Entra – The Microsoft Cloud Identity Provider. I made an access package to enforce just enough access and Just in Time. These principles secure environments from security threats by restriction access only when needed compared to having them applied all the time. Access packages are a great way of doing this since you can request the access you need, the reasons for it and an admin have time to approve these requests when they can. But how did I do this? Well, I decided to use the following approach. I made a new user and they are Bruce Wayne. I made sure to apply a dynamic group to them as they are going to be apart of the application team in my test environment. I used expressions to assign the group via automation.
Now at this rate I could have just assigned the role Application Admins and been done with it. But I did not want anyone in my test lab to have direct access to anything unless they requested it. It was my way of segmenting the access and also a way to build a better infrastructure. So, I used access Packages. So, I made this group here
This group in a way is static, it can only be applied to users manually by an admin but instead I attached it to my access package. This way the only way for users to get this role was by requests. I also added the Entra role for application admins to this role so it would give any user with the role access to application management.
Next, I just want to show where user’s can find their access requests if a company supports them. For instance, I have signed in as Bruce Wayne at https://myaccess.microsoft.com/ and as you can see there is currently no access packages created. This is good since we’re going to create one for our staff.
Bruce also has no access if they use Entra. My Lab is set up that only admins can manage the portal. So Bruces Portal looks like this.
No blaze is shown due to the permission level needed to have read or write access. Bruce has no roles so no permissions to do anything on the admin portal. So, lets change that so Bruce can admin applications. When I set up the access package I made it so that the group I made is applied to the access
Doing this then allows me to say, when a user gets approved, I can simply assign the group to their account. That then applies the role Bruce would need to admin apps.
During the access package creation, I made it so that the access lasts for an hour. This can be changed but I did this for testing reasons so that the access was taken away from Bruce within the next hour after being approved the access
After creating the access package I can go back to Bruces account on My Access and I can see there should be a access package I can request This is great now Bruce can request this and then get the application admin role, however, before I do this, I know currently that everyone can request this. I don’t want this since if we used this in a business scenario and we had 1000+ members in our org that’s a lot of approvals that could come in, so let’s restrict it.
So now I want to review the access package policy. Doing this allows me to change a setting inside the access package properties.
When editing the policy instead of allowing all members an external user or all members excluding external members you can assign specific members. You can do this by manual assignment of members or you can add a group. The group to me is a better process since you can assign a dynamic group that would then automate the assignment.
I have added a Dynamic group that is assigned to all users within the apps team. If we now try and sign in as another user we shouldn’t see this access package. As you can see, I have signed in as Allan and they cannot see the access package for application admin role. Only Bruce can access this package due to the change I made and anyone else who is assigned to that Dynamic group. Within the Dynamic group you can get your expressions as to who in the apps team gets the access. Maybe you want the Applications Managers to have more access than other members and this is something you can decide within your infrastructure. So now we have established this access package, what happens when Bruce requests it?
Well let’s see 🙂
So, when you request the package, it should bring up a menu. Fill this in and then you should get this message:
Here you can see as the admin I can see that Bruce has made the request. But as an admin I cannot approve or deny this? What is this Black Magic sorcery? Well depending on how you set up the access package depends on what happens when a user requests this. This is why it’s important to make sure your users have all their information filled out in the identity. Why? Well specific User.Properties are sometimes needed by some Entra services. Within this instance I have set the access package approval level to manager. Meaning the manager of the user requesting this access needs to approve the role access first.
So, I can see under Bruces account that their manager is – Nestor Wilke so they will be the one to approve this request. An email should be sent to their inbox. The blue button saying approve or deny request will take me straight back to MyAccess, but this MyAccess would be for Nestor, Nestor can then decide to let Bruce have his pride and joy access or deny the request and of course providing justification
This justification is also done due to the policy of the access package. I Could have decided that manager justification was not needed or I could have decided that any approval was never needed. But this is a more secure way of doing things, we don’t want anyone just having access to admin roles and as admins of the tenant we want to know who has what access and why it’s needed. Just the same as we’d want to know why it was granted or denied even revoked. These logs in larger organisations would be handy to see what happened and why. It’s also good to see on the approval part of the request I can view the request details if any justification was given. What’s inside the access package and if it’s been assigned to the requested user before.
And that’s it. We now have an automated process to assign a role to a user who can request it and be granted access by a manager. Bruce can now make apps for an hour and then the access will be denied. They can ask for an extension on this access or they can let the time run out and then they’d need to request the access again. This type of assignment keeps your Entra secure from external threats if their was a breach and also it makes it possible that user’s can assist on different pieces of work or even projects. Instead of full access all the time we only get access for when we need it.
After the hour of access was up, I checked Bruce’s access on Entra, As you can now see Bruce no longer has the role assigned to them
