Ok, I think I have pinned down the problem. As it turns out, the client fails to bind to the OD completely (-14002). The tricky part is that it only happens when ALL of the conditions below are satisfied:
* DHCP is used to supply client with LDAP data.
* Both the LDAP AND AD plug-ins are active.
* The client is rebooted(!).
Before client reboot, everything is peachy. After reboot, only the AD accounts work, MCX settings are forgotten, and the Kerberos file cannot get the OD data. ldapsearch against the server still works fine.
10.3.8 and 10.3.9 client/server are equally affected (haven’t tried Tiger).
The obvious (or not-so) workaround is to setup OD binding manually in Directory Access.
To cut a long story short, I’ve filed a bug with Apple on this one. However, if someone else has experienced this odd behaviour, has additional info, or would like to review the evidence in full, please let me know!
I was under the strong impression that the OD part of edu.mit.kerberos were essential to get full functionality from the OD?
What you (and TIL 300765) are saying is that MCX settings will work regardless of kerberos, correct? This is something we could learn to live with, but I’d rather prefer to be able to have user accounts / home dirs in both OD & AD. Feel free to set me straight, of course.
(What is really eating me is that at some point, auto-generation actually worked. But it does not seem to be entirely stable…)
Recent Comments