Tranquil IT Forum

Ah, I didn't understand, sorry.

We do have a package that does this internally.

The principle is as follows: we encrypt the new password using the public key of each machine stored in the wapt inventory.

Each workstation can then decrypt the password with its private key and apply it to the machine.

Note that the private key is only accessible by the local administrators of the workstation. Therefore, only the local administrators of the workstations will be able to read the password. This key pair is located in wapt\private\.

A MUCH cleaner method is to use laps
https://blogs.technet.microsoft.com/arn ... tion-laps/

Yes, because having the same local password for all machines is still not very clean...

Simon

Hello EricT,

Erict wrote: ↑June 4, 2018 - 4:51 PM I understand, but my initial request was: to change the admin password for the workstation properly, not the WAPT service password.

Anyway, I'll continue to use Group Policy Objects (GPOs) for that.

Could you explain how you do this with GPOs? I'd be interested to know how you do it in a "secure" way. Aside from LAPS, the only way I can think of is to reuse shared Kerberos hashes, which isn't particularly easy.

Sincerely,

Denis

Since the topic is interesting, I created a proof of concept (POC) of a WAPT version:

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

The principle is as follows: it's not good to have the same administrator password on all machines.

The package therefore generates a random password and assigns this password to the local administrator account.

It then encrypts this password with the package's certificate (the certificate of the person who created the package).

The password thus appears in encrypted form in the package's output in the console.

You can then read the machine's password using your private key with the `print_all_password` function.


We might look into integrating something into the console to quickly decrypt a package's output. This would allow sensitive data to be easily retrieved by a WAPT administrator.

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

I'd like to propose an alternative solution because I have the same problem.

Having the same password for the admin session isn't ideal, but that's what we'd like for a 'secondary' account, not called 'Administrator'.
This account is on most of our machines with the same name, the only issue is that the passwords change depending on the account's creation date, and it's confusing.

There's no way to use a GPO or LPAS domain because some machines don't have a domain.

My idea is this: allow WAPT to manage encrypted/password-protected packets.
The file extension is changed to .waptx, and when the package is deployed, the server provides the client with the extraction code defined beforehand in the server's .ini file or during its setup.
This same code must be provided when performing an encrypted build-upload, in addition to the encryption key and the server admin password.
Alternatively, to simplify the process, the decryption extraction code could be the server admin code. However, this creates a security breach if the client-server communication can be read in plain text.

Therefore, when person X looks in their cache folder or repository and downloads/opens a .waptx file, they are prompted for a password.
This protects the packet's contents from prying eyes. ^__^

Regards,
Ren.

Have you tried this:

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

F9 in PyScript generates the encrypted text using each machine's public key. You'll find the encrypted text in the encrypt-txt.json file.

During installation, each machine will retrieve its Encrypt entry based on its UUID. It will then be able to decrypt the text with its private key.


In your example, the server becomes a sensitive asset since it possesses the password.
(Furthermore, this method wouldn't work for secondary repositories, which are simply HTTP servers.)