NT AUTHORITY\SYSTEM is not set up for single Sign On

I am having a problem using a Data directive to autoprint remittances after an upgrade. These worked before the upgrade and can still be manually printed. I am thinking went awry during the upgrade. The error I get is:

Failed to launch task to submit report. Error: System.ServiceModel.FaultException: NT AUTHORITY\SYSTEM is not setup for single sign-on.

I have combed the sight and seem some similar issues, and I now have a couple possible solutions. However, this is way over my head, but not above my pay grade. So I am left with fixing it. Normally, I have little problem jumping in and “fixing” (sometimes breaking) something, but this one seems like something I want to get right the first time. Therefore, I am posing this to some of the far smarter people than myself. And one day maybe this thread will help others with this similar problem (or myself when I forget).

Possible solution one: On the application server >> services >> Epicor ICE Task Agent >> Properties >> Log On. Change this from This account to Local System Account.

Possible solution two: SQL Server >> Securty >> add different admin right to the NT Authority\System acount

Would either of these solve the problem? Or is it something else?

Any feedback would be greatly appreciated.

I did check under Administrative Tools >> IIS Manager >> Application Pools >> Advanced Settings. This was where the EpicorHelp directed me (sort of). The two .Net and the Default App Pool are set up as Identity - Application Pool Identity. EpicorSSO is set up as Identity - Local Client.

I’d recommend that you run the task agent under it’s own service account, rather than NT Authority.
You will want to add the service account as a user through the admin console and then set the Task Agent service to run under that account.


Just to add onto what @Aaron_Moreng stated, you will need to associate this account with an Epicor account for SSO to work properly.

1 Like

Should I just run the task agent under something like the EpicorAdmin account? Or a completely separate account.

I run 3 service accounts, EpicorAPP, EpicorSQL, and EpicorTA to seperate duties.

1 Like

Just curious… what’s the delineation between the three? I can guess the APP one…

Fair question. I wanted delineation and clarity between the separate parts of the entire application, so that it was clear what the function of the account was.
As an example, I have my EpicorSQL account running all things SQL related
SQL Services running under this account for this SQL Server:

On the front end, I use the Task Agent accounts to run task agents

And on the configuration of the application itself, the application pool is run by the App account.

We had our task agent being driven by an account EpicorSSO. I took the low tech solution and added a user account in Epicor NT AUTHORITY\SYSTEM and the BPM fired. This is probably not the way things should be done, but seeing @Aaron_Moreng replies made me realize we do have a “seperate” account running the task agent.

Thanks guys.

1 Like

I got this error once, not sure how to fix it?

It looks like the user logged into the Server/Admin Console doesn’t have impersonation rights. Where it says Endpoint Binding, I have that at UsernameWindowsChannell and the userID and password are an account we created just for this purpose.

1 Like