Posted on 01-06-2012 08:52 AM
So in the interest of buttoning a few things up over here I got the LDAP lookups setup with our CA cert so that it is done over SSL. I also got a public wildcard cert installed and setup in Tomcat so I can now goto:
https://host.glenbrook225.org:8443
and get no cert errors and passwords are no longer sent in the clear. :)
Now I want to redirect everything so you have to login over SSL.
Basically I want an Apache/Server Admin "RedirectMatch / https://host.glenbrook225.org" to the site running on the secure port so that you are always forced to login over SSL etc.
At present visiting https://i.p.ad.dy:8443 results in a cert error as does https://host:8443.
And despite the fact that this entry
<Connector executor="tomcatThreadPool"
port="9006" protocol="HTTP/1.1"
connectionTimeout="20000"
maxPostSize="8388608"
redirectPort="8443" />
Already exists in /Library/JSS/Tomcat/conf/server.xml it does NOT, in fact, redirect :9006 to :8443.
Has anyone done this? How do I get it to work? Do I need to clarify better?
Thanks,
~Ryan
Solved! Go to Solution.
Posted on 01-06-2012 02:42 PM
I discovered the answer yesterday but I needed to read it a little more carefully before I grok'd it. The shortened link points to a post on the Apache mailing list from 2001.
So I got all the Management Framework settings correct, CMD + OPT launched Admin and Remote and changed where they were pointing to, tested a few things on a client machine and everything was working as I hoped.
Then I swam to the deep end. ;)
The key thing I wasn't getting on the first pass was this part, "In the deployment descriptor for your web app (/WEB-INF/web.xml)"
After I thought for a second I dug down and found the file here:
/Library/JSS/Tomcat/webapps/ROOT/WEB-INF/web.xml
A quick copy of the web.xml file.
$ cp web.xml{,.bak}
And then I opened the file up in vim and pasted the following after <web-app> and before the first <listener>
<security-constraint>
<web-resource-collection>
<web-resource-name>JSS</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
et voilà
Hitting the JSS via web browser on 9006 always redirects you to 8443.
Because it isn't taking you to the FQDN like the Apache trick above the cert still throws an exception if you goto the IP addy or just the hostname but at least it is encrypted. :D
Also, I thoroughly tested policies, Remote, and Self Service after making this change and so far there are no issues. Having said that, you should proceed at your own risk, IANAL, etc. etc., and be wary of the Global Device Management page re: SCEP
Cheers,
Ryan
Posted on 01-06-2012 03:54 PM
Would using an Apache virtual host redirect you to the FQDN?
Posted on 01-06-2012 09:08 AM
Ryan,
I'm not sure if this is what you are interested in, but if you login to your JSS, and go to Settings->Global Management Framework Settings there will be two fields there. One field will have the 8443 port and the other with a title of "JSS URL (HTTP)" will have a default value of http://jss.mycompany.com:9006/. If you just delete that value out of the "JSS URL (HTTP)" and leave it blank it will force all traffic over port 8443. You then do not have to edit the server.xml file manually.
Dave
Posted on 01-06-2012 09:29 AM
I did need to do fix those settings as well so thanks for the reminder but that is not exactly what I mean.
I am not really talking about the computer -> JSS communication right now, I will take care of that as soon as I get this licked.
Here is an example of what I am looking to accomplish.
We use AD and several years ago I set up an internal wiki for posting training items, procedures etc. Now Apple recommends you to use SSL to auth an AD user to the wiki (http://support.apple.com/kb/ts1619). So one thing that I did was tell Apache via Server Admin to redirect all traffic to the site running on 443.
The result of this is no matter if you browse to
http://wiki.domain.org
http://wiki
http://192.168.1.1
https://wiki
https://192.168.1.1
You always end up at
https://wiki.domain.org
So all the traffic is always done over SSL with no cert errors.
What I want is if my boss goes to http://jss.domain.org:9006, which we have been using since setting Casper up for the first time, to generate a report of some kind Tomcat redirects his browser to the secure connection on 8443.
Or if I just type in "jss" in the browser bar and let DNS handle getting me there I get redirected to https://jss.domain.org so that I do not get a cert error because https://jss:8443 is not the FQDN in the cert. This applies to the IP addy as well.
Posted on 01-06-2012 09:38 AM
To clarify further I NEVER, EVER want to see this in Wireshark again.
0000 00 1f fe 87 a5 00 34 15 9e 3c 79 fa 08 00 45 00 ......4. .<y...E.
0010 00 64 1a d4 40 00 40 06 00 00 0a 03 2b fa 0a 01 .d..@.@. ....+...
0020 4b 84 ca 9a 23 2e d1 68 13 56 01 33 0f 84 80 18 K...#..h .V.3....
0030 82 18 8b d8 00 00 01 01 08 0a 9f a2 38 f9 41 7a ........ ....8.Az
0040 c9 b4 75 73 65 72 6e 61 6d 65 3d 72 6d 61 6e 6c ..userna me=rmanl
0050 79 26 70 61 73 73 77 6f 72 64 3d 73 69 6c 6c 79 y&passwo rd=silly
0060 70 61 73 73 31 26 73 75 62 6d 69 74 3d 4c 6f 67 pass1&su bmit=Log
0070 69 6e in
Posted on 01-06-2012 02:42 PM
I discovered the answer yesterday but I needed to read it a little more carefully before I grok'd it. The shortened link points to a post on the Apache mailing list from 2001.
So I got all the Management Framework settings correct, CMD + OPT launched Admin and Remote and changed where they were pointing to, tested a few things on a client machine and everything was working as I hoped.
Then I swam to the deep end. ;)
The key thing I wasn't getting on the first pass was this part, "In the deployment descriptor for your web app (/WEB-INF/web.xml)"
After I thought for a second I dug down and found the file here:
/Library/JSS/Tomcat/webapps/ROOT/WEB-INF/web.xml
A quick copy of the web.xml file.
$ cp web.xml{,.bak}
And then I opened the file up in vim and pasted the following after <web-app> and before the first <listener>
<security-constraint>
<web-resource-collection>
<web-resource-name>JSS</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
et voilà
Hitting the JSS via web browser on 9006 always redirects you to 8443.
Because it isn't taking you to the FQDN like the Apache trick above the cert still throws an exception if you goto the IP addy or just the hostname but at least it is encrypted. :D
Also, I thoroughly tested policies, Remote, and Self Service after making this change and so far there are no issues. Having said that, you should proceed at your own risk, IANAL, etc. etc., and be wary of the Global Device Management page re: SCEP
Cheers,
Ryan
Posted on 01-06-2012 03:54 PM
Would using an Apache virtual host redirect you to the FQDN?
Posted on 01-09-2012 09:49 AM
Why not just block port 9006 at the server's firewall?
Posted on 01-09-2012 10:19 AM
I didn't see the forest for the trees as I don't know a lot about Apache, Tomcat etc. So I assumed the solution had to be done via Tomcat.
bentoms is correct. I created a VirtualHost via Server Admin to do the RedirectMatch I talked about so that all traffice arriving on 9006 is redirected to
https://host.domain.org:8443
and it is working beautifully.
I knew how to do that as you can see from my initial post but I wrongly assumed that it would not work or it would break something in Tomcat so I didn't even try.
Thanks for the tip bentoms. I learned a LOT about how Apache works this morning and even more about what Server Admin does to all of its conf files.
Posted on 01-09-2012 02:40 PM
Np.
Took me ages to figure it out on Lion server as Apple have removed most of the options from the GUI. :(
http://macmule.com/2011/09/20/how-to-enable-virtual-hosts-on-lion-server/
Posted on 01-10-2012 08:15 AM
FYI just found out this morning setting up the Virtual Host / RedirectMatch on 9006 to 8443 prevents the old machines from self-updating the settings and getting the cert when the management framework runs...so no go on there. :(