Home / server / Questions / 373104
Accepted
Brad
Asked: 2012-03-25 18:36:10 +0800 CST

Why isn't Apache Basic authentication working?

  • 772

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???

apache-2.2

8 Answers

  1. Best Answer

    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.

    • 16

  2. 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>
    • 11

  3. 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>
    • 6

  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
    • 4

  5. 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
    • 1

  6. 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 :(

    • 1

  7. 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

  8. 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.

    • 0