[1478] in Kerberos-V5-bugs
Re: Problems with BETA5
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Thu Jun 15 14:43:57 1995
Date: Thu, 15 Jun 1995 14:42:56 +0500
From: Theodore Ts'o <tytso@MIT.EDU>
To: Ken Guyre <kguyre@cabell.vcu.edu>
Cc: krb5-bugs@MIT.EDU
In-Reply-To: Ken Guyre's message of Thu, 15 Jun 95 9:00:29 EDT,
<9506151300.AA08357@cabell.vcu.edu>
Date: Thu, 15 Jun 95 9:00:29 EDT
From: Ken Guyre <kguyre@cabell.vcu.edu>
I have loaded the BETA4 version of Kerberos5 on both our AIX 3.2.5
and Ultrix 4.3A systems with no problems. However when I went to
make the BETA5 version on our AIX systems, I found several problems.
We are currently working on getting Kerberos V5 working under AIX 3.2.5.
As you've discovered, there are a number of changes required to get
things working. Hopefully we'll be able to release a patch release soon
that will work under AIX.
I am also having the same problem as others running sclient on our
Ultrix system getting the "Server not found in Kerberos database"
message. Right now my realm is set up with the KDC on the AIX
system. I have the server running on both the AIX and Ultrix
systems. I can access the server on the AIX system from both clients
(AIX and Ultrix). However, when I try to access the Ultrix server
from the Ultrix client I get the "Server not found" error. When I
try to access the Ultrix server from the AIX client I get an error
message "Wrong principal in request".
Currently in Beta 5, the KDC logs its activities via syslog. (This will
be changed in future releases, so that you don't have to use syslog in
order to log to a file). Add a line in /etc/syslog.conf like this:
local6.info /usr/adm/krb5.log
And you will be able to see what sort of requests are being made of the
KDC.
In order to use sclient, you need to have created a key for
"sample/fully.qualified.domain.name.of.server@YOUR.LOCAL.REALM"
So if you want to run sserver on the host dcl.mit.edu, in the Kerberos
realm ATHENA.MIT.EDU, you must create a service principal with a random
key for "sample/dcl.mit.edu@ATHENA.MIT.EDU", and make sure that a srvtab
for that key is extracted and installed on dcl.mit.edu.
The "Wrong principal in request" *may* be caused by a resolver bug.
There's a program in src/tests/resolve that will hopefully smoke this
out. The problem is that some operating systems have thoughtly changed
the behavior of the resolver library, such that it is often hard to
obtain the fully qualified, canonical DNS name for a particular host.
Systems which are using Yellow Peril.... er, NIS, seem to be very prone
to this problem. (The bug is that you're using YP/NIS. Stop using it,
and your life will be much better. :-)
- Ted
