[OpenAFS] Debian - openafs -noauth problems

[Madhusudan Singh]

Hi

On Monday 15 August 2005 2:26 pm, Sergio Gelato wrote:
> * Madhusudan Singh [2005-08-15 13:26:45 -0400]:
> > My /etc/openafs/server/KeyFile was generated using asetkey from the
> > supplied keytab.
> >
> > How do I check what is going on there ?
>
> "asetkey list", or use Heimdal's ktutil (package heimdal-clients):
> 	ktutil -k AFSKEYFILE:/etc/openafs/server/KeyFile list
> But note that the latter fills in some information from other sources
> (and the Debian 3.1 version looks for krb.conf in /etc/openafs/etc,
> strace tells me; so don't take the ktutil output too seriously).
>

Thanks. I was able to use asetkey. However, I do not have access to the KDC in 
my case. So, how does one compare ?

> > Further, if I am able to authenticate and obtain tickets, should it not
> > just work from there on ?
>
> The key used by the KDC in issuing the ticket needs to be one that the
> service will accept. You don't know whether that's the case until you
> actually present the ticket/token to the service for authentication.

I do get a key (kinit) and a token (aklog). (Checked with klist and tokens). 
Shouldn't that pretty much settle this ?

>
> > My /etc/krb5.conf :
>
> [looks fine]

Ok.

>
> > You were making a reference to the enctypes earlier. Could above be a
> > part of the reason for my inability to work on the filesystem ?
>
> No. That list of permitted enctypes was fine. What is required (for now)
> is that the KDC always use a single-DES key when issuing AFS service
> tickets, since AFS doesn't support anything else. That's done in kadmin,
> by deleting unwanted enctypes from the AFS service key (and from that
> key alone; you most definitely should use stronger ciphers whenever
> possible). But since --- as you showed us --- your AFS tickets are
> single-DES, your problem lies elsewhere.

Ok.

>
> > > would not show up using -localauth but only when using token-based
> > > authentication; which means you can test it by issuing some vos
> > > commands on your server, both with -localauth and using an
> > > administrator's tokens. "vos create" and "vos remove" should be
> > > adequate for this test. A difference between "fs setacl /afs" and "vos
> > > create" is that the latter doesn't involve the /afs mount point; that
> > > should help draw the line between authentication on the one hand and
> > > afsd issues on the other.
> >
> > vos commands did work for me when I created the partition. But I believe
> > that I issued them while running bos under -noauth. Could that have
> > caused these problems ?
>
> Caused? No. Hidden? Yes, but then -localauth would hide them too.
>
> > omega:/etc# cat /etc/openafs/server/UserList
> > cat: /etc/openafs/server/UserList: No such file or directory
> >
> > Hmm.
>
> Indeed. "bos adduser omega <adminname> -localauth" should fix it.
> Hopefully that was your only remaining problem.

Done :

omega:~# bos listusers -server omega.admin.edu
SUsers are: <adminuser>

Still does not work. But good point - I had thought that after adding it to 
pts database, I was set.

omega:~# fs setacl /afs system:anyuser rl
fs: You don't have the required access rights on '/afs'