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.