OK, so I’ve done some more tinkering. I’m giving up (for the time being) on pulling the user’s full name out of the LDAP server, though something tells me I’m missing something pretty obvious there. It would be ideal, of course, for it to work both with OpenLDAP and AD, but it may take someone smarter than I to figure this out.
I’ve built an RPM for automx using the current code on GitHub–the 0.10.2 version used for the OpenSuSe RPM is now four years old, and there have been some major changes since then, though the project now appears to be all but abandoned. I started with their .spec file, cleaned it up a bit (mainly to remove the multi-distro logic), and adjusted some dependencies.
I’ve also built a nethserver-automx RPM based on @Stefano_Zamboni’s work, with a couple of updates to the templates and dependencies. The templates seem to be doing what I want them to do, and the script seems to be working as intended. Here’s what’s tested and working:
- The script responds properly to Thunderbird-style autoconfiguration requests, with properly-formatted XML consistent with the manual.
- The script generates .mobileconfig files for Apple clients, with the same configuration.
- When the configuration properties are set correctly, and the script is given a certificate and private key, it will generate signed .mobileconfig files, which are much more useful (fewer warnings to click through on installation).
Not tested, but assumed working:
- Responding properly to Outlook-style autoconfiguration requests. Since this uses the same script and configuration file, it should work, but I haven’t tested it yet.
Not working, needs fixing:
- The nethserver-automx RPM adds a virtualhost.conf template fragment and expands that template, but doesn’t reload httpd. Trying to reload httpd puts it in a weird state where the error log is showing repeated segfaults. After restarting httpd, it works fine.
- The nethserver-automx-update event doesn’t expand the automx.conf template.
Signing .mobileconfig files remains an issue of key control. Ordinarily the private key file is only readable by root, and Apache doesn’t run as root. This means the automx script can’t read the private key, and therefore can’t sign anything. There are a few ways I can think of to deal with this:
- Run Apache as root. Generally discouraged for security reasons.
- Make the server’s private key readable by Apache. Also generally discouraged for security reasons.
- Make the automx script setuid root. Again, discouraged for security reasons. Any of these three options raise the possibility of leaking private key data for your main server certificate.
- Create a separate certificate for just autoconfig.yourdomain, and make that readable by the automx script. There’s still the possibility of a key compromise if there’s a vulnerability in that script, but that key would do less damage if compromised.
My RPM would work with options 2 and 4 (since there are config properties for the cert and key paths, you can set them to whatever you want), but I think option 4 is the least bad.
So how can I get these RPMs somewhere where people can bang on them for a bit?