Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) X-RT-Original-Encoding: iso-8859-1 Content-Length: 4968 From mdw@umich.edu Mon Dec 17 23:41:49 2001 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by rt-11.mit.edu (8.9.3/8.9.3) with ESMTP id XAA23359 for ; Mon, 17 Dec 2001 23:41:49 -0500 (EST) Received: from quince.ifs.umich.edu (quince.ifs.umich.edu [141.213.229.138]) by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id XAA03032; Mon, 17 Dec 2001 23:41:12 -0500 (EST) Received: from pepper-pot (pepper-pot.ifs.umich.edu [141.213.229.91]) by quince.ifs.umich.edu (8.6.13/8.6.12) with ESMTP id XAA10816; Mon, 17 Dec 2001 23:40:59 -0500 Message-Id: <200112180440.XAA10816@quince.ifs.umich.edu> Date: Mon, 17 Dec 2001 23:40:59 -0500 From: Marcus Watts To: Jin Zhou Cc: kerberos@mit.edu, krb5-bugs@mit.edu, mdw@quince.ifs.umich.edu In-Reply-To: Your message of "Mon, 17 Dec 2001 20:01:02 PST." <3C1EBF7E.A9C0A89B@gene.com> Subject: Re: Bug with Kerberos 1.2.2 for 64 bit HPUX 11 !? >Number: 1029 >Category: pending >Synopsis: Re: Bug with Kerberos 1.2.2 for 64 bit HPUX 11 !? >Confidential: yes >Severity: serious >Priority: medium >Responsible: gnats-admin >State: open >Class: sw-bug >Submitter-Id: unknown >Arrival-Date: Mon Dec 17 23:42:01 EST 2001 >Last-Modified: >Originator: >Organization: >Release: >Environment: >Description: >How-To-Repeat: >Fix: >Audit-Trail: >Unformatted: Jin Zhou writes: > Message-ID: <3C1EBF7E.A9C0A89B@gene.com> > Date: Mon, 17 Dec 2001 20:01:02 -0800 > From: Jin Zhou > To: kerberos@mit.edu, krb5-bugs@mit.edu > Subject: Bug with Kerberos 1.2.2 for 64 bit HPUX 11 !? > > Hi: > > I compiled Kerberos 1.2.2 on HPUX 11.00 with "+DD64" flag passed to > cc compiler, which means all > the binaries will be in 64 bit format. > > Everything so far works fine except for /usr/local/sbin/kadmin. Here > is what happens when I run kadmin > trying to connect to a kadmind & krb5kdc running on another Unix box: > % > % /usr/local/sbin/kadmin > Authenticating as principal user1/admin@TEST.COM with password. > Enter password: > kadmin: GSS-API (or Kerberos) error while initializing kadmin > interface > % > > In KDC's /var/log/kadmin.log file, I can see that (xxx is the > machine's IP address): > kadmind[4342](Notice): Authentication attempt failed: xxx.xxx.xxx.xxx, > GSS-API error strings are: > kadmind[4342](Notice): A token was invalid > kadmind[4342](Notice): Token header is malformed or corrupt > kadmind[4342](Notice): GSS-API error strings complet > > I did some troubleshootings, finally the problem being traced back > to system call "clnt_call()" around line #287 in > ./Kerberos/src/lib/rpc/auth_gssapi.c where "call_res" gets its value by > calling "clnt_call()". The program exit around line #329 when the value > of "call_res.gss_major" is checked and found invalid. > > The interesting part is that I'm not sure whether this is a bug in > HPUX 11 64 bit RPC library or a bug with Kerberos 122. Because > clnt_call() actually returns "RPC_SUCCESS" as exit code, but yet gets > invalid value for "call_res.gss_major". > > Can somebody who runs 64 bit Kerberos on HPUX 11 test whether kadmin > works or not ? My KDC has no problem, because we can run kadmin from > other (SGI, SUN, HPUX10.20) Kerberos systems without any problem. > > If this is a bug, then just treat my message a bug report. > > Thanks > > Jin > ----------------------------------- Most likely, your client is generating defective data, which the server is detecting, then returning an error. The client side error message "GSS-API (or Kerberos) error while initializing kadmin" is pretty much the catch-all, means little in itself (except that you are in for much drudgery). All of this is below the RPC code, in the gssapi layer of things, so you probably shouldn't need to worry about what clnt_call is thinking. At least in theory. The server side errors are actually more useful. Those errors probably actually come from kadmind not from kdc. The useful manifests are GSS_S_DEFECTIVE_TOKEN = A token was invalid G_BAD_TOK_HEADER = Token header is malformed or corrupt Mapping the "useful" english text that gssapi prints out, to the actual manifests in the code, is one of the challenges that this code presents. G_BAD_TOK_HEADER can only be generated by the routine g_verify_token_header in lib/gssapi/generic/util_token.c . You'll probably have to step through kadmind, dump out the data as it passes through this routine, and compare it with a "good" kadmind run from a connection with a 32-bit client to to see what's wrong. Probably there is some sort of 64-bitness that caused the client to generate bad data... You may also need to step through the client side that is generating this code, and compare that as well. -Marcus Watts UM ITCS Umich Systems Group