Your best friend for file transfer.

Fetch using wrong kerberos principal (6 posts)
- Started 15 years ago by Epeterso
- Latest reply 15 years ago from Scott McGuire
-
Epeterso Member
-
Scott McGuire Administrator
Hi,
I've consulted with my Fetch colleagues about your problem and we need more information in order to help you.
First, an unedited transcript would be very helpful; and second, based on what you sent so far, we need to see your Kerberos configuration file in order to figure out what is going on.
We realize that you don't want to post the unedited transcript or configuration file in a public forum; but if you email to us, they will stay private. You can email them to us at:
bb at fetchsoftworks dot com
If you need help finding the Kerberos configuration file on Mac OS X, please see:
http://web.mit.edu/macdev/KfM/Common/Documentation/preferences-osx.html#locations
or let us know if you need further assistance after reading that.
Thanks,
Scott McGuire
Fetch Softworks[This message has been edited by ScottMcGuire (edited 07-23-2008).]
-
Epeterso Member
Scott, thanks for pointing me to the documentation. It turns out that the/Library/Preferences/edu.mit.Kerberos file had the incorrect realm information.
However the /etc/krb5.conf file was using the correct realm info. The client is a managed system by a OS X server running a KDC. I bet the file must have been automatically updated and was thus preferred by Fetch over the unix standard /etc/krb5.conf file.
-
Scott McGuire Administrator
Hi,
So, just to confirm, Fetch is now able to connect successfully now that the two configuration files have the same information?
Thanks,
Scott McGuire
Fetch Softworks[This message has been edited by ScottMcGuire (edited 07-23-2008).]
-
Epeterso Member
that is correct. Fetch is now working as expected. Thanks.
-
Scott McGuire Administrator
Hi,
You're welcome, and thanks for the confirmation.
Best,
Scott McGuire
Fetch Softworks
- Page 1
After obtaining a new ticket and using Fetch 5.3 on OS X 10.4.11 to connect to an FTP server i get the following error.
"GSS authentication data could not be constructed"
The ONLY tgt and "active user" ticket in the kerberos utility is:
krbtgt/OURDOMAIN.EDU@OURDOMAIN.EDU
however on the target KDC logs it shows the following tgt trying to be used.
krbtgt/SERVER1@OURDOMAIN.EDU, Server not found in Kerberos database
Other services (kerberized ssh, kftp etc all work fine). It just seems that Fetch is passing the wrong principal/realm info to the KDC. There is an unrelated KDC running on the same network as the client (SERVER1). Is there any cached files that might be causing this behavior? Rebooting the client and recreating the kerberos ticket has already been attempted.
Fetch Transcript entry:
Connecting to ftp.ourdomain.edu port 21 (Mac OS X firewall is on) (7/22/08 4:50:13 PM)
Connected to XXX.XXX.XXX.XXX port 21 (7/22/08 4:50:13 PM)
220 ftp.ourdomain.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@ftp.ourdomain.edu
release 2
service 0gss_send_tok_buff = host@ftp.ourdomain.edu
release 2
service 1
Console Log:
Fetch 5.3 (5D161): --- BEGIN FETCH ERROR ---
Fetch 5.3 (5D161): FST2/SIaARgIEAkjn1ACjawQAo9l0AKPf1AHiIoQB/VBkAWL61APKTNQDvxNJCHS3KQgtWhkILKQpLfGHiS3wuOadJLjmLxAD5Q0AA
Fetch 5.3 (5D161): FST2B2HwAAG5IAABq5AAAAAg
Fetch 5.3 (5D161): FST2/SIaARgIEAkjn1ACjawQAo9l0AKPf1AO0W/QBT30UAUAFYDZQC0AnEqtAJxMqQB4iZ0Af1QZAFiDykzUA78TSQh0tykI
Fetch 5.3 (5D161): FST2LVoZCCykKS3xh4kt8PgpLjmnSS45i8QAAAAdh8AABuSAAAauQAAAAIA==
Fetch 5.3 (5D161): An FTP with GSSAPI connection to "ftp.ourdomain.edu" could not be opened because GSS authentication data could not be constructed. (Try again, or contact the server administrator for assistance.)
Fetch 5.3 (5D161): --- END FETCH ERROR ---
Posted 15 years ago #