I made a User in E10 to test some security settings with. But when I use “Changes User” and switch to this user, my original login (as manager) security settings still apply.
We use SSO, and my OS username is tied to the manager user. Is this what’s causing the problem?
FWIW, here’s what I did
Made a new E10 user jschmo. The domain and domain user ID are left blank.
Added this new user to the Company,
On the Options tab, all check boxes in the Security, Background Tasks, and Tools Option sections are unchecked.
Added user to previously created security group READONLY
Enabled the user account.
Use the Change User function to switch to user jschmo.
After the main appears, it shows user jschmo, but all the menus show as if jschmo is a Security Manager.
Yes, this is because of SSO. User is defined by windows account and can’t be switch by change user function.
aidacra
(Nathan your friendly neighborhood Support Engineer)
3
In the E905 and earlier days if SSO was in use for a user session, we disabled the button to change users - makes sense as if you tied your Epicor credentials to your Windows login, in order to change user one’d need to log all the way out of the Windows session, log back in with a different Windows user account, and launch Epicor again (or, at the launch the Epicor shortcut as a different Windows user account). We didn’t bring that same behavior with preventing the ability to change users from within an SSO session forward in E10 (I suspect we wanted to try to decouple privacy and authentication for additional connection options), but, if one were using SSO it doesn’t really follow to me that one would change users from within the application if the Epicor credentials are tied to logged in Windows user as once an appserver process is configured for SSO, all connections to it must be SSO. The fact that the change user button is selectable at all within an SSO session is the behavior I feel we should be addressing.
I’ll make another case to development to see if we can disable the change user button when SSO is in use like our previous releases to avoid this situation.
So how can I launch a session as another user? Would making a special config file with the specified user and password setup, launch the session as that user?
I’m only trying to test user and group security settings. That’s why i need to run as user jschmo.
And user jschmo doesnt have a domain login, so i cant just login to the desktop as that user.
FWIW - When using “switch user”, none of the switched to users security settings are used. But the switched to userID is what is used.
A quick test shows that switching to user jschmo (which has no domain or OS user setup, and thus not capable for SSO), from user manager, and then a simple change to the Invoice Comments of an Order Header, yeild OrderHed.ChangedBy = ‘jschmo’.
And what may be an exploitable issue… Is that the user I switched to, had never set a password up (I got the “You have 3 remaining logins …” message). And can simply skip that. Now the user is logged in as another. While the changed to user’s securitywon’t replace the original users, anything done in the system will look like it was done by the “switched to” user.
This “exploit” relies on users not setting up an initial password in E10. But if your environment is SSO, users never even get asked to create a password.
aidacra
(Nathan your friendly neighborhood Support Engineer)
7
You’d create a non-SSO appserver, and log in with that user account using a .syconfig file pointed to that non SSO-appserver.
3 Likes
aidacra
(Nathan your friendly neighborhood Support Engineer)
8
Epicor ERP doesn’t yet have the concept of user impersonation (in the way that we are discussing; there is a user right called impersonation, but, it isn’t for this). If one is a pure SSO shop, the way I would recommend testing another user account is to change their domain user name on their user record in the testing instance to the person’s domain user name that will be testing so you can log into their user account.
We used SSO for everyone so no one knew their Epicor password. You set
up every new user with the same password that only you know. Now you can
sign in as anyone using a config file without SSO.
Any way to disable switching users on SSO servers?
We will have a non-SSO app server but the vast majority of our users will
use the SSO server, so it’s not hard to make our user creation policy be to
setup passwords. Even IT wouldn’t need to retain those as we could just
clear the PW’s if the user needed to use the non-SSO server for some
reason.
For those working in mixed mode of Epicor and Windows authentication, make sure you are setting ‘Requires Single Sign-on’ for Windows auth users. This prevents people from stealing that users credentials.
Here is a section out of the “Epicor 10_NewInstallGuide_102100” that cautions about using the “require” checkbox in Mixed Mode. So, does the below warning only apply to SSL?
DO NOT select this check box when:
•
The server is configured for multiple application servers that use different authentication methods. For
example, if one application server uses Windows authentication while another application server uses
UsernameToken via SSL authentication, do not select this check box.
For testing security we:
Setup a dummy AD account
add that to Epicor
setup the security on a group
apply the group against the user we created
logout
then run epicor using runas, enter in users credentials.
This saves having to setup a new app server with a different security model.
Thank you. That is a clever solution, I’ll probably be using it for some testing.
However, I’m mostly interested in having 2 Appservers. One for SSO and one for non-SSO. The SSO will be used for our humans. The non-SSO will be used for machines and administrative actions. This is because we have some userid’s in E10 that will never be domain accounts. So, I’m wondering if this scenario means we cannot use the “Require SSO” checkbox.
Thanks!
No problems. We too have situations where we will have users who won’t have an AD account, so we will need an non-SSO app server at some stage, but in our current phase of things I wanted to keep things simple and using runas appeared to be a good solution. Not to mention you can be at someone elses machine and login to Epicor as yourself which can be useful if you want to do some admin on the fly.
