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.