Odd things …

 

 

Well - its been very busy around here and I haven't had a lot of time for posts.. but here was an interesting one… at least I thought so.

 

 

It began with the following events being posted – it appeared that there was something wrong with the authentication of the server to the domain. The clues to this are that the DFS service  runs under the local system , and the group policy processing was failing the machine group policy processing.

 

 

Event Type:        Warning

Event Source:    DfsSvc

Event Category:                None

Event ID:              14534

Date:                     9/4/2007

Time:                     11:03:33 AM

User:                     N/A

Computer:          MEMSRV

Description:

DFS Root DomRoot1 failed during initialization. The root will not be available.

 

Event Type:        Warning

Event Source:    LSASRV

Event Category:                SPNEGO (Negotiator)

Event ID:              40960

Date:                     9/4/2007

Time:                     11:00:35 AM

User:                     N/A

Computer:          MEMSRV

Description:

The Security System detected an authentication error for the server cifs/domain.com.  The failure code from authentication protocol Kerberos was "The attempted logon is invalid. This is either due to a bad username or authentication information.

 (0xc000006d)".

 

Event Type:        Error

Event Source:    Userenv

Event Category:                None

Event ID:              1053

Date:                     9/4/2007

Time:                     10:23:17 AM

User:                     NT AUTHORITY\SYSTEM

Computer:          MEMSRV

Description:

Windows cannot determine the user or computer name. (Access is denied. ). Group Policy processing aborted.

 

 

 

 

 

Now the interesting part was this event logged on the DC in the security event logs when “Audit Account Logon events”  for failures – was set:

 

Event Type:        Failure Audit

Event Source:    Security

Event Category:                Account Logon

Event ID:              675

Date:                     9/4/2007

Time:                     7:42:32 PM

User:                     NT AUTHORITY\SYSTEM

Computer:          DOMAINCONTROLLER

Description:

Pre-authentication failed:

                User Name:        OtherServer$

                User ID:                                DOMAIN\OtherServer$

                Service Name:   krbtgt/DOMAIN.COM

                Pre-Authentication Type:             0x2

                Failure Code:     0x18

                Client Address: 10.10.10.45

 

 

 

 

According to http://support.microsoft.com/kb/230476   we see that error 0x18 is:

 

0x18 (KDC_ERR_PREAUTH_FAILED) "Pre-authentication information was invalid"

This indicates failure to obtain ticket, possibly due to the client providing the wrong password.

 

               

 

 

Typically the scenario is that the machine account is not in sync with the machine ( perhaps some kind of replication issue\latency  after a join ) or there may be a duplicate SPN somewhere. ( Kerb ticket data  encrypted \ decrypted with "wrong"  password )  However in this case if we look closely you will notice that the event logged on the DC is a different name – however this event always coincides with the DFS svc restart  failures.

 

Odd. Yes?

 

The IP address of the client address -     Client Address: 10.10.10.45  was indeed the IP address for the computer named MEMSRV, but the Username and User ID was definitely not the correct one.

Another tidbit of info was that this server \\memsrv  used to be named \\otherserver  ( we can see this via data in the \windows\debug\netsetup.log.)

 

So the thought process then goes like this – how do we get that name in the Event Log? Is it passed from the client when we authenticate? Is it derived somehow from the DC? Is it a direct relation to the IP address and the DC places it in there via some name resolution process?

 

Well it turns out that the name is had from the DC – not passed from the client.  It calls something similar to NetUserGetInfo and gets the data from the account.

 

 

This changes things a lot – since if we assumed that the information was directly sent from the client then we may have had some odd items in the reg or who knows where related to the fact that this machine used to be called the User Name being registered in the failure event.

 

 

 

Anyway.. it turns out that the old machine account -  OtherServer$  still existed and it has a userPrincipalname = memsrv@domain.com.

 

One more thing – which I mentioned a little in an older post http://blogs.msdn.com/spatdsg/archive/2006/05/15/598260.aspx :

 

DFS Service runs as Local System

If the Kerberos authentication fails for some reason and we fall back to NTLM and it will authenticate as NULL

 

Authenticated as NULL in this case is anon and this is certain to fail so the whole thing falls apart.

 

spatdsg