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) 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, if I really need to create an account on the Windows machine, how should I configure it so it only can be used to authenticate the IIS's requests from the Linux server?

  • Does the application hosted on IIS require authentication or is this something you'd like to have in place to ensure only the Linux host will have access? Commented Sep 13, 2018 at 19:53
  • I am sorry but I cant't see the difference between the two statements. What I want is that for this application it only responds to requests coming from a particular Linux Server. I understand that for doing this the application will have to require client authentication to the Linux server.
    – Juan
    Commented Sep 13, 2018 at 20:06
  • @user2320464 If the question was if the application will have a login page. It won't.
    – Juan
    Commented Sep 13, 2018 at 20:12
  • What utility will be used to make the web requests? Commented Sep 13, 2018 at 20:31
  • @user2320464 a php script using curl.
    – Juan
    Commented Sep 13, 2018 at 20:32

2 Answers 2


You're right to be concerned with creating a new user account just for this task. A much easier approach is to use an application key inserted into the request header. Since you're using self-signed certificates, this leads me to believe that this is a one-off solution and won't be scaled to hundreds of clients. Here are the steps to make this happen.

UPDATE: this alternative solution will have no impact on the IIS hosted application since URL Rewrite will process the request before the application. To immediately drop failed attempts, update the action section of the URL Rewrite rule to the following. Note that this will cause failed requests to not appear in IIS logs.

<action type="AbortRequest" />

Install URL Rewrite on IIS

This is a Microsoft module that isn't installed by default and provides functionality similar to mod_rewrite.


Create URL Rewrite Rule

Add the following rule to the web.config for your application. It will look for a request header of AppAuthKey (which you can change/personalize) and a value of joshua (not case sensitive and should be something more complex). If either is not present, the 401.4 will be returned.

<?xml version="1.0" encoding="UTF-8"?>
                <rule name="Application-Request-Header-Filter" patternSyntax="Wildcard" stopProcessing="true">
                    <match url="*" />
                        <add input="{HTTP_AppAuthKey}" pattern="joshua" negate="true" />
                    <action type="CustomResponse" statusCode="401" subStatusCode="4" statusReason="Access denied." statusDescription="Authorization failed by filter." />

Edit curl command

Update your curl command to include the request header as follows:

curl -H "AppAuthKey: joshua"

No Need for a Client Certificate

Using this method doesn't require a client certificate. Normal SSL (should be TLS1.2) will suffice as long are you're using strong ciphers. More information about this can be found at the following OWASP page:



@AlphaD brings up good points regarding various policy settings one can use to further limit accounts. I would recommend against this since it goes against configuration management. Taking that approach introduces configuration requirements for the system hosting the web application that may or may not impact other services. The preferred method is to architect the web app for portability so little of the hosting system is required. Suppose it makes sense to highlight some key points as to why it’s preferred to use an application key in this instance rather than a local or domain user account on IIS.

Local User

If the user is local to just the web server hosting IIS, then that account will be able to authenticate to any other website and/or service hosted by that server. Make sure permissions on all other resources are reviewed because by default the account will be a member of the local "Users" group which has a surprisingly wide breadth. Additionally this account has Read access on the file system (NTFS). If another website is misconfigured, this user could be used to authenticate and read its contents. Authentication via this account will most likely use Basic Authentication which means the credentials are Base64 encoded (not encrypted) and placed into every request header. (Just like my recommendation of adding a custom request header for authentication.) Lastly, using local user accounts makes system management difficult. When migrating the website to a new server, a new account must be created with permissions updated and properly scoped. That logon information then needs to be updated in the consuming curl script(s). It doesn’t make your application portable.

Domain User

Same as local user, now the scope of where this user can authenticate has expanded to the entire domain. This includes Read access to much of active directory and other services advertised in the environment. Authenticating with this user will be a bit more secure since NTLM or Kerberos can be used as long as AD is accessible and your Linux host is configured for AD auth. Otherwise Basic Auth will probably be used. Account management becomes a bit easier since it will fall into the realm of domain account management instead of system account management and often (not always) there are well established procedures for domain account management.

Application Key

Preferred method since no user account is required and limits the scope to just this application. Making the weak point the communication channel (secured via TLS and strong ciphers) and the content directory which should have limited access anyway.

  • I will consider this alternative, but I would prefer to implement authentication with certificates. I guess I could turn 'joshua' into a token (I hope Dr. Falken doesn't mind) and validate the token at application level if I didn't trust the rewrite module. I'll keep this alternative in mind if nothing else comes up.
    – Juan
    Commented Sep 14, 2018 at 12:25
  • Great, that's what I was aiming for, to provide a suitable alternative. Using a user account with mutual certificate authentication would be more secure. The downside is managing another user account. This alternative solution will have no impact on your application since URL Rewrite will process the request before it gets handed off to the application. This seemed like the best solution without having details of the IIS app. Commented Sep 14, 2018 at 17:18
  • This answer is not what I expected but I it does provide an alternative solution and also provides useful insights, so I will mark this answer as the correct one. Still I am left with a bitter taste in the mouth, I really can't belive that IIS can't handle client certificate authentication without having to map a user account.
    – Juan
    Commented Sep 21, 2018 at 2:13
  • Thanks @Juan! Hopefully you'll find that the implementation and maintenance of using an app key will make that bitter taste quickly subside. Commented Sep 24, 2018 at 17:01

From what I can understand of your question, you're asking for a method to generate a windows server user without allowing login or other normally granted permissions.

If that is the case you can do this by setting the local policy for that user in Control Panel > Administrative Tools > Local Security Policy. On the left menu go to Local Policies > User Right Assignments. Add the user to the "Deny log on locally" "Deny log on through Remote Desktop Services" policies (and any others applicable).

Please note I might be missing a few things here as I've only tried this to prevent users from seeing service accounts on the login screen.

  • The answer I was expecting was in these lines, but given that this solution seems to have many moving parts in terms of configuration, aspects to keep in mind, and possible trade-offs, I would expect a more detailed explanation to give this answer as the correct one.
    – Juan
    Commented Sep 21, 2018 at 2:04
  • Thanks Juan, unfortunately I can only hope someone with more knowledge can point you to the exact configuration. I had a nightmare trying to set this up for basic authentication a long time ago and the windows documentation isn't too helpful either.
    – AlphaD
    Commented Sep 21, 2018 at 3:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .