When I posted the Referral Madness article, there was an intriguing comment that I didn’t get a chance to investigate until it came up in a case. The commenter noted that when we used RPC_C_AUTHN_GSS_NEGOTIATE as our authentication mechanism, we could no longer use “Check Name” in the dialog brought up by ConfigureMsgService:
If we hit Check Name, we get an error that the name could not be resolved due to network problems:
To understand why we get this error, we look at one of the caveats I noted:
During profile configuration (ConfigureMsgService), the Exchange provider will do an NSPIBind to the Exchange server to lookup the mailbox name. This single bind and lookup is unavoidable.
In order to perform the name resolution involved in Check Name, the Exchange provider is going to go through DSProxy. In network terms, this means we’re sending the packets directly to the Exchange server. DSProxy picks up our packets and forwards them on, unchanged, to the GC. Consider how this affects authentication. When we use RPC_C_AUTHN_GSS_NEGOTIATE, in most environments this means we’re going to use Kerberos. Combining the two: the client thinks it needs to negotiate Kerberos authentication with the Exchange server. It begins the handshake, sending a packet with a ticket using the Service Principal Name (SPN) for the Exchange server. DSProxy grabs this packet and whips it on over to the GC. The GC tries to parse the ticket in the packet but can’t since the ticket wasn’t intended for the GC. The GC returns the Kerberos error KRB_AP_ERR_MODIFIED. This error bubbles up on the client side as MAPI_E_NETWORK_ERROR, resulting in the dialog.
This problem with proxying Kerberos packets was noted in a KB article a long time ago, which has one of the earliest references to profile settings to enable referral. In the KB article, they wanted to enable Kerberos authentication to get around a problem with authenticating local system accounts, but due to the problem discussed here, also had to enable referral.
Does this mean we’ve got a bug in DSProxy’s handling of Kerberos? Not really – DSProxy predates Windows’ adoption of Kerberos by a number of years. Kerberos authentication can by proxied, but the proxy must be aware it’s proxying Kerberos traffic – it’s not as simple as reading packets off one port and sending them out another. On the other hand, NTLM authentication, the default used by the Exchange provider when we don’t specify an authentication mechanism, can handle being passed to the GC by DSProxy. This would fall under the heading of design limitation.
So – the upshot:
- Failure to perform Check Name in this scenario does not indicate a problem with the profile and does not indicate a problem with the network.
- If you’ve configured a profile for referral and reconnect, using RPC_C_AUTHN_GSS_NEGOTIATE, you cannot use ConfigureMsgService to reconfigure the profile. If you really want to reconfigure the profile, build a new one instead.
- If you want to be really clever, you could remove the auth setting before calling ConfigureMsgService, then add it back when you’re done.