none
RDP Login with local account

    Question

  • I have a domain member server and I'm trying to RDP to the server with a local account. I'm getting denied 3 times, then I get the certificate prompt window and if I continue I see the RDP session window stating that the account is locked out. If I go unlock the local account (through a console session I already had established), and then go back to the RDP window and try to log in again I am allowed to RDP to the server.  For the failed RDP attempts, the event logs show a login type (3) getting denied due to a bad username or password.  Then, after I unlock the account and try again, the event logs show a login type of (10) and a successful login occurs.  I'm using the same local account and password each time.  Console logins with the local accounts work fine.  I'm leaning towards it being an NTLM issue but I'm not sure. 

    We have a group policy preference item renaming the local administrator account.  We also have the following two Network Security Policies set using a GPO

    Network Security: Do not store LAN Manager hash value on next password change - Enabled

    Network Security: LAN Manager authentication level - Send NTLMv2 response only. Refuse LM & NTLM

    Has anyone experienced this type of behavior before?

    Thanks,

    Michael

    Friday, November 15, 2013 3:41 PM

Answers

  • Hi Michael,

    Thanks for the reply.

    If the threshold of account lockout policy is 3, I can image that the issue is related to NTLM configurations.

    After reading the article, Security Watch-The Most Misunderstood Windows Security Setting of All Time, it seems that client will not send NTLMv2 message with Level 1.

    Send LM and NTLM—use NTLMv2 session security if negotiated

    Sends: LM, NTLM, NTLMv2 Session Security is negotiated

    Accepts: LM, NTLM, NTLMv2

    Prohibits Sending: NTLMv2

    Therefore, I suggest to set the Level to 2 on client side and test the issue again.

    Hope this helps.


    Jeremy Wu

    TechNet Community Support

    • Marked as answer by Hollisorama Wednesday, November 20, 2013 4:44 PM
    Wednesday, November 20, 2013 9:54 AM
    Moderator
  • I tested with level 2 (Send NTLM response only) and level 3 (Send NTLMv2 response only) on the client.  Level 3 worked and level 2 did not work.

    Thanks for your help!

    Michael

    • Marked as answer by Hollisorama Wednesday, November 20, 2013 4:44 PM
    Wednesday, November 20, 2013 4:43 PM

All replies

  • Hi,

    Logon Type 3 – Network

    Windows logs logon type 3 in most cases when you access a computer from elsewhere on the network. One of the most common sources of logon events with logon type 3 is connections to shared folders or printers. But other over-the-network logons are classed as logon type 3 as well such as most logons to IIS.

    Logon Type 10 – RemoteInteractive

    When you access a computer through Terminal Services, Remote Desktop or Remote Assistance windows logs the logon attempt with logon type 10 which makes it easy to distinguish true console logons from a remote desktop session. 

    Regarding the issue, what do you mean that the account is locked out? How do you unlock the account? Do you use mstsc.exe to remote to the machine?

    In addition, please let us know the OS of the client and server.

    Meanwhile, when you RDP to the server with a local account, please use the following format for account name:

    Server name\account name.

    Thanks.

      


    Jeremy Wu

    TechNet Community Support

    Monday, November 18, 2013 7:24 AM
    Moderator
  • Hi Jeremy,

    Thanks for replying.  I have narrowed the issue down to the Network Security: LAN Manager Authentication level settings in our environment.  By default, all our servers are set at level 5 (Send NTLMv2 responses only. Refuse LM & NTLM) and our clients are set at level 1 (Send LM & NTLM - use NTLMv2 session security if negotiated).  This is the reason for the issue when using local accounts for RDP access.  I read this article (http://technet.microsoft.com/en-us/magazine/2006.08.securitywatch.aspx) which goes in depth about the various compatibility settings.  It seems that some time in the past, the configuration was made in our environment due to a security audit but I don't have any other details.  I'm not clear what setting change we could make that would still protect us from whatever vulnerability was revealed by the audit and allow us to use local accounts for RDP access.  We have a mixture of server OSs (2003, 2003 R2, 2008 & 2008 R2) and client OSs (XP, Windows 7 and Windows 8.1).  We are using mstsc.exe as the RDP client.  We are using your suggestion for the account name.  I unlock the account through a console session on the server.  I have no trouble logging in with a local account using a console connection.Thanks, Michael

    Monday, November 18, 2013 8:17 PM
  • Hi Michael,

    Thanks for the reply.

    If the threshold of account lockout policy is 3, I can image that the issue is related to NTLM configurations.

    After reading the article, Security Watch-The Most Misunderstood Windows Security Setting of All Time, it seems that client will not send NTLMv2 message with Level 1.

    Send LM and NTLM—use NTLMv2 session security if negotiated

    Sends: LM, NTLM, NTLMv2 Session Security is negotiated

    Accepts: LM, NTLM, NTLMv2

    Prohibits Sending: NTLMv2

    Therefore, I suggest to set the Level to 2 on client side and test the issue again.

    Hope this helps.


    Jeremy Wu

    TechNet Community Support

    • Marked as answer by Hollisorama Wednesday, November 20, 2013 4:44 PM
    Wednesday, November 20, 2013 9:54 AM
    Moderator
  • Do you mean to use the setting "Send NTLMv2 response only" on the client?
    Wednesday, November 20, 2013 4:28 PM
  • I tested with level 2 (Send NTLM response only) and level 3 (Send NTLMv2 response only) on the client.  Level 3 worked and level 2 did not work.

    Thanks for your help!

    Michael

    • Marked as answer by Hollisorama Wednesday, November 20, 2013 4:44 PM
    Wednesday, November 20, 2013 4:43 PM
  • Hi Michael,

    Glad to hear that the issue has been resolved.

    Cheers!


    Jeremy Wu

    TechNet Community Support

    Thursday, November 21, 2013 2:04 AM
    Moderator