For all other shipping Classes/Methods than X509, NAM allows you to provide a fully-customized LDAP Query that overrides default queries.
X509 does allow you to trim down sub-strings of data that it has consumed from a user's client certificate, but that minimal customization is insufficient control, comparatively.
Our use-case is as follows, but consistently adding a customizable LDAP Query capability to X509 would open up many other possibilities:
O365/Azure AD is federated via NAM.
Azure AD is synchronized with on-prem AD via Azure AD Connect. One of the attributes synchronized is proxyAddresses. Among other data, this multi-valued proxyAddresses attribute essentially maintains a historical record of all email addresses that have ever been assigned to each account, not just their current/primary Email address. The present and historical email addresses are stored within the proxyAddresses attribute with an "SMTP:" or "smtp:" prefix
Group Policy is enabled to provision a per-user client certificate our internal Microsoft Certificate Authority into the Personal certificate store of each Domain User who logs into a Domain Computer, with their current primary email address as the Subject/CN of the client certificate.
While this all comes together with NAM protected sites/federation, and mostly works today, there is an important gap that leads to frequent failures to X509 authenticate.
Microsoft Certificate Server / GPO on a Win10 PC will not automatically trigger replacing that per-user Personal client certificate with an updated one just because the primary email address for a user happened to change.
Our email addresses format of email@example.com, so many scenarios necessitate it's changing (woman's surname changes due to marriage/divorce, someone decides to change from full legal first name to a nickname such as John.Doe@company.com to Johnny.Doe@company.com, etc).
So when NAM consumes this email address from a now-"stale" client certificate and performs an LDAP Query against the primary "mail" attribute in on-prem AD, it is no longer able to locate the user.
And we can't simply point NAM's X509 Class LDAP map against that proxyAddresses attribute in AD, which syncs down from Azure AD/Exchange Online, because of that "SMTP:" prefix on the current/historical email address values in that attribute.
All of this would be easily solved if NAM were to properly extend the same flexibility it affords all other Class/Method types in allowing us to define a custom X509 LDAP query, like the following:
By allowing us to define custom X509 queries based on *any* of the collected fields in the client certificate (in addition to the existing regex trimming feature), we can inject the "smtp:" prefix into the LDAP Query and allow matches against all current/historical email address values in the proxyAddresses attribute.
Such a customized LDAP Query creates a high-degree of survivability for those now-"stale" client certificates, through uninterrupted user authentication.