Your best friend for file transfer.

Fetch application logoFetch

Fetch w/ Kerb? (16 posts)

  • Started 16 years ago by mosx86
  • Latest reply 13 years ago from pskpsk
  • mosx86 Member

    I'm using Fetch v5.2 and am attempting to connect to a Mac OS 10.4 server that only allows kerberos authentication.

    When I attempt the connection w/ FTP w/ KClient I get the error:

    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 KERBEROS_V4
    504 KERBEROS_V4 is unknown to me

    When I attempt the connection with FTP with GASSAPI I get the following error, but I am granted a ticket for the FTP server (I'm granted both a FTP and host ticket).
    Connecting to FQHN.com port 21 (Mac OS X firewall is off) (5/24/07 3:19:16 PM)
    Connected to IPobscurred port 21 (5/24/07 3:19:16 PM)
    220--------------------------------------------------------------------------------
    220-This is the "Banner" message for the Mac OS X Server's FTP server process.
    220-
    220- FTP clients will receive this message immediately
    220- before being prompted for a name and password.
    220-
    220-PLEASE NOTE:
    220-
    220- Some FTP clients may exhibit problems if you make this file too long.
    220-
    220--------------------------------------------------------------------------------
    220-
    220 FQHN.com 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@FQHN.com
    ADAT
    535-GSSAPI error major: Incorrect channel bindings were supplied
    535-GSSAPI error minor: No error
    535 GSSAPI error: accepting context [ Incorrect channel bindings were supplied - No error ]
    release 2
    service 0gss_send_tok_buff = host@FQHN.com
    ADAT
    535-GSSAPI error major: Miscellaneous failure
    535-GSSAPI error minor: Wrong principal in request
    535 GSSAPI error: accepting context [ Miscellaneous failure - Wrong principal in request ]
    release 2
    service 1

    As far as kerb goes on the server, all other single signon services are working fine. The FetchSofworks help document on kerberos states taht 5.2 doesn't require the MIT Kerb Extras.

    Thanks!

    Posted 16 years ago #

  • Scott McGuire Administrator

    Hi,

    The FTP server built into Mac OS X 10.4 Server does not support all Kerberos options.

    It does not support Kerberos v4/KClient connections at all; and it does not support GSSAPI connections with encryption. (The password exchange is still encrypted, but data transfers are not.)

    Before connecting to the server with GSSAPI, try unchecking the "Enable encryption" checkbox in the New Connection dialog and that should fix the errors.

    If it doesn't, try chaning the setting of the "Specify GSSAPI channel bindings" checkbox in the Security Preferences pane of Fetch.

    Thanks,

    Scott McGuire
    Fetch Softworks

    Posted 16 years ago #

  • mosx86 Member

    Scott,

    Thanks for the quick reply...

    Still getting the same error after both adjustments. I look at the server logs and authenticatio is successfull. I am getting both the ftp and host tickets as well...

    Do you know if there are any adjustments that need to be made server side?

    Regards...

    Posted 16 years ago #

  • Scott McGuire Administrator

    Hi,

    There may be some further configuration that needs to be done to the server. Unfortunately we aren't familiar with setting up Kerberos on Mac OS X server; I do know that some servers force certain GSSAPI channel bindings and you may need to find a way to turn that off, if possible. It may not be possible on Mac OS X Server.

    So, you may want to contact Apple about this problem and see if there is a solution.

    Another option is posting a question on one of the Kerberos mailing lists; someone may have run into the same problem and may have a solution for you. You can find a list of the Kerberos mailing lists here:

    http://web.mit.edu/kerberos/www/mail-lists.html

    The "main Kerberos list" is probably the best place to start.

    Sorry not to have a better answer for you. If you do find a definite answer, please let us know.

    Thanks,

    Scott McGuire
    Fetch Softworks

    Posted 16 years ago #

  • mosx86 Member

    Thanks, Scott. I will give the mailing list a try. If I come across anything I will definitely post it.

    Posted 16 years ago #

  • mosx86 Member

    Scott-

    Is there a way to get more detailed transcripts out of Fetch? I'd like to see what principal is being passed on to the server.

    Posted 16 years ago #

  • Scott McGuire Administrator

    Hi,

    No, currently there is no way to get Fetch to print the name of the principal in the transcript in your case. (It will print the name of the principal after you've successfully authenticated, but obviously that's not useful to you.)

    However, I can assure you that Fetch is passing in the principal that is the listed as the "Active User" in the Mac OS X Kerberos application (which as you may know, can be found in /System/Library/CoreServices ).

    From what I recall, the errors you are receiving are not related to the principal being passed in. I believe that the errors may be related to being behind a NAT. Have you tried connecting to the server from a Mac that has its own, proper IP address, and is not behind a NAT?

    You may also want to make sure that you're requesting addressless Kerberos tickets, although I believe that is the default setting in Mac OS X.

    After that, the best I can suggest is contacting Apple, or asking questions on the Apple discussion forums (since I see you haven't received a reply on the kerberos mailing list).

    Thanks,

    Scott McGuire
    Fetch Softworks

    Posted 16 years ago #

  • mosx86 Member

    Thanks, Scott...

    The question is out in the ether now. I will keep pinging Apple on it and we'll see what happens. Just out of curiousity, what does Apple need to do to support full packet encryption? In the server configuration for an open directory master (Mac OS 10.4.x server), you can optionally select the ability to encrypt all packets with Kerb... Does this just not work with FTP?

    Posted 16 years ago #

  • Scott McGuire Administrator

    Hi,

    To be honest, we don't know the answers to those questions... sorry.

    Best,

    Scott McGuire
    Fetch Softworks

    Posted 16 years ago #

  • mosx86 Member

    Scott, just an update...

    Using 10.5 server, I've been able to get Fetch v5.3 to work with GSSAPI authentication when deselecting encryption.

    If a connection with encryption is attempted it errors out with:
    504 Unrecognized protection level.

    Any idea what its expecting?

    Still the GSSAPI authentication is definitely a step forward!

    Posted 15 years ago #

  • Scott McGuire Administrator

    Hi,

    No, sorry, we don't. It sounds like it still doesn't support encrypting data transfers.

    Glad to hear it's at least improved a little, though.

    Thanks,

    Scott McGuire
    Fetch Softworks

    Posted 15 years ago #

  • pskpsk Member

    I tried V5.6 on OS X 10.5.8 and get the same error. Has this been resolved yet. Thanks for the help. Here's what's in the Fetch Transcript file:

    Connecting to devosx-3-cdc port 21 (Mac OS X firewall is allowing connections) (6/16/10 11:24 AM)
    Connected to 172.27.19.196 port 21 (6/16/10 11:24 AM)
    220--------------------------------------------------------------------------------
    220-This is the "Banner" message for the Mac OS X Server's FTP server process.
    220-
    220- FTP clients will receive this message immediately
    220- before being prompted for a name and password.
    220-
    220-PLEASE NOTE:
    220-
    220- Some FTP clients may exhibit problems if you make this file too long.
    220-
    220--------------------------------------------------------------------------------
    220-
    220 devosx-3-cdc.centrify.dev 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@devosx-3-cdc.centrify.dev
    ADAT
    535-GSSAPI error major: Incorrect channel bindings were supplied
    535-GSSAPI error minor: No error
    535 GSSAPI error: accepting context [ Incorrect channel bindings were supplied - No error ]
    release 2
    service 0gss_send_tok_buff = host@devosx-3-cdc.centrify.dev
    ADAT
    535-GSSAPI error major: Unspecified GSS failure. Minor code may provide more information
    535-GSSAPI error minor: Wrong principal in request
    535 GSSAPI error: accepting context [ Unspecified GSS failure. Minor code may provide more information - Wrong principal in request ]
    release 2
    service 1An FTP with GSSAPI connection to “devosx-3-cdc” could not be opened because the FTP server rejected your authentication information. (Contact the server administrator to verify that you have the correct hostname, username, password, and authentication method.
    Server responded: “GSSAPI error major: Unspecified GSS failure. Minor code may provide more information
    GSSAPI error minor: Wrong principal in request
    GSSAPI error: accepting context [ Unspecified GSS failure. Minor code may provide more information - Wrong principal in request ]”)

    Posted 13 years ago #

  • Scott McGuire Administrator

    Hi,

    As mentioned above, please try the following:

    Before connecting to the server with GSSAPI, try unchecking the "Enable encryption" checkbox in the Fetch New Connection dialog and see if that helps.

    If it doesn't, try toggling the setting of the "Specify GSSAPI channel bindings" checkbox in the Security Preferences pane of Fetch.

    Otherwise, we recommend that you contact Apple for further assistance; these are problems with the way the Mac OS X FTP server supports Kerberos/GSSAPI, not with Fetch, and so Apple are the only ones who can help resolve the problem.

    Thanks,

    Scott McGuire
    Fetch Softworks

    Posted 13 years ago #

  • pskpsk Member

    Hi Scott,

    I did all that and it still gives out the same error, ;-(. I am pretty sure SSO works on this server and the same client acount because I can do SSO SMB share mount to the same Mac server. I am evaluating your product for volume purchasing for our company. This is hurdle I have to overcome before we can commit the purchase. Any help and direction as to what need to be send to Apple for bug reporting is appreciated. T/C.

    PSK

    Posted 13 years ago #

  • Scott McGuire Administrator

    Hi PSK,

    GSSAPI can work on the server with SMB sharing when FTP with GSSAPI does not; SMB sharing communicates with a different piece of server software. The problem is probably in the FTP server software and/or its settings, not the overall GSSAPI setup on the server.

    The only further suggestion we have for troubleshooting is that you might want to see if you can find a command-line FTP client that supports GSSAPI, and see if you run into the same problem connecting to the server with it. Unfortunately, the command-line FTP client built into Mac OS X doesn't support Kerberos or GSSAPI. I don't know if there's an alternative one you can compile and install for Mac OS X that does or not, but you could take a look and see.

    Best,

    Scott McGuire
    Fetch Softworks

    Posted 13 years ago #

  • pskpsk Member

    Hi Scott,

    Thanks for prompt reply. I can guess I have to surf the 'Net more to see if I can find more help on this. Take care.

    PSK

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