Score:0

Apache 2.4 no auth config works in VirtualHost

cv flag

I'm setting up a brand new server — I literally just spun up an AWS EC2 instance, did a fresh install of apache and mod_ssl, and have close to the simplest of configs. Apache appears to ignore any auth configuration (including LogLevel) in VirtualHost blocks.

This is with Apache 2.4.51 on amzn2.x86_64 Linux.

I started by redirecting HTTP to HTTPS, and then followed the basic instructions for Apache 2.4 Authentication and Authorization. That got me to the following virtual.conf:

<VirtualHost _default_:80>
        DocumentRoot /var/www/html
        RewriteEngine On
        RewriteCond %{HTTPS} !=on
        RewriteCond %{HTTP_HOST} !^(localhost|127.0.0.1)
        RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [R,L]
</VirtualHost>

<VirtualHost *:443>
        LogLevel debug
        SSLEngine on
        SSLCertificateFile /etc/pki/tls/certs/ca.crt
        SSLCertificateKeyFile /etc/pki/tls/private/ca.key
        <Directory "/var/www/html">
                AllowOverride All
                Options Indexes FollowSymLinks
                AuthType Basic
                AuthName "Restricted Files"
                # (Following line optional)
                AuthBasicProvider file
                AuthUserFile "/mount/local/apache/passwd/passwords"
                Require user someuser
        </Directory>
        DocumentRoot /var/www/html
</VirtualHost>

In general, the above seems to be working, with the exception of auth stuff. If I go to my IP address in a web browser, it correctly redirects to 443, it serves the certificates from the specified (non-standard) path, and I can see it logging debug level activity, at least for mod_ssl. However, it just serves this index.html from /var/www/html/ (NB: /var/www/html is a symlink).

I found this other question, which led me to look for any Require all granted directives.

# pwd
/etc/httpd/conf.d
# grep Require * 2>/dev/null
autoindex.conf:# Required modules: mod_authz_core, mod_authz_host,
autoindex.conf:    Require all granted
ssl.conf:#   With SSLRequire you can do per-directory access control based
ssl.conf:#SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
ssl.conf:#   o StrictRequire:
ssl.conf:#     This denies access when "SSLRequireSSL" or "SSLRequire" applied even
ssl.conf:#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
userdir.conf:    Require method GET POST OPTIONS
virtual.conf:       Require user someuser
welcome.conf:    Require all granted

The one in autoindex.conf is inside of a <Directory "/usr/share/httpd/icons"> block, and the one in welcome.conf is in <Directory /usr/share/httpd/noindex>. I did find one in /etc/httpd/conf/http.conf:

# Further relax access to the default document root:
<Directory "/var/www/html">
    Options Indexes FollowSymLinks
    AllowOverride None
    Require all granted
</Directory>

Note, on this installation (via yum on Amazon Linux 2), the main config file is /etc/httpd/conf/http.conf. The last line of that file is IncludeOptional conf.d/*.conf. My main configuration I posted above is in /etc/httpd/conf.d/virtual.conf.

I tried commenting out that Require all granted and restarted the server, but no change. That's when I noticed that it doesn't appear to be doing anything at all. That previously mentioned question showed some entries in his log file. However, even though I have LogLevel debug, I'm not seeing anything related to authz_core in the log files, as he was. ¯_(ツ)_/¯

At this point, I tried a number of modifications inside of the <VirtualHost> block:

  • I tried wrapping the lines AuthType basic through Require user someuser in a <RequireAll> block
  • I tried adding Require all denied before the Require user
  • I tried using a .htaccess file with the same configuration
  • I tried changing the AllowOverride All to AllowOverride All AuthConfig and using a .htaccess file
  • I tried extending the logging to LogLevel debug auth_basic:trace1 authz_core:trace1

In all cases, no change, and the configuration parses fine. The server just serves the page, and there's nothing in any of the log files.

However, if I make changes in the main conf/httpd.conf file inside of the <Directory "/var/www/html"> block, things work as expected:

  • changing Require all granted to Require all denied (instead of commenting it out) blocks all access
  • changing AllowOverride none to AllowOverride AuthConfig makes my .htaccess file with the same auth configuration as in the <VirtualHost> block work as expected — it solicits username and password
  • turning up logging with LogLevel debug auth_basic:trace1 authz_core:trace1 gets me lots of logging

So, to summarize, even though my <VirtualHost> config is working in general (redirect, SSL, debug for everything except auth), it appears to silently ignore any auth configuration, including LogLevel.

In the short term, I've solved my problem by undoing all the changes I made in the main config file, so things don't get overridden during a software update, and put them in conf/00-override.conf:

<Directory "/var/www/html">
    AllowOverride All
    AuthType Basic
    AuthName "Restricted Files"
    # (Following line optional)
    AuthBasicProvider file
    AuthUserFile "/mount/local/apache/passwd/passwords"
    Require user someuser
</Directory>

However, it would be good to be able to configure authorization at the virtual-host level. Any ideas?

Gerard H. Pille avatar
in flag
Have the necessary modules been loaded? What do you get in the error log when you restart Apache?
philolegein avatar
cv flag
I'm not entirely sure which are "necessary", but `apachectl -t -D DUMP_MODULES` _looks_ right to me. In the error log on restart, the only messages are about heartbeat monitor and mpm not being supported. I can put the full restart log in the question, if you think it will help.
Gerard H. Pille avatar
in flag
There's no .conf file in /etc/httpd that specifies access rules for /var/www and an "allowoverride none" ?
philolegein avatar
cv flag
/etc/httpd/httpd.conf does have a `Require all granted` for /var/www before its /var/www/html entry, but I assumed the later, more specific took precedence. In that same file /, /var/www, and /var/www/html all have an allowoverride none.
Gerard H. Pille avatar
in flag
You are correct, "allowoverride" counts for .htaccess. There's no .htaccess in /var/www/html? You do have two configurations for /var/www/html. I wonder in what order they are parsed.
Gerard H. Pille avatar
in flag
Also, don't forget to clear your browser's cache.
philolegein avatar
cv flag
The only thing in /var/www/html is an index.html that says Hello World. According to https://httpd.apache.org/docs/2.4/sections.html#merging "Sections inside <VirtualHost> sections are applied after the corresponding sections outside the virtual host definition. This allows virtual hosts to override the main server configuration.", so should be fine. I can't imagine how caching would matter, since I see the request on the server, but I cleared it anyhow, and still same behavior.
philolegein avatar
cv flag
Also, I tried adding `Require all denied` to the vhost config, and still same behavior.
Gerard H. Pille avatar
in flag
Add separate logs for that host, to see if it is being used.
philolegein avatar
cv flag
@GerardH.Pille — substantial edits to the question; it now seems clear it's a problem inside the virtual-host blocks.
Gerard H. Pille avatar
in flag
It used to be the case (I was already working with Apache 1.4) that one had to activate the use of VirtualHosts, but I thought that was no longer the case. Did you try separate logs for that host? Any other VirtualHost configs apart from the two you show?
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.