Scripting Driver - Previlege Issue

Hey,

Currently using 4.8.1 IDM & eDirectory 9.2.

I can able to run a command in the Remote Loader machine without any issues locally. but if I trigger the script using the driver, I am getting access denied error. 

Note : The account which is logged into Remote Loader to exceute the powershell is same as that I configured for Driver n RL Communication.

Badly application team says that, using my remote loader machine I can be able to run. If its not running when triggered using the driver then its my cup of tea.

Any thoughts over here ?

Parents
  • Can you provide more details regarding the type of powershell commands you are running?

    Some commands require different types of authentication that may not be possible under the local service account. (Which is what I think Alex B was getting at).

    The normal config I run with is this;

    Configure script service. Set it to run as a domain user or the user which normally would run these commands.

    Make this user above a member of local administrators group (on the member server itself).

    Configure the scripting driver RL to run as local system.

    The logic behind this config is that the events from the engine are stored in clear text (Yes you should also have have EFS enabled) in windows temp directory. So the script service needs local admin rights to access and read those events.

    The script service is the only bit that actually runs powershell commands. It often needs to run as the user who has the rights to execute such commands. This is essential in cases where the powershell commands expect to be able to use Kerberos or NTLM authentication.
Reply
  • Can you provide more details regarding the type of powershell commands you are running?

    Some commands require different types of authentication that may not be possible under the local service account. (Which is what I think Alex B was getting at).

    The normal config I run with is this;

    Configure script service. Set it to run as a domain user or the user which normally would run these commands.

    Make this user above a member of local administrators group (on the member server itself).

    Configure the scripting driver RL to run as local system.

    The logic behind this config is that the events from the engine are stored in clear text (Yes you should also have have EFS enabled) in windows temp directory. So the script service needs local admin rights to access and read those events.

    The script service is the only bit that actually runs powershell commands. It often needs to run as the user who has the rights to execute such commands. This is essential in cases where the powershell commands expect to be able to use Kerberos or NTLM authentication.
Children
  • Can you provide more details regarding the type of powershell commands you are running?

    Its icacls command for providing the rights to the fodler.

    Some commands require different types of authentication that may not be possible under the local service account. (Which is what I think Alex B was getting at). - correct 

    The normal config I run with is this;

    Configure script service. Set it to run as a domain user or the user which normally would run these commands. - Followed the same and it worked 

    Thanks for your help

  • I use Sneakycat CLE and LDIF Driver to execute a number of complex PowerShell scripts, that working with AD/Office 365/Azure AD and  Workday. 

    Parameters for scripts and what kind of scripts required to execute calculated in the driver policies.

    We don't have a "free internet" connection. All internet connectivity must go thru corporate proxy and it takes out the option to run Remote Loader under the "default" system (local) account. RL process must run under a "real" AD domain account.

    As all functions are fully automated, RL (scripts) supposed to be executed in interactive and/or non-interactive modes (nobody logged to the console of Remote Loader server).

    Even when somebody logged to the server console, RL process (and PowerShell) run in "own memory space" and can't display RL trace window. for this reason, I run the BareTail app that shows info from RL trace file (emulate "native" RL trace functionality).

    Alex

    P.S.

    I want to separately thank Aleks Mujadin, author of the great apps C2, ldif manipulation tools, and this wonderful IDM driver, that provides more flexibility, functionality, and security than some "commercial" drivers.

    New version (with a number of important bug fixes and enhancements) released less than a week ago and available on CS site.

    /cyberres/idm/w/identity_mgr_tips/21988/sneakycat-cle-and-ldif-driver-0-91