>> >What does your /vice/auth2/AuthLog say at the time of clog? 
>> 
>> 18:13:01        vid = 83886
>> 18:13:01 AuthNewConn(0x7da9cdba, 0, 66, 2, 83886)
>> 22:11:47        vid = 484
>> 22:11:47 AuthNewConn(0x72199dd5, 0, 66, 2, 484)  
>> 
>> Where is coda getting this ID?  Clearly it believes there is a 484, but 
>> executing:  pdbtool export /tmp/file1 /tmp/file2; grep 484 /tmp/file?
>> results in null output. 
> 
> It is Kerberos who produces the account name from the ticket the auth
> daemon acquires with the help of the data sent by the client. If Kerberos
> would happen to produce a string "484", then the suthentication daemon
> takes it literally and transforms to the numerical id.

I can't be understanding this correctly, am I?  Because my kerberos user has 
the string "484" in it, which it does (along with a few other numbers), coda 
mangles the coda _UID_ to match this random string in the kerberos 
_username_?  Wouldn't it make a touch more since to simply use the coda UID 
as the coda UID? 

This cannot be the desired behavior, is it? 


> To make it easier to analyze I wouls ask you to make the corresponding
> clog using Coda password. You do not have to change anything in the
> setup, just create a password for an account and tell clog to use the
> codapassword method.

Nor use the codaauth service, I should think (nor perhaps even the DNS SRV 
records?).  So noted for the future, but not needed now.  I have confirmed. 

It is as you suspected.  As based on the above:  If there is a number in the 
kerberos username, coda drops it's internal coda UID in favor of the first 
integral number fragment in the kerberos username.  This, of course, munges 
authentication and the associated ACLs that have been based on the _actual_ 
internal coda UID. 

I've updated my random username generation algorithm to avoid numbers to 
work around this behavior and, low and behold, no more issue. 


I cannot thank you enough for your assistance.  I simply don't know that I 
would have ever stumbled upon that correlation.  Certainly not soon enough, 
at any rate. 


Regards,
 -Don
{void}