On Mon, Mar 03, 2008 at 09:40:25PM +0100, Mark Phalan wrote: > > On 3 Mar 2008, at 21:04, Will Fiveash wrote: > >> On Mon, Mar 03, 2008 at 08:39:51PM +0100, Mark Phalan wrote: >>> >>> On 3 Mar 2008, at 20:21, Will Fiveash wrote: >>> >>>> On Mon, Mar 03, 2008 at 01:43:40PM +0100, Mark Phalan wrote: >>>>> >>>>> On Fri, 2008-02-29 at 15:25 -0600, Will Fiveash wrote: >>>>>> >>>>>> Mark, I know this is a late response so you don't have to deal with it >>>>>> in this putback but don't you think, >>>>>> *Change Request ID*: 6245750 >>>>>> *Synopsis*: kadmin "Bad encryption type" error should state the >>>>>> enctype >>>>>> should also be a part of it? >>>>> >>>>> I think it could be, I took a look at this last night and came up with >>>>> the following: >>>>> >>>>> >>>>> Old behaviour: >>>>> >>>>> Mar 02 20:12:17 zup kadmind[2324](Notice): Request: >>>>> kadm5_randkey_principal, t at ACME.COM, Bad encryption type, >>>>> client=mark/admin at ACME.COM, service=kadmin at zup.czech.sun.com, addr= >>>>> (10.4.193.194) >>>>> >>>>> soe-280r-4# kadmin -p mark/admin -q "ktadd -k /tmp/t t" >>>>> Authenticating as principal mark/admin with password. >>>>> Password for mark/admin at ACME.COM: >>>>> kadmin: Bad encryption type while changing t's key >>>>> >>>>> >>>>> New behaviour: >>>>> >>>>> Mar 02 21:00:38 zup kadmind[11939](Notice): Request: >>>>> kadm5_randkey_principal, t at ACME.COM, Unknown encryption type: 18, >>>>> client=mark/admin at ACME.COM, service=kadmin at zup.czech.sun.com, addr= >>>>> (10.4.193.194) >>>>> >>>>> zup# ./kadmin -p mark/admin -q "ktadd -k /tmp/t p" >>>>> Authenticating as principal mark/admin with password. >>>>> Password for mark/admin at ACME.COM: >>>>> kadmin: Bad encryption type while changing p's key >>>>> kadmin: Encryption types requested: 18, 17, 16, 23, 3, 1 >> >> Can the client print the enctype names that it requested? I understand >> your point below that the server isn't sending the enctype(s) that it >> had problems with but the client should be able to map the enctypes it >> requested to names.
What do you think about my point above? >>>>> Unfortunately I don't think it would be trivial to have the client >>>>> print out the encryption type that caused the server to reject the >>>>> request. It would require that the server provide more >>>>> information than the error code when failing. This sort of change >>>>> would require a protocol change (I think). -- Will Fiveash Sun Microsystems Inc. Austin, TX, USA (TZ=CST6CDT)
