Saturday, August 21. 2010
Integrating Terminal Services into a Portal (Linux Version)
In a previous entry Remote Desktop Protocol (RDP) was discussed and a custom portlet was presented. The portlet shows some applications (that were previously registered in Microsoft Remote Desktop Services) and it lets the user click any of them to download a RDP connection settings file that silently starts client-side RDP application. The solution was tested on a Windows XP box. Windows and Mac have free Microsoft RDC client application, but Linux is a complete different story.
Rdesktop is the traditional, and I think the only one, open source RDP solution. Until the time I faced that pre-sale I was not aware of the poor status of this project. Last rdesktop 1.6.0 version only supports version 5.2 of the remote desktop protocol and its releases are becoming more and more infrequent (1.6.0 was released in May 2008, 1.5.0 in September 2006, 1.4.1 in May 2005 and so on). The request to support RDP protocol 6.0 was open in the summer of 2007 (a year after 6.0 version was released with Windows Vista) and it is still not assigned. But, you know, this is open source, do not complain and do not wait others to do your job, fix it yourself! Now talking seriously, if somebody has enough time and skills and wants to participate in the never-ending war against Microsoft this is a good project that needs some love.
Coming back to the RDP portlet, Linux only has rdesktop and the portlet must work with it. The main restriction is that this program cannot use TS gateway, so only typical plain RDP (3389 TCP port) communication is possible (remember gateway can use the more secure, easier to integrate HTTPS protocol). This limitation makes absolutely compulsory the use of a VPN in order to establish a secure channel between an internet user and the server. And, of course, 5.2 protocol seems to be more bandwidth-hungry than 6.0/7.0 but nothing can be done with this issue.
Nevertheless seamless remote application was introduced in 1.5.0 rdesktop version. I am not really sure if this feature uses RDP 6.0 protocol or it was done ad hoc but, after all, rdesktop has the -A option to run a remote application. SeamlessRDP extension was a contribution of Cendio to rdesktop in another example of how open source works. This feature needs to install a server side windows program called seamlessrdpshell which is invoked by rdesktop as the alternate shell with the remote application to execute as an argument. For example:
Other issue is rdesktop does not understand rdp files (it is just a common linux command with several execution options). Some other graphical applications (like tsclient) can parse rdp files and call rdesktop accordingly but none of them (at least I could not find anyone) understands the seamless rdp integration (-A option). So I had to code a little python example that reads the rdp file and transforms the file tags into rdesktop options (plaease do not blame me, I already know there is room for improvement). The script needs two minor changes in the generated rdp file (now the alternate shell is specified with the full path to the application and the username is also supplied) but it still works for Microsoft client. Here it is a wordpad.rdp example. Finally the password to rdesktop invocation is hardcoded inside the script (I have commented the script is improvable, haven't I?).
With all the commented limitations the portlet solution is ready to be executed in linux. Now when the application link is clicked the downloaded rdp file will be executed by the python script, which will run rdesktop with the seamless application option. The video is very similar to the presented in the previous entry but with Debian as OS and firefox/iceweasel as browser. If you see when rdesktop is launched the usual windows login page is presented, automatically fulfilled, and then it disappears, the reason is rdesktop does not have Network Level Authentication (new feature of 6.1 version of the protocol).
In summary, this time linux solution is less practical (internet access needs a VPN, a better RDP file parser would be necessary in a real deployment and some bandwidth improvements are lost) but thinking in a global solition, I mean, a solution for all type of clients, is always a good thing and, this way, nobody will say I did not try it.
Keep the faith!
Rdesktop is the traditional, and I think the only one, open source RDP solution. Until the time I faced that pre-sale I was not aware of the poor status of this project. Last rdesktop 1.6.0 version only supports version 5.2 of the remote desktop protocol and its releases are becoming more and more infrequent (1.6.0 was released in May 2008, 1.5.0 in September 2006, 1.4.1 in May 2005 and so on). The request to support RDP protocol 6.0 was open in the summer of 2007 (a year after 6.0 version was released with Windows Vista) and it is still not assigned. But, you know, this is open source, do not complain and do not wait others to do your job, fix it yourself! Now talking seriously, if somebody has enough time and skills and wants to participate in the never-ending war against Microsoft this is a good project that needs some love.
Coming back to the RDP portlet, Linux only has rdesktop and the portlet must work with it. The main restriction is that this program cannot use TS gateway, so only typical plain RDP (3389 TCP port) communication is possible (remember gateway can use the more secure, easier to integrate HTTPS protocol). This limitation makes absolutely compulsory the use of a VPN in order to establish a secure channel between an internet user and the server. And, of course, 5.2 protocol seems to be more bandwidth-hungry than 6.0/7.0 but nothing can be done with this issue.
Nevertheless seamless remote application was introduced in 1.5.0 rdesktop version. I am not really sure if this feature uses RDP 6.0 protocol or it was done ad hoc but, after all, rdesktop has the -A option to run a remote application. SeamlessRDP extension was a contribution of Cendio to rdesktop in another example of how open source works. This feature needs to install a server side windows program called seamlessrdpshell which is invoked by rdesktop as the alternate shell with the remote application to execute as an argument. For example:
$ rdesktop -A -s "seamlessrdpshell.exe c:\Windows\System32\mspaint.exe"In my windows 2008 server installation this program was installed under c:\Windows\System32\ directory (this way it is always found in the execution path). Besides the executable was published as a valid TS Remote Aplication with command line parameters enabled (TS Server lets it run with arguments).
Other issue is rdesktop does not understand rdp files (it is just a common linux command with several execution options). Some other graphical applications (like tsclient) can parse rdp files and call rdesktop accordingly but none of them (at least I could not find anyone) understands the seamless rdp integration (-A option). So I had to code a little python example that reads the rdp file and transforms the file tags into rdesktop options (plaease do not blame me, I already know there is room for improvement). The script needs two minor changes in the generated rdp file (now the alternate shell is specified with the full path to the application and the username is also supplied) but it still works for Microsoft client. Here it is a wordpad.rdp example. Finally the password to rdesktop invocation is hardcoded inside the script (I have commented the script is improvable, haven't I?).
With all the commented limitations the portlet solution is ready to be executed in linux. Now when the application link is clicked the downloaded rdp file will be executed by the python script, which will run rdesktop with the seamless application option. The video is very similar to the presented in the previous entry but with Debian as OS and firefox/iceweasel as browser. If you see when rdesktop is launched the usual windows login page is presented, automatically fulfilled, and then it disappears, the reason is rdesktop does not have Network Level Authentication (new feature of 6.1 version of the protocol).
In summary, this time linux solution is less practical (internet access needs a VPN, a better RDP file parser would be necessary in a real deployment and some bandwidth improvements are lost) but thinking in a global solition, I mean, a solution for all type of clients, is always a good thing and, this way, nobody will say I did not try it.
Keep the faith!
Comments