mirror of
				https://github.com/apache/httpd.git
				synced 2025-10-30 08:05:39 +03:00 
			
		
		
		
	browsing with SSIs but more easily posted on USENET. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@83378 13f79535-47bb-0310-9956-ffa450edef68
		
			
				
	
	
		
			372 lines
		
	
	
		
			14 KiB
		
	
	
	
		
			HTML
		
	
	
	
	
	
			
		
		
	
	
			372 lines
		
	
	
		
			14 KiB
		
	
	
	
		
			HTML
		
	
	
	
	
	
| <!--#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.1 $ ($Date: 1999/06/24 15:02:52 $)
 | |
|   </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>
 | |
|   </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>
 | |
| </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 -->
 |