10.3 Application Proxy & Consent

Application Proxy and consent on SC-300

Two high-frequency Domain 3 themes close this chapter: publishing on-premises apps securely with Microsoft Entra Application Proxy, and controlling OAuth consent so users and admins do not silently grant dangerous permissions. Both sit at the intersection of enterprise applications, Zero Trust remote access, and tenant governance.

/practice/azure-sc-300Practice questions with detailed explanations

Microsoft Entra Application Proxy overview

Application Proxy lets remote users reach on-premises web applications (IIS, other HTTP apps, remote desktop via partners patterns, etc.) using Microsoft Entra authentication and conditional controls—without placing the app directly on the public Internet.

Application Proxy is not a full VPN replacement for every protocol, and it is not the same product as Global Secure Access Private Access (different architecture; both can appear in modern Microsoft remote-access stories). For SC-300, know Application Proxy’s connector + publish + pre-auth model as the classic Entra feature for on-prem web apps.

Connectors and connector groups

Application Proxy connectors are lightweight agents installed on Windows servers that can reach the on-premises application. Key facts:

• Connectors call out to the Application Proxy cloud service (HTTPS)—firewall-friendly.
• Deploy at least two connectors for high availability.
• Place connectors on servers that have network routes to the backend apps (often a DMZ or app-tier segment, per design).
• Connector groups map sets of connectors to sets of published apps—use groups to isolate networks (for example, connectors that can reach HR systems vs factory floor apps).
• Connectors are updated to stay supported; monitor connector health in the Entra admin center.

Role reminder: managing Application Proxy requires privileges beyond Cloud Application Administrator—Application Administrator (or Global Administrator) is the usual built-in answer when the stem includes connector/proxy administration.

Publishing an on-premises app

High-level publish flow:

1. Ensure connectors are installed, registered to the tenant, and healthy in a connector group.
2. Enterprise applications → Application proxy → Configure (or new on-premises application experience).
3. Provide:
   • Name
   • Internal URL (how connectors reach the app)
   • External URL (user-facing hostname under msappproxy.net or a custom verified domain)
   • Pre-authentication mode
   • Connector group
4. Assign users/groups; set assignment required as appropriate.
5. Configure SSO to the backend if needed (for example Kerberos constrained delegation).
6. Apply Conditional Access targeting the enterprise application.
7. Test from outside the corporate network with a pilot account.

Pre-authentication

Exam stance: prefer Microsoft Entra ID pre-authentication unless a specific compatibility constraint forces passthrough. Passthrough is the wrong choice when the stem emphasizes MFA or Conditional Access for remote access to the on-prem app.

Hardening published apps

• Combine pre-auth + Conditional Access (compliant device, MFA, named locations).
• Use least-privilege assignment on the enterprise app.
• Prefer custom domains and proper TLS certificates for professional external URLs.
• Segment backends with connector groups; do not give every connector network paths to every system.
• Monitor sign-in logs for the enterprise application and connector health alerts.
• For private network modernization strategies, know that Microsoft also positions Global Secure Access Private Access—but do not erase Application Proxy knowledge; SC-300 still expects the proxy pattern.

User consent versus admin consent

OAuth/OIDC apps request permissions. Consent is how those permissions become granted on the service principal for your tenant.

Application permissions effectively require admin consent—an end user cannot responsibly authorize “read all mailboxes as an app.” Delegated low-risk permissions (for example User.Read) may still be user-consentable if policy allows.

Consent phishing (why policies exist)

Attackers publish multi-tenant apps that request broad Graph scopes and trick users into clicking Accept. If user consent is wide open, a single click can grant a malicious SP enduring delegated access. Defense is layered:

1. Restrict user consent to verified publishers / low-risk permissions (or disable user consent).
2. Enable admin consent workflow so legitimate requests still have a path.
3. Review enterprise application permissions and OAuth app governance (Defender for Cloud Apps OAuth policies appear in the next chapter).
4. Educate users; prefer publisher verification signals.
5. Remove grants and disable sign-in for malicious enterprise apps quickly.

Consent policies and admin consent workflow

Tenant user consent settings

Tenant-wide switches (labels evolve; know the intent) typically allow configurations such as:

Permission classifications (low impact vs high impact) help allow users to consent only to low-risk delegated permissions while forcing admin involvement for high impact.

Admin consent workflow

When users cannot consent themselves:

1. User attempts to sign in to an app requiring consent.
2. Instead of a dead end, they request admin approval (workflow enabled).
3. Designated reviewers receive the request (email/admin center).
4. Reviewer inspects requested permissions and publisher.
5. Approve (admin consent) or deny.
6. User is notified; on approval, they can retry sign-in.

Configure reviewers who understand permission risk—not an unmonitored shared mailbox. Pair with clear SLAs so app onboarding does not shadow-IT around the process.

Who can grant admin consent?

Roles such as Global Administrator and Privileged Role Administrator have broad power; Application Administrator and Cloud Application Administrator can grant consent for applications in many scenarios. Exam stems may ask which role can consent without being Global Admin—know that application admin roles exist specifically so you are not forced to hand out Global Administrator for SaaS onboarding.

Risk of over-permissioned apps

Over-permissioning is both a registration design failure and a consent governance failure.

Mitigations SC-300 expects you to cite:

1. Least privilege scopes and app roles; prefer custom API scopes over Graph *.All when you control the resource.
2. Admin consent only after permission review; deny workflow requests that are excessive.
3. Restrict user consent; use verified publishers and classifications.
4. Separate identities per environment and workload.
5. Credential hygiene—certs/federation, short-lived secrets, Key Vault.
6. Monitor service principal sign-ins, audit logs for consent events, and OAuth app governance tooling.
7. Disable / delete unused enterprise apps; remove unused permissions.
8. Integrate with access reviews and entitlement patterns for human access to apps; treat privileged workload identities as review-worthy too.

Scenario drill: proxy + consent together

• “Publish intranet HR site to WFH users with MFA” → Application Proxy + Entra pre-authentication + Conditional Access MFA; assign HR group.
• “Cloud Application Administrator cannot configure proxy” → expected; use Application Administrator for proxy.
• “Users must not consent freely but apps still need onboarding” → disable/limit user consent + admin consent workflow.
• “Malicious app obtained Mail.Read delegated for many users” → revoke user grants / disable SP; tighten consent policy; user education; review sign-in/audit logs.
• “Daemon approved with Directory.ReadWrite.All for a read-only job” → remove permission; grant narrower app permission; re-consent; rotate credentials.

Chapter close

/study-guides/azure-sc-300Free exam prep with practice questions & AI tutor