Mike Lagase

Saving the Exchange world one day at a time.....

Outlook 2007 clients unable to perform Check name

Outlook 2007 clients unable to perform Check name

  • Comments 2
  • Likes

Yesterday,

I had an interesting issue where no Outlook 2007 clients were not able to perform a check name operation against any Exchange Server or Global Catalog server and we were continually prompted for authentication. Outlook 2003 clients and earlier did not have this problem. This environment was a simple setup with a single Exchange 2007 server hosting all roles on one Global Catalog server.

Went over the generics in http://support.microsoft.com/default.aspx?scid=kb;EN-US;297801, but that didn't provide any help. Oddly enough, Outlook 2007 was installed on the Exchange 2007 server as that in now currently supported and check name actually worked there.

So looking at this from the network side with a network trace, we see the following information being passed. 

Example Server Names we are dealing with in these traces.
---------------------------
Exchange Server - EXSERVER
Global Catalog - GC.DOMAIN.COM

Netmon snippets
------------------------
Here we see the request for a kerberos ticket, but we are trying to connect to the Exchange server to do the address book lookups based on the exchangeAB/EXSERVER principal name.

2394 108.092812 000FEA71865E 0019B9B0A9C5 KERBEROS KRB_TGS_REQ 10.0.0.11 GC.DOMAIN.COM IP

KERBEROS: KRB_TGS_REQ
    KERBEROS: Protocol version number (pvno[1]) = 5 (0x5)
    KERBEROS: Message type (msg-type[2]) = KRB_TGS_REQ (0x0C)
    KERBEROS: Pre-authentication Data (padata[3])
        KERBEROS: Data type = PA-{AP|TGS}-REQ
            KERBEROS: Protocol version numer (pvno[0]) = 5 (0x5)
            KERBEROS: Message type (msg-type[1]) = 14 (0xE)
            KERBEROS: Ticket (ticket[3])
                KERBEROS: Ticket version number (tkt-vno[0]) = 5 (0x5)
                KERBEROS: Realm (realm[1]) =DOMAIN.COM
                KERBEROS: Server name (sname[2]) =krbtgt/DOMAIN.COM
                    KERBEROS: Principal name type (name-type[0]) = KRB_NT_SRV_INST (Service & other unique instance)
                    KERBEROS: Principal name value (name-string[1]) =krbtgt/DOMAIN.COM
                KERBEROS: Encrypted part (enc-part[3])
                    KERBEROS: Encryption type (etype[0]) = RC4-HMAC-NT
                    KERBEROS: Key version number (kvno[1]) = 2 (0x2)
                    KERBEROS: Ciphertext (cipher[2])
            KERBEROS: Authenticator (authenticator[4])
                KERBEROS: Encryption type (etype[0]) = RC4-HMAC-NT
                KERBEROS: Ciphertext (cipher[2])
    KERBEROS: Request body (req-body[4])
        KERBEROS: Realm (realm[2]) =DOMAIN.COM
        KERBEROS: Server name (sname[3]) =exchangeAB/EXSERVER
            KERBEROS: Principal name type (name-type[0]) = KRB_NT_SRV_INST (Service & other unique instance)
            KERBEROS: Principal name value (name-string[1]) =exchangeAB/EXSERVER

Here is the response back from the domain controller that we receive
      
2395 108.092812 0019B9B0A9C5 000FEA71865E KERBEROS KRB_TGS_REP GC.DOMAIN.COM 10.0.0.11 IP

KERBEROS: KRB_TGS_REP
    KERBEROS: Protocol version number (pvno[0]) = 5 (0x5)
    KERBEROS: Message type (msg-type[1]) = KRB_TGS_REP (0x0D)
    KERBEROS: Client realm (crealm[3]) =DOMAIN.COM
    KERBEROS: Client name (cname[4]) =Administrator
        KERBEROS: Principal name type (name-type[0]) = KRB_NT_PRINCIPAL (Name of Principal)
        KERBEROS: Principal name value (name-string[1]) =Administrator
    KERBEROS: Ticket (ticket[5])
        KERBEROS: Ticket version number (tkt-vno[0]) = 5 (0x5)
        KERBEROS: Realm (realm[1]) =DOMAIN.COM
        KERBEROS: Server name (sname[2]) =exchangeAB/EXSERVER
            KERBEROS: Principal name type (name-type[0]) = KRB_NT_SRV_INST (Service & other unique instance)
            KERBEROS: Principal name value (name-string[1]) =exchangeAB/EXSERVER
       
So again, we are trying to connect to the Exchange server to perform the lookups and since referrals were turned on, we couldn't lookup the users account in Active Directory because the Exchange server itself was not a domain controller.

What did happen on this server recently is that this server was demoted from being a Domain controller while Exchange 2007 server was on the server. During this demotion process, the ExchangeAB SPN entries were not removed from the Exchange server causing this problem. After removing these entries, Outlook was happy once again.

On a side note, Outlook 2007 has some new changes so that if Kerberos authentication fails, we no longer fall back to NTLM which is what the previous Outlook versions did.

The steps to fix this problem is listed in http://support.microsoft.com/?id=927612.

To help detect this in the future, an ExBPA bug has been submitted so that we can detect this now on the Exchange servers having these ExchangeAB SPN entries as ExBPA already detected these SPN's on the domain controllers.

 -Mike

Comments
  • Have you tried this on Exchange 2010?

  • I have Exchange 2010 with Update Rollup 4 installed fresh as a new VM.  But, after I unregister the ExchangeAB SPN (even though this VM has never been a DC or GC), after I reboot, the ExchangeAB SPN comes back every time?  Any ideas?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment