Find workaround for logging changes when the "Security Layer" is SSL/TLS

[EvanAnderson]

When an RDP client that supports SSL/TLS (rather than only "RDP" security, as was the case with older clients) fails authentication to the RDP server an IP address for the client won't be logged when the NtLmSsp security provider is used.

Arguably, SSL/TLS is a Good Thing(tm) (see http://technet.microsoft.com/en-us/magazine/ff458357.aspx) for details and I am wary of other invalid RDP logon block products suggestions to force the security layer to "RDP" (see http://rdpguard.com/windows-server-how-to-catch-failed-logons.aspx) because, while it does cause IP addresses to be logged, it prevents useful features (like mutual authentication) from being used.

The "Cyberarms IDDS" product came up with a workaround that allows the SSL/TLS security layer to remain enabled while still being able to log IP addresses. I'm going to look at their product to see if I'm able to determine what they're doing, however anything that involves compiled code is probably going to be above my interest level for ts_block.

[EvanAnderson]

I did some more research on this and it looks, to me, like there's no good way to handle it from VBScript.

I think this is likely the death knell for ts_block. It's difficult for me to get interested in putting more time into it if it's not going to work well with a more secure RDP listener configuration.

[LittleHann]

how Cyberarms IDDS are doing to get remote IP addresses？

[EvanAnderson]

I didn't do any reverse-engineering of their code to see. I suspect they're just rate-limiting new connections to the RDP port but I can't say for sure.

[dvolk]

I found the ips logged in

Application and services log - Microsoft - Windows - RemoteDesktopServices-RdpCoreTS - Operational, event id 140

[EvanAnderson]

@dvolk - On Windows Server 2012 R2 I do find client IP addresses in the log you reference. I don't immediately see a method to correlate these events to logon failures, however. I guess they could be used for simple rate-limiting, though.

[dvolk]

Do you not get these in event 140?

"A connection from the client computer with an IP address of xx.xx.xx.xx failed because the user name or password is not correct."

Maybe you have to turn on login failure auditing in the group policy.

[EvanAnderson]

Interesting. I have failure auditing for "Audit account logon events" and "Audit logon events" enabled.

Just to confirm, you're seeing this logged on Windows Server 2012 R2 w/ default RDP security layer settings -- correct?

I'll spend some time this weekend trying to repro.

[wilsncc]

I'm in the same position as @dvolk whereby there are no IPs logged in the Security events source and there is no way to enable it.

There are IPs logged in RemoteDesktopServices-RdpCoreTS in the 140 events.

[EvanAnderson]

Have a look at this post from two days ago: http://purerds.org/remote-desktop-security/auditing-remote-desktop-services-logon-failures-1/

I can confirm that I receive event ID 140 in RemoteDesktopServices-RdpCoreTS for non-existent usernames, per this post.

I don't have any Server 2016 available right now to see if the notes in the post hold true.

For Server 2012 (and 2012 R2), at least, it looks like I could just do rate-limiting of new connections (because correlating the event 131's from to the RemoteDesktopServices-RdpCoreTS log to the event 4625 in the Security Log is a dodgy hack that I'm not going to do).

[greatquux]

OMG. After reading that link it's obvious that Microsoft has really got to get their act together. But there's a good portion of us that can live with the restrictions of the RDP security layer + no NLA, and it's great to have this script working and blocking IPs that are attacking us.

[zparta]

There is good news in Windows Server 2016.
It creates an event in the Security log with Event ID 4625 and this is whats inside it:

An account failed to log on.

Subject:
	Security ID:		NULL SID
	Account Name:		-
	Account Domain:		-
	Logon ID:		0x0

Logon Type:			3

Account For Which Logon Failed:
	Security ID:		NULL SID
	Account Name:		ADMINISTRATOR
	Account Domain:		

Failure Information:
	Failure Reason:		Unknown user name or bad password.
	Status:			0xC000006D
	Sub Status:		0xC000006A

Process Information:
	Caller Process ID:	0x0
	Caller Process Name:	-

Network Information:
	Workstation Name:	-
	Source Network Address:	84.232.60.4
	Source Port:		0

Detailed Authentication Information:
	Logon Process:		NtLmSsp 
	Authentication Package:	NTLM
	Transited Services:	-
	Package Name (NTLM only):	-
	Key Length:		0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.
	- Transited services indicate which intermediate services have participated in this logon request.
	- Package name indicates which sub-protocol was used among the NTLM protocols.
	- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

[greatquux]

Yep I can totally confirm this is back to working without any security changes in Server 2016! WOO-HOO! Hopefully they won't break it again.