none
Problems with Exchange 2007 and Outlook 2007 Kerberos Authentication.

    Question

  • Hello,

    I have a fairly large lab deployment of Exchange 2007 in a distributed form as follows:
    2 DC's
    2 HUB/CAS
    2 Mailbox
    1 CCR
    1 Cluster

    The DC Servers also have installed Outlook 2007 Client for testing.
    The issue i'm experiencing is that Outlook repeatedly asks for my username/password, but never actually logins. Investigations show kerberos errors (537 with 0x7 code) and some garbled characters for the "logon source" (never seen anything like it...).
    Playing around with NTLM/Kerberos settings on the client, i see that i can logon with NTLM flawlessly, but negotiation seems to fail (even though it reverts to NTLM!). kerberos however, if i force it, fails on "bad password" on the MACHINE account(the Exchange server).
    fairly odd up until now, gets weirder...
    the problem i'm describing is documented at: http://support.microsoft.com/kb/927612
    only that there, it's Outlook 2007 with Exchange 2003.
    Checking on it, i found that the proper SPN's do exist on the global catalog.
    baffled, i turned on kerberos logging and found events showing that the authentication failed since it expected to find the exchangeAB SPN on the Exchange Server(?!?).
    I tried manually setting the SPN's, but got the kerberos "bad username or password" routine again.

    I am COMPLETELY baffled! anyone encounter this? anyone has any idea?

    P.S. I've tried another installation of minimal server configuration, with the same results.
             Outlook 2003, however, works fine!

    P.P.S. I have noticed an odd thing about the cluster environment, from some reason the cluster EVS doesn't have the MDB SPN. which means it cannot accept kerberos authentication.
    I've tested this and it is so! why is that? what is the consideration for removing kerberos authentication from a cluster server?

    Thanks,
    Lior
    Tuesday, February 27, 2007 5:50 PM

All replies

  • bump.

    no one encountered this? anyone from ms has any thought about this?


    Sunday, March 04, 2007 12:49 PM
  • Outlook 2007 is pickier than Outlook 2003 in terms of permissions it requires.  I had a problem with Outlook 2007 and Exchange 2003 that turned out to be related to be missing permissions assigned to the Everyone group on the Exchange Organization object in AD. 

    http://www.activedir.org/article.aspx?aid=126

    Not the same as your problem, obviously, but might give you a few pointers.

    Tony

    www.activedir.org

    Sunday, March 04, 2007 8:04 PM
  • Hi Tony,

    Thanks for the (so far only) reply!

    The environments in which this problem is occurring are all newly installed and barely used, yet the issue is consistent with all of them. Nevertheless, i checked that proper permissions are in place as per the article.

    At some point i started thinking it was the fact that all these environments are virtual that might have caused the issue, but i have since then managed to duplicate the issue in a physical environment.

    I'm starting to suspect it might be a problem with the outlook 2007 client or the exchange 2007 installation that i have. both are from MSDN, and seem to offer no other problems.

    It seems strange that no MS reply has been made on this, is there another proper channel to direct this issue to them?

    Thanks,
    Lior
    Monday, March 05, 2007 9:32 AM
  •  

    I am having the same problem and ripping my hair out trying to find a fix!

    Monday, March 12, 2007 1:24 AM
  • Dont' think if you upgrade Exchange 2003 to 2007 that the problem disappears. If you use the Out Of Office function on Exchange 2007 with Office 2007 than the same login popup will come back for 3 times. So im going crazy here with everthinh on 2007.

     

    Tuesday, April 10, 2007 6:52 AM
  • The CCR server doesn't register its SPNs properly in Ex2007 RTM***. I fixed this for SP1. Look for 'exchangerfr' in the KB to get the list of four SPNs that need to be registered.

     

    Until SP1 comes out, a manual workaround is to use adsiedit and give the nodes “Write Public Information” permission on the CMS computer account. Then the System Attendant will have sufficient permissions to register the SPNs in AD.

    The CMS account would be something like this:
    CN=GC-NSAUDA-DOM,CN=Computers,DC=NSAUDA-dom,DC=extest,DC=microsoft,DC=com

    and NOT the one in the Configuration naming context.

    In the above, the CMS is named 'gc-nsauda-dom' (yeah, our test domains are really annoying to type Smile ).

     

    There is a nicer KB being written that explains this better than I can (e.g. I don't use adsiedit much, I usually use ldp.exe Smile ). I don't know what the KB number will be.

     

    -martin

     

    ***Why? The system attendant service (mad.exe) runs as LOCALSYSTEM (e.g. node1), which is fine on standalone mail servers. But on clusters, it tries to update the SPNs on the CMS account, which is not LOCALSYSTEM. So AD rejects access. In SP1, we register the SPNs from resrcmon.exe, which is running as the Cluster Service Account, which is the creator of the CMS account, so it will have permissions to update the SPNs.

    • Proposed as answer by Ziemek Borowski Wednesday, October 30, 2013 12:53 PM
    Tuesday, April 10, 2007 8:29 PM
  • Did you ever find a Solution to this problem
    Wednesday, May 09, 2007 4:29 PM
  • I'm afraid not. and no follow from microsoft on this either.

    But the problem, it seems, is completely the Outlook 2007 client's fault, as i behaves this way with Exchange 2003 as well.

    Sunday, May 20, 2007 11:28 AM
  •  

    I've spent 1 hour trying to find this space to convey my problem...

     

    I've forgotten my password to access Microsoft Office Outlook.

     

    please help

     

    ken t ward

    Saturday, June 02, 2007 9:55 PM
  • Not sure if this will help (you may have sorted it by now) but we were experiencing the same problem;

     

     - Outlook 2000 and Exchange 2007 worked

     - Outlook 2007 and Exchange 2007 didn't work.

     

    It turns out that Outlook 2007, by default, uses Negotiate Authentication where as Outlook 2000 would use NTLM Authentication.  That in itself is nothing special, but if Exchange 2007 is NOT a global catalog server (and it shouldn't be as Microsoft recommends it not also be a DC) but still has the two exchangeAB service principal names registered against itself, Negotiate Authentication will fail in Outlook 2007 (it's actually the kerberos authenticaion which is tried first that fails).

     

    The solution is to remove the exchangeAB SPN's from the Exchange 2007 server and ensure that these SPN's are registered against every DC that is a GC server.

     

    The whole process is detailed in this KB article:  http://support.microsoft.com/kb/927612. Even though it mentions Exchange 2003, it worked for us in Exhange 2007.

     

    Hope this helps.

     

    Cheers,

     

    Ross

     

    Tuesday, October 16, 2007 12:57 PM
  • We are experiencing a similar problem, Outlook say it is connecting the exchange server for 20-30 minutes but never does.  This does not happen for all of our users.  When it has happened, we have changed our Outlook 2007 Logon network security to NTLM and has resolved the problem. 

     

    Our mailbox servers are in a CCR and were built with the gold build (software assurance downloads).  We have recently upgraded to SP1 and the problem still occurs.  We are going to check the spn.  Is there something that we need to do post-SP1 install to ensure the SPN's are set correctly outside of going through http://support.microsoft.com/kb/927612?

     

    Tuesday, May 20, 2008 3:10 PM
  • I have the same problem. I solved aply this: http://support.microsoft.com/kb/936594/en-us.

    Friday, August 08, 2008 7:41 PM

  • I have a similar issue with Outlook 2007 the default installation cannot connect to ex2k3 using negotiate Authentication
    I have to change this to 'Password Authentication (NTLM)' in the security settings of the mail profile for the user.  This works fine after this has been changed, how ever with an 80% mobile work force we have the setup of Users Outlook automated no one seems to stay at the same machine for longer than about a week?  So any response to how to resolve this (I suspect an Exchange server issue) would be greatly appreciated.
    Monday, October 06, 2008 1:22 PM
  • Please ignore my post the web page had not loaded fully and i did not see the answers.  Just so you know http://support.microsoft.com/kb/927612 did fix the problem.

    Monday, October 06, 2008 1:51 PM
  • ofirst time posting on here but i found the problem:

     

    check your security settings on the autodiscover virtual directory in IIS. I changed it to basic and integrated authentication and it works like a charm. i hope this helps someone.

    Wednesday, November 12, 2008 9:23 PM
  • test

     

    Wednesday, November 12, 2008 9:27 PM
  • I know it's a little late for my message, but we are suffering the same issue with the Outlook clients in a branch office (we have outlook 2007 and exchange 2007).

    Everybody else in the org connects ok with the option "Negotiate Authentication", but in this branch we noticed that Outlook continuously asks for user credentials and never logs in. Changing security to use NTLM works charmly.

    We think it's maybe a problem with the DC in that branch, we are now troubleshooting Kerberos authentication against that server.

    Checking the security logs in the users mailbox, we saw a failure login event, when he tries to open outlook:

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          12/16/2010 2:40:19 PM
    Event ID:      4625
    Task Category: Logon
    Level:         Information
    Keywords:      Audit Failure
    User:          N/A
    Computer:      Server.hidden.org
    Description:
    An account failed to log on.

    Subject:
        Security ID:        NULL SID
        Account Name:        -
        Account Domain:        -
        Logon ID:        0x0

    Logon Type:            3

    Account For Which Logon Failed:
        Security ID:        NULL SID
        Account Name:       
        Account Domain:       

    Failure Information:
        Failure Reason:        Unknown user name or bad password.
        Status:            0xc000006d
        Sub Status:        0xc000006a

    Process Information:
        Caller Process ID:    0x0
        Caller Process Name:    -

    Network Information:
        Workstation Name:    -
        Source Network Address:    10.49.11.105
        Source Port:        4825

    Detailed Authentication Information:
        Logon Process:        Kerberos
        Authentication Package:    Kerberos
        Transited Services:    -
        Package Name (NTLM only):    -
        Key Length:        0

     

    Comparing it to a healthy security event:

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          12/16/2010 2:45:10 PM
    Event ID:      4624
    Task Category: Logon
    Level:         Information
    Keywords:      Audit Success
    User:          N/A
    Computer:      Server.hidden.org
    Description:
    An account was successfully logged on.

    Subject:
        Security ID:        NULL SID
        Account Name:        -
        Account Domain:        -
        Logon ID:        0x0

    Logon Type:            3

    New Logon:
        Security ID:        Domain\username
        Account Name:        username
        Account Domain:        Domain
        Logon ID:        0x363364b8e
        Logon GUID:        {afe748fc-9bcf-3463-10a0-9265b48e065c}

    Process Information:
        Process ID:        0x0
        Process Name:        -

    Network Information:
        Workstation Name:   
        Source Network Address:    10.37.11.123
        Source Port:        1866

    Detailed Authentication Information:
        Logon Process:        Kerberos
        Authentication Package:    Kerberos
        Transited Services:    -
        Package Name (NTLM only):    -
        Key Length:        0

     

    At the client machine, we can see these events (I cut only the important part because they are in spanish):

    Tipo de suceso:    Información
    Source:    Outlook
    Category:    None
    Id:    19

    Description:
    Cannot execute call (EcDoConnectEx) to a Remote Procedure Call (RPC) using transport (ncacn_ip_tcp) to server (Server.myorg) with error (721) after waiting (532) ms; eeInfo (Block (0), Error = 721, Version = 1, GeneratingComponent = 2, DetectionLocation = 97, Flags = 0, Params = 1, [Param (0) Type = eeptLongVal, Value = 80090322], Block (1), Error = 80090322, Version = 1, GeneratingComponent = 3, DetectionLocation = 96, Flags = 0, Params = 3, [Param (0) Type = eeptLongVal, Value = 9], [Param (1) Type = eeptLongVal, Value = 6], [Param (2) Type = eeptLongVal, Value = 10a1e]).

     

    Has anyone had this problem before? Maybe you can guide us to a quicker exit!

    Greetings and thanks in advance!!

    Rafael Sisto.

    • Proposed as answer by Diana191 Wednesday, May 22, 2013 9:48 AM
    Thursday, December 16, 2010 6:15 PM
  • Set the Logon Network Security to "Negotiate Authentication"
    Friday, September 09, 2011 10:33 PM