I work for a massive company. They have 6,000-plus servers integrated into the PRA solution. BeyondTrust is a remote solution for administrators and other privileged accounts across the organization. It controls access to critical servers, domain controllers, Active Directory, Exchange, or any client servers they'll be using. Right now, there are about 10 products on the market globally, and BeyondTrust is the market leader. Within BeyondTrust, there are multiple sub-products, including Password Safe, Privileged Remote Access (PRA), and Endpoint Protection. PRA is unique among BeyondTrust products and other solutions.
We use Password Safe to store all the passwords in a vault, indicating when a privileged user attempts to access a privileged account on a server. PRA doesn't provide direct access to the process. Instead, we'll provide PRA access to Password Safe through a connector. In other words, the user doesn't have access to the critical account via Password Safe.
Whenever a user wants to initiate a session, they will log into Password Safe, which will inject the credentials. PRA limits access to Password Safe itself. Only a Password Safe engineer has access to that solution, and the engineer is responsible for onboarding the servers and end users. The user will initiate the session via PRA, which will retrieve the credentials. In addition to this core feature, it has reporting tools to record sessions, providing a list of clear logs.
Right now, BeyondTrust is an on-premise solution. We have a cloud version, but we are not using it. Eventually, we plan to move it to the cloud. BeyondTrust is being used extensively in our organization. There are between 100 and 130 concurrent sessions daily. Our server can easily maintain that usage level, so we don't need to add another.
Using BeyondTrust has made our end users happy because they have trouble logging into multiple sessions. Now, they only need to open the client to start a session. It has shortened and simplified various processes, like approval requests. They can do several sessions, with a session time of 15 minutes.
From an administrative point of view, BeyondTrust has streamlined user onboarding, a never-ending process. Every day, we are onboarding and deactivating users on the server. It's easy, and I don't need to change passwords or worry about who has access. My users access the servers through PRA exclusively. It's enough to remove a user's access to the server from PRA. Later, I can clean up the password or access control.
I can remove user access with one click, then figure out the other offboarding activities later. It's convenient for an administrator and the end users. Every channel has been monitored and recorded, so it's highly secure.
After getting the password, a user can initiate a direct connection to the target server. Any user working on a server can log into Password Safe to pull the password and store it somewhere. Next time, they won't need to log in to Password Safe. After that, they will directly initiate the session. PRA has a connector that allows it to retrieve the password.
PRA also doesn't require a VPN, which is a substantial cost saving for our organization. In the past, we needed a VPN license for every administrator operating from home to connect to the server. That's a massive expenditure. By implementing PRA, we could completely get rid of our VPN solution. It works like Microsoft but allows direct access, so I don't need to worry about a VPN. I log in to my PRA control and initiate the session. It's easy for any user. A domain name is more than enough. I can log into my PRA control, and I'll be able to access my server.
I like the enterprise credential manager. It's a connector that sits in PRA and tests the credentials for the end user with a process that will clean the password. This is one of PRA's primary features and simplifies user onboarding. There aren't many restrictions or complications. We can add the user while only opening one port, which is more than enough to access the PRA server. Every organization requires only four critical servers out of a hundred and some 50 production servers.
In PRA, it's easy to secure production and non-production environments. You can secure an organization's entire ecosystem. On a development server, we have privileged access and essential activities we will perform in production. The development server will be onboarded, and the consumed license will be less compact than other products.
Connecting to the target server takes at least 30 seconds with other tools. It is more straightforward in PRA, so the target connection takes five or ten seconds. Managing users, accounts, and services and upgrading the agents are all incredibly straightforward.
There are two methods of integration. We don't need to create accounts when it's onboarded to the PRA solution because the same server has already been onboarded to the process. You can initiate multiple sessions across the solution whenever your user wants. You can open the same server and various licenses. Users can unlock numerous servers and other products, features, and tasks. Users who don't want to access the server directly can initiate a connection without worrying about the desktop.
Let's say I'm a user with access to the production server. I'll be using a privileged account with access to the development server. Usually, a PAM solution will try to secure one leader-created account so they don't need to worry about the development account. There is a single pane of glass so the user can be brought into the PRA solution in a fraction of a second. My area account will be given to the dynamic team to add some security groups, and the security group will be added to my PRA solution. If I'm in that security group, I'll be able to see all my servers easily.
Nobody can log in through my server without PRA access, so it maintains excellent access control. Even if I know the password, I cannot access the server because that is a restriction we can implement across the organization. We can ensure that any protocol—43, 00, SDP, 22, etc.—goes through PRA. This is a simple tool, and any access management person can easily handle it.
They can see the system information, including the voice operating system details. Everything will be flashed over there. There are two methods of connecting to PRA: jump client and jumpoint. The jumpoint method is agentless. If there's a critical server where the owner doesn't allow you to install an agent, you can still onboard that server into the PRA solution with the agentless method.
Another great feature is built-in remote support. If an administrator needs help from the vendor, a third-party provider, or someone else within their organization, they can invite the person from within the PRA console. We can restrict the person's access to only what's necessary to provide support. With other tools, I would need to set up a video conference on WebEx or Teams and share my screen with them, and everything is in the picture.
PRA lets you invite somebody immediately from within the console. There is a small tab on the right side. I can put the email address in and send an invitation to the other person's mailbox. They only need to launch the URL to join my session quickly.
This works on mobile devices. They can use their mobile phone to log into my session and access me. If they want to do mouse control, I can allow them to work on my screen. I can minimize my session and do other work. I can also see a complete recording of the third-party support's troubleshooting steps.
I can provide direct access to the vendor through a separate app, but I have to open that domain. For example, if you are from XYZ domain, I can just add the domain to PRA and provide access, but creating an AD account for the vendor is a better option. However, most organizations will never give direct access to any third party. Instead, we'll create a dummy account that will be set up using my ID, and that account will be shared with you. I must access that secure area through my account whenever you want to log in. It's convenient for the third-party vendor, and the session is monitored, so you don't need to worry about complaints.
Third parties shouldn't have direct access, but maybe some guy also can log into the domain using this password. We create an account in our environment that provides access to the PRA control. They can easily access the solution using their account in my domain.
The vault functionality is straightforward. I have an account managed by Password Safe, which holds the password. Every password change is tracked in the vault, so I don't need to worry about that. I log into PRA and launch a server. Then it will prompt me for my service or local account. It's my only account. I can keep the service account, and this PRA solution will pull the service account's password from the vault. It is going to this credential over here when I log into the PRA solution, which works in this space.
BeyondTrust has multiple products, including Password Safe and PRA, integrated natively. Providing direct access to Password Safe might cause some issues, which is why PRA exists. We want to restrict the direct access to Password Safe for anyone except the password administrator. A user could be an administrator or end-user when they are onboarded to our service area, and the administrator will be onboarded for the accounts in Password Safe.
That's why we keep passwords in the vault and only provide access to the PRA solution. PRA will retrieve the passwords. If there is a server on which other services are running, PRA doesn't consider anything like it for the account. You can initiate the session and open the session server. You can see what services are running from there or whether the password has changed.
Password Safe performs every job, and PRA is only an intermediary that takes the password from the person and opens the session. It's like a proxy server or a jump server.
Multiple areas can be improved. We've seen lots of updates in the past year. They have a portal where we can submit our ideas. BeyondTrust is immediately implementing user suggestions. The UI could be more informative. Initially, there were two or three connectors, and now we have five or six. It would be nice if they added a few more connectors for third-party integration. There are multiple tools, but the clients may require more for their convenience.
I have been using BeyondTrust for around 18 months.
We haven't faced any issues in the past 18 months.
PRA should be scalable, but it depends on the client. We've never had any issues. We have 400-plus admins on the accounts. The total number of end users is huge, but no end users log into the privileged server. There are more than 400 admins onboarding and 6,000 trust servers.
I rate BeyondTrust support an eight out of ten. We are still in the initial stage, so we are building servers and onboarding. We have frequent calls to ensure that we are fully utilizing the product's features.
In my previous company, I worked with BeyondTrust, but I didn't use PRA.
I was not part of the initial setup, but I came on board toward the end of the deployment. I was involved in onboarding our client data. Setting up BeyondTrust PRA is simpler than other products. You have three or four servers and a primary server. Based on your recommendations, you can set up a gem server across multiple server types. It takes three or four hours, and you need to have the prerequisites in place.
It all depends on the company's requirement or the access session that is happening daily. We can use only one server or several, and it's easy to attend to those servers. I don't think integration is the hardest part. It's lightweight in terms of maintenance, but while implementing the solution, we should be careful about how we are pointing the solution so the DCD should be working properly. If you want to bring other appliances in, it's plug-and-play.
I rate BeyondTrust Privileged Remote Access an eight out of ten. If you are using a BeyondTrust product and you want to secure that process, you should use PRA, which enables you to skip a step. You don't need to worry about users having direct access to the process.