Sophos Network Threat Protection: Installation fails (solved)

The error code you show ( -2146869243) is TRUST_E_TIME_STAMP - "The timestamp signature and/or certificate could not be verified or is malformed."

I would suggest open the Event log and expand to

 Microsoft-Windows-CAPI2/Operational from under: Applications and Services logs and enable the opera CAPI2 operational log.

Reproduce the error and see what this specific event log has to say for the APIs being called.

Maybe you can export the evtx for this log and attach it?

Any chance this could be it, i.e. "automatic root certificates update" has been disabled?

How to enable the "automatic root certificates update" on Windows Server 2016 - Microsoft Q&A

we didn(t have a group policy like this

(and there is no DisableRootAutoUpdate

in "HKLM:\Software\Policies\Microsoft\SystemCertificates\AuthRoot"


Here it is the CAPI2 event log :

fromsmash.com/0NHGBIDsqo-ct

Sophos already say to me to read theese event  log, but I didn't understand how to solve theese errors

thanks

Thanks for that.  If I look at this entry for example:

Log Name: Microsoft-Windows-CAPI2/Operational
Source: Microsoft-Windows-CAPI2
Date: 16/02/2022 08:44:32
Event ID: 60
Task Category: Open Store
Level: Error
Keywords: Certificate Store
User: LOCAL SERVICE
Computer: COMPUTER
Description:
For more details for this event, please refer to the "Details" section
Event Xml:
<Event xmlns="">schemas.microsoft.com/.../event">
<System>
<Provider Name="Microsoft-Windows-CAPI2" Guid="{5bbca4a8-b209-48dc-a8c7-b23d3e5216fb}" />
<EventID>60</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>60</Task>
<Opcode>0</Opcode>
<Keywords>0x4000000000000100</Keywords>
<TimeCreated SystemTime="2022-02-16T08:44:32.6688870Z" />
<EventRecordID>459444</EventRecordID>
<Correlation />
<Execution ProcessID="5964" ThreadID="8048" />
<Channel>Microsoft-Windows-CAPI2/Operational</Channel>
<Computer>COMPUTER</Computer>
<Security UserID="S-1-5-19" />
</System>
<UserData>
<CertificateStore>
<Store type="CERT_STORE_PROV_SYSTEM_W" constant="10" location="CERT_SYSTEM_STORE_CURRENT_USER_ID">CA</Store>
<Flags value="110C0" CERT_STORE_SHARE_STORE_FLAG="true" CERT_STORE_SHARE_CONTEXT_FLAG="true" CERT_STORE_MAXIMUM_ALLOWED_FLAG="true" />
<EventAuxInfo ProcessName="SophosFileScanner.exe" />
<CorrelationAuxInfo TaskId="{AD4E00D3-7C41-4A92-86CE-5252C6F7DC6C}" SeqNumber="3" />
<Result value="5">Accès refusé.</Result>
</CertificateStore>
</UserData>
</Event>

The process is getting access denied trying to open the cert store. This process is running as local service so it's in effect trying to read:

HKEY_USERS\S-1-5-19\SOFTWARE\Microsoft\SystemCertificates\CA

I suspect if you run Process Monitor, when starting the SFS service (in this case), with a filter for the path (contains):

S-1-5-19\SOFTWARE\Microsoft\SystemCertificates

..you will see an access denied.

One easy way to fix this would be to rename the following file early at boot by the Windows Session Manager

\windows\ServiceProfiles\LocalService\NTUSER.DAT

To 

\windows\ServiceProfiles\LocalService\NTUSER.DAT.BROKEN

for example. To do so, download:

https://docs.microsoft.com/en-us/sysinternals/downloads/pendmoves

You need MoveFile so you can run as admin:

movefile "C:\windows\ServiceProfiles\LocalService\NTUSER.DAT" "C:\windows\ServiceProfiles\LocalService\NTUSER.DAT.BROKEN"

This will add the file to the pendingfilerenameoperations reg key. Reboot.  The registry hive for the local service user will be created on next boot with the correct permissions.

I could probably create a PS script to do it calling the MoveFile API if needed.

I suspect the process can then validate the timestamp as it will be able to open the store.

---

If you have computers yet to migrate to 21H2, it would be interesting to check the registry permissions before the upgrade and then after. 

E.g. from a PS admin prompt run:

New-PSDrive -PSProvider Registry -Name HKU -Root HKEY_USERS

Then:

get-acl "HKU:\S-1-5-19\SOFTWARE\Microsoft\SystemCertificates\CA" | fl

It should show that local service has full control of its own key, e.g.

Path : Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-19\SOFTWARE\Microsoft\SystemCertificates\CA
Owner : NT AUTHORITY\LOCAL SERVICE
Group : NT AUTHORITY\LOCAL SERVICE
Access : NT AUTHORITY\LOCAL SERVICE Allow FullControl
NT AUTHORITY\SYSTEM Allow FullControl
BUILTIN\Administrators Allow FullControl
NT AUTHORITY\RESTRICTED Allow ReadKey
APPLICATION PACKAGE AUTHORITY\Software and hardware certificates or a smart card Allow ReadKey
Audit :
Sddl : O:LSG:LSD:(A;OICIID;KA;;;LS)(A;OICIID;KA;;;SY)(A;OICIID;KA;;;BA)(A;OICIID;KR;;;RC)(A;OICIID;KR;;;S-1-15-3-9)

---

It would be interesting to run that on 21H1, perform the upgrade and then run it on 21H2, is it all still the same?  Is the upgrade breaking the permissions?

Hope it helps.

Do you mean Sophos File Scanner services ? (SFS ?)

there is some acces denied !

I do this think (with the movefile exe)

movefile "C:\windows\ServiceProfiles\LocalService\NTUSER.DAT" "C:\windows\ServiceProfiles\LocalService\NTUSER.DAT.BROKEN"

but nothing change for me (even after reboot)

I don't need to recreate admin profile ?

it seems there is no

Owner : NT AUTHORITY\LOCAL SERVICE
Group : NT AUTHORITY\LOCAL SERVICE
Access : NT AUTHORITY\LOCAL SERVICE Allow FullControl

I assume the Powershell command was run following the reboot so still shows the issue?

Did the Pending File Rename Operation (PFRO) actually work? 

Did you end up with the file:

"C:\windows\ServiceProfiles\LocalService\NTUSER.DAT.BROKEN"

following the reboot and a new NTUSER.DAT?

Can you check that is the correct location on your computer for the NTUSER.DAT for the local service user?

I assume the Powershell command was run following the reboot so still shows the issue?

yes

yes

Well that's odd, the hive is being created again, you would assume with the correct permissions for the user, which suggests it's being "broken" shortly after being created.  You could try explicitly granting access to local service for the keys.  The following PowerShell would do that:

$keys_to_fix = "S-1-5-19", 
               "S-1-5-19\Software", 
			   "S-1-5-19\Software\Microsoft", 
			   "S-1-5-19\Software\Microsoft\SystemCertificates",
			   "S-1-5-19\Software\Microsoft\SystemCertificates\CA"

foreach($key_to_fix in $keys_to_fix)
{
    Write-host "Fixing:" $key_to_fix

    $key = [Microsoft.Win32.Registry]::Users.OpenSubKey($key_to_fix,
           [Microsoft.Win32.RegistryKeyPermissionCheck]::ReadWriteSubTree,
           [System.Security.AccessControl.RegistryRights]::ChangePermissions)

    $acl = $key.GetAccessControl()

    $rule = New-Object System.Security.AccessControl.RegistryAccessRule ("NT AUTHORITY\LOCAL SERVICE","FullControl","Allow")
    
    $acl.SetAccessRule($rule)
    
    $key.SetAccessControl($acl)
}

The idea behind deleting and letting it get re-created would be to ensure all the permissions are correct.

I assume the above works?  Does that get reverted.

As another test, I would be interested to setup the PFRO again to delete/rename the local service users ntuser.dat and then setup Process Monitor to capture a boot log.

On reboot, collect the PML boot log, you should see where smss.exe renamed or deleted the ntuser.dat to prove that happened and then later on, do you see something setting permissions on the key(s)?

Hope it helps.

I have some issue with this script,

probably with the var key_to_fix "S-1-5-19"

I try the script itself and the script

without foreach with only S-1-5-19" but it's the same

xception lors de l'appel de «SetAccessRule» avec «1» argument(s): «Impossible de traduire certaines ou toutes les
références d'identité.»
Au caractère \modifRg.ps1:19 : 5
+     $acl.SetAccessRule($rule)
+     ~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : IdentityNotMappedException

Fixing: S-1-5-19\Software\Microsoft
Exception lors de l'appel de «SetAccessRule» avec «1» argument(s): «Impossible de traduire certaines ou toutes les
références d'identité.»
Au caractère \Desktop\modifRg.ps1:19 : 5
+     $acl.SetAccessRule($rule)
+     ~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : IdentityNotMappedException

thanks