Weekend Scripter: Report on Network Level Authentication
Summary: Boe Prox shows how to use Windows PowerShell to report on Network Level Authentication.
Honorary Scripting Guy and Windows PowerShell MVP, Boe Prox, here today filling in for my good friend, The Scripting Guy. I plan to spend this Sunday showing you how you can report on whether your systems are enabled for Network Level Authentication.
By using PowerShell, we can make some amazing scripts and functions that can do a variety of things. Whether we want to build a complex workflow to provision a system, use Desired State Configuration to configure many systems, or even build a UI, we can pretty much do anything we want with Windows PowerShell…within limits.
One of the most simple things we can do (or maybe not simple, depending on the requirement) is report on certain configuration settings of a local or remote system and generate various kinds of reports such as CSV, HTML, or XML. Today we will use WMI to report on a Remote Desktop session setting called Network Authentication Level to see whether it is enabled on a system.
Before we dive into the process of finding and reporting on this, we should have a brief background as to what Network Level Authentication actually is.
Network Level Authentication has been around since Windows 2008, and it provides a way to better secure the Remote Desktop session by requiring a user to authenticate prior to making the connection to a server. Without it, you would be taken directly to the server's logon screen and already have a Remote Desktop session created to support this. Authenticating also forces the server to create several processes to support this and could help with a denial-of-service attack.
Now that we have an idea about what this is and how it can be useful to us, we need to take a look at our systems to see what is actually there and if we need to look at implementing a Group Policy, DSC configuration, or simple script to make this change on those systems. Regardless of our fix action, we need to figure out which systems are not compliant.
Fortunately for us, this setting happens to reside in WMI. This means we can use our approach of choice, Get-CIMInstance or Get-WMIObject to make our connection and pull this information. For this example, I am going to be running with Get-WMIObject.
Before I can actually start writing the code, I need to know what class and namespace I need to pull the data. For the namespace, I am going to use root/cimV2/TerminalServices and the class in question is Win32_TSGeneralSetting. Now that I have this figured out, we can make a quick query to my local system and see how it is configured:
$WMIParams = @{
Class = 'Win32_TSGeneralSetting'
Namespace = 'root\CIMV2\TerminalServices'
Filter = "TerminalName='RDP-Tcp'"
ErrorAction = 'Stop'
}
Get-WmiObject @WMIParams
Note that I have a WMI filter that is looking for only terminal names that are RDP-Tcp. This saves me some time by filtering on the system rather than pulling back a bunch of unneeded data and sorting that locally.
Of course, this is my local system, but it is more important when you scale this out to remote systems. The result that I get back looks something like the following image, which shows a wealth of information about this particular protocol setting.
We can also tell by UserAuthenticationRequired being set to 1 that Network Level Authentication is enabled on this system.
This is great and it tells us how we can quickly query systems to determine which ones have the setting enabled and which ones do not and need to be addressed. I’m not one to have a single piece of information to report on, so I wrote a function called Get-RDPCertificate which not only pulls this information but also looks at the certificate being used with this configuration and determines if it is a self-signed certificate or a CA-issued certificate. You can download the script from the Script Center Repository: Get-RDPCertificate.
A quick demo of the script against my local machine will again show you the Network Level Authentication setting. It also provides a deeper look into the certificate that is being used to host the session.
Get-RDPCertificate -Computername $env:COMPUTERNAME
Now I have a little more information to present if I am reporting for compliance. I looked to see if Network Level Authentication is enabled, and I also checked to see if I am using a self-signed certificate or one issued by a Certification Authority.
That’s all there is to using PowerShell to report on Network Level Authentication. Hopefully, you can make use of this function and knowledge to begin looking at your environment and reporting on the state of the configuration.
I invite you to follow the Scripting Guy on Twitter and Facebook. If you have any questions, send email to the Scripting Guy at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. Until then, see ya!
Boe Prox, Windows PowerShell MVP and Honorary Scripting Guy
Light
Dark
0 comments