Password Safe Functional Account Permissions on RDS Server to Launch Application

Based on the latest guidance and best practices, here's a refined and accurate view of the least privileges required for a Functional Account (FA) to launch an application from RDS servers:

Minimum Privileges Required

1. Interactive Logon Rights

   • The FA must be allowed to log on interactively to the RDS server. This is typically managed via Group Policy or Local Security Policy under:

     Local Policies > User Rights Assignment > Allow log on locally
     

   • Ensure the FA is part of a group that has this right assigned.

2. Access to Remote Desktop Collections

   • The FA must be assigned to the appropriate Remote Desktop Collection to access the published application. This is done via the RD Connection Broker by adding the FA or its group to the collection's access list.

3. Local Administrator Rights (Only If Necessary)

   • This should be avoided unless the application explicitly requires elevated privileges to run. If the app can be configured to run without admin rights (e.g., by adjusting file/folder permissions or using RunAs), then Local Admin membership is not required.

4. Application-Specific Permissions

   • If the application accesses restricted resources (e.g., registry keys, protected folders), modify those permissions to allow standard users to access them.
   • Avoid placing executables in restricted locations like C:\ root. Use structured folders like C:\Apps\AppName with appropriate read/execute permissions.

Password Management Considerations

• Avoid Password Safe Managed Accounts for FAs that require frequent or automated logins. These can interfere with session stability and password rotation.
• Instead, consider auto-managed accounts with strong password policies and regular rotation schedules.

Security Best Practices for Functional Accounts

• Least Privilege Principle: Grant only the permissions necessary for the FA to perform its task. Avoid domain admin or broad access unless absolutely required.
• No Identity Association: FAs should not be tied to individual users. They are meant for automation and should not be used for daily work.
• Password Rotation: Ensure passwords are rotated periodically and securely managed.
• Audit and Monitoring: Log and monitor FA activity to detect misuse or anomalies.

Functional Accounts: Do’s and Don’ts | BeyondTrust

Thank you ​@frank.colvin 

my pleasure