Tag Archives: authentication

Remote Desktop Protocol [RDP] and OS X

So, I had occasion to try and connect to a windows machine from my Mac. As a long time windows user, my default goto for this is of course Microsoft’s Remote Desktop Protocol. And as luck would have it, OS X/macOS ships with a client called Remote Desktop Connection for Mac (version 2.1.1 build 110309) though from the copyright notices this looks like it hasn’t been touched since 2010… and that is the problem.

On attempting to connect to anything half way recent e.g. Server 2012, Win10, etc. you are thrown the very helpful error “Remote Desktop Connection cannot verify the identity of the computer that you want to connect to. Try reconnecting to the Windows-based computer, or contact our administrator.”

It turns out that Microsoft improved the security of RDP (always a good thing) to make use of something called Network Level Authentication [NLA]. This happened the same time Windows moved from Terminal Services to Remote Desktop Services.

What’s the difference? When connecting to a Terminal Server, a user starts a session and types in their credentials. When using an RD Session Host server, a user typically enters credentials into a client-side dialog box. NLA forces the client computer to present user credentials for authentication before the server will create a session for that user.

Because of that process, it’s sometimes called “front authentication.” Servers that are running Windows Server 2008/Vista or later, and clients running Windows XP SP3 or later, support NLA. Because NLA relies on a technology called Credential Security Support Provider [CredSSP] Protocol, if you’re using a Remote Desktop Protocol [RDP] client for another OS, you’ll need a client that supports NLA.

Microsoft Remote Desktop Connection Client for Mac doesn’t.

Fortunately there is an alternative that does. Via the AppStore, search for ‘Microsoft Remote Desktop’ – Version 8.0.36 (Build 27228) is what I have today. Install this, try and connect to your Windows machine (Win10 for me) and you are in business.

 

Securing simple telemetry submission with HTTP Header Enrichment

As part of an ongoing side project involving my newly acquired Arduino, I’ve been thinking about datalogging, and specifically network based data logging – the goal being to have all the sensor data available for analysis, graphing, etc. I’ve decided to do this on my own server to get familiar with RRD, and PHP again rather then using a Web-based service like Xively.

Also given that Google values a thermostat company, Nest,  at $3.2bn the temperature and other sensor data is clearly valuable in someone’s mind 🙂

As I sketched up a very simple GET submission of the data to a PHP page, it occurred to me that I didn’t want just anybody to be able to submit sensor data. So the question is ‘How can I allow a very simple datalogger to send in data, but block all others?’. For me one possible approach is HTTP Header Enrichment.

HTTP Header Enrichment is most commonly used by mobile operators to add interesting custom fields to HTTP Header requests, usually at the GGSN or just after in the Services Gateway. The typical application is to add the MSISDN or IMSI to HTTP requests going to internal self-service portals so that sign-in is not required from a mobile device.

Typical format used for this is X-something. This is not a formal requirement, as RFC2616 basically allows most things to be used in the headers, but was borrowed from RFC2047 Section 5 (since deprecated). This is a convention, not a requirement but it is one that I will use here.

Basically the approach is to have the server side code check for the custom header, and its value and if it matches what the client sends, then log the data. If not, then return HTTP 404 – Page Not Found.

<?php
$auth_key="my_shared_secret";

if($auth_key == $_SERVER['HTTP_X_AUTH_KEY']){

// Code to handle sensor data

}
else {
   error_log("Auth Key Incorrect. Received value was $_SERVER['HTTP_X_AUTH_KEY']\n");
   header('HTTP/1.0 404 Not Found');
   exit;
}
>

$_SERVER is an array containing information such as headers, paths, and script locations. The entries in this array are created by the web server. There is no guarantee that every web server will provide any of these; servers may omit some, or provide others not listed here. HTTP_ is also added automatically as a prefix, and the hyphens (-) are replaced with underscores (_).

So on the client (arduino side) the code segment looks like:

   client.print("GET /path/file.php?t=");
   client.print(t1);
   client.print("&v=");
   client.print(v1);
   client.println(" HTTP/1.1");
   client.println("User-agent: Arduino Uno");
   client.println("Host: flat-planet.net");
   client.println("X-AUTH-KEY: my_shared_secret");
   client.println("Accept: text/html"); 
   client.println();

so we are sending X-AUTH-KEY and that is available to the server as HTTP_X_AUTH_KEY. As long as they match, all will work fine, and remember that X-AUTH-KEY can be anything, just ensure that it is meaningful for you.