Skip Menu |
 

Download (untitled) / with headers
text/plain 8.1KiB
From benjid@media.teamnet.net Thu Aug 28 12:41:06 1997
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id MAA05356 for <bugs@RT-11.MIT.EDU>; Thu, 28 Aug 1997 12:41:01 -0400
Received: from media.teamnet.net by MIT.EDU with SMTP
id AA17429; Thu, 28 Aug 97 12:40:59 EDT
Received: (from benjid@localhost)
by media.teamnet.net (8.8.6/8.8.6) id LAA29596;
Thu, 28 Aug 1997 11:40:54 -0500 (CDT)
Message-Id: <199708281640.LAA29596@media.teamnet.net>
Date: Thu, 28 Aug 1997 11:40:54 -0500 (CDT)
From: benjid@teamnet.net
Reply-To: benjid@teamnet.net
To: krb5-bugs@MIT.EDU
Subject: failure of ftpd for kerberos authentication
X-Send-Pr-Version: 3.99

Show quoted text
>Number: 466
>Category: krb5-appl
>Synopsis: failure of ftpd for kerberos authentication
>Confidential: no
>Severity: critical
>Priority: medium
>Responsible: krb5-unassigned
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Thu Aug 28 12:42:01 EDT 1997
>Last-Modified: Tue Aug 11 01:21:25 EDT 1998
>Originator: Ben Dehner
>Organization:
TEAM Technologies
Show quoted text
>Release: 1.0pl1
>Environment:
System: IRIX media 6.2 03131015 IP22


Show quoted text
>Description:
Brief: failure of Kerberos ftpd to authenticate

Expanded: Our company's domain name is "teamnet.net", and I have made our
Kerberos realm TEAMNET.NET. However, we have many dedicated client machines
which have names outside of this domain, e.g. "www.nk.com". ftpd fails
to do Kerberos authentication on this machine. (I have included this machine
in the "TEAMNET.NET" realm in /etc/krb5.conf.)

Diagnostics: I put the ftpd server in debug mode by adding the "-v" flag to
ftpd in the /etc/inetd.conf file. The following exceprt below are from a
client connect and from the syslog:

client:
---------------------------------------
media/benjid>/usr/local/bin/ftp www.nk.com
Connected to www.nk.com.
220 www FTP server (Version 5.60) ready.
334 Using authentication type GSSAPI; ADAT must follow
GSSAPI accepted as authentication type
GSSAPI error major: No error
GSSAPI error minor: No error
GSSAPI error: acquiring credentials
GSSAPI ADAT failed
GSSAPI authentication failed
Name (www.nk.com:benjid):
331 Password required for benjid.
Password:
530 Login incorrect.
Login failed.
Remote system type is UNIX.
Using binary mode to transfer files.
Show quoted text
ftp> quit
221 Goodbye.
-------------------------------------------------

Server, obtained from syslog: (I have deleted parts of the
"ADAT" string)

------------------------------------------------------
Aug 28 11:26:33 6D:www ftpd[17800]: connection from media.teamnet.net at Thu Aug 28 11:26:33 1997
Aug 28 11:26:33 7D:www ftpd[17800]: <--- 220
Aug 28 11:26:33 7D:www ftpd[17800]: www FTP server (Version 5.60) ready.
Aug 28 11:26:33 7D:www ftpd[17800]: command: <AUTH GSSAPI^M
Aug 28 11:26:33 5B:www >(13)
Aug 28 11:26:33 7D:www ftpd[17800]: <--- 334
Aug 28 11:26:33 7D:www ftpd[17800]: Using authentication type GSSAPI; ADAT must follow

Aug 28 11:26:33 7D:www ftpd[17800]: command: <ADAT YIIB3QYJKoZIhvcSAQICAQBuggHMM
Aug 28 11:26:33 5B:www YoxBWg0dspdGO0paQAnC6SazYhtgzVGPR4NCMGMp4hriMxjdDyNJ148Us
XkEFWnJbSf65x/TOffoE0MggVw0ua2cX+l4j0EHD

Aug 28 11:26:33 5B:www >(651)
Aug 28 11:26:33 6D:www ftpd[17800]: importing <ftp@www.teamnet.net>
Aug 28 11:26:33 6D:www ftpd[17800]: importing <host@www.teamnet.net>
Aug 28 11:26:33 7D:www ftpd[17800]: <--- 501-
Aug 28 11:26:33 7D:www ftpd[17800]: GSSAPI error major: No error
Aug 28 11:26:33 7D:www ftpd[17800]: <--- 501-
Aug 28 11:26:33 7D:www ftpd[17800]: GSSAPI error minor: No error
Aug 28 11:26:33 7D:www ftpd[17800]: <--- 501
Aug 28 11:26:33 7D:www ftpd[17800]: GSSAPI error: acquiring credentials
Aug 28 11:26:33 3D:www ftpd[17800]: gssapi error acquiring credentials
Aug 28 11:26:36 7D:www ftpd[17800]: command: <USER benjid^M
Aug 28 11:26:36 5B:www >(13)
Aug 28 11:26:36 7D:www ftpd[17800]: <--- 331
Aug 28 11:26:36 7D:www ftpd[17800]: Password required for benjid.
Aug 28 11:26:39 7D:www ftpd[17800]: command: <PASS nonehere^M
Aug 28 11:26:39 5B:www >(15)
Aug 28 11:26:39 7D:www ftpd[17800]: <--- 530
Aug 28 11:26:39 7D:www ftpd[17800]: Login incorrect.
Aug 28 11:26:39 7D:www ftpd[17800]: command: <SYST^M
Aug 28 11:26:39 5B:www >(6)
Aug 28 11:26:39 7D:www ftpd[17800]: <--- 215
Aug 28 11:26:39 7D:www ftpd[17800]: UNIX Type: L8
Aug 28 11:26:41 7D:www ftpd[17800]: command: <QUIT^M
Aug 28 11:26:41 5B:www >(6)
Aug 28 11:26:41 7D:www ftpd[17800]: <--- 221
Aug 28 11:26:41 7D:www ftpd[17800]: Goodbye.
-------------------------------------------------

IMO, the key here is the "importing" string -- for some reason it
appears that the ftpd is cannonicalizing the system name incorrectly
and searching for server authentication tickets for the system
"www.teamnet.net" instead of "www.nk.com". The latter name
alread has a principal entered into the database and local
keytab file.


Show quoted text
>How-To-Repeat:


Show quoted text
>Fix:
One work-around would be to re-name the machine with a new
"teamnet.net" identifier; this is somewhat impractical on high-availability
web servers which already have names of this form.

To: benjid@teamnet.net
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-appl/466: failure of ftpd for kerberos authentication
Date: Mon, 01 Sep 1997 01:59:35 -0400

Show quoted text
>media/benjid>/usr/local/bin/ftp www.nk.com
>Connected to www.nk.com.
>220 www FTP server (Version 5.60) ready.
>334 Using authentication type GSSAPI; ADAT must follow
>GSSAPI accepted as authentication type
>GSSAPI error major: No error
>GSSAPI error minor: No error
>GSSAPI error: acquiring credentials

Don't you just _love_ this error? "Error: no error".

It took me a while to figure out what caused this, although your particular
problem is more complex. This is actually in the new Kerberos FAQ,
but I'll give you a "sneak preview" :-)

All of the _other_ Kerberos daemons will accept a ticket for whatever
service you give it, _if_ that service is in the local keytab file.
Even if you send to telnetd a ticket for "foobar/kremvax.su", as
long as that principal is in the local keytab, the daemons will
continue merrily on their way (this is probably a bug, though). Of
course, that ticket has to _exist_ in your KDC, so I doubt it's
a security bug (but don't quote me on that).

However, since ftpd uses the GSS-API, it works differently than the
other daemons. Specifically, it figures out what it's service name
is _supposed_ to be ... and if it doesn't find it in the local keytab,
it returns the oh-so-lovely "No error" error message.

The algorithm it uses can be found in appl/gssftp/ftpd/ftpd.c:auth_data(),
but essentially it uses gethostbyname(gethostname()) and uses the name
found therein as the hostname for the principal instance.

In _your_ case, I would guess that the hostname for that machine is
www, right? So in your case, gethostbyname("www") would return
"www.teamnet.net" ... not surprising :-)

_However_ (and this is also in the FAQ) you have to set your DNS up
a special way to make Kerberos work with multihomed machines, and I'm
guessing that you're doing web site hosting with a bunch of virtual
addresses on the same box.

The way to set up DNS to make Kerberos work is to create a bunch of
A records for the canonical hostname listing all of the IP addresses
for the host, i.e.

www.teamnet.net. IN A 192.104.107.5
IN A 192.104.107.97

and make all of the PTR records point back to the canonical hostname:

5.107.104.192.in-addr.arpa. PTR www.teamnet.net.
97.107.104.192.in-addr.arpa. PTR www.teamnet.net.

The principal you'll want to use is "host/www.teamnet.net@TEAMNET.NET"

_Then_, you can create more A records for the virtual interfaces:

www.nk.com IN A 192.104.107.97

And once you do that, voila! It should all work.

(Okay, one small fib ... just changing the PTR records around _should_
be sufficient, if you don't want to put all of those addresses
in the www.teamnet.net A record, but that might break other things
in the long run).

--Ken

State-Changed-From-To: open-closed
State-Changed-By: mdh
State-Changed-When: Tue Aug 11 01:20:04 1998
State-Changed-Why:

This is a known problem documented elsewhere. No new info here. A good
fix will have to wait for Secure DNS or name canonicalization in the KDC.

Show quoted text
>Audit-Trail:
>Unformatted: