Agents are the same, but Agents are different

Recently a large organization adopting Microsoft E7 licenses noticed that their Intune Vulnerability Remediation Agent had stopped working. When the agent was first deployed it took on the identity of the user, an Intune Administrator but had recently been updated to use the proper agent identity (this is now the default behavior). The organization has processes in place for how a user can request and be granted permissions, and they have a process in place for how to provision a Service Account and grant it the necessary permissions. However, they had not yet considered how an AI Agent’s Identity would request the permissions and how they would review, approve, and coordinate the responsiblity of assigning the permissions.

In many ways Agents are like Service Accounts, because it should be owned and managed by an actual human who would be responsible for requesting the permissions. However, the agent is also like a human account because as time goes on and Agents change and adapt there will be periods of new abilities requiring new permissions, and at some point there will be a question of “Who is still using this agent and should we shut it down?”

These two perspectives may require the organization to adapt existing account review and approvals, or at least update them to match with the Agent ID concept.

Manual Setup Engagement - Don’t Automate What You Can’t Describe

Before trying to update you process to work with an Agent Identity, as you think it will work, you should actually enable one so you can undestand the various differences and potential issues.

When working with this customer we started with the documentation for the agent to align on who we would need to coordinate the efforts. Fortunately, for the Intune Vulnerability Remediation Agent there are only a few documented Intune and Defender XDR permissions necessary, so the audience is generally small.

Prior to the call

Before our technical guidance call the customer had already completed these steps on their own attempting to reactivate the Intune Vulnerability Remediation Agent.

  1. Customer activated the Intune Vulnerability Remediation Agent. Originally this used the identity of the user activating the agent and was able to run, but was automatically updated to a unique identity created by Microsoft.     
    1. This has been updated so when the agent is activated today it will create and attempt to start with a new Agent Identity for the agent.
    2. Normally the Agent will not run at this point (permissions failure) because none of the permissions have been granted.
  2. Customer created custom permissions in Defender XDR granting Read permissions to Security Operations & Security Posture and assigned this new role directly to the Agent’s identity.

At this point the customer performed the permission check and verified the agent had the necessary permission in XDR, but was missing Intune permissions.

During the call

  1. We reviewed with the customer the required permissions of the agent in both Intune and in XDR, and discussed if we wanted to use the default permission groups or use a restricted approach granting the agent the limited set of permissions.
  2. Customer chose and created a new Intune Role that granted Read permissions to Mobile Apps & Device Config.
    1. Using the Intune Read Only Operator permission is suppored, but we found there were 40+ read permissions granted, and the agentonly needed two, so using the Least-Priviledge approach a new role was created.
  3. Because Role assignment is limited to groups a new Entra group was created, and the Agent Identity was added to this group.
    1. Group assignments for the agent were also reviewed and we noticed the Agent had been assigned to several Dynamic Groups. Reviewing those group rules vs the production rules identified that several of the groups were incorrectly configured, but this is an important identification & discovery.
  4. Customer assigned the group, with the agent identity as a member, to the newly created Intune role.

About 10 Minutes Later re-ran the permission check and found the permissions and status of the agent reporting as correct and the Agent running.

Key Topics to Consider

There were a couple of key topics covered during the guidance call with the customer that are important for others to consider.

Ownership and Sponsorship

When the Agent is created, now dynamically during the enablement process, the user who enables the agent becomes the Sponsor and Owner. For your organization it is important to decide if this is the correct person or if one or both of these need to be changed. In addition, what responsibility does the Sponsor and Owner have when it comes to requesting the permissions?

Recommendation: The Owner and Sponsor should be different users that work on the Intune/Device Management Team. The Owner should be the person responsible and authorized to request the necessary permissions, someone that will use the agent on a regular basis, and accountable for reviewing the permissions on a regular basis. The Sponsor should probably be the Owner’s manager, and have responsiblity to ensure this and all other agents their team uses are properly accounted for.

Least Priviledge Or Least Effort

Using a default permission level is acceptable, but remember this should be reviewed by your oganization before granting this. Consider the Read Only Operator permission grants read to 40+ categories while the documentation for Intune Vulnerability Remediation Agent requires only 2: Mobile apps / read and Device configuration / read. While Read can be a lower risk permission, the span of Read can still be a potential exposure risk and should be considered.

Recommendation: Numerous custom RBAC roles are tedious to maintain, but we have seen what happens when user’s are granted too many permissions and Agents are users with super speed abilities and less common sense, so grant only what is necessary and review the assignments often!

Groups or Individual Assignments

In this specific scenario, because of assigning Intune roles there was really only one option that worked consistently across the services: Groups.

Recommendation: I’m not a fan of creating one group for one identity, but I do believe in being consistent in the approach as this make reviews and audits easier.

Be Aware of Dynamic Groups

During the technical call when performing the group assignment we noted the Agent Identity had been added to a lot of groups, and all of them were Dynamic assignments. This is a key area to review, because those groups could be granting access to additional data and roles, so be sure to review your Dynamic Rule sets for your Entra Groups.

NOTE: Because the identity is created automatically there could be concerns that it may appear in Entra Dynamic Groups and the rules for the groups & assignments for this account should be reviewed especially in production.

Streamlining the Process

Once we had completed the call and everything was working the last thing we did was to review and organize how the flow could work more efficiently, and this is what we came up with.

  1. Activate the Intune Vulnerability Remediation Agent (Responsible: Agent Owner)
    1. This will create a new Agent Identity for the agent to use
    2. Agent should not run at this point (permissions failure) & verify the agent’s identity has not been added to groups unexpectedly
  2. Create a new group in Entra for the Remediation Agent
    1. Add the agent’s identity to the group
  3. Create a Custom Role in Intune with the permissions (Responsible: Intune Admins)
    1. Mobile Apps - Read
    2. Device Config - Read
  4. Assign the Custom Intune role to the Group created in Step #2
  5. Create a Custom Role in Defender with the permissions (Responsible: XDR Admin)
    1. Security Operations - Read
    2. Security Posture - Read
  6. Assign the the role to the Group created in Step #2
  7. Wait about 10 minutes
  8. Test permissions for the Vulnerability Remediation Agent
    1. The Agent should show it has the necessary permission and is/can run

Group Bug

While working with the customer we did discover an interesting and annoying bug. While creating the Entra group, and after creating the group, the identity that was created for the Agent could not be added to the group. However, by going to the Agent’s user identity page (this is the Users page not the Agent Identity page) we could add the group to the user.

Status: This was reported to Microsoft as a bug and there is a tracking item related to it, but as of Nov 2 I’m unsure of the status of this fix.