Jump to content

Connecting via Remote Desktop to Win7 Enterprise


Recommended Posts

I have a Dell PC running Win7 Enterprise. The device has a Remote Desktop connection that appears in Domotz as per the screen shot below:



However, when I attempt to connect to it using the Domotz Connect button, I get this "DISCONNECTED" dialog box, and when I attempt to Reconnect, it flashes an attempt for a fraction of a second and I get right back to this DISCONNECTED screen shot.



I know that Remote Desktop works fine on the target machine, as I can use the windows RDP client to connect to it without a problem. Here's a screen shot of that connection.



So, do you have any idea why I can make the RDP connection from a Windows client, but I can't connect to it from Domotz?



Link to comment
Share on other sites

I just figured out the answer to my own question, which I'm posting here in case it helps anyone else.  In Windows System Properties (right-click My Computer to find it), there's an option on the Remote tab to "Allow connections only from computers running Remote Desktop with Network Level Authentication (more secure)".  Domotz does not support Network Level Authentication, so it was unable to connect via RDP to my computer.  When I changed the setting to the "less secure" version as per the screen shot below, Domotz was able to connect via RDP just fine.  The issue with this less secure setting is that it exposes your PC to denial of service attacks and can reveal your user names to a remote computer, but it doesn't seem like a wild security hole, so I'm going with it.  Problem solved!





Link to comment
Share on other sites

Just let me add that, if you have home editions of windows the above options for enabling RDP are not present.

Nevertheless, there are few tricks to enable remote desktop.


See here 


And also here if that is not enough







Link to comment
Share on other sites

  • 1 month later...

Thanks for answering your own original question, JeremyL.  I was wondering why this remote functionality only worked on about 2% of the machines that I tried to connect to using this method.


For the Staff:  Are there any plans to support "Network Level Authentication" sometime in the future?  

Link to comment
Share on other sites

39 minutes ago, ATCIS said:

For the Staff:  Are there any plans to support "Network Level Authentication" sometime in the future?  


Thanks for asking this. It is good chance for me to explain a bit more of what we do.

Actually, our solution is still more secure than having an RDP with NLA, but for instance, open to the outside via NAT.

In our case:

* we work on a trusted network
* we do not increase the attack surface of the network, on the contrary - if you want to access your network remotely, we reduce it.
* RDP with NLA prevent access to RDP clients non windows based
* For our choice, where possible, we do not want to store or manipulate passwords of users (with NLA we should, because we would need to ask you for a password before creating the communication channel)


Link to comment
Share on other sites

Dear Silvio,


Thank you for that expeditious reply!  Based on what you stated on asterisk (*) #1 - does that mean that the RDP session actually originates from the Domotz Agent?  I ask because during the session initiation it looks like there is a cloud based proxy server getting involved somehow.  


When utilizing this type of RDP, is the session encrypted at some point?  If so, where?


Regarding asterisk (*) #3 - Do you say that because the Domotz Agent only runs on Linux (at this point)?


Thanks in advance! 

Link to comment
Share on other sites

Dear Atcis,


Our remote connection implementation is slightly different from a regular RDP client-server session.

When an external user wants to establish a remote connection to an internal company server, by RDP, VNC or whatever, it can use various connection model.


1) Basic RDP connection 


In this case, a client outside the company network and outside the border firewall can connect to an internal server only through a NAT rule and an ACL rule on the firewall.


User Authentication and session confidentiality are provided from RDP protocol.


A strict security firewall ACL rule can be defined and enforced if the client has a static IP address only.


2) Gateway based RDP Connection


In this case, the client connects to internal server leveraging the functionalities of a gateway on the firewall or using a dedicated application level gateway.


Typically the gateway provides user authentication and application level SSL-encryption and RDP session is encapsulated inside the external pipe.

An example of this is RDP with Microsoft Remote Desktop Gateway.


3) VPN-based RDP connection


In this case, the user needs to establish a client VPN connection ( typically IPSEC or SSL)  before start RDP session, and RDP session is encapsulated inside the external pipe.


4) Domotz-based RDP connection


Domotz remote connection adopts a gateway-based approach with application level encryption and clientless RDP functionalities.


Our RDP session is encapsulated inside an encrypted tunnel from the ephemeral RDP gateway and the domotz agent and encapsulated in an SSL encrypted tunnel from the web client and the cloud gateway.


An encrypted tunnel is started from the agent inside the trust network towards the cloud using a separated encrypted control channel so that there is not any constraint to have or to set up an open port on the company firewall.


Domotz remote connect does not support NLA because, by design, we don't want to know or to store RDP user credentials and also because we believe that, in our implementation, the absence of NLA support does not reduce the overall security of the application.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...