Fetch Softworks

Kerberos auth fails when AD is KDC (4 posts)

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