Server not found in Kerberos Database
Douglas E. Engert
deengert at anl.gov
Wed Jul 26 09:07:08 EDT 2006
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 <sayali_s_kulkarni at yahoo.co.in> sent:
>
>>Date: Wed, 26 Jul 2006 04:45:10 +0100 (BST)
>>From: sayali k <sayali_s_kulkarni at yahoo.co.in>
>>Subject: Re: Server not found in Kerberos Database
>>To: kneofyte <kneofyte at excite.com>, kerberos at mit.edu
>>In-Reply-To: <ea4ei9$bmr$1 at newswest.sybase.com>
>>
>>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 <kneofyte at excite.com> 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 mdw at DOGS.UMICH.EDU
> 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 Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
More information about the Kerberos
mailing list