p.s. we are working with 8.2
When you logged into the gui, did you check the ‘cache credentials for this session’ box?
What is in the secure file on your client system?
what's the contents of windows\rsc\secure file?
perhaps it's something like this (no reference the auth profile):
if so, then see if this would work:
- "Save Credentials fot this session" is enabled
- in the secure file i have:
is it not ok ?
Do I really need something like ...
and if I have multiple profiles in my console ??? not only OurBLTest ...
I have an identical secure file and i can use "nsh here" without any problems !
I'd still try to modify the secure file and see if it would work. You can always back track.
Daniel, do you happen to set BL_AUTH_PROFILE_NAME var by any chance (because that's how it works)?
we do not set the variable BL_AUTH_PROFILE_NAME
Custom command will automatically pick the logged in authentication profile this scenario (i.e. Client is configured for NSH proxy using appserver_protocol=ssoproxy in secure file) and there is no need to specify authentication profile name through the environment variable.
But auth profile name is still required in interactive NSH usage. I believe “NSH here” will treated as interactive NSH usage.
If you add respective command (like ls, df etc ) as custom command and then directly run it as custom command (in place of “NSH Here”) it should work.
This is applicable on 8.2 onwards. Hope this helps.
Thanks, Swapnil. I'll test it and let you know ...
you should not need to set the location of the profiles file or the profile name if you are using nsh here. you should only need the appserver_protocol=ssoproxy set in the secure file. the gui should be handing that down to nsh via the 'nsh here'.
you could try adding the auth_profiles_file and auth_profile to the secure file and seeing if that works.
I modified my default entry to remove auth_profiles_file and auth_profile entries, and could run NSH here command (just like others mention). But when I execute nsh locally, I get the issue in question. Adding auth_profile to default entry fixes this.
dinoel,looks like in your case nsh here is somehow detached from the gui and the auth profile that it would normally pass, and this is why you have to set the variable to work around it.
Check how your NSH Here command is configured.
Type should be: Local
Command should be: nsh -D //%H"%p"
when you run nsh here, the gui should be passing down the required env settings (BL_AUTH_PROFILE_NAME, BL_AUTH_PROFILES_FILE, BL_RBAC_ROLE) to the nsh session that's spawned so that they will override whatever is in the profiles file.
what's interesting is that does not seem to happen on my linux rcp client, but works ok on my windows client, not sure what's happening there.
I remember issues of similar nature, in the end it came down to linux shells being contained and not inheriting variables from one another
The command is: nsh -D //%H"%p" ... so it is right
What is interesting:
"agent infomation", "view disk usage", "view processes" etc are working without any problems ;-)