Support for Network Level Authentication

Topics: Developer Forum, User Forum
Coordinator
Jul 22, 2010 at 8:02 PM
FYI, to add support for NLA (more secure RDP) into terminals its a matter of adding: ((_axMsRdpClient2.GetOcx() as MSTSCLib6.IMsRdpClientNonScriptable3)).EnableCredSspSupport = true; into the RDPConnection.cs file. if (Settings.SupportsRDP6) { ((_axMsRdpClient2.GetOcx() as MSTSCLib6.IMsRdpClientNonScriptable3)).EnableCredSspSupport = true; ... CodePlex's TFS server is down right now, or I would commit the chance myself.
Aug 10, 2010 at 6:04 PM

Is there a build with this change available?

Nov 30, 2010 at 8:18 PM

I second this question...has this option be enabled in any of the builds? Maybe adding it as an option on the RDP tab.

Dec 8, 2010 at 12:40 AM

I've uploaded a built version with NLA enabled to this issue:
http://terminals.codeplex.com/workitem/26306

 

Feb 8, 2011 at 8:38 AM

Can anyone post a compiled version? Preferably one without an installer so I don't need to run it as an administrator. (I've been using some beta version that solved the problem with drive selection and didn't run into major problems)

Feb 8, 2011 at 10:47 AM
prejudiced wrote:

Can anyone post a compiled version? Preferably one without an installer so I don't need to run it as an administrator. (I've been using some beta version that solved the problem with drive selection and didn't run into major problems)

I think you are using my unofficial version.

It is not actually the installer that enforces the administrator requirements, but rather it is built into the actual terminals.exe file. I removed this requirement from my build, but it is still in the official version. (I can understand why this is still kept in, as any new user would normally expect to install to c:\program files\...  and if admin rights are not required, then the program would not work properly).

On the plus side, if you are using my build, then it should already support NLA, but is using the programming terminology that Microsoft use, ie CredSSP (Credential Security Support Provider) rather than NLA.

On the minus side, the name used in the configuration files are also different (enableCredSSPSupport vs enableNLAAuthentication) which means the config files are incompatible (and not just to the extent that it will ignore/lose this setting, but will lose the whole configuration file). 

So if you are moving back to the official versions, you should make sure you have a backup of terminals.config and will need to replace all occurances of  enableCredSSPSupport to enableNLAAuthentication in it.

Or you can use the little patch file available here   https://14cmd.s3.amazonaws.com/FixTerminalsConfig.zip?AWSAccessKeyId=0R5PHV09FXGZGJJ0YH82&Expires=1356998357&Signature=bYpIdGe%2BsmB6CRgCCCPmsrfzlfw%3D or http://goo.gl/zyYdb

Note, once you run this patch, it will mean the config file will now longer work with my build.

 

 

 

Feb 14, 2011 at 3:50 PM
sgmoore wrote:
prejudiced wrote:

Can anyone post a compiled version? Preferably one without an installer so I don't need to run it as an administrator. (I've been using some beta version that solved the problem with drive selection and didn't run into major problems)

I think you are using my unofficial version.

It is not actually the installer that enforces the administrator requirements, but rather it is built into the actual terminals.exe file. I removed this requirement from my build, but it is still in the official version. (I can understand why this is still kept in, as any new user would normally expect to install to c:\program files\...  and if admin rights are not required, then the program would not work properly).

On the plus side, if you are using my build, then it should already support NLA, but is using the programming terminology that Microsoft use, ie CredSSP (Credential Security Support Provider) rather than NLA.

On the minus side, the name used in the configuration files are also different (enableCredSSPSupport vs enableNLAAuthentication) which means the config files are incompatible (and not just to the extent that it will ignore/lose this setting, but will lose the whole configuration file). 

So if you are moving back to the official versions, you should make sure you have a backup of terminals.config and will need to replace all occurances of  enableCredSSPSupport to enableNLAAuthentication in it.

Or you can use the little patch file available here   https://14cmd.s3.amazonaws.com/FixTerminalsConfig.zip?AWSAccessKeyId=0R5PHV09FXGZGJJ0YH82&Expires=1356998357&Signature=bYpIdGe%2BsmB6CRgCCCPmsrfzlfw%3D or http://goo.gl/zyYdb

Note, once you run this patch, it will mean the config file will now longer work with my build.

I've tried Your patch on Your custom terminals.config. It replaced enableCredSSPSupport with enableNLAAuthentication. But the new config file didn't work with either Your custom terminals nor with the stable 1.9a. When replaced the default terminals.config with the patched one - terminals would complain that it couldn't migrate my connections and would launch the initial config window. After the initial configuration (master pasw etc.) the terminals.config file would loose any record regarding enableNLAAuthentication and I couldn't connect to servers requiring NLA.

Meanwhile Your custom terminlas app has 8 records enableCredSSPSupport="false" in it's terminals.config. I've changed them to "true" and now I can connect to our Win 2008 server that would previously give me an error that the server requires NLA (also - this message only appears on Your custom terminals, the standard 1.9a does not show a message at all - very inconvenient, I wouldn't even know NLA was the culprit of my failed attempts to connect if not for Your custom build). But I've tried to connect to our clients server (also win 2008) but got the same message stating that NLA is required. So it seems just changing enableCredSSPSupport to "true" does not solve everything - at least in my case (obviously something is configured stricter at our client site since I can connect to our server that I reckon has near default configuration - it's only a test system).

Maybe You have a config file that is patched and would fit the standard 1.9a version (with enableNLAAuthentication)?

Feb 14, 2011 at 7:44 PM
prejudiced wrote:

I've tried Your patch on Your custom terminals.config. It replaced enableCredSSPSupport with enableNLAAuthentication. But the new config file didn't work with either Your custom terminals nor with the stable 1.9a. When replaced the default terminals.config with the patched one - terminals would complain that it couldn't migrate my connections and would launch the initial config window. After the initial configuration (master pasw etc.) the terminals.config file would loose any record regarding enableNLAAuthentication and I couldn't connect to servers requiring NLA.

Meanwhile Your custom terminlas app has 8 records enableCredSSPSupport="false" in it's terminals.config. I've changed them to "true" and now I can connect to our Win 2008 server that would previously give me an error that the server requires NLA (also - this message only appears on Your custom terminals, the standard 1.9a does not show a message at all - very inconvenient, I wouldn't even know NLA was the culprit of my failed attempts to connect if not for Your custom build). But I've tried to connect to our clients server (also win 2008) but got the same message stating that NLA is required. So it seems just changing enableCredSSPSupport to "true" does not solve everything - at least in my case (obviously something is configured stricter at our client site since I can connect to our server that I reckon has near default configuration - it's only a test system).

Maybe You have a config file that is patched and would fit the standard 1.9a version (with enableNLAAuthentication)?

When you say 'the stable 1.9a', do you mean the original version (May 11 2010) as per the downloads page.  This doesn't support NLA but the one from http://terminals.codeplex.com/workitem/26306 does. (Should maybe point out that that 26306 still needs admin rights)  

If you were using the May 2010 version, it wouldn't understand the config file ( if it refers to either enableCredSSPSupport or enableNLAAuthentication) and would bring up the message about not being able to migrate your connections etc.

> Meanwhile Your custom terminlas app has 8 records enableCredSSPSupport="false" in it's terminals.config. 

I erred on the side of caution and hence did not enable this setting by default. So you need to enable it on the Extended settings tab on the RDP tab of each connection that you need it. If you do a search and replace for enableCredSSPSupport="false" in the terminals.config and change it to true, that will work, but only if the that line already exists. This might explain why some connections work and others don't. So you would be better using the UI to check/set the option.

> also - this message only appears on Your custom terminals, the standard 1.9a does not show a message at all - very inconvenient

Yeap, that was another change I made. That fix will be in the next offical release (but it is not in the 26306 version)

> Maybe You have a config file that is patched and would fit the standard 1.9a version (with enableNLAAuthentication)?

The config file is a list of your connections, which obviously I don't have. All I can say is that the only change I made to the file format was to add the enableCredSSPSupport setting. If you want to go back to the original 1.9a you can remove all occurances of enableCredSSPSupport="false" or enableCredSSPSupport="true" and the config file will open correctly. (This would also open using the workitem/26306 version, but obviously all connections would be set to not enable CredSSP/NLA). All my patch did was replace  enableCredSSPSupport with enableNLAAuthentication so that the  config could be opened with workitem/26306 version (and future versions of terminals) without having to go through all your connections and re-enable this setting.

 

Feb 15, 2011 at 11:52 AM

Oops. Was double checking my notes and there was another change which I forgot. You may have a setting for AmazonBucketName which would need to be removed as well.

Feb 21, 2011 at 9:31 AM

Thanks for all the help - got it to work just before the v2 came out. v2 works fine right out of the box so I'll be using it.