Vendor access best practices
This topic describes best practices for managing vendors with Remote Access.
Things to do after installation
Creating an additional administrator is recommended for eliminating any bottle necks that come with a single point of contact for all vendor PAM - Self-Hosted admin functions. For more information, see Add a tenant admin.
Once the VendorLDAP is configured, it’s important to make sure that the correct EPV user licenses are being consumed when a vendor is provisioned. Typical configuration is the VendorLDAP directory mapping consumes the External User or PSMUser license type in EPV. For more information, see Directory mapping for vault users.
It’s helpful to familiarize yourself with What's new for any additional or new features and settings available. Remote Access has a frequent release cycle. Items that get released range from minor tweaks to the SaaS service all the way to major feature enhancements.
Adding an additional connector provides high availability and load balancing functionality to your architecture. Per Site, you can configure multiple connectors. For more information, see Add additional connectors to existing VendorLDAP.
Identifying, inviting, and registering your first vendor user is key to developing your internal process for vendor access. The process should be repeatable using any of the methods for inviting a vendor: manual invitation, build automation using the API, or the vendor self-service URL. Your process could include a combination of these methods. For more information, see Invite Vendors.
Understanding your use cases
Take some time to think about the use cases that are specific to you. Try to think beyond internal user vs. external user access. Rather, think about the situational and operational use cases that can apply to you based on the sections below. It is recommended to document your use cases based on what your current process is to what your new process will be. Document things like the vendor user invitation/provisioning workflow, access workflow, and any administrative scenarios.
Situational use cases are scenarios in which you’ve defined who needs access to what. The examples below run through some of these scenarios based on whether the user coming in via Remote Access is an existing internal user or a vendor user.
Vendor Users – Remote access to PAM - Self-Hosted
Access to type of target system is based on an organization’s individual needs. Examples can include, but are not limited to:
IT Systems and Applications
OT Systems and Applications
Point of Sale Systems
Remote Access allows for the extension of existing CyberArk controls to vendor users that need access to your organization’s internal systems. In some cases, new controls can be put in place that provide stricter controls for vendor access than what may have been in place previously. The following are examples of operational use cases that can either streamline a process or provide more controls for vendor access.
Provide streamlined vendor user life-cycle management for access to target systems through the built in user management Remote Access provides.
Provide increased accountability of vendor actions on target systems through enhanced recording and monitoring.
Provide streamlined vendor user experience access target systems via the CyberArk Web Portal.
Safe and platform design considerations
Here are some considerations for Safe design for vendor access to CyberArk and target systems:
Create vendor specific Safes. One way is to create a Safe for each vendor organization where all of the accounts a vendor could use reside.
Another way is to create, for example, OS specific Safes based on the vendor organization. Permissions for each Safe is role based access controlled and pulled from the groups you’ve set up.
Safe permissions for vendors should be set to List Accounts and Use Accounts. With these permissions, vendors can see the accounts in the Safe and use them for PSM connectivity.
Create vendor specific accounts for target devices – these accounts are not usually with IT users. Safe permissions are easier to separate when account objects aren’t shared between IT users and vendors. This also makes for cleaner audit trails.
Create vendor specific platforms with connection components that only use the HTML5 gateway. Vendors will usually not use an RDP connection since they won't be in the network. For more information, see Install the HTML5 Gateway for PSM (side-by-side).
Situations where internal privileged users are using Remote Access to connect to the PVWA, it makes sense to use the AllowHTML5Select option in the connection component. This allows an existing internal privileged user the ability to use the HTML5 gateway for PSM connections when using Remote Access remotely, but use a regular PSM connection (RDP, for example) when using the same account object while connected on the internal network.
For more information, see Platform properties.
License management tips
Use these instructions to validate, or change, the directory mapping for the OpenLDAP (on the connector) to the EPV. Administrative rights in EPV that have Directory Mapping permissions is required to change the Directory Mapping. In most deployments, the mapping is set to use the EPV license type of External Use or PSMUser.
Step 1: Validate the ‘External User’ or ‘PMSUser’ License Type
Run a license capacity report in the PrivateArk client:
Log in to the PrivateArk client with a user that has the permissions to run a License Capacity Report. Example, the Administrator user.
Go to Tools > Reports > License Capacity Report and check the usage of the External_Users (it may also be labeled as Ext_User) or the PSMUser license type. This depends on what you have in your license file. If you don’t have either External_Users or PSMUser as a license type you may need to update your license file. Check with your CyberArk account team to validate license types.
Validate External Users or PSMUser aren’t being used.
If External Users or PSMUser aren't being consumed, this means the user template in the Directory Mapping is not set for Remote Access (vendor users) to use the External User License or PSMUser type.
Step 2: Change the Directory Mapping (as necessary)
Log into the PrivateArk client as an Administrator (this is necessary to access Directory Mapping).
Go to Tools > Administrative Tools > Directory Mapping and click on 'RemoteAccessUsers' (this could be called something different like OpenLDAP or VendorLDAP).
Click Update and click on User Template.
Change the User Type to External_Users (could be called Ext_Users) or PSMUser.
Click OK until you are back to the Directory Mapping window, then click Close.
If you had to change the Directory Mapping after vendors have already been registered (for example, those users consumed the EPVUser license type and it needed to be changed), the existing vendor users that are in EPV will need to be deleted. Since these users are based on an external directory mapping, the next time they login, they will get the External User or PSMUser license type in EPV.
Step 3: Delete existing vendor users (if necessary)
Delete existing vendor users from EPV to fix their EPV license type consumption (based on consumption report from Step 1).
In the PrivateArk Client go to Tools > Administrative Tools > Users and Groups.
Find vendor users from Remote Access. The account will be in the format of <user>@<company>.alero. Delete these users.
If the user has direct permissions on a Safe (not group based), those permissions need to be re-assigned. If all of these users are in groups, the users get permissions to the Safes based on the groups when they log in again.
Once the vendor user logs in again, they will get the External User license type based on the new User Template mapping.
In addition to setting a time frame for access, Remote Access can be configured to remove an expired vendor. The interval options start at 30 days after expiration. Using this setting can be useful for your company security policies or general Remote Access license cleanup. The benefit of keeping an expired vendor is the ease in which you can extend the time frame and give access back to a particular vendor without having to resend any invitation.
For example, a vendor is part of a project that is supposed to last two weeks. At the end of the two weeks their access to Remote Access has expired. However, they are still a valid user. In this scenario, let’s say the week after their access has expired, they need access again to finish up a lingering issue from the original issue. Instead of inviting them again, simply extend their access period to the new end date. The vendor can then login and have the same access they did during the first two weeks.
By automatically removing a vendor after expiration, you’re able to automatically manage your vendor licenses as well. In the above example, if no extra work was needed and you have set vendors to be removed 30 days after expiration, the vendor would be removed at the 30-day mark, freeing up a license to be used by someone else.
For more information, see Manage identities settings.
As an administrator, it's important to get familiar with both the administrative and technical aspects ofRemote Access . Get familiar with the Connector CLI utility.
It is recommended to add at least one additional connector to your site . This will provide high availability between the connectors. In addition to multiple connectors, depending on the size of your environment, number of users (vendor and internal) and potential usage, consider adding and load balancing multiple HTML5 Gateways. When load balancing the HTML5 gateways, the installation mode needs to be stand-alone. HTML5gateway load balancing cannot be done if the HTML5 gateway is installed on the same Docker host as the connector (side-by-side install).
For more information see: