0

I had originally posted this question in securitystackexchange, but I didn't get the answer I was expecting, and I see the topic can also fit here.

I need to connect two servers in different locations in order for one of them (Linux stack) issues HTTP periodic requests to the other (Windows stack) -Windows Server 2008 R2- using cron based jobs.

On the Windows machine, I am going to set up an IIS with a self-signed certificate to authenticate to the client (by pinning the certificate) and to encrypt the connection over SSL.

I am also going to configure IIS to request client certificate to authenticate the Linux server. I have gone through a tutorial to configure the Certificate Authentication which involves mapping the certificate to a user account.

I am not happy with the idea of having a user account created for a remote server because I wouldn't like anyone logging into the (Windows) server with that account.

With this in mind:

1) Do I really need to create a user in the Windows server to enable client certificate authorization?

2) if I really need to create an account on the Windows machine, what do I need to set for this user not to be able log into the windows server, nor do anything else but authenticate itself to the IIS?

Note: The active-directory tag was added by @Lex Li. I will leave it, but I understand (and I may be wrong) that there are security concerns about having active directory in Internet facing servers.

Juan
  • 111
  • 5
  • Is there anything that could be improved in the question for which it has been downvoted? – Juan Sep 21 '18 at 15:15

1 Answers1

2

I'm assuming there is no other way than using http for your particular task, because I don't know what the purpose of these https requests is (otherwise it's nice to know that Windows 10 and Server 2016 finally have SSH support).

I don't know which version of IIS/Windows you're using so I give you a general description:

1) Yes, and this is the reason:

Client certificates are for authentication, not for authorization, do not confuse these two. Authorization is what you do with roles/rules/permissions etc., authentication is letting the server know who you are and proving your identity to it (a client certificate is kind of like an ID).

Also the answer is yes, the certificate is always linked to some kind of account. This is no different to how Linux approaches it. Just after authentication is complete authorization can apply. Or in general terms: Just because I know who you are doesn't mean I let you go into my bedroom. It depends if you are a coworker or a family member.

If the request to the IIS is of any kind of security concern (which I assume) there should also be firewall rules in place, VPN, etc. and also you don't want an unauthenticated user to trigger some kind of response on your server.

2) Don't allow access to the server externally.

If you have a Windows Server on the internet you should definitely make sure nobody you don't want has access to it, a firewall is mandatory! So your question about not being able to "log in to the windows server" is kinda misleading. IIS is part of the windows server and uses its user/group/permission system. E.g. if you look at the Windows Group "Users" you see that

What you want to do is this:

Create a user for this task and remove ALL user groups/roles. The user has absolutely no permissions then. Then, in IIS give him read access to the directory you want him to have access to only. Your guide should cover that part I guess.

On the Note: AD and IIS can both handle client certificates. If you're using IIS standalone, your approach is the right one, in an AD environment you would configure client certificates in the AD, not IIS.

Broco
  • 1,919
  • 12
  • 21
  • Thanks for the your answer, I'll see if I can get this done with an account with no roles/permissions as you state, it seems like a simple and direct solution. And I can also add firewall rules to accept only traffic from the linux box. Regarding the comparison with linux certificates, it should actually be compared to Apache's certificates in any case. Apache doesn't need a mapping to a user to work. – Juan Sep 21 '18 at 15:12
  • I added the Windows Server version to the question. – Juan Sep 21 '18 at 15:18
  • Don't forget, apache has a user account and also you can set user and group permissions on web folders. Not saying it's the same but the principles are the Sam because it just makes sense to confine services to entities under your control. – Broco Sep 23 '18 at 12:18
  • Btw, on the topic of Apache client certificates: Client certificates should always be linked to some kind of entity. Sure, Linux is more free in the way it handles this. With pure Apache you can issue client certificates and keep a revoke list but you have to keep track of all the certificates you issued. So by not linking them to some kind of account you can see the problem: You can lose track of the certs and that's a security risk. But you can also let Apache use LDAP and issue client certificates there, keeping track of all your clients in a way more sophisticated manner. – Broco Sep 25 '18 at 10:34
  • You are mixing things. Both, Linux and Windows, need the certificates linked to an account to log in users to the OS. But this question is about the web server trusting or not an incoming https request. Web servers serve content to entities unrelated to the OS. If the web server or a web app in it require authentication using a certificate, it is the web server or the app asking it, not the OS. By having to create an OS user account for the web server / app to authenticate a connection / login (to the app) I see that principle of least privilege is unnecessarily not respected in Windows. – Juan Sep 25 '18 at 12:40
  • To clarify, the user account I refer to is for each client that holds a certificate to authenticate itself to the web server. Not a user account for the web server to run in the operating system. – Juan Sep 25 '18 at 12:45
  • I wasn't talking about OS-based user authentication, sorry if that wasn't clear. Trying to be more precise: A client authentication needs (to be secure) some logic behind it to map it to a specific entity so you can for example block it or handle permissions based on the entity (e.g. user). Apache gives you the freedom not to do so but then you have to manually keep track of the client certificates you issue. Windows doesn't. IIS is a Windows component, and thus forces you to use its infrastructure while Apache is a completely seperate software that can be interfaced with other services. – Broco Sep 25 '18 at 12:46
  • And I agree, Windows doesn't respect the principle of least privilege. But then again, Apache's standalone approach isn't really secure (because not foolproof) either because there is no entity associated with a certificate you can just "block" (which doesn't matter if you only have one client certificate but it definitely matters if you have 200). In the end it always comes down to knowing about the pitfalls in the software you use. – Broco Sep 25 '18 at 12:55