I recently deployed a new remote access VPN system at my company, using a Cisco ASA 5510 as the concentrator. The protocol is L2TP-over-IPsec for maximum compatibility across clients, and authentication is handled by an RSA SecurID appliance. Everything works really well, except in one particular scenario: User's workstation is a domain member User is logging in to the local workstation as a domain user User is connecting to the VPN using the same user name as the logged-in account User attempts to access network resources, such as file shares or Microsoft Exchange In this case, the user's account is locked in Active Directory almost immediately after attempting to connect to a network resource (i.e. opening Outlook). I believe the issue is that Windows is attempting to use the credentials provided for connecting to the VPN. Because the username matches but the password does not, since it is actually a one-time password generated by the SecurID token, the authentication fails. Continuous attempts result in the account being locked out. Is there any way to tell Windows to stop doing this? I've tried disabling the "Client for Microsoft Networks" option in the VPN properties, but it didn't help.

Hi, If it repeatedly uses VPN account to access network resource, your assumeption is reasonable. You can confirm this point by checking Security log on PDC when there is a VPN session connecting. As it is a non-microsoft VPN product, you may need to ask the 3rd party provider to configure the settings, such as "not prompt for username and password". On client, you could try Enable this policy: Do not allow storage of credentials or .NET Passports for network Authenticatio(Windows Settings --> Security Settings --> Local Policies --> Security Options -->Network access) Restart to take effect. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

Brian, While the first part of your message doesn't make any sense, the security policy setting to which you referred seems to be exactly what I am looking for. Since the problem only affects domain-member workstations, it should be trivial to enable that setting using Group Policy. Thanks!