On 3/13/2010 9:19 AM, Jeffrey Altman wrote:
I've been using the VPN software on this box with no problems
for 2 weeks now.
And the rest of us have been running OpenAFS and KFW for many
years and have done so in conjunction with Cisco VPN software on
XP and Vista.
As have I.
So why is the problem the fault of OpenAFS or KFW?
Jeffrey, it was just a *thought* that maybe KfW or
OpenAFS under Windows 7 was doing something weird/wrong.
Is that really such a stretch, as someone who doesn't
know the source for these products inside and out, to
ping the list *to see if maybe* I've hit something that
nobody else has hit yet on such a new platform, or
maybe that someone *has* hit and has a solution for?
I ran into a new problem with the tools. I queried
the list and provided some info.
Thanks for the detailed reply, but you seem to read an
accusatory tone of some sort into everything I type -
like I've offended you by posting to the community with
a problem I've hit, and haven't been able to figure out
yet.
I can't really grasp why a report/question about
Cisco VPN + Windows 7 and the tools these lists
revolve around is so offensive/annoying to you.
I'm sorry I don't know immediately and exactly where to
look for the cause of problems like you do. I wish I
knew everything about everything, but I don't, and you
don't.
I posted to [email protected] with the initial screenshot
and query. I followed it up with something I thought
might be useful in order to get some help from someone,
running Network Identity Manager with logging on.
I then tried to narrow things down a bit and ran just
afscreds alone and got the same result. Because I don't
have your back+front knowledge of exactly how everything
is pieced together, I thought that maybe this was just an
OpenAFS problem and the original KfW problem was because
of the OpenAFS plugin. I posted to openafs-info.
What a pain I am.
I finally got around to installing OpenAFS + KfW yesterday.
After installing OpenAFS + KfW, it continues to work fine until
I tickle OpenAFS, at which point the VPN session drops.
You have an interop problem that you cannot explain but
how do you expect anyone to be able to help you when you
describe your problem in such absolute terms such as "tickle"?
So far you have stated:
1. the problem is KFW
2. the problem is NetIdMgr
I never separated the two. I stated that, to my apparently
stupid eyes, my VPN connection was dying every time I ran
KfW and tried to get credentials. Because, uh, that's what
I saw, with the original KfW and its Network ID Manager, and
then as a test with the v2.0 Network ID Manager. I tried it
a few times, could repeat it, had never experienced it before
under XP+OpenAFS+VPN+KfW, and queried the kerberos list to see if
"anyone has run into this?"
Apparently that's the same as saying "KfW is the problem."
3. the problem is OpenAFS because there are two loopback adapters
4. the problem is the OpenAFS authentication tool, afscreds
I never stated either of those things.
What I said was,
"This appears to be an OpenAFS problem (?), as I can
replicate it without Network ID Manager running."
NOTE: "appears to be" and "(?)" -- these items mean, "I
really don't know."
and
"I have to assume the 2 loopback adapters (VPN and AFS)
are stomping on each other, but don't know how to fix
that if it's the case."
NOTE: "I assume" "if that's the case" -- these items mean,
"I really don't know."
5. the problem is OpenAFS when it is tickled
Keep in mind that the Microsoft Loopback Adapter is active from the
moment that the machine boots and that the OpenAFS Service is also
active from boot time. If the VPN software, which is started later
works for some period of time and then drops, it is most likely not
due to the installation of those packages.
In the NetIdMgr v2 log that you sent to [email protected], you said
that the VPN disconnect occurs at a particular time. In the log at
that time the MSLSA credential cache is being accessed in an attempt
to import a TGT which is not present on your machine because you are
using a non-Domain logon.
You then later on said that the problem wasn't NetIdMgr but was instead
OpenAFS because the problem occurs when you start the AFS Authentication
Tool (afscreds). As I pointed out on the [email protected] mailing list,
afscreds is a Kerberos v5 credential manager and it also attempts to
import a TGT from the MSLSA: credential cache. Both tools do so in
an attempt to obtains AFS tokens for the user without prompting the
user to enter a principal and password.
What I bet is that you will find that if OpenAFS is uninstalled and the
loopback adapter is uninstalled and NetIdMgr is not running that the
problem can be reproduced by accessing the MSLSA credential cache using
the KFW command line tools:
klist -c MSLSA:
kdestroy -c MSLSA:
ms2mit
mit2ms
Uninstalled OpenAFS + loopback adapter, Network ID Manager not
running.
None of these commands (issued in the order above) bring the
VPN session down.
kinit [email protected] does, for whatever that's worth.
Assuming that I am right, someone with a debugger and access to the
Cisco software can step through the MSLSA credential cache and identify
exactly which Lsa operation is being executed that produces the
disconnect. At that point Cisco and perhaps Microsoft will need to be
brought into the discussion by the customer to identify how the MSLSA
access is affecting the Cisco VPN connection. Attempts to obtain a TGT
from an empty cache will cause Windows to attempt to obtain one from a
KDC. For a non-domain logon this should be a no-op. Perhaps there is a
bug in Windows, perhaps it is the VPN software being sensitive to
something it shouldn't be.
Jeffrey Altman
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
