Certificate based authentication to file share

Question

I am trying to connect an isolated, non-domain-connected system to a file share contained in an Active Directory domain. Ultimately, I need to be able to backup files from the isolated system to the domain-connected file share using a scheduled task. I have the additional requirement that I cannot store passwords, and the file share cannot accept anonymous connections.

To get around these problems, I created an X509 certificate from our CA for the purpose of client authentication. I have installed the certificate in the Personal certificate store for the user account I am using to run my program. I have also linked this certificate to a user account in Active Directory.

Simply running the tool with the certificate installed fails, and everything I have come across either:

1. only provides a username/password authentication scheme
   • FileWebRequest.Credentials via WebRequest.Create() pointed at a file:// URI
   • WNetAddConnection2
2. requires implementing a middle-man service
   • Connecting using WCF
   • An HTTPS connection via WebRequest.Create() to a correctly configured IIS server

Is there any way to make the system authenticate using the stored certificate (or any non password-based method) in order to access the file share directly? Due to the nature of the system, closed-source external libraries are also not an option. Open source libraries are OK though.

As a side note, we have multiple systems where this needs to be set up on, and in a couple of those setups, NetApp 8.2.1 is being used for the file share server. Preferably a solution would not depend on this fact, since not all of our systems use NetApp, but a partial fix is better than no fix. For those unfamiliar with NetApp, it means that in addition to being a standard SMB Windows share, it is also accessible as a NFS share, among other things.

Answer 1

It sounds like you've picked on a particularly knotty problem here. I can't offer a solution, but I can offer a suggestion - consider Kerberos authentication.

One of the things Kerberos will allow you to do is generate an authentication token - called a Service Principal Name (SPN) on a suitable authentication server. Active Directory is a Kerberos based system. You should find you can export an SPN from your AD, using setspn - save it to a file, and then use kinit on your client to load that file and use it for authentication.

This should be applicable for both CIFS and NFS.

I'm afraid I can't be much more specific though - it's been a while since I've had to do anything like this, and wouldn't want to send you off in the wrong direction. You may also need to create a 'pretend' machine account in your AD, to generate client SPNs.

Part of what a 'domain join' does is configure the Kerberos keytab on a Unix or Windows client, which is - basically - the 'machine account' authentication token. You don't actually need to do this, but instead should be able to export the machine account keytab and use that.