The hex format may does the good letting us find the exact missing or different field, though. It's concise and exact.
-----Original Message----- From: Zheng, Kai [mailto:[email protected]] Sent: Saturday, November 21, 2015 9:06 AM To: [email protected] Subject: RE: KDC is rejecting my TGS The text format might save us some time when just want to take a look from having a tool dump out from hex. I guess the text could be ok if it's made more compact? -----Original Message----- From: Emmanuel Lécharny [mailto:[email protected]] Sent: Saturday, November 21, 2015 7:04 AM To: [email protected] Subject: Re: KDC is rejecting my TGS Le 20/11/15 23:27, Zheng, Kai a écrit : > Marc, > > You detail looks pretty good. Thanks! > > From your observation I copied below, I thought all the differences should be > checked. The kvno (255 too large, bet 1) and principal name types for client > and server may be the causes that block you, but I'm not very sure. > For now, please set principal type manually, and would be good to provide the > similar comparing for the AS-REQ because that's the starting. I'm looking > into this. Thanks. > > The differences I see are: > 1. The authenticator from kerby PS-TGS-REQ has a kvno=255, java > doesn't have that attribute 2. Kerby has a cname section with the > name of the client, java's implementation does not 3. Kerby's SNAME > has a name-type of KRB5-NT-Principal where as java's is > KRB5-NT-Unknown 4. Kerby has a "from", java does not 5. Kerby's from > and till are real dates, Java's is expired What would be good is to provide the PDU as it's being transmitted, in Hex format. I must say it's easier for me to read such things than any other output.
