The Command Authorizations are setup such that if you add one of them, that is the only one allowed. If you don't specify any Command Authorizations, you get all of them. But i don't think that is your issue.
can you run this nsh attempt again, and watch the rscd.log on the target? and then paste in the connection attempt? you may want to put the agent log in debug mode (the rscd logger in log4crc.txt)
i believe w/ the AP you specify the user name and domain on separate lines. if not, then the email@example.com should work.
Your target server is in the domain ? you can login to that server w/ those creds? the user in the AP has all the appropriate rights assigned in the Domain Policy ? (logon as batch job, I think a couple others)
Correct, target server is in the same domain. The credentials are an administrator on the target server and can login without issue. I believe all rights should be covered by being in the administrators group.
I wouldn’t be so sure about that last one Nick. The user rights assignment has nothing to do with permissions. Check that the policy has the user or the administrator group specified in “Allow logon as batch job”. In the target server’s security log, do you see type 4 logins being denied?
Checking the "Logon as batch job" the Administrators group is listed as having this right.
Watching the security log while attempting nsh all I see are some successful Registry category events and successful "Other Object Access Events" which refer to PlugPlayManager.
How is your autoprin setup? I don’t think you can set it up as firstname.lastname@example.org . I think you have to specify the domain in the domain field and only the user’s UPN(blautomprinusr) in the username field.
I've been trying both ways just as a test. Currently I have just the UPN as the Principal ID (I've removed the @domain.com since my previous post) and have included the domain in the domain field.
Has the rscd log changed as well?
It's logging the same thing. This makes me thing the user being listed in the rscd.log is the BL user and not the AD user - we have been setting up our BL user names as email@example.com. If this is the case would it indicate I'm not hitting the nsh proxy?
The way I've been performing the nsh commands is by doing
%blcred authprofile -add -profile <profile name> -username <user name as configured in BL> -password <password>
%blcred cred -acquire -profile <profile name> -username <user anme as configured in BL> -password <password>
Authentication succeeded: acquired session credential
%cd //<target machine name>
After the first time I did the "blcred authprofile -add" command I get the option of which role I want to use when I start nsh, so I just select the one for the profile I created.
That doesn’t mean you are or aren’t using the proxy. Can you past the contents of your secure file into the body? If you fire up NSH without using blcred, does it give you a message about local usage only?
can you paste the log entry? you should see a mapping of the from and to user in the log.
also - you may need to remove all mapping entries for your role from users and users.local on the target.
As soon as I launch nsh I'm prompted with the list of Roles to choose from between the Automation Principal role and the BLAdmin role. I do not get the local use only error.
The secure file is below. PROD01 is the server I'm attempting NSH from.
#PROD01:protocol=5:encryption=tls:appserver_protocol=ssoproxy:auth_profile=blserver:auth_profiles_file="C:\Program Files\BMC Software\BladeLogic\8.0\NSH\br\authenticationProfiles.xml"
default:protocol=5:encryption=tls:appserver_protocol=ssoproxy:auth_profile=blserver:auth_profiles_file=/c/Program Files/BMC Software/BladeLogic/8.0/NSH/br/authenticationProfiles.xml
Bill, with no entries in users or users.local for the Automation Principal user, I get the following log entry when I try to nsh:
11/23/11 14:38:41.097 WARN rscd - 10.50.2.226 2660 SYSTEM (automprin:firstname.lastname@example.org): nsh: Failed to map user to local user