First of all, I would not call that a backdoor. A backdoor usually refers to methods of bypassing normal authentication, which would not include an Administrator account owned by IT. Nearly all corporations I have worked with have the IT department own the Administrator accounts and functions for all workstations and servers in the environment, whereas the end users just have unprivileged "normal" user accounts. There are a number of reasons for this:
- This prevents end users from installing unauthorized applications on company owned devices.
- Administrative functions, such as patching, can be centrally managed and ensured that they are applied in a timely manner.
- When an IT services employee has to work on a device, they do not need the end user to be there.
- Very Important: End users should be trained to NEVER give out their passwords, even to IT employees. It sounds like where you work, this is common. Above all, I would recommend an awareness campaign informing your employees to never give out their passwords to anyone, and make doing so against your corporate policy. This behavior completely invalidates your second bullet under your con section, and an employee can claim they gave their password to an IT person if anything "went wrong". Additionally, social engineering is the #1 way an outsider is going to get into your network... frankly, just flat out asking people for their passwords is quite effective in an environment like yours, even as a non-employee.
Eventually, you may want to look into an Identity Access Management (IAM) solution. If you purchase the right tool, the IAM solution manages all the administrator password in the environment, and each device has a different randomly generated password set. Any IT person that needs to work on a device must first log into the IAM solution with their credentials, "check out" the administrator password, and when done, "check it in". Once checked in, the solution will connect and change the admin password on that device, so only it knows the current password. If anything "wrong" occurs, you know the capabilities of the non-admin end user, and you can check the logs of the IAM system to see who had the admin password checked out for a particular device at the time to determine who caused the problem.
EDIT 7/27: Just to explain more regarding your below comment - small companies, such as a grocery store with 1 computer, generally have no data worth protecting (assuming credit card data isn't running through the PC), and so there is little reason to enforce an unprivileged user. Plus, grocery stores usually don't have dedicated IT folks supporting the single PC.
Large corporations, on the other hand, have significant amounts of data worth protecting. Forcing all users to run as an unprivileged user is a security measure to protect the company. Users are not security experts - they tend to download random software off the internet and install it. Often, this software has been backdoored by malware. Developers are famous for doing this, as they often like to "test" new tools. At best, this leads to an increased attack surface, at worst, the whole company's domain has been compromised.
Why do you believe developers need to be administrators to develop code? Speaking as a past developer, that is completely untrue. There is no reason to be a local admin to test/qa code. There should be a defined deployment process so that once a developer is done packaging an application, it can go through the corporate deployment/patching/update process to get pushed to the PCs that need it (initially, the qa testers). After the code makes it through testing, and is approved, it goes through the same process to be pushed to the rest of the company that needs the software installed to fulfill their job function.
That said, I am speaking about a more mature IT organization. It takes years to get there if you are starting from where it sounds like you are. Start small. End user/non-IT employees don't need to be administrators. Limit it to just IT initially. Develop your processes and procedures. Take a software inventory to determine what software is critical to the business. Eliminate everything non-necessary. Everything necessary becomes the "approved software" list. Anything not on that list, you will need an approval process to get put on that list. Continue making small, incremental changes, until you end up with a mature, and secure, IT organization.
Don't take my word for it:
