LSA Protected Mode Troubleshooting Tips for Windows Server 2012 R2 and Windows 8.1
I need help with LSA protected mode. How do I enable auditing and do other troubleshooting?
In my previous Ask an Admin post, I described the new LSA protected mode in Windows Server 2012 R2 and Windows 8.1, how it works, and how to enable the setting. LSA protected mode is not turned on out-of-the-box, except in Windows 8.1 RT where it cannot be disabled because it may cause compatibility issues with some third-party applications, such as smart card drivers or self-service password reset applications.
In this article, I’ll describe how to enable auditing so you can identify drivers or plug-ins that fail to load in LSA protected mode.
LSA Protected Mode Requirements
There are a couple of requirements that LSA drivers and plug-ins must comply with to work with protected mode:
- The driver or plug-in must be digitally signed by Microsoft through the WHQL program.
- All drivers and plug-ins must be developed according to Microsoft Security Development Lifecycle (SDL) best practices.
Turn On Auditing for LSA Plug-ins and Drivers That Fail to Load
In the example, we’ll configure LSA auditing on computers in your domain. You don’t need to enable LSA protected mode itself; if an LSA driver or plug-in doesn’t meet the necessary requirements for protected mode, an event will be logged but the driver or plug-in will not be blocked from loading.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
Log on to a Windows Server 2012 R2 domain controller with an account that has permission to create and link Group Policy Objects (GPOs):
- Open the Group Policy Management Console (GPMC) from the Start menu.
- In the left pane of GPMC, expand your AD forest and domain.
- Right-click the Group Policy Objects folder and select New from the menu.
- In the New GPO dialog, name the GPO Audit LSA and click OK.
- Click the Group Policy Objects folder in the left pane.
- Right-click the new GPO in the right pane of GPMC and select Edit from the menu.
- In the Group Policy Management Editor window, expand Computer Configuration > Preferences > Windows Settings.
- Right-click Registry, and then select New > Registry Item from the menu.
- In the New Registry Properties dialog, click HKEY_LOCAL_MACHINE under Hive.
- In the Key Path box, type SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\lsass.exe
- Type AuditLevel in the Value name box.
- Select REG_DWORD in the Value type drop-down menu.
- Type 1 in the Value data box and click OK.
- Close the Group Policy Management Editor window.
- In the left pane of GPMC, right-click your AD domain or an Organizational Unit, and select Link an Existing GPO here from the menu.
- In the Select GPO dialog, choose the Audit LSA GPO and click OK.
What to Look For in the Event Log
Once the Group Policy has applied to a machine in scope, you can check in the machine’s Event Viewer for any potential problems loading LSA drivers or plug-ins in protected mode.
- Open Event Viewer from the Start screen.
- Navigate in the left pane to the Operational log under Applications and Services Logs > Microsoft > Windows > CodeIntegrity.
- In the Operational log, search for Event IDs 3065 and 3066.
Event ID 3065 shows that the driver or plug-in didn’t comply with SDL best practices for Shared Sections. Event ID 3066 indicates that a plug-in or driver didn’t pass a code integrity check because it wasn’t signed by Microsoft.
In a large environment, you might want to set up Event Forwarding to collect the logs from multiple computers in a central location for convenience.