Target environment requirements
Netwrix Privilege Secure for Access Management (Privilege Secure) manages resources on the platforms in this table. Each platform needs its own service account permissions. See Service account permissions.
| Platform | Requirement |
|---|---|
| Active Directory | Domain controllers that the application server can reach. |
| Windows |
|
| Microsoft Entra ID | An app registration with Microsoft Graph permissions. |
| Linux | Use a supported release of the distribution with SSHv2 or later. |
| BSD | The host needs SSH access. |
| Cisco | The device needs SSH access. |
| Palo Alto | The device needs SSH access and the PAN-OS API. |
| Microsoft SQL Server |
|
| Oracle |
|
For BSD targets, the service account signs in over SSH and runs commands with sudo. The command plans use the FreeBSD pw utility. For PAN-OS targets, Privilege Secure manages administrator accounts through the PAN-OS XML API over HTTPS at the device's address.
Privilege Secure also supports any device that accepts an SSH connection, and any device or website that uses Active Directory or Microsoft Entra ID authentication. These devices have no local account management and no preconfigured activity steps.
Privilege Secure has no Arista-specific platform in 26.07.
Websites and secret vaults are platforms too. For the full platform list and their settings, see Platforms.
Service account permissions
| Target | Permission |
|---|---|
| Active Directory, and Windows member servers and desktops | Membership in the Domain Administrators group in the target domains. |
| Standalone Windows servers and desktops | Membership in the local Administrators group on each server or desktop. |
| Linux | A service account on each server, or a central domain account for hosts bridged to Active Directory. The account is root, or has permissions delegated through sudo or another least-privilege solution. Netwrix recommends a least-privilege account instead of root. See Linux targets. |
| Cisco | Level 15 Privileged EXEC, which gives full access for configuration and management. |
| Microsoft Entra ID | An app registration with Microsoft Graph application permissions and Entra directory role assignments. For the permission and role list, see Register an app in Microsoft Entra ID. |
| Oracle | SYSDBA privileges. |
| Microsoft SQL Server | sysadmin privileges. |
For the Entra ID app registration, see Register an app in Microsoft Entra ID.
For BSD targets, use root or an account that can run the needed commands through sudo. For the least-privilege policy, see Configure a least-privilege sudoers policy for Linux and BSD. For PAN-OS targets, use an administrator whose role enables the XML API and allows configuration changes and commits. See Configure an admin role profile in the Palo Alto Networks documentation.
Windows targets
WinRM
Privilege Secure manages Windows hosts through PowerShell remoting over WinRM. Open TCP port 5985 (HTTP) or 5986 (HTTPS) from the application server to each Windows host. See Ports.
Kerberos delegation
A host scan runs on the target host itself. It reads local users and local groups with local WMI and ADSI calls, so it doesn't contact a domain controller. You don't need delegation for a host scan.
Some actions on Active Directory resources run a command on the target host that then reads from a domain controller. This makes a second network hop, from the target host to the domain controller. The command reaches the domain controller only when the target host can forward the administrator's credentials on that second hop. Configure Kerberos delegation so the target host can authenticate to the domain controllers on the second hop.
Without delegation, the second hop fails. The command can't read the domain, so the collected data is incomplete. Password rotation can still proceed while a session holds the old password. This can cause recurring Active Directory account lockouts.
Non-domain-joined hosts
On a Windows host that isn't joined to a domain, remote PowerShell can fail with "Access is denied" for a local service account. User Account Control (UAC) filters remote sign-ins by local accounts, which causes the error. First, confirm that the service account is a member of the local Administrators group on the host. If the error continues, run this command in a PowerShell session that you started as an administrator:
New-ItemProperty -Name LocalAccountTokenFilterPolicy `
-Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System `
-PropertyType DWord -Value 1
The command sets the LocalAccountTokenFilterPolicy registry value to 1, which turns off UAC remote restrictions for local accounts. For more information, see these articles:
- Access Denied Error Connecting to a Non-domain-joined Windows Resource
- Managing Non-domain-joined Windows Computers with Netwrix Privilege Secure
Linux targets
Use a dedicated service account with least privilege instead of root. Create a sudoers file for the account that allows only the commands Privilege Secure needs, and don't grant blanket sudo access. The same applies to BSD targets.
Azure Linux 4.0 resources need extra preparation before you add them. See Prepare an Azure Linux resource.
The account name that you add as a service account in Privilege Secure must match the account name in the sudoers file. For the policy, the command list, and how to check it, see Configure a least-privilege sudoers policy for Linux and BSD.