edu.mit.kerberos overwritten (erroneously)

[emill]

Hi all,

I have an issue with OD/AD binding that I ca’nt seem to solve. After binding clients to both OD and AD, all is fine and the edu.mit.kerberos file is created jointly by the AD & LDAP plugins. After reboot, however, the AD plugin overwrites the file, seemingly without consulting LDAP. Doing it manually with /sbin/kerberosautoconfig gives the same result, unless edu.mit.kerberos is deleted beforehand.

This is odd, as the generation ID on the server (/LDAPv3/127.0.0.1/Config/KerberosClient = 1659293282) is vastly greater that what the AD plugin generates (134404727 ballpark).

The LDAP gid gets used when placing that service highest in the Authentication list, otherwise it use the AD gid.

After the rewrite, lookups to the OD fails with -14008. In rare cases, the opposite happens, so that only the LDAP info gets written – AD lookup then fails with -14002.

What gives?

N.B. removing the autoconf lines from edu.mit.kerberos DOES fix the problem, but as the AD is rather extensive and treacheously dynamic, i’d rather have the dynamic mechanism working…

Thanks in advance,

/Emil

Background info:

Goals:
Bind clients (10.3.8) to OD (OS X server 10.3.8) and AD (Win 2003 server)
Use computer lists to set prefs in OD
Use accounts in OD & AD to login

Setup:
OD: macserver.example1.com
AD: pcserver.example2.local
Clients: macXXX.example1.com

DNS: example1.com on regular DNS, example2.local on AD
(using an /etc/resolver/example2.local file to provide lookup on both domains)

[emill]

Hi and thanks for the reply,

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…)

/Emil

P.S. I’ll see you in Stockholm next week!

[emill]

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!

regards,

/Emil

[Author]

Posts