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.
