Compartilhar via

Auth and Check Names

  • Artigo

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:

Check Name dialog displayed by ConfigureMsgService

If we hit Check Name, we get an error that the name could not be resolved due to network problems:

The name could not be resolved.

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.

Comments

  • Anonymous
    October 22, 2009
    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.

  • Anonymous
    October 22, 2009
    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.

  • Anonymous
    October 22, 2009
    Writing my own ConfigureMsgService function which adds the MSEMS service to the registry is doable but I would rather not. :)

  • Anonymous
    June 02, 2012
    Stephen ... I'm using PR_CONVERSION_PROHIBITED and it seems to be working. Any gotcha's?

  • Anonymous
    June 05, 2012
    pcunite - what's the context here? I don't see the relation between your question and this article.

  • Anonymous
    July 18, 2012
    You state: "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." I'm saying that using PR_CONVERSION_PROHIBITED makes this NOT true. Then I ask, "what does this break?" :-)

  • Anonymous
    July 18, 2012
    All PR_CONVERSION_PROHIBITED effectively does is move the call to your first OpenMsgStore. If that works for your needs, then great.