Your best friend for file transfer.

Fetch application logoFetch

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

  • Started 8 years ago by jpz
  • Latest reply 8 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 8 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 8 years ago #

  • jpz Member

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

    Posted 8 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 8 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 8 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 8 years ago #

Reply

  • Or nickname, if you prefer.
  • This will be kept confidential.
  • This is to ensure that you’re a person, not a spambot.