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. >>> 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). >> >> Okay. Certainly that's an improvement on the client side. Do you know >> what the kadmind is loggin? If that is also terse that could also be >> improved I bet. > > > Actually I included the kadmind output as well... Here it is again: Hah, as you can tell, I'm out of it today (long night last night). > Old: > > 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) > > New: > > 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) > > > Basically it replaces "Bad encryption type" with "Unknown encryption type: > 18". (Of course it's 18 just for this example). Seems clearer to me. -- Will Fiveash Sun Microsystems Inc. Austin, TX, USA (TZ=CST6CDT)
