1 2 3 Previous Next 37 Replies Latest reply on Mar 19, 2014 3:12 PM by Frederic Renaud Branched to a new discussion.

    RDP Tunnelling - the hidden feature ?

    Mike Jones

      I have started this discussion to find out the information below, share best practices and collect votes for some enhancements to the functionality


      • Do you use RDP tunnelling and if not did you know that you could
      • How do you use it, what improvements have you made to the supplied scripts
      • What additional features would you like


      We use RDP tunnelling extensively which allows us to connect to and manage Windows servers that are behind SOCKS proxies from the BSA console and have no direct connection to port 3389.


      How is it used


      A separate role is created for RDP tunnelling to get round the issue there is no system authorization (see RfE's) and it is a specific NSH right that is not included by default.

      The authorization profile assigned to the role only has - "Custom Command. Execute, CustomCommand. Read, NSH_Proxy.Connect, Server.Read, ServerGroup.Read and NSH tcptunnel command" 


      Two custom commands are used to launch RDP tunnel

      RDP Tunnel - "nsh -c 'rdptunnel.nsh %H'"                        

      RDP Tunnel with Switches - nsh -c 'rdptunnel_withsw.nsh %H' - allows addtional command line options to be added e.g. /admin


      Please see the attached files, the main change to the scripts supplied with BSA is the addition of an RDP file which allows you to set any security options you require e.g. disable drive mapping, also by copying this to a file with the name of the server you are connecting to means that the servername is correct in the MSTSC title bar.


      I am interested to see how other people have implemented this


      Request for Enhancements


      1. Provide a system authorization to allow TCP tunnelling to be assigned to standard roles
      2. Provide support to connect to servers that are listening on a non-standard port so not on 3389 - could be an additional switch to the tcptunnel command
      3. Provide support to allow connections when "Network Level Authentication" is enabled
        • 1. Re: RDP Tunnelling - the hidden feature ?
          Bill Robinson

          you should create Ideas for the enhancements you list in the 'ideas' area of this community if you haven't already.


          for the 'network level authentication' i'm not sure if we can support that as it may not work w/ any kind of tunneling.

          • 2. Re: RDP Tunnelling - the hidden feature ?
            Mike Jones

            Bill, thanks - I will raise the idea, however looking at the number of responses to this discussion perhaps nobody uses RDP tunnelling, I was expecting to see a few responses and some discussion on how it has been implemented elsewhere


            I agree that NLA might not work with any tunnelling it is not something I have had a chance to test e.g. through SOCKS proxy

            • 3. Re: RDP Tunnelling - the hidden feature ?
              Bill Robinson

              setup an ssh tunnel and try the NLA stuff just to confirm... (ssh from your client to another box near your rdp target, fwd the 3389 port through that target *nix box)

              • 4. Re: RDP Tunnelling - the hidden feature ?
                Mike Jones

                I will reply in here as well as the idea, I have tested with SSH tunnel and NLA enabled and it works fine.

                • 5. Re: RDP Tunnelling - the hidden feature ?
                  Mike Jones

                  Update to NLA support and RDP tunnelling support


                  The RDP file we use in the example above contains a lot of settings however to get RDP tunnelling working on any Windows client with the built-in mstsc application you need to use an RDP file with the following setting "enablecredsspsupport:i:0" or "enablecredsspsupport:i:1" this can be the only line in the RDP file if you do not need to configure any other options.


                  Use 0 for legacy or non-NLA enabled servers and 1 for NLA enabled servers

                  • 6. Re: RDP Tunnelling - the hidden feature ?
                    Carmine Ricci

                    Thank you for this information you have provided since there is really little on this subject. But I'm still having problems implementing RDP tunneling properly with RBAC. Here is the problem:  The users have only ene role to perform administration tasks through the GUI & NSH. I have given the role access to an authorization profile in which has all the NSH commands & the NSH_Proxy.Connect authorization. The problem occurs when deploying a NSH script job (where nexec is used with local commands examples: nexec servername cmd /c "echo %systemdrive% or net stop/stop) An error message show that the command is not authorized. It seems, as far as I can tell, when you give the role all the command athorizations explicitely, the local commands do not work anymore. Can you confirm this evalutation. Is there another solution for this problem. I have already tried removing all the command authorizations. When I do this, the NSH script jobs work again but hen I will have problems with the RDP tunneling because it needs the tcptunnel (hidden authorization)

                    • 7. Re: RDP Tunnelling - the hidden feature ?
                      Mike Jones



                      That is one of the problems with the current implementation within BSA you need to use a separate role so that you can give the authorization without breaking everything else in NSH, there is no way around this unless you would like to try adding every nsh authorization including tcptunnel but I think your users file will be massive and I do not know if it will work correctly. (The line length would be huge)


                      It is one of the items in my idea https://communities.bmc.com/ideas/2981

                      • 8. Re: RDP Tunnelling - the hidden feature ?
                        Carmine Ricci

                        thanks for fast reply! That is exactly wht i did. I added ervery nsh command inclduing tcptunnel. This is what I tried to explain in my last post. As far as your answer is concerned regarding creating another role, that creates another prooblem for me ...I'm not sure about you. This means the user will use the GUI interface with one role and then if he would like to execute some NSH commands, the user would then connect with another role? Does this role they will connect via nsh willl have only certain NSH command authorizations or will it be soley used for tcptunneling and therefore only the appriate authorizations for such a role (tcptunnel, nsh, NSH.Proxy.Connect). Is this what u mean when u say "break everything in NSH". It means you need to seperate the NSH commands for the purpose of tcptunneling for one role and other the rest of the NSH commands for the regular role. Won't this be confusing for the user when launching the "NSH here" commands. And yes the "users" is quite complicated to read when reading all the NSH commands across the line. And what about the problem I have what the local commands? Do you have any ideas why this is happening? Because this has nothing to do with tcptunnneling! It's just very odd that if you give all the command authorizations for a role, the local commands do not work? Any ideas?

                        • 9. Re: RDP Tunnelling - the hidden feature ?
                          Bill Robinson

                          your 'cmd' command won't run because it's not in the command list.  if you want to run something on the target via nexec you'd need to create a new command authorization of type 'nexec' and then add it to the list to the role/server.


                          you should raise this issue of the tcptunnel functionality w/ your bmc account manager and talk to product management.  this issue has been raised before and i think there is an 'idea' for it


                          in the example that mike mentions, the user would have to switch roles or launch another gui and login as that role to use only the tcptunnel/rdp commands.  then for all other bsa functionality they would flip back to the other role.


                          right now these are the only two ways to accomplish this.


                          i was thinking that maybe in the rdptunnel.nsh we could do a 'chrole' and flip to the other (tcptunnel only) role before setting up the tcptunnel and launching rdp - i'm not sure if that would work or not...

                          • 10. Re: RDP Tunnelling - the hidden feature ?
                            Mike Jones

                            That is correct our RDP role only has the RDP authorizations so that is what I mean by break everything in NSH.


                            Bill Robinson has answered the local command issue, it seems that nexec is a specific right contained in the NSH * but not specifically listed if you want to include them all.


                            The way we recommend using the RDP role is to either have a separate console running with that role or my preference an NSH command prompt as that role and run rdptunnel.nsh servername from the command line. I think Bill's idea of a chrole command in the nsh script will probably work as well if you want to keep it in the one console

                            • 11. Re: RDP Tunnelling - the hidden feature ?
                              Carmine Ricci

                              hello bill & mike ! I'm tring to integrate this solution bu I'm not able to understand where I'm going wrong. I've created an authrization profile with the appropriate authporizations mentioned above. I then added the profile to the role called tcptunneling. I then created a user whom is member of the roles "tcptunneling" and "windowsadmin". The "Default Network Shell role" is "windowsadmin" for the user. I then connected to the server with a classic "NSH Here". At this point, the user can perform all the network shell commands, which is normal, after I executed the follwing commands manually at the command prompt : chrole tcptunneling  , cd //  , disconnect  , cd //host 

                              This gives me no postive result as far as call tell. I can still execute all the NSH commnads that the "windowsadmin" has.

                              • 12. Re: RDP Tunnelling - the hidden feature ?
                                Bill Robinson

                                Does your nsh client connect via a nsh proxy ?

                                • 13. Re: RDP Tunnelling - the hidden feature ?
                                  Carmine Ricci

                                  If the question is whether the client (console) & app server is configuration with secure file appserver_protocol=ssoproxy

                                  Let me check with this on the dev environment.

                                  • 14. Re: RDP Tunnelling - the hidden feature ?
                                    Bill Robinson

                                    Yes – the nsh client you are trying to run the tcptunnel from ?

                                    1 2 3 Previous Next