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 ?
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.
Thank you for the information, this is helpful and clears most of my confusion on Linux RSCD agent functioning.
This is much appreciated.
1 of 1 people found this helpful
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.
Thanks dude for the information, it is appreciated.