[OpenAFS] Re: OpenAFS and AD trusts

[Danko Antolovic]

Well yes, the group system:authuser@iu.edu does exist:

[root@afs1c afs]# pts  listentries -groups  -noauth
Name                          ID  Owner Creator
system:administrators       -204   -204    -204
system:backup               -205   -204    -204
system:anyuser              -101   -204    -204
system:authuser             -102   -204    -204
system:ptsviewers           -203   -204    -204
system:authuser@iu.edu      -207   -204       2

Also, system:authuser@iu.edu was created by 2, which is me as admin, so 
it was there before my aklog as foreign user.  Is the foreign-realm 
group something that needs to be set in advance, or is that part of the 
automatic registration thing?

And yes, as foreign user dantolov@iu.edu, I lack the "rlidwka" rights to 
the cell directory /afs/afs1.bedrock.iu.edu.  All I can do is "rl"

Danko

Andrew Deason wrote:
> On Thu, 15 Sep 2011 11:10:40 -0400
> Danko Antolovic <dantolov@indiana.edu> wrote:
>
>   
>> However, this does not let me touch the files in the cell. Trying to
>> add the foreign-realm group to the directory ACL, like this:
>>
>> [root@afs1c afs]# fs  setacl -dir  /afs/afs1.bedrock.iu.edu  -acl 
>> system:authuser@iu.edu  rlidwka
>>
>> does not seem to work, and just adds the group system:authuser to the 
>> ACL once more:
>>     
>
> To be clear: this is supposed to work (and does for me, here). Have you
> been changing around the names or IDs of these groups?
> system:authuser@id.edu doesn't appear to exist anymore.
>
> This would suggest something along the way is screwing up the id<->name
> mapping, but that may not necessarily prevent the actual access from
> working. Are you actually lacking those rights? (that is, when trying to
> do one of those operations)
>
> You can look at a network dump to verify what names are going across the
> wire, to see if the setacl and listacl requests are what you think
> they are. You don't need to be familiar with the protocol or anything;
> it should be pretty easy to see where the acl data is (it is transmitted
> in the clear, when 'fs crypt' is turned off).
>
>