LKDC question

[maximumjack]

Hi,

today I had to rush out a couple of new laptops for deployment, and as I hadn’t finished creating my production Leopard image I just restored a (mostly) setup laptop to the new laptops using Disk Utility.
Now everything seemed to be fine, until I tried to bind the new laptops to my OD server (running 10.4.11). The first laptop was fine, and I was able to add it to one of my management groups, but when I went to bind the second laptop I was told that it was already bound to the server! It turns out that when doing authenticated binding with a Leopard client there are 3 entries made in the computer lists on the server:

1) laptopA$
2) laptopA.local$
3) LKDC:SHA1.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx$

and when I had done the cloning the local KDC had also been cloned and the LKDC:SHA value was the same.

So what I am wondering is how to easily recreate/rebuild the LKDC on a client machine so that it has a unique LKDC:SHA1…. value. I’m sure it’s something that I should be able to do with kadmin.local, but I’m in need of some guidance.

thanks in advance

paul

[crashdummy]

Well, If your still around, did you resolve this?

I’m having the same problem since applying the security patch
security Update 2008-002 v1.1 Server (leopard)

It bumped existing computers off OD, and when they rejoin, 2 new entries show up in computer accounts, one is the FQDN,( e.g., labtable6.physicslabs.uri.edu), the other is a Realm name (e.g. LKDC:SHA1.03344892C418CB16C250B59EAA7F93FEF79EF257.

Not only that, but in the list of principles in the Kerberos database, 2 entries for each machine are added to each service (e.g.,
afpserver/[email protected]
and
afpserver/LKDC:SHA1.03344892C418CB16C250B59EAA7F93FEF79EF257@CRASHDUMMY.PHYSICSLABS.URI.EDU.

The DNS is OK, I’m not sure what happened.

[s_groening]

The SHA1 value that’s found in the LKDC’s realm name comes from the self signed SSL computer certificate, that’s created during installation. Therefore this gets cloned along with the keychain as the image is used to restore another computer, and thus the LKDC’s realm name reflects that.

[Stephen Buckley]

Great, I’m relieved to get to the bottom of this, I have been tearing my hair out for the best part of a week trying to figure out what was happening with my clones.

But what is the solution? I’m seeing this with 10.5.3 clients on a 10.5.3 OD and cloning my machines using net boot images built on 10.5.3 server using System Image Utility and enabling options to change byhost prefs and set unique machine names, The resulting .nbi is hosted on my 10.4.11 Netboot server but I am hoping this is not a factor. Presumably Apple haven’t completely stymied anyone deploying systems from a static image and binding to a domain.

I am definitely seeing that the two default certificates in the system keychain are the same across clones and I would dearly like to know if there is a way of having the clones generate their own unique certificates, either using a postinstall script or by doing something to my build prior to imaging it. I presume that this would fix the problem at its root, but if I’m missing something here I’d appreciate some clarification.

I’d like to think the fix is as easy as deleting the certificates, or the system keychain itself and letting the OS rebuild them next boot but I doubt it will be that simple (and will probably cause something bad to happen). Any more intelligent suggestions would be most welcome.

Thanks for all contributors to this thread, I will sleep better tonight thanks to your figuring this out.

… For what it’s worth, I tried killing the system Keychain, and although it gets recreated it doesn’t get repopulated 😕 .

Stephen

EDIT:
updating with the results of my bad idea.

[crashdummy]

I disabled the local KDC as per Bombich see

http://forums.bombich.com/viewtopic.php?t=11834&highlight=kerberos

I used the sso_util to remove it.

[Stephen Buckley]

Thanks, I think I’m going to try changing my imaging methodology and use InstaDMG, as it looks like the way forward and a good way of maintaining several builds forked off of a central base.

I am hoping the fact it appears to run the OS Installer on each imaging will avoid this problem be creating a new unique local kerberos realm each time… but if it doesn’t that is a hot tip!

Thanks again,
Stephen 😀

[Stephen Buckley]

Follow up, for those who are interested.

Well I had some time to investigate this further, Ive been playing with instaDMG and my testing (although I’d like to test it a bit more thoroughly to make sure) seems to confirm that it solves the problem with systems building with unique com.apple.systemdefault and com.apple.kerberos.kdc certificates in the system keychain.

However the excellent thread at: [url]http://forums.bombich.com/viewtopic.php?t=11834&highlight=lkdc[/url] I was referred to by crashdummy has a few solutions and good discussion, however one post from “beamsjr” in particular might prove to be useful. Particularly for anyone with a bunch of machines they have just imaged with a monolithic 10.5 image and now found are causing duplicate problems when they try and bind them to the OD.

I’ll include it here for completeness and possibly to save someone time in future

[quote]

The LKDC:SHA1 entry is from the local KDC certificate in 10.5. Under Leopard they run a local KDC for use with peer-to-peer authentication, and there’s a certificate generated for com.apple.kerberos.kdc on the client. The SHA1 hash is the hash of that certificate, and it’s created during the setup of the local KDC.

Here is a workaround:

1) In the Utilities folder, open Keychain Access. In the System keychain, find and delete the three com.apple.kerberos.kdc entries – a certificate and a public/private key pair generated from that certificate.
2) In Terminal, run ‘sudo rm -fr /var/db/krb5kdc’ – this will destroy the local KDC database.
3) In Terminal, run ‘sudo /usr/libexec/configureLocalKDC’ – this will regenerate the local KDC database, including a new certificate and SHA1 hash.
4) Bind the machine to OD.

[/quote]

I think I’ve got answers to my original question and much more now! Many thanks to crashdummy for pointing me to the bombich forums and to everyone else in this thread.
Stephen

[crashdummy]

Glad to help 😀

[mcclint]

“Here is a workaround:

1) In the Utilities folder, open Keychain Access. In the System keychain, find and delete the three com.apple.kerberos.kdc entries – a certificate and a public/private key pair generated from that certificate.
2) In Terminal, run ‘sudo rm -fr /var/db/krb5kdc’ – this will destroy the local KDC database.
3) In Terminal, run ‘sudo /usr/libexec/configureLocalKDC’ – this will regenerate the local KDC database, including a new certificate and SHA1 hash.
4) Bind the machine to OD.”

I can confirm that those steps work in 10.6.4 to fix the problem.

[Author]

Posts