Bug 55622 - AuthnProviderAlias does not work w/ authnz_ldap in 2.4.6
Summary: AuthnProviderAlias does not work w/ authnz_ldap in 2.4.6
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_authn_alias (show other bugs)
Version: 2.4.7
Hardware: Other All
: P2 major with 8 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: FixedInTrunk
: 56203 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-10-02 20:10 UTC by Tony Guadagno
Modified: 2014-10-13 00:36 UTC (History)
4 users (show)



Attachments
virtual host debug log (16.52 KB, text/plain)
2013-10-02 20:10 UTC, Tony Guadagno
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tony Guadagno 2013-10-02 20:10:14 UTC
Created attachment 30901 [details]
virtual host debug log

hi, i was using AuthnProviderAlias in 2.2.24 without issue, when i moved up to 2.4.6, the config would not work.

Config

LDAPVerifyServerCert off
LDAPTrustedMode SSL
<AuthnProviderAlias ldap ldapUEDC1>
	AuthLDAPURL "ldaps://uedc1.company.com/DC=company,DC=com?sAMAccountName?sub?(objectClass=*)" SSL
	AuthLDAPBindDN "CN=ldap Lookup,OU=Service Accounts,OU=Ultra Users,DC=company,DC=com"
	AuthLDAPBindPassword pw
</AuthnProviderAlias>

<AuthnProviderAlias ldap ldapUEDC2>
	AuthLDAPURL "ldaps://uedc2.company.com/DC=company,DC=com?sAMAccountName?sub?(objectClass=*)" SSL
	AuthLDAPBindDN "CN=ldap Lookup,OU=Service Accounts,OU=Ultra Users,DC=company,DC=com"
	AuthLDAPBindPassword pw
</AuthnProviderAlias>


<VirtualHost 172.30.0.10:443>
	ServerAdmin ueadmin@company.com
	DocumentRoot "d:\websites\svn"
	ServerName FLSoftware.company.com

	CookieTracking On
	CookieDomain .FLSoftware.company.com
	CookieExpires "10 years"
	CookieName FLSoftwareSession
	CookieStyle Cookie

	ErrorLog d:/logs/apache/FLSoftware-Error.log
	CustomLog d:/logs/weblogs/FLSoftware/FLSoftware-Apache-%Y-%m-%d.log combined
	DirectoryIndex index.txt
	LDAPTrustedMode SSL
	<Location /svn>
		AuthBasicProvider ldapUEDC1 ldapUEDC2
		Authtype Basic
		AuthzLDAPAuthoritative on
		Authname "SubVersion"
		Require valid-user

		SetOutputFilter DEFLATE

		DAV svn
		SVNParentPath d:/SVNRepo
		SVNPathAuthz on
		SVNIndexXSLT "/svnindex.xml"
		AuthzSVNAccessFile d:/SvnRepo/svn_dir_access.conf

	</Location>
	<Directory "d:/websites/svn">
		DavGenericLockDB "D:/SVNRepo/ApacheLocks"
		AllowOverride None
		Order allow,deny
		Allow from all
	</Directory>
SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLProtocol all -SSLv2
SSLCipherSuite HIGH:MEDIUM:!ADH:!RC4
<FilesMatch "\.(cgi|shtml|phtml|php)$">
    SSLOptions +StdEnvVars
</FilesMatch>
BrowserMatch ".*MSIE.*" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

</VirtualHost>



error when on 2.4.6
[Wed Oct 02 14:54:25.160786 2013] [auth_basic:error] [pid 3288:tid 956] [client 172.30.2.149:9950] AH01618: user tonyg not found: /svn/Auracle


see full debug log attached
Comment 1 Jarle Jacobsen 2013-11-14 13:11:11 UTC
Using this feature in our Subversion Edge installation. I'm about to upgrade to the latest version, but are not able because of this bug
Comment 2 Geir Engebakken 2013-11-23 17:27:28 UTC
The same applies to us, we need to setup several LDAP hosts to authenticate, and we cannot upgrade to latest SVN Edge due to this bug.
Comment 3 Eric Covener 2013-11-23 18:19:52 UTC
out of curiosity, does it help if you remove "AuthZLDAPAuthoritative" which is probably unnecessary now anyway?  I think there is a quirk that will make it cause harm (actually any directive from mod_authnz_ldap in the same context as the provider is used).

If you can confirm, I can try to fix it, although AuthZLDAPAuthoritative is not really needed there are other directives that cna get in the way.
Comment 4 Geir Engebakken 2013-11-25 09:11:19 UTC
We dont use AuthZLDAPAuthoritative in our config, and it doesnt work for us either.
Comment 5 Eric Covener 2013-11-25 12:59:11 UTC
Thanks Geir, no other mod_authnz_ldap directives inside the block that has AuthBasicProvider?
Comment 6 Jarle Jacobsen 2013-11-26 09:47:55 UTC
I got it working in my Subversion Edge installation. I copied the svn_viewvc_httpd.conf file and modified the httpd.conf file to use my version instead. In the copied version I added the following before the <Location /> element:

<AuthnProviderAlias file csvn-file-users>
  AuthUserFile "C:\csvn\data/conf/svn_auth_file"
</AuthnProviderAlias>

<AuthnProviderAlias ldap ldap-users>
  AuthLDAPUrl "ldaps://DomainDnsZones.eu.mycompany.com/DC=eu,DC=mycompany,DC=com?sAMAccountName?sub?(&(objectCategory=user)(|(memberOf=CN=CMS Users Local,OU=Security Groups,OU=Groups,OU=Norway,OU=TEAD,DC=eu,DC=mycompany,DC=com)(memberOf=CN=CMS Users Global,OU=Security Groups,OU=Groups,OU=Norway,OU=TEAD,DC=eu,DC=mycompany,DC=com)))" "SSL"

  AuthLDAPBindDN "CN=someUser,OU=System Accounts,OU=Norway,OU=TEAD,DC=eu,DC=mycompany,DC=com"
  AuthLDAPBindPassword "MyPassword"

</AuthnProviderAlias>

<AuthnProviderAlias ldap ldap-users-india>
  AuthLDAPUrl "ldaps://apdc02.ap.mycompany.com/DC=ap,DC=mycompany,DC=com?sAMAccountName?sub?(&(objectCategory=user)(memberOf=CN=SG IZZ IFZ CMS Users Global,OU=Security Groups,OU=Groups,OU=India,OU=TEAD,DC=ap,DC=mycompany,DC=com))" "SSL"

  AuthLDAPBindDN "CN=someUser,OU=System Accounts,OU=Norway,OU=TEAD,DC=eu,DC=mycompany,DC=com"
  AuthLDAPBindPassword "MyPassword"

</AuthnProviderAlias>



The Location element for root is modified to look like this:

# Apache will issue sub_req for PATH_INFO on ScriptAlias which
# gives a spurious error message. Setting auth at root level to avoid clogging logs.
<Location />
  AuthType Basic
  AuthName "CollabNet Subversion Repository"
  AuthBasicProvider csvn-file-users ldap-users ldap-users-india
  LDAPReferrals Off

  Require valid-user
</Location>


I'm using Subversion Edge 4.0.3 with Apache Http Server 2.4.6. I already had the server configured for LDAP and File auth so the required modules was already included in the conf files.
Comment 7 Dmitry 2013-12-15 14:16:16 UTC
I observe the same problem with Apache 2.4.6-3 (Debian sid). Actually documentation (http://httpd.apache.org/docs/2.4/mod/mod_authn_core.html) says that this functionality should be provided by mod_authn_core.

Configuration test passes OK, but AuthnProviderAlias has no effect: LDAP module is not activated, no requests are sent to server, Apache logs "AH01618: user NNN not found".
Comment 8 Eric Covener 2013-12-15 15:30:31 UTC
This configuration works for me when a user only belongs in one of ldap1 or ldap2:

<AuthnProviderAlias ldap ldap1>
AuthLDAPUrl ldap://bluepages.ibm.com/ou=bluepages,o=ibm.com?mail?sub?
</AuthnProviderAlias>

<AuthnProviderAlias ldap ldap2>
AuthLDAPURL ldap://goku.raleigh.ibm.com/o=apache,c=US?cn?sub?
</AuthnProviderAlias>

<Location />
AuthType basic
AuthName whatever
AuthBasicProvider ldap1 ldap2
require valid-user
</location>
Comment 9 Geir Engebakken 2013-12-17 13:58:59 UTC
Our users are defined in both ADs, but disabled in one of them, so we need to use a filter. It worked before in 2.2, but cannot get it to work in Apache 2.4.6

<AuthnProviderAlias ldap ldap-users>
  AuthLDAPUrl "ldap://*******:3268/DC=***,DC=***?sAMAccountName?sub?(!(userAccountControl:1.2.840.113556.1.4.803:=2))"
  AuthLDAPBindDN "************************"
  AuthLDAPBindPassword "**********"
</AuthnProviderAlias>

<AuthnProviderAlias ldap ldap-corp1>
  AuthLDAPUrl "ldap://*********:3268/?sAMAccountName?sub?(!(userAccountControl:1.2.840.113556.1.4.803:=2))"
  AuthLDAPBindDN "************************"
  AuthLDAPBindPassword "**********"
</AuthnProviderAlias>
Comment 10 Eric Covener 2013-12-17 14:13:05 UTC
(In reply to Geir Engebakken from comment #9)
> Our users are defined in both ADs, but disabled in one of them, so we need
> to use a filter. It worked before in 2.2, but cannot get it to work in
> Apache 2.4.6
> 
> <AuthnProviderAlias ldap ldap-users>
>   AuthLDAPUrl
> "ldap://*******:3268/DC=***,DC=***?sAMAccountName?sub?(!(userAccountControl:
> 1.2.840.113556.1.4.803:=2))"
>   AuthLDAPBindDN "************************"
>   AuthLDAPBindPassword "**********"
> </AuthnProviderAlias>
> 
> <AuthnProviderAlias ldap ldap-corp1>
>   AuthLDAPUrl
> "ldap://*********:3268/?sAMAccountName?sub?(!(userAccountControl:1.2.840.
> 113556.1.4.803:=2))"
>   AuthLDAPBindDN "************************"
>   AuthLDAPBindPassword "**********"
> </AuthnProviderAlias>

Can you generate LogLevel trace8 for the request?
Comment 11 Adrian Sandu 2014-01-03 00:57:21 UTC
I have something similar.

<AuthnProviderAlias ldap thing1>
        AuthLDAPBindDN ldapshp@thing1.int
        AuthLDAPBindPassword password
        AuthLDAPURL "ldap://dc.thing1.int/OU=THING Team BBU,DC=thing1,DC=int?sAMAccountName?sub?(objectClass=user)"
</AuthnProviderAlias>
<AuthnProviderAlias ldap thing2>
        AuthLDAPBindDN ldapshp@thing2.int
        AuthLDAPBindPassword password
        AuthLDAPURL "ldap://dcdlm.thing2.int/OU=THING Team DLM,DC=thing2,DC=int?sAMAccountName?sub?(objectClass=user)"
</AuthnProviderAlias>
<VirtualHost 10.10.1.32:80>
        ServerName athena.thing.int
        DocumentRoot /var/www/html/athena.thing.int
        <Directory /var/www/html/athena.thing.int>
                AuthBasicProvider thing1 thing2
                AuthType Basic
                AuthName "User"
                Require valid-user
        </Directory>
</VirtualHost>

If I put LogLevel trace8 in httpd.conf ( instead of LogLevel warn ) I get this:

[root@athena conf.d]# /etc/init.d/httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd: [Fri Jan 03 02:40:21.541073 2014] [core:trace3] [pid 14187] core.c(3035): Setting LogLevel for all modules to trace8
                                                           [  OK  ]

However, if I put LogLevel trace8 in at the top of conf.d/thing.int.conf ( pasted above )

[root@athena conf.d]# /etc/init.d/httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd: [Fri Jan 03 02:45:20.299802 2014] [core:trace3] [pid 14460] core.c(3035): Setting LogLevel for all modules to trace8
[Fri Jan 03 02:45:20.299952 2014] [authnz_ldap:trace1] [pid 14460] mod_authnz_ldap.c(1424): auth_ldap url parse: `ldap://dc.thing1.int/OU=THING Team BBU,DC=thing1,DC=int?sAMAccountName?sub?(objectClass=user)', Host: dc.thing1.int, Port: 389, DN: OU=THING Team BBU,DC=thing1,DC=int, attrib: sAMAccountName, scope: subtree, filter: (objectClass=user), connection mode: not using SSL
[Fri Jan 03 02:45:20.299978 2014] [authnz_ldap:trace1] [pid 14460] mod_authnz_ldap.c(1424): auth_ldap url parse: `ldap://dcdlm.thing2.int/OU=THING Team DLM,DC=thing2,DC=int?sAMAccountName?sub?(objectClass=user)', Host: dcdlm.thing2.int, Port: 389, DN: OU=THING Team DLM,DC=thing2,DC=int, attrib: sAMAccountName, scope: subtree, filter: (objectClass=user), connection mode: not using SSL
[Fri Jan 03 02:45:20.300684 2014] [core:trace3] [pid 14460] core.c(3035): Setting LogLevel for all modules to trace8
                                                           [  OK  ]

[Fri Jan 03 02:45:20.303593 2014] [suexec:notice] [pid 14460] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Fri Jan 03 02:45:20.336602 2014] [auth_digest:notice] [pid 14461] AH01757: generating secret for digest authentication ...
[Fri Jan 03 02:45:20.336715 2014] [auth_digest:debug] [pid 14461] mod_auth_digest.c(250): AH01759: done
[Fri Jan 03 02:45:20.337296 2014] [ldap:debug] [pid 14461] util_ldap.c(2939): AH01316: LDAP merging Shared Cache conf: shm=0x7f0cd7617b90 rmm=0x7f0cd7617be8 for VHOST: athena.thing.int
[Fri Jan 03 02:45:20.338093 2014] [ldap:info] [pid 14461] AH01318: APR LDAP: Built with OpenLDAP LDAP SDK
[Fri Jan 03 02:45:20.338150 2014] [ldap:info] [pid 14461] AH01319: LDAP: SSL support available
[Fri Jan 03 02:45:20.364323 2014] [core:trace4] [pid 14461] mpm_common.c(530): mpm child 14463 (gen 0/slot 0) started
[Fri Jan 03 02:45:20.365746 2014] [core:trace4] [pid 14461] mpm_common.c(530): mpm child 14464 (gen 0/slot 1) started
[Fri Jan 03 02:45:20.367057 2014] [core:trace4] [pid 14461] mpm_common.c(530): mpm child 14465 (gen 0/slot 2) started
[Fri Jan 03 02:45:20.368319 2014] [core:trace4] [pid 14461] mpm_common.c(530): mpm child 14466 (gen 0/slot 3) started
[Fri Jan 03 02:45:20.369630 2014] [core:trace4] [pid 14461] mpm_common.c(530): mpm child 14467 (gen 0/slot 4) started
[Fri Jan 03 02:45:20.369703 2014] [mpm_prefork:notice] [pid 14461] AH00163: Apache/2.4.7 (Unix) PHP/5.5.7 configured -- resuming normal operations
[Fri Jan 03 02:45:20.369737 2014] [mpm_prefork:info] [pid 14461] AH00164: Server built: Jan  2 2014 23:36:19
[Fri Jan 03 02:45:20.369811 2014] [core:notice] [pid 14461] AH00094: Command line: '/usr/sbin/httpd'
[Fri Jan 03 02:45:20.369855 2014] [mpm_prefork:debug] [pid 14461] prefork.c(995): AH00165: Accept mutex: sysvsem (default: sysvsem)
[Fri Jan 03 02:48:49.312603 2014] [core:trace5] [pid 14463] protocol.c(618): [client 10.10.9.90:40681] Request received from client: GET / HTTP/1.1
[Fri Jan 03 02:48:49.312813 2014] [http:trace4] [pid 14463] http_request.c(301): [client 10.10.9.90:40681] Headers received from client:
[Fri Jan 03 02:48:49.312831 2014] [http:trace4] [pid 14463] http_request.c(305): [client 10.10.9.90:40681]   Host: athena.thing.int
[Fri Jan 03 02:48:49.312843 2014] [http:trace4] [pid 14463] http_request.c(305): [client 10.10.9.90:40681]   Connection: keep-alive
[Fri Jan 03 02:48:49.312853 2014] [http:trace4] [pid 14463] http_request.c(305): [client 10.10.9.90:40681]   Cache-Control: max-age=0
[Fri Jan 03 02:48:49.312863 2014] [http:trace4] [pid 14463] http_request.c(305): [client 10.10.9.90:40681]   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
[Fri Jan 03 02:48:49.312873 2014] [http:trace4] [pid 14463] http_request.c(305): [client 10.10.9.90:40681]   User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36
[Fri Jan 03 02:48:49.312884 2014] [http:trace4] [pid 14463] http_request.c(305): [client 10.10.9.90:40681]   DNT: 1
[Fri Jan 03 02:48:49.312894 2014] [http:trace4] [pid 14463] http_request.c(305): [client 10.10.9.90:40681]   Accept-Encoding: gzip,deflate,sdch
[Fri Jan 03 02:48:49.312903 2014] [http:trace4] [pid 14463] http_request.c(305): [client 10.10.9.90:40681]   Accept-Language: en-US,en;q=0.8,ro;q=0.6
[Fri Jan 03 02:48:49.312913 2014] [http:trace4] [pid 14463] http_request.c(305): [client 10.10.9.90:40681]   If-None-Match: \\"0-4eed4a25d923d\\"
[Fri Jan 03 02:48:49.312923 2014] [http:trace4] [pid 14463] http_request.c(305): [client 10.10.9.90:40681]   If-Modified-Since: Tue, 31 Dec 2013 13:35:31 GMT
[Fri Jan 03 02:48:49.313063 2014] [authz_core:debug] [pid 14463] mod_authz_core.c(802): [client 10.10.9.90:40681] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Fri Jan 03 02:48:49.313081 2014] [authz_core:debug] [pid 14463] mod_authz_core.c(802): [client 10.10.9.90:40681] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Fri Jan 03 02:48:49.313101 2014] [core:trace3] [pid 14463] request.c(116): [client 10.10.9.90:40681] auth phase 'check user' gave status 401: /
[Fri Jan 03 02:48:49.313182 2014] [http:trace3] [pid 14463] http_filters.c(977): [client 10.10.9.90:40681] Response sent with status 401, headers:
[Fri Jan 03 02:48:49.313198 2014] [http:trace5] [pid 14463] http_filters.c(984): [client 10.10.9.90:40681]   Date: Fri, 03 Jan 2014 00:48:49 GMT
[Fri Jan 03 02:48:49.313208 2014] [http:trace5] [pid 14463] http_filters.c(987): [client 10.10.9.90:40681]   Server: Apache
[Fri Jan 03 02:48:49.313220 2014] [http:trace4] [pid 14463] http_filters.c(806): [client 10.10.9.90:40681]   WWW-Authenticate: Basic realm=\\"User\\"
[Fri Jan 03 02:48:49.313231 2014] [http:trace4] [pid 14463] http_filters.c(806): [client 10.10.9.90:40681]   Content-Length: 381
[Fri Jan 03 02:48:49.313259 2014] [http:trace4] [pid 14463] http_filters.c(806): [client 10.10.9.90:40681]   Connection: close
[Fri Jan 03 02:48:49.313268 2014] [http:trace4] [pid 14463] http_filters.c(806): [client 10.10.9.90:40681]   Content-Type: text/html; charset=iso-8859-1
[Fri Jan 03 02:48:49.313296 2014] [core:trace6] [pid 14463] core_filters.c(527): [client 10.10.9.90:40681] core_output_filter: flushing because of FLUSH bucket
[Fri Jan 03 02:48:49.313383 2014] [core:trace6] [pid 14463] core_filters.c(527): [client 10.10.9.90:40681] core_output_filter: flushing because of FLUSH bucket
[Fri Jan 03 02:48:49.546826 2014] [core:trace4] [pid 14461] mpm_common.c(530): mpm child 14468 (gen 0/slot 5) started
[Fri Jan 03 02:48:58.449614 2014] [core:trace5] [pid 14464] protocol.c(618): [client 10.10.9.90:40682] Request received from client: GET / HTTP/1.1
[Fri Jan 03 02:48:58.449807 2014] [http:trace4] [pid 14464] http_request.c(301): [client 10.10.9.90:40682] Headers received from client:
[Fri Jan 03 02:48:58.449824 2014] [http:trace4] [pid 14464] http_request.c(305): [client 10.10.9.90:40682]   Host: athena.thing.int
[Fri Jan 03 02:48:58.449834 2014] [http:trace4] [pid 14464] http_request.c(305): [client 10.10.9.90:40682]   Connection: keep-alive
[Fri Jan 03 02:48:58.449843 2014] [http:trace4] [pid 14464] http_request.c(305): [client 10.10.9.90:40682]   Cache-Control: max-age=0
[Fri Jan 03 02:48:58.449851 2014] [http:trace4] [pid 14464] http_request.c(305): [client 10.10.9.90:40682]   Authorization: Basic dGVzdDp0ZXN0MTIz
[Fri Jan 03 02:48:58.449860 2014] [http:trace4] [pid 14464] http_request.c(305): [client 10.10.9.90:40682]   Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
[Fri Jan 03 02:48:58.449869 2014] [http:trace4] [pid 14464] http_request.c(305): [client 10.10.9.90:40682]   User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36
[Fri Jan 03 02:48:58.449878 2014] [http:trace4] [pid 14464] http_request.c(305): [client 10.10.9.90:40682]   DNT: 1
[Fri Jan 03 02:48:58.449887 2014] [http:trace4] [pid 14464] http_request.c(305): [client 10.10.9.90:40682]   Accept-Encoding: gzip,deflate,sdch
[Fri Jan 03 02:48:58.449895 2014] [http:trace4] [pid 14464] http_request.c(305): [client 10.10.9.90:40682]   Accept-Language: en-US,en;q=0.8,ro;q=0.6
[Fri Jan 03 02:48:58.449904 2014] [http:trace4] [pid 14464] http_request.c(305): [client 10.10.9.90:40682]   If-None-Match: \\"0-4eed4a25d923d\\"
[Fri Jan 03 02:48:58.449913 2014] [http:trace4] [pid 14464] http_request.c(305): [client 10.10.9.90:40682]   If-Modified-Since: Tue, 31 Dec 2013 13:35:31 GMT
[Fri Jan 03 02:48:58.450047 2014] [authz_core:debug] [pid 14464] mod_authz_core.c(802): [client 10.10.9.90:40682] AH01626: authorization result of Require valid-user : denied (no authenticated user yet)
[Fri Jan 03 02:48:58.450064 2014] [authz_core:debug] [pid 14464] mod_authz_core.c(802): [client 10.10.9.90:40682] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet)
[Fri Jan 03 02:48:58.450087 2014] [auth_basic:error] [pid 14464] [client 10.10.9.90:40682] AH01618: user test not found: /
[Fri Jan 03 02:48:58.450102 2014] [core:trace3] [pid 14464] request.c(116): [client 10.10.9.90:40682] auth phase 'check user' gave status 401: /
[Fri Jan 03 02:48:58.450179 2014] [http:trace3] [pid 14464] http_filters.c(977): [client 10.10.9.90:40682] Response sent with status 401, headers:
[Fri Jan 03 02:48:58.450193 2014] [http:trace5] [pid 14464] http_filters.c(984): [client 10.10.9.90:40682]   Date: Fri, 03 Jan 2014 00:48:58 GMT
[Fri Jan 03 02:48:58.450202 2014] [http:trace5] [pid 14464] http_filters.c(987): [client 10.10.9.90:40682]   Server: Apache
[Fri Jan 03 02:48:58.450213 2014] [http:trace4] [pid 14464] http_filters.c(806): [client 10.10.9.90:40682]   WWW-Authenticate: Basic realm=\\"User\\"
[Fri Jan 03 02:48:58.450223 2014] [http:trace4] [pid 14464] http_filters.c(806): [client 10.10.9.90:40682]   Content-Length: 381
[Fri Jan 03 02:48:58.450231 2014] [http:trace4] [pid 14464] http_filters.c(806): [client 10.10.9.90:40682]   Connection: close
[Fri Jan 03 02:48:58.450260 2014] [http:trace4] [pid 14464] http_filters.c(806): [client 10.10.9.90:40682]   Content-Type: text/html; charset=iso-8859-1
[Fri Jan 03 02:48:58.450287 2014] [core:trace6] [pid 14464] core_filters.c(527): [client 10.10.9.90:40682] core_output_filter: flushing because of FLUSH bucket
[Fri Jan 03 02:48:58.450375 2014] [core:trace6] [pid 14464] core_filters.c(527): [client 10.10.9.90:40682] core_output_filter: flushing because of FLUSH bucket

Maybe this guy has some insight: 
http://stackoverflow.com/questions/18874062/can-authnprovideralias-ldap-work-with-apache2-4-x
Comment 12 Eric Covener 2014-01-03 01:36:53 UTC
Thanks Adrian, as basic as this sounds, does your symptom go away if you define and use your providers in either the same vhost or all in the base configuration?

For me, moving the usage into a VH broke my testcase, which meshes with the initial analysis in stack overflow (where the poster there finds a NULL returned, emphasis on per-server module config in authn_core, and lack of a merge function)
Comment 13 Eric Covener 2014-01-03 01:39:32 UTC
(In reply to Eric Covener from comment #12)
> Thanks Adrian, as basic as this sounds, does your symptom go away if you
> define and use your providers in either the same vhost or all in the base
> configuration?
> 
> For me, moving the usage into a VH broke my testcase, which meshes with the
> initial analysis in stack overflow (where the poster there finds a NULL
> returned, emphasis on per-server module config in authn_core, and lack of a
> merge function)

ironically, it's not specific to LDAP.
Comment 14 Eric Covener 2014-01-03 01:52:14 UTC
(In reply to Eric Covener from comment #13)
> (In reply to Eric Covener from comment #12)
> > Thanks Adrian, as basic as this sounds, does your symptom go away if you
> > define and use your providers in either the same vhost or all in the base
> > configuration?
> > 
> > For me, moving the usage into a VH broke my testcase, which meshes with the
> > initial analysis in stack overflow (where the poster there finds a NULL
> > returned, emphasis on per-server module config in authn_core, and lack of a
> > merge function)
> 
> ironically, it's not specific to LDAP.

The final magic piece of the puzzle -- this worked in 2.2 because <authaliasprovider> was by itself in a module, but now it shares a module with AuthType, which causes a per-server config to always be created when you use a provider.
Comment 15 Eric Covener 2014-01-03 01:59:47 UTC
http://svn.apache.org/r1554995 if anyone affected can give it a try.
Comment 16 Adrian Sandu 2014-01-03 11:19:37 UTC
Seems that if I put the <Directory> container with the auth outside of the <VirtualHost> directive .. it works ! :) Thanks for pointing that out ..
Comment 17 Adrian Sandu 2014-01-03 12:03:38 UTC
Tried the patch on 2.4.7, works as a charm.

Now .. to post a bug on 2.2 mod_authnz_ldap not doing its job with mod alias ( only the 1st provider uses the bind, the others fail ( tcpdump is saying that a successfull bind must be done before the search operation ).


The exact same configuration should work on 2.2 but it doesn't :|
Comment 18 Eric Covener 2014-03-01 00:55:29 UTC
*** Bug 56203 has been marked as a duplicate of this bug. ***
Comment 19 Eric Covener 2014-04-15 12:24:27 UTC
Setting [reported] version back to 2.4.7.