Closed Proxy implemented with Apache Refuses all Authentication Credentials
First of all, I have to admit I am also puzzled at why, when the proxy offers a challenge, it uses WWW-Authenticate instead of Proxy-Authenticate. That may be a hint, or it may be a distraction.
But the immediate problem is this: I am trying to configure Apache to run on port 8080 as a proxy only, accessible without password for machines on my LAN, but accessible only after a challenge to machines outside. Right now, I am using Basic authentication, but I certainly plan to leave it enabled only after it has been switched to Digest. The first part works: I can access the proxy from inside. But the second fails: I get a password challenge, but it always fails to accept even valid user/pwd. So for now, I am using the following lines in httpd.conf: <IfModule mod_proxy.c> ProxyRequests On ProxyVia On <Proxy *:8080> Require valid-user AuthName "ClosedProxy" AuthType Basic AuthUserFile /home/mejohnsn/xanthusPwdFileBasic Order allow,deny Allow from 192.168.0.0/255.255.255.0 Satisfy Any </Proxy> </IfModule> I also tried moving the Require directive, replacing 'valid-user' w/ 'user mejohnsn, and AuthName both with and w/o quote marks. Other points: yes, I made sure user:group 'apache' has read permissions on the file. I made sure it has the modules, mod_auth_basic and mod_authn_file. In fact, when I print out using httpd -M and grep for auth, I see: auth_basic_module (shared) auth_digest_module (shared) authn_file_module (shared) authn_alias_module (shared) authn_anon_module (shared) authn_dbm_module (shared) authn_default_module (shared) authz_host_module (shared) authz_user_module (shared) authz_owner_module (shared) authz_groupfile_module (shared) authz_dbm_module (shared) authz_default_module (shared) authnz_ldap_module (shared) and grepping for proxy: proxy_module (shared) proxy_balancer_module (shared) proxy_ftp_module (shared) proxy_http_module (shared) proxy_connect_module (shared) So I think I have all the modules I need. As expected from following the online docs, the above "Order ... Any" lines correctly force password authentication when connecting from outside the firewall, allowing use of proxy w/o login when from within the LAN. I also tried both with and w/o the '-m' in: "htpasswd -m -c xanthusPwdFileBasic mejohnsn". Finally, of course, I am running Fedora 14 and Apache 2.2.17. |
Hi,
You should use the following: Code:
Order Deny,Allow |
Quote:
|
Did you try it? This way it denies access to anyone unless "Satisfy Any" occurs.
You need the above change if you want to allow access either by IP or by username/password |
Quote:
So I will try your change later today, but I still cannot see how it could help. I will update this thread with the results in either case. |
Quote:
Anyway if you are prompted for username/password, but cannot authenticate, check the apache error_log to see if you find the reason. |
Quote:
As for the Order directive, as I read the online Apache docs, the second parameter for the Order command is the default. Since I had "allow,deny", I did not need an explicit deny, it was the default. I think relying on the default makes for less readability, but it explains why the Apache example works. So we are back to the basic problem: why I see a password prompt, but it rejects the one user/pwd combo defined. Also, why it displays the wrong realm. I set the realm explicitly to 'ClosedProxy' (see my original post this thread), yet what I see is always some long winded message, a default set by someone else. BTW: I am not sure it is relevant, but I am also seeing it sometimes return "404 not found" instead. But at least once, when I cleared cookies and history, I got it to return "401 not authorized" again. I haven't figured out the pattern yet, since I tried clearing both again, yet still get 404. But I still get no errors in error_log, I can watch the client do a GET http://www.ipl.org/div/special/ HTTP/1.1 (in Wireshark). So httpd thinks it is doing exactly what it was told to do;) Finally, since I did get the 401 again, I can see the long wordy message it is using for the realm: "Before configuring the Gateway, a User Name / Password is required. If you do not know the User Name / Password please refer to the User manual for further support." That is not the realm I specified! This suggests to me that Apache is still not processing the AuthName directive -- for some mysterious reason. And this is the sole occurrence of AuthName in the whole file. Anyway, thanks for your time, and please do let me know if you think of any other things I should investigate or try. |
Hi,
Quote:
Quote:
|
Quote:
As for .htaccess, I already thought of that: no, there are none, and I have "AllowOverride None" anyway (outside of any container, in the "server config" context). Now back to the error_log file: here is a pretty typical output after I to "httpd -k restart" and try one Http GET: [Thu Mar 08 19:49:08 2012] [info] Server built: Oct 27 2010 10:04:08 [Thu Mar 08 19:49:08 2012] [debug] prefork.c(1018): AcceptMutex: sysvsem (default: sysvsem) [Thu Mar 08 19:49:08 2012] [debug] proxy_util.c(1818): proxy: grabbed scoreboard slot 0 in child 11390 for worker proxy:forward [Thu Mar 08 19:49:08 2012] [debug] proxy_util.c(1837): proxy: worker proxy:forward already initialized [Thu Mar 08 19:49:08 2012] [debug] proxy_util.c(1934): proxy: initialized single connection worker 0 in child 11390 for (*) [Thu Mar 08 19:49:08 2012] [debug] proxy_util.c(1818): proxy: grabbed scoreboard slot 1 in child 11390 for worker proxy:reverse [Thu Mar 08 19:49:08 2012] [debug] proxy_util.c(1837): proxy: worker proxy:reverse already initialized [Thu Mar 08 19:49:08 2012] [debug] proxy_util.c(1934): proxy: initialized single connection worker 1 in child 11390 for (*) [Thu Mar 08 19:55:49 2012] [info] removed PID file /etc/httpd/run/httpd.pid (pid=7401) [Thu Mar 08 19:55:49 2012] [notice] caught SIGTERM, shutting down One of the things that concerns me is that it mentions reverse already initialized: since I have one occurrence in server context (formerly in <IfModule> block) of ProxyRequest On, and none of ProxyPass, I do not understand why a reverse proxy is initialized at all. Nor why forward is -already- initialized. But there is no mention of the attempted access here or in access_log. Yet I can see the HTTP transaction in Wireshark. I hope this does not leave you feeling as stymied as it does me;) Again, I look forward to whatever observations/suggestions you might have. Then again, after writing the above, it occurred to me: is the problem ServerName? I had it set to the 'inside' IP address of the proxy in the 192.168.0.0 block. But outside, of course, it has another IP address. What impact does the differing IP address really have and how should I deal with it? I would try ServerAlias, but the online docs seem to say that is for Virtual Hosting only, which I no longer do (my setting of ServerName is left over from when I was trying that). |
Quote:
Quote:
Quote:
For the rest, I don't think that ServerName is that important. But you can put all your proxy stuff inside a vhost container like this: Code:
<VirtualHost *:8080> |
Quote:
Yes, I could, but the only difference between that and what I already tried is that 1)you are giving up on the restriction of the proxy to port 8080 and 2) you are leaving the default server doing who-knows-what. That looks like it introduces more complications we really don't need as long as we don't understand where that value for realm is coming from. Besides: if that makes the difference, then isn't there a bug in Apache? Yet Googling has turned up no such report. I will keep this suggestion in mind, but at this point in time, I think there are more promising avenues to investigate. I will update the thread if I find something. And about your exclamation points, yes, you got that exactly right, and I am just as amazed! Either there really is a bug in Apache such that it is finding that Realms somewhere else, or the indentation got screwed up in my httpd.conf and I don't know when I am really in what context. One final note for now: when I give up on distinguishing between inside and outside using the following for the <Proxy> section, I get it working, even using Proxy-Authenticate (instead of WWW-Authenticate) only when going to the proxy from inside the firewall! The current <Proxy>: ProxyRequests On ProxyVia On <Proxy *> Order deny,allow Allow from all AuthType Basic AuthName "Password Required" AuthUserFile xanthusPwdFileBasic Require valid-user </Proxy> all the above in server config context (assuming indentation correct). Oh, I have two more questions that I think would help to have answered, perhaps you can help with that: 1) what does 'ProxyVia' really do, anyway? The Apache docs are skimpy on explaining this. 2) now that you know I have no .htaccess files, what else do I have to do to be sure no other configuration files are loaded? I realize that without the '-f' option, httpd assumes <ApacheRoot>/conf/httpd.conf, but don't I have to check for includes, too? Anyway, thanks for your help so far. |
You are not going to believe what fixed it: it was giving up on using port 8080 alone, reverting to port 80. Now it works both from inside and outside the LAN. This makes no sense to me, but I can live with it, so I changed the sole Listen directive to "Listen 80" in place of "Listen 8080".
|
Glad to see you've made it, even though I still wonder why it works when apache listens on port 80 and not when it listens on port 8080
Quote:
Quote:
For an explanation of the Via header see #14.44 here Quote:
Regards |
All times are GMT -5. The time now is 04:21 PM. |