Server not found in Kerberos Database

[Marcus Watts]

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