can you show your script or a snippet of it that's doing the id check ?
When running the script from within the BSA Script Job:
Info 20-Feb-2015 17:53:49 c:\>aws ec2 describe-regions --output table Info 20-Feb-2015 17:53:49 uid=400(BMCTSPR11$) gid=401(mkpasswd) Info 20-Feb-2015 17:53:49 c:\>id
When manually running the script from my NSH session:
I'm not sure if I'm just not choosing the right script type for what I'm trying to do.
id is not a windows native command so do you have cygwin or nsh installed on the target ?
We have the agent and the BSA console installed on the server.
We use the TS boxes as break outs for engineers and dev's to run against cli's.
We have Navisec and PowerCLI running and working fine, jus the AWS one is giving us issues and all I can see that is different is the UID as the AWS CLI is a bit more sensitive.
Is there a way to allow the script to pick up the native BSA users NSH UID for access?
1 of 1 people found this helpful
this is likely due to how the user impersonation works in windows. when you run things under the context of the rscd you inherit the profile of the localsystem user (rscd starts as localsystem and drops to bladelogicrscd) and then the rights of the mapped user (but not the profile/env) are assigned to the process. so things like APPDATA, USERPROFILE, etc will be what you'd expect for localsystem, not the mapped user. i forget if this is different if you use an Automation Principal since that doesn't use the user impersonation feature of windows.
Is there any way around this without using AP's?
Is there a way to map to a certain environment and account on running a script or is it possible to call a job from within Bladelogic manually from within a NSH shell?
If you can call a job would it use the properties of the current NSH shell?
I don’t believe there is a way around this behaviour. Why do you need to get the current user id ?
Due to how the AWS CLI works with it's authorisations being in the users environment table, I need the particular script jobs to run as the users NSH shell environment not the localsystem.
If not is it possible to change the localsystem environment via NSH?
?if it's just going off of the username or other variable you should be able to set that before you make the call to the aws cli.
It needs to run off their logon shell, as it will be configured to the individual IAM credentials of that session.
So currently the flow of the process i need to create is:
1) The user logs into BladeLogic and runs an NSH shell with AWS Configure to enter their IAM credentials. (These are then stored permanently)
2) After this the user can log into an NSH shell session and run commands directly against AWS (Working after adding the correct environment variables etc..). We then need the user to be able to create a Script job in the depot, create a job and run it mapped to their own login session not as localsystem.
What's the best way to alter a script within Bladelogic to run under a different user and what would be the best type of script job to run it as?
If this can't be done, is it possible that they could create a manifest saved on the local server and call it via their NSH shell session? (as I presume this would then use the current session variables)
So i've now got this working within BSA where BSA will run the script against the correct session using a none NSH script.
Is it possible to add parameters to Type 3 scripts so that they can be passed through when ran?
yeah - you should be able to, your script just needs to handle the inputs.
what did you end up doing ?
So we ended up writing a script that we one time run against any server we've built to act as an AWS Command Interpreter that changes the system environment variables of %userprofile% or /c/windows/system32/config/systemprofile and also the cygwin shell for the same user.
We added in a service account for the AWS and added the config and credentials to the localsystem user profile using the script above. This way any user that runs a script against AWS in the console GUI will go in via the service account but will be tracked via the audit log on the job. We also added in the proxy settings for http to the localsystem so we could make it more controllable.
We also added the "aws" command to the NSH Commands in RBAC so that users can call direct into AWS without needing to use nexec or move to a local shell.
Is there any documentation on Type3 NSH scripts or any posts that you know of around using Parameters from the Console GUI to pass through to a Type 3 Script? I've tried using the usual $, $1, $2 etc.. but it doesn't seem to pass through correctly. Not sure if this is just calling them wrongly however.