New blog is running on Writefreely. Which is a nice project for simple blogging. All previous content has been copied over with a quick conversion to fit the new format.
No content has been edited beyond that.

Originally posted on 2019-10-12 on the old blog

There are many guides out there on how to implement Kerberos for application x-y-x.

But there are surprisingly few going into some of details that are important for the understanding what you are doing exactly.

So with this article I am going to hopefully help you understand how Kerberos works in a general sense, and that is not as difficult to implement as you might think (as long as you have the all the pieces of the puzzle).

What is Kerberos?

Kerberos is a modern authentication protocol for strong and secure authentication in a network and indeed across any network.
It is safe enough to be used across the the internet, but is rarely used in a configuration like that because the setup requirements makes it impractical.

Using Kerberos requires pre-existing knowledge of you client endpoints which is simply not practical in a public facing site.
But it can technically be used with a internet roaming (pre-configured) client, as long as the client can find and talk to the KDC and app server.

Kerberos it is in active developed by Massachusetts Institute of Technology.
More information can be found at its official site at MIT here.

How does Kerberos work?

The exact workings of Kerberos can be rather complicated.
But in general authentication to a service using Kerberos is between 3 devices; the client, the Key distribution center (KDC) and the application server.

Here is the (very simplified) process to access a resource on the app server using Kerberos:

* Client sends a authentication request (AS_REQ).
* KDC replies with to the (successful) request with a encrypted access ticket "TGT" (AS_REP).
* Client requests a service ticket for the app server from the KDC using the TGT ticket (TGS_REQ).
* KDC replies with a service ticket encrypted with the app server's secret key (TGS_REP).
* Client requests access to a resource on the app server using the service ticket (app server decrypts it using its own key) (AP_REQ).
* Optional: App Server replies to client to prove it the server the client is expecting (when mutual authentication is required) (AP_REP).

Going into the details would be a article all on its own, but the Kerberos Consortium has an excellent tutorial available here for those that are curious.

Kerberos in practice

Armed with the knowledge above we can go into the practical workings of Kerberos. And while I am going to focus on the implementation in a Microsoft Active Directory environment, I will start by killing off some myths.

For simplicity sake i will refer to Microsoft Active Directory as "AD DS".

Myth: Kerberos authentication can only be used by clients in a a AD DS enviroment

This is perhaps one of the most important misconceptions to get rid of.
As you might have noticed above Kerberos is a protocol under the MIT licence, and as such it has been implemented in various ways (AD DS, MIT Kerberos, Heimdal and so on).
Per krb5-1.13 onwards; interoperability between the implementations should be quite good, since support for a lot of the extensions has been added to the original source (ref.: Kerberos Features).

The only real requirements for using Kerberos from the client side is that it has a Kerberos client installed, and that it can communicate with the KDC to get it's tickets.
Windows and MacOS comes with a Kerberos client pre-installed, and most Linux distros has a pre-compiled version available in their repositories.
But basically it can work on any OS as long as you can compile the source for it.

There is of course also the requirements that the application or service can negotiate the protocol properly as well.
For example the Chromium project properly supports negotiating the protocol in HTTP scenarios.

Fun fact: You can add your Windows workgroup computer to a Kerberos realm using the ksetup tool. Though if it is a AD DS realm I recommend joining the computer properly to the domain.

Myth: Kerberos is an outdated authentication protocol

This is one i heard the other day.
When I asked someone to look into implementing Kerberos on a MS Exchange server (to move away from NTLM), I was told that this was unnecessary work:
“Kerberos is an outdated method that will be replaced by a more modern authentication method when moving to Office365.”

Granted Kerberos is not entirely suited for authentication for end user services using Azure AD across the internet, but it is in no way or form an outdated protocol.
Inside a on-premise AD DS it is by far the most seamless and secure SSO solution you can implement (maybe with the exception of using certificates, but the added complexity there can be immense).

Concepts for successful use of Kerberos

There are three primary concepts to understand in a Kerberos setup; realm, principal and ticket.

Realm

A realm indicates the boundaries in which the authentication is handled.
In AD DS this is for all intents and purposes basically what we are talking about when we talk about a domain.
In authentication scenarios this is often written as for example @ANITBLOG.NO.

Note: In Kerberos the realm name is case sensitive, in most situations it is common to simply write it in upper case.

Ticket

There are a lot of parts to a ticket, but for practical purposes a ticket is what identifies principals.

The tickets are encrypted with with the secrets (passwords) of the various principals.
A ticket is reusable and it is not possible for a KDC to control its use after it has been transmitted (you can only really deny the creation of new ones).
Therefore a ticket has several properties indicating it's use, and a predefined lifetime to limit potential abuse.

By default the lifetime of a ticket is 10 hours but this can be changed (usually shortened) depending on requirements.

Principals

Principals are the identifier for entities in a authentication database.
In short they are what identifies a user, host or service.
This is probably the part that trips people up the most during configuring Kerberos.

First a thing to note: In a AD DS you have probably touched upon the property "userPrincipalName" (UPN).
This is not the same as a Kerberos principal.
UPN are configured as an alternative logon username and is us usually configured to the user's mail address (description of the property can be found at MS Docs).
It has no bearing on the Kerberos authentication process.

USER principal

The user principal name identifier of an AD object is based on it's sAMAccountName.

For for a user with the sAMAccountName “johnsmith”, the full principal name would then be “johnsmith@ANITBLOG.NO”.

For computer objects in AD DS, they get a “$” added to the sAMAccountName automatically.
So in that case the user principal name for the computer account would be “mycomputer$@ANITBLOG.NO”.

The user principal name is what would be used during the user identification part of the authentication process (AS_REQ/AS_REP).

Service Principal

The “service princpal name” (SPN) is what identfies a service in the Kerberos authentication process (TGS_REQ/TGS_REP).

In AD DS this is defined in the AD-object attribute _servicePrincipalName_.
This is a multi string attribute. And can contain several identifiers.

When the KDC gets a request for a service ticket it will look for a SPN matching the request.
If it finds a match it will send back a service ticket encrypted with the credentials of the AD-object the that has the SPN assigned.
If the KDC is unable to find a SPN matching the request, then the authentication fails.

The above is extremely important to note and is why Kerberos often fails!
For Kerberos to work the correct SPN must be found!

Service principals are usually written as <service>/<host> so for a http (or https) server in my example realm the SPN would be something like http/webserver.anitblog.no.
The full service principal name would then be: http/webserver.anitblog.no@ANITBLOG.NO.

Also remember that this is reliant on name resolution, so if you access the server with only the NetBIOS name you would also need a entry for http/webserver too!

Herein also lies another stumbling block; the DNS name resolution.
If you use a A/AAAA record to reach your server all is well, the SPN gets resolved correctly.
However if you use a CNAME then you might get issues.

If in our case webserver.anitblog.no is a alias for iishost.anitblog.no, then the SPN that will be requested will most likely be for http/iishost.anitblog.no instead, which might fail depending on configured SPN!

Usually the simplest is to avoid CNAME records and use A/AAAA records instead.
Depending on the use case you might simply add the SPN needed to the host server.

Or in case of load balancing; you would use a service account with the correct SPN running the service itself, and have the DNS record resolve to the load balancer.

The balancer then redirects the traffic to the back-end servers which can decrypt the service tickets using the service account credentials.
Usually no authentication should be handled on the balancer itself, but there might be scenarios where this is needed.
But that would be out of scope for this guide.

The “HOST” SPN

Note that there is a special type of service called HOST. This is actually a alias for several known service types.

The alias is defined in the sPNMappings attribute on the Directory Service object found at:

"CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=EXAMPLE,DC=COM". 

In general unless you have a very good reason you should avoid messing with this attribute.
But it is useful to be aware of this.

Also if a specific entry is made for one of the services HOST is an alias for, then the specific entry will be used and the HOST alias is ignored.

The SPN search pattern is basically something like this (using http/ as an example):
KDC looks for "http/<host>" -> "http/<host>" found on object -> All good!

KDC looks for "http/<host>" -> "http/<host>" not found -> substituting "http/<host>" with "HOST/<host>" -> "HOST/<host>" found -> All Good!

KDC looks for "http/<host>" -> "http/<host>" not found -> substituting "http/<host>" with "HOST/<host>" -> "HOST/<host>" not found -> Fail!  

Working with service principal names

So now we know a bit on the authentication process for Kerberos.
Lets take a closer look at SPN that are required for all this to work.

Modifying SPN

As noted earlier the SPN are defined in the AD attribute servicePrincipalName this means that any method of editing AD attributes of a object is valid for for modifying SPN.

The most commonly used way is to use the tool setspn.exe but it is by no means the only method (here is a reference for the tool).

You can also use the Active Directory PowerShell cmdlets, for example by using parameter -ServicePrincipalName.
Or you can modify it using the PowerShell accelerator [ADSI].

You can of course also edit it using GUI tools like “AD Users and Computers”, “ADSI Edit” or even ldp.exe.

Using setspn.exe is pretty straight forward like this:

This will assign the SPN "http/webhost.anitblog.no" to the AD object  "iishost" 

setspn.exe -s http/webhost.anitblog.no iishost

Adding SPN using the PowerShell cmdlets:

This will assign the SPN “http/webhost.anitblog.no” to the AD computer “iishost”

Set-ADComputer -Identity “iishost$” -ServicePrincipalNames (@{Add=“http/webhost.anitblog.no”})

Note that we are using the sAMAccountName here so we add a $ at the end of the identity.

While only showing for the cmdlet ADComputer, process is similar on ADUserand ADServiceAccount.

ADObject cmdlets require a bit more effort to use but they could allow you to make a script that works regardless of AD object type.

Here we first need to find the object using a Get-ADObject filter.
Then we pipe it to Set-ADObject using the parameter -Add to add our SPN to the servicePrincipalName attribute.

Get-ADObject -Filter "sAMAccountName -eq 'iishost$'" | Set-ADObject -Add @{servicePrincipalName="http/webhost.anitblog.no"}

Using ADSI can be a bit difficult but nonetheless possible as well:

Create the ADSI object

[ADSI]$ADObject = (([adsisearcher]'sAMAccountName=iishost$').FindOne()).Path

Append SPN to the object

$ADObject.PutEx('3', 'servicePrincipalName', @('http/webhost.anitblog.no'))

Write info back to directory

$ADObject.SetInfo()

Working with ADSI is pretty low-level as you are working directly with .net classes.
You rarely will need to do this, but it should always be available on any Windows computer past Windows 7.

Some more details on the PutEx method can be found in MS Docs.
Also here is a quick reference the PutEx actions:
CLEAR = 1 UPDATE = 2 APPEND = 3 DELETE = 4

In general most methods will fail if you try to create duplicate SPN.
But some tools might misbehave so it can still happen....

Finding SPN

In any case it is useful to know some commands to check if an SPN has been set, so here are a few ways to do that.
If you are trying just to quickly check if a SPN is defined use you can use:

setspn.exe -Q <SPN>

Using PowerShell cmdlet Get-ADObject you can do it like this (this also support wildcards):

Get-ADObject -Filter 'servicePrincipalName -eq "http/webserver.anitblog.no"' -Properties Name,servicePrincipalName

And using [ADSISearcher]:

([adsisearcher]'servicePrincipalName=http/webserver.anitblog.no').FindAll()

If you are simply trying to find any duplicates while troubleshooting the most simple way is:

setspn.exe -X

If you are automating I would strongly recommend using either the PowerShell cmdlets or if the AD-cmdlets are not installed, use the accelerators (which should always be available from Win 7 and onwards). These will make it easier to handle errors since they will output native .net objects or exit codes you can use. If you were to use setspn.exe you would have to parse the string output.

Putting it all into use

Now we should have a decent grasp of the requirements on the KDC side of things so lets move on practicals.
I am not going to dive very deep into this, as that would warrant it's own article. But we will go over the basics.

Clients

On the client side; if your Windows client is in the domain, no further configuration is needed to use Kerberos.
All of this is handled in the background.

On MacOS or Linux (or Windows client in a workgroup) you will have to configure you Kerberos client to be able to get valid tickets from the Kerberos realm.
In most cases this involves invoking [kinit](https://web.mit.edu/Kerberos/krb5-latest/doc/user/user_commands/kinit.html), or using [ksetup](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/ksetup) on Windows.
Of course it is possible to use other Kerberos implementations on Windows depending on requirements as well.

Also to note: Microsoft has expanded Kerberos with something called "Service4User" (S4U).
This is also often referred to as protocol transition.
This extension allows a service to contact a KDC on behalf of a client if they can provide the correct credentials through other means.
This can be by for example; username and password (basic, NTLM) or client certificate.
Details on the extension can be found here.

Servers

Servers have pretty much the same requirements as clients.
They need to have a working Kerberos client, so if your Windows Servers are joined to the domain, you are all good.

For other platforms you would usually need to create Kerberos keytabs to store their credentials, and use those with for example kinit.
In AD DS, keytab creation is done with [ktpass](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/ktpass), for other platforms this is usually done with the tool [ktadd](https://web.mit.edu/Kerberos/krb5-latest/doc/admin/appl_servers.html).

VERY IMPORTANT!It cannot be stressed enough but a keytab is very much the equivalent of storing a username and password in a clear text file.And as such it must be protected in the same way (absolutely do not send it by e-mail for example).

For your services; as long as you assign the correct SPN to the account running your service (computer, user or service account).
Or the server running the service can access the credentials on behalf of the account with the SPN, things should just work™ (mostly depending on the service itself)....

Summary

So to summary this very long article; while Kerberos itself is a complex beast, using it needs not be so.

In your AD DS all the pieces are already in place, so the most important detail is simply to set the SPN correctly.

Second important part is to that pay attention to how the service names gets resolved by the DNS.
This is a vital part of how the client figures out just which service they are requesting access to (so be careful when using CNAME).

But before we leave I have a few points that needs to be covered.

IIS Negotiate

On a IIS server with Windows Authentication it is strongly recommended to only have Negotiate as the provider, unless you have a specific specific issue.
The HTTP Auth Negotiate method is implemented in most http clients (like in Chromium as mentioned earlier), and it will negotiate the use of strongest available authentication method.

Usually this means that Kerberos will first be attempted, and if that fails it will fall back to NTLM.

You can also force the use of Kerberos by using Negotiate:Kerberos if the service should only be available when authenticated with Kerberos.

Kerberos encryption ciphers

In short Kerberos can work using several encryption types.
For a AD DS these are:
DES_CBC_CRC
DES_CBC_MD5
RC4_HMAC_MD5
AES128_HMAC_SHA1
AES256_HMAC_SHA1

Of these it is only recommended to use the AES ones.
The DES type are disabled by default in most versions of AD DS, but RC4 is still enabled by default.
It is strongly recommended that the RC4 cipher is disabled and that only AES types are allowed.
Here is Microsoft's information on this.

When you are working on disabling RC4 pay close attention if the domain is part of a forest.
In that case the domain trust must be marked as supporting AES as well.
Microsoft has a KB on this here.

Comments

While I have have only glanced by some points, I hope this will be a helpful primer on understanding and fully utilizing Kerberos.

As always; please comment if there is something that incorrect or unclear. I'll be happy to correct it.

Originally posted on 2019-06-14 on the old blog

This is a followup on my post DFS domain name resolution headaches.

Occasionally there are times when the solution seems correct since it fixes the issue there and then. But then it turns out you where looking in the entirely wrong place.....

Turns out the issue was the rather common issue of using DFS together with Offline files.
If Offline files is enabled and Windows detects a “poor connection” it will automatically go into Slow-Link mode which drops all connection/access to the DFS share beyond those files that have been selected for caching (selected either automatically or by the user).

The simple solution to this is to configure the “Slow-Link” setting in a computer configuration GPO.
By default slow-link will initiate at 80ms on Win7 and 35ms on Win8 and onwards.
Preferably you should set your DFS root to a high latency (like a 1000ms). Then you can for example set the user network folder to something like 50ms or 100ms.
For example like this:

\\example.com\DFSRoot Latency=1000
\\example.com\DFSRoot\Users Latency=100

Now that the solution is found it seems obvious, and it also seems strange that the cause was not discovered earlier.

However this is is where the !fun is; usually only you laptops would have enabled Offline files (desktops are usually always connected to the network), and indeed that is how it looked in our GPO... that is filtering with a WMI query for laptops.
So why did we also have desktops with this same issue?
Well... don't let your colleagues check the computer form factor by simply query kind of RAM form factor is used, desktops too can have SO-DIMM modules.... 🤨

So what have i learned from this?
- If you have any issues at all with DFS connections, verify your Offline files configuration. And remember to configure Slow-Link.
- Even if the GPO WMI filter is named “Laptops Only”, does not make it true.
Select * from Win32_PhysicalMemory WHERE (FormFactor = 12) do NOT a laptop make....

Originally posted on 2018-12-05 on the old blog

EDIT!: An update to this six months later....

So here is a quick one; ever had issues with DFS (Distributed File System) share being unable to resolve their name properly at seemingly random times?

If the answer is yes, here is a quick solution to test: Try appending a “.” (dot) at the end of the fully qualified domain. So \\anitblog.no\DFSRoot would become \\anitblog.no.\DFSRoot.

The reason for this is that appending the dot to a FQDN makes it an absolute query instead of an relative one.

Instead of rephrasing someone else, here is an explanation about dots in name resolution: https://stackoverflow.com/questions/19480767/domain-names-with-dots-at-the-end

Originally posted on 2018-11-09 on the old blog

I stumbled into an issue recently with Thunderbolt enabled computers.

By default the Thunderbolt Software that is used to approve Thunderbolt devices requires local administrator to work, this is not really practical in enterprise environments where most users are not local administrators.

So i dug into it and found some solutions to this issue.

Solution 1 – Disable User Authorization

The simplest solution is to go into your device BIOS and change your Thunderbolt settings from “User Authorization” to “No Security” (exact wording varies depending on device).

This however is not really recommended as you would be compromising the security of the device.

By doing this you are essentially exposing a PCIe bus to the outer world without any form of security, enabling easy access for a DMA attack. Though there are use cases where this might be useful nonetheless....

Solution 2 – Disable local admin requirement

The second and recommended solution is to simply disable the requirement for a administrator to approve Thunderbolt devices.

In simplest terms it comes down to changing the registry property “ApprovalLevel” value to “1” under the registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ThunderboltService\TbtServiceSettings

However this is not as straight forward as it would seem, as this key has some very restrictive permissions. Basically only the Thunderbolt service can change it, so even a local admin would not be able to change it normally.

Now there are two ways to solve this: Now there are three ways to solve this:

Solution 2A – Reinstall application

The first solution out there is easily available, it basically boils down to this: – Uninstall the Thunderbolt Software – Reboot – Change registry property – Reboot (optional but recommended) – Install Thunderbolt Software – Connect all the devices you want

This is a straight forward if cumbersome way to handle it (especially if you have to do this on several computers).

I have also had one issue with this that the installer actually created a new key with the exact same name (which i did not think was even possible)!

To make things easier for me i developed a PowerShell script to change this registry key, so on to the next solution!

Solution 2B – Script your way out

So after butting heads with the keyboard for a while i came up with a scripted way to solve this.

In summary the script is doing these actions. – Backup original ACL settings for the key in question. – Using .Net methods apply full access for “NT Authority\SYSTEM” account on the key. – Change the property in registry. – Reset ACL based on backup. – Pack script in a Scriptblock and encode it in a Base64 string – Create a Scheduled Task with the encoded command as action launched by PowerShell, and SYSTEM as the running user (with high access). – Run task immediately – Delete task afterwards

#Change Thundebolt Software approval level to allow users to accept Thundebolt equpiment without being local admin

#Created by Jens-Kristian Myklebust <jensmyklebust@outlook.com>
#Create Script payload
$TBFix ={

    #Registry key to modify
    $RegistryKey = "SYSTEM\CurrentControlSet\Services\ThunderboltService\TbtServiceSettings"
    
    #Store original ACL info
    $ACLinfo = Get-Acl "HKLM:\$RegistryKey"
    
    #Modify ACL using .Net methods, and give "SYSTEM" user full access to registry key
    $RegKeyDotNETItem = [Microsoft.Win32.Registry]::LocalMachine.OpenSubKey($RegistryKey,[Microsoft.Win32.RegistryKeyPermissionCheck]::ReadWriteSubTree,[System.Security.AccessControl.RegistryRights]::ChangePermissions)
    $DotNET_ACL = $RegKeyDotNETItem.GetAccessControl()
    $DotNET_AccessRule = New-Object System.Security.AccessControl.RegistryAccessRule ("System","FullControl","Allow")
    $DotNET_ACL.SetAccessRule($DotNET_AccessRule)
    $RegKeyDotNETItem.SetAccessControl($DotNET_ACL)
    
    #Change property of Item in key to desired value
    Set-ItemProperty -Path "HKLM:\$RegistryKey" -Name 'ApprovalLevel' -Value 1
    
    #Reset ACL to what it was before modification
    Set-Acl -AclObject $ACLinfo -Path "HKLM:\$RegistryKey"
    
}

#Encode payload script in a base64 string
$TBFixEncoded = [Convert]::ToBase64String([System.Text.Encoding]::Unicode.GetBytes($TBFix))


#Create action for scheduled task
$action = New-ScheduledTaskAction -Execute powershell.exe -Argument "-noprofile -encodedcommand $TBFixEncoded"
#Create task
$Taskname = "Run Thundebolt User Access Fix"
Register-ScheduledTask -Action $action -TaskName $Taskname -RunLevel Highest -User S-1-5-18 -Force
#Run task 
Start-ScheduledTask -TaskName $Taskname
#Remove task
Unregister-ScheduledTask -TaskName $Taskname -Confirm:$false

Running this script as admin will put the change into effect immediately. If the Thunderbolt Software is already running you might need to restart it or the computer for properly pick it up the change.

Solution 2C – Set registry property before installing (new!)

This should have been really obvious when i wrote this, but I did not think of it then.

If you are doing fresh deployments you can also add the registry property before installing the Thunderbolt Software.

Exactly how to implement this depends a bit on your solution. But in the case of SCCM; running this in a Command Line step should do the trick (again remember to do this before installing the TB software):

cmd /c reg add "HKLM\SYSTEM\CurrentControlSet\Services\ThunderboltService\TbtServiceSettings" /v ApprovalLevel /t REG_DWORD /d 1 /f

(A shout-out to my colleague Ilvars for being the one that actually implements my barrage of suggestions!)

I hope this solution will be helpful for those who stumble upon the same issues as i have.

Originally posted on 2018-08-08 on the old blog

Running your commands on a local machine is all well and good, but most admins work with remote servers.

So lets talk about using CIM over network and using CIM sessions!

CIM sessions

Using CIM remotely involves working with the concept of CIM sessions. CIM sessions is similar to PowerShell sessions in that they are based on WsMan for connection, with the difference being that a CIM session is limited to CIM commands only. For reference WMI works with the legacy system DCOM instead.

Some of the advantages compared to WMI is that you can re-use sessions, and you will only need to open the firewall ports required for WsMan (which reduces attack surface which is good in these security conscious days). It also has the advantage of being able to execute in parallel which can speed things up significantly at scale.

Using CIM Sessions

CIM sessions can be made in two ways: You can create a temporary one by specifying -ComputerName in Get-CimInstance (This is quick and easy):

Get-CimInstance -ComputerName "COMPUTER1" -Namespace <namespace> -ClassName <class>

Or you can create a session that is open until you close it, by using  New-CimSession to create, and Remove-CimSession to close:

#Create a session named "Session1"
New-CimSession -Name Session1 -ComputerName "COMPUTER1" 

#Remove Cim "session1"
Remove-CimSession -CimSession Session1

There are advantages and disadvantages to both.

Usually if you only need to run one command against your targets then -ComputerName would the the best choice, it starts and stops the sessions automatically and is straight forward and easy to use. But it can be slow when you want to run many commands against the same target.

The CIM session cmdlets show their power when you need to run multiple commands against your remote targets, since you only create the session once this can significantly speed up your script. Depending on the script this can actually shave off seconds off processing for each remote target. It does require you to pay a bit more attention though on your script. Sessions should close when you close the shell, but if your script exits out into a shell it is possible the connections are kept open.

That's basically it for how CIM sessions works in practice, but lets show a real example of how this can be used.

#Array of hostnames
$computerlist = ,
"Computer1",
"Computer2"

#Create empty array for use with successful connections
$availableComputers = @()

#Foreach loop that runs connection test against hostnames in $computerlist
#Then it adds the successful connections to the $availabelComputers array
Foreach ($computer in $computerlist){
    $Test = Test-Connection $computer -Quiet -Count 1 -TimeToLive 10
    if($Test -eq "True" ){
      "Connection to $Computer"
      $availableComputers += $computer
    }
    
    else{
      "No connection to $computer"
    }
}

#Creates named sessions for all computers in $availableComputers
New-CimSession -Name RDPEnable -ComputerName $availableComputers | Out-Null

#Store the class object for all computers with the session name RDPEnable
$CIM_TerminalServiceSetting = Get-CimSession -Name RDPEnable | Get-CimInstance -Namespace root/cimv2/TerminalServices -ClassName Win32_TerminalServiceSetting
$CIM_TSGeneralSetting = Get-CimSession -Name RDPEnable | Get-CimInstance -Namespace root/cimv2/TerminalServices -ClassName Win32_TSGeneralSetting
 
#Invoke CIM methods against the class object variables.
$CIM_TerminalServiceSetting | Invoke-CimMethod -MethodName SetAllowTSConnections -Arguments @{AllowTSConnections=1;ModifyFirewallException=1} | Format-Table -Property PSComputerName,ReturnValue -AutoSize
$CIM_TSGeneralSetting | Invoke-CimMethod -MethodName SetUserAuthenticationRequired -Arguments @{UserAuthenticationRequired=1} | Out-Null

#Remove all sessions with the name RDPEnable
Get-CimSession -Name RDPEnable | Remove-CimSession

This builds on the previous post example regarding enabling RDP. Here you feed it a list of hostnames, then it will do a basic connection test before it creates a named session containing all the available computers. After that it uses the session to set the correct RDP flags.

That's it for the basics of working with CIM cmdlets in PowerShell. For those that has taken the time to read my posts; i hope you have learned something new that you can use be it at work, the lab or at home.

So until my next post; have a good one!

Originally posted on 2018-08-03 on the old blog

Onward to working with CIM methods!

The data you get from using Get-CIMInstance is rarely directly modifiable as the data returned is usually a snapshot of deeper system settings. To change this you will need to use the methods provided by the Class you are looking at.

Note that that most classes have their own methods unique to them, so depending on what you want to do you will have to read up on the documentation for that class.

There are ways to look up the method names themselves in PowerShell, but the format of the input data is not always obvious. Luckily in most cases you will find what you need for classes made by Microsoft at Microsoft Docs (just search for the class name).

Example

For this article i will mainly use the class Win32_TerminalServiceSettings as an example. This is the class that controls most of the RDP Host settings on the computer.

Here is a snippet that will enable RDP on your local machine (run from an elevated shell):

$Win32TerminalServiceSettings = Get-CimInstance -Namespace root/cimv2/TerminalServices -ClassName Win32_TerminalServiceSetting 
$Win32TerminalServiceSettings | Invoke-CimMethod -MethodName SetAllowTSConnections -Arguments @{AllowTSConnections=1;ModifyFirewallException=1}

So lets break this down a bit.

$Win32TerminalServiceSettings = Get-CimInstance -Namespace root/cimv2/TerminalServices -ClassName Win32_TerminalServiceSetting

This line simply creates a variable containing the CIM Class object. This makes it simple to reuse if you want to invoke several methods, it can also help improve readability of your script.

$Win32TerminalServiceSettings | Invoke-CimMethod -MethodName SetAllowTSConnections -Arguments @{AllowTSConnections=1;ModifyFirewallException=1}

Here we are getting to the meat. We pipe the class object variable into the Invoke-CimMethod cmdlet. Here we first specify the method “SetAllowTSConnections” with the -MethodName parameter. Then we set our arguments with -Arguments, this parameter uses a hashtable to set the properties “AllowTSConnections” to 1 (allow) and “ModifyFirewallException” to 1 (enable firewall rule).

When you execute this command it will usually return a “0” to indicate success. You can check the setting by running the command:

Get-CimInstance -Namespace root/cimv2/TerminalServices -ClassName Win32_TerminalServiceSetting | select AllowTSConnections

It is important to note that calling the variable instead will return stale data, as the variable contains a snapshot of the parameters at the time of creation. This can be useful to compare data, but it is something to be aware of when you check for change.

Vs WMI-Object

For those that are more familiar with WMI this could be done with this command:

(Get-WmiObject -Namespace root/cimv2/TerminalServices -Class Win32_TerminalServiceSetting).SetAllowTsConnections(0,0)

This is an okay way to do it if your method does not have many parameters, but for some methods this can be really finicky.

The reason for this is that the parameter is positional in WMI, meaning that if you have several parameters but you only want to change one you will have to find it's correct position to change it. This is not always easy, as occasionally the parameter position is different that what the documentation says.

By using CIM methods you specify the name of the parameter in you arguments hashtable therefore rendering this issue moot.

Conclusion

As you can see above using CIM methods is fairly easy once you have the basics.

And while you can probably write shorter code with WMI, this can lead to issues when trying to set parameters.

My philosophy when writing scripts is that verbosity (within limits) is good, as it makes the script easier to read and understand and modify when necessary. And CIM cmdles are superior to WMI cmdlets in that way.

Also if you want to use the snippet above to enable RDP, you would probably also want to ensure that “Network Level Authenticaton” is enabled as well. You can do this with this snippet:

$Win32TSGeneralSettings = Get-CimInstance -Namespace root/cimv2/TerminalServices -ClassName Win32_TSGeneralSetting
$Win32TSGeneralSettings| Invoke-CimMethod -MethodName SetUserAuthenticationRequired -Arguments @{UserAuthenticationRequired=1}

Next article in the CIM series will talk about remote connections. Till then have a good one!

Originally posted on 2018-06-15 on the old blog

Here are a few various useful resources:

Microsoft Docs - Documentation on all things Microsoft, should contain almost all the articles from the old MSDN TechNet as well.

Stack Exchange - The root site for various excelent resources like Stack Overflow and Server Fault.

RegExr - Excellent site for creating and testing Regular Expressions (RegEx) strings.

SS64 - References for common scripting languages (across OS-es) and reference for database commands.

My GitHub profile

Originally posted on 2018-06-13 on the old blog

This is the first part of how to work with CIM cmdlets; here i write about how to gather and sort information.

Gathering information

Gathering information with CIM is pretty straight forward. Using the class CIM_Process as an example.

Get-CimInstance -ClassName CIM_Process

This should list all running processes on your system.

As with all PS objects you can also store you result in a variable and pipe this to your other commands:

$Processes = Get-CimInstance -ClassName CIM_Process

Keep in mind that this will be a snapshot of the moment you are creating the variable, so the data can become stale.

Sorting and filtering

Now you got some data to work with. But it might be somewhat unordered,  maybe you want to change the ordering of the list, or filter the results? That is easy to do!

The CIM cmdlets like most other cmdlets returns data objects (instead of raw text), and PowerShell have a few different cmdlets for sorting and filtering the data.

So for a few examples: Using the Sort-Object cmdlet we can sort the list according to the property we would like. Here we are sorting according to the “name” property:

Get-CimInstance -ClassName CIM_Process | Sort-Object -Property Name

Using the Where-Object cmdlet, we can filter for objects that has specific properties. Here we are filtering to only get the objects where the name begins with “A”

Get-CimInstance -ClassName CIM_Process | Where-Object -Property Name -Like "A*"

Side note on using Where-Object:
There are a lot of ways to use this cmdlet, but going into that would be beyond the scope of this post.
In case you would like to read up on this, you can take a look at Microsoft's documentation of it; Where-Object

Selecting properties

By default the output might not contain all the data you want, but just is likely to show some of the most commonly relevant properties.

Piping your command into Get-Member is an easy way to show all properties available to you:

Get-CimInstance -ClassName CIM_Process | Get-Member

Using the list of returned properties you can use the Select-Object cmdlet to get the properties you want:

Get-CimInstance -ClassName CIM_Process | Select-Object -Property Name,ProcessID,CreationDate

This should show you the process name, its ID, and when it started running.

You can also see all properties for each object if you pipe your result to Format-List:

Get-CimInstance -ClassName CIM_Process | Where-Object -Property Name -Like "Notepad.exe" | Format-List *

Note that I am also piping through Where-Object to avoid getting too many results (in this case looking for notepad.exe).

It is important to note the difference between writing “Format-List” and “Format-List *”; adding the * (wildcard) character will ensure you get all properties. In the odd case you are still not getting everything, appending -Force at the end  might help.

Rounding off to keep this somewhat easy to read; this should be a decent beginning in understanding how to use CIM cmdlets. Any questions, corrections? Please comment below!

The next article i will write about working with CIM methods. So till then, have a good one!

Originally posted on 2018-05-17 on the old blog

So for my fist post on this blog i'll write some musings about PowerShell and using the WMI and CIM cmdlets.

WMI is the backbone of most PowerShell cmdlets that interact with system settings (and C# as well). And they are a powerful tool for collecting data and making system changes.

WMI itself  is based upon the standard called Common Information Model (CIM) created by the Distributed Management Task Force (DMTF).

Originally PowerShell v 1.0 was shipped with the following cmdlets for working with WMI:

Invoke-WmiMethod
Register-WmiEvent
Get-WmiObject 
Set-WmiInstance
Remove-WmiObject

These are common workhorses for a lot of scripts around. But they are lacking a critical part of the PowerShell experience; discoverability.

These cmdlets does not allow for autocomplete of classes and namespaces, meaning you would have to dig into the documentations to discover them.

This was resolved with the release of PowerShell 3.0 and the CIM cmdlets:

Get-CimAssociatedInstance	
Get-CimClass	
Get-CimInstance	
Get-CimSession	
Invoke-CimMethod	
New-CimInstance	
New-CimSession	
New-CimSessionOption	
Register-CimIndicationEvent	
Remove-CimInstance	
Remove-CimSession	
Set-CimInstance

These cmdlets support autocomplete and makes it much easier to script without searching through documentation to find your classes and namespaces.

Now writing about this in-depth would get really long, so i'll just link to Microsoft's documentation on these: WMI: https://msdn.microsoft.com/en-us/library/aa384642(v=vs.85).aspx.aspx”) CIM\MI: https://msdn.microsoft.com/en-us/library/jj819829(v=vs.85).aspx.aspx”)

Documentation on WMI classes included in Windows can be found here: https://msdn.microsoft.com/en-us/library/aa394554(v=vs.85).aspx

And Microsoft Docs is an excellent reference for PowerShell cmdlets (and everything else Microsoft): https://docs.microsoft.com/en-us/powershell/module/

WMI vs CMI cmdlets

I will focus on the CIM cmdlets, for a few reasons:

Fist is auto-complete, which makes it much faster to create scripts in various editors (ISE primarily, but also VSCode), but also when you are just working in the console.

Second reason is that CIM is much faster when trying to query multiple computers. This is because it will execute the commands in parallel, and also because it uses WSMan as the backend for remote management (same as PowerShell). One of the really nifty features of using WSMan as backend, is that you can create CIMSessions as well (more in a later post).

And the third reason CIM is the way forward for PowerShell Core (PS v6.0), and will be supported on all platforms that PSCore is working on. Meaning you can reuse a lot of the knowledge from CIM on both Linux and MacOS as well.

Here is a little snippet to show what i mean. This will use both WMI and CIM to get some information about the computers in the $ComputerList array. This will return hostname, Windows version and install date in a table. It will also do a measure with the same commands to show how much time each command takes to complete.

$ComputerList = "Computer1","Computer2","Computer3"

Get-CimInstance CIM_OperatingSystem -ComputerName $ComputerList | Select CSName,Version,InstallDate
Get-WmiObject Win32_OperatingSystem -ComputerName $ComputerList | Select CSName,Version,InstallDate 

Measure-Command {Get-CimInstance CIM_OperatingSystem -ComputerName $ComputerList} 

Measure-Command {Get-WmiObject Win32_OperatingSystem -ComputerName $ComputerList}

Now querying 3 computers on the same network does not have a  really significant delay (both are likely below 1 second). But this quickly scales, and if one computer is slower than the others the Get-WMIObject will likely hang until it gets an response.

The CIM cmdlet also shows another nice feature here. Date values will automatically be shown with the user's own time and date format (the PS object itself is unchanged). No need to do any additional step to understand the time and dates returned in CIM objects.

This will be the first post about PowerShell and CIM in an ongoing series. So please check in later for more posts!

Have a any feedback, suggestions, corrections and the like? Please do leave a comment!

This is my first proper blog post (of hopefully many), and good feedback is the best way to improve!