We use E10.1.400.23 with Windows for both the Net TCP binding, and Authentication methods.
This pretty much makes every session based on SSO, which ties the E10 userID to the user’s domain\OS ID.
I made a test user account in E10, with the domain and OS username left blank.
I don’t want to have to make a test account in our Active Directory, just to run as that user. And even if I did, I’d have to open an RDC to another computer (logining into the PC as the test user), and then launch an E10 Client from that remote desktop.
I thought I had it working by making a special .mfgsys config file. But now it seems it’s not.
You have to start a process on the Windows client as that user. That’s the whole point of using Windows throughout. You hard code access to be only from that Windows identity.
btw - there is nothing stopping you from creating a second app server that runs an alternative security endpoint. Point it at the same db and you run fine. We do this internally for SaaS administration for example.
As Bart mentioned, 2nd app server is the way if you don’t want to create a new AD account. If you go the AD account way, if you shift-right click a shortcut in the start menu you can pick “Run as different user” and login to that account.
Using alternate app server for security purposes is an under utilized approach to be honest. If you care about security for regulatory for example, the db access is usually split. Give minimal sql rights to one app server for users. Give elevated to an ‘admin’ app server which has limited access - locked out in IIS for example to just allowing certain people / workstations to access it using standard Windows and IIS tricks.
The whole point of building on these platforms is to let you folks use all those vanilla Windows tricks to plumb things like you need to do so. I have always called it no throw away knowledge. Whatever you learn to tweak E10 should be something you can use for any WIndows app.
Just an extra bit of info, be aware that the client and any other processes it spawns run under that user’s context. So things like mapped drives and permissions will also be running as that user. Not sure if it will affect you in this case, but something to keep in mind.
Vanilla Windows Security 101. Same as ‘Run As’ when launching a browser or anything else. It’s amazing how many tricks you can abuse if you fall back to taking advantage of the platform. Windows or anything else.
A bit late to the party here, I agree that the creating the additional app server appears to be best practice, but if you have the ability to create a temporary AD user for the purpose of testing security and create a copy of the shortcut for running Epicor and add C:\Windows\System32\runas.exe /user:<username> “path of epicor.exe /config=EpicorERPTest.sysconfig” to the target field. When you run the shortcut you will be prompted with a command window to enter in the password of the newly created ad user.
Epicor will now open in the context of that user so you can check the security. I agree you can run the menu security group as well, but sometimes a picture is 1000 words. In this case an Epicor user in the correct security group and menu security, and logged in is just as useful
