Adminrechte / Softwareupdates / User Context

[PEASANT KING]

Moin moin,

ich habe ein Problem, eigentlich würde ich das Problem so lösen, dass ich regelmäßige Updates einer eigenen Softwarelösung per PDQ Deploy an unsere Clients ausliefern würde.
Das Problem was ich habe ist, unsere Eigenentwicklung bietet eine automatische Update Routine. Die User haben und sollen auch keine Admin Rechte am Client besitzen. Heißt die IT muss hier manuell immer eingreifen, bei jedem Update und die Installation genehmigen unter Windows 10 Pro. Updates werden regelmäßig ausgeliefert.

Es müsste doch möglich sein, die Software sich updaten zu lassen im User Context ohne, dass ständig Adminrechte am jeweiligen Client für das Update benötigt werden. Ständig müssen 35 und mehr Clients geupdatet werden.

Vielen Dank für eure Ideen vorab.

 

[Autokiller677]

Der einfachste Weg wäre wohl, die Software direkt im User-Kontext zu installieren. Dann landet die halt nicht unter C:\Programme sondern im Benutzerordner, wo der User Schreibrechte & co hat.

Geht aber nur, wenn die Software keine Treiber installiert oder sonstige Späße macht, die Admin-Rechte brauchen, unabhängig davon, wo die Software installiert wird.

 

[kartoffelpü]

Da es eure eigene Software ist, könnte es sinnvoll sein, die Updateprozedur in die Software zu implementieren.
Die Programmdateien auf einem Webserver bereitstellen und in der Software dann bei jedem Start (oder nach beliebigem Intervall) prüfen lassen, ob neue Version verfügbar ist. Wenn ja, entweder automatisch installieren oder den User vorher noch fragen.

E: evtl. reicht es auch schon, den Benutzern die entsprechenden Schreibberechtigungen auf benötigte Verzeichnisse zu erteilen?

 

[derlorenz]

Nur so eine Idee, du könntest evtl. über eine Policy einen Task verteilen, der im Admin-Kontext die Updatefunktion triggert.

 

[PEASANT KING]

Da klingt ganz gut @derlorenz Problem ist, es gibt manchmal 2, 3 Updates an einem Tag, da die Programmierer, ja wie soll ich sagen, keine guten Programmierer sind xD.

Ich bin zum Glück nur hier für die IT zuständig, wenn ich Entwicklungsleiter bzw. Programmierer wäre, würde hier ein anderer Wind wehen.

 

[derlorenz]

Verstehe ^^ naja eventuell wirft die Anwendung ja einen Eintrag im System-Log, was du dann wiederum als Trigger für die Aktion im Task nutzen kannst.

 

[PEASANT KING]

Ich denke was Sicherheit angeht wäre das nicht optimal, aber wäre es möglich einen Domain Admin anzulegen, der nur die Rechte hat an den Clients die Applikation zu updaten bzw. zu installieren und sonst nichts und die Applikation würde über das AutoUpdate mittels dieses Users aktualisiert?

Eigentlich der Schlüssel zu Pandoras Box...

 

[t-6]

Ein Domänen-Admin hat da schon mal gar nichts verloren. Schlag das gleich mal aus dem Kopf.

Eine Idee: Einen Dienst erstellen der im Kontext des lokalen System-Kontos läuft, regelmäßig auf Updates prüft & ggf. installiert.
Macht Google Chrome bspw. so.

 

[Art Vandelay]

Ich hab im alten Job eine Baramundi Softwareverteilung administriert. Dort wurde auch jegliche Installation auf den Windows Clients mit einem Dom-Admin Account durchgeführt. Scheint von deren Seite wohl gängige Praxis zu sein.

Aber wenn es doch eure eigene Applikation ist, die euch da Ärger bereitet, lässt sich da nicht der Update Mechanismus der Software umstellen um euch die Arbeit zu erleichtern? Kann ja nicht sein, dass ein Admin auf jedem Rechner jedes dieser Updates genehmigen muss, das muss ja auch im Interesse der Admins sein das abzustellen. Die haben sicher besseres zu tun.

 

[nosti]

N’Abend,

ACMP Softwareverteilung nutzt für sowas einen lokalen administrativen User mit den notwendigen Berechtigungen. das wäre auch ein gangbarer Weg, neben den bereits angesprochenen Möglichkeiten. Keinesfalls solltest du einen Domain-Admin dafür nutzen. Die IT-Kollegen nutzen für die noch manuelle Installation hoffentlich auch einen entsprechenden User und turnen nicht als Domain Admins auf den Kisten rum.

Wie installiert ihr denn Clients allgemein?

Ist eine Installation der Software überhaupt notwendig? Rede mal mit den Kollegen, vielleicht ist ein Ordnersync z.B. von einem Share ausreichend.

Grüße

 

[PEASANT KING]

Ja das mit dem Domänen Admin war die Idee eines Programmierers, was die auch nicht verstehen ist, das ich in meiner IT keine lokalen Admin Konten auf den Clients möchte. Leider stellt sich da die Entwicklung etwas quer.

Die Verteilung mit PDQ Deploy wäre möglich, aber hier wäre das Problem, dass die Entwickler manchmal drei Updates pro Tag raus hauen, einfach aus Leienhaftigkeit und mangelndem QM.
Dann müsste ständig das Paket zum deployen geupdatet werden und dann verteilt werden.

Beste Lösung, so sehe ich das auch, wäre ein Dienst auf dem jeweiligen Client, der das System Konto nutzt für die Installation.

 

[nosti]

Moin,
ich kenne die Diskussionen, wir haben selbst auch gut 20 Entwickler, welche für ihre Aufgaben z.T. aber lokale Admin-Rechte auf den Kisten benötigen. Auch die Kollegen haben einen separaten ADM-Account, welcher die entsprechenden lokalen Rechte hat. Gibt halt keinen Support für die Jungs wenn sie sich was zerschießen...die Kisten werden von uns einfach platt gemacht.

Mittlerweile rollen wir Clients jedoch über Intune aus, und können da auch entsprechende Software zentral Verwalten. Man muss zwar für so einen Fall immerwieder neue Pakete bauen, aber spart sich die manuelle Installation. Mittels DevOps könnte man hier sicherlich auch eine Deployment Pipeline erstellen. Ich weiß aber nicht, ob ihr solche Tools und das Know How habt.

Grüße

 

[PEASANT KING]

Danke für deine Antwort @nosti. Jetzt läuft es so wie ich es mir vorstelle indem die Software über PDQ Deploy ausgeliefert und installiert / geupdatet wird. Nachteil im Moment, die Entwickler geben Bescheid, wenn eine neue MSI verfügbar ist und es wird dann ausgerollt manuell, da ich hier keinen Automatismus bereit stellen kann, für ständige Bugfixes etc.

 

[Chris_S04]

Ich hab im alten Job eine Baramundi Softwareverteilung administriert. Dort wurde auch jegliche Installation auf den Windows Clients mit einem Dom-Admin Account durchgeführt. Scheint von deren Seite wohl gängige Praxis zu sein.

Nein, ist es nicht.

Baramundi braucht einen Account mit lok. Adminrechten um seinen Agent zu installieren, außer die OS Installation ist schon per baramundi gemacht worden. Updates des Agents können auch ohne diesen User gemacht werden. Danach braucht man den eigentlich nicht mehr, muss also nicht Mal permanent aktiv sein.

Software wird per baramundi i.d.R. als Local System oder lok. Installationsadmin ausgeführt, dafür legt der Agent einen User an, der Admin ist, aber immer nur für die Ausführung von Jobs aktiviert wird und dann auch immer ein neues zufälliges Passwort bekommt.

Baramundi rät sogar dringend davon ab dafür einen Domänen-Admin herzunehmen.

Zur eigentlichen Thematik:
Ich würde dir auch dringend vom Domänen-Admin abraten. Das ganze über einen Dienst oder einen Scheduled Task zu lösen wäre wohl am einfachsten. Ansonsten wäre eben auch eine Autoupdate Funktion nicht schlecht.
Soweit ich aber weiß, kann man Software, die per MSI Paket ausgeliefert wird, ohne Adminrechte upgedatet werden, wenn es schon eine ältere Version der Software gibt. Wäre evtl. auch was.

 

[Art Vandelay]

Nein, ist es nicht.

Baramundi braucht einen Account mit lok. Adminrechten um seinen Agent zu installieren, außer die OS Installation ist schon per baramundi gemacht worden. Updates des Agents können auch ohne diesen User gemacht werden. Danach braucht man den eigentlich nicht mehr, muss also nicht Mal permanent aktiv sein.

Software wird per baramundi i.d.R. als Local System oder lok. Installationsadmin ausgeführt, dafür legt der Agent einen User an, der Admin ist, aber immer nur für die Ausführung von Jobs aktiviert wird und dann auch immer ein neues zufälliges Passwort bekommt.

Baramundi rät sogar dringend davon ab dafür einen Domänen-Admin herzunehmen.

Jetzt wo du es sagst kommt mir der Barainst Benutzer wieder in den Sinn, der auf den Windows 10 Rechnern angelegt war. Dann mag es sicher so gelaufen sein wie du sagst, aber ich weiss, dass wir damals extra einen Dom Admin Account für Baramundi Tätigkeiten angelegt und immer genutzt hatten. Mag aber dann vielleicht nur für's OS Deployment notwendig gewesen zu sein.

 

[nosti]

Der wird man wohl für den Domain Join der Clients gebraucht haben, sofern man diese über Baramundi ausgerollt hat.

 

[t-6]

Der wird man wohl für den Domain Join der Clients gebraucht haben, sofern man diese über Baramundi ausgerollt hat.

Wiederum ist ein Dom-Admin nicht für Domänenbeitritte nötig.

Fun Fact: Ein reguläres Benutzerkonto kann bis zu 10 Geräte in eine Domäne aufnehmen.

Und für Deployments sollte man ohnehin 5 Minuten Zeit investieren um einen "echten" Deployment-Benutzer zu erstellen der mehr als 10 Joins kann.

 

[nosti]

Das ist ja mal äußerst interessant @t-6. Vielen Dank für die Info.
Kann man den Zähler auch wieder zurücksetzen, oder geht das nur über wilde ADSI-Edit Hacks?

Grüße

 

[t-6]

Ohne drüber nachgedacht zu haben: Wahrscheinlich wilde ADSI-Hacks ^^

Ist aber fürs Deployment ohnehin egal weil zu wenig.

Hier ist bspw. eine Anleitung wie man sich einen entsprechenden Benutzer erstellt:
https://www.moderndeployment.com/correct-domain-join-account-permissions/
(diese spezielle Anleitung nicht getestet, aber die Schritte waren aus der Erinnerung her identisch)