Prevent smart card logon to the network
Installing Active Directory Certificate Services in the default configuration automatically configures the environment so that smart card logons are accepted by the domain controllers.
Therefore, if the use of smart card logons is not desired, it makes sense to disable the functionality in order not to jeopardize Active Directory in the event the certification authority is compromised.
See also article "Changes to Certificate Issuance and Certificate-Based Logon to Active Directory with the May 10, 2022 Patch for Windows Server (KB5014754) ".
Under what circumstances is the smart card logon functionality enabled?
See also article "What requirements must be met on the infrastructure side for smart card logons to be possible? ".
When installing an Active Directory integrated certification authority, its certification authority certificate is copied to the NTAuthCertificates object in the Active Directory forest. This step marks the certification authority as usable for certificate-based logons in the environment, which includes smart card logon.
If the publication of the default certificate templates is not prevented during the installation, the certification authority automatically provides the "domain controller" certificate template, which is then also automatically requested by the domain controllers.
Also, if, the publishing of the default certificate templates was prevented during the installation, but another one of the default domain controller certificate templates is published, this will lead to the same result. See also article "Domain controller certificate templates and smart card logon ".
Ways to disable the smart card logon functionality
Do you know TameMyCerts? TameMyCerts is an add-on for the Microsoft certification authority (Active Directory Certificate Services). It extends the function of the certification authority and enables the application of rule sets to realize the secure automation of certificate issuance. TameMyCerts is unique in the Microsoft ecosystem, has already proven itself in countless companies around the world and is available under a free license. It can be downloaded via GitHub and used free of charge. Professional maintenance is also offered.
The following options are available to disable the smart card logon functionality:
- Operate domain controller without certificates
- Distribute customized domain controller certificates
- Remove certificate authorities from NTAuthCertificates object
- Restrict certification authority certificates
Details: Operating domain controllers without certificates
It is of course possible to operate the domain controllers without certificates, i.e. not to offer them a certificate template for requesting certificates.
The disadvantage here, however, is that LDAP over SSL (LDAPS) connections cannot then be offered either. This is not practical in most cases.
Details: Distribute customized domain controller certificates
It is possible to issue certificates to domain controllers that allow them to accept LDAP over SSL (LDAPS) connections, but at the same time not to be able to process smart card logons.
For the configuration of such a certificate template, see the article "Configuring a Certificate Template for Domain Controllers ".
A domain controller will log the events 19 and 29 when a logon is made via smart card. This event can therefore be followed by an alert.
Details: Remove certificate authorities from NTAuthCertificates object
It is possible to remove the certification authority certificate from the NTAuthCertificates object of the Active Directory forest after installing the certification authority. See the article "Editing the NTAuthCertificates object in Active Directory ".
The disadvantage with this method, however, is that some functions depend on the presence of the certification authority certificate in NTAuthCertificates:
| Function | Description |
|---|---|
| Enroll on Behalf Of (EOBO) | The CA certificate of the certification authority that issues the certificates for the enrollment agents must be located in NTAuthCertificates. |
| Key Recovery / Private Key Archiving | The CA certificate of the certification authority that archives the keys must be located in NTAuthCertificates. |
| smart card logon | The CA certificate of the certification authority that issues the certificates of the domain controllers and the users logging on must be located in NTAuthCertificates. |
| Windows Hello for Business | Identical to smart card logon. If Windows Hello for Business is used without certificates, only the certification authority for domain controllers must be entered. |
| Network Policy Server (Network Policy Server, NPS) when certificate-based logons are processed (e.g. 802.1x over wireless or wired network, DirectAccess, Always ON VPN). | The CA certificate of the certification authority that issues the certificates of the users or computers logging on must be located in NTAuthCertificates. |
| EFS File Recovery Agents | The CA certificate of the certification authority that issues the certificates of the file recovery agents must be located in NTAuthCertificates. |
| IIS Client Certificate Mapping (against Active Directory) | The CA certificate of the certification authority that issues the certificates of the users logging on must be located in NTAuthCertificates. |
| Network Device Enrollment Service (Network Device Enrollment Service, NDES), Renewal mode only | Only affects renewal mode, i.e. signing a certificate request with an existing certificate. The CA certificate of the certification authority that issued the certificates of the certificates to be renewed must be located in NTAuthCertificates. |
Details: Restrict certification authority certificates
However, the disadvantage of this method is that domain controllers in the standard configuration do not check the restrictions on the certification authority certificate. Although it is possible to adjust the configuration of the domain controllers, a residual risk remains, depending on the restrictions defined on the certification authority certificate. For further details, see the article "Domain controllers do not check Extended Key Usage on smart card logon ".
Conclusion
It is possible to adjust the environment so that smart card logons are no longer possible. However, almost every method listed has disadvantages.
Probably the best option with the fewest drawbacks is to distribute customized domain controller certificates so that they cannot process smart card logons - unless this feature is used.
If the use of smart card logon or Windows Hello for Business is required, it makes sense to think about using OCSP in conjunction with the deterministic "Good". See article "Force domain controllers (or other participants) to use an Online Responder (OCSP) ".
Related links:
- Attack vector on the Active Directory directory service via the smart card logon mechanism
- What requirements must be met on the infrastructure side for smart card logons to be possible?
- Domain controller certificate templates and smart card logon
- Domain controllers do not check Extended Key Usage on smart card logon
- Configuring a Certificate Template for Domain Controllers
- Editing the NTAuthCertificates object in Active Directory