One Identity Safeguard Reviews

We are using it internally because I work in a consultancy company. I use it both for our internal privileged accounts. We have different systems like Google Cloud, some internal servers, data centers, etc. To secure those privileged accounts, like the administrator accounts and root accounts, I use One Identity Safeguard to rotate passwords, authorize sessions, and more. The second use case is that we also implement One Identity Safeguard for different customers.

The most significant benefit is that in the past, we saved passwords in Notepad files or Excel files. Now, we do not, and we have more security. We do not have saved passwords or plain text passwords in different places within the organization. That is probably the most significant benefit regarding security.

In terms of integrations, we have basic integrations for our Windows and Unix servers. We do the transparent connection for LDP and SSH, and that is all. The integration is simple overall for this kind of connection. However, if we want to integrate different consoles or different systems, it is a bit more complex because it is not so much out of the box, but for our current systems, it was very easy.

End-users require just a couple of training sessions and some documentation, and they are ready to go. They can start using the tool as an end user in a week or less. Managers or administrators require a technical specialist training workshop, which is a full-week course. After that, they need one to three months of training with laboratories and documentation. They would need at least three months to work well with the platform.

The purpose is to ensure that privileged users do not know their own passwords.

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.

We use it to handle secure access to our Windows and Linux servers and also to manage some of our user accounts. This includes password rotation, JIT, and disabling accounts when they are not in use.

We use their physical appliance.

I look after the backend, but I am also a user of it. In general, users do not love it because there are extra steps to what they are used to, but it is an intuitive service. The approval workflows work particularly well with their integration into Teams. From a backend point of view, it is not too bad. There are a few places where the interface could be slightly different, but mostly, it is fairly intuitive.

The Approval Anywhere feature provides an approval process. We use it for our external contractors. It is nice and easy once things are set up from their point of view, and it provides the university with an additional layer or multiple layers of security, which we did not have before.

We have integrated it with Identity Manager, which is another One Identity product. We have not integrated it with anything else. We thought about integrating it with ServiceNow to have a one-stop shop from ServiceNow to make API calls and requests from there. However, we wanted to keep things a bit simpler at this point. The interface is pretty nice. Asking users to go via the Safeguard method works well.

We are a One Identity partner, and our clients use One Identity Safeguard for password vaults, session management for Linux and Windows servers, and network appliances.

One Identity Safeguard now prevents unauthorized access to servers by eliminating privileged passwords and requiring all connections to go through a PAM-authorized process. This means no one, including hackers, can access servers without explicit approval, significantly enhancing overall security.

One Identity Safeguard is easy to use with a good partner to support you, and it can be up and running within a few days.

We have successfully integrated One Identity Safeguard with cloud targets, and the process was straightforward.

One Identity Safeguard has improved our incident response time by 300 percent.

Our customer is a public service organization with about 800 privileged accounts and 8,000 functional accounts. The client already has a relatively unadvanced identity management implementation. It's a request-based identity management solution. What we're doing now is getting better control of the privileged accounts and getting rid of the old technology.

The end users don't know of an alternative. They are still subject to identity management through what is quite a large, manual process instead of process automation. For instance, the users do not have a self-service port where they can automatically get privileges they don't have today. Everything goes via the ITSM manual control workflow.

It's the manual processing our client currently has that is what we are thinking of improving. The installation was not set up by my team, but our job is to focus on the most sensitive information assets and secure insights into how service and other infrastructure are managed through privileged accounts. After that, we will work on simplifying the everyday user experience.

We work with just the physical appliances. It wasn't my decision. It was what the client already had. Regarding the form factor, just put it in a rack and it works. It's not an issue.

We're introducing the solution's transparent mode for privileged sessions. This is part of what the client hasn't used before. It will simplify their administrative situation greatly. So far, the rollout of this feature has been a seamless process, but we're still in the midst of rolling it out. The benefits will be on the risk side.

Right now, the way accounts are managed, you don't necessarily know who is using an account. There's a shared admin account, and that's not a good thing. And those accounts are shared in wallets by several people. One of the real benefits of safeguarding here is that the client will have an absolute audit of who is using an administrative interface, whether it's server or network.

I am an independent consultant who assists end users in deploying One Identity Safeguard correctly and creating all necessary workflows within the product. I then ensure its effective utilization in the production environment. I have been working with Safeguard since the beginning and continue to use it presently. Based on my experience, the majority of projects, around ninety-nine percent, involve virtual appliances. While I have performed some hardware appliance installations, I lack extensive experience with them. Therefore, I cannot definitively state whether they are good or bad. However, I can affirm that they function properly.

When we discuss the situation at the beginning of my journey, it serves as a safeguard. So, seven years ago, it primarily revolved around RDP and SSH session control. However, nowadays, I observe that customers are shifting their focus primarily toward password rotation and password management functionality. Moreover, they are increasingly utilizing the permanent analytics capabilities of Safeguard, such as user entity and behavioral analytics. Currently, we utilize all the functionality offered by One Identity Safeguard, including password rotation, password management, session management, and possibly session harmonics as well.

In most cases, we are referring to active directory environments and the safeguards implemented in such environments. This implies a close integration with the domain controllers, which serve as a source of identity information. However, the customers I work with as an independent consultant often utilize password management solutions. This indicates their desire to replace passwords, which may already be in use on certain devices. Sometimes, it involves scheduled password rotation. Additionally, session management has evolved. Nowadays, some customers are not only using RDP and SSH control but also MSS. Furthermore, I have worked on several projects involving HTTPS special control.

The situation as it was seven years ago, the usability and functionality of Safeguard were like three key questions in the case of Safeguard. Unfortunately, several years ago, they still had a sync client, which means a desktop application for one part of the product, while another part of the product was managed through the web UI. Of course, it was not so convenient. But nowadays, all the functionality is managed from the same console, meaning via the web UI, 100 percent. So, from this perspective, I can say that customers are quite happy with the current user interface of the solution.

The most important benefit is that when we talk about the deployment of any PAM solution, it serves as a centralized point for privileged access connections. This includes internal users, such as administrators or individuals with special privileges, like an accountant with additional access to the company's ERP system. This is in contrast to the standard situation where users have a direct connection to the target system, which lacks control. Firstly, a single point is created to enable full control over connections. Additionally, automation allows for quick response in case of any malicious activity. For instance, if the system detects abnormal behavior, such as in an SSH session, it can instantly terminate the session without requiring the involvement of cybersecurity personnel. The advantage of this approach is that it eliminates the need to involve humans in the process, which would take time. With a PAM solution like Safeguard, these actions can be executed within seconds, preventing any negative impact on the target system.

From my perspective, using the transparent mode is quite easy. However, from the customer's point of view, they should take the time to understand how it works properly. Once they grasp the concept of how this mode operates, which is made possible by the unique technology at the core of Safeguard's privileged session module, it becomes a significant benefit. Some customers may find it necessary to review this aspect carefully. Nevertheless, once they comprehend the intended functionality, everything else becomes straightforward.

I did not observe any issues concerning the rollout of the transparent mode for our users.

Monitoring privileged accounts using transparent mode is much easier from a user perspective, as it is almost invisible to them. What we are discussing is the deployment of Safeguard in transparent mode. From a monitoring standpoint, unfortunately, it does not prevent the injection of certain credentials. However, in terms of monitoring functionality, it is almost the same. Therefore, I cannot say that there is a significant negative impact from that perspective.

We utilize the secure remote access feature for privileged users. The majority of my projects involve contractors and third parties rather than direct employees.

Without One Identity Safeguard, managing remote access would be significantly more challenging. Safeguard is the tool that, from my perspective and based on my project experience, enables customers to have complete and effective control over remote access for both their contractors and internal infrastructure. It is remarkably user-friendly. Therefore, there is no distinction between deploying Safeguard for securing our internal network and implementing it for managing remote access from third-party networks and beyond.

It is nice that the Secure Remote Access feature does not rely on VPN; however, all of my customers continue to use VPN and utilize a VPN panel to manage remote access via Safeguard.

Our administrators mainly use it to protect their different packages and access secrets through Safeguard, either by checking out credentials, using encrypted sessions, or utilizing the product's API.

We are using a virtual appliance deployed in the cloud and on-premises.

The centralized storage of secrets and credentials prevents them from spreading throughout the organization. We know who has control over them and who has access. Before Safeguard, there might have been a few Post-Its stuck on screens, which isn't secure.

We have also gained visibility into the use of privileged access. It's way easier for us to see what, when, how, where, and why. We now have a good way to provide justification for doing things, instead of relying upon people to remember. Now we can demand that. 

And the rich level of logging, including visual logs with video recordings of sessions, has given us more confidence in our security posture, where we have onboarded the system.