As I just wanted a test box on my local network, I followed Apple's suggestion to use a ".local" hostname and installed it as "aplawrence.local". That's the installation that worked, although it had some odd behavior as related earlier.
Configured as shown above, that all worked perfectly.
So far, so good. Of course, aplawrence.local was not what I wanted. I wanted something like "aplawrence.org" (not really, but for purposes of this testing). I therefore first tried changing the host name to "server.aplawrence.org". Apple warns that this may not be a good idea:
In fact, after changing the hostname, the slapd files don't appear to be touched. The Open Directory server name now showed "server.aplawrence.org" but other things still said "aplawrence.local"
The /etc/openldap/slapd_macosxserver.conf also still had references to "aplawrence.local".
By the way, this is all quite different from how it was in 10.7 server, so if you find yourself confused, that might be why.
I figured I could just edit the files to change "aplawrence.local" and "APLAWRENCE.LOCAL" to "aplawrence.org" and "APLAWRENCE.ORG". I made the edits and rebooted, but nothing changed. To my complete surprise, "aplawrence.local" continued to work from the Kerio side!
Must be something cached in Kerio, I thought, so I shut that down and restarted it. Nope, still happily found "aplawrence.local".
Ah, but wait: what about the launchd files? Well, on 10.8, they are empty files:
OK - this was baffling. There must be some configuration files I missed and it looks like the stuff in /etc/openldap gets read in to those rather than being used directly - and they haven't been re-read. Understand I'm guessing at that, but I can't think of anything else to explain this. So, momentarily giving up on that mystery, I reverted to a snapshot and did a fresh configuration, using "server.aplawrence.org" as my host name.
I had tried that before, but I had made a mistake. I wrongly assumed that the Open Directory would ignore the "server" part and create a server for "aplawrence.org". I therefore configured Kerio to look for that and it failed. It failed because Open Directory doesn't ignore "server" at all:
"server.aplawrence.com" is also configured in the /etc/openldap/slapd_macosxserver.conf and configuring Kerio to use that will work:
That's not really what I want, though. I want just "aplawrence.org" on the Kerio side, but I still want this server to be "server.aplawrence.org". I can always do an alias of just aplawrence.org for this domain, but that is annoying.
With Microsoft, you can say the directoryserver name is not the same as the mail server domain. Why can't you do that with Apple?
Domain Mapping in Kerio Control
An easy thing to miss in Control is the necessity to pull down the domain in the Users section:
Control can also map from multiple domains:
What if I want that Open directory machine to handle aplawrence.org and aplawrence.net? Surely Open Directory can do that, but if it can, I've been unable to dig anything out of Google that would tell me how. In fact, I seem to find hints that it can't; that you'd need to set up yet another server for another domain. That seems hard to believe.
Whether you can or cannot, there is obviously more to Open Directory than just the ldap files. Without knowing how that works, I can't do much more here, so I'll move on to looking at using a Linux server as the authentication point.
The next part of this will be delayed a bit as I have too many other things on my plate right now.
Solved by customer
A customer ran into this problem and spend several unfruitful hours with Kerio Support and an Apple technician. After all that, he called me and I commiserated but told him I had not been able to figure it out either. While we talked, he doodled atound and suddenly said "I've got it!"
His Apple server was configured as "kerio.xyzx.com" and of course Connect wanted to be just xyzx.com. This is how he configured it:
THAT works! A big thank you to Armen Meguerditchian at Outcome Referrals!
But I tried exactly that and it did not work. I need to revisit that to see why.
I think this is it
Interestingly, Armen's setup did NOT work. It was a variation on what I had found, but the symptoms were that the setup as described above would TEST and would bring in domain users, but would reject their password when they tried to login.
The same behavior was observed on Workspace, Control and Operator.
In Workspace, Control and Operator, the solution was simple: the Kerberos domain needed to be set to KERIO.xyzX.COM, not just xyzX.COM. Of course it needed that in Connect also, but oddly it would not work until Connect was restarted.