httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier (tomcat/perl)>
Subject [users@httpd] mod_authnz_ldap, invalid user, server error 500
Date Fri, 18 Sep 2020 14:52:41 GMT

Version info :
[Sun Sep 13 06:25:05.107620 2020] [mpm_prefork:notice] [pid 4125] AH00163: Apache/2.4.25 
(Debian) OpenSSL/1.0.2u mod_apreq2-20090110/2.8.0 mod_perl/2.0.10 Perl/v5.24.1 configured

-- resuming normal operations

Background :
We have developed our own AAA "authorization" scheme, based on mod_perl.
This scheme is such that for the authentication part, it can use any available "standard"

Apache module/scheme (such as ldap (mod_authnz_ldap), Shibboleth (mod_shib2), Basic auth 
(mod_auth_core), etc.. (including some which we developed ourselves)), and the 
Authorization phase will "delegate" the authentication to whatever authentication method 
is configured, and subsequently "collect" the authentication information in order to 
authorize or not access, and provide the subsequent applications with a user profile in a

standard format.

(Thus, in this case, we intend to use mod_authnz_ldap as the authentication method, but 
use our own module as the authorization code.)

Our issue :
When mod_authnz_ldap is used to authenticate the user (via the HTTP Basic browser dialog),

the following happens :

a) if the user-entered userid / pw are correct, everything happens as expected (our 
authorization module gets called subsequently, and the user ultimately gets access to the

desired resource)
b) if the user-entered userid is valid, but the entered password is not, the server 
(presumably mod_authnz_ldap) returns a 401 response. (This happens without our 
authorization module being called).
As a consequence, the user gets a new HTTP Basic login dialog, in which he can re-enter a

valid combination; and if he does, everything happens as expected, as per the first case 
c) but if the user-entered *userid* is invalid (iow it does not exist in the LDAP 
directory), then the server returns a server error 500 status immediately, without calling

our authorization module. Subsequent page reloads in the browser always return the same 
server error 500.

(c) is a problem, because from the user perspective, it is really unclear why the 
authentication failed, and in addition, the only way in which they can retry is by closing

the browser, re-opening it, and retry to access the same URL (this is because apparently,

although the authentication failed, the browser nevertheless caches the wrong Basic 
credentials, and re-submits the same at any subsequent attempt to reload the same resource).
It is also a problem for us, because there sems to be no way in which we can "intervene" 
in case (c) : our authorization method is not even called; upon return from the 
mod_authnz_ldap authenticate function, httpd just goes straight to sending back a server 
error page (and with a strange error in the log, see below).

In the Apache error log, this is what case (c) looks like :
(UMA2 is our self-developed "authorization provider", and I have numbered the log lines 
for further reference).

1) [Fri Sep 18 10:50:42.349048 2020] [perl:info] [pid 12610] [client]

<--UMA2[12610]authz_user.PASS1: (no user, will now call configured authentication method(s))
2) [Fri Sep 18 10:50:42.349085 2020] [authz_core:debug] [pid 12610] mod_authz_core.c(809):

[client] AH01626: authorization result of Require UMA-user valid-user:

denied (no authenticated user yet)
3) [Fri Sep 18 10:50:42.349098 2020] [authz_core:debug] [pid 12610] mod_authz_core.c(809):

[client] AH01626: authorization result of <RequireAny>: denied (no

authenticated user yet)
4) [Fri Sep 18 10:50:42.349142 2020] [authnz_ldap:debug] [pid 12610] 
mod_authnz_ldap.c(520): [client] AH01691: auth_ldap authenticate: 
using URL ldap://(redacted, but works fine in other cases)
[Fri Sep 18 10:50:42.349163 2020] [authnz_ldap:trace1] [pid 12610] mod_authnz_ldap.c(541):

[client] auth_ldap authenticate: final authn filter is 
5) [Fri Sep 18 10:50:42.367039 2020] [authnz_ldap:info] [pid 12610] [client] AH01695: auth_ldap authenticate: user (redacted) authentication 
failed; URI /auth-test/ELVISb/test-auth.html [User not found][No such object]
6) [Fri Sep 18 10:50:42.367075 2020] [authn_core:error] [pid 12610] [client] AH01796: AuthType basic configured without corresponding module

(the last line is where httpd returns the server error 500 page to the browser)

At (1), our authorization method (which is called first because of a "Require") returns 
AUTHZ_DENIED_NO_USER to httpd. This triggers the call to the configured authentication 
method. Lines (2)-(6) do not involve our authorization code at all anymore.

It seems that the last error log message (6) is somewhat nonsensical, because :
1) the (somewhat edited/simplified) configuration is as follows :

     PerlAddAuthzProvider UMA-user AUTH::UMA2->authz_user

<LocationMatch "/ELVISb/.*$">
	# for AAA : LDAP login
	AuthType basic
	AuthBasicProvider ldap
	AuthBasicAuthoritative Off
	AuthLDAPBindDN "cn=(redacted),cn=memberserver,cn=computers,o=(redacted),c=de"
	AuthLDAPBindPassword "(redacted)"
	AuthLDAPBindAuthoritative off

# and here either :
		# Require valid-user triggers the LDAP/Basic auth
		Require valid-user
		# Require UMA-user valid-user triggers the UMA2->authz_user sub.,
		# then also Basic/LDAP authentication (if no cookie yet)
		Require UMA-user valid-user

# or simply :
	Require UMA-user valid-user

#(same behaviour on both cases)


(so the "corresponding module" is configured as "ldap")

and 2) httpd already called this ldap provider during the first pass, since it is the one

which returned the 401 response triggering the browser's authentication dialog

Note also that this configuration works perfectly in the above-mentioned cases (a) and (b).

Digging a bit further yelded these links which may be of interest :

But I am unable to say if the behaviour we are seeing is expected, or if we are making a 
mistake in our configuration.

Can anyone help ?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message