Ich kämpfe schon seit einiger Zeit mit etwas. Der Chef möchte ein Verzeichnis auf unserem Dateiserver, in dem er Programminstallationsdateien ablegt, die alle lesen und nur er ändern kann.
Er möchte, dass Client-Workstations über ein Skript verfügen, das das Verzeichnis liest und dem Benutzer zeigt, welche Dateien dort vorhanden sind. Dann könnte der Benutzer, ein normaler Domänenbenutzer (ohne die Möglichkeit, etwas zu installieren), auf „Installieren“ klicken und die Datei installieren.
Die Idee dahinter besteht darin, einen lokalen Administrator auf der Station des Benutzers zu haben, dem Skript das Kennwort des lokalen Administrators zu geben und das Programm dann mit den Anmeldeinformationen dieses lokalen Administrators auf dem Computer des Benutzers zu installieren.
Dies ist ein sehr problematisches Problem, da ich nicht sehe, wie ich es sichern kann, ohne das lokale Administratorkennwort im Skript zu speichern, was sehr schlecht wäre.
Ich habe versucht, mir vorzustellen, das Passwort irgendwie zu verschlüsseln und das Skript in eine ausführbare Datei umzuwandeln, aber ich sehe keine Möglichkeit, wie ein Benutzer, der sich ein wenig mit Computern auskennt, die ausführbare Datei nicht dekompilieren könnte. Wenn ich PowerShell-Verschlüsselung verwende, wäre sie nur für eine Maschine und einen Benutzer geeignet.
Dann ist mir eine andere Möglichkeit eingefallen: einen Anruf von der Client-Workstation an den Filer zu tätigen und den Filer dann dazu zu bringen, psexec für die Kommunikation mit dem Benutzer zu verwenden, aber das ist mir zu kompliziert.
Dann habe ich darüber nachgedacht, mithilfe des Invoke-Befehls einen Anruf vom Computer des Benutzers an den Filer und dann vom Filer zurück an den Benutzer zu tätigen, aber ich muss WinRM für alle Clients zulassen.
Ich verwende hierfür PowerShell. Vielleicht hat hier jemand schon einmal etwas Ähnliches gemacht und kann mir Tipps geben, wie ich das sicher machen kann.
Die erste Option hat prima funktioniert, daher würde ich nach Möglichkeit gerne dabei bleiben, aber ich muss noch herausfinden, wie ich das Ding absichern kann und nicht einfach die Anmeldeinformationen in ein PowerShell-Skript eintrage, das auf dem Computer des Benutzers gespeichert ist.
Antwort1
Ich sehe zwei Ansätze.
- Suchen Sie sich einen anderen Chef. Er hat offensichtlich keine Ahnung, wie kompliziert die Aufgabe, die er verlangt, wirklich ist, es geht immer um die Details, und ich bezweifle, dass er sich diese angeschaut hat. Windows-Installationen sind im Detail äußerst schwierig zu beherrschen.
Lesen Sie noch? Okay. Es ist machbar.
- Der entscheidende Punkt ist, Ihr Skript als „geplante Aufgabe“ im Hintergrund auszuführen. Wenn Sie pro Computer eine neue „geplante Aufgabe“ einrichten, werden Sie nach einem Benutzernamen und einem Kennwort gefragt, die diese Aufgabe verwenden soll. Hier geben Sie die Anmeldeinformationen Ihres Installationskontos ein. Das Kennwort kann später nicht mehr abgerufen werden, es kann also als sicher betrachtet werden. Diese „geplante Aufgabe“ verfügt nun über vollständige Administratorrechte, und wenn Sie ein Domänenbenutzerkonto verwenden (geben Sie ihm Administratorrechte auf den Clients und nur Benutzerrechte auf dem Server), kann Ihr Skript problemlos über das Netzwerk auf die Installationsdateien zugreifen und die Installation auslösen.
Beachten Sie jedoch, dass viele Installationsprogramme ziemlich dumm sind. Sie installieren das Programm für den Benutzer, der das Programm installiert (also Ihren Installer-Benutzer), und nicht für den im Vordergrund angemeldeten Benutzer. Einige Installer können so parametrisiert werden, dass sie für „alle Benutzer“ installiert werden, was wahrscheinlich ausreicht. Für die anderen müssen Sie Ihr Skript intelligenter machen, damit es „alle erforderlichen Einstellungen, Lizenzen (!), Symbole, was auch immer ein Programm zum Funktionieren braucht“ in das Profil des Vordergrundbenutzers einfügen kann, nachdem das Installationsprogramm der Software abgeschlossen ist.
Es gibt absolut keine legitime Möglichkeit, diese Aufgabe über ein Benutzerkonto ausführen zu lassen. Wenn es eine Möglichkeit gäbe, dass ein Benutzer seine Rechte auf Administratorrechte erhöhen könnte, ohne ein Administratorkennwort zu kennen oder von einem Administrator Administratorrechte zu erhalten, könnte jeder Benutzer jederzeit alles tun, was fast gleichbedeutend damit wäre, alle Benutzerkonten ständig als Administratoren auszuführen.
Jetzt brauchen Sie ein zusätzliches Skript, eine Web-GUI oder was auch immer, das dem Benutzer die Auswahl der Software auf dem Server ermöglicht, wahrscheinlich überprüft, ob der Benutzer über die Berechtigung zur Installation der Software verfügt und wahrscheinlich, ob der Computer des Benutzers die Voraussetzungen für die erfolgreiche Installation (Hardware? Freier Speicherplatz? ...) erfüllt. Dann müssen Sie diese Informationen an einem Ort speichern, an dem Ihr Hintergrundinstallationsprogramm sie lesen kann. Eine einfache Liste auf dem Server reicht aus.
Schließlich greift das Hintergrundskript regelmäßig auf diese Liste zu und löst die Installationsprogramme aus.
Erledigt.
Nehmen wir an, Sie haben vor, eine Einrichtung zur automatischen Softwareverteilung zu programmieren. Dafür gibt es kommerzielle Tools, eines ist sogar in Windows Active Directory integriert und kostenlos. Ich weiß nicht, wie viele Jahre und wie viel Geld die Entwickler investiert haben, um an einen Punkt zu gelangen, an dem ihre Installationsprogramme viele (die meisten? alle? einige?) der vielen Installationsvarianten beherrschen, die von verschiedenen Windows-Programmen verwendet werden. Auf den ersten Blick mögen sie pro Client teuer erscheinen, aber ich bezweifle, dass Sie in Bezug auf Kosten, Zuverlässigkeit, Funktionen, Dokumentation und Community-Support mit irgendetwas, das Sie in Powershell erstellen können, eine kommerzielle Lösung übertreffen können.
Antwort2
Dies klingt nach einem Job für die Bereitstellung von Gruppenrichtliniensoftware. Dadurch wird das Problem fehlender Administratorrechte für Benutzer umgangen.
VonVeröffentlichenWenn Sie ein Paket erstellen, wird die Software den Benutzern in der Systemsteuerung zur Verfügung gestellt (anstatt sie einfach automatisch zu installieren).
Aus der Sicht der Endbenutzer:
Aufstellen
- Siehe Microsoft-HandbuchHier(alter Artikel, aber immer noch relevant). Folgen Sie den "Veröffentlichen eines Pakets" anstelle von "Ein Paket zuweisen".
- Delegieren Sie die entsprechenden Berechtigungen für das GPO und die Freigabe „Software-Repository“. Sie können hierfür eine spezielle Sicherheitsgruppe namensOptionale Softwareadministratorenund fügen Sie beispielsweise Ihren Chef als Mitglied hinzu.
Stellen Sie sicher, dass der ACE gilt fürDieses Objekt und alle Nachkommenobjekte:
GewährenÄndernNTFS-Berechtigungen für den Softwareordner für optionale Softwareadministratoren:
- Installieren Sie die Gruppenrichtlinien-Verwaltungskonsole auf dem Rechner Ihres Chefs, indem Sie den folgenden PowerShell-Befehl mit erhöhten Rechten ausführen:
Add-WindowsCapability -Name "Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0" -Online
Von nun an kann Ihr Chef damit beginnen, Installationsprogramme in die Softwarefreigabe zu kopieren und die GPO für die Softwarebereitstellung entsprechend zu ändern (er muss jedoch zunächst angeleitet werden). Und das alles ohne lokale Computer- oder Domänenadministratorrechte und eine (relativ) einfache Erfahrung für alle Beteiligten!
Sie können es Endbenutzern und Ihrem Chef sogar leichter machen, indem Sie Verknüpfungen direkt dorthin senden, wo sie hin müssen. Die Installation der Gruppenrichtlinien-Verwaltungskonsole kann auch automatisiert werden, wenn diese auf mehr Administratorbenutzer ausgeweitet werden muss oder wenn Ihr Chef zwischen mehreren Computern hin- und herwandert.