When I use the new remote desktop with ssl and try to log on with bad credentials it logs a 4625 event as expected. The problem is, it doesn't log the ip address, so I can't block malicious logons in our firewall. The event looks like this:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
        <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{00000000-0000-0000-0000-000000000000}" /> 
        <TimeCreated SystemTime="2012-04-13T06:52:36.499113600Z" /> 
        <Correlation /> 
        <Execution ProcessID="544" ThreadID="596" /> 
        <Security /> 
        <Data Name="SubjectUserSid">S-1-0-0</Data> 
        <Data Name="SubjectUserName">-</Data> 
        <Data Name="SubjectDomainName">-</Data> 
        <Data Name="SubjectLogonId">0x0</Data> 
        <Data Name="TargetUserSid">S-1-0-0</Data> 
        <Data Name="TargetUserName">notauser</Data> 
        <Data Name="TargetDomainName">MYSERVER-PC</Data> 
        <Data Name="Status">0xc000006d</Data> 
        <Data Name="FailureReason">%%2313</Data> 
        <Data Name="SubStatus">0xc0000064</Data> 
        <Data Name="LogonType">3</Data> 
        <Data Name="LogonProcessName">NtLmSsp</Data> 
        <Data Name="AuthenticationPackageName">NTLM</Data> 
        <Data Name="WorkstationName">MYSERVER-PC</Data> 
        <Data Name="TransmittedServices">-</Data> 
        <Data Name="LmPackageName">-</Data> 
        <Data Name="KeyLength">0</Data> 
        <Data Name="ProcessId">0x0</Data> 
        <Data Name="ProcessName">-</Data> 
        <Data Name="IpAddress">-</Data> 
        <Data Name="IpPort">-</Data> 

It seems because the logon type is 3 and not 10 like the old rdp sessions, the ip address and other information is not stored.

The machine I am trying to connect from is on the internet and not on the same network as the server.

Does anyone know where this information is stored (and what other events are generated with a failed logon)?

Any help will be much appreciated.


Using TLS/SSL as encryption for the RDP protocol, Windows does not log the IP address of the user trying to log in. When you configure the server to encrypt the protocol with the (legacy) RDP encryption, it writes the IP address into the security event log.

You will have to make a trade-off. Either you will have a less secure protocol encryption or you will never know the source of a potential attack. Having the right intrusion detection system (can be downloaded for free), the system will automatically lock out the potential attacker after a defined number of invalid logins.

Read more about RDP security and intelligent intrusion detection and defense here: https://cyberarms.net/security-blog/posts/2012/june/remote-desktop-logging-of-ip-address-(security-event-log-4625).aspx

| improve this answer | |
  • Stop spreading FUD! FYI, see my answer on how to both use SSL (i.e. confirmed server identity w/ no warnings on clients) and get Source Network Address in Event ID 4625 in the audit log. – wqw Oct 17 '15 at 12:55
  • I don't think this is true in Win10, as my honeypot is logging RDP successes and failures just fine, with IPs and with TLS enabled. – user145837 Aug 7 '19 at 3:16

In secpol.msc open Local Policies | Security Options set Network security: Restrict NTLM: Incoming NTLM traffic to Deny all accounts. This cannot be used with NLA but works with SSL (the SSL info icon on the topbar of mstsc.exe client confirms server identity) and sucessfully records source network address in failed Event ID 4625 in the audit log.

Here is my before log

Oct 17 13:59:22 TS04.ucssaas.local rdp-farm: {"EventTime":"2015-10-17 13:59:22","Hostname":"TS04.ucssaas.local","Keywords":-9218868437227405312,"EventType":"AUDIT_FAILURE","SeverityValue":4,"Severity":"ERROR","EventID":4625,"SourceName":"Microsoft-Windows-Security-Auditing","ProviderGuid":"{54849625-5478-4994-A5BA-3E3B0328C30D}","Version":0,"Task":12544,"OpcodeValue":0,"RecordNumber":1366552,"ProcessID":568,"ThreadID":35244,"Channel":"Security","Category":"Logon","Opcode":"Info","SubjectUserSid":"S-1-0-0","SubjectUserName":"-","SubjectDomainName":"-","SubjectLogonId":"0x0","TargetUserSid":"S-1-0-0","TargetUserName":"wqw","TargetDomainName":"UCSSAAS","Status":"0xc000006d","FailureReason":"%%2313","SubStatus":"0xc000006a","LogonType":"3","LogonProcessName":"NtLmSsp ","AuthenticationPackageName":"NTLM","WorkstationName":"CVETKOV-C3414E6","TransmittedServices":"-","LmPackageName":"-","KeyLength":"0","ProcessName":"-","IpAddress":"-","IpPort":"-","EventReceivedTime":"2015-10-17 13:59:24","SourceModuleName":"eventlog","SourceModuleType":"im_msvistalog"}#015

and after

Oct 17 14:00:36 TS02.ucssaas.local rdp-farm: {"EventTime":"2015-10-17 14:00:36","Hostname":"TS02.ucssaas.local","Keywords":-9218868437227405312,"EventType":"AUDIT_FAILURE","SeverityValue":4,"Severity":"ERROR","EventID":4625,"SourceName":"Microsoft-Windows-Security-Auditing","ProviderGuid":"{54849625-5478-4994-A5BA-3E3B0328C30D}","Version":0,"Task":12544,"OpcodeValue":0,"RecordNumber":2613410,"ProcessID":564,"ThreadID":17112,"Channel":"Security","Category":"Logon","Opcode":"Info","SubjectUserSid":"S-1-5-18","SubjectUserName":"TS02$","SubjectDomainName":"UCSSAAS","SubjectLogonId":"0x3e7","TargetUserSid":"S-1-0-0","TargetUserName":"wqw","TargetDomainName":"UCSSAAS","Status":"0xc000006d","FailureReason":"%%2313","SubStatus":"0xc000006a","LogonType":"10","LogonProcessName":"User32 ","AuthenticationPackageName":"Negotiate","WorkstationName":"TS02","TransmittedServices":"-","LmPackageName":"-","KeyLength":"0","ProcessName":"C:\\Windows\\System32\\winlogon.exe","IpAddress":"","IpPort":"0","EventReceivedTime":"2015-10-17 14:00:37","SourceModuleName":"eventlog","SourceModuleType":"im_msvistalog"}#015

Basicly source WorkstationName is lost and now it show RDSH server name instead but you get IpAddress in exchange. This shows the change that happened underneath "LogonType":"3","LogonProcessName":"NtLmSsp ","AuthenticationPackageName":"NTLM" is changed to "LogonType":"10","LogonProcessName":"User32 ","AuthenticationPackageName":"Negotiate"

I'm using this setting on several Win2012 R2 session hosts and did tests with several sucessful/failed logon sessions from mstsc.exe clients on Win XP machines (latest mstsc.exe version 6.1.7600 for XP).

(The log above is from rsyslog on a haproxy load-balancer that collects audit logs from RDSH boxes that are being forwarded by nxlog service in JSON format. There is a fail2ban jail on the haproxy that blocks clients by IP after a number of failed logon attempts.)

| improve this answer | |
  • I have installed all updates on both server (Win2k12R2) and client (Win10), but when I follow these instructions, I get the following error trying to log-on: "An authentication error has occurred. The function requested is not supported This could be due to CredSSP encryption oracle remediation. For more information, see go.microsoft.com/fwlink/?linkid=866660" – tommed Aug 8 '18 at 19:52
  • I'm using this setup in production in an AD domain with a separate RD connection broker server for the RD farm, not sure which one makes the difference. – wqw Aug 10 '18 at 11:44
  • @tommed you must turn of NLA – jjxtra Aug 13 at 1:49

I have found this article about log files for RDP session. I hope it will be helpful to you.


I don't see one either - what is the problem specifically?

Taking a guess based on the Subject, check the Windows XP Security Event Viewer Log. An Audit Policy may be configured using the Group Policy editor to track logon success and failures: From the Start | Run command window type gpedit.msc. Navigate to Local Computer Policy | Computer Configuration | Windows Settings | Security Settings | Local Policies | Audit Policy | Audit logon events. Highlight and right-click and select properties. Configure as desired.

Note that logging in without a password is logged as a failure. This results in the security log filling up very fast if you log failures and have a user without a password. The result is you can not login normally. Also note, not having a password is a potential and probable security risk.

The event log can be viewed by going to Start | Control Panel | Performance and Maintenance | Administrative Tools and click on Event Viewer.

The Event Log (Security) noting a successful logon and logoff by a remote user. The user can highlight a log entry and right-click to view the event Properties for detailed information.

Look in the Security Event Log for a Logon/Logoff Event 528 and Logon Type 10.

The free Microsoft Port Reporter tool provides for additional logging. Description of the Port Reporter Parser (PR-Parser) tool http://support.microsoft.com/default...b;en-us;884289

Availability and description of the Port Reporter tool http://support.microsoft.com/kb/837243

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.