Application Permissions for Daemon Services in Entra

What this option proposes

This option suggests defining Directory.ReadWrite.All and Mail.ReadWrite as Application permissions and granting them via PowerShell with admin consent.

Why it doesn't meet the requirement

While using application permissions and admin consent is correct for a daemon service, this option violates the principle of least privilege:

• Over-privileged for User Profiles: The requirement is to "Retrieve the full profile details for all users." The permission User.Read.All (Application permission) is sufficient for this. Directory.ReadWrite.All grants the ability to read and write to the entire directory, including users, groups, and applications. This is significantly more access than required and introduces unnecessary risk.
• Over-privileged for Email: The requirement is to "Send emails from a designated shared mailbox." The permission Mail.Send (Application permission) is sufficient for this. Mail.ReadWrite grants the ability to read, write, and send mail for all mailboxes. This is also significantly more access than required, as the service only needs to send emails, not read or modify existing ones.

Key Characteristics/Limitations

• Violation of Least Privilege: Granting ReadWrite permissions when only Read or Send is needed is a major security flaw, increasing the blast radius if the application is compromised.
• Increased Risk: Applications with excessive permissions pose a greater risk to the organization's data security. An attacker exploiting such an application could gain broad control over directory objects and mailboxes.
• PowerShell as a Granting Method: While PowerShell is a valid and common method for granting permissions, the issue here is with the scope and type of permissions being granted, not the method itself.

This answer would be correct if

This answer would be correct if the daemon service had explicit requirements to not only read user profiles but also modify directory objects (e.g., update user attributes, manage groups) and to not only send emails but also read and modify mailboxes (e.g., process incoming mail, manage folders). However, the scenario explicitly states only reading profiles and sending emails, making the ReadWrite permissions over-privileged.

What Delegated Permissions and User Consent Are

Delegated permissions are used when an application acts on behalf of a signed-in user. The application's effective permissions are the intersection of the delegated permissions granted to the application and the user's own permissions. This means the application can never access more than what the user themselves could access.

User consent occurs when an individual user grants an application permission to access their data or act on their behalf. This is typically allowed for less privileged delegated permissions and is often presented to the user during their first sign-in to the application.

Why it doesn't meet the requirement

This option fails to meet several critical requirements of the scenario:

• Daemon Service: The scenario explicitly states a "daemon service" requiring "unattended access" and operating "without user interaction." Delegated permissions fundamentally require a signed-in user to be present, which contradicts the app-only nature of a daemon service.
• Admin Consent Mandate: The security policy mandates admin consent. User consent, even if possible for these permissions (which it often isn't for *.All scopes), would violate this policy.
• Scope of Access: While User.Read.All and Mail.Send can exist as delegated permissions, their effective scope would be limited by the individual user's permissions, not the tenant-wide access required for "all users" or sending from a "designated shared mailbox" without a specific user context.

Key Characteristics/Limitations

• Requires User Context: Always operates in the context of a signed-in user.
• Limited by User's Permissions: The application's access is constrained by the user's own privileges.
• User Consent for Lower Privileges: Often relies on individual user consent, which is not suitable for tenant-wide or highly privileged operations.
• Not for App-Only Scenarios: Inappropriate for background services or automation that run without a user.

This answer would be correct if

This answer would be correct if the scenario involved a client application (e.g., a web app or mobile app) where a user signs in, and the application needs to access data on behalf of that specific user (e.g., reading their own profile or sending emails from their own mailbox), and user consent for those specific delegated permissions was permissible by policy.

What this option proposes

This option suggests a mixed approach: using an Application permission for User.Read.All and a Delegated permission for Mail.Send. It also specifies granting both via PowerShell with admin consent.

Why it doesn't meet the requirement

While using User.Read.All as an application permission is appropriate for the daemon service to read all user profiles, the inclusion of Mail.Send as a Delegated permission is fundamentally incompatible with the scenario's core requirements:

• Daemon Service / Unattended Access: A delegated permission, by definition, requires a signed-in user to be present. The scenario clearly states the service is a "daemon service" requiring "unattended access" and operating "without user interaction." A delegated Mail.Send permission would necessitate a user context to send emails, which contradicts the app-only nature of the daemon service.
• Sending from a Shared Mailbox: Even with admin consent, a delegated Mail.Send permission would typically allow sending mail as the signed-in user. To send from a designated shared mailbox without user interaction, an application permission (Mail.Send as an application permission) is required, often combined with specific mailbox permissions or an application access policy in Exchange Online. A delegated permission does not facilitate this app-only, shared mailbox scenario.
• Principle of Least Privilege: While Mail.Send itself is least privileged for sending, using it as a delegated permission in an app-only context is an architectural mismatch and would likely lead to operational failures or require complex workarounds that violate the spirit of unattended access.

Key Characteristics/Limitations

• Inconsistent Permission Model: Mixing application and delegated permissions for a single daemon service often indicates a misunderstanding of their respective use cases.
• Delegated Requires User: The fundamental limitation of delegated permissions is the need for a user context, which is absent in a daemon service.
• PowerShell for Granting: While PowerShell is a valid method for granting permissions, the issue here lies with the type of permission being granted, not the tool.

This answer would be correct if

This answer would be correct if the service were a hybrid application that sometimes acts on behalf of a user (for Mail.Send) and sometimes as itself (for User.Read.All), and the Mail.Send operation was intended to send emails as that specific signed-in user. However, this contradicts the "daemon service" and "unattended access" requirements for the email sending function.