LSASS Crashing, CNF Objects May Be the Cause

___________________________________________________________________________________________________________________________

IMPORTANT ANNOUNCEMENT FOR OUR READERS!

AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!

We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!

Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.

If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.

NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!

As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!

__________________________________________________________________________________________________________________________

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