Fetch Softworks

334 Using authentication type GSSAPI; ADAT must follow (6 posts)

• Started 17 years ago by jpz
• Latest reply 17 years ago from Scott McGuire

• jpz Member

  I am attempting to FTP to a server using Kerberos authentication (GSSAPI). I get ths following error though:

  334 Using authentication type GSSAPI; ADAT must follow

  and my connection is dropped.

  I have checked my Kerberos ticket and it seems to be working fine with this server (I can log in through kerberized telnet, for example). I have tried toggling the following options:

  -Obscure >> Do not send ADAT probe command
  -Obscure >> Do not send MCAB probe command
  -Security >> Specify GSSAPI channel bindings

  And as near as I can tell, none have any effect. (I think the transcripts are identical, and the FTP connection always gets dropped.) Any suggestions? I've included the Fetch transcript below. I'm running Fetch 5.1 on in Intel iMac (OS X 10.4.7).

  The fetch transcript is:

  Connecting to server1.edu port 21 (OS X firewall is off) (9/11/06 9:45:11 AM)
  Connected to ###.##.#.### port 21 (9/11/06 9:45:11 AM)
  220 server2.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@server1.edu
  ADAT
  get_reply():con_conn->Getline() returns -3253

  Posted 17 years ago #

• Scott McGuire Administrator

  Hi,

  What happens if you uncheck the "Use passive mode transfers" checkbox in the General pane of the Fetch Preferences, and try again?

  Thanks,

  Scott McGuire
  Fetch Softworks

  Posted 17 years ago #

• jpz Member

  Same result (identical Fetch transcript) with "Use passive mode transfers" unchecked...

  Posted 17 years ago #

• Scott McGuire Administrator

  Hi,

  Thanks for the additional information.

  Could you try connecting without forwardable Kerberos tickets? To do this:

  * Destroy your existing Kerberos tickets (you'll probably need the Kerberos application to do this; it's in /System/Library/CoreServices ).
  * Request new tickets, but before entering your password, click the gear icon in the lower left-hand corner of the Kerberos authentication dialog.
  * Choose Ticket Options.
  * In the Ticket Options dialog, uncheck the "Get tickets that can be forwarded to other computers" checkbox.
  * Click OK
  * Enter your password and get tickets.
  * Try connecting again to the FTP server again.
  * Since you do not have forwardable tickets, Fetch will ask for your password; enter your Kerberos password.

  Please let us know what happens.

  Thanks,

  Scott McGuire
  Fetch Softworks

  Posted 17 years ago #

• jpz Member

  That did it, everything works great now. Thanks very much for your help.

  (Fetch did not, however, ask for my Kerberos password, it somehow worked off the existing ticket.)

  [This message has been edited by jpz (edited 09-11-2006).]

  Posted 17 years ago #

• Scott McGuire Administrator

  Hi,

  Glad to hear that worked.

  We suspect this is the result of a bug in the server, which we've seen with a couple other Kerberized FTP servers. The problem is the auth data sent with the ADAT command is larger than the server can handle (even though Fetch is sending a legitimate set of data); turning off forwardable tickets makes the auth data quite a bit smaller.

  You may want to contact your server maintainer, and ask them to make sure they are running the latest server software, and if not, to report a bug to the makers of the server software. (In particular, if it's a Mac OS X server, report a bug to Apple.)

  Best,

  Scott McGuire
  Fetch Softworks

  Posted 17 years ago #