Authbind broken in 10.14 - with workaround

[darrelle]

In Jamf 10.14 (on Ubuntu 18.04), tomcat has moved to systemd instead of the old init script. It seems that all of the handling of the AUTHBIND environment variable has been removed. Setting AUTHBIND=yes no longer works to allow binding to unprivileged ports.

As a workaround, you can make a change to the ExecStart line /etc/systemd/system/jamf.tomcat8.service as follows:

ExecStart=/usr/bin/authbind --deep /usr/local/jss/tomcat/bin/startup.sh

[aaronpolley]

Good save! This one definitely stumped me when I first realised /etc/init.d/jamf.tomcat8 was gone

[m_entholzner]

Thanks for that hint! works like a charm for me. I'd be curious if there's an "official" solution for this topic...

[franton]

We've circumvented this by running on the default port 8080 and doing our SSL termination at a load balancer instead. Better design than putting Jamf in a DMZ as it means external attackers hit the LB, and Tomcat isn't running as root or has the overhead of SSL decrypt.

[cstout]

Thank you for posting this. You saved the day.

[darrelle]

A follow-up for anyone else using this authbind fix - it's possible to use a systemd "drop-in" config to make this fix persistent across jamf upgrades. All you need to do is create the file /etc/systemd/system/jamf.tomcat8.service.d/override.conf with the following contents:

[Service]
ExecStart=
ExecStart=/usr/bin/authbind --deep /usr/local/jss/tomcat/bin/startup.sh

This will persistently override the ExecStart command.

[cstout]

In Ubuntu 20.04.2 LTS I had to edit the file located here:

/etc/systemd/system/jamf.tomcat8.service

 Just open it up in your editor of choice and then find the "ExecStart=" line. Edit it to be:

ExecStart=/usr/bin/authbind --deep /usr/local/jss/tomcat/bin/startup.sh

and restart to see it go into effect.

Thanks for the tip @darrelle!