Certificate-Based S4U Logon for Computer Accounts in Windows Security Architecture

Question

Hello, I work on the enterprise Windows Security Engineering team and am designing cross-service authentication flows for internal web APIs accessible only from managed devices. As part of this deployment, I intend to integrate enterprise-issued computer certificates into an LSA-based logon flow. Specifically, I am considering using the KERB_CERTIFICATE_S4U_LOGON structure within the LsaLogonUser function to obtain an identification level token for the computer account. This is evaluated as part of broader Zero Trust compliance requirements, and we are under pressure to avoid fully implementing user interaction authentication paths.

What I want to verify is whether this certificate-based S4U logon mechanism is actually supported for computer identities, or if it is strictly limited to user principals within the Windows security architecture. Additionally, if computer certificate mapping is supported, I would like to know the exact constraints (e.g., EKU requirements, principal/SAN types, AD object linkage) regarding implicit mapping that ensure the certificate resolves correctly to a computer object in Active Directory. I may be missing something among the constraints, or I may not have found clear and authoritative analysis materials.

Answer 1

Hi LIL Tinder,

To clarify, the KERB_CERTIFICATE_S4U_LOGON structure within LsaLogonUser is primarily intended for user principals, not computer accounts. In practice, Windows security architecture does not support certificate-based S4U logon flows for computer identities in the same way it does for users. Computer accounts can authenticate using Kerberos or NTLM, but the certificate mapping logic is scoped to user principals.

That said, computer certificates can still be leveraged for device authentication scenarios, but the mapping constraints are strict. The certificate must contain the correct EKU (usually Client Authentication), and the Subject Alternative Name (SAN) must align with the computer object in Active Directory. Implicit mapping requires that the certificate’s identity information matches the AD computer account attributes exactly. Without that alignment, the certificate will not resolve correctly to the computer object.

If your goal is to achieve device-level assurance without user interaction, you may want to explore device-based conditional access policies in Entra ID or certificate-based authentication at the TLS layer, rather than relying on S4U logon for computer accounts. These approaches are more consistent with current Windows and Entra ID security architecture.

In short, certificate-based S4U logon is not supported for computer accounts, and while certificates can be mapped to devices, the constraints are strict and usually better handled through other mechanisms.

I hope this helps you move forward. If you find this answer helpful, please consider clicking Accept Answer so others can benefit too.

Jason.

Answer 2

Certificate-based S4U logon is supported in Windows via the KERB_CERTIFICATE_S4U_LOGON structure and the LsaLogonUser API, but the provided material only describes the mechanism and flags at the protocol/structure level. It does not distinguish behavior between user and computer accounts, nor does it document computer-specific constraints such as EKUs, SAN formats, or implicit mapping rules for resolving a certificate to a computer object in Active Directory.

From the available information:

• KERB_CERTIFICATE_S4U_LOGON is defined as the structure used to submit a certificate for S4U logon via LsaLogonUser. It includes:
  • MessageType (must be KerbCertificateS4ULogon).
  • Flags (including KERB_CERTIFICATE_S4U_LOGON_FLAG_CHECK_DUPLICATES, KERB_CERTIFICATE_S4U_LOGON_FLAG_CHECK_LOGONHOURS, KERB_CERTIFICATE_S4U_LOGON_FLAG_IF_NT_AUTH_POLICY_REQUIRED, KERB_CERTIFICATE_S4U_LOGON_FLAG_IDENTIFY).
  • UserPrincipalName and DomainName used by LsaLogonUser to locate the user and KDC when not NULL.
  • CertificateLength and Certificate containing the client certificate.
• The documentation explicitly states that when DomainName is NULL, LsaLogonUser attempts to authenticate against the domain to which the computer is joined, but it does not specify whether the target security principal must be a user or can be a computer account.
• The related PKU2U S4U structure (PKU2U_CERTIFICATE_S4U_LOGON) is similarly defined for certificate-based S4U logon, but again only in terms of structure fields and not principal type.
• KB5014754 and the smart card sign-in flow describe certificate-based Kerberos authentication and mapping behavior (including S4U) at a high level, but focus on user sign-in, certificate mapping, and troubleshooting after the CVE-2022-26931/26923 hardening changes. They do not provide explicit rules for computer-object mapping or EKU/SAN constraints for computer certificates.

The context does not provide:

• An explicit statement that KERB_CERTIFICATE_S4U_LOGON is supported for computer accounts, or that it is restricted to user accounts.
• Any normative description of implicit certificate-to-computer mapping rules (e.g., required EKUs, SAN types, or how subject/SAN values are matched to dNSHostName, servicePrincipalName, or sAMAccountName of a computer object).
• Any Zero Trust–specific guidance or authoritative constraints for using enterprise-issued computer certificates with S4U to obtain identification-level tokens for computer identities.

Because those details are not present in the supplied material, the exact support statement and the precise constraints for certificate-based S4U logon to computer accounts cannot be derived from this context.

---

References:

• KB5014754: Certificate-based authentication changes on Windows domain controllers
• Certificate Requirements and Enumeration
• KERB_CERTIFICATE_S4U_LOGON structure (ntsecapi.h)
• PKU2U_CERTIFICATE_S4U_LOGON structure (ntsecapi.h)
• Granting Logon as Service Right on the Host Computer