[OpenAFS] KfW on Windows 7 / 64 bit

John Tang Boyland boyland@cs.uwm.edu
Wed, 02 Feb 2011 21:49:48 -0600

jaltman@secure-endpoints.com wrote:
] On 2/2/2011 12:39 PM, John Tang Boyland wrote:
] > I have a student who is trying to get Kerberos/OpenAFS working on
] > Windows 7 (64 bit).  But not even NIM works, it says that
] > 	validity of identity couldn't be determined
] > When they run kinit in a command.com window they get the same error
] > with one (I am typing this from memory) about not being able to
] > contact a KDC for the desired realm.
] >=20
] > And yet,=20
] > 	ping kerberos.cs.uwm.edu
] > works just fine.
] MIT Kerberos provides very few mechanisms for debugging the internal of
] the library operations.  Things you can do:
] * Turn on Network Identity Manager logging from the General page
]   and confirm that the identity the user is entering matches
]   the one in the KDB
] * Examine the KDC logs to see if a request is in fact being
]   received for that user and what error response is being sent.
] * Use wireshark or Microsoft netmon to trace the network traffic
]   and confirm that the user is in fact sending requests to the
]   correct KDCs.
] A failure to contact a KDC for the desired realm can be a failure to
] identify what the KDCs for the desired realm are.
] Since the user is on Windows 7, if a krb5.ini file is being used
] to specify the configuration data for the realm and it is stored
] in the %windir% directory and the user is not an Administrator
] for the machine it is quite likely that the user cannot read the
] file.
] On Windows Vista/7/2008 the proper location for such a configuration
] file is \ProgramData\Kerberos but because KFW 3.2 was released before
] Vista and due to historical reasons, that is not the default location.
] Sites that deploy KFW when transforming the MSI installer to include
] their own krb5.ini file should store it at that location and set the
] system-wide KRB5_CONFIG environment variable to refer to it.

Thanks for all this careful help.

My student changed networks, and the problem went away,
so it was indeed a paranoid router.

] > They are not aware of any firewall issues that would be=20
] > preventing kerberos from getting through. =20
] > But that's the only thing I could think of,
] > since the server is accessible to everyone else,
] > and is accessible from their computer using ping.
] >=20
] > We still haven't solved earlier problems either.
] > I find it bizarre how four people running the latest
] > OpenAFS on Windows 7 on 64 bit machines can get four
] > completely different results.
] With all due respect, Kerberos issues are not OpenAFS issues.

Too true.

Thanks everyone,