What is our primary use case?
The purpose is to ensure that privileged users do not know their own passwords.
How has it helped my organization?
Our organization is more secure, and we are confident that the privileged users who are using the systems are actually the users they claim to be due to two-factor authentication because we are using two-factor authentication in One Identity Safeguard.
It is easy for us to revoke access as well. Previously, we did not know who had access to a system, but now, we can see what access is currently open to systems directly from one single pane of glass, allowing us to revoke that access if necessary. We have limited the possibilities for malicious actions and have made it safer for our users when they are using privileged accounts. They only have privileged access when using that account, but they do not know the password. While nothing is 100% secure, it is more difficult to misuse that privileged account. In the past, IT administrators could log in with domain administrator access on their normal PCs, which made everything work without needing to elevate their rights. Now they cannot do that because they no longer know the password. They are required to go through One Identity Safeguard to elevate their rights.
In the beginning, we had some pushback from the administrators because they could not log in directly to a server or a system. They have to go through the web interface and log in. We had to educate them and put in a little bit of effort. We made them aware that we were also taking risks away from them so that nobody could misuse their credentials. People become administrators only when they want to use the system. When they are done using it, the account is disabled, and administrative privileges are revoked.
Previously, we had external consultants who had accounts, but we did not necessarily know when they were using the account. We now know because we have put up an approval flow. The external company needs to request access for a user, they need to call us and provide a ticket number. We then can approve it. We can also approve them for a specific duration, such as two hours. After that, the user needs to request access again and he needs to be approved. We now know when external people are using our systems. All the external privileged users are now disabled, which were not disabled before because we did not know when they needed to use the system. They did not have a normal user and a privileged account. They just had one user who could log in to the systems. Now, they need to have a normal user that can log in to One Identity Safeguard, and then the privileged account will only be enabled when we have approved the access to the system. The normal user does not have any access besides logging in to One Identity Safeguard. So, there was some pushback because administrators had to raise a ticket. We also tightened up our ticket system to ensure that IT does not do any work unless there is a ticket.
Our management can see that our security posture has greatly improved because, on a normal day, we do not have any privileged users who are enabled, so it is very difficult to elevate access to various systems. If they are not active, privileged access is revoked, and there is no access without a ticket.
We use the transparent mode feature for privileged sessions. It is very easy because it just goes through the Safeguard session. That session is used as a proxy now, so we can limit our end-user's access to server assets. Only the session has access to the servers, so we can do micro-segmentation in a different way now on our network.
The transparent mode is rather seamless because the user does not see this Safeguard session. They only see the Safeguard for privileged passwords because that is the interface that is there, a single pane of glass. When they request access to an IDP session or server, they see a different background because it goes through the process that does the recording but the users do not see that.
The transparent mode helps to monitor privileged accounts which we could not do before.
We have integrated it with test and development. They do not know the password either. Previously, they were the kings of their kingdom, whereas now, they are just users of their kingdom. They also now have to go through One Identity Safeguard.
If a privileged user does something malicious or suspicious, with session recordings, we can see what happened. We can see this person authenticated with two factors when he logged into One Identity Safeguard. If it was not something malicious, we can use this information to become better so that the issue will not happen again.
What is most valuable?
The implementation time was quick. It was basically up and running within a week.
I like the features that allow you to rotate your password, give you access to an RDP session without knowing your password, and record sessions. This is helpful for external people coming in, as we can review what they have been doing and use the recordings for training purposes. For example, if I want to upgrade a system that an external consultant did, these recordings can help identify issues. We can set different keywords to cut off a session if something malicious is detected. We can prevent a malicious action.
We use it to log in to various systems such as Linux and Windows, which is very convenient. There is also a personal vault for browser use, allowing us to save credentials for business-related websites securely. If a user leaves the company, I can assign that vault to another user. I can share credentials, save files within One Identity Safeguard, and ensure that certificates and license numbers are securely stored. I can see who has access to the files. I can save license numbers and license files in One Identity Safeguard, so I know where they are saved. I can also give access only to those who need it, as opposed to them residing on a file share or OneDrive, where access is not as transparent.
What needs improvement?
From a management point of view, it would be beneficial if One Identity Safeguard Privilege Password and One Identity Safeguard Privilege Session had a more similar interface. Also, if Privilege Session pushed more data to Safeguard Privilege Password, an admin would only need to log in to one place. They could then see the sessions and everything happening, even if it is running on a separate appliance. Why should I log into Safeguard for Privilege Session separately when it has been requested through the Privilege Password appliance? It would be advantageous if it was seen as one unified box, even though they are different. This is the improvement I would like to see.
For how long have I used the solution?
I have used the solution for less than a year.
What do I think about the stability of the solution?
It is stable. I would rate it a nine out of ten for stability.
What do I think about the scalability of the solution?
It is very scalable. I would rate it a nine out of ten for scalability.
Our clients are medium to large enterprises.
How are customer service and support?
Most clients use regular support, but some clients use premium support.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
In previous work, I have used CyberArk and Secret Server. One Identity Safeguard is way cheaper, intuitive, and easier to use. Its implementation costs are much lower than CyberArk.
It is on par with Secret Server, but you do not have session recordings. You just have the privileged passwords and rotation features. You need to harden the Windows because it was installed on Windows, whereas One Identity Safeguard is already a hardened appliance. One Identity Safeguard is more secure than Secret Server. However, I used Secret Server a couple of years ago. It has probably matured now.
How was the initial setup?
We are using the virtual appliance because we already have a virtual environment. The only on-prem setup we have are the physical servers that run a hypervisor. We like to have everything virtual. We can also secure a virtual appliance in a different way compared to the physical appliance. With a physical appliance, if something happens, we have to get hold of the vendor and sort out how fast they can ship a replacement, whereas we can deploy a virtual appliance instantly and get it up and running if there is a problem.
One Identity Safeguard Privilege Password is rather straightforward, rating it as an eight out of ten. Privilege Session is more like a six out of ten, being a bit more complex if I want to use all the features. However, if I just want to use it in Transparent mode, it is easier.
In total, it takes less than two weeks, depending on the landscape. Some preparation, like obtaining certificates and securing a backup share, is required first. I do require input from others to implement it within two weeks. If I can gather all the necessary data and access, the implementation becomes more straightforward.
The deployment was disruptive in a way for the privileged users because they now needed to log in through the web interface, whereas previously, they could log in directly. There are more or different steps. Instead of clicking directly on an asset they want to log in to, they need to log in to a different web page and request access. There are a few more mouse clicks than before, but we now have a better security posture of our environment.
To manage and do the implementation, you need to know certain things. You can also use a trusted partner for implementation. If you do not change anything in the system or do not want to do other connection types, you do not need that much training. You need to be aware of what you should look for. A three-day workshop with a partner would be sufficient. For end-users who need to use the system, a two-hour training would be enough.
What about the implementation team?
We have two One Identity Safeguard specialists in our organization.
What's my experience with pricing, setup cost, and licensing?
It is more expensive than Secret Server but way less expensive than CyberArk. As a customer, I would like the pricing to be lower, but it has a good price point.
What other advice do I have?
There is no reason not to recommend it. Everyone should have a PAM solution to prevent privileged user damage and mitigate risks like stolen passwords or insecure storage. If you want to ensure recordings of activities, be it from external people or highly privileged users, then this is essential. This reduces the risk of malicious insiders. You cannot always prevent it, but having recordings allows you to pinpoint activities before a system failure. You can consider having SPA analytics for additional security. We do not have that yet because of the price, but we might add it later.
I would rate One Identity Safeguard a nine out of ten.
Which deployment model are you using for this solution?
On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor. The reviewer's company has a business relationship with this vendor other than being a customer: Partner