What to turn on for each feature

Some Velauth features need a setting in your environment before they work. Velauth cannot turn these on for you, but the Readiness card on the Overview page checks each one through your agent and shows the exact steps for anything that is missing. This page lists each one: what it needs, how to enable it, who can do it, and what Velauth shows if it is missing.

Commands marked verified were tested on a live Windows Server 2022 lab on 2026-10-17. Commands marked verify before running were not tested. Check them in a test environment first.

Restore deleted objects (AD Recycle Bin)

What it needs: the AD Recycle Bin turned on for the forest, plus two permissions for the Velauth agent account: read access to the Deleted Objects container, and the Reanimate Tombstones right on the domain.

How to turn it on (verified):

Check the forest functional level is 2008 R2 or newer:
Terminal window
```
(Get-ADForest).ForestMode
```

Enable the Recycle Bin. Use your forest DNS name:

Enable-ADOptionalFeature -Identity 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target 'corp.example.com' -Confirm:$false

Let the agent account list deleted objects. Replace the domain, and use your agent service account name. The dollar sign matters:

dsacls "CN=Deleted Objects,DC=corp,DC=example,DC=com" /takeownership
dsacls "CN=Deleted Objects,DC=corp,DC=example,DC=com" /G "CORP\svc-velauth$:LCRP"

Let the agent account restore deleted objects. The space in the right name matters. Written with a hyphen (Reanimate-Tombstones), the command reports success but grants nothing:
```
dsacls "DC=corp,DC=example,DC=com" /G "CORP\svc-velauth$:CA;Reanimate Tombstones"
```
The agent account must also hold write rights on the OU the object is restored into, and the deleted object keeps the rights it had when it was deleted. Restoring a protected admin account also needs the Org Owner Tier-0 override.

Who can do it: Enterprise Admin for step 2. Domain Admin for steps 3 and 4.

Can it be undone: No. Step 2 is permanent for the forest. Only objects deleted after it is on can be fully restored. Steps 3 and 4 can be reversed with dsacls.

What Velauth shows if it is missing: “The Active Directory Recycle Bin is not enabled in this forest, so deleted objects cannot be restored.” If the Recycle Bin is on but nothing is returned, Velauth says: “No deleted objects were returned. Only objects deleted after the Recycle Bin was enabled can be restored, and the Velauth agent account needs read access to the Deleted Objects container.” It never claims nothing was deleted, because an unreadable container looks the same as an empty one.

LAPS passwords

What it needs: LAPS deployed on your computers, passwords stored in AD (not encrypted), and read permission for the agent account on the password attribute.

How to turn it on (verify before running): run these on a machine with the Windows LAPS PowerShell module. Legacy Microsoft LAPS uses different cmdlets (Update-AdmPwdADSchema, Set-AdmPwdComputerSelfPermission, Set-AdmPwdReadPasswordPermission). Verify those too.

Extend the schema (verify before running):
Terminal window
```
Update-LapsADSchema
```

Let computers write their own password on the OU (verify before running):

Set-LapsADComputerSelfPermission -Identity "OU=Workstations,DC=corp,DC=example,DC=com"

Turn on password backup to Active Directory with a Group Policy (Computer Configuration, Administrative Templates, System, LAPS). The exact path differs by Windows build. Verify before running.

Let the agent account read passwords on the OU (verify before running):

Set-LapsADReadPasswordPermission -Identity "OU=Workstations,DC=corp,DC=example,DC=com" -AllowedPrincipals "CORP\svc-velauth$"

Do not turn on password encryption if you need Velauth to show the password. Velauth cannot decrypt encrypted LAPS passwords.

Who can do it: Schema Admin for step 1. Domain Admin for steps 2 to 4.

Can it be undone: Permissions and Group Policy, yes. The schema extension, no.

What Velauth shows if it is missing: “No LAPS password is stored on this machine, or this service account may not read it.” Velauth cannot tell these two cases apart. For encrypted passwords: “This machine stores an ENCRYPTED Windows LAPS password. Velauth cannot decrypt it.” Safety Lock also blocks this feature while it is on.

BitLocker recovery keys

What it needs: computers that save their recovery keys to AD, and read permission for the agent account on the recovery password attribute.

How to turn it on (verify before running): run the client commands on a machine with the BitLocker feature.

Set a Group Policy: Computer Configuration, Administrative Templates, Windows Components, BitLocker Drive Encryption, Operating System Drives, “Choose how BitLocker-protected operating system drives can be recovered”. Choose “Save BitLocker recovery information to AD DS”. Verify the exact path for your Windows build.
For drives that are already encrypted, push the key to AD again from the client (verify before running):
Terminal window
```
Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId '{protector-id}'
```
Give the agent account read access to the msFVE-RecoveryPassword attribute on the computer OUs. This attribute is confidential, so plain Read Property is not enough. Velauth has no tested command for this. Verify the delegation in a test OU first.

Who can do it: Domain Admin.

Can it be undone: Yes. Both the Group Policy and the permissions can be removed.

What Velauth shows if it is missing: “No BitLocker recovery keys are escrowed for this machine, or this service account may not read them.” Velauth cannot tell these two cases apart. Safety Lock also blocks this feature while it is on.

Find the machine behind a lockout

What it needs: the audit events written on your domain controllers, and permission for the agent account to read the Security log on every domain controller.

How to turn it on (verify before running):

Check the audit policy on the domain controllers. Velauth reads events 4740, 4771 and 4625:
- 4740 comes from “Audit User Account Management” (success).
- 4771 comes from “Audit Kerberos Authentication Service” (failure).
- 4625 comes from “Audit Logon” (failure).
To check or set one on a domain controller (verify before running):
```
auditpol /get /subcategory:"Kerberos Authentication Service"
auditpol /set /subcategory:"Kerberos Authentication Service" /failure:enable
```
In a domain, set this through Group Policy so it stays on.
Add the agent account to Event Log Readers (verify before running):
Terminal window
```
Add-ADGroupMember -Identity 'Event Log Readers' -Members 'svc-velauth$'
```
Restart the agent service so it gets a new token.
If the agent cannot reach a domain controller, allow the Windows Firewall group “Remote Event Log Management (RPC)” on it.

Event Log Readers is a domain-wide read of the Security log. Every other Velauth right is limited to OUs. Adding the agent account is a deliberate choice. It is not part of the standard setup.

Who can do it: Domain Admin.

Can it be undone: Yes. Remove the group member and change the audit policy back.

What Velauth shows if it is missing: “The domain controllers’ Security logs could not be read. The Velauth service account needs to be a member of Event Log Readers on the domain controllers.” If auditing is off, Velauth may instead say the logs hold no matching events, which can also mean auditing was never on.

Scheduled reports and Send now

What it needs: allowed recipient domains set on the agent host, a mail relay that supports STARTTLS, and a from address and recipients on an allowed domain.

How to turn it on (verified):

On the agent host, set the allowed domains. Use the MSI property when you install or upgrade:

REPORT_RECIPIENT_DOMAINS="contoso.com"

Or set the registry value HKLM\SOFTWARE\Velauth\Agent, name ReportRecipientDomains, type string, comma separated:

New-Item -Path HKLM:\SOFTWARE\Velauth\Agent -Force
New-ItemProperty -Path HKLM:\SOFTWARE\Velauth\Agent -Name ReportRecipientDomains -Value 'contoso.com' -PropertyType String -Force
Restart-Service VelauthAgent

In the app, open Settings, Scheduled reports, and enter your mail relay. The agent supports STARTTLS only. Implicit TLS (port 465) and plain SMTP are refused. The mail server certificate must be trusted by the agent host.
Make sure the from address and every recipient are on an allowed domain.

The allowed domains cannot be set from the app. Someone must change them on the agent host. A report was delivered in the lab with STARTTLS and a sealed password. The registry command and service restart were not run separately: verify before running.

Who can do it: a local Administrator on the agent host. A Velauth user with the right permission edits the schedules.

Can it be undone: Yes. Remove the registry value and restart the service.

What Velauth shows if it is missing: “Report delivery is not turned on for this agent.” The schedule buttons are disabled.

Microsoft Entra users

What it needs: an Entra app registration with the Microsoft Graph application permission User.Read.All, admin consent, and a client secret saved in Velauth.

How to turn it on (verify before running, these portal steps were not tested):

In the Entra admin center, open App registrations and choose New registration.
Open API permissions, Add a permission, Microsoft Graph, Application permissions. Add User.Read.All.
Choose Grant admin consent.
Open Certificates and secrets and create a client secret. Copy the value now.
In Velauth, open Settings, Microsoft Entra. Enter the tenant ID, client ID and secret. Access is read only.

Who can do it: an Entra Global Administrator or Privileged Role Administrator grants consent. A Velauth user with the right permission saves the credential.

Can it be undone: Yes. Delete the secret or the registration.

What Velauth shows if it is missing: the setup checklist lists Microsoft Entra as optional. If the credential fails (bad secret, no consent, expired secret), Velauth shows on-premises users only and does not say why. Client secrets expire, so note the date.

Changes refused outside the delegated OUs

What it needs: the agent account must hold delegated write rights on the OU of the object you are changing.

How to turn it on: your AD administrator delegates rights per OU. The agent setup guide that ships with the agent has the dsacls lines, and the agent’s delegate-ad command can preview them with --check-rights. That check runs on the agent host and is read only.

Who can do it: Domain Admin, or whoever owns the OU permissions.

Can it be undone: Yes. Remove the rights with dsacls /R.

What Velauth shows if it is missing: “Access denied by Active Directory. The agent account cannot write to this object (check its delegated OUs).” It does not say which OU or right. Protected admin accounts also need the Org Owner Tier-0 override.

Stale computers

This is a note, not a setup. Velauth uses the lastLogonTimestamp attribute. AD updates it only about every 14 days, so a threshold under 14 days gives false results. Computers that are offline or never logged on also look stale. Check before you disable anything.

Fine-grained password policy

This is a note, not a setup. Reading fine-grained password policies usually needs Domain Admin rights. If the agent cannot read them, Velauth shows the domain default policy with a note that a fine-grained policy may apply. The default shown may not be the policy that applies to that user.