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?

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

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

I guess being a French OS, it should be

AUTORITE NT\LOCALSERVICE

rather than:

NT AUTHORITY\LOCALSERVICE

Can you update the script and try again?

Maybe check under Services.msc what localservice is on a French OS, I don't have one. Thanks.

it was

"NT AUTHORITY\LOCALSERVICE" and not "NT AUTHORITY\LOCAL SERVICE"

now the script run with no error

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


Path   : Microsoft.PowerShell.Core\Registry::HKEY_USERS\S-1-5-19\SOFTWARE\Microsoft\SystemCertificates\CA
Owner  : BUILTIN\Administrateurs
Group  : PCP3853\Aucun
Access : AUTORITE NT\RESTRICTED Allow  ReadKey
         AUTORITE NT\Système Allow  FullControl
         AUTORITE NT\SERVICE LOCAL Allow  FullControl
         BUILTIN\Administrateurs Allow  FullControl
         PCP3853\Administrateur Allow  FullControl
         AUTORITÉ DE PACKAGE D’APPLICATION\Vos certificats de logiciel et de matériel ou carte à puce Allow  ReadKey
         AUTORITE NT\RESTRICTED Allow  ReadKey
         AUTORITE NT\Système Allow  FullControl
         BUILTIN\Administrateurs Allow  FullControl
         PCP3853\Administrateur Allow  FullControl
         AUTORITÉ DE PACKAGE D’APPLICATION\Vos certificats de logiciel et de matériel ou carte à puce Allow  ReadKey
Audit  :
Sddl   : O:BAG:S-1-5-21-1891537447-1770671421-2111988918-513D:AI(A;OICI;KR;;;RC)(A;OICI;KA;;;SY)(A;;KA;;;LS)(A;OICI;KA;
         ;;BA)(A;OICI;KA;;;LA)(A;OICI;KR;;;S-1-15-3-9)(A;OICIID;KR;;;RC)(A;OICIID;KA;;;SY)(A;OICIID;KA;;;BA)(A;OICIID;K
         A;;;LA)(A;OICIID;KR;;;S-1-15-3-9)

I remove sophos again,

but the bug still there :/

Can you filter Process Monitor to Access Denied again and let AutoUpdate have another try at installing NTP?

Did a new Process Monitor show a permissions issue with the same key, a different key?  Is the problem solved?

sorry my collegue format the PC,
I need to find another pc to try again

the problem is not solved at this time.

I want to say thanks you "Sophos User930" a lot !!!

finaly it was a ACL issue on all registry since we apply OS update !

# Modification des acls des clés de registre

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force -Confirm:$false

$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"

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\LOCALSERVICE","FullControl","ContainerInherit","None","Allow")
    
    $acl.SetAccessRule($rule)
    
    $key.SetAccessControl($acl)
}

$keys_to_fix2 = "S-1-5-19", 
               "S-1-5-19\Software", 
			   "S-1-5-19\Software\Microsoft"			   
			   

foreach($key_to_fix2 in $keys_to_fix2)
{
    Write-host "Fixing:" $key_to_fix2

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

    $acl2 = $key2.GetAccessControl()

    $systemSid = New-Object System.Security.Principal.SecurityIdentifier('S-1-15-2-1')

    $rule2 = New-Object System.Security.AccessControl.RegistryAccessRule ($systemSid,"ReadKey","Allow")
    
    $acl2.SetAccessRule($rule2)
    
    $key2.SetAccessControl($acl2)
}

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

foreach($key_to_fix3 in $keys_to_fix3)
{
    Write-host "Fixing:" $key_to_fix3

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

    $acl3 = $key3.GetAccessControl()

    $person = [System.Security.Principal.NTAccount]"restricted"
    $access = [System.Security.AccessControl.RegistryRights]"ReadKey"
    $servicelocal3 = New-Object System.Security.AccessControl.RegistryAccessRule ($person,$access,"ContainerInherit","None","Allow")
    
    $acl3.SetAccessRule($servicelocal3)
    
    $key3.SetAccessControl($acl3)
}
#
#New-PSDrive -PSProvider Registry -Name HKU -Root HKEY_USERS
$key_to_fix =  "S-1-5-19\Software\Microsoft\SystemCertificates\CA"


    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\LOCALSERVICE","FullControl","Allow")
    
    $acl.SetAccessRule($rule)
    
    $key.SetAccessControl($acl)
    
    $acl = Get-Acl "HKU:\S-1-5-19\SOFTWARE\Microsoft\SystemCertificates\CA"
    
    $servicelocal = New-Object System.Security.Principal.NTAccount 'NT AUTHORITY\LOCALSERVICE'
    $acl.SetGroup( $servicelocal)
    $acl | Set-Acl

  

here it is our script to solve the issue

and we need to reinstall Sophos to solve the issue.