Fetch Softworks

Fetch using wrong kerberos principal (6 posts)

• Started 14 years ago by Epeterso
• Latest reply 14 years ago from Scott McGuire

• Epeterso Member

  After obtaining a new ticket and using Fetch 5.3 on OS X 10.4.11 to connect to an FTP server i get the following error.

  "GSS authentication data could not be constructed"

  The ONLY tgt and "active user" ticket in the kerberos utility is:
  krbtgt/OURDOMAIN.EDU@OURDOMAIN.EDU

  however on the target KDC logs it shows the following tgt trying to be used.
  krbtgt/SERVER1@OURDOMAIN.EDU, Server not found in Kerberos database

  Other services (kerberized ssh, kftp etc all work fine). It just seems that Fetch is passing the wrong principal/realm info to the KDC. There is an unrelated KDC running on the same network as the client (SERVER1). Is there any cached files that might be causing this behavior? Rebooting the client and recreating the kerberos ticket has already been attempted.

  Fetch Transcript entry:

  Connecting to ftp.ourdomain.edu port 21 (Mac OS X firewall is on) (7/22/08 4:50:13 PM)
  Connected to XXX.XXX.XXX.XXX port 21 (7/22/08 4:50:13 PM)
  220 ftp.ourdomain.edu FTP server (Version 5.60) ready.
  ADAT
  503 Must identify AUTH type before ADAT
  AUTH This command is checking whether this server supports Kerberos or GSS security, see RFC 2228
  504 Unknown authentication type: This command is checking whether this server supports Kerberos or GSS security, see RFC 2228
  AUTH GSSAPI
  334 Using authentication type GSSAPI; ADAT must follow
  gss_send_tok_buff = ftp@ftp.ourdomain.edu
  release 2
  service 0gss_send_tok_buff = host@ftp.ourdomain.edu
  release 2
  service 1

  Console Log:

  Fetch 5.3 (5D161): --- BEGIN FETCH ERROR ---
  Fetch 5.3 (5D161): FST2/SIaARgIEAkjn1ACjawQAo9l0AKPf1AHiIoQB/VBkAWL61APKTNQDvxNJCHS3KQgtWhkILKQpLfGHiS3wuOadJLjmLxAD5Q0AA
  Fetch 5.3 (5D161): FST2B2HwAAG5IAABq5AAAAAg
  Fetch 5.3 (5D161): FST2/SIaARgIEAkjn1ACjawQAo9l0AKPf1AO0W/QBT30UAUAFYDZQC0AnEqtAJxMqQB4iZ0Af1QZAFiDykzUA78TSQh0tykI
  Fetch 5.3 (5D161): FST2LVoZCCykKS3xh4kt8PgpLjmnSS45i8QAAAAdh8AABuSAAAauQAAAAIA==
  Fetch 5.3 (5D161): An FTP with GSSAPI connection to "ftp.ourdomain.edu" could not be opened because GSS authentication data could not be constructed. (Try again, or contact the server administrator for assistance.)
  Fetch 5.3 (5D161): --- END FETCH ERROR ---

  Posted 14 years ago #

• Scott McGuire Administrator

  Hi,

  I've consulted with my Fetch colleagues about your problem and we need more information in order to help you.

  First, an unedited transcript would be very helpful; and second, based on what you sent so far, we need to see your Kerberos configuration file in order to figure out what is going on.

  We realize that you don't want to post the unedited transcript or configuration file in a public forum; but if you email to us, they will stay private. You can email them to us at:

  bb at fetchsoftworks dot com

  If you need help finding the Kerberos configuration file on Mac OS X, please see:

  http://web.mit.edu/macdev/KfM/Common/Documentation/preferences-osx.html#locations

  or let us know if you need further assistance after reading that.

  Thanks,

  Scott McGuire
  Fetch Softworks

  [This message has been edited by ScottMcGuire (edited 07-23-2008).]

  Posted 14 years ago #

• Epeterso Member

  Scott, thanks for pointing me to the documentation. It turns out that the/Library/Preferences/edu.mit.Kerberos file had the incorrect realm information.

  However the /etc/krb5.conf file was using the correct realm info. The client is a managed system by a OS X server running a KDC. I bet the file must have been automatically updated and was thus preferred by Fetch over the unix standard /etc/krb5.conf file.

  Posted 14 years ago #

• Scott McGuire Administrator

  Hi,

  So, just to confirm, Fetch is now able to connect successfully now that the two configuration files have the same information?

  Thanks,

  Scott McGuire
  Fetch Softworks

  [This message has been edited by ScottMcGuire (edited 07-23-2008).]

  Posted 14 years ago #

• Epeterso Member

  that is correct. Fetch is now working as expected. Thanks.

  Posted 14 years ago #

• Scott McGuire Administrator

  Hi,

  You're welcome, and thanks for the confirmation.

  Best,

  Scott McGuire
  Fetch Softworks

  Posted 14 years ago #