If you read WhatIsTheCOMAuthenticationLevel, you learned that the COM authentication level is a setting that a client and server use to negotiate the protection of calls between them. The impersonation level is quite different, as it's designed purely as a protection for the client. You see, a secure server requires its clients to authenticate. And during authentication, if the server is trusted for delegation (WhatIsDelegation), the underlying security plumbing normally sends the client's network credentials to the server via a Kerberos ticket (WhatIsKerberos). The impersonation level is the client's control over whether this happens.

There are actually four levels, but only the last two of them are really meaningful in network scenarios:

• RPC_C_IMP_LEVEL_ANONYMOUS
• RPC_C_IMP_LEVEL_IDENTIFY
• RPC_C_IMP_LEVEL_IMPERSONATE
• RPC_C_IMP_LEVEL_DELEGATE

If you choose the last level (DELEGATE), you're telling COM you're happy to send your network credentials to the server if that server is trusted for delegation. This means the server can impersonate you (WhatIsImpersonation) and talk to other servers on the network on your behalf. Those other servers will think you are connecting directly! Clearly this implies a great deal of trust in the server. For more on delegation, see WhatIsDelegation.

Any other level besides DELEGATE prevents the COM plumbing from sending your network credentials to any server, even one marked "trusted for delegation" in Active Directory. The difference between the other three levels isn't very important in a remoting scenario, as there isn't much difference in how much real protection is afforded the client, as I'll explain shortly. But you'll see that some of these levels might actually cause server code to fail, so here's a tip: When choosing an impersonation level for remote scenarios, pick between the last two levels based on your delegation needs: IMPERSONATE or DELEGATE.

Let me show you what the first three levels mean so you can understand why I suggest the above policy. First of all, IMPERSONATE is the normal setting that says the server is allowed to impersonate you. IDENTIFY is a more restrictive setting that says the server is allowed to impersonate you but only for the purposes of making access control decisions. In other words, if the server impersonated you and then called the Win32 function AccessCheckAndAuditAlarm to decide whether you were allowed to do something (and perhaps generate an audit), this would work just fine. The server is allowed to identify you and check your groups, privileges, and so on. But while impersonating, a call to CreateFile would fail with a result of ERROR_ACCESS_DENIED because you didn't grant the server the right to open objects using your identity.

ANONYMOUS is weird. Take a remote case as an example. If the authentication level negotiated is something other than NONE, you authenticate with the server. But if the server attempts to get a handle to your token (the token produced as a result of authentication), this fails. The server process can't impersonate you or even identify you. But you've authenticated! You've sent a Kerberos ticket (WhatIsKerberos) or answered an NTLM challenge! Clearly the server machine knows who you are, but the operating system conspires to keep the server process in the dark. Do you trust the server's operating system and its administrator with your identity? I guess what I'm trying to say is that, if you don't want the server to know who you are, you shouldn't authenticate in the first place. Avoid using this setting. I doubt it's even received much testing, and it's likely to just break your code. This setting would make much more sense if used in conjunction with a server-to-client authentication protocol like SSL, but that’s not terribly common under COM.

I hope you can see that ANONYMOUS and IDENTIFY really have no teeth in the remote case, because you ultimately have to trust the remote server's operating system to enforce these restrictions. This is why I suggest choosing a level of either IMPERSONATE or DELEGATE in network scenarios.

If you need to configure this setting for a base COM client, see HowToConfigureSecurityForACOMClient. For a COM+ app, see HowToConfigureTheAuthenticationAndImpersonationLevelForACOMApp. For an ASP.NET app, see HowToConfigureTheAuthenticationAndImpersonationLevelForAnASPDotNETApp.

PortedBy GavinGreig