Your best friend for file transfer.

Fetch application logoFetch

Kerberos auth fails when AD is KDC (4 posts)

  • Started 9 years ago by bombich
  • Latest reply 9 years ago from Scott McGuire
  • bombich Member

    I have a MOSXS 10.4.2 bound to my own AD server (Win2K3) via the AD plugin, and joined to the AD Kerberos realm. I have FTP, AFP, and Windows services enabled. On my client machine (also bound to AD via the AD plugin), I can SSO mount AFP and SMB shares, but FTP (GSSAPI) via Fetch is failing. Oddly, I get the ftp service ticket (and the principal named in the service ticket matches the one specified in the FTP server configuration), it seems that Fetch is simply not sending the authorization data (transcript below).

    The same machines bound to my MOSXS 10.4.2 OD Master, FTP (GSSAPI) with Fetch works fine.

    Transcripts:
    Server and client bound to AD, client user has AD krbtgt:

    Connecting to services.apple.edu port 21 (10/7/05 1:06:56 PM)
    Connected to 10.0.2.3 port 21 (10/7/05 1:06:56 PM)
    220--------------------------------------------------------------------------------
    220-This is the "Banner" message for the Mac OS X Server's FTP server process.
    220--------------------------------------------------------------------------------
    220-
    220 services.apple.edu FTP server ready.
    ADAT
    503 You must issue an AUTH first.
    AUTH This command is checking whether this server supports Kerberos or GSS security, see RFC 2228
    504 This command is checking whether this server supports Kerberos or GSS security, see RFC 2228 is unknown to me
    AUTH GSSAPI
    334 Send authorization data.
    gss_send_tok_buff = ftp@services.apple.edu.

    [at this point I get an error message: "Mac OS error -30200. Server responded: Send authorization data"]

    Here is the transcript while client and server are bound to AD, client user already has an OD krbtgt

    Connecting to services.apple.edu port 21 (10/7/05 1:21:44 PM)
    Connected to 10.0.2.3 port 21 (10/7/05 1:21:44 PM)
    220--------------------------------------------------------------------------------
    220-This is the "Banner" message for the Mac OS X Server's FTP server process.
    220--------------------------------------------------------------------------------
    220-
    220 services.apple.edu FTP server ready.
    ADAT
    503 You must issue an AUTH first.
    AUTH This command is checking whether this server supports Kerberos or GSS security, see RFC 2228
    504 This command is checking whether this server supports Kerberos or GSS security, see RFC 2228 is unknown to me
    AUTH GSSAPI
    334 Send authorization data.
    gss_send_tok_buff = ftp@services.apple.edu.
    ADAT
    235 ADAT=YIGWBgkqhkiG9xIBAgICAGjCBg6ADAgEFoQMCAQzB1oAMCARCibgRsXuxcOjakRjGl7lara1yIwYNZAqXKFLiGmORzcox24WS0ToMB28rvbRw24PeIqegVZwsQNQb9wLXQMRzIwMWdf6awOXyxTvqK1fd6HtukMefbTlrTsW4xPp4qUcqv5qf2u/gDB
    USER education
    230-No directory! Logging in with home=/

    230--------------------------------------------------------------------------------

    230-This is the "Welcome" message for the Mac OS X Server's FTP server process.

    I'd be willing to entertain the suggestion that my setup is not configured correctly, but AFP and SMB file services are working fine under the same conditions. Any reason why Fetch might not be sending the authorization data when requested?

    Posted 9 years ago #

  • bombich Member

    Sorry, I should also have mentioned that this is with Fetch 5.0.4. Forward and reverse DNS are working fine for all hosts.

    Posted 9 years ago #

  • bombich Member

    Crud, also, the second transcript is while server and client are bound to OD, not AD. Perhaps I should just register ;-)

    Posted 9 years ago #

  • Scott McGuire Administrator

    Unfortunately, we believe the problem connecting to the AD server is a problem in Fetch caused by a somewhat larger-than-normal response from the server when asked for authorization data. At this time there is no workaround, sorry. We will work on fixing it for the next version of Fetch.

    Thanks,

    Scott McGuire
    Fetch Softworks

    [This message has been edited by ScottMcGuire (edited 10-09-2005).]

    Posted 9 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.