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
Time: 11:03:33 AM
DFS Root DomRoot1 failed during initialization. The root will not be available.
Event Source: LSASRV
Event Category: SPNEGO (Negotiator)
Event ID: 40960
Time: 11:00:35 AM
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.
Event Type: Error
Event Source: Userenv
Event ID: 1053
Time: 10:23:17 AM
User: NT AUTHORITY\SYSTEM
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
Time: 7:42:32 PM
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.
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 = firstname.lastname@example.org.
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.