Currently, we have a Epicor 9 Terminal Server (win server 2008) configured to auto login using a generic AD account. Once this account logs into our server, it auto launches epicor handheld mode. From there, they enter their employee ID number and select Login > a login prompt is presented which I believe authenticates the employee to Epicor:
Once they enter their AD credentials it takes them to the main menu and they can proceed as normal.
On our new Epicor 10 Terminal Server (win server 2016), I tried mirroring the same process. Use a generic AD account to authenticate to server, auto launch Epicor -hh. Asks for employee ID > then prompted for login. However, it doesn’t accept the AD creds. What I think is happening is Epicor is trying to use Epicor authentication instead of AD authentication. When trying to use AD creds, it presents the following error:
How do I tell the system to use AD authentication for this login prompt? In both E9 and E10 environments, the accounts are set for SSO.
What binding is your Application Pool/Server configured with? How do they login to the server level? Is it there standard username, a common user name, or a specific user per handheld? We are on 10.2.300 with Single Sign On enabled using Windows for net TCP and httpsbinarywindowschannel for the https binding. Our handhelds are not prompted for that initial login anymore. They login to the handheld with a specific user for that handheld number and that user is setup in Epicor. Then, in the handheld screen they still key their employee number and password to connect to the HH screens.
The SSO is controlled by the app server no?
I’ve seen many cases where customers have 1 app server for SSO and one for epicor login, both pointing to same DB
Apologies but I don’t think my last response was thorough.
NET.Tcp binding is Windows.
HTTP binding is HttpBinaryUsernameSslChannel
HTTPS binding is HttpsBinary WindowsChannel
App pool has Windows Auth / Anonymous Auth enabled.
The CN80 android handheld has Xtralogic RPD client installed and configured to connect with a generic AD account to our new Epicor terminal server. Each handheld has a unique AD account assigned to it. We have also created an Epicor account that matches the AD account with SSO enabled.
Handheld connects to terminal server > logs in as generic AD account > auto launches E10 Client -hh. At this point they are prompted for an Employee ID which is expected. However, when they are prompted next for an ID and password, it is not accepting the AD creds. I’m not sure if this issue is tied to a .sysconfig or if its something new in E10.
In E9, both generic AD, Epicor account and Employee account has SSO enabled. When handheld logs into our E9 Terminal server, they are able to enter employee ID and then their AD creds > main menu is displayed. In E10, they enter their employee ID but when asked for User ID and Pwd - I’m thinking it wants Epicor creds instead of AD creds. Need to figure out how to tell it to use AD credentials.
You can use SSO without the “Require Single Sign-On” checkbox in User Security checked.
From help “When you select the Require Single Sign-On check box, you indicate this user account is restricted to only use Single Sign On for logging into the Epicor ERP application.”
We have both a SSO and an Non-SSO App Server pointing to the same DB, this way some of our stations, and batch processes we wrote, can use the Non-SSO without
restriction.
I don’t know enough about handheld if the is a combination of binding type in sysconfig and user account options that can get you there without a Non-SSO app
server.
But one thing is, just a shot in the dark, do you have an Employee assigned to the user account in user account maintenance for the employee signing in? I know
with standard MES if that is assigned it forces the user to put their credentials in after entering their employee id.
@litzer67 is likely on the right track. One of the Security hardening changes made to ERP 10 will not let you change your User if the login was originally created with SSO and SSO is Required for the original User.
You either need to change the original Generic AD user so SSO is Not required (User Account Maint) or you need to Un-link the Employee ID so processing remains under the original SSO User.
Error message about not being allowed to change password is misleading (at best).
I figured the error about changing pwd was misleading - changing pwd makes no sense in this scenario. Will continue troubleshooting - instead of a second app pool, why couldn’t I utilize a different, properly configured .sysconfig file?
I looked at the code - you are getting the error message because of the new rule that does not let you change the User when the original user came in as SSO and that User is tagged with SSO Required. Have another look at my post.
Different Client Sysconfigs will not help you. Unlike E9 when an ERP 10 AppServer is setup for SSO all logins against that AppServer have to be done via SSO. If you want a mix of SSO and Epicor User ID / Password, you will need multiple AppServers.
We are on 10.1.600
App server binding NET.Tcp binding is Windows
We publish the app in RDS and we pickup the published app in the xtralogic RDP client config.
One AD user account per site with SSO.
Employee record user id is set to the related User account.
The handheld logs in with no further prompt for username and password, which is how we want it.
The lack of selecting a workstation against the user id will prevent printing if you are using autoprint and using the default device in the autoprint setup. So this post has helped me reflect a bit, looks like I might need to do some more work here to resolve our default printing conudrum. Has anyone seen a change workstation option in later versions of the handheld?
I think we went down this road. Problem is, transactions are captured under the handheld generic AD account which is something like HH01, HH02, etc. The employee who is actually using the device doesn’t get stamped to transactions - just the HH name.
We do want to assign workstations because we want to tie handhelds to wifi label printers.
If you are asking if I have and Employee ID assigned to the AD user account that is used for logging into the terminal server (PTPHH01) then the answer is no. I use an AD account so the handheld can log into our terminal server. I was hoping that when epicor -hh is launched, it will ask for employee ID and then AD creds but it seems that its asking for Epicor creds.
I think you are misunderstanding what Rich and I are trying to relate or I am not understanding how you are setup.
First, in User Account Maintenance there is a Require Single Sign-On check box. This does NOT need to be checked to use SSO, this just states that the user has
to use SSO to login, they could not use a Non-SSO App Server to log in.
Second, I assume you have these filled in for the generic user\AD account the Handheld is using for the session to Epicor. These are the fields that are used
when connecting to a SSO (Windows binding type) App Server and the Domain User ID is the same as the Account User ID.
Third, the Employee field on the Company / Detail tab needs to be empty when multiple users want to log in with their Employee ID on the HH but still use the
generic user account session to Epicor
If that field has an Employee assigned it is then forcing ANY Employee logging in on the Handheld to put in an AD Username / Password.
This is the way it works for MES and I do not have Handheld module but what Rich is stating it works the same way.
As far as transactions are concerned, relating this MES and job clocking, if you look at a labor transactions in Job Tracker it shows both the Employee that was
logged in (Employee ID and Name) and the background user account that created the transaction (Created By). You can see this also in Time & Expense Entry, it is the Employees records but there is a Submitted By which indicated what Epicor session created
the transaction. I am assuming the HH transactions work the same way.
I read Simon’s post and my guess is that the User Account being used to create the HH session to the App Server and the Employee assigned are the same person
so no further authentication is needed.
If you are setup this way and it is not working then I would create a case with Epicor.
We might have to go the RF implant route to resolve that 
