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' _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
