Locking down direct access to the app not addressed

[Shorinsean]

Hi, An important gap that has not been addressed in documentation is the need, once the new AAD path has been created, tested, and put into production, to lock down the previous direct paths used by application users. A new secure path to an app is useless if a user (or bad actor) can simply enter the legacy URL of the app (perhaps with IP address instead of an FQDN to sidestep DNS redirection) to gain access. The bad guys certainly won't follow the rules. Locking down access to only AAD app proxy traffic is often as complex a task as the enterprise application setup and testing. Regards, Sean

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 594121fe-176f-2edd-77b2-6fcdb07819c2
• Version Independent ID: 9cb402e7-595a-f7c8-b747-ce60546d1b4f
• Content: Security considerations for Azure AD Application Proxy
• Content Source: articles/active-directory/manage-apps/application-proxy-security.md
• Service: active-directory
• Sub-service: app-mgmt
• GitHub Login: @msmimart
• Microsoft Alias: mimart

[SaurabhSharma-MSFT]

@Shorinsean Thanks for the feedback ! I have assigned this issue to content author to investigate and update the document as appropriate.

[rucam]

Would be interested in hearing what's regarded as best practice here. Usually get around this by changing the legacy address of the app to be a CNAME to the AAD App Proxy address, or in-app controls to restrict access by the new address.

[Shorinsean]

There are multiple complications - comments inline below. a couple of scenarios where this won’t work.

The second is that CNAMEs

Thanks,

Sean

From: ruairidhlc notifications@github.com Sent: Thursday, May 7, 2020 2:02 AM To: MicrosoftDocs/azure-docs azure-docs@noreply.github.com Cc: Sean Deuby Sean@enterpriseidentity.com; Mention mention@noreply.github.com Subject: Re: [MicrosoftDocs/azure-docs] Locking down direct access to the app not addressed (#54104)

Would be interested in hearing what's regarded as best practice here. Usually get around this by changing the legacy address of the app to be a CNAME to the AAD App Proxy address,

There are challenges with this approach. The first is that many applications don’t use a load-balancing or vanity DNS name (MyApp.mycompany.com); they use an FQDN server name (https://server1.internal.mycompany.com/apppath) or worse just a hostname (https://server1/apppath). These two are very common, in fact the majority in my experience.

• CNAMEs will work for vanity DNS names as there’s no server directly behind the name. But for everything else -

• A bad actor (or user) can simply enter the server’s IP address instead of the DNS name, thus bypassing any DNS attempts to point to a new address. Even worse with just hostname if I recall correctly; it’s been a year since I’ve worked on this so I’m a little rusty).

  or in-app controls to restrict access by the new address.

[Sean] Yes, this is the other. But it’s problematic. You can classify apps into 3 types:

• Apps written and managed by the app team, typically use a web service such as IIS or Apache – these apps can have access restrictions (typically IP address whitelisting) written into the app. The app team many not have any idea how to do this (esp if it’s a shared server), but may know who to contact. Responsibility: app team
• 3rd party apps – Typically must be done at the OS firewall. App team has no idea, must contact the OS team and drag it out through there. Often very slow.
• Load balanced app – whitelisting must be done at the load balancer. App team has no idea, must contact the network team, put in a ticket, get the modernization team involved because the app team has NO IDEA, everyone retires or dies of old age before it actually gets done.

[cid:image003.png@01D62530.2109DA00]

There are even more complications related to whitelisting. For example, if you have 6 use cases for accessing an app (e.g. internal user access, internal admin access, external user access, etc.), and if ONE of them – for example API access from another application, perhaps multiple applications - doesn’t work with IP whitelisting, you have to throw the whole thing out of scope. Sure, you could maintain a white list for every app that needs API access (and more you discover when you lock it down and other apps break), but that’s an unsustainable level of overhead. Any time a server IP changes, the app team gets help desk calls, then must engage say the network team, etc. etc. etc.

Vanity apps behind a load balancer such as F5 are the easiest, because the app only allows access via the F5.

Executive summary: This is a HUGE amount of work to make an on-premises app secure via Azure AD integration and Azure AD Application Proxy. And none of this is documented at ALL in the Microsoft docs.

FYI, I’m a 15-year MVP alumnus for Enterprise mobility and am known to most of the senior Microsoft identity management team.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMicrosoftDocs%2Fazure-docs%2Fissues%2F54104%23issuecomment-625070000&data=02%7C01%7Csean%40enterpriseidentity.com%7C0ee29d473b4b43fcc38f08d7f25495b2%7C9b0c644aeaa24fe4b738f225cd6bb9e9%7C0%7C0%7C637244317422672837&sdata=%2FqnOeDJEj30wDThiotW7SqWObGMRHjfBJhEvoEeNSKg%3D&reserved=0, or unsubscribehttps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAFR47F5UBZCU57TJKBBSBFLRQJMHXANCNFSM4MZXILCA&data=02%7C01%7Csean%40enterpriseidentity.com%7C0ee29d473b4b43fcc38f08d7f25495b2%7C9b0c644aeaa24fe4b738f225cd6bb9e9%7C0%7C0%7C637244317422672837&sdata=bTP12RRl0KlZHfelDraLq8cataHn8S4yPjFB9qSHQ8U%3D&reserved=0.

[kenwith]

reassign:kenwith

[kenwith]

Thank you for the feedback in improving the doc. I have added this item to our backlog so that it can be prioritized and worked on as appropriate.

please-close