Having been in this position, I usually just took a moment to have a chat with management/supervisor or senior developers. This shakes out various ways:
1) The Company has a strict policy, IT has to handle all these things - even for developers. They know it's a pain, but they have to have it this way. You'll be asking for a lot of passwords, unless...
2) The Company has a strict policy and can't/won't change, but developers tend to do whatever they want anyway. A senior tech once asked me what I used for a given task, and I told him, and he responded, "You developers...you just can't use the approved program list, can you?" - with a knowing smile.
This is often referred to as "covert" or "black bag" operations, where everyone uses what they want and management knows, and people just don't say anything or particularly care as long as you don't come complaining when something goes wrong (and you don't screw up anything for anyone else). The downside here, by the way, is sometimes political games are played and if anything goes wrong you can get chewed on even if your tools/software/workstation had nothing to do with it - especially if you are junior ("if any of your team is captured or killed the Secretary will disavow all knowledge").
3) The Company has a strict policy...and knows about you pesky developer types, and grants you local admin privileges on your own machines, or even sets up unmanaged virtual machines you can use to run your tools without screwing up their workstations and making them reinstall an image when you inevitably blow the thing up.
We all say we know what we are doing, and we all end up blowing up an OS install at one point or another. "I'm pretty sure manually installing an alpha version of the wrong driver and editing the registry to make the process go faster didn't cause a problem...cough..."
Especially when the company doesn't have a ton of new hires into your department regularly, or if your dev department is just a small edge-case for what IT does in a day, sometimes people just forget how to handle things and they have no checklist for dev installs.
At all non-software companies I've worked the dev tools are not a standard part of any image or install and are handled on a case-by-case basis anyway.
4) The Company has things the way they are for a reason and they do not, or can not, change because you dislike it and it seems unproductive. You end up just having to put up with it, though the good news is usually it dies down once you get everything setup and you rarely need to call for a password anymore.
Sometimes you also get very good at using software that doesn't require admin privileges, or...see #2 above. Sometimes it's just a downside of tough policies, secure infrastructure, bad management, or the nature of bureaucracy...the upside is often that you don't really need to worry about any of it and when the next big security vulnerability pops up and it's revealed the NSA is actually The Missing Butler (gasp!), it's not your problem. You just do your job, or have a visiting hour while IT scrambles to patch and reboot all workstations, secure in the knowledge that it's "Not My Problem". This may or may not suite your style of work and personality, but different environments for different folk!