That’s what I was trying to figure out with Azure VPN Gateway- I am still learning about what you can do to route traffic to on prem resources and how much control there is.
Networking is not my strong suite.
Thanks for the info Jose.
1 Like
So what does “wide open” mean here? If we’re talking about BasicAUTH, Epicor does provide login access with OAUTH2 via Azure AD so it’s possible to have MFA and have conditional access rules with their cloud product. It’s on the users who don’t use that. 
Everyone is trying to get rid of BasicAUTH and Epicor is on track to do so.
Is their Azure Data Center wide open access? Not according to anyone who wants ODBC access. 
Are there security features that could be put in front of the app servers like Azure Front Door, Azure Firewall, Azure Private Link/Endpoint, Azure Application Gateway, etc.? Sure.
Tailscale is an interesting alternative to traditional VPNs.
From a Zero Trust perspective, the VPN is generally too permissive of a tool as Jose has pointed out. The goal is to provide access from a well-authenticated resource to another resource, preferable right down to the application and not the entire server. This is doable with modern authentication methods.
1 Like
They don’t have any way of doing it in 10.2.500 as far as I am aware. Is that different for newer versions? I have blurry recollection of whether this changed in 10.2.600 or 10.2.700 or kinetic.
Would you please clarify what you mean by modern authentication methods and which of those are supported by Epicor?
If you do a Menu search and see this, then you have the capability. Somewhat sure that 12.2.500 had it.
Epicor only supports Azure AD today. Other authentication providers are Auth0 or JumpCloud.
A very good explanation of authentication: Modern Authentication (codemag.com)
Thanks Mark, but you can still hit the rest endpoints with basic auth even if you have the Azure active directory set up- right? At least that is what I have experienced with my own setup of an azure active directory single sign on environment.
I believe that it’s the same as enabling Windows authentication. If you mark a user as SSO only, they shouldn’t be able to log in via BasicAuth. If you don’t force SSO, then yes, they can still log in that way.
The thing is though then you would have to make the whole organization (every user) SSO in order to eliminate the possibility of someone trying to log into the application server using basic auth.
Is there no way to set the application pool up so that it does not accept basic auth instead of handling it at the user level?
Not that I know of. I believe that @Olga confirmed this awhile ago but maybe Mr. @edge knows the future of the Epicor security posture for vNext releases.
1 Like
You are right - REST only checks for SSO-Only flag on user level for authentication.
Olga, do you have any contacts in the industry that you could connect me with that have managed to block basic auth attempts at the application server level using some sort of networking technology?
Basically we have one application server that we want to allow other authentication methods (non SSO) and one application server where we want to allow only Azure authentication (via SSO).
Maybe I am fighting a losing battle, but it would be nice to choose at the application server level
I hear you but I think I can work with the SSO flag. Create a Password policy with a minimum length of 12, leave SSO off for service accounts protected by a scope, and maybe have a “break glass” Security Manager account when AAD takes a dump. Although, MS just shadowed the whole AAD system, so 
1 Like
What do you mean by this?
The first thing that comes to mind is to use something like API Management or Application Gateway in Azure. It will inspect headers on every incoming call and you can process them according Authorization header value - Basic or Bearer.
But what is the point to have 2 app servers for authentication? in WCF you only could use one authentication method per protocol, so I can understand why would you create another appserver for another login. But in REST there is not such limit.
1 Like
They added a lot of redudancy to avoid failures in the future. Practically another AAD as backup.
https://azure.microsoft.com/en-gb/blog/advancing-service-resilience-in-azure-active-directory-with-its-backup-authentication-service/
2 Likes
We would like to connect users to the second appserver that would be using port 443 for CRM and application use.
We would like to separate this traffic from using the app server that our manufacturing plants use so that it does not affect their (manufacturing’s) ability to do work should a denial of service attack or some other web related issue affect the application’s performance or integrity.
Is it not normal to separate app servers for load balancing or based on how they will be used?
Thanks Olga, for taking the time to educate me. I really appreciate it.
We have something in the works to use Azure front door and gateway to try and inspect the headers.
Absolutely normal. I was just asking why you want to include type of authentication in that.
Did I answer your question or is it still unclear why I want to include authentication in that?
I am assuming that any connection coming from inside our network is safe (please don’t ridicule me) I know zero trust is a framework and this directly goes against that…
I am just really more concerned about port 443 and the fact that someone could use basic auth to connect to our epicor endpoint. For that reason I wanted to turn this authentication type off for that app server- should we ever spin one up.
I would think that allowing people to specify authentication types at the server level as well as the user level would allow for more flexibility for the ever changing use cases that businesses keep coming up with.
-Utah
1 Like