This is applicable to SBS 2003 Running ISA 2000. The VPN was working fine, and then, one day it started getting 20189's several times per second until whatever account trying to connect was automatically locked out. Searched fruitlessly for a solution until I remembered I had a similar problem with RDP connections through the ISA which was fixed when I raised the MTU on the calling router.
I therefore locked the MTU on VPN connections for W2003 at 1500 using the instructions listed in ME826159
and the problem was instantly corrected.
In my case, this event occurred on the VPN access server because the user's session did not disconnect after logging off. This led to a "non-existent" active session. Under Computer Management, open Sessions and close that session.
- Error: "The user tried to connect using an unauthorized dial-in media" - See ME266460
to find out how to fix this problem.
From a newsgroup post: "I had a similar problem between my VPN at work and home. What worked for me was to change the LAN manager authentication level on the servers in the security options of the local security policy. I had mine set to the highest level – “send ntlmv2 response only/refuse lm and ntlm”. I had to back that off to – “send ntlmv2 response only/refuse lm”.
A good test to see what the problem is to create or use a test account in a different OU. Narrow it down to the user, group, or OU Container. Check the permissions on the OU container itself. Make sure "Authenticated Users" group if you have it listed has at least Read and not blank, also Administrators should have at least Read.
Error: "The current configuration only supports local user accounts." - Verify the RRAS settings - make sure it allows connections for domain users (not just for users configured locally on the RRAS server).
Error: "There was an authentication failure because of an unknown user name or a bad password." - Attempt to VPN into Windows 2000 Server fails. This started to appear after a registry setting of
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LsaREG_DWORD lmcompatibilitylevel to 5. Here is the list of levels:
Level 0 Send LM response and NTLM response; never use NTLMv2 session security
Level 1 Use NTLMv2 session security if negotiated
Level 2 Send NTLM authenication only
Level 3 Send NTLMv2 authentication only
Level 4 DC refuses LM authentication
Level 5 DC refuses LM and NTLM authenication (accepts only NTLMv2)
Switching the value down to 4 and allowing other authentication methods besides NTLMv2 has corrected the problem.