Rainer Sch�pf wrote:
On Mon, 11 Oct 2004, Derrick J Brashear wrote:
> Jeff Altman explained why in the RT ticket you opened; Basically, "because > it can lead to 2 principals being treated as the same one".
Fair enough. A minor annoyance only. It was my bad luck that I did my first test with the wrong principal. (Although I still think that aklog or ktc_Settoken should give an error message for a principal with a "." in its name.)
I can certainly add a check for this in the Windows aklog.
However, the Unix aklog does not ship with OpenAFS and therefore it would be impossible for OpenAFS to make this change.
However, a not so minor annoyance is the lack of documentation. There is not much on 2b tokens, and I could not find anything about these pitfalls. In particular, the Unix specific documentation says very little about Kerberos 5 integration, if at all.
I think a sort of "best practices" document is needed. I'll try to write something down in the near future.
This is partly because the Kerberos 5 integration work is still in progress. Partly it is because of a lack of volunteers to write
documentation.
> Until the pts suite has been modified and we are using true krb5 > everywhere (or at least in the code path where such check happens) this > will not be removed.
So the first step would be to modify the pts suite. Is this something to happen soon? Just asking.
It would happen sooner if there were more resources available to the OpenAFS community. As long as getting the work done is dependent on a small number of highly over allocated individuals it is going to be slow going.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
