9 Replies Latest reply on Apr 7, 2014 12:59 PM by Bill Robinson

    Failed to map user to local user

      I have a problem with some windows systems. The same config (export, user.local) is in all system and the most of them are ok. In others the "no autorhizaton to access host" appears in the bladelogic console and in the rscd.log of the server appears "Failed to map user to local user"


      The local users exist and her rights are ok, is the local "administrator". I don't know what is the different between the correct systems, and the system which doesn't work.


      There is some previous posts comenting this issue, but without solutions.



        • 1. Failed to map user to local user

          Some things that I would check for would be:

          -syntax and spacing in exports, users and users.local files

          -what exactly is failing is it any job and any custom command or only certain actions

          -are the manged servers in different domains. do you have automation principals setup. are you using nsh proxy

          -if you restart one of the agents that keeps failing does it work after that

          • 2. Failed to map user to local user

            do you see a line "nouser" added in the users.local file of the problenatice server? Can you send the users,exports, users.local and rscd.log from a problematic server? That can help us understand what the problem is.

            • 3. Failed to map user to local user
              Gurneet Singh Chopra

              Hi Alexandra,


              Can you check if you have mapped role BLAdmins to property ADMIN_ACCOUNT instead of administrator ?


              You can check this by logging as RBACAdmin. Go to Roles > Open BLAdmins > Go to 2nd tab (Agent ACL).


              There, Windows User should be mapped to property ADMIN_ACCOUNT if you have multiple local admin accounts in your environment.





              • 4. Failed to map user to local user
                Joe Piotrowski

                Hi Alexandra, has this issue been resolved? If so, please let us know what the resolution was. I have seen this issue on Windows Server 2008 R2 where security settings were blocking interactive user mapping. You can also try reviewing your security settings on a successful server vs ones that are failing.

                • 5. Re: Failed to map user to local user
                  richard mcleod

                  Currently having this issue after our upgrade from 8.2 to 8.3 via NSH (live browse from console works fine), upgraded the target agent to match version-wise. The exports, users, and users.local files have remained untouched.


                  Something I've noticed in the target rscd.log is that when i issue agentinfo <target> from the appserver, it is trying to map my user-id alone rather than my user-id@domain.com. if i add just my user-id to the users file, it works without issue.


                  when i use blcred cred -acquire I supply my fully qualified user-id...


                  still looking into this but I am receiving "can't access host "<host>": no authorization to access host from my source query and "System (userid) : agentinfo : Failed to map user to local user"

                  • 6. Re: Failed to map user to local user
                    Bill Robinson

                    what is the name of your RBAC user ?  user-id@domain.com ?  and there's an exact (case) match in the users file for ROLE:user-id@domain.com ?  and this maps to a local acct on the target ?

                    • 7. Re: Failed to map user to local user
                      richard mcleod

                      Yes there are two exact matches of my RBAC user which is user@domain.com in the users file on the target.


                      The first match is shown as


                      BLAdmins:user@domain.com rw,map=admin


                      The second match is shown under the #NSH-Only Acls section of the users file


                      user@domain.com rw,map=admin

                      • 8. Re: Failed to map user to local user
                        richard mcleod

                        Just as a follow up here, I've somewhat come to a conclusion on the issue and resolution (or atleast my understanding of it)


                        The issue I was experiencing was occuring on an appserver, the appserver in addition had the rscd agent installed and the rcp console. When issuing NSH commands it would send those commands directly to the target, bypassing the nsh proxy because it was "technically" already authenticated on the appserver host at an OS level.


                        I installed the agent on another server and then installed the rcp client, attempted to issue NSH commands to a target and it would fail the same way.


                        I ran secadmin -m default -appserver_protocol ssoproxy -auth_profile <nameofrcpauthprofile> to update the 'secure' file configuration, then blcred cred -acquire just to ensure everything is refreshed, issued an NSH command to a target without error.


                        edit: Also confirmed that the target is now receiving the commands from (Role:user-id@domain.com)


                        So that seems to fix it by forcing nsh proxy, does that seem right?


                        Wanted to poll the community if this would be ok to do on the appserver?

                        • 9. Re: Failed to map user to local user
                          Bill Robinson

                          prior to 8.0 you cannot enable the nsh client on the appserver to use the nsh proxy.  8.0+ it's fine and it's required if you are using Automation Principals and need NSH,FDJ and Patching jobs to pickup the AP credential.


                          if you do not have the nsh client go through a nsh proxy (or launch via 'nsh here') there is no way to pickup bsa credentials.  in that case nsh will sent the username you logged into the os you are running the nsh client on to the remote side and that will be looked for in the rsc files.  this is how nsh worked before we had an appserver.


                          there's no authentication happening there.  the fact that you ran this from the appserver is irrelevant, other than the exports file on the target allowing a connection from the appserver.


                          if exports allows the connection, users has 'nouser' and there is no mapping for the os user name you started nsh as, you won't be able to connect, no matter where you try and connect from.  unless you do a 'nsh here' from w/in the gui or go through a nsh proxy and there is a blade mapping in the rsc files.