F5 APM RDP

To enable secure RDP access for Mac and non-domain Windows clients using F5 APM, you'll need to ensure that your configuration supports these clients properly. Here’s HealthCareGov a detailed approach you can follow:

Overview of Steps

1. Access Policy Configuration
2. RDP Settings in APM
3. Testing and Troubleshooting
4. Security Considerations

1. Access Policy Configuration

You need to modify your existing access policy to include checks and configurations for non-domain devices. Here’s how to proceed:

• Add Device Detection: Use the Client Type or User Agent to detect Mac and non-domain Windows devices.
• Add RDP Access: Create a branch in the access policy that handles RDP connections. You can use the following sequence:
  • Logon Page: Authenticate users.
  • Access Policy Branch: Check if the user is on a non-domain machine and route to the RDP branch.
  • RDP Access: Use the RDP access profile and configure it to serve the RDP file.

2. RDP Settings in APM

1. Create an RDP Access Profile:
   • Go to Access > Profiles > RDP Access.
   • Create a new profile or modify an existing one, ensuring it points to the correct internal resources.
2. Configure RDP Settings:
   • Specify the RDP host (the Windows machine users will connect to).
   • Configure security settings (like SSL/TLS) to secure the RDP session.
   • Ensure that the RDP file generated contains the correct details for the session.
3. RDP File Generation:
   • The RDP file needs to be formatted correctly to ensure it points to the right target and uses the correct authentication method (e.g., domain credentials).

3. Testing and Troubleshooting

• Test Access: Use a Mac or non-domain Windows machine to test access. Ensure the RDP file downloads and attempts to connect correctly.
• Log Analysis: Check the APM logs to troubleshoot connection issues:
  • Authentication Failures: Ensure users are authenticated correctly.
  • Connection Errors: Look for errors in the RDP connection attempt.

4. Security Considerations

• Encryption: Ensure that RDP sessions are encrypted.
• User Roles: Define roles and permissions clearly in APM to prevent unauthorized access.
• Client Restrictions: Consider adding restrictions based on the OS type for better security.

Example Access Policy

1. Start with Logon Page
2. Branch for Non-Domain Check (Use Client Type):
   • If it's a non-domain Windows or Mac, allow access.
3. RDP Access Action:
   • Use the configured RDP profile.

Final Thoughts

Setting up F5 APM for non-domain clients requires careful attention to access policies and proper RDP configurations. Test thoroughly with different devices and ensure your access policies are robust enough to handle varying scenarios.

Hi, 

Thx for your quick response! Great steps, I would like to use "Client OS" to detect client type with specified domain Win Registry for client restrictions, and I want to check if the RDP host you mentioned is pointing a Windows Terminal Server with Remote Desktop Session Host service, use the terminal server to call end user own company laptop? Or directly pointing to end user's own company laptop?

Without the /var/log/apm logs for that user's session, this is a guess, but it might be that the access is denied because there is another higher precedence ACL assigned to the user, or the system isn't noticing that it should be allowing that destination RDP server. Normally if the RDP host is statically assigned (just one IP:port) this "allow access" is automatic, but there may be some corner case issue.

Normally the RDG-RAP policy is used to authorize user access to dynamic RDP endpoints, like where you assign it with a session variable or the user chooses it. It seems weird, but this mechanism is used because of technical limitations: APM doesn't have knowledge of what RDP endpoints should be allowed, so RDG-RAP can be used to query servers to obtain authorized endpoints.

For testing we can just try to create a policy of type "RDG-RAP" that's just Start -> Allow so the connection is always allowed, then assign it during access policy execution.

Then assign it to the user in their access policy: