With the Impersonate functionality a user can work on behalf of another user.
This means that a user account can specify other accounts that can operate with their account. In other words, if user-B is allowed to impersonate user-A, then user-B can take actions using the full account details of user-A.
This allows the impersonator accounts to complete tasks as if they were using the account they are impersonating; for example, during an absence or to share an excessive load short-term.
Not sure if this would work without adding User A in the impersonators tab for User B
If user-B should be able to work as user-A, user-A should add user-B to it's list allowed impersonators. That means, that you as a user-A designate the user-B to act as your standin during your absence (to stay in the scenario Arun outlined).
I already know this part. What I need to understand is why only the user "admin" is able to impersonate without adding it to any of the user's impersonators tab, and not any other user within the administrators group.
Adding each user to the impersonators tab is manual and long, as I have thousands of users and doing it manually is not possible. So was just wondering why any user in the administrators group, is not able to impersonate ?
admin user(not administrator group) account is special account which used to to carry out maintenance tasks in JCR, as well as performing project administration actions that project owners aren't allowed access to. It is kind of a super user account.
As Jörg mentioned, the functionality was designed so each user would define who their impersonators are.
A few years ago I had to do something similar and my best advise to you is to create your own admin tool to add and remove impersonators from users. The good news is that the actual implenetation of this tool is quite easy