Lithnet Application Logs in Event Viewer are Not Getting Generated at the Time of Password Change

[sageking94]

Hi,

The Lithnet password protection is working fine in one of our test active directory domain controller server systems while in the other test server, the Lithnet password protection is not at all working. Also, we have noticed that the Lithnet application logs in the event viewer are not getting generated at the time of password change in the test server where the tool is not working while the logs are getting generated correctly in the server where the tool is working correctly. Any hint to indicate why such a thing is happening and how to troubleshoot it would be greatly appreciated.

P.S: We have noticed that the Lithnet password protection dlls are properly registered in both the test servers.

Thanks in advance.

[ryannewington]

Hi @sageking94
The first thing we can check is if windows is actually loading the password filter DLL at start up.

Reboot, the server, and look for event ID 3, with the message "The password filter has been successfully loaded."

If it doesn't appear, I'd take the following steps

1. Uninstall LPP
2. Install LPP
3. Reboot
4. If event ID 3 still does not appear, then look for other events in the event log that indicate a problem loading the password filter.

[sageking94]

Hi @ryannewington,

Out of the 2 test active directory domain controller servers where we have installed the Lithnet password protection application, the event ID 3 is found with the message "The password filter has been successfully loaded." only in one of the servers where the application is working correctly while it is not being found in the other one where the application is not working correctly. Even on performing the first 3 steps, the event ID 3 still does not appear. So I believe we would need to look for other events in the event log if we are to find out why the password filter is not loading properly as you have mentioned in the 4th step. Do you know which event IDs we can look at for finding out why there is a problem loading the password filter?

Thanks in advance.

[ryannewington]

The events would probably be from lsa or lsass. I don't have specific event IDs, but it would be worth checking them all from the boot sequence. It could be a 3rd party software app such as AV blocking it from loading.

[sageking94]

I just checked the lsa/lsass events along with the antivirus client logs on the test AD DC system where the Lithnet Password Protection is not working. On that system, we are not getting any log after filtering for the source "LSA" in the event viewer console. Also. Did not find anything to indicate that a 3rd party software application such as the antivirus is blocking it from loading.

[ryannewington]

What does the following command return

 reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa" /v "Notification Packages"

[sageking94]

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
Notification Packages REG_MULTI_SZ rassfm/0scecli/0lithnetpwdf

[ryannewington]

@sageking94 It seems the filter is registered correctly. There's something blocking the DLL from being loaded. The only things I can suggest is going through all event logs from start up with a fine tooth comb looking for clues, or perhaps engaging Microsoft for troubleshooting assistance if you have a support contract with them. Even in the scenario where the filter wasn't configured correctly, we'd still see that event ID 3 which occurs when Windows loads the password filter. It's the very first thing that happens when the DLL is loaded. So something fundamental is happening to stop Windows for loading the filter.

[sageking94]

Hi @ryannewington,

Found this.

Event ID: 16953

The password notification DLL lithnetpwdf failed to load with error 577. Please verify that the notification DLL path defined in the registry, HKLM\System\CurrentControlSet\Control\Lsa\Notification Packages, refers to a correct and absolute path (:<path><filename>.) and not a relative or invalid path. If the DLL path is correct, please validate that any supporting files are located in the same directory, and that the system account has read access to both the DLL path and any supporting files. Contact the provider of the notification DLL for additional support.

[sageking94]

Would like to know which are the supporting files in this context.

[ryannewington]

Ah great work on finding this. Ok, so this (strangely) means that there was a problem with validating the digital signature on the password filter DLL.

Can you confirm the version of lithnetpwdf.dll in c:\windows\system32 on each server, and run the following command on the working and non working server and report the results

 reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa" /v "RunAsPPL"

[sageking94]

The results are the same in both the servers(the working and the non working servers):

RunAsPPL REG_DWORD 0x1

[ryannewington]

Can you confirm the version of lithnetpwdf.dll in c:\windows\system32 on each server?

Can you also check the digital signatures tab, and see if both Lithnet and Microsoft signature show that they are ok

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs.

[ryannewington]

@sageking94 can you also let me know what version of Windows each server (working and non working) is running

[sageking94]

Hi @ryannewington, both are having windows server 2016 standard edition.

[ryannewington]

@sageking94

I've been able to reproduce this on Server 2012 R2. The issue doesn't seem to appear on Windows Server 2019. I'm still investigating what is going on, but there is definitely something up with that version of c runtime. I'm going to try making a new build and linking it to the latest c runtime. I'm currently having some EV signing certificate issues that I'm trying to sort out with my vendor, so it will be a few days before I have updates on this.

[sageking94]

Ok

[ryannewington]

An update on this issue - We've been working with Microsoft and have confirmed that Windows Server 2012 R2 and Windows Server 2016 are impacted, and Windows Server 2019+ is not. This appears to be related to a recent change in signing certificate Microsoft have used for the Visual C runtime.

[ryannewington]

We've released a fix to workaround the issue with the Microsoft signing certificate

https://github.com/lithnet/ad-password-protection/releases/tag/v1.0.7242

[krokeau]

Hi, just wondering about this issue that i have actually on a two 2019 servers. This command showed me that LSA was not configured on both servers : reg query "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa" /v "Notification Packages"

It's been added in registry and rebooted, but lithnet still doesn't work in the same manner. Should i try to reinstall ?
i got event 3 at boot, and the reg queries above return (now) the expected results.
Best regards and thanks :)