Fetch Softworks

4.0.2: kerberos stopped connecting under Mac OS X (2 posts)

• Started 21 years ago by irwin
• Latest reply 21 years ago from Jim Matthews

• irwin Member

  When I upgraded from 4.0.1 to 4.0.2, I found that connecting using GSS stopped working (to a Kerberos version 5 server) in the Mac OS X environment.

  Steps to reproduce:

  1. Obtain a Kerberos ticket from Kerberos v5 server, using the
  MIT Kerberos for Mac OX X, version 4.0 client.

  2. Launch Fetch 4.0.2.

  3. In the "New Connection" dialog, I've entered the fully-qualified canonical hostname, and a userid.
  Security is GSS, encrypt session is enabled. After I hit "OK" in the New Connection dialog, instead of
  getting a successful connection, an alert appears, saying "GSSAPI error: An invalid name was supplied
  Hostname cannot be canonicalized (OK)"

  If I quit Fetch 4.0.2 and repeat the test using Fetch 4.0.1 on the same computer
  (no change to Fetch preferences, using the same shortcut, etc), it works fine.

  Platform:
  Mac OS X 10.1.4
  No personal firewall or NAT installed.
  ftp server is a Solaris 8 system running from MIT Kerberos 5 version 1.2.4.
  No firewall, NAT or proxy sever between the ftp client and server.

  Fetch relevent Preferences
  Security:
  do not warn before sending password insecurely
  do warn before sending cleartext password to secure server
  do not check protoection level on incoming data
  do not make Kerberos v5 tickets forwardable
  do send dummy password to Kerberos servers
  do specify GSS channel bindings (only present in 4.0.2) (changing to do not makes no difference)

  Here are copies of transcripts from 4.0.1 followed by 4.0.2.
  (I've xxx'd out some identifying info.)

  Fetch 4.0.1 works:
  System Version = 0x1014
  Connecting to xxxxx.princeton.edu port 21 (5/10/02 3:32:04 PM)
  220 xxxxx.Princeton.EDU FTP server (Version 5.60) ready.
  ADAT
  503 Must identify AUTH type before ADAT
  AUTH GSSAPI
  334 Using authentication type GSSAPI; ADAT must follow
  ADAT
  235 ADAT=xxxxxxxxxxxxxx....
  USER xxxxxxx
  232 GSSAPI user xxxxxx@PRINCETON.EDU is authorized as xxxxxx
  PBSZ 131072
  200 PBSZ=131072
  PROT P
  200 Data channel protection level set to private.
  PWD
  257 "/home/xxxxxx" is current directory.
  SYST
  215 UNIX Type: L8
  PWD
  257 "/home/xxxxx" is current directory.
  MACB ENABLE
  500 'MACB ENABLE': command not understood.
  CWD tmp
  250 CWD command successful.
  PWD
  257 "/home/xxxx/tmp" is current directory.

  Kerberos

  Fetch 4.0.2 fails:
  Fetch 4.0.2 System 0x1014 Serial xxxxxx
  Connecting to xxxxxx.princeton.edu port 21 (5/10/02 3:36:18 PM)
  220 xxxxxx.Princeton.EDU FTP server (Version 5.60) ready.
  ADAT
  503 Must identify AUTH type before ADAT
  AUTH GSSAPI
  334 Using authentication type GSSAPI; ADAT must follow
  gss_send_tok_buff = ftp@
  gss_send_tok_buff = host@
  Connecting to xxxxxx.princeton.edu port 21 (5/10/02 3:36:29 PM)
  220 xxxxxx.Princeton.EDU FTP server (Version 5.60) ready.
  ADAT
  503 Must identify AUTH type before ADAT
  AUTH GSSAPI
  334 Using authentication type GSSAPI; ADAT must follow
  gss_send_tok_buff = ftp@
  gss_send_tok_buff = host@

  Posted 21 years ago #

• Jim Matthews Administrator

  What a great bug report! Thanks for all the information.

  There was a change between Fetch 4.0.1 and 4.0.2 in the way it requests Kerberos tickets. Fetch makes a connection to the server, then asks the Domain Name System to turn that address into a hostname, and then asks the GSS/Kerberos software for a ticket for that hostname. The change was in the call used to turn the address into a hostname. It looks like, in your case, the new call is not working -- it is returning an empty string. That's why Fetch is asking for a ticket for "ftp@" -- it should be something like "ftp@xxx.princeton.edu".

  Is it possible that the address you are connecting to is not associated with a name in the domain name system? Could you email me the server's hostname (send it to support@fetchsoftworks.com)?

  Thanks,

  Jim Matthews
  Fetch Softworks

  Posted 21 years ago #