7 Replies Latest reply on Feb 5, 2013 12:32 AM by Santosh Pande

    RSCD Agent - Functionality



      I was trying to understand the RSCD agent architectture and what it actually does on the targets when an operation is performed from Bladelogic application server on a target.


      For communities and document I found the following for Wndows RSCD agent but not getting much info on Linux Agent


      "When the BladeLogic RSCD agent performs an operation due to a request from the Application Server or an interactive NSH session, the agent will call the Windows LsaLogonUser() API to obtain a Windows SID for the BladeLogicRSCD account. The agent will then determine the set of privileges that the "mapped" user should have. This is done by inspecting the user definition that the Role maps to and determining the set of privilege tokens that are assigned to that user. These privilege tokens are attached to the SID that was obtained for the BladeLogicRSCD account to make this SID's privileges match those of the mapped user. The thread that will perform the operation will then call ImpersonateLoggedOnUser() API passing in the SID for that user that also contains the privilege tokens appropriate for the mapped user."


      When we install Linux RSCD agent on target a user is not created, After installation in rscd files I will map user to root. 


      I want to know in detail what  RSCD does on Linux target when an operation  is performed from Bladelogic application server on that target ?


      Please can someone provide me this information, it will be much appreciated.





        • 2. Re: RSCD Agent - Functionality

          Hi Joe,


          Yes I have gone through this document and understand how the user mapping and access to target works.


          But what I am asking is, what does rscd daemon does on linux target when an operation is performed from Bladelogic app on the linux target (Assume Target has all the required access from BL App and rsc files are set)?


          Sorry I am not a linux expert and want to know to which linux user (If any ?) the local root account on target is mapped to ?


          Like on windows when we Install RSCD a BladelogicRSCD account is created and the mapped administartor account SID is impersonated by BladelogicRSCD account.


          But on linux this is not the case, Hence how linux RSCD agent manages the request from BL app and to what component of RSCD the root user mapping is done on Target ?



          • 3. Re: RSCD Agent - Functionality

            Santosh, on Linux the agent runs as root and thus has access to the whole system. Authentication and Authorization work completely different on Windows and Linux. On Windows, the RSCD user account performs type 4 logins. On Linux, the agent is already "logged in" as root. When the request comes in to the Linux agent, the rscd service evaluates the information against what is in the secure files (exports, users, users.local) and then executes the command on the OS as that user.  They are completely  different mechanisms and the two operating systems handle system instruction completely differently. Not starting a Win vs *Nix fight here, but system authorizations (permissions, etc) are far more straight forward and not as kludgey on Unix based systems, such as Linux.


            Hope this helps.

            1 of 1 people found this helpful
            • 4. Re: RSCD Agent - Functionality

              Hi Adam,


              Thank you for the information, this is helpful and clears most of my confusion on Linux RSCD agent functioning.


              This is much appreciated.





              • 5. Re: RSCD Agent - Functionality

                My pleasure

                • 6. Re: RSCD Agent - Functionality

                  Just to expand a little on what Adam wrote...


                  When the app server connects to the RSCD agent, the initial handshake message includes the user:role of the current Bladelogic user, on whose behalf the operation (such as a job or a live-browse) is being executed.


                  Similarly when an NSH client connects to RSCD, it supplies the user:role of the logged in user -- either the local OS user on that client machine, or the Bladelogic user if you've configured the NSH proxy and authenticated with it.


                  On the target side, when RSCD receives this connection request, it maps the incoming user:role to a local OS user (on the target machine) based on the mapping specified in the users / users.local file.  It spawns a child RSCD process owned by this local user, to handle the connection.  From that point onwards, all messages on the connection are handled by this child process in the local user's context.  Thus the permissions of the local user automatically apply to any target operations attempted by the agent.

                  4 of 4 people found this helpful
                  • 7. Re: RSCD Agent - Functionality

                    Hi Neeran,


                    Thanks dude for the information, it is appreciated.