Enterprise Random Password Manager 4.0

When a member of your IT department leaves the company, you know you need to change critical passwords such as the domain administrator password, the SQL Server systems administrator password, and even the four-digit combination lock on the server room door. However, many companies fail to change the local Administrator password on individual servers and workstations. And let’s face it, who wants to take the time to do it?

That’s where Lieberman Software’s Enterprise Random Password Manager (ERPM) 4.0 comes in. This product does more than just change passwords—it also manages passwords, and includes a web-based password check-in/check-out procedure. Once the product is set up, ERPM can even automatically change local Administrator and other service account passwords, and provides full and secure access to the account passwords. Let me dive in and show you how ERPM works.

Installing the ERPM MSI package on a dedicated server takes only a few seconds and is straightforward. A SQL Server backend (i.e., SQL Server 2000 or later, Microsoft Data Engine) must be preinstalled and running before you begin installing ERPM. Once the ERPM server product is installed, you use a configuration wizard to set up your backend database. In just a few minutes, I was connected to SQL Server, had created a new database, and had ERPM talking to the SQL Server.

After ERPM is connected to SQL Server, the wizard takes you to the Deferred Processor Setup screen, which you can use to configure ERPM to automatically change local Administrator and service accounts passwords without having to continually provide it with the proper credentials. The account that you use must have local Administrator rights to each machine in the domain so that it can change the local passwords, restart NT Services, etc. For this review, I chose to use the domain administrator account. For more information about how to grant local Administrative rights to a machine without using the domain administrator account, see the web-exclusive sidebar.

After ERPM is up and running, you can create and populate a group of servers using the GUI located under the ERPM Start menu item. Although you can populate the servers manually, I really liked having the option to “link” a group of servers in ERPM to an organizational unit (OU) in Active Directory (AD). When you select this option, new objects that are added to AD will automatically show up in the ERPM group.

Next, you can set up a schedule for when the local Administrator password, service account passwords, or any other password will automatically change. ERPM can also change passwords for OSs and database platforms other than Windows and SQL Server, including MySQL, Oracle, Linux, OS X, UNIX, Cisco, or mainframes such as AS/400 or OS/390. Passwords can be changed hourly, daily, weekly, monthly, yearly, or every N days. These passwords are random, encrypted, and stored in SQL Server. Lieberman Software recommends that the local Administrator password be changed daily, or weekly at the least. Service account passwords should be changed on a schedule that you set because the NT services that use these accounts will be restarted automatically by ERPM. (Note that this is a requirement of Windows, not ERPM.)

Once your hardware has been added to a group, you can quickly drill down and find out which services are logging on with an account. If you’ve ever taken over a network that someone else has built, you know what a challenge it is to figure out which service accounts are enabled on which servers. With just a few clicks of your mouse, you can quickly see where specific service accounts are being used. ERPM verifies this information without the need for a client-side agent.

As soon as the initial set up is complete, you can configure the many other ERPM options that are available. There are too many options to describe in detail, but the following options caught my eye:

Once ERPM has been setup and the machine groups have been populated, your administrators and Help desk staff will spend most of their time in the Web Application GUI. A GUI configuration page walks you through everything you must do to get the Web Application up and running. Don’t forget to set Microsoft IIS to allow Active Server Pages (ASP); otherwise Microsoft Internet Explorer (IE) will report that it can’t find the web page. Granular security permissions for the web page can be set via the ERPM executable or Web Application. Security for the web page is tied directly to AD accounts and negates the need to create yet another set of usernames and passwords. This tie-in to AD also showcases EPRM’s ability to work across domains within a forest, and even across forest trusts.

After you’ve configured the local Administrator password to change on a set schedule, you’ll eventually find that you need to use that password. The Web Application lets you “check out” the password for two hours (as Figure 1 shows) if you need to gain access to a machine. If your business requires it, you can even create a workflow that forces certain people to be approved before they’re given the password. After the password has been checked back in, it’s changed again to keep it secure. This entire process is audited to ensure that only authorized users are viewing the password.

ERPM earns my highest praise for a simple-to-use product that fills a huge hole in password security. The only thing that bothers me about ERPM is its high price. With a base price of $25,000, a company with a network consisting of 50 servers and 500 workstations would have to spend almost $30,000 to implement the product in its environment, and that price doesn’t include a maintenance agreement. However, if you need to regularly change your local Administrator and service account passwords, and need to be able to check out these passwords with an audit trail, then you owe it to yourself to look into this capable product. I am extremely impressed with ERPM.

In my Enterprise Random Password Manager review, I mentioned that the Deferred Processor required local Administrator permission to change local passwords and/or restart NT Services. In the review, I chose to use the domain administrator account because it’s automatically added to the local Administrator group when the machine is added to the domain. However, using this all-powerful account probably isn’t the best idea in a production environment. In fact, the domain administrator account shouldn’t be used at all on a day-to-day basis; IT personnel should have separate administrator accounts that have been delegated the proper authority in Active Directory (AD), and the domain administrator account password should be locked away for safe keeping.

To grant the Deferred Processor (or any other service or user) local Administrator rights to a PC or server, you need to complete the following three steps:

Once you’ve completed these steps, the setup should look similar to Figure A. Completing these steps takes only a few minutes on one or two computers, but can be a nightmare if you have hundreds or thousands of machines. So how can you add a global group to a local Administrators group on multiple machines without visiting each PC? Let’s take a look at two methods for adding a global group to a local group in such environments.

Method 1: Using a Script
You can use a simple logon or machine startup script similar to the following command to add a global group to a local Administrator group:

net Localgroup Administrators "DomainDeferred Processor" /add

Note that you must place quotes around names that have spaces in them.

Method 2: Using the Restricted Groups Policy
There’s a Group Policy, called Restricted Groups, that provides a more elegant method for adding a global group to a local group. The Restricted Groups policy’s name doesn’t describe it very well. Even the Microsoft article at support.microsoft.com/kb/279301 doesn’t quite provide the whole story about Restricted Groups. Let’s look at how you can use Restricted Groups to add a global group to a local group.

You can find this Group Policy under Computer Configuration/Windows Settings/Security Settings/Restricted Groups. Once you’ve navigated to the Group Policy Object (GPO), right-click it and choose Add Group from the context menu. Next, enter the name of the local group on the machine to which you want to add global groups. For our example, you’ll want to add to the local Administrators group. A new window will pop up that lets you add domain users or groups to the local group, which you can do by clicking Add in the Members of this Group section. I recommend referring to Figure A to keep the process straight as to which group goes where.

Be sure to note which groups are already in the local group that you’re modifying because implementing the Restricted Groups policy will remove all groups and users from the list on the local machine. For example, the Domain Administrators global group is automatically added to the Local Administrators group when a machine is added to the domain. If you forget to add domain administrators to the Restricted Groups policy, domain administrators will be removed from the local Administrators group. At this time, I don’t know of a way to force the GPO to append additional users and groups to the original list; it’s strictly a replace operation. The next time that Group Policy is refreshed on the machine or the machine is rebooted, the list of users and groups in the local Administrators group will be replaced by the list in the Restricted Groups policy.