119944
Oct 17, 2016, updated at 12:31:26 (UTC)
1442
9
0
Chrome 54 und Software Restriction Policies
Hallo zusammen,
seit Freitag gibt es ein neues Update welches die Version des Chrome Browser auf 54 anhebt.
Durch unsere Software Restriction Policies ist das Ausführen von Dateien im Ordner "C:\Users\%username%\Appdata" (mit wenigen Zertifikats-Ausnahmen) verboten.
Leider funktioniert mit diesen Einstellungen die aktuelle Version des Chromes nicht mehr. Es wird nur ein Prozess im Taskmanager gestartet und das wars.
Gebe ich "C:\Users\%username%\Appdata\Local\Temp" und "C:\Users\%username%\Appdata\Local\Google" frei ändert sich daran leider nichts.
Das freigeben des kompletten Appdata Ordners hingegen führt dazu, dass Chrome wieder problemlos startet.
Hat hier jemand eine Idee was das Problem sein könnte oder wie ich herausfinde was genau geblockt wird?
Edit: Es befinden sich leider keine Einträge in der Ereignisanzeige.
VG
Val
seit Freitag gibt es ein neues Update welches die Version des Chrome Browser auf 54 anhebt.
Durch unsere Software Restriction Policies ist das Ausführen von Dateien im Ordner "C:\Users\%username%\Appdata" (mit wenigen Zertifikats-Ausnahmen) verboten.
Leider funktioniert mit diesen Einstellungen die aktuelle Version des Chromes nicht mehr. Es wird nur ein Prozess im Taskmanager gestartet und das wars.
Gebe ich "C:\Users\%username%\Appdata\Local\Temp" und "C:\Users\%username%\Appdata\Local\Google" frei ändert sich daran leider nichts.
Das freigeben des kompletten Appdata Ordners hingegen führt dazu, dass Chrome wieder problemlos startet.
Hat hier jemand eine Idee was das Problem sein könnte oder wie ich herausfinde was genau geblockt wird?
Edit: Es befinden sich leider keine Einträge in der Ereignisanzeige.
VG
Val
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 318093
Url: https://administrator.de/contentid/318093
Printed on: April 19, 2024 at 10:04 o'clock
9 Comments
Latest comment
Sers,
das ist ein Bug seitens Chrome 54.
Im Detail: Die Enforce certificate rules von SRP verhindert aktuell zurecht den korrekten Start von Chrome.
Das Verzeichnis "C:\Users\%username%\Appdata\Local\Temp" von SRP auszuschließen ist die denkbar schlechteste Lösung, da du damit Haus und Hof für Cryptolocker und Konsorten öffnest.
Bester "fix" aus meiner Sicht: Zurück auf Version 53, bis Google das Problem löst.
Grüße,
Philip
das ist ein Bug seitens Chrome 54.
Im Detail: Die Enforce certificate rules von SRP verhindert aktuell zurecht den korrekten Start von Chrome.
Das Verzeichnis "C:\Users\%username%\Appdata\Local\Temp" von SRP auszuschließen ist die denkbar schlechteste Lösung, da du damit Haus und Hof für Cryptolocker und Konsorten öffnest.
Bester "fix" aus meiner Sicht: Zurück auf Version 53, bis Google das Problem löst.
Grüße,
Philip
Sauber danke dir!
Echt ärgerlich, dass hier nichts im Eventlog steht...
VG
Val
Echt ärgerlich, dass hier nichts im Eventlog steht...
Das Verzeichnis "C:\Users\%username%\Appdata\Local\Temp" von SRP auszuschließen ist die denkbar schlechteste Lösung, da du damit Haus und Hof für Cryptolocker und Konsorten öffnest.
Das ist mir klar, hab ich auch nur in meiner TestVM für meinen Testuser gemacht um herauszufinden was der neue Browser für Probleme hat.VG
Val
Hi.
Da wir applocker, den Nachfolger von SRP, einsetzen und Chrome 54 und das Problem trotz Verwendung von Zertifikatsrichtlinien (Whitelisting) nicht besteht, denke ich, dass Ihr evtl. mal Eure Logs durchschauen solltet, was denn geblockt wird. Auch mal die Regeln sortieren nach Typ und die Zertifikatsrichtlinien durchsehen.
Da wir applocker, den Nachfolger von SRP, einsetzen und Chrome 54 und das Problem trotz Verwendung von Zertifikatsrichtlinien (Whitelisting) nicht besteht, denke ich, dass Ihr evtl. mal Eure Logs durchschauen solltet, was denn geblockt wird. Auch mal die Regeln sortieren nach Typ und die Zertifikatsrichtlinien durchsehen.
Moin,
das Problem an der Sache ist, dass hier leider nichts im "Anwendung" Protokoll angezeigt wird.
Lade ich Putty herunter und versuche es vom Desktop zu starten kommt wie erwartet der Eintrag im Log.
VG
Val
das Problem an der Sache ist, dass hier leider nichts im "Anwendung" Protokoll angezeigt wird.
Lade ich Putty herunter und versuche es vom Desktop zu starten kommt wie erwartet der Eintrag im Log.
VG
Val
Ok. Und was hast Du an Zertifikatsrichtlinien?
Mit Zertifikatsrichtlinien meinst du die Zertifikatsregeln? (bin eher im Linuxbereich fit)
Wir haben aktuell nur 3 Zertifikatsregeln für Go2Meeting, join.me und Teamviewer.
Wir haben aktuell nur 3 Zertifikatsregeln für Go2Meeting, join.me und Teamviewer.
[Chromium hat den Bug übrigens noch immer nicht bestätigt. Ergo SRP-Nutzer sind und bleiben Randgruppenerscheinungen.}
Lösung: wenn man das Enforcement für Certificate-Rules aufhebt, geht es wieder UND DENNOCH werden certificate Rules umgesetzt.
Was das zu bedeuten hat, weiß nur Schrottosoft selbst.
Lösung: wenn man das Enforcement für Certificate-Rules aufhebt, geht es wieder UND DENNOCH werden certificate Rules umgesetzt.
Was das zu bedeuten hat, weiß nur Schrottosoft selbst.
Ich muss mich leicht korrigieren und zitiere mal meinen Kommentar in dem Chromium-Thread (#58):
I should not have called it a solution but a workaround. Calling it incorrect, you overlook one thing: Let's assume your SRP settings are set to disallow anything, that is not whitelisted and you have used certificate rules to whitelist some apps including chrome, then taking away the cert enforcement will still allow the same apps as before but chrome 54 will be startable in addition, since this setting is only partly activated, until we restart. Have a go and try. Only after a restart will windows disregard the other cert rules. So this is a workaround - until the system restarts. But it can be re-applied.
Morgen kommt wohl ein Update mit dem Fix.
We're going to have M54 Stable Release on Wednesday (OCT 19).Please ensure to land the fix today before 8.00 PM to have enough baking time in trunk. If all looks good CL can be merged in time for tomorrow's stable cut at 4 PM (OCT 18).
