I leverage BeyondTrust Privileged Remote Access and underlying jumpoint technology to remote into systems hosted in Azure. Unfortunately, BeyondTrust does not alert on disconnected jumpoint status. Meaning if either the FW infront our PRA or the FW infront of our Azure Jumpoints has issues, we simply cannot jump to the respective systems.
Rather than rely on infrastructure alerts of the firewall devices itself (of course, also relevant), we’ll use BeyondTrust’s API to do our own neat little bit of reporting on issues.
For this purpose, we’ll leverage the following products to check BeyondTrust PRA Jumpoint status:
- BeyondTrust PRA API
- Azure KeyVault (store API secret)
- Azure LogicApp (authenticate to API & retrieve status)
- Exchange Online (email alert out)
- Alternatively; Azure or Twilio.com for sending SMS / Voice Alert
Design drawn out below:
1. Prerequisites
Ensure you have enough privileges (and budget :-)) in Azure to create both a KV, LogicApp and also configure underlying RBAC. For BeyondTrust PRA, make sure you’ve got the privileges to create an API clientid&secret with enough privileges to report out on your jumpoint status.
2. Azure Configuration
First, create an Azure KeyVault. Regardless of how you design your KeyVaults, I prefer to use Azure role-based access control (recommended by Microsoft), but Vault Access Policy also works.
Inside the Azure KeyVault you created, add a secret that’s called beyondtrustapisecret. Keep this page open.
3. BeyondTrust PRA Configuration
New browser tab. Log into /login (admin console), go to Management – API Configuration
Add an API account that has sufficient privileges (Command API Full Access), you can tweak privileges to your liking of course.
Copy OAuth Client Secret Value, and paste it into the Secret field of beyondtrustapisecret inside your KeyVault. Click Save on API account page and keep PRA page open.
4. Azure LogicApp
Back to your Azure tab, create an Azure LogicApp. I typically choose Consumption-based and disable fancy features like redundancy, log analytics, etc. But this is entirely dependent on your own budget.
Once created, head into the LogicApp itself and choose Identity. Turn on System-Managed Identity and take note of the ID that’s assigned to it (blacked out part below):
5. Configure proper rights
Head back to your KeyVault. Now, dependent on how you created it (RBAC vs Vault Access Policy), you’ll have to either go to Access Control or Vault access Policy tab:
5.1: Role-Based Access Control
Assign Key Vault Reader to the managed identity:
5.2: Vault Access Policy
Assign Get Privileges to the Managed Identity:
6. Design Logic App
Back to your Azure Logic App, head to Designer. Create a schedule-based trigger, I chose to check every 5 minutes:
First things first, let’s authenticate to BeyondTrust API. Create a variable called clientid and add the value of your API OAuth2 ID:
Next, we need the Client Secret. Create an action, search for and use Key Vault Get Secret, and connect to the previously created KV & Secret using our LogicApp’s Managed Identity. Once created, click on Settings of this step and choose Secure Output.
Next, we need to parse this Client Secret as a variable. Create an Action for this:
We’ll use this secret to Authenticate next. Create an action, search for and use HTTP.
- Method: POST
- URI: /oauth2/token
- Headers: Content-Type: application/x-www-form-urlencoded
- Body: grant_type=client_credentials
- Authentication: Basic, and add the previously created dynamic content for clientid & secret
We need to Parse the body response of our HTTP request as JSON. Action > Data Operations > Parse JSON. Use this schema:
{
"properties": {
"access_token": {
"type": "string"
},
"expires_in": {
"type": "integer"
},
"token_type": {
"type": "string"
}
},
"type": "object"
}Let’s get the status of our jumpoint. Another HTTP action:
- Method: GET
- URI: /api/config/v1/jumpoint?code_name=
- Headers: Authorization <access_token> (dynamic content we just parsed!)
Parse JSON for this HTTP response as well. Shema below.
{
"items": {
"properties": {
"clustered": {
"type": "boolean"
},
"code_name": {
"type": "string"
},
"comments": {
"type": "string"
},
"connected": {
"type": "boolean"
},
"enabled": {
"type": "boolean"
},
"id": {
"type": "integer"
},
"name": {
"type": "string"
},
"platform": {
"type": "string"
},
"protocol_tunnel_enabled": {
"type": "boolean"
},
"rdp_service_account_id": {},
"shell_jump_enabled": {
"type": "boolean"
}
},
"required": [
"id",
"name",
"code_name",
"platform",
"comments",
"rdp_service_account_id",
"clustered",
"enabled",
"shell_jump_enabled",
"protocol_tunnel_enabled",
"connected"
],
"type": "object"
},
"type": "array"
}
Final step, we need to report out on the status of course. Create a condition ; if connected equals true. On true; do nothing. On False, send an email. Idea is outlined below:
8. Voice / SMS Alerting
Unfortunately, at the time of writing this article full functionality of Azure Voice/SMS alerting is still limited to USA for me, so I cannot use it properly as an EU consumer.
Instead, we could also leverage a service like Twilio.com to send SMS and/or Voice alerts. Their SMS functionality is even pre-configured as a connector in Azure LogicApps, and sending a voice alert is a simple HTTP POST request away:
I’ll most likely do another write up on leveraging Twilio and LogicApps another day.
That wraps up this post! Hopefully in a nearby future, BeyondTrust adds alerting functionality out-of-the-box rather than us having to rely on these duct tape solutions :-). Still a fun way to play around with API’s, Azure native solutions and more!
