Forum IT Tranquillo

Ah, non ho capito, scusa.

Abbiamo un pacchetto interno che fa proprio questo.

Il principio è il seguente: crittografiamo la nuova password utilizzando la chiave pubblica di ogni macchina memorizzata nell'inventario wapt.

Ogni workstation può quindi decrittografare la password con la propria chiave privata e applicarla alla macchina.

Tieni presente che la chiave privata è accessibile solo dagli amministratori locali della workstation. Pertanto, solo gli amministratori locali delle workstation saranno in grado di leggere la password. Questa coppia di chiavi si trova in wapt\private\.

Un metodo MOLTO più pulito è usare laps
https://blogs.technet.microsoft.com/arn ... tion-laps/

Sì, perché avere la stessa password locale per tutte le macchine non è comunque molto pulito...

Simon

Ciao EricT,

Erict ha scritto: ↑4 giugno 2018 - 16:51 Capisco, ma la mia richiesta iniziale era: cambiare correttamente la password di amministratore per la workstation, non la password del servizio WAPT.

Ad ogni modo, continuerò a usare gli Oggetti Criteri di gruppo (GPO) per quello.

Potresti spiegare come lo fai con i GPO? Mi piacerebbe sapere come lo fai in modo "sicuro". A parte LAPS, l'unico modo che mi viene in mente è riutilizzare gli hash Kerberos condivisi, il che non è particolarmente semplice.

Sinceramente,

Denis

Visto che l'argomento è interessante, ho creato una prova di concetto (POC) di una versione WAPT:

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

Il principio è il seguente: non è consigliabile avere la stessa password di amministratore su tutte le macchine.

Il pacchetto genera quindi una password casuale e la assegna all'account amministratore locale.

Successivamente, crittografa questa password con il certificato del pacchetto (il certificato della persona che ha creato il pacchetto).

La password appare quindi in forma crittografata nell'output del pacchetto nella console.

È quindi possibile leggere la password della macchina utilizzando la propria chiave privata con la funzione `print_all_password`.


Potremmo valutare l'integrazione di una funzionalità nella console per decrittografare rapidamente l'output di un pacchetto. Ciò consentirebbe a un amministratore WAPT di recuperare facilmente i dati sensibili.

In alternativa: https://wapt.lesfourmisduweb.org/list_p ... ypt-sample

Vorrei proporre una soluzione alternativa perché ho lo stesso problema.

Avere la stessa password per la sessione di amministratore non è l'ideale, ma è quello che vorremmo per un account "secondario", non chiamato "Amministratore".
Questo account è presente sulla maggior parte dei nostri computer con lo stesso nome, l'unico problema è che le password cambiano a seconda della data di creazione dell'account, e questo crea confusione.

Non è possibile utilizzare un GPO o un dominio LPAS perché alcuni computer non hanno un dominio.

La mia idea è questa: consentire a WAPT di gestire i pacchetti crittografati/protetti da password.
L'estensione del file viene modificata in .waptx e, quando il pacchetto viene distribuito, il server fornisce al client il codice di estrazione definito in precedenza nel file .ini del server o durante la sua configurazione.
Questo stesso codice deve essere fornito quando si esegue un caricamento di build crittografato, oltre alla chiave di crittografia e alla password di amministratore del server.
In alternativa, per semplificare il processo, il codice di estrazione per la decrittazione potrebbe essere il codice di amministratore del server. Tuttavia, questo crea una falla di sicurezza se la comunicazione client-server può essere letta in chiaro.

Pertanto, quando la persona X controlla la propria cartella cache o repository e scarica/apre un file .waptx, le viene richiesta una password.
Questo protegge il contenuto del pacchetto da occhi indiscreti. ^__^

Cordiali saluti,
Ren.

Hai provato questo:

https://wapt.lesfourmisduweb.org/detail ... 4_all.wapt? Premendo

F9 in PyScript viene generato il testo crittografato utilizzando la chiave pubblica di ciascuna macchina. Troverai il testo crittografato nel file encrypt-txt.json.

Durante l'installazione, ogni macchina recupererà la propria voce Encrypt in base al suo UUID. Sarà quindi in grado di decrittografare il testo con la propria chiave privata.


Nel tuo esempio, il server diventa una risorsa sensibile poiché possiede la password.
(Inoltre, questo metodo non funzionerebbe per i repository secondari, che sono semplicemente server HTTP.)