Ethereal can parse the Kerberos packets. Its a lot easier they trying to decode them youself. You can run it on Windows or Unix, and it can take a tcpdump file as input.
http://www.ethereal.com/ Marcus Watts wrote: > sayali k <[EMAIL PROTECTED]> sent: > >>Date: Wed, 26 Jul 2006 04:45:10 +0100 (BST) >>From: sayali k <[EMAIL PROTECTED]> >>Subject: Re: Server not found in Kerberos Database >>To: kneofyte <[EMAIL PROTECTED]>, [email protected] >>In-Reply-To: <[EMAIL PROTECTED]> >> >>Hi Neo, >> Thanks for the reply, >> When I am trying to do a kinit on the client, I am getting this error. Ho= >>wever, I have no idea of the log files on the KDC (which I assume should be= >> on the AD server). = >> >> I found out that this error was eliminated when i tried to rename the cli= >>ent machine. e.g. I had the name of the client as test1.mydomain.com and no= >>w i changed it to test2.mydomain.com. >> Can you please help in exactly pinpointing why this could have happened? >> = >> >> Thanks for all the help, >> Regards, >> Sayali >> >>kneofyte <[EMAIL PROTECTED]> wrote: >> = >> >> >>>Hi all, >>>When do we get the error as "Server not found in Kerberos Database"? >>>I have a KDC on Win2003 and a client which is a Linux (redhat) is trying = >> >>to authenticate the users from this Active directory, which is on the win 2= >>003 machine. = >> >> >>>I observed that in case we specify the wrong user name (which does not ex= >> >>ist on the AD server) at the time of kinit command on Linux machine we get = >>the error as "Client not found in Kerberos database". = >> >> >>>What is this server which is not found when I am trying to join the redha= >> >>t client machine to the AD server? >> >>>= >> >> >>What command are you running when you get that message? Are you trying = >> >>to extract the server principal onto a keytab? Can you show your KDC log = >> >>file? >> >>-Neo > > > If you don't have access to your KDC logs (presumably on your AD machine) > then you need to find another way to figure out what your client software > is doing. Simplest is probably "tcpdump" - if you use this right, you can > get most of the information you'd get from your KDC, but with a lot more pain. > (You can also learn things you can't from the KDC, like where you're > really going if you're talking to the wrong KDC.) > > On your client machine, in one window, > tcpdump -s 1500 -x -n -p udp port 88 > then run kinit > if all goes well, you'll see at least 2 packets going back & forth. > All the information you need is right there, encoded in hexadecimal. > > Not sure where the udp header stops & the kerberos payload starts? > Can't decode hexadecimal to asn.1 in your head? > Then read this message: > http://lists.openafs.org/pipermail/openafs-info/2006-March/021789.html > I describe there in somewhat gruesome detail how to use > perl to convert the hex to "pem", followed by "openssl asn1parse -i -dump" > to convert the pem encoded data to human readable text. You may also > find it handy to have a copy of RFC 4120. > > Here are some important things you can learn doing this: > > client principal name on behalf of which you're acting. > kerberos realm & server you're actually using. > service principals for which you are attempting to acquire a ticket. > ( "Server not found in Kerberos Database" = the > service principal isn't actually there. ) > wire error code and a possible english gloss for the error code. > > The above should suffice for diagnosing "kinit" problems. You say you > are attempting to "join" an AD forest, and that the problem changed > when you changed the client machine, but somehow omitted describing > what software you were using at that point. That's probably not just > kinit. If you have such software, you might be able to use "strace" to > good effect on whatever tool it is - something not quite like: > strace -s 16384 -ttt -f -o /tmp/kinit.out kinit [EMAIL PROTECTED] > any asn.1 in this output won't be any easier to read, but the strings > should by default contain any recognizable ascii, so you can probably > make a good enough guess as to client & server principals, error codes, > etc., were passed. For this task, the tool you use needs to use > whatever administrative protocol AD supports to create a host principal > & save the accompanying keytab to local disk. Then you would use > something (presumably samba) to use that keytab to access microsoft > services. With AD, you might need to run "ktpass.exe" on a windows > machine then copy the resulting keytab to linux to accomplish this > effect; you may not have any tools in the linux world that can do this > with AD directly. > > -Marcus Watts > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos > > -- Douglas E. Engert <[EMAIL PROTECTED]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
