I'll skip all the drama - but one thing you could do is call the help desk to get your password reset because of one clusterf after another. It actually worked great. Hi, my username is JoeBob. Ok JoeBob, your new password is XXXX.
That was it. This is a system with super long passwords that had to be changed ridiculously often, and an account lock feature after a few messed up entries which required a password reset and lots of temp staff who came and went among other issues (there were two layers of passwords and people constantly got them confused).
So they had a metric TON of password calls. Despite all the drama with passwords, you could get your password reset just by knowing your username and the number to call for resets. It was brilliant and did save a TON of time, but I had to laugh at the security of the system given your username was derived directly from your name and was widely available in reports etc.
I never mentioned anything though because the thought of a more complicated procedure to deal with for all the staff would have been a nightmare.
I haven't worked there for years. When I was laid off during the acquisition, I didn't protest, because I was about to look for a new job anyway. My only regret was not being allowed to finish building the new image deployment system so the persons to take up my duties wouldn't have to deal with yet-another-half-finished-system-built-by-people-no-longer-working-here.
Another thing they do is supply you with an endless cascade of developers who rotate in and out of your dev team on a 3-month basis. In those three months they will a) tell your IT team that they need a newer laptop because their current one gets slow when trying to run 3 instances of Visual Studio concurrently b) wonder why hard drive failures are correlated with rough handling of the laptop c) ask IT to troubleshoot their compilation errors d) only save their code locally instead of to a shared repo e) get upset when 3 months of said locally saved code, which IT was never told about, gets lost when the laptop, previously issued to the dev they replaced, is re-imaged before redeployment as per company policy/standard-procedure f) thereafter dodge turning in laptops to IT after their rotation ends, instead giving it directly to their replacement, causing IT's stores of deployable laptops to get depleted, and thus causing IT to come hunting after the never-turned-in laptops, because the next wave of 3-month devs is coming and hardware to issue them is needed, and finally g) treat company-issued laptops so roughly that when IT eventually does them back, what was brand shiny and new 3 months prior is now chipped, cracked, scratched and covered in grease and crumbs, and has a full kitten's worth of fluff accumulation in the cooling fan.
Okay, that last one was a bit hyperbolic, but every single point there did happen, and more than once.
Yes, I have been embittered by contractors from these large Indian IT firms, both as an end user 'supported' by them and as a co-worker supporting them. My experience with them has not been a positive one.