[OpenAFS-devel] aklog and heimdal
Martin MOKREJŠ
mmokrejs@ribosome.natur.cuni.cz
Fri, 17 Feb 2006 23:34:46 +0100
That's true, ktutil distributed with heimdal is perfectly sufficient
for key creation/move. I think I have updated the afs admin wiki
pages about this. As a brief hint, few emails with my communication
in "Love" who develops the stuff. Might help someone browsing the
archives. Please note those improvements/fixes were introduced after
heimdal-1.7 or maybe just in some release candidates around 1.7 release.
Derek Atkins wrote:
> Jim Rees <rees@umich.edu> writes:
>
>
>>Rev 1.3 of asetkey.c breaks the build on heimdal, but then I think it was
>>already broken.
>
>
> asetkey isn't necessary with Heimdal, so I don't think it really
> matters.
>
> -derek
From: Love <lha@stacken.kth.se>
Martin MOKREJŠ <mmokrejs@xxxxxxxx.cz> writes:
>> Hi Love,
>> doesn't this work. I think this used to work, but ktutil manpage
>> doesn't mention AFSKEYFILE at all. Should be updated.
I'll deal with this later.
>> How am I supposed to copy the keys? BTW: Which enctypes should I
delete
>> on kdc or which should I export into keytab and recopy into KeyFile?
>> Thanks for help
Probably the file /usr/vice/etc/ThisCell that is missing, I've
included the
info documentation in current heimdal. Hope that helps.
Love
AFS
===
AFS is a distributed filesystem that uses Kerberos for authentication.
For more information about AFS see OpenAFS <http://www.openafs.org/>
and Arla <http://www.stacken.kth.se/projekt/arla/>.
How to get a KeyFile
--------------------
`ktutil -k AFSKEYFILE:KeyFile get afs@MY.REALM'
or you can extract it with kadmin
kadmin> ext -k AFSKEYFILE:/usr/afs/etc/KeyFile afs@MY.CELL.NAME
You have to make sure you have a `des-cbc-md5' encryption type since
that is the enctype that will be converted.
How to convert a srvtab to a KeyFile
------------------------------------
You need a `/usr/vice/etc/ThisCell' containing the cellname of you
AFS-cell.
`ktutil copy krb4:/root/afs-srvtab AFSKEYFILE:/usr/afs/etc/KeyFile'.
If keyfile already exists, this will add the new key in afs-srvtab to
KeyFile.
Using 2b tokens with AFS
========================
What is 2b ?
------------
2b is the name of the proposal that was implemented to give basic
Kerberos 5 support to AFS in rxkad. Its not real Kerberos 5 support
since it still uses fcrypt for data encryption and not Kerberos
encryption types.
Its only possible (in all cases) to do this for DES encryption types
because only then the token (the AFS equivalent of a ticket) will be be
smaller than the maximum size that can fit in the token cache in
OpenAFS/Transarc client. Its so tight fit that some extra wrapping on
the ASN1/DER encoding is removed from the Kerberos ticket.
2b uses a Kerberos 5 EncTicketPart instead of a Kerberos 4 ditto for
the part of the ticket that is encrypted with the service's key. The
client doesn't know what's inside the encrypted data so to the client
it doesn't matter.
To differentiate between Kerberos 4 tickets and Kerberos 5 tickets 2b
uses a special kvno, 213 for 2b tokens and 255 for Kerberos 5 tokens.
Its a requirement that all AFS servers that support 2b also support
native Kerberos 5 in rxkad.
Configuring a Heimdal kdc to use 2b tokens
------------------------------------------
Support for 2b tokens in the kdc are turned on for specific principals
by adding them to the string list option `[kdc]use_2b' in the kdc's
`krb5.conf' file.
[kdc]
use_2b = {
afs@SU.SE = yes
afs/it.su.se@SU.SE = yes
}
Configuring AFS clients for 2b support
--------------------------------------
There is no need to configure AFS clients for 2b support. The only
software that needs to be installed/upgrade is a Kerberos 5 enabled
`afslog'.
Martin MOKREJŠ <mmokrejs@xxxxxxxx.cz> writes:
>> Great. afslog(1) manpage doesn't say that afslog looks for
>> afs@REALM and if not found, for afs/cellname@REALM.
You can see what afslog tries to do by using "afslog -v"
>> Does that means they are equivalent somehow?
>>
>> Do they have to hame same key and kvno?
No, they can be diffrent, its used then you "piggyback" a second
cell to a already existing kerberos realm. For example:
Kerberos realm NADA.KTH.SE have to cells: nada.kth.se and pdc.kth.se.
nada.kth.se uses afs@NADA.KTH.SE
pdc.kth.se uses afs/pdc.kth.se@NADA.KTH.SE
I'll write some text about this and add it to the documentation, but
it have to be later. I'll be busy next week.
>> What happens if admin is messy and once had create both with two
>> different random password, but say the latter has extracted into
>> KeyFile?
Then bad things happen.
>> Is that true /usr/afs/etc/KeyFile can hold several keys? So one
>> could store into it afs@REALM and later afs/cellname@REALM?
It can hold several kvno's of key, but it only hold one principal
(the principal for the cell). In fact it doesn't know that principal
is it, if the key decryptes the kerberos message, it all happy.
>> Improving ktutil(1) woul help users to figure out what's
>> contained in the file, especially kvno and enctype. bos(1) from
>> openafs isn't much informative. :( And while you have the
>> routines to write the file, you probably can also diplay it. ;)
>>
>> # ktutil -k /usr/afs/etc/KeyFile list
>> ktutil: krb5_kt_start_seq_get /usr/afs/etc/KeyFile: Unsupported
>> key table format version number
>> #
Try ktutil -k AFSKEYFILE:/usr/afs/etc/KeyFile list
Love
Martin MOKREJŠ <mmokrejs@xxxxxx.cz> writes:
>> d313base root # ktutil -k AFSKEYFILE:k4 list
>> AFSKEYFILE:k4:
>>
>> Vno Type Principal
>> 1 des-cbc-md5 afs/biomed.cas.cz@BIOMED.CAS.CZ
>> d313base root # ktutil -k AFSKEYFILE:k5 list
>> AFSKEYFILE:k5:
>>
>> Vno Type Principal
>> 1 des-cbc-md5 afs/biomed.cas.cz@BIOMED.CAS.CZ
>> ----------------------^^^^^^^^^^^^^ the original key was
>> afs@BIOMED.CAS.CZ !!!
>> d313base root #
>>
>> d313base root # /usr/athena/sbin/ksrvutil list
>> Version Principal
>> 1 afs@BIOMED.CAS.CZ
>> d313base root #
The problem is that the AFSKEYFILE code doesn't know the principal
because its not in the file. So it has to guess, and in your case,
it guesses wrong.
Don't worry that the strings doesn't match.
Love