LSASS Crashing, CNF Objects May Be the Cause

  • Article

Hey y’all, Mark back with a rare but hard-to-troubleshoot problem where CNF or conflict mangled NTDS Settings objects cause LSASS to crash on Active Directory domain controllers. The goal of this article is to create some awareness and have you install preventative fixes in the hopes of keeping both of our phones from ringing.

What is a CNF mangled NTDS Settings Object

First, a quick refresher on CNF or a conflict mangled objects. CNF objects are the result of conflict resolution when two updates for the same object are received at approximately the same time from two different originating DCs. Then these updates replicate to their partner DCs throughout the forest and eventually meet up and need to be handled in some way. More information on this can be found here and here. Anyways you end up with something that has the look of CNF:guid.

This article is focused on CNF mangled NTDS settings object (the parent object for Active Directory connection objects) which looks something like this:

image

 

As a side note, CNF mangled NTDS Settings objects are extremely rare. In an environment that replicates in a healthy way, this should not occur.  Many of us have tried to reproduce this condition in lab environments but were unsuccessful.

What Happens and How Do I Know if I’m Affected?

When CNF mangled NTDS settings objects are created, the Lsass.exe process may crash and unexpectedly reboot one or more domain controllers. So there is a pretty good chance you’ll know about it. You may not know the root cause of the crash. More specifically though you’ll see the following events in the Application Log which you can look for.

Log Name: Application
Source: Application Error
Date: DateTime
Event ID: 1000
Task Category: Application Crashing Events
Level: Error
Keywords: Classic
User: N/A
Computer: ComputerName
Description:
Faulting application name: lsass.exe, version: 6.1.7601.17725, time stamp: 0x4ec483fc
Faulting module name: ntdll.dll, version: 6.1.7601.18229, time stamp: 0x51fb164a
Exception code: 0xc0000374
Fault offset: 0x00000000000c4102
Faulting process id: 0x1f4
Faulting application start time: 0x01ceb94c671de3dd
Faulting application path: C:\Windows\system32\lsass.exe
Faulting module path: C:\Windows\SYSTEM32\ntdll.dll
Report Id: 80a2cd04-2540-11e3-99e2-441ea1d316a4
Faulting package full name: %14
Faulting package-relative application ID: %15

And

Log Name: Application
Source: Microsoft-Windows-Wininit
Date: DateTime
Event ID: 1015
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: ComputerName
Description:
A critical system process, C:\Windows\system32\lsass.exe, failed with status code 255. The machine must now be restarted.

How do I Fix This or How Can I Prevent It?

The key to this one is prevention so you don’t end up in this situation. If you are on Server 2008, Server 2008 R2 or Server 2012 R2, you’ll want to apply KB 2913087. If you experience this issue on Server 2012 please contact support and request a backport of this update. You’ll want to monitor for CNF on NTDS Settings objects until you can get these updates deployed in the meantime. If you are experiencing this issue applying the update will stop the reboots and you can follow along in the KB in removing the CNF objects.

· Open ldp.exe or ADSIEDIT.

· Connect and bind to the Domain Controller.

· Search the Configuration partition for any object where the Common Name contains "CNF:" and the object class is nTDSDSA. For example, LDAP search filter may look like this:
BaseDN = CN=Configuration,DC=contoso,DC=com(&(ObjectClass=nTDSDSA)(CN=CNF*))

If your DCs are rebooting so frequently that you cannot install KB 2913087 or manually remove the conflicted objects, try stopping the netlogon service or unplugging the network cable can buy you a bit of time to get it applied or cleaned up. But remember prevention is key for this.

 

Mark “conflict mediation” Morowczynski