Lieberman ERPM Account Pooling

When trying to secure a domain service account which is running some kind of service, it is normally no big deal. But when we talk about a service account that is running on multiple hosts, we are often faced with a challenge of potentially locking out that account. Which means it will also bring your application down.

For example, if you are trying to propagate your passwords to other servers and one of those servers fails in the propagation, you may have a server that still has the old password, and when it tries to re-authenticate back to the domain it can potentially lock out that account.

Let’s say we have an account that we wanted to change/rotate the password for:

  •  Account: APP1SVC
  •  Current password: Passw0rd

We are tasked to rotate that password for APP1SVC so we can be in compliance and prevent our systems to be compromised. So, we initiate a password change for APP1SVC on the domain controller and give it a new password of “NewPassw0rd”. ERPM does this by initiating a password change for APP1SVC on the domain controller where the identity resides and then propagates the new password down to any of the servers that is using that account.

So, after the password change job has completed. We noticed that we were only successful in changing the password on Server1, and Server3, but were not successful in changing the password on Server2. For whatever reason, we were not able to propagate the change on Server2.

We now have a server that still has the old password and we now have a potential risk.

Let’s say Server2 was offline due to maintenance being done. When the server comes back online, it will try to start the service and since it still has the old password it will eventually lock out account due when trying to re-authenticate.

This is where Lieberman’s Account Pooling can be very helpful. Lieberman’s answer to this is quite simple. Create at least 3 services accounts and place them in the Account Pooling for rotation. This account pool will house the identities to be able to run your services.

Let’s say we created the following accounts to be utilized in the account pool.

  • SVCAccount1
  • SVCAccount2
  • SVCAccount3

The following is an example how your environment would be configured:

In this example, we have scheduled a password rotation job and selected the option for Account Pooling. ERPM will rotate the service account in sequence for the following servers:

  •  Server1
  •  Server2
  •  Server3

Let’s say we run another scheduled job and this time Server2 is down for maintenance, so we were only successful in changing the password for Server1 and Server3.

In this scenario once Server2 comes back online, it will still have the necessary credentials to run the service and upon next password rotation it will then be updated as well. This will help maintaining stability and prevent the potential downtime.