[OpenAFS] Kerberos 5, AFS, and no krb524d

[Douglas E. Engert]

Nicholas Henke wrote:
> 
> On Mon, 2003-06-09 at 14:19, Douglas E. Engert wrote:
> > Nicholas Henke wrote:
> > >
> > > On Mon, 2003-06-09 at 11:59, Douglas E. Engert wrote:
> > > > I think you are asking if the ak5log I have can run with the standard
> > > > Kerberos krb524 lib and krb524d.
> > >
> > > Sorry for the confusion -- yes that is what I was asking.
> > > I have gotten ak5log to compile and run -- and it appears to be
> > > succeeding.
> >
> > Was this with afs/<cell>@<realm> or with afsx/<cell>@<realm>?
> 
> afs/roughneck.liniac.upenn.edu@UPENN.EDU -- note that this works for
> aklog as well as your ak5log.
> >
> > Is this just an admin problem?
> >
> > Does it work with an ordinary user?
> 
> I am not sure -- I have not been able to even setup the toplevel of the
> /afs space. So far it is just an admin problem.
> 
> >
> > You are trying to use a multipart user name, which might be making it harder.
> > If you had a principal like henkeadmin@<realm> and gave the AFS user henkeadmin
> > all privilages and listed it in /usr/afs/etc/UserList, I think that would work.
> > (Each of our AFS admins has his own account so we dont have a shared afsadmin.)
> 
> This would just include the membership in system:administrators and bos
> adduser ? I have done this for my regular username:
> 
> [root@roughneck etc]# bos adduser roughneck.liniac.upenn.edu henken
> -cell roughneck.liniac.upenn.edu -noauth
> 
> [root@roughneck etc]# pts createuser -name henken -cell
> roughneck.liniac.upenn.edu -noauth
> User henken has id 2
> 
> [root@roughneck etc]# pts adduser henken system:administrators -cell
> roughneck.liniac.upenn.edu -noauth
> 
> [root@roughneck etc]# pts membership henken
> libprot: a pioctl failed Could not get afs tokens, running
> unauthenticated.
> Groups henken (id: 2) is a member of:
>   system:administrators
> 
> After this I stop the running bosserver -noauth, kill it and start afs.
> 
> enken@roughneck henken $ klist
> Ticket cache: FILE:/tmp/krb5cc_27659
> Default principal: henken@UPENN.EDU
> 
> Valid starting     Expires            Service principal
> 06/09/03 14:26:30  06/10/03 00:26:27  krbtgt/UPENN.EDU@UPENN.EDU
> 
> Kerberos 4 ticket cache: /tmp/tkt27659
> klist: You have no tickets cached
> henken@roughneck henken $ aklog -d
> Authenticating to cell roughneck.liniac.upenn.edu (server
> roughneck.liniac.upenn.edu).
> We've deduced that we need to authenticate to realm UPENN.EDU.
> Getting tickets: afs/roughneck.liniac.upenn.edu@UPENN.EDU
> About to resolve name henken to id in cell roughneck.liniac.upenn.edu.
> Id 2
> Set username to AFS ID 2
> Setting tokens. AFS ID 2 /  @ UPENN.EDU

Also do a klist and tokens commands after to see what else has changed.

But this looks strange, I would have expected it to say:

  Setting tokens. AFS ID 2 /  @ roughneck.liniac.upenn.edu

I would expect the cell name here, not the K5 realm name.
 But you are running the aklog and the unmodified krb524 code. Our code in 
ak5log and in the conv_princ.c would have done this:  

!  *
!  * If the client is in the same K5 realm as this server, then this
!  * K5 realm is considered to be able to hand out tickets for the
!  * AFS cell(s). We need to make it look like to AFS that the user
!  * is in the AFS cell, so we set the clients prealm to match the
!  * AFS cell name. But we don't want to do this if the client
!  * is not in the same K5 realm, since AFS does some cross cell
!  * authentication, and this would violate that. The user should
!  * still look like he is in the foriegn K5 realm.
!  */
!      if (!strcmp(sname, "afsx")) {
!        if (!strcmp(prealm, dummy))
!          strcpy(prealm, sinst) ;
!         strcpy(sname,"afs");
!         *sinst = '\0';
!        *afsflag = 1; /* set that this is AFS and princ was changed */
!      } else
! #endif /* AFS524 */
!      *afsflag = 0; /* with or without the AFS524, set to zero */
!      return(0);
  } 


> 
> henken@roughneck henken $ bos listusers roughneck.liniac.upenn.edu
> SUsers are: afsadmin.roughneck.liniac.upenn.edu henken
> 
> henken@roughneck henken $ bos listkeys roughneck.liniac.upenn.edu
> bos: you are not authorized for this operation error encountered while
> listing keys
> 

You need a token for oner of the people on the SUsers list above. 


> >
> > If you must use the multpart name, I don't think it gets converted
> > like you might want. The krb524d appears to eventially call the
> > krb5_524_conv_principal routine, and I don't see afsadmin listed.
> 
> What other information can I provide ? It seems like I get the same
> errors regardless of the use of ak5log over aklog or vice-versa. They
> seem to be hitting the same problem.
> 
> Nic
> --
> Nicholas Henke
> Penguin Herder & Linux Cluster System Programmer
> Liniac Project - Univ. of Pennsylvania

-- 

 Douglas E. Engert  <DEEngert@anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444