none
SBS2008/Win7 - VPN clients do not need credentials

    Question


  • Hi,

    I have an odd thing happening to the clients at one of my clients.
    They have decided that no VPN credentials should be cashed. I therefore made a group policy shown below.
    It works fine (grey check box in VPN connection window) and if they enter a valid usernam but leave the password field blank, they get rejected.
    The strange thing is that when they leave both the username and the password fields blank, they are connecting.
    It looks like their windows credentials are being passed along which is not desirable.
    Does anyone have a suggestion for a fix?

    /Lars

    Hive HKEY_LOCAL_MACHINE
    Key path SYSTEM\CurrentControlSet\Services\RasMan\Parameters
    Value name DisableSavePassword
    Value type REG_DWORD
    Value data 0x1 (1)

    Monday, October 24, 2011 9:21 AM

Answers

  • This is by design and there is no way to change this behavior
    Ketan Thakkar | Microsoft Online Community Support
    • Marked as answer by Lars Ågren Thursday, November 10, 2011 5:28 PM
    Thursday, November 10, 2011 1:32 PM
    Answerer

All replies

  • Try running this command from a command prompt - rundll32.exe keymgr.dll, KRShowKeyMgr

    It should clear the previously cached credentials.


    Regards, Boon Tee - PowerBiz Solutions, Australia - http://blog.powerbiz.net.au
    Monday, October 24, 2011 10:53 AM
  • Hi Boon,

    Thank you for the suggestion but no cashed credentials exists when I run the command, still it connects as long as the username/password fileds are left blank.
    We discovered it by accident as one of the users accidently pressed OK forgetting to enter any values.

    So far, I've only seen one case like this when searching the internet.

    /Lars

    Monday, October 24, 2011 11:07 AM
  • Is the local username and password the same as their domain logon?

    What happens if the user's domain password is changed? Are they still able to logon? If they are not, then the credentials must be cached somewhere.


    Regards, Boon Tee - PowerBiz Solutions, Australia - http://blog.powerbiz.net.au
    Monday, October 24, 2011 11:11 AM
  • Hi again Boon,

    There are no local accounts except "Administrator".

    The story so far:
    Logged on to a client (cached) and started the VPN without credentials - worked.
    Logged off and changed the password on the server
    Logged on again (cached) and tried VPN (again without credentials) - it didn't work.
    Entered the new password into VPN - worked
    Disconnected and tried again without credentials - didn't work

    It looks like, when I do not submit any credentials, the client forwards my cached windows credentials instead.
    There is an option for that under the security tab of the VPN settings but that box is unchecked.

    /Lars

    Monday, October 24, 2011 1:12 PM
  • What happens when you delete the VPN connection and create a new one?

    So far, it definitely sounds like the credentials are cached somewhere.


    Regards, Boon Tee - PowerBiz Solutions, Australia - http://blog.powerbiz.net.au
    Monday, October 24, 2011 3:11 PM
  • Good point Boon,

    I tried that just now but the result is the same.
    It doesn't matter if I create the VPN for "all users" or just the test account either.

    Thank you for for feeding me ideas. I'm a bit lost at this point.

    /Lars

    Monday, October 24, 2011 3:23 PM
  • Hi Lars,

    Thank you for your post.

    Please provide more information related your VPN issue:
    1. When you started the VPN without credentials: double click VPN connection, if it prompt the VPN credentials UI and you just leave the credentials(user name/Password/Domain) all blank?
    2. Run command "cmdkey /list" after you connected VPN session
    3. Check client and VPN server event log, confirm the VPN established by which type(like PPTP) and credentials(domain user account)
    4. Try to disable and re-able the NIC connection, then connect VPN

    If there are more inquiries on this issue, please feel free to let us know.


    Regards,
    Rick Tan
    Wednesday, October 26, 2011 6:11 AM
    Moderator
  • Hi Rick and thank you for joining!

    1.
    If I leave all fields in the VPN UI blank, the VPN connects without any problems.
    If I change the users password on the server (without updating the windows clients cached PW), if fails (thankfully)
    A clarification: I can only establish a VPN connection with blank fileds from domain connected computers logged on as a VPN enabled user.

    2.
    Below is the output of cmdkey /list while being connected to the VPN (INGEN = NONE)

    C:\Users\testkonto>cmdkey /list
    Aktuella sparade autentiseringsuppgifter:
    * INGEN *
    C:\Users\testkonto>

    3.
    I activated full Remote Access logging (including th debug option) and now have a bunch of log files to go through in %windir%\tracing. Do you know which log file(s) to focus on?

    4.
    The problem exists regardless of NIC (wired ,wireless) but I did it anyway and it had no effect.

    I'll go through the log files and report back. Man logs were empty so aybe it won't tack that long after all.

    /Lars

    Thursday, October 27, 2011 11:57 AM
  • Hi,

    Can you tell us what authentication method is used here?

     


    Ketan Thakkar | Microsoft Online Community Support
    Thursday, November 3, 2011 8:50 AM
    Answerer
  • This is by design and there is no way to change this behavior
    Ketan Thakkar | Microsoft Online Community Support
    • Marked as answer by Lars Ågren Thursday, November 10, 2011 5:28 PM
    Thursday, November 10, 2011 1:32 PM
    Answerer
  • Hi Ketan,

    I was just writing an answer to Rick as I read your latest reply.

    Do i understand you right when I say that:

    - On a domain connected computer, I can prohibit Windows from remembering Dial-up usernames/passwords through group policy but then the users only have to leave the fields empty and hit "connect"?

    If that is the case then I really have to check with other customers as well. I just assumed that this was a configuration error that was caused by me.

    Thanks for the clarification,

    Lars

    Thursday, November 10, 2011 5:27 PM