SSO Domain User Name

Epicor ERP 10
1

We use SSO here and we have a couple of computers that run our equipment that came form the equipment manufacturer. As such their Windows user names are sometimes odd, like Production Console. Two words. I have noticed that I can not use a two word Domain user name with Epicor.

I had thought about creating another App server for these specific users and just have them log into Epicor. Does anyone have any other insight or thoughts on this?

1 Like
2

I always like to have another app Server to log into in case SSO is down. And it will go down.

1 Like
3

It’s good to have a NonSSO.

Lets say you have HH01 and HH02 (two Handhelds) and if you do SSO the Forklift driver must make sure he grabs the right HandHeld… and each user HH01 and HH02 is tied to their respective Workstation, Printer, Label Printer… I like to have a NonSSO so if I have 10 devices, they just need to login with the proper username depending on their intention to use it for.

You could even name then HHPacking HHReceiving HHDockStation05

2 Likes
4

Well, I guess I need to get the manual downloaded as I have not ever did a non-sso install before. This should be fun!

5

Agreed with all my colleagues here - we also have multiple appservers for Non-SSO, SSO, and external access (EMA, EWA, Infoworker, Mobile CRM). That way, when one of them has an issue, the whole company isn’t disconnected.

2 Likes
6

I have an appserver for my office people that includes the order entry people, another one for the shop floor, and now one for Non SSO. I am thinking of another one for Shipping. Well, eventually I wan to take Manifest and put it on its own server and then have its own appserver, but that will be a different day.

7

“There are two type of hard drives. Those that have failed, and those that will fail.”

4 Likes
8

For clarification … Is there is a difference between SSO implemented in E10 vs, just using Windows binding on the App?

I have two Apps pointing to our production DB. They are:

  • PRD_102300 - With Endpoint Binding: Windows
  • PRD_102300_WUC - With Endpoint Binding: UsernameWindowsChannel

(yes, I know the 2nd should have been PRD_102300_UWC )

A client to the first doesn’t prompt for login info. It selects the E10 user that matches the domain user logged into the workstation.

The second prompts for the username and login.

Is a user account with the “Require Single Sign On” enabled, prevented from connecting to my PRD_102300_WUC app?

9

Yep.

Worth noting that Epicor has added Service accounts too so if you have a service with an Epicor username and a password that doesn’t expire, you have to grant explicit rights to that username using the API-KEY - which do expire.

BTW, I think that UsernameWindowsChannel is poorly named because it has nothing to do with AD or AAD at all as far as I can tell. It’s just a username-password scheme.

10

Internally tcp uses Windows stuff for that binding security, you can see windowsStreamSecurity inside binding definition.

11

OK, that makes sense. It’s using the Windows libraries for the hashing, transport, etc. but just not ActiveDirectory itself for any account storage.

12

So UsernameOverWindowsChannel would be clearer :wink:

13

:grin:
There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors.

4 Likes
14

I’m not arguing. There are three hard things in IT:

  • Naming Things
  • Off by one errors

EDIT: I couldn’t remember the real one. Thanks @Olga!

1 Like