Windows GLPI Agent 1.10 Install by MSI // Delete C: Security

[tristangallet]

Bug reporting acknowledgment

Yes, I read it

Professional support

None

Describe the bug

We're deploying the Windows 1.10 MSI Agent with a Group Policy Object as usual :
Computer Configuration -> Policies -> Software Settings -> Software installation -> Original Msi on a share

On several machines, no soucy, but on 5 Lenovo Laptops, the drive C has lost all the security, so the user can not see it (Access denied) and the system is very unstable.

On the Windows Event Viewer, we can see that the MSI is deployed, but ended with an error, maybe because the drive C is touched.

Event Viewer:
Application Managment policy : event 301 : GPO is attributes
Service Control Manager : ID 7045 : Glpi services are installed :
Un service a été installé sur le système.

Nom du service : GLPI Agent
Nom du fichier de service : "C:\Program Files\GLPI-Agent\perl\bin\glpi-agent.exe" -I"C:\Program Files\GLPI-Agent\perl\agent" -I"C:\Program Files\GLPI-Agent\perl\site\lib" -I"C:\Program Files\GLPI-Agent\perl\vendor\lib" -I"C:\Program Files\GLPI-Agent\perl\lib" "C:\Program Files\GLPI-Agent\perl\bin\glpi-win32-service"
Type de service : service en mode utilisateur
Type de démarrage du service : Démarrage automatique
Compte de service : LocalSystem

Application Management Group policy : Erreur %%1603 : Échec de l’installation de l’application GLPI Agent 1.10 de la stratégie
Application Management Group policy : Erreur %%1603 : Échec de la suppression de l’attribution de l’application GLPI Agent 1.10
Application Management Group policy : Impossible d’appliquer les modifications aux paramètres d’installation du logiciel. Les modifications du logiciel n’ont pas pu être appliquées. Il devrait exister une entrée de journal précédente avec plus de détails. L’erreur est : %%1603

To reproduce

We can not reproduce the bug, but we can not deploy on more 4000 machines with this bug.

Expected behavior

Installation of the GLPI Agent 1.10 without removing the C: Drive's security.

Operating system

Windows

GLPI Agent version

v1.10

GLPI version

10.0.15

GLPIInventory plugin or other plugin version

GLPI Inventory v1.3.5

Additional context

No response

[tristangallet]

Adding information : Antivirus is Windows Defender and SCCM Client is installed. OS could be Windows 10 or 11.

[g-bougard]

Hi @tristangallet

... but on 5 Lenovo Laptops, the drive C has lost all the security, so the user can not see it (Access denied) and the system is very unstable.

What do you mean by the drive C has lost all the security ? Do you mean it occurred during installation or the computer can have lost all the C security for another reason ?
Also, by the system is very unstable, do you mean it is only unstable since the installation ?

Anyway, can you also provide your installer commandline ?

In general, a 1603 installation failure is due to an unavailable msi-server service. If you're not using our official vbs, you should use it as it checks since few version the msi-server service is available.

[tristangallet]

Hello, during installation of the GLPI agent, all security rights have been removed from C:
After rights have been removed, people can not log in and use the computer.
We're using Microsoft Policy to deploy the msi, it has been worked since GLPI agent 1.6 without problem.
Using a vbs is not secure because we can not encrypt it.

[g-bougard]

Using a vbs is not secure because we can not encrypt it.

I'm not a MS Policy deployment expert. I just know 70 or 80% of our customers use the vbs without reporting any problem with glpi-agent 1.10.
Also if I understood well, you put the MSI on a shared folder. I imagine this share is secured. Why not putting the vbs in the same place and start it in place of a msiexec command ?

This is up to you to explain us how the installation is processing in you context. We can't guess it. Until you provide more info (like the installer commandline I requested), we can only suppose you're triggering a windows os issue for which we can't do anything. And for now, you provided too poor info, so I can't help to identify what could be the real problem.

A point, you can add an installer option to generate a full installer log: for example /L*V "C:\glpi-agent-install.log", see msiexec windows commands doc for more details.

[tristangallet]

We're not using a command but a policy to deploy it.
To configure the package with the good parameters, we have a policy to add the good registry keys.
It's not a security problem, the share is the same and the security is READ for auhtenticated. We can see the log that the Windows policy has been read. I know that this is poor info, it's not logical and the first time i've seen such a bug. I will test the policy this week on more machine to see if it comes again.

[g-bougard]

What was the latest version you installed without any error ?

[tristangallet]

GLPI Agent 1.9

[g-bougard]

GLPI Agent 1.9

Nothing essential changed between 1.9 MSI & 1.10 MSI. Then as I don't see any issue, I'll move this issue as a Q&A discussion if you have more to share or need some help.

[nbriche]

We're seeing the exact same problem migrating from 1.7.3 to 1.11.

On the 7/11 we started deploying on ~400 workstations and servers using a GPO running WPKG, as we've done since time untold.

On the 8/11 morning we had a first impacted workstation; we first concluded it was a weird Windows issue and re-imaged it.

Then the same morning, a second, third and fourth workstation were impacted: no executable could be run, and when trying to access the c: drive we got an "Acces denied" error.

We went into threat assessment, disabled every deployment of every update for every piece of software, isolated the impacted workstations and tried to diagnose the issues. Which was difficult, since the only way to access the files were through our XDR.

Turned out that the ACLs for the C: were wiped, thoroughly enough that we couldn't get the rights to correct the rights.

Eventually, with the help of our cyberdefence cell and Microsoft support, we eventually put aside the threat aspect and managed to reinject the correct rights via our XDR and some powershell black magic.

All deployments were still offline until yesterday, when I enabled 1.11 again. And two hours later I got a new impacted workstation, which deployed 1.11 right before it happened.