During my BBSA training I seem to recall be advised by the intrsuctor that the use of the NSH Here custom command should be done with some element of caution. The reason for this is that firstly the network shell caches user credentials and secondly with some shells user activity is not logged.

I'm struggling to find any documentation that highlights these security concerns officially either in a KB article or a user guide so I thought to ask the community here.

Does anyone know of these risks and if there is any reference to them anywhere on the BMC site?

If you have keystroke logging enabled on the agents than you will get all activity run even if they nexec into a shell on the box.

There’s nothing insecure about nsh here – the problem might be w/ granting nsh access in general to your users. you may not want them to have nsh access to the systems. you can block down nsh access a couple of ways:

1 – look at the ‘command’ authorizations in rbac and restrict what nsh and even nexec/shell commands can be run

2 – in 8.1 there’s a NSH_Proxy.Connect authorization. If you setup a nsh proxy, and then restrict communication so all nsh traffic must come from the appservers/nsh proxy, you can grant that connect access to only roles you want to have nsh access.

If I grant them permissions to specific nsh commands, since that then blocks any non-granted commands, are there impacts to what is available via the UI? I would expect that external commands in a blpackage would be affected, but what about other file deploy and config file modifications?

If you have the keystroke logs enabled on the agent, then you will get keystrokes sent to the target even if you nexec a shell.

The creds are cached in the context of the workstation, so the security posture of the workstation should be sufficient to protect the credentials. If it’s not, then I think you have larger problems than bladelogic caching credentials.

The session credentials have a lifetime, so you can change that to your liking.

Look at it this way – you log into your desktop and use your AD credentials as long as you are logged in. your credentials are effectively cached for the lifetime of your session, so you can access network shares, applications that authenticate w/ Kerberos tickets, etc. it’s much the same as that. how are those kinds of applications secured in your environment? Must the user enter a passwd everytime they try to access a network share on the domain?