opsiclientd via GPO als automatischen Start setzen

[magicalUnicorn]

Moin zusammen,

in der Doku hab ich auf Anhieb nichts dazu gefunden, ob es empfohlen ist oder Probleme machen kann. Deswegen hier die Frage:

Kann es Probleme machen, wenn Ich via GPO für den Service opsiclientd den automatischen Start erzwinge? Hintergrund ist, dass wir vereinzelte User bei uns haben, die sonst gerne (über Umwege) den Start des Dienstes deaktivieren.

Ggf. hat damit ja schon jemand positive/negative Erfahrung gemacht oder kann meine Nase einfach auf den passenden Abschnitt der Doku drücken ^^

[Jan.Schmidt]

Hintergrund ist, dass wir vereinzelte User bei uns haben, die sonst gerne (über Umwege) den Start des Dienstes deaktivieren.

das bedeutet die sind nicht nur dumm, sondern halbwissend und vollberechtigt.

UnDumme vollberechtigte helfen sich dann damit, (wenns kein WAN Modul gibt) den Rechner nie neuzustarten nur wenn es das OS unbedingt unumgänglich macht..

Lösung:
* Keine Adminrechte für User
* Ansage in der Computernutzung - wer updates abschaltet handelt grob fahrlässig und wird mit körperlicher Abmahnung nicht unter 20 Stockhieben belohnt.

[magicalUnicorn]

Moin Jan,

Das trifft es leider sehr genau. Den Kampf gegen die Adminrechte kämpfe ich auch schon seit Jahren. Mittlerweile hab ich die auch 99% der User entziehen können.

Aber Grade die dummen, Halbwissenden Spielkinder rennen dann so lang mit den irrsinnigsten Begründung zur Leitung bis die Nachgibt. Konsequenz und so...

Und während Hiebe mit dem Stock oder der CAT6-Peitsche sicherlich ihren Effekt erzielen würden, gibt es hier am Ende eh keinerlei Konsequenzen für die :/

Deswegen die Idee den Dienst per GPO zum Start zu zwingen. Weiß halt nur nicht ob das dann z.b. bei Paketen wie Windows-Upgrade oder Update/Reinstallation des Clients Probleme machen kann

[Jan.Schmidt]

[OT}
Das Institut, für das ich arbeite wurde in der Nacht vom 3. auf den 4. Oktoer 2022 durch Ragnarlocker verschlüsselt und 95% unserer Daten sind verloren.
Die Kosten, die da enstanden sind entsprechen ziemlich sicher mehr als mein addiertes Nettogehalt, das ich in 33 Jahren erwirtschaftet habe.

Vor ~2 Wochen hat wieder ein "Sonderfall" seine Zugangsdaten auf einer Webseite eingegeben auf die der|die durch eine schlechte englische Phisingmail incl. Header ACHTUNG DIESE MAIL stammt nicht vom Institut, bitte den Inhalt mit Vorsicht behandeln" geleitet wurde.

Danach gab es bei uns einen Vorschlag eines externen, diesen "Sonderfall" abzumahnen, damit das nicht wieder passiert.
Ohne nachzudenken, dass "wir" von den Kollegen wissen müssen, wenn die das gemacht haben und eine Abmahnung nur dazu führt, dass sic nie wieder einer melden wird, wenn ihm das passiert ist und damit den Angreifern einen Zeitvorteil zu geben.

[/OT]

Druck diese Zeilen aus, drück Sie deinen Chefs auf den Tisch und teile Ihen mit, wer länger an der Sicherheit spart gibt später das mehrfache auf einen Schlag aus und ob das (incl. Verlust von Daten/bzw. wiederauffinden derselben im Darknet) der Laden überlebt ist die andere Frage.

[magicalUnicorn]

Glaub mir...da rennst du bei mir offene Türen mit ein... Ich wunder mich quasi täglich, wie wir bei unserer Netzwerkgröße es geschafft haben noch nicht erwischt zu werden...

Aber zurück zum Thema Probleme siehst du selber also nicht, wenn man den Dienst via GPO zum Start zwingt?

[Jan.Schmidt]

Aber zurück zum Thema Probleme siehst du selber also nicht, wenn man den Dienst via GPO zum Start zwingt?

Die GPO macht nur dass, was der normale installer auch macht. Also eher nein.
Nur die die da eh schon ..... werden irgendwann einfach den Rechner ohne Netzwerk starten, sich mit Ihren gecachten Credentials anmelden und dann das Netzwerkkabel reinstecken.

Ist also der Hebel an der falschen Stelle angesetzt, denn wer will und kann - kann der OPSI aushebeln und du scheinst ja einige zu haben, die das machen.
Versprich die also nicht wirklich eine Änderung, wenn du das machst.

[SisterOfMercy]

Can you deploy a scheduled task that sets the correct registry settings?

[Jan.Schmidt]

Can you deploy a scheduled task that sets the correct registry settings?

DONT DO THAT!!!!

Wenn er das mit einer GPO macht dann ist das sicherer, als ein at/shedjob mit sc usw.
Denn sowas suchen die Verschlüsseler nur und hebeln dich damit aus und biegen temporär deinen Dienst mit Elevated permissions auf "ihren" Trojaner um.

Über die GPO kann er die Sicherheit des Dienstes ändern, dann kann die Dienststeuerung nur noch das / der Benutzer System ändern.
Schalter Sicherheit bei Starten des Dienstes und die Admins können den dann nicht mehr veränderm.
Opsi läuft selber als der Benutzer, sollte also da kein Problem machen, wenns ein Clientupdate gibt.

Aber nochmal, dann booten die einfach ohne Netz - kein Opsi wird gefunden und damit ist das aktualisieren dann auch inaktiv, trotz aktivem Dienst.

[SisterOfMercy]

Wenn er das mit einer GPO macht dann ist das sicherer, als ein at/shedjob mit sc usw.
Denn sowas suchen die Verschlüsseler nur und hebeln dich damit aus und biegen temporär deinen Dienst mit Elevated permissions auf "ihren" Trojaner um.

Über die GPO kann er die Sicherheit des Dienstes ändern, dann kann die Dienststeuerung nur noch das / der Benutzer System ändern.
Schalter Sicherheit bei Starten des Dienstes und die Admins können den dann nicht mehr veränderm.
Opsi läuft selber als der Benutzer, sollte also da kein Problem machen, wenns ein Clientupdate gibt.

Aber nochmal, dann booten die einfach ohne Netz - kein Opsi wird gefunden und damit ist das aktualisieren dann auch inaktiv, trotz aktivem Dienst.

Well, I read the rest of the door was wide open, so why bother in this case?

But seriously, the opsiconfd service runs as the local system account, not as a user right?
If you change the rights in the registry so that a local user can change the registry settings of that service, one can use a non-elevated task that sets the service to autostart again.

Or do you mean that with a task deployed from the domain one could get domain admin rights via a task like that?

But I think this case can be solved more easily with a few rolls of carpet and enough quicklime

[Jan.Schmidt]

But seriously, the opsiconfd service runs as the local system account, not as a user right?
If you change the rights in the registry so that a local user can change the registry settings of that service, one can use a non-elevated task that sets the service to autostart again.

Or do you mean that with a task deployed from the domain one could get domain admin rights via a task like that?

But I think this case can be solved more easily with a few rolls of carpet and enough quicklime

* Yes it runs as System not as a User (well the User System is a "User" just a very special one)

* if you do that and didnt have a OU for the "users with adminrights" than everyone could change the startup for opsi - made things even more worse than right now.

* Yes deployed tasks are used by the people for these bad things (ask me how i know...)