From the command line you user can use
kinit -4 <[EMAIL PROTECTED]> aklog -4 <your.cell>
However, you should probably start to consider a transition to a Kerberos 5 KDC and OpenAFS 1.2.x in the near future. Kerberos 4 support is being removed from MIT Kerberos within two years and the OpenAFS 2.0
release is going to depend quite heavily on GSS-API and Kerberos 5
crypto for securing your data.
Jeffrey Altman
giovanni bracco wrote:
We run a AFS cell with AFS transarc dbservers and standard kerberos 4.
A colleague working at MIT site [athena.mit.edu] has problems in authenticating to AFS from his windows laptop (XP SP2, OpenAFS 1.3.75) and gets the message:
"Cannot resolve network address for KDC in requested realm"
when she tried to get a token from the OpenAFS tray panel.
That sistem is configured also to access the local system athena.mit.edu.
On the contrary on another system with OpenAFS 1.2.11, (that is not configured to access athena.mit.edu ) everything works nicely with our AFS cell.
In OpenAFS documentation http://www.openafs.org/dl/openafs/1.3.76/winnt/afs-install-notes.txt I have found the following:
....
As of 1.3.65, the OpenAFS client will directly use Kerberos 5 tickets as tokens if KFW is installed. The client requires that all of the AFS Servers with which it communicates support the use of Kerberos 5 tickets as tokens (aka 2b tokens).
This means that all of the AFS servers must be running OpenAFS release 1.2.8 or higher. Transarc servers do not support Kerberos 5 tickets as tokens.
....
and I suppose that this can be the reason fro the problems in the former system.
How can we solve the problem: authentification to old AFS transarc dbservers from the last version of OpenAFS Windows client?
Thanks
Giovanni
smime.p7s
Description: S/MIME Cryptographic Signature
