Control server will give control to the entire server not just to manage login of this user. I just need one user managing login of another user primarily enable or disable operations.
I think you are stuck with granting the ALTER ANY LOGIN permission with all the baggage/extra permissions that come with it.
An alternative might be to create a stored procedure with the code to enable/disable Login2 with the "EXECUTE AS" option using a login that has the elevated permissions. Then grant execute permission on that stored procedure to the low-level permissioned Login1.
Theoretically it should work, but I haven't tried it.
However it's not going to work in my case as the user will have execute SP permissions as well as DML permissions for SQL code deployment. So he can modify the SP and may be cause threat or audit concern.
I am not able to put my finger on it, but the requirement that a login has to have a wide range of permissions, and ability to alter just one other login seems like a it is less than robust design/security setup/something else. Perhaps if you took a step back and looked at your goals, there might be some way to achieve the end result that you are looking for in a simpler manner? I don't know, I am just asking/suggesting.
User1 is not a DBA however will be performing SQL deployments which should allow him to alter objects (no SQL jobs, logins, configuration etc) and data.
Before the deployment begins he has to disable application login (SQL login User2) to stop user's using application. Hope this is clear now.
I will perhaps try deny alter on specific sproc to User1 and this sproc will alter the login for User2,