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 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.

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.

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.

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