On 3/13/2010 6:51 AM, Jeff Blaine wrote: > Jeffrey, > > 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. So why is the problem the fault of OpenAFS or KFW? > 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 3. the problem is OpenAFS because there are two loopback adapters 4. the problem is the OpenAFS authentication tool, afscreds 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 kerbe...@mit.edu, 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 kerbe...@mit.edu 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 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
smime.p7s
Description: S/MIME Cryptographic Signature
