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:
Is it possible to call ConfigureMsgService and have zero RPC auth attempts occur? I am trying to configure a profile and offline, disconnected from the network it works after a short timeout, but if the network connection is good and the user is not authenticated to the Exchange's domain I get a user/password prompt. I don't want to get the auth yet, just make a dummy profile.
Good question - I believe it's possible if you take on most of the configuration work yourself and fill in the properties manually...but I've not tried to do it myself. If you want to try it, look at the profile before and after you call ConfigureMsgService and see what properties actually get set. The trick would then be figuring out how to populate them.
Writing my own ConfigureMsgService function which adds the MSEMS service to the registry is doable but I would rather not. :)