How to get a password filter dll signed so it loads with LSA protection enabled.

Question

Since enabling LSA protection, our password filter .dll file fails to load on startup, with Event Log errors indicating that we need to get the .dll signed by Microsoft:

• EventID 3033 logged in Event Viewer>Microsoft>Windows>Codeintegrity>Operational log with message:
• Code Integrity determined that a process (\Device\HarddiskVolume4\Windows\System32\lsass.exe) attempted to load \Device\HarddiskVolume4\Windows\System32<NameOfDLL>.dll that did not meet the Microsoft signing level requirements.

This Microsoft article gives information on how to create an LSA submission but it looks geared towards hardware and requests a CAB file which we don't have, simply an .msi and installation files including the password filter .dll.

Has anyone else gone through the process of getting their password filter. dll signed and can confirm which process they used, or can advise me that the above process is correct for our .dll (and what to do about the CAB)?

Many thanks

Answer 1

my signed DLL get this error when loaded with RunAsPPL set to 1.

Event 3033 records that a code integrity check determined that a process, usually LSASS.exe, attempted to load a driver that didn't meet the Microsoft signing level requirements.

The signtool.exe /verify /pm Filename.dll reports

Index Algorithm Timestamp

=====================

0 sha256 RFC3161

Does that look correct?

Answer 2

The signtool.exe /verify /pm Filename.dll command you ran is used to verify the signature of a file. The output you’re seeing indicates that the file was signed using the SHA256 algorithm and the timestamp is RFC3161 compliant. This seems correct.

However, if you’re still encountering issues, it could be due to the following reasons:

The DLL might not be signed with a Microsoft signature. Protected mode requires any plug-in that’s loaded into the LSA to be digitally signed with a Microsoft signature.

The DLL might not be compliant with the Microsoft Security Development Lifecycle (SDL) process guidance.

Configure added LSA protection | Microsoft Learn

You might want to check these aspects and ensure that your DLL meets these requirements.

[8a2a-7323-a87-7bfe] (microsoft.com)

Answer 3

Hello

Is this Issuer proper to meet the Microsoft signature requirement?

CN = DigiCert SHA2 Assured ID Code Signing CA

OU = www.digicert.com

O = DigiCert Inc

C = US

With Digest encryption algorithm sha256RSA?

Also is it okay for the DLL to have 2 signatures one sha256 and one sha1 for the digest algorithm?

Does a property called "unauthenticated attributes - Counter Sign" or "unauthenticated attributes..." with a series of dotted numbers impact the recognition of the Microsoft quality of the signed DLL?

I am trying to figure out what about my signed DLL is not being accepted?

Thank you

Lisa

Answer 4

The issuer you mentioned, DigiCert SHA2 Assured ID Code Signing CA, is indeed a valid issuer for code signing certificates. DigiCert is a widely recognized Certificate Authority and their certificates are trusted by major platforms including Microsoft.

As for the digest encryption algorithm, SHA-256 (which you referred to as sha256RSA) is a commonly used algorithm for code signing and is accepted by Microsoft.

Regarding having two signatures (SHA-256 and SHA-1) on the DLL, it is possible to dual sign a DLL with both SHA-1 and SHA-256. This is often done to maintain compatibility with older systems that do not support SHA-256. However, since May 9, 2021, Microsoft has been using the SHA-2 algorithm exclusively for all major processes and services, including code signing.

The “unauthenticated attributes” you mentioned typically refer to additional information that is included in the signature but is not directly authenticated by the signature itself. One common use of unauthenticated attributes is for time-stamping. Time-stamping allows Authenticode signatures to be verifiable even after the certificates used for signature have expired. However, without more specific information about the “unauthenticated attributes” in your DLL, it’s hard to say definitively how they might impact Microsoft’s recognition of the signed DLL.

If your signed DLL is not being accepted, it could be due to a variety of factors. If you’re still having trouble, you might want to consult with a software engineer or a professional who has experience with .NET and code signing to help troubleshoot the issue.

Stack Overflow or Microsoft Q&A

Answer 5

We got it working with a different cert