We are facing a small issue relating to sso enabled app servers.
We have app server A that is set up with SSO Windows authentication but we needed a secondary app server B setup without SSO (but still using windows credentials, UsernameWindowsChannel) to accommodate handhelds (we have a generic RDP login to the server which is why SSO will not work)
The users log into the rdp server with the generic credentials, then once in handheld should enter their own username and password
I have setup app server B which uses the same database as appserver A. If i take a user and sign on I can sign on to app server B just fine 5 times. After the 5th time i get an error saying the password for the user has expired.
Any suggestions on how to fix this? Or a different approach to logging into handheld? I really do not want to have 2 separate lists of users just to accommodate mixed mode authentication.
Do the HH users ever login via a full desktop client? - to setup their password?
Also your comment doesn’t make sense: without SSO (but still using windows credentials, UsernameWindowsChannel)
Username means that they are using Epicor usernames, not Windows credentials. WindowsChannel indicates that Windows is used for authentication. I fought for a more descriptive naming:
EpicorUsernameWindowsEncryption but when you add in binary serialization (for performance) versus an integration friendly format like SOAP the names would have gotten insanely long
Yes HH users would also be using the full desktop client, and at that point they would be on the SSO app server because that is what the client uses.
Yes, app server B is set up with the UsernameWindowsChannel binding. If i am using that binding, does the domain and userid even matter in user account security setup?
UsernameWindowsChannel binding. If i am using that binding, does the domain and userid even matter in user account security setup?
Nope - nothing about Windows IDENTITY is used for that binding. We use Windows to secure client to server payloads so no man in the middle type attacks can be made to sniff the data. The identity and password being passed around is against the Epicor UserFile table.
NOTE - Take a peak at the User Maintenance form and you will note a field - Require SIngle Sign-On
This is important to note when playing with mixed modes. If someone is NEVER going to use Epicor stored passwords and only SSO, make sure you check that. It was added to cover the security hole for users that have never and will never use Epicor password based auth. Otherwise someone can login as them and set their non Windows password. Probably not something you want to allow
aidacra
(Nathan your friendly neighborhood Support Engineer)
5
One caution for those that use SSO: the user account on the system agent record should NOT have require single sign-on checked in user account security. But, that user account should be unique to only that task, with some Epicor password that no one actually uses, and has minimal access to objects within Epicor (it doesn’t have to be a security manager or have access to any particular modules within Epicor–it just needs access to every company in the database in user account security).
Tasks or agent accounts in general are a different breed that need special consideration so good point. I was meaning ordinary human users.
When it comes to agent accounts, all kinds of interesting possibilities are out there based on what how you are deployed. How we handle those accounts in MT SaaS and DT SaaS are different for example. That’s just good ol’ ‘dummies guide to IIS, SQL Server and AD security’.
One of the architectural tenants of ICE3/ERP10 was ‘No Throw Away Knowledge’. Meaning if you need to do some advanced security or whatever with the system, we want to play nice in the Windows ecosystem. Any tricks and approaches in Windows/DotNet/SQLServer should be applicable and E10 should play nice. We still have some rough spots but it’s the direction.
