![]() ![]() The password is encrypted in memory with the public key of the certificate (cert.cer) and saved to an archive file to the specified share (\\server\share). This resets the password on the local Administrator account (or whatever account is specified at the command line) with a 15-25 character, random complex password. PasswordArchivePath \\server\share -LocalUsername Administrator Using Group Policy, SCCM, a third-party EMS, schtasks.exe or some other technique, create a scheduled job on every computer that runs once per week (or every night) under Local System context which executes the following command: powershell.exe \\server\share\Update-PasswordArchive.ps1 -CertificateFilePath \\server\share\cert.cer Any certificate from any source will do, but a 2048-bit or larger RSA public key from one's own PKI is preferred.Ĭopy the Update-PasswordArchive.ps1 script into that shared folder (\\server\share). CER file into a shared folder (\\server\share\cert.cer). SolutionĪ trusted administrator should obtain or create a certificate and private key, then export that certificate to a. The PowerShell solution here is better though. ![]() If the choice is between LAPS and doing nothing, then LAPS is far better than nothing. You will also need a digital certificate, either self-signed or from a PKI, but this is a good thing because it uses the public key from the certificate for encryption. However, the solution does require, at a minimum, PowerShell to be on every managed host, and it scales best in an Active Directory environment with Group Policy. The solution presented below never stores or transmits passwords in plaintext, not even temporarily, does not require an Active Directory schema update (or AD for that matter), does not require a Group Policy extension, works on stand-alone computers, can manage any number of local user accounts, you have access to the PowerShell source code for inspection or customization (it's in the public domain), and it works with any SMB server, including Samba and TrueNAS. However, note that LAPS 1) stores passwords in plaintext in the Active Directory database, using AD permissions to restrict access to the passwords, 2) requires an update to the Active Directory schema, 3) requires a Group Policy client-side extension to be installed (an MSI package) on all managed hosts, 4) is not for stand-alone servers or workstations because of the Active Directory and Group Policy components, 5) can only be used to manage one local user account on each machine, no more, 6) we don't have access to the C++ source code of the LAPS client-side extension if we need to customize it, and 7) though the LAPS tools themselves encrypt passwords while in transit over the network, admins must take care to use network encryption when using other tools when reading the passwords out of AD, e.g., a third-party utility might use LDAP in plaintext by default (this has nothing to do with LAPS per se, it's only something to be aware of). You can get technical support when using LAPS, and it comes with a GUI client for admins as well as a PowerShell module. There is also Microsoft's own Local Administrator Password Solution ( LAPS).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |