8 Replies Latest reply on Jan 24, 2012 2:22 AM by Carlos NameToUpdate

    CLI to set Automation Principal property

    Jim Campbell

      Is there a way with the CLI to set a Server Property to an instance of an Automation Principal?  The only thing that looks likely is Server.setOverridenValueAsObject but it requires a com.bladelogic.model.typesystem.type.ClassField as the first argument.  Is there a way to get an object of this type or some other way to set the server property?

        • 1. CLI to set Automation Principal property
          Bill Robinson

          why are you trying to do this?  i thought you set the automation prinicpal at the role level, not the server level...

          • 2. CLI to set Automation Principal property
            Jim Campbell

            We don't want to really commit to using only automation principals (i.e. for the role) but have some times where it would be helpful to be able to use them with the role for a specific job.  Our first choice would be to script changing a server property that is read for the role from a default of null (i.e. fall back to using user impersonation) to a temporary value prior to running a deploy job (typically a deploy in which some portion of the job requires AD access that we don't want to give to a local bladelogicrscd user).  The last stage of the script would be to reset the server property to null so that any other jobs would not use the automation principal and would instead use user impersonation.

             

            As an example, we typically use BLAdmins for most task and this is mapped to a server property named ADMIN_AUTOMATION_PRINCIPAL.  This property is null on all but a few test servers so for all other servers user impersonation is used.  We would like to be able to set ADMIN_AUTOMATION_PRINCIPAL for a target server temporarily, run a job, and then reset it so that user impersonation was used.

             

            Our ghetto solution would be to create a new role for the job, set the role to always use an automation principal, and use an execution override so that the job is always run using that role.  However, I believe this would require giving the role some kind of access to the blade server objects which is always a hassle.

            • 3. CLI to set Automation Principal property
              Bill Robinson

              why don't you just always map the role w/ the AP ?  is that much different than the local acct you are mapping them to in terms of access?

              • 4. CLI to set Automation Principal property

                Hi Jim,

                We are facing a very similar problem here. How did you finally resolve it?

                 

                Thanks in advance.

                • 5. Re: CLI to set Automation Principal property
                  Bill Robinson

                  can you use the blcli to change the AP setting for the role and then change it back ?

                  • 6. Re: CLI to set Automation Principal property

                    Hi Bill,

                     

                    Unfortunately, that is not an option, since the role is being used by many users at the same time. The problem is exactly as explained by Jim.

                     

                    Regards.

                    • 7. Re: CLI to set Automation Principal property
                      Bill Robinson

                      I think you should create a new role for this.  trying to flip around the security settings could have unintended consequences, like what happens if you set the AP and another job runs by another user in the same role that should not run w/ the AP ?

                       

                      what about using the execution override on the jobs you need - run as a different role that uses the AP.

                      • 8. Re: CLI to set Automation Principal property

                        It's going to be quite complicated that two different users run a job against same target, since in the way our customer works is like every user "owns" a group of servers. Nevertheless, I agree with you in that technically is like you say.

                         

                        Anyway, I like your idea of creating a new role plus using execution override. I'll further explore that option, since there are some other issues (like using the same job at the same time against two servers that will requiere different APs)