| <!--#if expr="$FAQMASTER" --> |
| <!--#set var="STANDALONE" value="" --> |
| <!--#set var="INCLUDED" value="YES" --> |
| <!--#if expr="$QUERY_STRING = TOC" --> |
| <!--#set var="TOC" value="YES" --> |
| <!--#set var="CONTENT" value="" --> |
| <!--#else --> |
| <!--#set var="TOC" value="" --> |
| <!--#set var="CONTENT" value="YES" --> |
| <!--#endif --> |
| <!--#else --> |
| <!--#set var="STANDALONE" value="YES" --> |
| <!--#set var="INCLUDED" value="" --> |
| <!--#set var="TOC" value="" --> |
| <!--#set var="CONTENT" value="" --> |
| <!--#endif --> |
| <!--#if expr="$STANDALONE" --> |
| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> |
| <HTML> |
| <HEAD> |
| <TITLE>Apache Server Frequently Asked Questions</TITLE> |
| </HEAD> |
| <!-- Background white, links blue (unvisited), navy (visited), red (active) --> |
| <BODY |
| BGCOLOR="#FFFFFF" |
| TEXT="#000000" |
| LINK="#0000FF" |
| VLINK="#000080" |
| ALINK="#FF0000" |
| > |
| <!--#include virtual="header.html" --> |
| <H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1> |
| <P> |
| $Revision: 1.5 $ ($Date: 2001/02/28 03:36:00 $) |
| </P> |
| <P> |
| The latest version of this FAQ is always available from the main |
| Apache web site, at |
| <<A |
| HREF="http://www.apache.org/docs/misc/FAQ.html" |
| REL="Help" |
| ><SAMP>http://www.apache.org/docs/misc/FAQ.html</SAMP></A>>. |
| </P> |
| <!-- Notes about changes: --> |
| <!-- - If adding a relative link to another part of the --> |
| <!-- documentation, *do* include the ".html" portion. There's a --> |
| <!-- good chance that the user will be reading the documentation --> |
| <!-- on his own system, which may not be configured for --> |
| <!-- multiviews. --> |
| <!-- - When adding items, make sure they're put in the right place --> |
| <!-- - verify that the numbering matches up. --> |
| <!-- - *Don't* use <PRE></PRE> blocks - they don't appear --> |
| <!-- correctly in a reliable way when this is converted to text --> |
| <!-- with Lynx. Use <DL><DD><CODE>xxx<BR>xx</CODE></DD></DL> --> |
| <!-- blocks inside a <P></P> instead. This is necessary to get --> |
| <!-- the horizontal and vertical indenting right. --> |
| <!-- - Don't forget to include an HR tag after the last /P tag --> |
| <!-- but before the /LI in an item. --> |
| <P> |
| If you are reading a text-only version of this FAQ, you may find numbers |
| enclosed in brackets (such as "[12]"). These refer to the list of |
| reference URLs to be found at the end of the document. These references |
| do not appear, and are not needed, for the hypertext version. |
| </P> |
| <H2>The Questions</H2> |
| <OL TYPE="A"> |
| <!--#endif --> |
| <!--#if expr="$TOC || $STANDALONE" --> |
| <LI VALUE="7"><STRONG>Authentication and Access Restrictions</STRONG> |
| <OL> |
| <LI><A HREF="#dnsauth">Why isn't restricting access by host or domain name |
| working correctly?</A> |
| </LI> |
| <LI><A HREF="#user-authentication">How do I set up Apache to require |
| a username and password to access certain documents?</A> |
| </LI> |
| <LI><A HREF="#remote-auth-only">How do I set up Apache to allow access |
| to certain documents only if a site is either a local site |
| <EM>or</EM> the user supplies a password and username?</A> |
| </LI> |
| <LI><A HREF="#authauthoritative">Why does my authentication give |
| me a server error?</A> |
| </LI> |
| <LI><A HREF="#auth-on-same-machine">Do I have to keep the (mSQL) |
| authentication information on the same machine?</A> |
| </LI> |
| <LI><A HREF="#msql-slow">Why is my mSQL authentication terribly slow?</A> |
| </LI> |
| <LI><A HREF="#passwdauth">Can I use my <SAMP>/etc/passwd</SAMP> file |
| for Web page authentication?</A> |
| </LI> |
| <LI><A HREF="#prompted-twice">Why does Apache ask for my password |
| twice before serving a file?</a> |
| </LI> |
| </OL> |
| </LI> |
| <!--#endif --> |
| <!--#if expr="$STANDALONE" --> |
| </OL> |
| |
| <HR> |
| |
| <H2>The Answers</H2> |
| <!--#endif --> |
| <!--#if expr="! $TOC" --> |
| <H3>G. Authentication and Access Restrictions</H3> |
| <OL> |
| |
| <LI><A NAME="dnsauth"> |
| <STRONG>Why isn't restricting access by host or domain name |
| working correctly?</STRONG> |
| </A> |
| <P> |
| Two of the most common causes of this are: |
| </P> |
| <OL> |
| <LI><STRONG>An error, inconsistency, or unexpected mapping in the DNS |
| registration</STRONG> |
| <BR> |
| This happens frequently: your configuration restricts access to |
| <SAMP>Host.FooBar.Com</SAMP>, but you can't get in from that host. |
| The usual reason for this is that <SAMP>Host.FooBar.Com</SAMP> is |
| actually an alias for another name, and when Apache performs the |
| address-to-name lookup it's getting the <EM>real</EM> name, not |
| <SAMP>Host.FooBar.Com</SAMP>. You can verify this by checking the |
| reverse lookup yourself. The easiest way to work around it is to |
| specify the correct host name in your configuration. |
| </LI> |
| <LI><STRONG>Inadequate checking and verification in your |
| configuration of Apache</STRONG> |
| <BR> |
| If you intend to perform access checking and restriction based upon |
| the client's host or domain name, you really need to configure |
| Apache to double-check the origin information it's supplied. You do |
| this by adding the <SAMP>-DMAXIMUM_DNS</SAMP> clause to the |
| <SAMP>EXTRA_CFLAGS</SAMP> definition in your |
| <SAMP>Configuration</SAMP> file. For example: |
| <P> |
| <DL> |
| <DD><CODE>EXTRA_CFLAGS=-DMAXIMUM_DNS</CODE> |
| </DD> |
| </DL> |
| <P></P> |
| <P> |
| This will cause Apache to be very paranoid about making sure a |
| particular host address is <EM>really</EM> assigned to the name it |
| claims to be. Note that this <EM>can</EM> incur a significant |
| performance penalty, however, because of all the name resolution |
| requests being sent to a nameserver. |
| </P> |
| </LI> |
| </OL> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="user-authentication"> |
| <STRONG>How do I set up Apache to require a username and |
| password to access certain documents?</STRONG> |
| </A> |
| <P> |
| There are several ways to do this; some of the more popular |
| ones are to use the <A HREF="../mod/mod_auth.html">mod_auth</A>, |
| <A HREF="../mod/mod_auth_db.html">mod_auth_db</A>, or |
| <A HREF="../mod/mod_auth_dbm.html">mod_auth_dbm</A> modules. |
| </P> |
| <P> |
| For an explanation on how to implement these restrictions, see |
| <A HREF="http://www.apacheweek.com/"><CITE>Apache Week</CITE></A>'s |
| articles on |
| <A HREF="http://www.apacheweek.com/features/userauth" |
| ><CITE>Using User Authentication</CITE></A> |
| or |
| <A HREF="http://www.apacheweek.com/features/dbmauth" |
| ><CITE>DBM User Authentication</CITE></A>. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="remote-auth-only"> |
| <STRONG>How do I set up Apache to allow access to certain |
| documents only if a site is either a local site <EM>or</EM> |
| the user supplies a password and username?</STRONG> |
| </A> |
| <P> |
| Use the <A HREF="../mod/core.html#satisfy">Satisfy</A> directive, |
| in particular the <CODE>Satisfy Any</CODE> directive, to require |
| that only one of the access restrictions be met. For example, |
| adding the following configuration to a <SAMP>.htaccess</SAMP> |
| or server configuration file would restrict access to people who |
| either are accessing the site from a host under domain.com or |
| who can supply a valid username and password: |
| </P> |
| <P> |
| <DL> |
| <DD><CODE>Deny from all |
| <BR> |
| Allow from .domain.com |
| <BR> |
| AuthType Basic |
| <BR> |
| AuthUserFile /usr/local/apache/conf/htpasswd.users |
| <BR> |
| AuthName "special directory" |
| <BR> |
| Require valid-user |
| <BR> |
| Satisfy any</CODE> |
| </DD> |
| </DL> |
| <P></P> |
| <P> |
| See the <A HREF="#user-authentication">user authentication</A> |
| question and the <A HREF="../mod/mod_access.html">mod_access</A> |
| module for details on how the above directives work. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="authauthoritative"> |
| <STRONG>Why does my authentication give me a server error?</STRONG> |
| </A> |
| <P> |
| Under normal circumstances, the Apache access control modules will |
| pass unrecognized user IDs on to the next access control module in |
| line. Only if the user ID is recognized and the password is validated |
| (or not) will it give the usual success or "authentication |
| failed" messages. |
| </P> |
| <P> |
| However, if the last access module in line 'declines' the validation |
| request (because it has never heard of the user ID or because it is not |
| configured), the <SAMP>http_request</SAMP> handler will give one of |
| the following, confusing, errors: |
| </P> |
| <UL> |
| <LI><SAMP>check access</SAMP> |
| </LI> |
| <LI><SAMP>check user. No user file?</SAMP> |
| </LI> |
| <LI><SAMP>check access. No groups file?</SAMP> |
| </LI> |
| </UL> |
| <P> |
| This does <EM>not</EM> mean that you have to add an |
| '<SAMP>AuthUserFile /dev/null</SAMP>' line as some magazines suggest! |
| </P> |
| <P> |
| The solution is to ensure that at least the last module is authoritative |
| and <STRONG>CONFIGURED</STRONG>. By default, <SAMP>mod_auth</SAMP> is |
| authoritative and will give an OK/Denied, but only if it is configured |
| with the proper <SAMP>AuthUserFile</SAMP>. Likewise, if a valid group |
| is required. (Remember that the modules are processed in the reverse |
| order from that in which they appear in your compile-time |
| <SAMP>Configuration</SAMP> file.) |
| </P> |
| <P> |
| A typical situation for this error is when you are using the |
| <SAMP>mod_auth_dbm</SAMP>, <SAMP>mod_auth_msql</SAMP>, |
| <SAMP>mod_auth_mysql</SAMP>, <SAMP>mod_auth_anon</SAMP> or |
| <SAMP>mod_auth_cookie</SAMP> modules on their own. These are by |
| default <STRONG>not</STRONG> authoritative, and this will pass the |
| buck on to the (non-existent) next authentication module when the |
| user ID is not in their respective database. Just add the appropriate |
| '<SAMP><EM>XXX</EM>Authoritative yes</SAMP>' line to the configuration. |
| </P> |
| <P> |
| In general it is a good idea (though not terribly efficient) to have the |
| file-based <SAMP>mod_auth</SAMP> a module of last resort. This allows |
| you to access the web server with a few special passwords even if the |
| databases are down or corrupted. This does cost a |
| file open/seek/close for each request in a protected area. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="auth-on-same-machine"> |
| <STRONG>Do I have to keep the (mSQL) authentication information |
| on the same machine?</STRONG> |
| </A> |
| <P> |
| Some organizations feel very strongly about keeping the authentication |
| information on a different machine than the webserver. With the |
| <SAMP>mod_auth_msql</SAMP>, <SAMP>mod_auth_mysql</SAMP>, and other SQL |
| modules connecting to (R)DBMses this is quite possible. Just configure |
| an explicit host to contact. |
| </P> |
| <P> |
| Be aware that with mSQL and Oracle, opening and closing these database |
| connections is very expensive and time consuming. You might want to |
| look at the code in the <SAMP>auth_*</SAMP> modules and play with the |
| compile time flags to alleviate this somewhat, if your RDBMS licences |
| allow for it. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="msql-slow"> |
| <STRONG>Why is my mSQL authentication terribly slow?</STRONG> |
| </A> |
| <P> |
| You have probably configured the Host by specifying a FQHN, |
| and thus the <SAMP>libmsql</SAMP> will use a full blown TCP/IP socket |
| to talk to the database, rather than a fast internal device. The |
| <SAMP>libmsql</SAMP>, the mSQL FAQ, and the <SAMP>mod_auth_msql</SAMP> |
| documentation warn you about this. If you have to use different |
| hosts, check out the <SAMP>mod_auth_msql</SAMP> code for |
| some compile time flags which might - or might not - suit you. |
| </P> |
| <HR> |
| </LI> |
| |
| <LI><A NAME="passwdauth"> |
| <STRONG>Can I use my <SAMP>/etc/passwd</SAMP> file |
| for Web page authentication?</STRONG> |
| </A> |
| <P> |
| Yes, you can - but it's a <STRONG>very bad idea</STRONG>. Here are |
| some of the reasons: |
| </P> |
| <UL> |
| <LI>The Web technology provides no governors on how often or how |
| rapidly password (authentication failure) retries can be made. That |
| means that someone can hammer away at your system's |
| <SAMP>root</SAMP> password using the Web, using a dictionary or |
| similar mass attack, just as fast as the wire and your server can |
| handle the requests. Most operating systems these days include |
| attack detection (such as <EM>n</EM> failed passwords for the same |
| account within <EM>m</EM> seconds) and evasion (breaking the |
| connection, disabling the account under attack, disabling |
| <EM>all</EM> logins from that source, <EM>et cetera</EM>), but the |
| Web does not. |
| </LI> |
| <LI>An account under attack isn't notified (unless the server is |
| heavily modified); there's no "You have 19483 login |
| failures" message when the legitimate owner logs in. |
| </LI> |
| <LI>Without an exhaustive and error-prone examination of the server |
| logs, you can't tell whether an account has been compromised. |
| Detecting that an attack has occurred, or is in progress, is fairly |
| obvious, though - <EM>if</EM> you look at the logs. |
| </LI> |
| <LI>Web authentication passwords (at least for Basic authentication) |
| generally fly across the wire, and through intermediate proxy |
| systems, in what amounts to plain text. "O'er the net we |
| go/Caching all the way;/O what fun it is to surf/Giving my password |
| away!" |
| </LI> |
| <LI>Since HTTP is stateless, information about the authentication is |
| transmitted <EM>each and every time</EM> a request is made to the |
| server. Essentially, the client caches it after the first |
| successful access, and transmits it without asking for all |
| subsequent requests to the same server. |
| </LI> |
| <LI>It's relatively trivial for someone on your system to put up a |
| page that will steal the cached password from a client's cache |
| without them knowing. Can you say "password grabber"? |
| </LI> |
| </UL> |
| <P> |
| If you still want to do this in light of the above disadvantages, the |
| method is left as an exercise for the reader. It'll void your Apache |
| warranty, though, and you'll lose all accumulated UNIX guru points. |
| </P> |
| <HR> |
| </LI> |
| <LI><A NAME="prompted-twice"><STRONG>Why does Apache ask for my password |
| twice before serving a file?</STRONG></a> |
| <P> |
| If the hostname under which you are accessing the server is |
| different than the hostname specified in the |
| <A HREF="../mod/core.html#servername"><CODE>ServerName</CODE></A> |
| directive, then depending on the setting of the |
| <A HREF="../mod/core.html#usecanonicalname"><CODE>UseCanonicalName</CODE></A> |
| directive, Apache will redirect you to a new hostname when |
| constructing self-referential URLs. This happens, for example, in |
| the case where you request a directory without including the |
| trailing slash. |
| </P> |
| <P> |
| When this happens, Apache will ask for authentication once under the |
| original hostname, perform the redirect, and then ask again under the |
| new hostname. For security reasons, the browser must prompt again |
| for the password when the host name changes. |
| </P> |
| <P> |
| To eliminate this problem you should |
| </P> |
| |
| <OL> |
| <LI>Always use the trailing slash when requesting directories; |
| <LI>Change the <CODE>ServerName</CODE> to match the name you are |
| using in the URL; and/or |
| <LI>Set <CODE>UseCanonicalName off</CODE>. |
| </OL> |
| <HR> |
| </LI> |
| |
| </OL> |
| <!--#endif --> |
| <!--#if expr="$STANDALONE" --> |
| <!-- Don't forget to add HR tags at the end of each list item.. --> |
| |
| <!--#include virtual="footer.html" --> |
| </BODY> |
| </HTML> |
| <!--#endif --> |