3 Replies Latest reply on Sep 14, 2010 2:21 PM by Paul Seager-Smith

    Usage of Automation Principals

    Steffen Kreis
      Share This:



      we are currently investigating the complete usage of the Automation principal mechanisms.


      Background is, there may be no local user with Administrative rights available on our target servers, where we can map to, using the user mapping functionalities of the RSCD agents.

      Therefore we ALWAYS want to map to an Automation principal (An authenticated domain user) on our Windows target servers, even for the BLAdmin user, for any task that gets executed.


      We tested that a little bit and it seems to work as expected so far.

      The only problem we are facing are extended objects at the moment.


      For example, we use a "Windows Inventory" extended object, which is an NSH script, that get's centrally executed on the Application Server against various Windows targets.

      This job is failing as it seems not to use the Automation Principal for mapping on the target server, but gets mapped to Anonymous instead.

      (we see this in the rscd.log)


      At the end that extended object fails, as the Anonymous user is not able to create some temporary files within the RSCDAgents tmp directory.


      Is that in general an realistic approach ?

      And does anybody have an advice, on how to ensure that an NSH script job (like the mentioned extended object) uses the Automation Principal for execution as well ?


      Many thanks for your help


        • 1. Re: Usage of Automation Principals

          Are you using an NSH proxy?

          • 2. Re: Usage of Automation Principals
            Steffen Kreis

            Hi Ben,


            yes we have configured an NSH proxy now, which was not too easy as we use a Load-Balancer to connect to our Application Servers.

            Due to this fact we had to configure two NSH proxys.

            The first one answers with the URL of the LoadBalancer

            The second one is used by the Job server for accessing the RSCD agents.


            But so far everything works as expected.

            We can see that the Automation principal is used for every action we trigger against a target server.


            What is the communities feedback regarding this ?

            As described, security denies local users as member of the local administrator group and therefore the default usage of an automation principal seems the only relieable way to us.


            Do you see any issues with this approach ?




            • 3. Re: Usage of Automation Principals
              Paul Seager-Smith



              we are working to setup this approach too for certain roles (although some roles still use the local admin account). It is also necessary if you want to install certain packages such as SQL 2005.


              You do need to give the users some rights though, depending on what you want to allow. We have a job that gives the user the logon as batch privilege and also sets permissions to allow the user to access the RSCD/transactions and RSCD/tmp folders.


              We have not had any problems with extended objects.



              1 of 1 people found this helpful