When configuring MIT Kerberos to use an LDAP database instead of DB2, I was surprised to see that user password hashes are stored in two different fields: userPassword and krbPrincipalKey. Seems the hashing algorithms may be different, but that seems unnecessary too. Why not just consolidate to avoid synchronization issues?
Ryan's questions
I've got Apache setup as a reverse proxy for a Java Application server (GlassFish) and I noticed there are about 100 connections in the state CLOSE_WAIT even on an idle development system:
sudo netstat -n -e -p -a -t | grep httpd | grep CLOSE_WAIT | wc -l
I'm using the following HTTP proxy settings:
ProxyPass /myapp http://localhost:8080/myapp ttl=20 max=1 smax=0
ProxyPassReverse /myapp http://localhost:8080/myapp
Why are all of these connections hanging around? I've set the "ttl=20 max=1 smax=0" so I figured all connections would be cleaned up on an idle system. Is the application server not doing its part to cleanup the connections?
While doing some experimenting I noticed that the MIT Kerberos version 5 "kinit" program will warn you when either your password is about to expire (within 7 days) or when your principal is about to expire. However, the warning message is identical in both cases. Is this for some security reason or is this a bug? When a principal expires kinit no longer allows you to obtain a TGT (You get the message: "kinit: Client's entry in database has expired while getting initial credentials"). In contrast, once your password expires kinit will prompt you for a new one.
I've got a name-based virtual host setup on port 443 such that requests on host 'apple.fruitdomain' are proxied to the apple-app and requests on host 'orange.fruitdomain' are proxied to orange-app. This is working, but I'd like to add a ServerAlias for each such that requests on host 'apple' are proxied to apple-app and requests on host 'orange' are proxied to the orange-app. If I simply add a ServerAlias directive to the virtual host it doesn't work. ssl.conf below:
Listen 443
NameVirtualHost *:443
<VirtualHost *:443>
ServerName apple.fruitdomain
ServerAlias apple
SSLProxyEngine on
ProxyPass /apple-app https://localhost:8181/apple-app
ProxyPassReverse /apple-app https://localhost:8181/apple-app
...
</VirtualHost>
<VirtualHost *:443>
ServerName orange.fruitdomain
ServerAlias orange
SSLProxyEngine on
ProxyPass /orange-app https://localhost:8181/orange-app
ProxyPassReverse /orange-app https://localhost:8181/orange-app
...
</VirtualHost>
Interestingly if I do a similar setup but with port 80 then the ServerAlias works...
I'm trying to setup the GlassFish application server behind an Apache reverse proxy. I've got it working with both port 80 and 443, but the problem is the transition between the two that occurs when a user accesses a page that requires authentication which causes Glassfish to issue a redirect to the login page, and in turn requires SSL over Apache 443/GlassFish 8181. In this case the user's browser attempts to access the origin server directly, which in my case is localhost so actually causes the user to try to access their own local system (https://localhost:8181/myapp).
To get this far I added the following to httpd.conf:
<VirtualHost *:80>
ProxyPass /myapp http://localhost:8080/myapp
ProxyPassReverse /myapp http://localhost:8080/myapp
</VirtualHost>
And the following to ssl.conf:
<VirtualHost _default_:443>
SSLProxyEngine on
ProxyPass /myapp https://localhost:8181/myapp
ProxyPassReverse /myapp https://localhost:8181/myapp
...
I've tried to add an additional ProxyPassReverse directive, but that doesn't work, probably because it can't handle switching protocols. Maybe I need to add a RewriteRule directive? Or maybe I need to enable mod_proxy_html to rewrite content?
Is it possible to have the reverse proxy (Apache HTTP 2.2) handle authentication (HTTP Basic) and then still use the container managed security of the Java application server (GlassFish 3.1 or JBoss 7.0.2) for authorization?
I've got GlassFish doing container managed security (both authentication and authorization together) just fine using both declarative and programmatic container security with form based authentication and a custom GlassFish authentication module. I've even got this working through an Apache HTTP web server reverse proxy using mod_proxy_ajp. Now I'm just trying to find a way to offload the authentication piece to Apache while maintaining the container managed security authorization piece. Maybe there is a single-sign-on interface in the Java application server which would facilitate this (since this is like SSO - Apache requires authentication for everything behind it)?