[OpenAFS] [FOR TESTING] OpenAFS 1.3.85 RPMs for RHEL4 (i386, x86_64)

[ted creedon]

Chris,

There has apparently been a change in kadmim ktadd, it now prompts for -e
"keysaltlist"

It would be clearer it the prompt was "-e key:salt". 

MIT KRB5 V 1.4.1.

tedc
-----Original Message-----
From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org]
On Behalf Of Christopher Allen Wing
Sent: Friday, July 15, 2005 9:12 AM
To: ted creedon
Cc: openafs-info@openafs.org
Subject: Re: [OpenAFS] [FOR TESTING] OpenAFS 1.3.85 RPMs for RHEL4 (i386,
x86_64)

Ted,


On Fri, 15 Jul 2005, ted creedon wrote:

> You should try building aklog in the
> openafs source tree, not from the afs-krb5 source tree. Does that work?
> 
> >>>> No. In fact new make messages are being emitted stating that that 
> >>>> build
> step has been bybassed.


Did you enable krb5 when you ran ./configure?

You need to do something like:

 	./configure --with-krb5-config=/usr/kerberos/bin/krb5-config

(assuming that you are using MIT Kerberos 5, with a 'krb5-config' binary in
the given path)

I think that Heimdal also has a 'krb5-config' program, find out where it is
and it should work.


When you get the configure script to accept the krb5 stuff properly, aklog 
should build inside the openafs tree.


> >>>> There is also a bug in the sources preventing the
--enable-supergroups
> from compiling caused by
> >>>> an error in ptprocs.c: PT_LstGrps needs to be in quotes or added to
the
> .h file.

This is fixed in CVS.


> >>>> asetkey needs to be in the build tree if aklog is. Can't aklog
without
> asetkey and its not in the MIT krb5 sources.


There is 'setkey' in src/auth/setkey.c which you can use, and there is a 
copy of asetkey in src/WINNT.

I guess you should open a bug report in openafs-bugs@openafs.org if you 
want the unix asetkey as part of the standard build.


Anyway, asetkey is just a helper program that reads the key out of a 
keytab for you and writes it into the KeyFile automatically.

You can do it manually via

 	ktadd -k /some/keytab/file
 	klist -k -K -t /some/keytab/file

 	./setkey add <key value from klist> <kvno from klist>


Okay so maybe that's a little more involved :)


> >>>> Ken's README needs a small documentation mod: -e des-cbc-crc now
needs
> to be -e des-cbc-crc:normal

I believe that the salt type is irrelevant when you are using 'ktadd'; it 
only matters for keys derived from a password string. At least MIT krb5 
doesn't care if you do:

 	ktadd -e des-cbc-crc

it will create a random key with no salt. (which is what you expect since 
the key value is random, not the result of a hashed string)


> >>>> in kadmin.local: ktadd -k /etc/krb5.keytab -e des-cbc-crc:normal
> afs@YOUR.CELL.NAME
> >>>> Question: Not sure if afs@YOUR.CELL.NAME shouldn't be afs@YOUR.REALM.
> I.e. how do you get a token for cell "bigcell" at domain some.domain.com
> in realm SOME.DOMAIN.COM?


The preferred way to do this nowadays would be:

 	ktadd -k /some/keytab/file -e des-cbc-crc
afs/your.cell.name@YOUR.REALM


if you have more than 1 AFS cell which share a single Kerberos realm for 
authentication.


-Chris
wingc@engin.umich.edu
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info