Authentication in Windows is really about two things: helping the client and server develop trust in each other's identities (they're introduced to one another), and helping them exchange a cryptographic key (what we call the session key) to protect their communication channel. The COM authentication level for any given call controls whether authentication occurs at all and, if it does, how much protection you'll receive from having that session key.

There are six levels defined, in order of increasing security.

1. RPC_C_AUTHN_LEVEL_NONE
2. RPC_C_AUTHN_LEVEL_CONNECT
3. RPC_C_AUTHN_LEVEL_CALL
4. RPC_C_AUTHN_LEVEL_PKT
5. RPC_C_AUTHN_LEVEL_PKT_INTEGRITY
6. RPC_C_AUTHN_LEVEL_PKT_PRIVACY

If a COM call goes out using the first level, no authentication occurs. The call appears to the server as anonymous, and the server is unable to determine the client's identity. The client has no idea who the server is, either. Zero protection. Avoid this.

The next level (CONNECT) says that the client and server authenticate only when the TCP connection ¹ is first established. The client and server might as well throw the session key away, because it won't be used to provide any further security on the channel (WhatIsCIA). This is akin to the level of security you get with the file server by default ². It's really quite weak and should be avoided.

The next level (CALL) is not implemented (COM internally promotes this to the next, more secure level if you choose it). If it were implemented, the first fragment of each call would have its headers integrity-protected with a message authentication code (MAC). No other protections would be provided. Weak.

The next level (PKT) says that COM will MAC-protect the headers of each fragment of each call. Because only someone who knows the session key can form the MAC, this prevents an attacker from injecting new packets. It also turns on replay detection and detects message-reordering attacks. Security is getting better, but an attacker can still modify the payload of a message without being detected, so this level is still unacceptably weak.

The next level (INTEGRITY) says that COM MAC-protects the entire payload of each fragment of each call. This is the first level I would recommend even considering in any application that cares about security.

The last level (PRIVACY) provides all the protection of the previous level, and all payload (not headers) are encrypted. Only someone who knows the session key (the client and server) is able to decrypt the messages. This is the level you should be using, unless you're debugging and need to see the payload in the clear, in which case you drop temporarily to the previous level. Be sure to use test data when debugging because everybody else on the network is seeing what you're seeing!

Figure 50.1 sums it all up (I've omitted the level that's not implemented).

Figure 50.1 COM authentication levels, summarized

Now that you understand what the different levels mean, let me explain briefly how COM figures out which level to use for any given call. By default, when you unmarshal a proxy (Box 1998), the proxy starts life using a level that's negotiated between the client and server processes. You see, each process that makes or receives COM calls specifies its preferred authentication level, so the client and server are both specifying a level that they desire. COM sets the proxy to use the highest of these two levels by default. The server rejects any requests that come in with a lower level than what the server specified, but this should never be a problem with normal clients because the default level is negotiated up front, and should never be lower than what the server requires. An attacker might try to lower the level by calling CoSetProxyBlanket, but the COM server-side plumbing will then reject the call because it's below the level specified by the server.

If either the client or server specifies a level of "privacy," calls between that client and server are fully protected by default. This is goodness! WhatIsCoInitializeSecurity and HowToConfigureSecurityForACOMClient explain how to configure these settings for your process.

One important note: You might assume that if you configure a process to use an authentication level of "privacy" or, for that matter, anything other than "none," anonymous calls will be rejected. This is in fact what used to happen back in Windows NT 4 prior to service pack 4. However, for some odd reason some code was added to the NTLM security provider in that service pack that has been with us ever since. This code allows null sessions (WhatIsANullSession) to go through the motions of authentication while really not proving anything. In other words, a COM client using a null session can connect to a server and make calls. The server sees a token for ANONYMOUS LOGON, as expected, but what's dangerous is that if your process requires authentication you probably expect COM to reject these requests. Well, it doesn't. You must use access control to block null sessions to COM servers (and clients, which often expose COM objects to handle callbacks, events, etc.) So be very wary of granting access to Everyone. If you're about to do this, stop yourself and instead grant access to Authenticated Users. I talk more about this in WhatIsANullSession and WhatIsCoInitializeSecurity). An odd bit of trivia is that if you've specified a level of "privacy" in your server (good for you!) and a null session is used to connect to you, the requests appears to be encrypted on the wire. This is security theatre though, not real security ³.

¹ . . .or the named pipes connection, SPX connection, or whatever connection-oriented protocol you happen to be using. Note that this level is internally promoted to the next more secure level if you're using a connectionless protocol like UDP, but COM uses connection-oriented protocols by default in Windows 2000 and beyond.

² Unless you turn on a feature called SMB signing, which provides integrity checks. This feature can be enabled via security policy under Security Settings, Local Policies, Security Options. Look for two entries called "Microsoft network server: Digitally sign communications . . ."

³ This blew me away the first time I saw it. How can a null session possibly be encrypting data securely? With a null session, there's no cryptographic key exchanged between the client and server. Clearly some funny business is going on here. Perhaps a hardcoded key is being used. Whatever it is, it's not secure!

PortedBy NaveenYajaman