Ruhiges IT-Forum

Ah, ich habe das nicht verstanden, Entschuldigung.

Wir haben ein Paket, das dies intern erledigt.

Das Prinzip ist folgendes: Wir verschlüsseln das neue Passwort mit dem öffentlichen Schlüssel jedes im Wapt-Inventar gespeicherten Rechners.

Jede Workstation kann das Passwort dann mit ihrem privaten Schlüssel entschlüsseln und auf den Rechner anwenden.

Beachten Sie, dass der private Schlüssel nur für die lokalen Administratoren der Workstation zugänglich ist. Daher können nur die lokalen Administratoren der Workstations das Passwort lesen. Dieses Schlüsselpaar befindet sich in wapt\private\.

Eine deutlich elegantere Methode ist die Verwendung von LAPS
(https://blogs.technet.microsoft.com/arn ... tion-laps/).

Ja, denn ein einheitliches lokales Passwort für alle Rechner ist immer noch nicht wirklich elegant …

Simon

Hallo EricT,

Erict schrieb: ↑4. Juni 2018 - 16:51 Uhr Ich verstehe, aber meine ursprüngliche Anfrage war: das Administratorkennwort für die Workstation ordnungsgemäß zu ändern, nicht das WAPT-Dienstkennwort.

Ich werde dafür weiterhin Gruppenrichtlinienobjekte (GPOs) verwenden.

Könnten Sie mir erklären, wie Sie das mit Gruppenrichtlinienobjekten (GPOs) umsetzen? Mich würde interessieren, wie Sie das auf eine sichere Weise realisieren. Abgesehen von LAPS fällt mir nur die Möglichkeit ein, gemeinsam genutzte Kerberos-Hashes wiederzuverwenden, was aber nicht besonders einfach ist.

Aufrichtig,

Denis

Da das Thema interessant ist, habe ich einen Prototyp (Proof of Concept, POC) einer WAPT-Version erstellt:

https://wapt.lesfourmisduweb.org/list_p ... de-in-wapt.

Das Prinzip ist folgendes: Es ist nicht ratsam, auf allen Rechnern dasselbe Administratorpasswort zu verwenden.

Das Paket generiert daher ein zufälliges Passwort und weist dieses dem lokalen Administratorkonto zu.

Anschließend verschlüsselt es dieses Passwort mit dem Paketzertifikat (dem Zertifikat des Paketentwicklers).

Das Passwort erscheint somit verschlüsselt in der Paketausgabe in der Konsole.

Mit der Funktion `print_all_password` und Ihrem privaten Schlüssel können Sie das Passwort des Rechners auslesen.


Wir könnten die Integration einer Funktion in die Konsole prüfen, um die Paketausgabe schnell zu entschlüsseln. Dies würde es einem WAPT-Administrator ermöglichen, sensible Daten einfach abzurufen.

Alternativ: https://wapt.lesfourmisduweb.org/list_p ... ypt-sample

Ich möchte eine alternative Lösung vorschlagen, da ich dasselbe Problem habe.

Das gleiche Passwort für die Administratorsitzung zu verwenden, ist zwar nicht optimal, aber genau das wünschen wir uns für ein „sekundäres“ Konto, das nicht „Administrator“ heißt.
Dieses Konto existiert auf den meisten unserer Rechner unter demselben Namen. Das Problem ist nur, dass sich die Passwörter je nach Erstellungsdatum des Kontos ändern, was verwirrend ist.

Die Verwendung einer Gruppenrichtlinie oder einer LPAS-Domäne ist nicht möglich, da einige Rechner keiner Domäne angehören.

Mein Vorschlag: WAPT soll verschlüsselte/passwortgeschützte Pakete verwalten.
Die Dateiendung wird in .waptx geändert, und beim Bereitstellen des Pakets stellt der Server dem Client den zuvor in der .ini-Datei des Servers oder während der Einrichtung definierten Entschlüsselungscode bereit.
Derselbe Code muss beim Hochladen eines verschlüsselten Builds zusätzlich zum Verschlüsselungsschlüssel und dem Server-Administratorpasswort angegeben werden.
Alternativ könnte der Entschlüsselungscode zur Vereinfachung des Prozesses auch der Server-Administratorcode sein. Dies stellt jedoch eine Sicherheitslücke dar, wenn die Client-Server-Kommunikation im Klartext lesbar ist.

Daher wird Person X beim Herunterladen/Öffnen einer .waptx-Datei aus ihrem Cache-Ordner oder Repository zur Eingabe eines Passworts aufgefordert.
Dies schützt den Inhalt des Datenpakets vor unbefugtem Zugriff. ^__^

Viele Grüße,
Ren.

Haben Sie Folgendes versucht:

https://wapt.lesfourmisduweb.org/detail ... 4_all.wapt? Durch Drücken von

F9 in PyScript wird der verschlüsselte Text mit dem öffentlichen Schlüssel jedes Rechners generiert. Sie finden den verschlüsselten Text in der Datei encrypt-txt.json.

Während der Installation ruft jeder Rechner seinen Encrypt-Eintrag anhand seiner UUID ab. Anschließend kann er den Text mit seinem privaten Schlüssel entschlüsseln.


In Ihrem Beispiel wird der Server zu einem sensiblen Gut, da er das Passwort besitzt.
(Diese Methode funktioniert außerdem nicht für sekundäre Repositories, die lediglich HTTP-Server sind.)