CyberArk Service/Dependent Accounts Notes

What are dependent accounts?

Dependent accounts are accounts that represent resources, such as Windows Services or Windows Scheduled Tasks, that are accessed from a target machine, and require the same credentials as the target machine. Dependent accounts may also be referred to as usages or service accounts.

When changing a password, the CPM synchronizes the target account password with all other occurrences of that password in the related dependent accounts. The following dependent accounts are supported:

Windows Services	Windows IIS Directory Security (Anonymous Access)
Windows Scheduled Tasks	Configuration Files
Windows Registry	Database String
Windows IIS Application Pools	Web Application Accounts
Windows COM+ Applications	Private SSH Keys

Here is CyberArk Doc's CPM Managing Service Account flow:

Create a dependent account

After you create a target account, you can created related dependent accounts for it.

To create a dependent account:

1. In the PVWA, on the Accounts page, select the target account to which you want to add the dependent account.
2. On the Account Details page, in the right pane, select the relevant dependency type, and then click Add.

There are following service tabs available to add dependent account(s):

• Windows Service
• Scheduled Task
• IIS Application Pool
• Windows Registry
• COM+Application
• IIS Anonymous User

3. On the Add Dependent Account page, enter the required information, and then click Save.

How CPM Managing Service Accounts

Here is a good explanation found from Reddit which they are talking about how the process CPM  change service/dependent accounts works. I found it is helpful and copied here for my reference. 

CyberArk has two main offerings for service-type accounts (maybe Three if we consider Conjur separately.) - the "Push" and the "Pull" password options.

• PUSH - Out of the box, CyberArk can use the CPM to connect to target machines, and update the passwords on certain types of service accounts. For example: Windows Scheduled Tasks (which it can restart after the change), Windows Services, text files, registry files, IIS app users. There are certain limitations here, and risks.
• • For example, if I remember correctly, you can only have 100 of these "usages" per a single managed account.
• • It takes time for the CPM to reach out to each target machine running such a service, something like 3 at a time, so there is a possibility that accounts can get locked, or services can fail.
• • You basically want to use this for non-critical service accounts, or at least service accounts that have some tolerance for how quickly the password is updated in the service account's definition.
• PULL If you have certain business systems, specific applications which have been built to work with the CyberArk vault, or custom applications you can update, or applications that can get passwords using SOAP calls, then you can use the CyberArk "pull" mechanisms to pull passwords straight from the vault, which are grouped together as "AIM". For the most part it requires a separate license per device that needs these passwords, and you either install a CyberArk service on those devices can talk directly to the Vault, or implement code which can querry the CCP (Central Credential Provider) for a password, whenever the service needs it. The benefit here is that each service runs independently, and they can all be updated concurrently.

Now to answer your other question about the logon accounts. In the case of the "push" mechanism, if you need to change the actual password, but the account cannot change it's own password, you need a reconcile account. If you need to update the new password on the target service (for example on a Windows Scheduled Task), but the account doesn't have the permissions to log into the system and do it, then you need a logon account.