none
Kerberos Security / KDC errors

    Question

  • Hello.

    I have installed a Windows Server 2008R2 with AD DS (DNS, DHCP) and SQL 2008x64.

    Had a problem with SQL server agent that could not start with the default account (NT AUTHORITY/ LOCAL SYSTEM) so I created a new user with domain admin rights, authorised him to start the service and that was solved.

    Now I am having multiple Security-Kerberos error events ID3:

    Log Name:SYSTEM
    Source: Security-Kerberos
    Event ID: 3
    
    A Kerberos Error Message was received:
     on logon session 
     Client Time: 
     Server Time: 18:57:45.0000 2/22/2011 Z
     Error Code: 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN
     Extended Error: 0xc0000035 KLIN(0)
     Client Realm: 
     Client Name: 
     Server Realm: AI.LOCAL
     Server Name: MSSQLSvc/2008R2.Ai.local
     Target Name: MSSQLSvc/2008R2.Ai.local@AI.LOCAL
     Error Text: 
     File: 9
     Line: efb
     Error Data is in record data.

    From a small research I made, it may refer to the new account I created.Kerberos can not recognize the user and grant him a service ticket? Action I took was going inside the user properties (in AD Domain Users) and delegate him to use any service , which I understand is a security risk.

    I just want to see the outcome of this action.

     

    But then I have this "KDC encountered duplicate names while processing a Kerberos authentication request. The duplicate name is MSSQLSvc " which I suspect another service account tries to register the same process through Kerberos (?).Really need to investigate.

    Log Name:SYSTEM
    
    Source: Kerberos-Key-Distribution-Center
    
    Event ID: 11
    
    The KDC encountered duplicate names while processing a Kerberos authentication request.
    The duplicate name is MSSQLSvc/2008R2.Ai.local (of type DS_SERVICE_PRINCIPAL_NAME).
    This may result in authentication failures or downgrades to NTLM.
    In order to prevent this from occuring remove the duplicate entries for MSSQLSvc/2008R2.Ai.local in Active Directory.

     

    I also ran find /I "cannot find" %SYSTEMROOT%\security\logs.log and what I got was:

    ---------- C:\WINDOWS\SECURITY\LOGS\WINLOGON.LOG
     Cannot find MSSQLFDLauncher.
     Cannot find MSSQLSERVER.
     Cannot find SQLSERVERAGENT.
     Cannot find WdiServiceHost.
       .
      .
      .
     Cannot find MSSQLFDLauncher.
     Cannot find MSSQLSERVER.
     Cannot find SQLSERVERAGENT.
     Cannot find WdiServiceHost.

     

    practically the same pattern of those four a dozen of times.

    MSSQLSERVER is the instance of the SQL Server and SQLSERVERAGENT for the server agent for whom the same custom created user (SQLSrvagent) starts them both.

    Maybe my approach is wrong but felt I could take some small action :-)

    Any help would be greatly appreciated.

    On a side note no practical problems exist.Both SQL Srver and SQL Agent start and work good.

     

    Thank you.

    Tuesday, February 22, 2011 10:58 PM

Answers

  • Through ADSIedit brought on the object in question (SQL Server Agent), checked the ServerPrincipalName attribute and found the two entries:

    MSSQLSvc/2008R2.Ai.local and

    MSSQLSvc/2008R2.Ai.local:1433

     -Removed the one with the port.

    Then again setspn -x and got:

    Checking domain DC=Ai,DC=local
    Processing entry 0
    MSSQLSvc/2008R2.Ai.local:1433 is registered on these accounts:
            CN=SQL Server Agent,OU=Ai Users,DC=Ai,DC=local
            CN=2008R2,OU=Domain Controllers,DC=Ai,DC=local

    found 1 group of duplicate SPNs.


    So there was still one duplicate but this time in object 2008R2.ai.local (the domain controller).

    Same procdure as above, found entries and delete them both (since its the user account I want to authenticate the service).

    Again setspn -x and:

    Checking domain DC=Ai,DC=local
    Processing entry 0
    found 0 group of duplicate SPNs.

    So far SQL tasks ran fine and no more errors.Hope it stays that way :-P

    • Marked as answer by jsof Friday, February 25, 2011 9:28 PM
    Friday, February 25, 2011 9:27 PM

All replies

  • Having tried to create a copy of the default domain controllers policy got this:

     

    GPO: Default Domain Controllers Policy...Succeeded, but note the following issues:
    
    [Warning] The security principal [WdiServiceHost] cannot be resolved.
    The task will continue; however there may be unresolved security principals in the destination GPO. [Warning] The security principal [MSSQLFDLauncher] cannot be resolved.
    The task will continue; however there may be unresolved security principals in the destination GPO. [Warning] The security principal [MSSQLSERVER] cannot be resolved.
    The task will continue; however there may be unresolved security principals in the destination GPO. [Warning] The security principal [SQLSERVERAGENT] cannot be resolved.
    The task will continue; however there may be unresolved security principals in the destination GPO.

     

    But this comes some time ago where I had a DNS server issue (due to a bad NIC).

    Wednesday, February 23, 2011 1:12 AM
  • Errors still there :-\ I found some small hint through setspn :

    C:\Users\Administrator>setspn -x

    Checking domain DC=Ai,DC=local

    Processing entry 0

    MSSQLSvc/2008R2.Ai.local is registered on these accounts:

    CN=SQL Server Agent ,OU=Ai Users,DC=Ai,DC=local CN=2008R2,OU=Domain Controllers,DC=Ai,DC=local

    MSSQLSvc/2008R2.Ai.local:1433 is registered on these accounts:

    CN=SQL Server Agent ,OU=Ai Users,DC=Ai,DC=local CN=2008R2,OU=Domain Controllers,DC=Ai,DC=local

    found 2 groups of duplicate SPN s.

    These must be the duplicate entries Kerberos yells about :-) But how can I safely identify which one to delete?

     

    Thanks.

    • Marked as answer by jsof Thursday, February 24, 2011 12:31 AM
    • Unmarked as answer by jsof Thursday, February 24, 2011 9:19 PM
    • Edited by jsof Thursday, February 24, 2011 9:34 PM rushed answer
    Thursday, February 24, 2011 12:30 AM
  • Someone please?
    Thursday, February 24, 2011 11:48 PM
  • Hi,

     

    I would like to confirm if you have enabled Kerberos logging in the Domain Controller. Based on my research, the Kerberos Event ID 3 with extended error c0000bb is benign and can be safely ignored. If we have Kerberos login enabled on the Domain Controller we would expect to see this events. As a result, if everything works fine, I suggest that we disable Kerberos logging and check the result.

     

    How to enable Kerberos event logging

    http://support.microsoft.com/?id=262177


    Tom Zhang – MSFT
    Friday, February 25, 2011 9:43 AM
    Moderator
  • Through ADSIedit brought on the object in question (SQL Server Agent), checked the ServerPrincipalName attribute and found the two entries:

    MSSQLSvc/2008R2.Ai.local and

    MSSQLSvc/2008R2.Ai.local:1433

     -Removed the one with the port.

    Then again setspn -x and got:

    Checking domain DC=Ai,DC=local
    Processing entry 0
    MSSQLSvc/2008R2.Ai.local:1433 is registered on these accounts:
            CN=SQL Server Agent,OU=Ai Users,DC=Ai,DC=local
            CN=2008R2,OU=Domain Controllers,DC=Ai,DC=local

    found 1 group of duplicate SPNs.


    So there was still one duplicate but this time in object 2008R2.ai.local (the domain controller).

    Same procdure as above, found entries and delete them both (since its the user account I want to authenticate the service).

    Again setspn -x and:

    Checking domain DC=Ai,DC=local
    Processing entry 0
    found 0 group of duplicate SPNs.

    So far SQL tasks ran fine and no more errors.Hope it stays that way :-P

    • Marked as answer by jsof Friday, February 25, 2011 9:28 PM
    Friday, February 25, 2011 9:27 PM
  • I was facing a similar issue, and found that I had somehow (and I think I know how, copy/paste can kill ya') applied the same ServerPrincipalName to 2 servers in AD.  The name of the server I was trying to log onto was applied to itself and another server. Logging onto the other server was working as expected, but not onto the first server.

    I removed the extra ServerPrincipalName from the second server, and was able to successfully log into the first.

    Monday, May 20, 2013 5:20 PM
  • Nice, I found dublicate SPN By setspn -X and using ASIDIEDIT.
    Wednesday, December 28, 2016 6:39 AM