LDAP authentication with password encryption from browser to webserver

I have been looking through a lot of documentation on this
subject, both on apache.org and elsewhere, and I can't seem to
find an answer to the following question:

Our Apache web server (version 2.2.11 running on Solaris 10) is
currently authenticating users via LDAP successfully. But, we
would like to have an *encrypted* password sent from *the
browser to the Apache web server* when authenticating via LDAP.
I understand that encryption is performed from the web server to
the LDAP server by using ldaps, which we are using, but we are
getting complaints that the password is traveling from the
users' web browsers to our Apache web server in the clear (not
encrypted). The problem really requires that the web browsers
and Apache support an encrypted authentication over http instead
of counting on wrapping everything via https. It would be nice
if the public key encryption worked between the browser and
Apache for the password part.

I understand that I could force the users to use an https URL
instead of an http URL, but that seems like it would be
overkill. If that is the only solution to this issue, then we
would really want the user to authenticate over https, but then
fall back to http for all of the rest of the communications to
the web server so as not to incur the inherent performance
penalty of https. Any hints on how to do that
effectively/efficiently would be welcome in that case.

I also understand that using the Digest method of authentication
(vs. Basic) does not work with LDAP, because, if I understand it
correctly, this method doesn't even send the password, which, of
course, LDAP would need.

Any help in understanding what the best approach is would be
welcome. Thanks for your consideration. I'm hoping that this
is somehow supported. I did not see any kind of bug/enhancement
on this topic in Apache's Bugzilla.

Mark

P.S.

I have the following in my .htaccess file (with certain things
removed):

AuthName "Enter your Corporate Short Login (CSL)"
AuthType Basic
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
AuthLDAPUrl ldaps://...:1793/dc=internal,dc=users,dc=alcatel?uid
AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthLDAPBindDN
uid=admin.quality_records,dc=quality_records,dc=apps,dc=alca tel
AuthLDAPBindPassword ...
Require valid-user

I have the following in my httpd.conf file (I cut out a lot of
what I thought would be extraneous):

# This is the main Apache HTTP server configuration file. It
contains the
# configuration directives that give the server its instructions.
# See for detailed
information.
# In particular, see
#
# for a discussion of each configuration directive.
#
# Do NOT simply read the instructions in here without understanding
# what they do. They're here only as hints or reminders. If
you are unsure
# consult the online docs. You have been warned.
#

# Dynamic Shared Object (DSO) Support
#
# To be able to use the functionality of a module which was
built as a DSO you
# have to place corresponding `LoadModule' lines at this
location so the
# directives contained in it are actually available _before_
they are used.
# Statically compiled modules (those listed by `httpd -l') do
not need
# to be loaded here.
#
# Example:
# LoadModule foo_module modules/mod_foo.so
#
LoadModule authn_file_module modules/mod_authn_file.so
# dal - 2009-02-23 - comment out the dbm cause it no work
#LoadModule authn_dbm_module modules/mod_authn_dbm.so
LoadModule authn_anon_module modules/mod_authn_anon.so
LoadModule authn_dbd_module modules/mod_authn_dbd.so
LoadModule authn_default_module modules/mod_authn_default.so
LoadModule authz_host_module modules/mod_authz_host.so
LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
LoadModule authz_user_module modules/mod_authz_user.so
# dal - 2009-02-23 - comment out the dbm cause it no work
#LoadModule authz_dbm_module modules/mod_authz_dbm.so
LoadModule authz_owner_module modules/mod_authz_owner.so
LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
LoadModule authz_default_module modules/mod_authz_default.so
LoadModule auth_basic_module modules/mod_auth_basic.so
LoadModule auth_digest_module modules/mod_auth_digest.so
LoadModule dbd_module modules/mod_dbd.so
LoadModule dumpio_module modules/mod_dumpio.so
LoadModule ext_filter_module modules/mod_ext_filter.so
LoadModule include_module modules/mod_include.so
LoadModule filter_module modules/mod_filter.so
LoadModule substitute_module modules/mod_substitute.so
LoadModule deflate_module modules/mod_deflate.so
LoadModule ldap_module modules/mod_ldap.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule log_forensic_module modules/mod_log_forensic.so
LoadModule logio_module modules/mod_logio.so
LoadModule env_module modules/mod_env.so
LoadModule mime_magic_module modules/mod_mime_magic.so
LoadModule cern_meta_module modules/mod_cern_meta.so
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
LoadModule ident_module modules/mod_ident.so
LoadModule usertrack_module modules/mod_usertrack.so
LoadModule unique_id_module modules/mod_unique_id.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule version_module modules/mod_version.so
LoadModule ssl_module modules/mod_ssl.so
LoadModule mime_module modules/mod_mime.so
LoadModule dav_module modules/mod_dav.so
LoadModule status_module modules/mod_status.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule asis_module modules/mod_asis.so
LoadModule info_module modules/mod_info.so
LoadModule cgi_module modules/mod_cgi.so
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule negotiation_module modules/mod_negotiation.so
LoadModule dir_module modules/mod_dir.so
LoadModule imagemap_module modules/mod_imagemap.so
LoadModule actions_module modules/mod_actions.so
LoadModule speling_module modules/mod_speling.so
LoadModule userdir_module modules/mod_userdir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule php5_module modules/libphp5.so

# Configuration and logfile names: If the filenames you specify
for many
# of the server's control files begin with "/" (or "drive:/" for
Win32), the
# server will use that explicit path. If the filenames do *not*
begin
# with "/", the value of ServerRoot is prepended -- so
"logs/foo_log"
# with ServerRoot set to "/opt/exp/lib/apache2.2" will be
interpreted by the
# server as "/opt/exp/lib/apache2.2/logs/foo_log".

#
# ServerRoot: The top of the directory tree under which the server's
# configuration, error, and log files are kept.
#
# Do not add a slash at the end of the directory path. If you point
# ServerRoot at a non-local disk, be sure to point the LockFile
directive
# at a local disk. If you wish to share the same ServerRoot for
multiple
# httpd daemons, you will need to change at least LockFile and
PidFile.
#
ServerRoot "..."

# This is the main server configuration file. See URL
http://www.apache.org/
# for instructions.

# Do NOT simply read the instructions in here without understanding
# what they do, if you are unsure consult the online docs. You
have been
# warned.

# Originally by Rob McCool

# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, instead of the default. See also the
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses.

Listen ...:...

# HostnameLookups: Log the names of clients or just their IP numbers
# e.g. www.apache.org (on) or 204.62.129.132 (off)
HostnameLookups off

....cut...

# 'Main' server configuration
#
# The directives in this section set up the values used by the
'main'
# server, which responds to any requests that aren't handled by a
# definition. These values also provide defaults for
# any containers you may define later in the file.
#
# All of these directives may appear inside
containers,
# in which case these default settings will be overridden for the
# virtual host being defined.

# ServerAdmin: Your address, where problems with the server
should be
# e-mailed. This address appears on some server-generated
pages, such
# as error documents. e.g. admin@your-domain.com
#
#ServerAdmin web-master@mobility.ih.lucent.com

# ServerName gives the name and port that the server uses to
identify itself.
# This can often be determined automatically, but we recommend
you specify
# it explicitly to prevent problems during startup.
#
# If your host doesn't have a registered DNS name, enter its IP
address here.

ServerName ...

# DocumentRoot: The directory out of which you will serve your
# documents. By default, all requests are taken from this
directory, but
# symbolic links and aliases may be used to point to other
locations.

DocumentRoot "..."

# UserDir: The name of the directory which is appended onto a
user's home
# directory if a ~user request is received.

UserDir public_html

....cut...

# Secure (SSL/TLS) connections
#Include conf/extra/httpd-ssl.conf
#
# Note: The following must must be present to support
# starting without SSL on platforms with no /dev/random
equivalent
# but a statically compiled-in mod_ssl.


SSLRandomSeed startup builtin
SSLRandomSeed connect builtin


# The following directive disables keepalives and HTTP header
flushes for
# Netscape 2.x and browsers which spoof it. There are known
problems with
# these

BrowserMatch Mozilla/2 nokeepalive

# BindAddress: You can support virtual hosts with this option.
This option
# is used to tell the server which IP address to listen to. It
can either
# contain "*", an IP address, or a fully qualified Internet
domain name.
# See also the VirtualHost directive.

#BindAddress *

# TransferLog: The location of the transfer log file. If this
does not
# start with /, ServerRoot is prepended to it.

TransferLog logs/access_log

# PidFile: The file the server should log its pid to
PidFile logs/httpd.pid

# ScoreBoardFile: File used to store internal server process
information.
# Not all architectures require this. But if yours does (you'll
know because
# this file is created when you run Apache) then you *must*
ensure that
# no two invocations of Apache share the same scoreboard file.
ScoreBoardFile logs/apache_status

# CacheNegotiatedDocs: By default, Apache sends Pragma: no-cache
with each
# document that was negotiated on the basis of content. This
asks proxy
# servers not to cache the document. Uncommenting the following
line disables
# this behavior, and proxies will be allowed to cache the documents.

# CacheNegotiatedDocs

# Timeout: The number of seconds before receives and sends time out

Timeout 1200

# KeepAlive: Whether or not to allow persistent connections
(more than
# one request per connection). Set to "Off" to deactivate.

KeepAlive On

# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited
amount.
# We reccomend you leave this number high, for maximum performance.

MaxKeepAliveRequests 100

# KeepAliveTimeout: Number of seconds to wait for the next request

KeepAliveTimeout 15

# Server-pool size regulation. Rather than making you guess how
many
# server processes you need, Apache dynamically adapts to the
load it
# sees --- that is, it tries to maintain enough server processes to
# handle the current load, plus a few spare servers to handle
transient
# load spikes (e.g., multiple simultaneous requests from a single
# Netscape browser).

# It does this by periodically checking how many servers are waiting
# for a request. If there are fewer than MinSpareServers, it
creates
# a new spare. If there are more than MaxSpareServers, some of the
# spares die off. These values are probably OK for most sites ---

MinSpareServers 5
MaxSpareServers 16

# Number of servers to start --- should be a reasonable ballpark
figure.

StartServers 5

# Limit on total number of servers running, i.e., limit on the
number
# of clients who can simultaneously connect --- if this limit is
ever
# reached, clients will be LOCKED OUT, so it should NOT BE SET
TOO LOW.
# It is intended mainly as a brake to keep a runaway server from
taking
# Unix with it as it spirals down...

MaxClients 254

# MaxRequestsPerChild: the number of requests each child process is
# allowed to process before the child dies.
# The child will exit so as to avoid problems after prolonged
use when
# Apache (and maybe the libraries it uses) leak. On most
systems, this
# isn't really needed, but a few (such as Solaris) do have
notable leaks
# in the libraries.

MaxRequestsPerChild 128

# Proxy Server directives. Uncomment the following line to
# enable the proxy server:

#ProxyRequests On

# To enable the cache as well, edit and uncomment the following
lines:

#CacheRoot /usr/local/etc/httpd/proxy
#CacheSize 5
#CacheGcInterval 4
#CacheMaxExpire 24
#CacheLastModifiedFactor 0.1
#CacheDefaultExpire 1
#NoCache a_domain.com another_domain.edu joes.garage_sale.com

....cut...

# AccessFileName: The name of the file to look for in each directory
# for access control information.

AccessFileName .htaccess

....cut...


Options FollowSymLinks ExecCGI Indexes Includes
AllowOverride None
Order deny,allow
Deny from all



AddType text/html .cgi .pl
AddHandler cgi-script .cgi .pl
AddType application/x-httpd-php .php
Options ExecCGI FollowSymLinks Includes Indexes


....cut...

LDAPSHaredCacheSize 20000
LDAPCacheEntries 1024
LDAPCacheTTL 600
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 600
LDAPTrustedMode SSL
LDAPTrustedGlobalCert CA_BASE64 /info/www/rootCa.pem

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: LDAP authentication with password encryption frombrowser to web server

> I understand that I could force the users to use an https URL instead of =
an
> http URL, but that seems like it would be overkill. =A0If that is the onl=
y
> solution to this issue, then we would really want the user to authenticat=
e
> over https, but then fall back to http for all of the rest of the
> communications to the web server so as not to incur the inherent performa=
nce
> penalty of https. =A0Any hints on how to do that effectively/efficiently =
would
> be welcome in that case.

You can't do this with basic authentication, because your browser only
prompts you once but transmits the password every subsequent protected
page.

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: LDAP authentication with password encryption frombrowser to web server

Eric,
Thanks for this response. Very interesting. I guess that
makes it even more desirous to find a solution to the overall
problem of authenticating via LDAP in a secure manner... Does
anyone have ideas on how to accomplish that?

Mark

On 9/24/2010 4:28 PM, Mark Tischler wrote:
> I have been looking through a lot of documentation on this
> subject, both on apache.org and elsewhere, and I can't seem to
> find an answer to the following question:
>
> Our Apache web server (version 2.2.11 running on Solaris 10)
> is currently authenticating users via LDAP successfully. But,
> we would like to have an *encrypted* password sent from *the
> browser to the Apache web server* when authenticating via
> LDAP. I understand that encryption is performed from the web
> server to the LDAP server by using ldaps, which we are using,
> but we are getting complaints that the password is traveling
> from the users' web browsers to our Apache web server in the
> clear (not encrypted). The problem really requires that the
> web browsers and Apache support an encrypted authentication
> over http instead of counting on wrapping everything via
> https. It would be nice if the public key encryption worked
> between the browser and Apache for the password part.
>
> I understand that I could force the users to use an https URL
> instead of an http URL, but that seems like it would be
> overkill. If that is the only solution to this issue, then we
> would really want the user to authenticate over https, but
> then fall back to http for all of the rest of the
> communications to the web server so as not to incur the
> inherent performance penalty of https. Any hints on how to do
> that effectively/efficiently would be welcome in that case.
>> You can't do this with basic authentication, because your browser only
>> prompts you once but transmits the password every subsequent protected
>> page.
>
>
> I also understand that using the Digest method of
> authentication (vs. Basic) does not work with LDAP, because,
> if I understand it correctly, this method doesn't even send
> the password, which, of course, LDAP would need.
>
> Any help in understanding what the best approach is would be
> welcome. Thanks for your consideration. I'm hoping that this
> is somehow supported. I did not see any kind of
> bug/enhancement on this topic in Apache's Bugzilla.
>
> Mark
>
> P.S.
>
> I have the following in my .htaccess file (with certain things
> removed):
>
> AuthName "Enter your Corporate Short Login (CSL)"
> AuthType Basic
> AuthBasicProvider ldap
> AuthzLDAPAuthoritative off
> AuthLDAPUrl ldaps://...:1793/dc=internal,dc=users,dc=alcatel?uid
> AuthUserFile /dev/null
> AuthGroupFile /dev/null
> AuthLDAPBindDN
> uid=admin.quality_records,dc=quality_records,dc=apps,dc=alca tel
> AuthLDAPBindPassword ...
> Require valid-user
>
> I have the following in my httpd.conf file (I cut out a lot of
> what I thought would be extraneous):
>
> # This is the main Apache HTTP server configuration file. It
> contains the
> # configuration directives that give the server its instructions.
> # See for detailed
> information.
> # In particular, see
> #
> # for a discussion of each configuration directive.
> #
> # Do NOT simply read the instructions in here without
> understanding
> # what they do. They're here only as hints or reminders. If
> you are unsure
> # consult the online docs. You have been warned.
> #
>
> # Dynamic Shared Object (DSO) Support
> #
> # To be able to use the functionality of a module which was
> built as a DSO you
> # have to place corresponding `LoadModule' lines at this
> location so the
> # directives contained in it are actually available _before_
> they are used.
> # Statically compiled modules (those listed by `httpd -l') do
> not need
> # to be loaded here.
> #
> # Example:
> # LoadModule foo_module modules/mod_foo.so
> #
> LoadModule authn_file_module modules/mod_authn_file.so
> # dal - 2009-02-23 - comment out the dbm cause it no work
> #LoadModule authn_dbm_module modules/mod_authn_dbm.so
> LoadModule authn_anon_module modules/mod_authn_anon.so
> LoadModule authn_dbd_module modules/mod_authn_dbd.so
> LoadModule authn_default_module modules/mod_authn_default.so
> LoadModule authz_host_module modules/mod_authz_host.so
> LoadModule authz_groupfile_module modules/mod_authz_groupfile.so
> LoadModule authz_user_module modules/mod_authz_user.so
> # dal - 2009-02-23 - comment out the dbm cause it no work
> #LoadModule authz_dbm_module modules/mod_authz_dbm.so
> LoadModule authz_owner_module modules/mod_authz_owner.so
> LoadModule authnz_ldap_module modules/mod_authnz_ldap.so
> LoadModule authz_default_module modules/mod_authz_default.so
> LoadModule auth_basic_module modules/mod_auth_basic.so
> LoadModule auth_digest_module modules/mod_auth_digest.so
> LoadModule dbd_module modules/mod_dbd.so
> LoadModule dumpio_module modules/mod_dumpio.so
> LoadModule ext_filter_module modules/mod_ext_filter.so
> LoadModule include_module modules/mod_include.so
> LoadModule filter_module modules/mod_filter.so
> LoadModule substitute_module modules/mod_substitute.so
> LoadModule deflate_module modules/mod_deflate.so
> LoadModule ldap_module modules/mod_ldap.so
> LoadModule log_config_module modules/mod_log_config.so
> LoadModule log_forensic_module modules/mod_log_forensic.so
> LoadModule logio_module modules/mod_logio.so
> LoadModule env_module modules/mod_env.so
> LoadModule mime_magic_module modules/mod_mime_magic.so
> LoadModule cern_meta_module modules/mod_cern_meta.so
> LoadModule expires_module modules/mod_expires.so
> LoadModule headers_module modules/mod_headers.so
> LoadModule ident_module modules/mod_ident.so
> LoadModule usertrack_module modules/mod_usertrack.so
> LoadModule unique_id_module modules/mod_unique_id.so
> LoadModule setenvif_module modules/mod_setenvif.so
> LoadModule version_module modules/mod_version.so
> LoadModule ssl_module modules/mod_ssl.so
> LoadModule mime_module modules/mod_mime.so
> LoadModule dav_module modules/mod_dav.so
> LoadModule status_module modules/mod_status.so
> LoadModule autoindex_module modules/mod_autoindex.so
> LoadModule asis_module modules/mod_asis.so
> LoadModule info_module modules/mod_info.so
> LoadModule cgi_module modules/mod_cgi.so
> LoadModule dav_fs_module modules/mod_dav_fs.so
> LoadModule vhost_alias_module modules/mod_vhost_alias.so
> LoadModule negotiation_module modules/mod_negotiation.so
> LoadModule dir_module modules/mod_dir.so
> LoadModule imagemap_module modules/mod_imagemap.so
> LoadModule actions_module modules/mod_actions.so
> LoadModule speling_module modules/mod_speling.so
> LoadModule userdir_module modules/mod_userdir.so
> LoadModule alias_module modules/mod_alias.so
> LoadModule rewrite_module modules/mod_rewrite.so
> LoadModule php5_module modules/libphp5.so
>
> # Configuration and logfile names: If the filenames you
> specify for many
> # of the server's control files begin with "/" (or "drive:/"
> for Win32), the
> # server will use that explicit path. If the filenames do
> *not* begin
> # with "/", the value of ServerRoot is prepended -- so
> "logs/foo_log"
> # with ServerRoot set to "/opt/exp/lib/apache2.2" will be
> interpreted by the
> # server as "/opt/exp/lib/apache2.2/logs/foo_log".
>
> #
> # ServerRoot: The top of the directory tree under which the
> server's
> # configuration, error, and log files are kept.
> #
> # Do not add a slash at the end of the directory path. If you
> point
> # ServerRoot at a non-local disk, be sure to point the
> LockFile directive
> # at a local disk. If you wish to share the same ServerRoot
> for multiple
> # httpd daemons, you will need to change at least LockFile and
> PidFile.
> #
> ServerRoot "..."
>
> # This is the main server configuration file. See URL
> http://www.apache.org/
> # for instructions.
>
> # Do NOT simply read the instructions in here without
> understanding
> # what they do, if you are unsure consult the online docs. You
> have been
> # warned.
>
> # Originally by Rob McCool
>
> # Listen: Allows you to bind Apache to specific IP addresses
> and/or
> # ports, instead of the default. See also the
> # directive.
> #
> # Change this to Listen on specific IP addresses as shown
> below to
> # prevent Apache from glomming onto all bound IP addresses.
>
> Listen ...:...
>
> # HostnameLookups: Log the names of clients or just their IP
> numbers
> # e.g. www.apache.org (on) or 204.62.129.132 (off)
> HostnameLookups off
>
> ...cut...
>
> # 'Main' server configuration
> #
> # The directives in this section set up the values used by the
> 'main'
> # server, which responds to any requests that aren't handled by a
> # definition. These values also provide
> defaults for
> # any containers you may define later in the file.
> #
> # All of these directives may appear inside
> containers,
> # in which case these default settings will be overridden for the
> # virtual host being defined.
>
> # ServerAdmin: Your address, where problems with the server
> should be
> # e-mailed. This address appears on some server-generated
> pages, such
> # as error documents. e.g. admin@your-domain.com
> #
> #ServerAdmin web-master@mobility.ih.lucent.com
>
> # ServerName gives the name and port that the server uses to
> identify itself.
> # This can often be determined automatically, but we recommend
> you specify
> # it explicitly to prevent problems during startup.
> #
> # If your host doesn't have a registered DNS name, enter its
> IP address here.
>
> ServerName ...
>
> # DocumentRoot: The directory out of which you will serve your
> # documents. By default, all requests are taken from this
> directory, but
> # symbolic links and aliases may be used to point to other
> locations.
>
> DocumentRoot "..."
>
> # UserDir: The name of the directory which is appended onto a
> user's home
> # directory if a ~user request is received.
>
> UserDir public_html
>
> ...cut...
>
> # Secure (SSL/TLS) connections
> #Include conf/extra/httpd-ssl.conf
> #
> # Note: The following must must be present to support
> # starting without SSL on platforms with no /dev/random
> equivalent
> # but a statically compiled-in mod_ssl.
>
>
> SSLRandomSeed startup builtin
> SSLRandomSeed connect builtin
>
>
> # The following directive disables keepalives and HTTP header
> flushes for
> # Netscape 2.x and browsers which spoof it. There are known
> problems with
> # these
>
> BrowserMatch Mozilla/2 nokeepalive
>
> # BindAddress: You can support virtual hosts with this option.
> This option
> # is used to tell the server which IP address to listen to. It
> can either
> # contain "*", an IP address, or a fully qualified Internet
> domain name.
> # See also the VirtualHost directive.
>
> #BindAddress *
>
> # TransferLog: The location of the transfer log file. If this
> does not
> # start with /, ServerRoot is prepended to it.
>
> TransferLog logs/access_log
>
> # PidFile: The file the server should log its pid to
> PidFile logs/httpd.pid
>
> # ScoreBoardFile: File used to store internal server process
> information.
> # Not all architectures require this. But if yours does
> (you'll know because
> # this file is created when you run Apache) then you *must*
> ensure that
> # no two invocations of Apache share the same scoreboard file.
> ScoreBoardFile logs/apache_status
>
> # CacheNegotiatedDocs: By default, Apache sends Pragma:
> no-cache with each
> # document that was negotiated on the basis of content. This
> asks proxy
> # servers not to cache the document. Uncommenting the
> following line disables
> # this behavior, and proxies will be allowed to cache the
> documents.
>
> # CacheNegotiatedDocs
>
> # Timeout: The number of seconds before receives and sends
> time out
>
> Timeout 1200
>
> # KeepAlive: Whether or not to allow persistent connections
> (more than
> # one request per connection). Set to "Off" to deactivate.
>
> KeepAlive On
>
> # MaxKeepAliveRequests: The maximum number of requests to allow
> # during a persistent connection. Set to 0 to allow an
> unlimited amount.
> # We reccomend you leave this number high, for maximum
> performance.
>
> MaxKeepAliveRequests 100
>
> # KeepAliveTimeout: Number of seconds to wait for the next
> request
>
> KeepAliveTimeout 15
>
> # Server-pool size regulation. Rather than making you guess
> how many
> # server processes you need, Apache dynamically adapts to the
> load it
> # sees --- that is, it tries to maintain enough server
> processes to
> # handle the current load, plus a few spare servers to handle
> transient
> # load spikes (e.g., multiple simultaneous requests from a single
> # Netscape browser).
>
> # It does this by periodically checking how many servers are
> waiting
> # for a request. If there are fewer than MinSpareServers, it
> creates
> # a new spare. If there are more than MaxSpareServers, some
> of the
> # spares die off. These values are probably OK for most sites
> ---
>
> MinSpareServers 5
> MaxSpareServers 16
>
> # Number of servers to start --- should be a reasonable
> ballpark figure.
>
> StartServers 5
>
> # Limit on total number of servers running, i.e., limit on the
> number
> # of clients who can simultaneously connect --- if this limit
> is ever
> # reached, clients will be LOCKED OUT, so it should NOT BE SET
> TOO LOW.
> # It is intended mainly as a brake to keep a runaway server
> from taking
> # Unix with it as it spirals down...
>
> MaxClients 254
>
> # MaxRequestsPerChild: the number of requests each child
> process is
> # allowed to process before the child dies.
> # The child will exit so as to avoid problems after prolonged
> use when
> # Apache (and maybe the libraries it uses) leak. On most
> systems, this
> # isn't really needed, but a few (such as Solaris) do have
> notable leaks
> # in the libraries.
>
> MaxRequestsPerChild 128
>
> # Proxy Server directives. Uncomment the following line to
> # enable the proxy server:
>
> #ProxyRequests On
>
> # To enable the cache as well, edit and uncomment the
> following lines:
>
> #CacheRoot /usr/local/etc/httpd/proxy
> #CacheSize 5
> #CacheGcInterval 4
> #CacheMaxExpire 24
> #CacheLastModifiedFactor 0.1
> #CacheDefaultExpire 1
> #NoCache a_domain.com another_domain.edu joes.garage_sale.com
>
> ...cut...
>
> # AccessFileName: The name of the file to look for in each
> directory
> # for access control information.
>
> AccessFileName .htaccess
>
> ...cut...
>
>
> Options FollowSymLinks ExecCGI Indexes Includes
> AllowOverride None
> Order deny,allow
> Deny from all
>
>
>
> AddType text/html .cgi .pl
> AddHandler cgi-script .cgi .pl
> AddType application/x-httpd-php .php
> Options ExecCGI FollowSymLinks Includes Indexes
>
>
> ...cut...
>
> LDAPSHaredCacheSize 20000
> LDAPCacheEntries 1024
> LDAPCacheTTL 600
> LDAPOpCacheEntries 1024
> LDAPOpCacheTTL 600
> LDAPTrustedMode SSL
> LDAPTrustedGlobalCert CA_BASE64 /info/www/rootCa.pem
>
> ------------------------------------------------------------ ---------
>
> The official User-To-User support forum of the Apache HTTP
> Server Project.
> See for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: LDAP authentication with password encryption frombrowser to web server

On Tue, Sep 28, 2010 at 2:17 PM, Mark Tischler
wrote:
> =A0Eric,
> =A0 =A0Thanks for this response. =A0Very interesting. =A0I guess that mak=
es it even
> more desirous to find a solution to the overall problem of authenticating
> via LDAP in a secure manner... =A0Does anyone have ideas on how to accomp=
lish
> that?
>

Wrap it in SSL on both ends?

--=20
Eric Covener
covener@gmail.com

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: LDAP authentication with password encryption frombrowser to web server

Eric,
As I mentioned in the original posting, I was hoping to
avoid using SSL due to the performance hit that we would take
with it. If there is a solution out there (changes to
httpd.conf or .htaccess files) that would allow me to pass the
encrypted password from the browser to the web server (which
would then pass it along to LDAP), that would be perfect. As I
understand it, if one uses basic authentication with a .htpasswd
file, then the passwords *are* encrypted from the browser to the
web server (please tell me if I'm not understanding this
correctly). The real question then is: is there something
comparable with LDAP authentication? If not, I wonder if there
is anything in the works to do that? That is, I did not see an
enhancement request in the list for Apache developers, so I'm
wondering if one needs to be created if nothing does yet exist
to do what I want.

Mark

On 9/28/2010 2:16 PM, Eric Covener wrote:
> On Tue, Sep 28, 2010 at 2:17 PM, Mark Tischler
> wrote:
>> Eric,
>> Thanks for this response. Very interesting. I guess that makes it even
>> more desirous to find a solution to the overall problem of authenticating
>> via LDAP in a secure manner... Does anyone have ideas on how to accomplish
>> that?
>>
> Wrap it in SSL on both ends?
>

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: LDAP authentication with password encryption frombrowser to web server

On 9/24/2010 4:28 PM, Mark Tischler wrote:
> I have been looking through a lot of documentation on this subject, both on apache.org
> and elsewhere, and I can't seem to find an answer to the following question:
>
> Our Apache web server (version 2.2.11 running on Solaris 10) is currently authenticating
> users via LDAP successfully. But, we would like to have an *encrypted* password sent from
> *the browser to the Apache web server* when authenticating via LDAP. I understand that
> encryption is performed from the web server to the LDAP server by using ldaps, which we
> are using, but we are getting complaints that the password is traveling from the users'
> web browsers to our Apache web server in the clear (not encrypted). The problem really
> requires that the web browsers and Apache support an encrypted authentication over http
> instead of counting on wrapping everything via https. It would be nice if the public key
> encryption worked between the browser and Apache for the password part.
>
> I understand that I could force the users to use an https URL instead of an http URL, but
> that seems like it would be overkill. If that is the only solution to this issue, then we
> would really want the user to authenticate over https, but then fall back to http for all
> of the rest of the communications to the web server so as not to incur the inherent
> performance penalty of https. Any hints on how to do that effectively/efficiently would
> be welcome in that case.
>
> I also understand that using the Digest method of authentication (vs. Basic) does not work
> with LDAP, because, if I understand it correctly, this method doesn't even send the
> password, which, of course, LDAP would need.

The only way to secure Basic auth is with SSL. Basic is simply encoded in 64 bit space
to make it safe for 7-bit transport. What you want is Digest auth, which then ties the
digest key to the hashed user/pass/domain and secures the token from being snarfed for
requests from yet a third IP address.

I don't know of any simple mechanism to store digest credentials in ldap (see htdigest
and the mod_auth_digest module for further details).


------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: LDAP authentication with password encryption frombrowser to web server

William,

Thanks. There is no way to make Digest authentication work with
LDAP from what I have found/read. But it seems to me that
someone must have already run up against this sometime before
now. Is my understanding correct that one can use Digest
authentication to encrypt the password between the browser and
the web server? If so, it seems like there ought to be a
corresponding solution (to get that same encryption capability)
with LDAP. From the answers I've been getting, I'm beginning to
think that it might be time to submit an enhancement request to
the Apache developers. I'll wait a bit longer to see if anyone
else knows of a way to accomplish this with existing
capabilities (besides SSL, which is, as I said, my backup plan).

Mark

On 9/28/2010 3:52 PM, William A. Rowe Jr. wrote:
> On 9/24/2010 4:28 PM, Mark Tischler wrote:
>> I have been looking through a lot of documentation on this subject, both on apache.org
>> and elsewhere, and I can't seem to find an answer to the following question:
>>
>> Our Apache web server (version 2.2.11 running on Solaris 10) is currently authenticating
>> users via LDAP successfully. But, we would like to have an *encrypted* password sent from
>> *the browser to the Apache web server* when authenticating via LDAP. I understand that
>> encryption is performed from the web server to the LDAP server by using ldaps, which we
>> are using, but we are getting complaints that the password is traveling from the users'
>> web browsers to our Apache web server in the clear (not encrypted). The problem really
>> requires that the web browsers and Apache support an encrypted authentication over http
>> instead of counting on wrapping everything via https. It would be nice if the public key
>> encryption worked between the browser and Apache for the password part.
>>
>> I understand that I could force the users to use an https URL instead of an http URL, but
>> that seems like it would be overkill. If that is the only solution to this issue, then we
>> would really want the user to authenticate over https, but then fall back to http for all
>> of the rest of the communications to the web server so as not to incur the inherent
>> performance penalty of https. Any hints on how to do that effectively/efficiently would
>> be welcome in that case.
>>
>> I also understand that using the Digest method of authentication (vs. Basic) does not work
>> with LDAP, because, if I understand it correctly, this method doesn't even send the
>> password, which, of course, LDAP would need.
> The only way to secure Basic auth is with SSL. Basic is simply encoded in 64 bit space
> to make it safe for 7-bit transport. What you want is Digest auth, which then ties the
> digest key to the hashed user/pass/domain and secures the token from being snarfed for
> requests from yet a third IP address.
>
> I don't know of any simple mechanism to store digest credentials in ldap (see htdigest
> and the mod_auth_digest module for further details).
>
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server Project.
> See for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: LDAP authentication with password encryption frombrowser to web server

Digest does more then just encrypting the password.

http://en.wikipedia.org/wiki/Digest_access_authentication

and if you have a look at that RFC http://www.ietf.org/rfc/rfc2829.txt
LDAP it self possibly supports already digest-md5.

so really the LDAP auth should support the digest auth by maybe just
forwarding the digest-md5 to ldap?


http://www.latenightpc.com/blog/archives/2007/08/31/no-autht ype-digest-with-ldap-authentication-provider-for-apache-toda y
seems to be a very known topic :)

Am 28.09.2010 23:04, schrieb Mark Tischler:
> William,
>
> Thanks. There is no way to make Digest authentication work with LDAP
> from what I have found/read. But it seems to me that someone must
> have already run up against this sometime before now. Is my
> understanding correct that one can use Digest authentication to
> encrypt the password between the browser and the web server? If so,
> it seems like there ought to be a corresponding solution (to get that
> same encryption capability) with LDAP. From the answers I've been
> getting, I'm beginning to think that it might be time to submit an
> enhancement request to the Apache developers. I'll wait a bit longer
> to see if anyone else knows of a way to accomplish this with existing
> capabilities (besides SSL, which is, as I said, my backup plan).
>
> Mark
>
> On 9/28/2010 3:52 PM, William A. Rowe Jr. wrote:
>> On 9/24/2010 4:28 PM, Mark Tischler wrote:
>>> I have been looking through a lot of documentation on this
>>> subject, both on apache.org
>>> and elsewhere, and I can't seem to find an answer to the following
>>> question:
>>>
>>> Our Apache web server (version 2.2.11 running on Solaris 10) is
>>> currently authenticating
>>> users via LDAP successfully. But, we would like to have an
>>> *encrypted* password sent from
>>> *the browser to the Apache web server* when authenticating via
>>> LDAP. I understand that
>>> encryption is performed from the web server to the LDAP server by
>>> using ldaps, which we
>>> are using, but we are getting complaints that the password is
>>> traveling from the users'
>>> web browsers to our Apache web server in the clear (not encrypted).
>>> The problem really
>>> requires that the web browsers and Apache support an encrypted
>>> authentication over http
>>> instead of counting on wrapping everything via https. It would be
>>> nice if the public key
>>> encryption worked between the browser and Apache for the password part.
>>>
>>> I understand that I could force the users to use an https URL
>>> instead of an http URL, but
>>> that seems like it would be overkill. If that is the only solution
>>> to this issue, then we
>>> would really want the user to authenticate over https, but then fall
>>> back to http for all
>>> of the rest of the communications to the web server so as not to
>>> incur the inherent
>>> performance penalty of https. Any hints on how to do that
>>> effectively/efficiently would
>>> be welcome in that case.
>>>
>>> I also understand that using the Digest method of authentication
>>> (vs. Basic) does not work
>>> with LDAP, because, if I understand it correctly, this method
>>> doesn't even send the
>>> password, which, of course, LDAP would need.
>> The only way to secure Basic auth is with SSL. Basic is simply
>> encoded in 64 bit space
>> to make it safe for 7-bit transport. What you want is Digest auth,
>> which then ties the
>> digest key to the hashed user/pass/domain and secures the token from
>> being snarfed for
>> requests from yet a third IP address.
>>
>> I don't know of any simple mechanism to store digest credentials in
>> ldap (see htdigest
>> and the mod_auth_digest module for further details).
>>
>>
>> ------------------------------------------------------------ ---------
>> The official User-To-User support forum of the Apache HTTP Server
>> Project.
>> See for more info.
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> " from the digest: users-digest-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>
> ------------------------------------------------------------ ---------
> The official User-To-User support forum of the Apache HTTP Server
> Project.
> See for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>


------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org

Re: LDAP authentication with password encryption frombrowser to web server

Thanks. I found the provided links very helpful. I decided
to file an enhancement request in ASF Bugzilla, given that this
has been complained about for at least 3 years.

Also, thanks to Igor for suggesting Kerberos. I will look into
that.

Mark

On 9/28/2010 6:09 PM, [triplepack] info (info@pack3.ch) wrote:
> Digest does more then just encrypting the password.
>
> http://en.wikipedia.org/wiki/Digest_access_authentication
>
> and if you have a look at that RFC
> http://www.ietf.org/rfc/rfc2829.txt LDAP it self possibly
> supports already digest-md5.
>
> so really the LDAP auth should support the digest auth by
> maybe just forwarding the digest-md5 to ldap?
>
>
> http://www.latenightpc.com/blog/archives/2007/08/31/no-autht ype-digest-with-ldap-authentication-provider-for-apache-toda y
> seems to be a very known topic :)
>
> Am 28.09.2010 23:04, schrieb Mark Tischler:
>> William,
>>
>> Thanks. There is no way to make Digest authentication work
>> with LDAP from what I have found/read. But it seems to me
>> that someone must have already run up against this sometime
>> before now. Is my understanding correct that one can use
>> Digest authentication to encrypt the password between the
>> browser and the web server? If so, it seems like there ought
>> to be a corresponding solution (to get that same encryption
>> capability) with LDAP. From the answers I've been getting,
>> I'm beginning to think that it might be time to submit an
>> enhancement request to the Apache developers. I'll wait a
>> bit longer to see if anyone else knows of a way to accomplish
>> this with existing capabilities (besides SSL, which is, as I
>> said, my backup plan).
>>
>> Mark
>>
>> On 9/28/2010 3:52 PM, William A. Rowe Jr. wrote:
>>> On 9/24/2010 4:28 PM, Mark Tischler wrote:
>>>> I have been looking through a lot of documentation on
>>>> this subject, both on apache.org
>>>> and elsewhere, and I can't seem to find an answer to the
>>>> following question:
>>>>
>>>> Our Apache web server (version 2.2.11 running on Solaris
>>>> 10) is currently authenticating
>>>> users via LDAP successfully. But, we would like to have an
>>>> *encrypted* password sent from
>>>> *the browser to the Apache web server* when authenticating
>>>> via LDAP. I understand that
>>>> encryption is performed from the web server to the LDAP
>>>> server by using ldaps, which we
>>>> are using, but we are getting complaints that the password
>>>> is traveling from the users'
>>>> web browsers to our Apache web server in the clear (not
>>>> encrypted). The problem really
>>>> requires that the web browsers and Apache support an
>>>> encrypted authentication over http
>>>> instead of counting on wrapping everything via https. It
>>>> would be nice if the public key
>>>> encryption worked between the browser and Apache for the
>>>> password part.
>>>>
>>>> I understand that I could force the users to use an https
>>>> URL instead of an http URL, but
>>>> that seems like it would be overkill. If that is the only
>>>> solution to this issue, then we
>>>> would really want the user to authenticate over https, but
>>>> then fall back to http for all
>>>> of the rest of the communications to the web server so as
>>>> not to incur the inherent
>>>> performance penalty of https. Any hints on how to do that
>>>> effectively/efficiently would
>>>> be welcome in that case.
>>>>
>>>> I also understand that using the Digest method of
>>>> authentication (vs. Basic) does not work
>>>> with LDAP, because, if I understand it correctly, this
>>>> method doesn't even send the
>>>> password, which, of course, LDAP would need.
>>> The only way to secure Basic auth is with SSL. Basic is
>>> simply encoded in 64 bit space
>>> to make it safe for 7-bit transport. What you want is
>>> Digest auth, which then ties the
>>> digest key to the hashed user/pass/domain and secures the
>>> token from being snarfed for
>>> requests from yet a third IP address.
>>>
>>> I don't know of any simple mechanism to store digest
>>> credentials in ldap (see htdigest
>>> and the mod_auth_digest module for further details).
>>>
>>>
>>> ------------------------------------------------------------ ---------
>>>
>>> The official User-To-User support forum of the Apache HTTP
>>> Server Project.
>>> See for more info.
>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>> " from the digest:
>>> users-digest-unsubscribe@httpd.apache.org
>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>
>>
>> ------------------------------------------------------------ ---------
>>
>> The official User-To-User support forum of the Apache HTTP
>> Server Project.
>> See for more info.
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> " from the digest: users-digest-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>
>
>
> ------------------------------------------------------------ ---------
>
> The official User-To-User support forum of the Apache HTTP
> Server Project.
> See for more info.
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> " from the digest: users-digest-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>

------------------------------------------------------------ ---------
The official User-To-User support forum of the Apache HTTP Server Project.
See for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
" from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org