Let me start with a big disclaimer: I don't fully grok Kerberos and I definitely do not grok how Kerio interfaces with it to get directory service authentication. These notes are therefore somewhat in the realm of "magic", which is something I really detest in troubleshooting: incant the magic words (or type them correctly, more likely) and things will work. I hate that, but I have neither sufficient time nor a sufficient test environment to dig deeply into the mysteries of Kerberos and Kerio's interaction with it.
The Connect user guide also has useful information on Kerberos, including some troubleshooting tips not included in that Knowledge Base article. Microsoft also has tools that can help check from that side of things:.
If things do NOT work, pay attention to the section of those articles that has the heading "Troubleshooting". Those are basic tests you can do at the Linux command line to validate your configuration. Until those work, there's no chance Kerio is going to have any luck either.
Note: it has been suggested that this "test" should include a kinit lookup. I suspect this will be added in some future version.
However, even that may not be enough. For example, I had a customer who had entered the correct server address in the Kerio configuration pane, but had referenced the backup domain controller in the Kerberos as though it were the primary. This caused authentication to ALWAYS use the backup domain controller, which led to a very confusing time when he tried shutting down that backup for an upgrade! As he had also accidentally mistyped the IP of the primary (the backup as far as Kerberos knew), that caused an error log full of "Cannot contact any KDC for requested realm, error code 0x96c73a9c" messages - quite baffling until he noticed the Kerberos configuration error.
Speaking of logs, turning on User Authentication and Directory Service Lookup in the Kerio Debug log can also help you track down odd authentication problems. Without those, Kerio logs won't help you much.
Generic LDAP and SAMBA
As implied by the title of that KB article, Kerio assumes Microsoft Active Directory or Apple Open Directory. However, because Apple Open Directory is an LDAP configuration, you can use other LDAP servers. Kerio does warn against this:
Please note this is not directly supported by Technical Support
and you are using this feature at your own risk!!! We recommend
to consider if this is really required scenario and we recommend
to use some supported solution for not experienced users like the
Active Directory integration or the Open Directory integration.
This is an area where I do have the infrastructure needed to test, but have simply lacked the time and sufficient motivation to set it up.
I'll therefore just note these articles for now and wish you luck:
Another option for directory service authentication is Kerio's own Unity Directory server. This doesn't use Kerberos, which eliminates that part of troubleshooting. Kerio Unity is presently in beta but is probably coming out soon.
Work to be done
I'd really like to set up some test servers here as virtual machines, but I don't presently own any Microsoft server products. If anyone wants to donate a LEGAL non-OEM cd and license, that would help.
On the Apple side, I have Mountain Lion and could upgrade it to Server for $19.99; my only hesitation is not knowing how much and for how long that upgrade is likely to affect my daily work. If anyone reading this has actually done that upgrade, please let me know.
With that infrastructure, I could deploy a "break it on purpose" campaign and perhaps have more to offer here.