I’m trying to understand the benefits of moving from Windows authentication to Azure AD authentication. I don’t see much commentary at all on why to do it, just the how. I see folks on the site running into lots of issues and headaches, and the only advantage I’ve spotted on the forum is that you need Azure AD for SSO to work properly for Kinetic Browser (not even sure if that’s true).
What am I missing?
Eating breakfast with the family, but expect a novel later today.
Yes, I wasn’t invited either.
The kids are in from Boston and Tacoma. I could feel the burning daggers from my wife without even seeing them because the phone was in my hand. I would certainly be dead if I invited EpiUsers members. 
Had to read that one twice because Tom asked “What am I missing?” and Mark answered, “eating breakfast with the family…” (-:
I started the novel but I’m going to reduce it down - hopefully.
Active Directory is an on-prem authentication and authorization service released in 2000 and is tightly integrated with Windows clients and servers. It does not work with devices that run iOS, Android, Linux, or MacOS. It organizes users and computers into groups, organizational units, domains, and forests. All computers within a domain have an implicit trust relationship with each other. Networking was new at the time and MS wanted to make sharing easy. This was great pre-Internet but is now more of a security liability. AD uses a single factor for access: the domain\userID and a secret (password). MFA can be added through 3rd parties like DUO.
Azure Active Directory is neither Azure nor Active Directory because naming things is hard. It is a hosted authentication and authorization platform based on OpenID Connect which provides an authentication component to the authorization features of OAuth 2.0. AAD works on all web platforms regardless of operating system and comes in a free tier, an M365 tier, and two premium tiers with additional capabilities. Azure AD is flat and not like a tree. There is little implicit trust. Access is granted explicitly. In addition to users, computers, and groups, AAD also registers applications. We see this when we set up Kinetic, which can be on-prem or in the cloud like other services: M365, GitHub, SmartSheet, KnowB4, and many, many others. This means that if you terminate an account, all of the services are shut-down at the same time - true single sign-on across all operating systems and not just Windows no matter where you log in - and no VPN required. Registered applications can give API access to other applications. This means that one application can display information from others without breaking context: see emails from O365 in Kinetic, view Kinetic data in a Teams app or a custom web app that pulls in data from an external warehouse application. There are more web applications that can use AAD than Windows Auth which is only possible on IIS.
AAD also comes with multi-factor authentication right out of the box - including the more secure phishing resistant number-entry and passwordless options.
With AAD, one can also use Conditional Access rules. For example, if a user logged into the home office and an hour later a login attempt comes in from Asia, it can require an extra MFA to continue or block the request outright. If a global admin tries to log in, a rule can indicate that the login must come from a small set of devices. AAD can also require that the device has a certain level of health checks approved like Windows Updates are applied, Endpoint security running, etc. before granting access.
Finally, with a single login system, there are fewer passwords for users to remember or get compromised. That also gives better forensic logging since AAD logging is far more difficult to alter or delete than on-prem logs.
This is what you might be missing. That and breakfast with my family.
Me neither, and I think you may be referring to a post I wrote.
So far it’s true (enough) for me, possibly because we have an unusual domain setup (.local but a public SSL for a .com [IIS bindings, etc.] and external integrations, on Kinetic 2022+ when net.tcp is gone).
In a .com domain, you may have an easier SSO route. I honestly have no idea.
We use Windows Authentication but have Azure AD connect in place here. Which helps with automation when it comes to provisioning M365 license’s. When we enabled the SSO feature with Epicor it was pretty seamless and evenyone really seemed to enjoy the idea of one less login and “just click a button” and poof Epicor is ready to go.
This also allowed us to setup SSO\License Provisioning with Adobe, Solid Works, Automation of EMail DL’s, RMM, Navex, and the list goes on and on.
Hope this helps.
I heard a great recommendation when using AD Connect: Don’t sync your admins. It increases your attack surface.
Thanks for that overview. Now we need the caveats and the pros/cons of it functioning with Epicor Kinetic Cloud. I’m about to find out as I test it in a dev environment.
I have found, with a few accounts that we need for things like QuickShip, Epicor Commerce, CPQ etc, we need the flexibility to set accounts up that don’t use IdP (Basic Logins) or SSO setups like Azure. These advanced modules were built with the E10 schema and have not been developed to be able to authenticate connectors using the advanced authentication tools. So I’ve made sure I have both IdP and Basic acccounts setup. I am about to setup Azure AD authentication in a FOURTH dev environment so that I can test some of the functionality/pitfalls. I’ll update my findings as soon as I have that done.
solid point thank you
Azure AD is infinitely better than Basic Auth for Cloud. If colleagues are reusing their Kinetic password with another account that gets popped, then they have access. At least with Azure AD, you can have MFA and optionally conditional access. Epicor IdP can also do MFA.
One of the cons previously was an AAD outage, which used to happen once a year. But Microsoft has done a lot in this area and I haven’t heard of a large or lasting AAD outage in the last year.
That was great general AAD info, but I had some questions regarding actually setting up AAD Auth for Kinetic.
we are unsing on prem AD, with AD Sync, and hope to eventually phase out on prem AD.
How does AAD Auth Kinetic Login work with AD based permissions in SQL Backend?
when setting up AAD Auth, it wants a redirect URL, what do we specificy if our App Server is not exposed to the internet?
It should not be accessible, AAD just checks that redirect you specify in the AAD application is the same you want to redirect after login (it is string case-sensitive comparasion). It does not access that url, only tells your browser to redirect there. Your local browser in your local network knows that URL and goes there correctly.
As Olga mentioned, it doesn’t actually need it. It’s just there so someone else can’t fake your site in your Entra ID.
