Greetings all: 


> A-ha, now I see what the problem is.

Excellent!  What is the problem?  :p 


>> sandbox1# /vice/bin/pdbtool list
> 
> Is this the whole output? Note that "pdbtool list" may be not reliable,
> it does not necessarily output the whole database (not big databases
> anyway). The reliable way to examine the whole contents is
> "pdbtool export".

Our database is tiny.  I ran pdbtool export and it shows the same data (in 
/etc/passwd,group format).  The key to understand, is that there is no ID 
484.  Here's the parsed down output (if you want me to send the full output 
privately, I can do that): 

codaadmin:*:83886:500::/:
codauser:*:83896:500::/: 

System%Administrators:*:-1:realmadmin,codaadmin
System%AnyUser:*:-2:System
GROUP%codauser:*:-8:codauser 

>> sandbox4# cunlog @coda.realm; clog admin -keytab admin-krb5.keytab; ctokens 
>> @coda.realm 
> 
> Another remark, it would help a lot if you use "clog account_at_realm",
> otherwise you implicitely refer to your clog config, which is
> an additional source of possible errors.

Ok, no change: 

sandbox4# cunlog @coda.realm; clog codauser_at_coda.realm -keytab 
~/.codafs/clog/krb5.keytab; ctokens @coda.realm 

Tokens [local user id: root] 

   @coda.realm
       Coda user id:    484
       Expiration time: Thu Mar  4 23:12:46 2010 


>> sandbox4# cunlog @coda.realm; clog user -keytab user-krb5.keytab; ctokens 
>> @coda.realm 
> 
> What is "user" ??? (see my remark above)

maps to codauser_at_coda.realm 


> 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. 


> Note that in a multiserver realm clog may talk to any of the
> authentication servers. Have the servers (if multiple)
> synchronized data?

Not applicable.  There is only one for simplicity of testing. 


>> Logged in as coda admin, IDs match and everything works.  Logged in
>> as any other coda user, and IDs do NOT match, and cannot access
>> anything. 
> 
> This is odd.

I'd hate to waste your time with anything less. 


> Does it happen even if you use Coda password authentication?

Yes.  I don't have the output handy on that one, but there's no change. 

Even if it didn't, as you said, coda's IDs are internal to itself.  It would 
do nothing to answer the question of where coda is getting ID 484. 


FYI:  I tried issuing a /vice/bin/codaservice stop/start on the coda server, 
and cunlog/clog/ctokens on the coda client, and still have ID 484 in both 
token and AuthLog. 


Very much waiting for assistance on this one. 

Thanks,
 -Don
{void}