12 Replies Latest reply on May 30, 2014 11:24 AM by Prabhukumar Uthamaraj

    Automation Principal Issue

      I am attempting to use Automation Principals (AP) to map BSA users to Windows Domain Accounts, for the purposes of access control to RSCD agent endpoint servers.  I do not believe I have configured my environment correctly, and am struggling to find the solution.


      This is what I have in my environment:


      1xConsole Server (ConServer)

      1xApp Server - of type ALL (AppServer)

      1xWindows Endpoint Server (WinServer)


      I have configured the AppServer to also act as a NSH Proxy Server.  My understanding is that AP only work if you are using a NSH Proxy Server.  I have confirmed that the NSH Proxy Server is working correctly, as I have reviewed the AppServer appserver.log and can see specific entries in there of the type "[BLSSOPROXY] NSH Proxy Connection Created and Verified".


      I have defined a new AP which specifies my Windows Domain user account ID, domain name, and passphrase.  I have associated this with a Role, and within that Role I have defined : Agent ACL->Windows->Automation Principal->Map to-> and then specified the relevant AP .


      I have added the Role to my own BSA user account.


      My WinServer is configured as follows:

      exports file:     single line of the form <AppServer IP address>     rw

           (I am allowing connections from AppServer only, since my understanding is all connections will now be routed via the NSH Proxy Server).

      users file:         single line of the form "nouser"

      users.local file:     no entries

           (I understand that when using AP the local users and users.local files are no longer used on the target server).


      I now performed a test using an NSH command line.


      I logged onto my ConServer.

      Opened a command prompt.


      Set my NSHDIR env variable (e.g. set NSHDIR=C:/Program Files/BMC Software/BladeLogic/NSH)


      Run "nsh" to open an nsh session.

      At the "Pick Role" prompt I selected the relevant Role (that is linked to the AP).

      Ran "blcred cred -acquire" to acquire a session credential for this NSH command line session.

      I received the "Authentication succeeded: acquired session credential" message.

      I then ran the following command:  agentinfo <WinServer IP>

      I received the error "No authorisation to access host".


      The rscd.log on WinServer shows:


      SYSTEM (<role>:<user>): agentinfo: Failed to map user to local user


      I am puzzled by this, as surely the AP should be used now? Shouldn't this be mapping my BSA user account to the Windows Domain user account, as specified in the AP?  Could it be that the AP is not actually being used, in which case the access method is simply falling back to the users file - and because that contains only "nouser" it is denying my access?


      As another test I removed the "nouser" entry from the users file, and re-ran the above test.  This time the command completes successfully.  However, note the following in the rscd.log:


      BladeLogicRSCD@<WinServer>->Anonymous:PrivilegeMapped (<Role>:<user>): agentinfo: agentinfo


      This indicates to me that my incoming connection was unable to be mapped to any user account on WinServer, and was thereby taken as anonymous.  Because the "nouser" has been removed from the users file, this access is therefore granted.  But, again, this appears to show that the AP was not used, as the Windows Domain user account was not used for the mapping.


      Is my understanding of AP fundamentally wrong?  Am I attempting to perform a task that isn't supported?  Or have I missed a configuration step somewhere?  I guess I could set the exports file on WinServer to also include user=<Windows Domain user account>, but wouldn't that negate the whole concept of using AP - as they are supposed to provide the mapping?

        • 1. Re: Automation Principle Issue
          Bill Robinson

          Put an entry in users.local like:


          BLAdmins:* rw


          And then push acls…


          I think you are being denied access because there is no acl for the role:user you are connecting as.

          1 of 1 people found this helpful
          • 2. Re: Automation Principle Issue

            Thanks for the quick response Bill.


            This does work, and it grants my access.  However, it does not clarify my lack of understanding.  I understand how the users and users.local files work.  However, I am struggling to understand the Automation Principles and what benefit they are bringing here.  I thought that these "took over" from the local users/users.local authentications, and enabled mapping to Windows Domain accounts to be handled?


            If the solution is just to add local user entries, what is the point of the AP?  I do not see that these AP are being used at all?

            • 3. Re: Automation Principle Issue
              Joe Piotrowski

              BSA requires an account with sufficient privileges to carry out it's tasks. You can either use a local account or a domain account. Customers will choose one or the other depending on their environment.


              Within RBAC Manager you have Roles. Those Roles (under the Agent ACL tab) are mapped to local Unix and Windows accounts or a Property. If you use a local account when you run an "ACL Push Job" it will populate the users file like this for example:


              # BLADmins ACLs

              BLAdmins:username1 rw,map=Administrator

              BLAdmins:username2 rw,map=Administrator

              BLAdmins:username3 rw,map=Administrator


              # WindowsAdmins ACLs

              WindowsAdmins:username1 rw,map=Administrator

              WindowsAdmins:username2 rw,map=Administrator

              WindowsAdmins:username3 rw,map=Administrator




              Because we're mapping to a local account, it shows up in the users file.


              If we're mapping to a Automation Principle property instead, the users file will look like this:


              # BLADmins ACLs

              BLAdmins:username1 rw

              BLAdmins:username2 rw

              BLAdmins:username3 rw


              # WindowsAdmins ACLs

              WindowsAdmins:username1 rw

              WindowsAdmins:username2 rw

              WindowsAdmins:username3 rw




              There will not be a domain user listed and the permissions will be handled internally by what's defined in the Automation Principle.

              1 of 1 people found this helpful
              • 4. Re: Automation Principle Issue
                Bill Robinson

                i would add here - the 'mapping' in the users or users.local is required because the permissions to even attempt to access the server, as any local or domain user, is still controlled by bladelogic.  so in the example above WindowsAdmins might use an AP of 'bob@domain.com' and need access to serverA.  there could be another role - WindowsJuniorAdmins that also uses the AP of 'bob@domain.com' but should not have access to serverA.  so that access is enforced by the bsa rsc files.

                • 5. Re: Re: Automation Principle Issue
                  Jim Wilson

                  Automation Principal




                  I have edited the original post

                  • 6. Re: Automation Principal Issue
                    Bill Robinson

                    In principle you should be using the automation principal to access windows servers….

                    • 7. Re: Automation Principal Issue

                      Thanks for all the help so far.  I am pleased to report some success, but still have a few issues/questions.


                      I now have the AP working for my Console-based activities.  For example, I am attempting to Live Browse drive C: on my target WinServer.


                      I have an AP called TESTAP, and this is assigned to a role called TESTROLE.

                      TESTAP defines a Windows Domain user account, called "testusr", in a Domain called "TESTDOM".

                      TESTROLE has an Agent ACL mapping onto TESTAP.


                      I have configured a NSH Proxy on AppServer.


                      My rsc configuration on WinServer is as follows:


                      exports: <AppServer IP>     rw

                      users: TESTROLE:joe     rw



                                BLAdmins:peter     rw,map=Administrator



                      I am logged onto the Console as TESTROLE:joe


                      I am able to Live Browse the C: drive on WinServer successfully.

                      The rscd.log on WinServer shows the following:


                      rscd - <AppServer IP> testusr@TESTDOM:PasswordLtestusr@TESTDOM:PasswordLogogtestusr@TESTDOM:PasswordLogon (TESTROLE:joe): CM: > [Client] Retrieving '/C'


                      So we can see beyond doubt that the AP is now definitely being used.  Good news!


                      Now, if I launch a Windows Command Prompt, run the nsh command, select the TESTROLE, and acquire a credential for joe, and finally run "agentinfo <WinServer>" - this also returns success.  However, looking at the rscd.log I can see that the AP was NOT applied, and in fact the connection was mapped to anonymous, and not the testusr@TESTDOM Windows Domain account:


                      rscd - <AppServer IP> BladeLogicRSCD@<WinServer>->Anonymous:PrivilegeMapped (TESTROLE:joe): agentinfo: Agent permissions are BladeLogicRSCD@<WinServer>->Anonymous:PrivilegeMapped (Identity via trust)


                      So, the command only completed successfully because the users file on WinServer contains TESTROLE:joe   rw.  But because this only contained "rw" and not "rw,map=<some user>" this is why it was mapped to anonymous.  But why should this be the case?  Why is the user not being mapped to that defined in the AP?  It seems the AP was not used for this NSH session.


                      Are AP supported for NSH sessions?  Or are they only supported for Console sessions?


                      I also performed another test.  This one was to perform a "NSH Here" to the WinServer from the Console, and then to run the agentinfo command.  As expected this was successul, and it also applied the AP.  So it would appear to just be the NSH sessions launched from the Windows Command prompt that do not pick up the AP.

                      • 8. Re: Automation Principal Issue
                        Steffen Kreis



                        on the box from where you launch the NSH, have you setup the secure file to make use of the NSH-Proxy ?

                        This entry needs to be in place (in the default entry for instance) appserver_protocol=ssoproxy

                        Some more details can be found here https://docs.bmc.com/docs/display/public/bsa83/Configuring+a+NSH+Proxy+Server


                        • 9. Re: Automation Principal Issue

                          Thanks for the reply.


                          Yes, this is configured on my source computer.  I can see NSH Proxy related messages in the logs on my NSH Proxy Server so I am sure the proxy is being used.  However, the Automation Principal is not being applied to the connection.

                          • 10. Re: Automation Principal Issue
                            Steffen Kreis




                            - So your jobs in BSA use the AP ?

                            - When you launch an NSH-Here from the console, the AP is also used ?

                            - Only when launch a standalone NSH-Session and acquire credentials the AP is not used ?


                            (Scenario 3 works for us, so it is possible)



                            • 11. Re: Automation Principal Issue

                              For the three questions above, the answer is yes.


                              I am pleased to report that the issue is now resolved!


                              The issue turned out to be due to the way I was referring to the target.  Within the BSA Console I had added the server using its hostname.  However, in my standalone NSH session I was performing the agentinfo against this server using its IP address.  When I tried this using the hostname, it worked perfectly, and did map the AP.


                              So, the thing to remember here is that consistency is required in the way you refer to servers, both via the Console and via NSH.  If one has hostname and the other has IP address it won't apply the AP correctly.  You must use whatever you added the server under into Console.


                              Thanks to everyone who offered their help in this discussion.

                              • 12. Re: Automation Principal Issue


                                First of all I would like to thank you for the very clear steps.

                                I was having issues with setting up the automation principal as we wanted to use AP for patchign DC servers.

                                I tried your steps and it helped me in getting the AP working.

                                Thanks a lot.