[OpenAFS] Windows Java Kerberos 5 implementation

Jeffrey Altman jaltman@secure-endpoints.com
Mon, 24 Sep 2012 22:12:59 -0400

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Java kinit.exe is quite broken.  It doesn't know how to find the Heimdal
and/or MIT KFW krb5 configuration profile and it doesn't know how to use
credential cache types which are not files.

If the JDK bin directory is first in the PATH, the JDK kinit.exe will be
executed in preference to any other on the machine.  This is similar to
the confusion caused by Microsoft's klist.exe and the klist.exe provided
by the JDK, Heimdal and KFW.

The Cygwin Kerberos will have identical problems.

The JDK Kerberos can be used provided that the JDK and Heimdal or KFW
are configured to use the same FILE credential cache and you provide the
necessary JDK Kerberos configuration data.

The OpenAFS aklog.exe cannot use the JDK Kerberos stack but if the cache
configuration is correct, the TGT obtained by the JDK kinit.exe can be
used by Heimdal or KFW Kerberos to obtain the necessary service ticket.

If you do not want the JDK kinit.exe to be used, create a batch file
named something else that your students will install and use that calls
the kinit.exe that you want to use directly.

You can also have your students create a Command Prompt shortcut that
has the Kerberos bin directory as the default.  Or you can write a
program that ensures that the JDK directory is after the Heimdal or KFW
directory in the PATH.

Jeffrey Altman

On 9/24/2012 8:46 PM, John Tang Boyland wrote:
> Dear OpenAFS community,
>    This semester I have had a number of students who have problems
> to do with kinit.  Sometimes, even after installing KfW,=20
> they have the following interaction:
>> kinit XXX@CS.UWM.EDU
>     =20
>      Password for XXX@CS.UWM.EDU:
>     =20
>      Exception: krb_error 0 Cannot locate default realm No error
>     =20
>      KrbException: Cannot locate default realm
>              at sun.security.krb5.PrincipalName.<init>(PrincipalName.ja=
>              at sun.security.krb5.internal.tools.Kinit.<init>(Kinit.jav=
>              at ...
> So it seems that someone (the default JDK installation?)
> installs a (non-working?) "kinit" command that sometimes
> is higher in the path than where Heimdahl/MIT KfW installs.
> (I once had someone go into the correct Heimdahl directory
> and then they were able to run the correct binary.)
> So, three questions:
> (1) Is this Java "kinit" really that broken?
> 	(Why does it need a default realm if the principal includes the realm?=
> (2) If so, how can we prevent it from causing things to fail?
> (3) If not, can we somehow leverage it in the same way we leverage
>     "kinit" on MacOSX ?
> I have students use kinit since NIM is fragile: sometimes
> my students can't get any of the plugins to work (not even Krb5)
> and NIM is useless, and since I don't have time to debug NIM,
> I have them use "kinit" at the command prompt.  It may be
> my bias toward the command line is showing.
> Best regards,
> John
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info

Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

Version: GnuPG v1.4.9 (MingW32)