Security - Page 6 - Uwe Gradenegger

Associate a universal security group with an Object Identifier (OID) in the Active Directory directory service (Authentication Mechanism Assurance).

Authentication Mechanism Assurance (AMA) provides the ability to tie membership in a security group to enrollment with a smart card certificate containing a specific Object Identifier (OID).

If the user does not log in with the smartcard certificate, but with user name and password, he is also not a member of the security group.

The following describes how to establish the connection between the certificate and the security group.

Configuring a Certificate Template for Authentication Mechanism Assurance (AMA)

Authentication Mechanism Assurance (AMA) provides the ability to tie membership in a security group to enrollment with a smart card certificate containing a specific Object Identifier (OID).

If the user does not log in with the smartcard certificate, but with user name and password, he is also not a member of the security group.

The following describes how to generate a certificate template for use with Authentication Mechanism Assurance.

Determine and export a Trusted Platform Module (TPM) Endorsement Certificate

If you want to use the Trusted Platform Module (TPM) key attestation, you have the option of attesting the TPM via the endorsement certificate (EkCert), among other things. The following describes how to obtain this information.

Determine the checksum (hash) of a Trusted Platform (TPM) Endorsement Key

If you want to use the Trusted Platform Module (TPM) key attestation, you have the option of attesting the TPM via the endorsement key (EkPub), among other things. The following describes how to obtain this information.

Configuring the Network Device Enrollment Service (NDES) to work with a Group Managed Service Account (gMSA).

For security reasons, it may make sense to operate NDES with a Group Managed Service Account (gMSA) instead of a normal domain account. This option offers the charming advantage that the password of the account is changed automatically, and thus this step does not have to be done manually, which is unfortunately forgotten far too often.

Configuring the Network Device Enrollment Service (NDES) to operate without a password.

There are situations in which you cannot operate NDES with changing passwords. This is usually the case when there is either no management solution for the devices to be managed, or when it cannot handle changing passwords. Some solutions cannot handle a password at all.

In this case, you can configure NDES not to generate or require a password.

Configuring the Network Device Enrollment Service (NDES) to work with a static password.

In this case, you can configure NDES to generate a static password that will not change afterwards.

Creating a virtual smart card in a Hyper-V guest system

For test environments, it is often helpful to be able to work with smartcards. Below is a brief guide on how to set up a virtual smartcard in a Hyper-V guest using a virtualized Trusted Platform Module (TPM).

Domain Controller Certificate Templates and Smartcard Logon

In order for domain controllers to process smart card logins, they need certificates that provide this function.

Editing the NTAuthCertificates object in Active Directory

In the default configuration, all certification authority certificates of Active Directory integrated certification authorities (Enterprise Certification Authority) are located in an object of type CertificationAuthority named NTAuthCertificates within the Configuration Partition of the Active Directory forest.

Attack vector on Active Directory directory service via smartcard logon mechanism

In simple terms, public key cryptography can be reduced to the assumption that the private part of each key pair is known only to its owner.

A certification authority is responsible for the correct identification of users, computers or resources. Its issued certificates are therefore granted a trust status because all participants assume that their private key is known only to it.

If an attacker succeeds in gaining knowledge of a certification authority's private key, or at least Perform signatures using the private key, the integrity of the certification authority is no longer guaranteed.

Basics: Restricting Extended Key Usage (EKU) in Certification Authority Certificates

A useful hardening measure for Certification Authorities is to restrict the Certification Authority certificates so that they are only used for the actually issued extended key usage (Extended Key Usage) becomes familiar.

In the event of a compromise of the certification authority, the damage is then (at least) limited to the defined extended key usages.

The Smart Card Logon Extended Key Usage, which is of interest for many attacks (in conjunction with the certification authority's membership in NTAuthCertificates) would then only be present in the certification authority certificate of the certification authority that actually issues such certificates.

What key lengths should be used for certificate authorities and certificates?

When planning a public key infrastructure, the question naturally arises as to which key lengths should be selected for certification authority and end certificates.

Using custom Registration Authority (RA) certificate templates for the Network Device Enrollment Service (NDES).

The Network Device Enrollment Service (NDES) uses two certificate templates for its internal function to make it act as a Registration Authority (RA). These are published during role configuration of the NDES service on the configured certificate authority and certificates are requested:

CEP Encryption
Exchange Enrollment Agent (Offline Request)

These certificate templates are standard templates from the Windows 2000 world (version 1 templates), i.e. they cannot be edited. In addition, the Exchange Enrollment Agent (Offline Request) template is marked as a user template, i.e. during NDES role configuration the certificate is requested in the context of the installing user and then imported into the machine store. At the latest when the certificates are to be renewed after two years, things get complicated here.

It is therefore a good idea to use your own certificate templates for NDES. These can be adapted in terms of their key length, for example. The use of hardware security modules (HSM) is also possible in this way. Even automatic renewal can be configured.

Domain controller does not check extended key usage on smart card login

Anyone who wants to use the smartcard logon function in their company would be well advised to ensure that their certification authority has the strongest possible security hardening. This includes some essential measures:

Removing all unnecessary certification authority certificates from the NTAuthCertificates object in Active Directory: Each certification authority located in this store is authorized to issue smartcard logon certificates in Active Directory for the complete forest.
Use qualified subordinationRestricting the certification authority certificates so that they are only trusted for the extended key usages actually issued. In the event of a compromise of the certification authority, the damage is then limited to these extended key usages. The "Smart Card Logon" Extended Key Usage would then only be present in the certification authority certificate of the certification authority that actually issues such certificates.

What is interesting about these thoughts, however, is that the domain controllers do not check the extended key usages at all when logging in via smartcard.