17

I just upgraded Apache from it's 2003 build, to a squeaky-clean, brand-new 2.4.1 build. All seems pretty good except for one glaring thing:

In my httpd.conf file I have the following:

<Directory />
    AllowOverride none
    Options FollowSymLinks
    AuthType      Basic
    AuthName      "Enter Password"
    AuthUserFile  /var/www/.htpasswd
    Require     valid-user
</Directory>

This should allow only users in the specified auth file to access the server - just as it had under the older version of Apache. (Right?)

However, it's not working. Requests are granted with no authentication provided. When I switch logging to LogLevel Debug, for the accesses, it says:

[Sat Mar 24 21:32:00.585139 2012] [authz_core:debug] [pid 10733:tid 32771] mod_authz_core.c(783): [client 192.168.1.181:57677] AH01626: authorization result of Require all granted: granted
[Sat Mar 24 21:32:00.585446 2012] [authz_core:debug] [pid 10733:tid 32771] mod_authz_core.c(783): [client 192.168.1.181:57677] AH01626: authorization result of <RequireAny>: granted

I really don't know what this means - and I (to the best of my knowledge) don't have any "Require all granted" or "" statements in any of my files.

Any ideas why this isn't working, or where to debug??

UPDATE:

I have a virtualhost on the SSL port which allows proxying. When I put the same entries inside the

<proxy *> 

clause in the virtualhost config, it works. It doesn't seem to work in the

 <Directory> 

clause. I then tried putting under other Directory clauses (specific for other directories) and that didn't work either.

ALSO

From Shane's questions below - I tried duplicating the root "/" block to a "/tmp" directory. The /tmp directory works CORRECTLY!! So - this problem is specific to the root directory only???

6
  • 1
    What other <Directory> blocks do you have applying to the requests that aren't working? Mar 25 '12 at 23:10
  • I just put one for the root "/" directory, which should apply to the entire server. I have tried adding one to the user home directory (per mod_userdir) and had the same results with that.
    – Brad
    Mar 26 '12 at 0:03
  • @ShaneMadden - on your question - I tried duplicating the root "/" block to a "/tmp" directory. The /tmp directory works CORRECTLY!! So - this problem is specific to the root directory only???
    – Brad
    Mar 26 '12 at 0:09
  • I suspect that there's a more-specific <Directory> block elsewhere in your Apache config that's taking precedence over the one that you've set for /. Mar 26 '12 at 0:16
  • I just grepped everything - nothing. These config files were very minimal modifications to Apache's newly-installed defaults.
    – Brad
    Mar 26 '12 at 0:29
15

I had a similar problem with Digest authentication on a fresh 2.4 install. Looking closely at the documentation on Apache's site, it looks like the authentication directives need to be in a <Location> tag rather than a <Directory> tag. See the documentation for the AuthBasicProvider directive.

2
10

I faced the same problem, and nothing from this post have helped me, so I'll add my 2 cents. In my case (apache 2.4) the problem was in the sequential Require directives.

By default, if you have more than one Require directives, they are considered as <RequireAny>

In my <Directory> I've had

Require ip 192.168.100.0/24 10.9.8.0/24
Require valid-user

So auth request didn't appear if IP was correct. I've had to switch Require logic from <RequireAny> to <RequireAll> and it seems that now everything works correct.

   <Directory /var/www>

      DirectoryIndex index.html
      Options -Indexes

      AuthType Basic
      AuthName "hidden data"
      AuthBasicProvider    file
      AuthUserFile /opt/httpaswd
      <RequireAll>
        Require ip 192.168.100.0/24 10.9.8.0/24
        Require valid-user
      </RequireAll>
    </Directory>
6

jscott's answer is incorrect. Apache 2.4 most certainly does allow authentication directives in <Directory> containers. Moreover, this is the only secure way to implement authentication, as <Location> containers can be accessed in different ways, allowing your authentication to be circumvented if you're not careful.

For the sake of reference, here is a sample container I am using on a production system:

<Directory "/srv/http/my_domain.org/html/secret-stuff">
    Options Indexes Multiviews FollowSymLinks
    AuthType Digest
    AuthName "staff"
    AuthUserFile /etc/httpd/private/secret-stuff.htaccess
    Require valid-user
</Directory>
4

Also check if there isn't accidentally another

    Require all granted

elsewhere in the same Directory config. it may be overriding your

    Require     valid-user
1
  • 1
    stupid me, that was the case in my example. Just found it via google. Thank you @commonpike.
    – merlin
    Jul 14 at 11:52
1

You appear to be missing a provider for AuthBasic. Try adding a line like:

AuthBasicProvider    file

Once you have this working you may want to look at the Satisfy directive. This can be used to allow local access without a password, while requiring a password for Internet access.

EDIT: I user an include file for BasicAuth to enable password basedd remote access to content which is normally not available from the Internet. You may not want the Satisfy directive. This is my /etc/apache2/basicauth.conf file:

# Basic authorization configuration include file 
# Enable basic auth access for remote users
AuthName             "Authentication Required"
AuthType             Basic
AuthBasicProvider    file
AuthUserFile         /etc/apache2/httpd.passwd
Require              valid-user
Satisfy              any

I also have an /etc/apache2/allow_local.conf include file for IP based authentication.

# Common local access block - Allow all local addresses
Order deny,allow
Deny  from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
Allow from 192.168.1.0/24

To enable them I use these includes.

Include /etc/apache2/allow_local.conf
Include /etc/apache2/basicauth.conf

You may want to try adding to to authorization specification. This works with my test configuration.

Order deny,allow
Allow from all
3
  • Tried it - still doesn't work :-O
    – Brad
    Mar 25 '12 at 15:08
  • If I just include your files as-is, I get an error: "AuthName not allowed here" - as you can't specify these directives anywhere (like outside a "Location", "Directory", or "Proxy" clause. Or am I missing something? If I do include it inside the "Directory" clause - again - I am let in without any credentials.
    – Brad
    Mar 25 '12 at 20:39
  • If I only put a "deny from all" in the "directory" clause, I am denied access (as you'd expect). If then include your FIRST script in the directory clause, I am unconditionally allowed access. If I remove the "satisfy" in your script, I am unconditionally denied.
    – Brad
    Mar 25 '12 at 20:50
1

I had the same problem and it's likely to be an Apache bug; in my case, the problem showed up after an update, and disappeared after a subsequent update, but I had to add this at the bottom:

Deny from all

That's scary that Apache could open security holes like this :(

3
  • Deny from all is an apache 2.2 setting. httpd.apache.org/docs/2.4/upgrading.html#run-time
    – danger89
    Nov 4 '15 at 21:09
  • yes changing security-related directives in a backward-incompatible way is baaaaaad
    – greg
    Nov 6 '15 at 16:27
  • 1
    I'm surprised that apache didn't give me a warning for basically ignoring BasicAuth directives before I added this.
    – user84207
    Jul 23 '20 at 20:28
0

Try:
<Directory "/"> ... </Directory>

Instead of:
<Directory /> ... </Directory>

Meaning: encapsulate the root symbol with double quotes. Otherwise, you might be closing the tag with that slash.

0

In my case I was building a sandbox to test some basic Apache features. When I tried setting up the authentication, my requests were also being granted without any authentication needed.

After trying the other answers, what ended up working for me was clearing the cache in my web browser. After that I was required to authenticate as expected.

I know it's very simple and specific to my case, but I figured I would post in case others have a similar issue later on.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.