Leiberman RED Identity Management [EOL] Reviews

Our use case is for privileged account password management.

It's more of a risk reduction. It takes passwords that are not being managed properly and manages them automatically which really reduces risk.

The password management is good.

They should improve the application password management. The capability to manage high availability application passwords is its biggest shortcoming.

It's stable, it's not the best in its class by any means but it's stable.

It's plenty scalable, there are no issues there. We have tens of thousands of users. To maintain it we have about a two headcount minimum, up to ten thousand a count. After that probably two headcounts for every ten thousand count.

Everybody's technical support isn't great so it's as good as anybody else's.

We also use CyberArk which I believe is the best of all the options. 

The initial setup was straightforward. The time it takes to deploy depends more on the client. If the requirements are clear then we can go from zero to production in probably four to six weeks.

The pricing for Lieberman is cheaper than the others that are in the market. The licensing is complicated but a lot of the privileged accounts are. 

We compared a lot of the available solutions, almost all of them. CA has one and we also looked at Thycotic Secret Server. The one thing they have over CyberArk is that CyberArk is more expensive. The only reason I see any of my clients choosing Lieberman over the other product is because, in most cases, it's cheaper.

I would advise someone considering this solution to make sure that you validate your use cases during the sales process. Make sure that you're going to have the capability that you need.

I would rate this solution a six and a half out of ten. 

The solid-state aspects of the platform. Once properly built out, the ERPM environment will run pre-configured, complex operations with little human intervention.

We have benefited as follows:

• Automation of the rotation of privileged credentials across the enterprise
• The Active Directory discovery almost always uncovers previously undiscovered accounts that are running processes in the environment
• Provides visibility of all accounts and secures them: This greatly reduces the attack surface
• Ability to manage passwords on multiple platforms – Windows, Linux, cloud-based and on-premise from a single pane: This is conducive to sound security practices.

The included session recording is not very robust.

The session recording feature is supplementary to the core product. It is an implementation of Microsoft Expressions and IIS Media components, freely available from Microsoft, that plugs into the ERPM product.

With this enabled, sessions that are launched through the ERPM Application Launcher can be recorded, using those free MS components and the exposed ERPM web service.

It records simple, flat Windows Media Viewer format files, and is suitable for very basic recording needs. It is not a very scalable or robust offering and offers no session management capabilities.

ERPM can run without this component enabled. ObserveIT integrates very well with the product and provides true robust recording and management capabilities. The product integrates successfully with Balabit as well.

I have used the product for thirty months.

We did encounter a few issues. Versions 5.5.0 and 5.5.1, which were feature releases, experienced some issues. These seemed to be alleviated by Version 5.5.2.

We did not encounter any scalability issues. Through zone processors and proper hardware scaling, I never saw any limits to the capacity of the product. It is built to be scalable to a virtually infinite capacity. One customer tests this almost daily and is able to support large environments with ERPM.

I would give technical support a rating of 10/10. They are 100% U.S. based in Austin Texas. Their guys are top notch.

I didn’t use another solution previously.

The initial setup was mixed. The product requires a SQL backend and SSL certificates. This is simple enough to provide, but most organizations manage those assets outside of the group that ends up implementing ERPM.

There is usually some internal pain getting all the people that need to be involved on-board. But once these pieces are in place, along with the SSL certificates and SQL backend, the setup is a snap.

Do a full PoC in production. The AD discovery data alone usually shows people the true scope of their password issues. It will also reveal how many licenses will be needed.

Workstations, which are often an afterthought, are an attractive attack surface. I would include them in the PoC as well. The licensing for workstations is pennies on the dollar compared to servers.

We evaluated Lumension, but everyone in my organization was pretty sold on ERPM.

Do a full PoC, compare it to other products, and ensure that ERPM or competing products will integrate well into your current security operations and owned systems.

ERPM has a full suite of API integrations, and any competing products considered should have that as well.

Password vaulting and password recovery: The encrypted password protects the clear text passwords and the recovery checkout process provides an audit of when the password was used.

When our field engineers logged into a workstation, they had to use the local admin password. They maintain 12,000 workstations. We used ERPM to create a new local admin account that is managed by ERPM, created a management set and defined all the workstations into the set. This saves the techs from manually changing the passwords on all those systems and provides them with the ability to recover the password (which is different from all the others) for specific systems.

Macs: The support team wasn't too knowledgeable about how to deploy the above solution to MAC workstations.

We deployed a solution where our desktop support team would use a local admin password created and managed by ERPM. There is a default local admin on each machine. We replaced it with an ERPM-created local admin account. The problem we faced was for MACs, we needed to know the current password of the default ID.

While setting up management set, we had Lieberman support on the phone and our developer was correcting most of the recommendations from their architect.

Apparently, they don't have a large MAC user base. It took a few days and several phone sessions with them before we were satisfied with the whole process so we could continue with the deployment.

Overall, ERPM looks like a good product and we are only using a small percentage of the features it says it will offer.

I’ve been using this product for two years.

We have had no issues with stability.

We want to manage DBA privileged IDs that access Oracle DBs. We have 100 DBs and 30 DBAs and there is no automated way to grant the access. Plus, we have over 1000 DBs coming into our environment. We won't be able to use ERPM.

With the exception of Macs, technical support is very helpful.

We did not have a previous solution.

I came in after the initial deployment, so I do not know about that. Setting up the management system and jobs was easy and straightforward.

Have a good roadmap defined so there are enough licenses to complete deployment and handle future growth. We had to pause our deployments until we purchased more licenses.

I came in later in the deployment, so I don't know whether any other options were evaluated.

Schedule enough time to implement in a lower environment and test out all aspects before putting into production.

It is very easy to install and enumerate all machines from an Active Directory domain and begin changing passwords on domain and local accounts. Managing service accounts is very easy as well.

Session recording generally works but intermittently stops. The permission model for individual accounts could be made better. It would also be nice to be able to group accounts together, specifically with domain accounts. Currently, the product is centered around nodes and machines.

The permission model is based around what they call Management Sets. Management Sets group together computers. So if you have multiple accounts on the same computer, you are not able to easily assign different permissions. The best example of this is the Active Directory domain. To Liebermann, it’s a single computer with lots of accounts. You could add the domain to multiple management sets, but that will create other problems. If you have service accounts in your Active Directory domain, the only choice for is to assign specific permissions to specific accounts as opposed to using some time of grouping.

I have used it for 1-2 years.

We did not encounter any issues with stability.

We did not encounter any issues with scalability.

Technical support is 7/10. They are generally good but in my experience slow to respond on product issues.

Straightforward and easy to install; very simple to make the initial connection to an Active Directory and pull in accounts and computers.

Analyze your requirements and ensure that you allocate enough time. PAM/PUM is not a simple process. There are the initial quick wins but when it deals with service accounts, the amount of time required to manage one account can increase exponentially.

Randomizing local accounts on all endpoints

• ERPM's greatest ability is that it can easily randomize ALL local accounts on almost any endpoint. One of biggest security risks that occur within a company is the ability of an attacker to compromise one system and then use similar local accounts to slide horizontally through an environment. Many organizations will use group policy to change the local admin account and even change the password as well. The problem with this is that every Windows system will have the same name for their local admin account and most likely, have the same password for every one as well. If an attacker is able to compromise one system, then there is a high likelihood that they will be able to compromise multiple systems within the environment as well from these local accounts.
• By randomizing local accounts, ERPM is able to keep local account passwords from becoming stale. Depending on the company's policies, it might be required to change all passwords every 30 days, 90 days, 180 days, etc... Without a tool to randomize all of these accounts, then trying to do this manually or remotely would be extremely difficult and time consuming. By setting up jobs to do this within ERPM, I do not have to do anything other than check a report to make sure all of my systems are being randomized.

• Service accounts normally have heightened permissions on servers, workstations, and throughout a company's environment. However, service accounts are also forgotten about and do not have their passwords changed very often. Before we started to crack down on service accounts in my environment, we had passwords for service accounts that were several years old. The only caveat to this is that for ERPM to change the password of the service account and then push it to the locations that it is being used, the service account must be available via a COM object, service, a task or other Windows functions. If the account is embedded within a program, either an API must be written to change the password from within the program, or the password must be manually changed.
• Using ERPM to change ALL Service Account passwords is not ideal or always possible, but it does help with many accounts; and can give an auditor insight into how old a password is and where it is being used within your environment.

Randomizing accounts that have elevated privileges in the domain:

• Since most IT administrators must have the ability to perform maintenance, install programs, and other tasks on servers or sensitive systems, they normally have admin rights on these systems or domain admin for an entire domain. This makes the IT group a VERY high target for attackers since most company's IT admins use their normal computer account to access servers as well. In order to have a clear segregation of a 'user' account and a 'server' account, we removed ALL permissions for a user's account from all servers, appliances, or sensitive systems and created 'server' accounts to access these sensitive systems. In order for an admin to access a server, sensitive system, or appliance, they must 'check out' the daily password for their server account and then use that account to perform their daily duties. If an attacker were to compromise an IT admin's normal account, they would only have access to that computer and would not be able to navigate through the environment with heightened permissions. Even if an attacker were to get local admin on one server and tried to dump the hashes to try and grab stored accounts for other users, these passwords would be no good since the password gets randomized every 24 hours. This has actually saved us during one of our third-party penetration tests where the tester was able to get onto a server using a compromised service account that ONLY had rights to that one server. Even though the tester dumped the hashes from the registry, all of the account's passwords were old and were not able to be used. This kept the tester from obtaining domain admin within our environment. Now, the tester could have sat on the server and possibly grabbed credentials from memory from a user that logged on later using mimikatz or another tool, but this would have taken more time and resources.

• RDP
• Admin Checkouts
• Removing hard-coded credentials from most of our built-in Apps

One of the features that ERPM is capable of providing is giving users the ability to 'request' admin credentials on their machines for a specific purpose (provided you have removed all users from local admin on their machines). You can force them to put in descriptions or ticket numbers for logging when they want to check out an admin password but keeping the backend configured properly, so that users can ONLY see their assigned computers is rather difficult.

My company is only around 600 users, so manually assigning users to specific computers is not too difficult but if my company was larger with several thousand endpoints, it would be almost impossible. Fortunately for me, we have spent time so that our CMDB is up-to-date. I can export the active computers in my network with the users who are assigned, and then import them into ERPM. I know some ERPM admins have to compromise by allowing users to see a 'group' of computers so that assignments can be by a group of computers instead of one to one but, to do it properly, you only want the user to have the ability to see ONLY their computer and nothing else. Also, you want to make the checkout experience as seamless as possible for the end user, so having only their computer show up makes it easier for them to navigate the web program. This is not a huge issue, but something that would be nice in future releases.

I have been using it since February 2013.

If you have multiple domains, DMZ's, or segregated subnets that cannot talk to the ERPM server, then setting up Zone Processors will be necessary. This has become easier to deploy but making sure the proper ports and permissions are given to the system that the Zone Processor exists can be a little time-consuming. Also, if the server that the Zone Processor exists has any issues, this can/will cause the Zone Processor to have communication issues with the ERPM Server. If the Zone Processor is not communicating, then any job that needs that Zone Processor will not work.

To help avoid this, we added the 'Restart Service' to every Zone Processor Service and we also monitor these Services using Solarwinds. If any of the Services restart or fail all together, then we are alerted via Solarwinds. This has helped our ability to have confidence that the Zone Processors are always up and operational.

Stability is not necessarily an issue since your purchase comes with a DR license for another management server. However, I have never had an issue with the program causing issues alone. The only actual issue I have had is, when the jobs run to randomize accounts, it can get stuck on a system and the job never completes. However, this is able to be mitigated by the Heartbeat setting that will allow forcing a job to stop scanning a specific system if it has not finished or shown any changes over x amount of time.

Also, we use High Availability (HA) for every aspect of the program. The ERPM solution can sit entirely on one server, which is absolutely what you DO NOT want to do. So, we set up two web servers that use a load balancer to redirect incoming requests to the server with the least amount of work. Both of the web servers talk back to two separate application servers; which gives us not only HA but also redundancy if one of the servers goes down. The application servers then point to what could be considered a ‘single point of failure’, which is the SQL Server Database. However, we have active mirroring to our DR site that allows ERPM (which has to be configure in the ERPM DB Setup) to automatically switch to the DR database if the primary SQL Server is unresponsive for a certain amount of time. We also have our DR instance of ERPM that the load balancer will automatically switch to if both of the primary web servers are down.

We encounter little scalability issues. The biggest issue was setting up the Zone Processors so that I could minimize latency in our remote locations and also use the ERPM solution to randomize endpoints in other domains. The process for setting up Zone Processors is simpler than it used to be, but you must have everything mapped out and know where you need every item before you start deploying ERPM to every endpoint.

I would give a 9/10. Whenever I have had any questions or issues with licenses or renewals, the Lieberman team has always assisted and fixed any issues extremely quickly and professionally.

Technical support is 9/10... I have never had an issue with their support. Anytime I have had an issue, they have responded to my emails within minutes, which is faster than the call times for many vendors. If my issue is critical, then I will call and escalate the issue as quickly as possible.

This was our first PIM solution.

For Windows-based systems, the setup is relatively straightforward. You will need an account that has the ability to change passwords or manage any endpoint that you want controlled by ERPM. For accessing other operating systems, it can be a little more challenging. It took some configuring, but we are also randomizing the built-in accounts for our IDRACs, ESXi Hosts (which they just started offering), and some of our more prominent printers. We do not do ALL of our printers because every printer requires a different Response File to do the call to randomize the password. However, if you can annotate how any system authenticates into the underlying OS, then you can build a Response File that can do the randomization call.

Make sure to scale implementation before purchasing any licenses. Know what systems and endpoints you will use this solution for and the location of those endpoints; so, the proper number of licenses is purchased and the number of Zone Processors is known beforehand. The Zone Processors are used to randomize systems that are in different locations (another country and you want to minimize latency) or in a DMZ. As long as you open the proper ports for the Zone Processor to talk back to the ERPM application, a Zone Processor can be placed almost anywhere and does not have to be a member of the ERPM application’s domain.

Unknown. It was a significant upfront cost but I believe that the amount of malware that has been blocked and possible infections that have been avoided due to randomizing the accounts truly outweigh the cost of the product and yearly maintenance renewals.

Make sure you know exactly what endpoints will be utilized for the solution. The only difference in price is between Standard Endpoints (Windows workstations, Linux, Cisco, etc...) and Servers (Microsoft Server 2008, 2012, etc...). Make sure you know if you are going to use this on just servers and workstations or if you will also include network devices, printers, IDRACs/ILOs, VMware ESXi and others.

Cyber-Ark