I hope I can describe this clearly. I’m trying to get a trusted SSL cert for our Kinetic server, which is on a .local domain. I’m open to any possible solution.
Here’s what I’ve done so far. (names have been changed to protect the innocent)
I’ve created a second internal DNS zone for abccompany.com and created an A record for erp.abccompany.com, which points to the IP of our Kinetic server. I can now ping erp.abccompany.com successfully. I have a wild card cert for *.abccompany.com, which I applied to IIS.
In the following URL to the Kinetic login, I can replace kinetic.abc.local with erp.abccompany.com and it works and shows a vaild cert now.
The client still shows https://kinetic.abc.local/Kinetic2021 (in the top right) and if I click the Open Kinetic in Browser it still point to the .local. I think I need to modify the client to use the erp.abccompany.com address, however, I can’t seem to do that.
In the Admin console, under server management it’s listed as kinetic.abc.local, so I thought maybe I needed to add erp.abccompany.com as a new server and create a new Application Server. I was able to add erp.abccompany.com, but I can’t create a new App Server.
That action is only available when the Admin Console is running on the server.
This is defined in the clients sysconfig file, just edit the app server url and it should point to that one.
The sysconfig file is in the deployment path inside the config folder, if you have several sysconfig you can check the shortcut you use to launch the ERP to see which one it is using.
We ended up doing what @Jonathan suggested and manually edited the sysconfig file to use the public domain. You change to change 2 values; AppServerURL & HomePageUrl
The one downside is that during every update you have to remember to edit these values again.
I just installed 2022.2.7 with a wildcard cert and for us there were two settings I needed to updated. Our wildcard cert is *.[DomainName].com. I don’t install the certs but in IIS I set the host name to [ServerName].[DomainName].com in the https binding, with DNS pointing to the same name. Then in Application Server Configuration the SSL Certificate Subject Name is the selected wildcard cert but the key was then to set the DNS Endpoint Identity to the same [ServerName].[DomainName].com. Make sure to Deploy. Was then able to connect to the App Server in EAC and the client without having to mess around with the .local domain. So instead of EAC trying to connect to the default .LOCAL domain it now connected to the DNS domain.
Update. Found out I did not need to add it to the bindings in IIS, just in the server configuration.
Also, since the value is in the DNS Identity it updates the sysconfig files for the App Server and Home Page URLs to the proper values, no need to manual update after applying updates going forward.
To clarify, are you all able to do this with Single Sign-on, also?
What we need/want to do is
Kinetic 2022+
Our internal domain is .local
Our SSL is issued to .com (necessary for integration)
Use single sign-on (SSO) tied to either AD or Azure AD
Bonus points - ability to use classic client also (preferred; not mandatory)
Have some or all of you accomplished this combination?
We have not got it to work yet.
After help from Epicor support, we accomplished all except #s 4 and 5. I am able to log into 2022.2, from a browser, outside the domain, using Epicor creds (not AD).
Here’s Microsoft’s recommendations on domain naming.
tl;dr
.local was picked by many but unfortunately not an accepted standard. The recommendation is to use a subdomain of your external domain (or an entirely different domain). It is possible to get a free cert from Let’s Encrypt for your internal network using the recommend subdomain option. (Watch for an upcoming Cloud and Obnoxious article.)
I’ve been able to use Azure AD with the classic client without issues. Heck, that was available in 10.2.300 or so.
While AD is comfortable for many of us, it doesn’t handle non-Windows devices, can’t do conditional access like Azure AD, is a trust-based system, doesn’t register approved applications, MFA costs extra, and doesn’t interact directly with your M365 services if you use them.
I learned from @olga that SSO is ONLY AD. You can assign an arbitrarily large password to force Azure AD login.
No argument with best practices, but we are already in the bad-practices boat. So before I ask some questions to help me understand this, let me describe where we are at first.
Today,
Our network was set up decades ago as example.local
300 computers on this network, plus servers, printers, etc.
Our emails are on example.com.
It was on-prem AD (only), but is now a hybrid Azure and on-prem AD sync thing
Currently the production Epicor environment is on an example.local server but tied to an address of epicor.example.com/Kinetic2021
Not literally, but the point is that it’s subdomain.something.com/OtherStuff
We have a public SSL (from GoDaddy) for epicor.example.com
IIS bindings resolve the difference
All of this works fine in Kinetic 2021.2. But not in 2022+. I am told it is owing to the abandonment of TCP.
So, the subdomain thing you mention. I saw a whiff of that in the MS doc you linked to:
Not sure if this is what you are meaning, but since we already have a subdomain in the Epicor endpoint, where does that leave us?
I don’t touch DNS entries myself, so my experience is nil with that part of it, FYI.
