Lithnet LAPS configuration page (Active Directory)
Last updated
Last updated
Note: Access Manager Agent v3 no longer stores passwords in the Active Directory, and support for the legacy v2 agent will be removed in a future release of Access Manager.
We recommend migrating any existing v2.0 agents utilizing this feature to AMSv3 agents, which securely store passwords for Active Directory-joined machines in the AMS database directly.
Ensure that your AMS server is up to date before deploying the AMS v3 agent to devices in your environment.
For more information on planning your AMS v3 migration, see our upgrading from Access Manager v2 to v3 guide.
The settings on this page only apply to the v2 Access Manager agent, when configured to store passwords in Active Directory. It does not apply to v3 agents at all.
A list of forests is shown along with an indication of the deployment status of the Lithnet Access Manager Agent schema.
You can use the Deploy Schema... button to access a script that will deploy the Lithnet Access Manager schema to the selected forest. You'll need to run this script as a member of the Schema Admins group in the forest you need to update.
This setting controls whether the Access Manager Server will attempt to retrieve passwords from the lithnetLocalAdminPassword attribute in Active Directory.
If you did not deploy the AMSv2 agent to store passwords in Active Directory, this this option should be disabled.
Where the Access Manager v2 agent is in use and storing passwords in Active Directory, you'll need to ensure this option is enabled.
Once you have migrated all your agents to v3, disable this option, to speed up password lookups.
You do not need to delegate permissions if you are using Access Manager v3 agent
If you are using the v2 agent, you'll need to delegate appropriate permission for the AMS service account to read those passwords.
Click the Delegate permissions button to generate a script to do this automatically.
Copy or save the script, modify the $OU variable as appropriate, and run it in with domain admin rights.
You do not need to create an encryption certificate if you are using Access Manager v3 agent
Each forest in the domain, where the v2 agent is in use, must have an encryption certificate published in order to deploy the Lithnet Access Manager Agent. Select a forest from the drop-down list, to see the encryption certificates available for that forest. Only one certificate can be published at any one time.
You can rotate these certificates as often as you like, but you need to ensure that the certificate used to encrypt a given password is available for as long as it is stored in the directory. Agents cannot decrypt their own passwords, so once they have encrypted it with a given certificate, it can only be decrypted with the same certificate.
Shows the forest that the encryption certificate was issued for
Shows the date that the certificate was generated
Shows the date that the certificate will expire
Indicates whether the certificate is correctly published in the directory. Clients in this forest will currently use this certificate to encrypt their passwords.
At any time you can generate a new encryption certificate by clicking the Generate new button. Clients will not use this new certificate until you publish it in the directory. Use the Publish button to generate a script to deploy the public key into the forest. This script must be run as a member of the domain admins group in the root domain of the forest. Publishing a new certificate will overwrite any existing certificate in use.
If there are previously used certificates shown here, don't remove them. If clients have encrypted their passwords or password history with these old certificates, the AMS service will need them to be able to decrypt them.
It is imperative that you have a safe and secure backup of your encryption keys. Select a certificate to back up and click View Certificate. From the Details tab, click Copy to file.... This will launch the export certificate wizard, which will allow you to export the certificate and private key to a PFX file. Choose a strong password for the PFX, and store the file somewhere safe. It's best to have multiple copies of the file, including an 'offline' copy.
See the guide on restoring an encryption certificate from backup for details on how to restore an existing key from a backup.
If you've lost the private key, you can force the agents to set new passwords and encrypt them with a new key by reading the recovering from a lost encryption certificate guide. Unfortunately, there is no way to recover the encrypted password history.
