UAC Privileges Flow Across WCF Boundaries

Today, I just spent an entire afternoon troubleshooting a problem in one of my WCF services. When the solution finally dawned on me, it was so simple that I wanted to kick myself, so I thought that by sharing my experience, I might spare you the agony.

In short, the setup was this: I had just developed a custom ServiceAuthorizationManager that basically just used WindowsPrincipal.IsInRole to test whether the caller (authenticated with Windows Authentication) was a member of .\Administrators.

I had already set it up on three of my four services, and it just worked as it should. On the fourth, however, it didn’t.

It was the same code running on all four services, and using the debugger, I could tell that in all four cases, the WindowsPrincipal in question represented my own account. However, in the first three services, IsInRole(".\Administrators") returned true as expected, whereas it returned false in the fourth service.

Even more strange, the fourth service exhibited expected behavior if IsInRole was called against Domain Users, or similar groups.

As far as I could tell, there was no significant differences in the WCF bindings and behaviors for the four services, but since WCF is pretty complex, I spent a lot of time comparing these without finding the reason.

It finally occurred to me that I was running my little test application for the fourth service in non-elevated mode, and since I was running on Windows Server 2008, the process didn’t have administrator privileges because of UAC. That I knew, but it had never crossed my mind that this non-elevated mode flows across WCF boundaries, so even though the service wasn’t impacted by UAC itself, the Windows credentials that represented my account was.

When I restarted my test tool in elevated mode, everything worked as expected.

It was my luck that I already had three working services when I ran into this issue; had I hit it on the first service, I might have concluded that my entire approach was unsound.

Comments (2)

  1. Kris says:

    I still don’t get the idea of writing a custom ServiceAuthrizationManager. Why could it not  support declarative style of a model ala asmx services where in you can apply security using the <authorization/> elements in the web.config file? It surprises me that they do not support this.

  2. ploeh says:

    It’s funny, because it was exactly such a ServiceAuthorizationManager I was setting up. Like you, I wonder why such a mainstream scenario isn’t supported out of the box…

    If I should venture a guess, it’s probably because of the composable and multi-hosting nature of WCF.

    You could set up a service listening on multiple endpoints, where one endpoint uses Windows Authentication and transport security, while another use X509 certificates and message security. In such a case, a ServiceAuthorizationManager that only works on Windows accounts would deny access for all requests coming in with message security based on certificates, and that’s probably not what you want.