- Jul 27th, '17, 14:25
We successfully fixed the problem for one domain - it was matter of proper trust setting i.e. subdomain to domain full trust. Also we got excellent response from Epicor Support:
In the log I can see various errors. for example an RPC server error.
Can you please first of all verify that you can add the user you want to import, to a share or security permission onto the iScala server?
In case full trust has been configured and security works fine, but import to iScala still fails, I think the solution will be to configure spn for the iScala Service Account, and set delegation.
Pease see the following information cut from iScala Admin Console help:
If you utilize Active Directory in your network, you must run iScala services under an account with checked "trusted for delegation" box in user's properties to be able to import Windows users.
This property cannot be set to Administrator as the corresponding property page is disabled, so Windows users import will fail if iScala services work under Administrator account. To make import work, add a new user to Administrators group, give the user administrator rights, and set the "trusted for delegation" option.
Also the computer running iScala services must be trusted for delegation. If delegation is not configured properly, you may get "A security package specific error occurred" error."
The reason for this is that user running import function cannot be impersonated as the iScala Service account.
To achieve this, it is required to have ‘Trusted for Delegation’ option set in AD for iScala service account against PDC.
This can be done using the “setspn” command. To get more information about setspn, please see the following resource: http://technet.microsoft.com/en-us/libr ... 73257.aspx
In case all the above are True and correctly configured, user import should work. In case it is still not working, the problem is happening due to other Infrastructure configuration issues probably, such as Network / Security configuration, which are already out of Hotline troubleshooting scope.
1. In order to import windows users, in a scenario where Admin Console is running on a computer different from one hosting iScala services, or to support different domain configurations, the actual information has to be retrieved by iScala Logon service.
2. In order to allow iScala logon service to access Active Directory, iScala Logon service has to impersonate the user initiating the import.
3. In order to allow p.2 to happen in cross-machine scenario (Admin Console, iScala Services and AD running on different machines), Windows rights need to be given. The actual rights required are described in the help.
4. This requirement comes from Windows technologies in use.
The above is required in order to guarantee that the user's SID imported is the one which will be recognized by iScala Logon service when that user would be logging on to iScala.
This is specifically why the import has to be performed by iScala Logon service, and not the Administration Console running on another machine. iScala has to support different usage scenarios, including iScala being installed within the workgroup, iScala being installed in multi-domain environments with complex trusts and users having been migrated from one domain to another (keyword: SIDHistory), etc.
Specifically, the client-side import will not work in several of the supported scenarios.
Basically, in order to show Windows users list dialog, iScala Administration Console uses DsObjectPicker object, described here: http://msdn.microsoft.com/en-us/library/ms675899(VS.85
When the user is selected, iScala (server side) calls Windows API: DsGetDcName to find the corresponding domain controller, LookupAccountName/LookupAccountSid to retrieve the information on user SID and user name, NetUserGetInfo to retrieve additional information related to the user.
Your problem might be that the RPC call to the DC is denied or the DC is not found correctly by the API.
Thank you, Epicor Support!