Apparently, the company policy does not permit such user accounts to be given admin rights.
No one from the dev team has access to the production environment and the deployment is done by onsite support guys. That is how things work here. The support people report issues and we give them different solutions to try out until the issue is fixed.
So when it came to me I did exactly the following:
I created myself a sample page to host on my local IIS
Created a test user account to play with
Pound the MSDN for some clue
I started by revoking all rights and permissions from the user account and went up stone by stone. Incidentally I stumbled upon this link:
You need not make the user an Administrator, but just need to enable the “Log on locally” right.After enabling the Logon Locally right to the user, the impersonation worked like a charm.
Quoted from the link:
"You can impersonate with the returned token and check which Windows groups the user is a member of. Whether you can access local resources or network resources depends on the logon session type that you request (you specify the logon session type in the third argument of LogonUser). The most commonly used logon session types when calling this API are the following:
Interactive logon: If you need to access remote resources, request an interactive logon session. This results in a logon session that has network credentials. The user account passed to logon user must be granted the Log on locally user right.
Network logon: This establishes a logon session with no network credentials. This means you can impersonate the token and access local resources only. The user account passed to logon user must be granted the Access this computer from the network user right. By default, all accounts have this right because it is granted to the Everyone group."