Wrong user name for network connection

[Axel Luttgens]

Le 21 avr. 08 à 23:38, Bill Cheeseman a écrit :

> on 2008-04-21 11:45 AM, Axel Luttgens at luttgens at fusl.ac.be wrote:
>
>> Are the two boxes involved in the "phenomenon" running (almost)  
>> 24/24?
>
> Yes.
>
>> And are they both Leopard ones?
>
> Yes. [...]
>
>> If yes, perhaps is this a kerberos thing.
>> What does /System/Library/CoreServices/Kerberos.app show?
>
> Lots of long numbers and other obscure information bearing no obvious
> relationship to this issue. When I click the Get Info button on the  
> ticket,
> one of the things I see is "Status: Valid".

Hello Bill,

This definitely seems to be a kerberos thing.

Thanks to your question, I've had the opportunity to get somewhat  
acquainted with .Mac accounts by creating one for myself and adding it  
to my user account.
This has resulted in various pieces stored in my keychain, among them  
a ".Mac Sharing Certificate", as well as some data created in or  
appended to my user record:
(new)	LinkedIdentity: a plist defining the .Mac user name
(new)	UserCertificate: <seems to be a copy of the ".Mac Sharing  
Certificate">
(added)	AuthenticationAuthority: an additional kerberos authentication  
source, the principal
	being the above certificate's SHA1 fingerprint.
(added)	RecordName: the .Mac full name and the SHA1 fingerprint
Moreover, a principal for the identity bound tho that fingerprint is  
added to the "principal.LKDC" file in /var/db/krb5kdc.

Now, the interesting thing appears when adding the same .Mac account  
on some user account on another box, and to enable AFP on that box.
The same kind of data creation/addition will happen; in particular,  
the same .Mac Sharing Certificate will be used to fill that user  
account.
As a result, each box now knows about some user bearing the SHA1  
fingerprint as one of its short names.

Enters what seems to be a Finder built-in behavior.
When clicking on the second box's icon in the sidebar, it seems that a  
connection will first be attempted under the .Mac identity (with the  
SHA1 fingerprint); then, because:
	that name is known by the remote box too,
	the .Mac password has been stored in the keychain (on both boxes),
	the AFP service is kerberized,
a connection will succeed, and a ticked will be generated/received and  
displayed in Kerberos.app; the user's principal will be of the form:
	<SHA1 fingerprint>@LKDC:SHA1...
hence those "lots of long numbers".

I'm sure missing a lot of things, after only such a quick look.  
Anyway, could you confirm this is the kind of behavior you are facing  
with your "rogue" machine?

Axel