Local KDC (LKDC) relating to Leopard clients logging into Tiger Server

Question

This is a follow-up to my posting on this thread:
http://discussions.apple.com/message.jspa?messageID=5982070#5982070
Pursuing the problem I had when I upgraded to Leopard, I found it odd that trusted binding to Tiger OD from a Leopard client created a funny computer entry in the Workgroup Manger (WGM). Previously when using trusted binding from a Tiger machine to a Tiger server, one entry would be created. And Logging in as an OD user worked every time for me. However, it appears that under 10.5.1 Kerberos has changed significantly in that it is now being used extensively through the Leopard OS for Peer-to-Peer applications. This may account for the screwed up Computer account entries in WGM when a 10.5.1 client binds to 10.4.11 Server using trusted binding. The giveaway clue to this is the LKDC:SHA1 entry created in the WGM computer record (usually 3 seperate records for 10.5.1 instead of the normal single record with a Tiger client). My question is this:
Are there any changes that can be performed via command line on the 10.5.1 client to mimic the old 10.4 client Kerberos configuration without pervasive Peer-to-Peer use of Kerberos? Is is a config setting for the mit.kerberos file? Could it be as simple as flipping a switch to get the older more compatible Kerberos config of a 10.4 Tiger client? Can I dump the Local KDC present in Leopard, and get back to the good old days of non-local KDC under Tiger?
http://www.afp548.com/article.php?story=LeopardServerReview-LocalDirectory
"The Local KDC
Yes, you read that right, the local KDC. All Leopard client systems will now create a Local KDC for use with peer to peer file sharing.
While this isn't even as close to as scary as it seems, it is a topic worthy of at least a separate article, if not a whole series. I put on my thinking toque and sat in my thinking corner for a while on this, and I've not yet been able to come up with a reason for why having a KDC on every machine is less secure than how 10.4 did things. Having said that, though, I fully understand how this can seriously freak out your network security team as they don't quite grasp all the ins and the outs of this. Combine this with Back to My Mac, another article that's forthcoming, and you have a very interesting collection of some "sleeper" features in Leopard.
So, in a nutshell, a Local KDC, the LKDC, is created when 10.5 is installed. Local users will get LKDC authentication authorities allowing them to get Kerberos tickets and use that for single sign on to all the services hosted on that client system. Kerberos is supposed to be only used when you use Bonjour to discover the other machine. So primarily in peer to peer on the same LAN cases.
It works, you can see this for yourself. Screen share to another machine as a local user by picking the machine out of the sidebar in the Finder. You'll have to enter in your password the first time, but after that you can close out of that screen sharing session and restart it without having to re-enter your password. You can also see the ticket in the Kerberos.app, still buried in /System/Library/CoreServices."

Answer 1

Eric,
Thanks so much for your thoroughness and assistance. I think we have decided, for now, to forgo the 10.5 clients attaching to the 10.4 server because of too many intermittant issues. Similar machines on 10.5 gave different results. And at this point, our client is very skittish about the process working at all. I think we need more testing and that is the directon we'll take for now.
Here are some of our results:
I did find information on afp548 regarding the 10.5 preference. It was specificall referenced in this article:
http://www.afp548.com/forum/viewtopic.php?forum=18&showtopic=16064
Clearing the check box on the 10.4 server under OD > Settings > Security "Require password change on new user login" did solve the memory issue that kerberos was having. After clearing the setting, I:
* deleted all binding references at the server (WGM > Accounts > Lists > All Computers
* Deleted the bindings at the client and the the LDAP server references in Directory Access
* Restarted the machine
* Reconnected the LDAP server, Rebind the machine
* Check the LDAP search in issuing id <username> in Terminal
* OPen System PReferences > Accounts > Login Items, the preference is there!
* Yeehah
Oh, but the user still can't login in that machine. Uhm, why? I have no idea. I take a new machine, 10.5.1, no login accounts except a local admin, and no that user still cannot login. Other users, no problem, but not that user.
Take a new system, 10.4.11, set up the binding, the LDAP server, try to log in that same user: works every time. Ugh.
So of course, I think there is something up with that user, but nothing in logs gives an indication of what is going on. That I can find. THis is after 10 hours of testing and trying. Needless to state, the client is frustrated, and so am I.
You know, we do have one 10.5.1 client laptop that did work. After lots of binding and rebinding, it just somehow starting working as expected. But, the reason that we're sticking with 10.4 clients for now is that machine will not respond to password change mandates. I select that user in the WGM, check the "require password change on next login" and nothing happens on their end. They are not an admin, I have reset their account more times than I can count, and so I expect there are more non-working items with 10.5.1 clients and 10.4 server that will get me. It needs more testing for now.
So, back to your message, I haven't tried the SSL certificate, but I will give that a try.
In general, for your network, how are your laptop users configured? As mobile users? Network homes? Or Local homes?
Thanks again for your help. I really appreciate it.