Using Authentication Mechanism Assurance (AMA) to secure the login of administrative accounts

Authentication Mechanism Assurance (AMA) is a feature designed to ensure that a user is a member of a security group only if they can be shown to have logged in using a strong authentication method (i.e., a smart card). If the user logs in via username and password instead, he or she will not have access to the requested resources.

Originally intended for access to file servers, however, AMA can also be used (with some restrictions) for administrative logon. Thus, for example, it would be conceivable for a user to be unprivileged when logging in with a username and password, and to have administrative rights when logging in with a certificate.

Restrictions

However, the approach is subject to some limitations that must be taken into account during implementation:

Since the AMA-managed groups must be mandatory Universal, some groups (such as "Domain Admins") cannot be secured via AMA (BUILTIN\Administrators works and is also used in this demo).
Fast Logon and Cached Logons should be disabled on admin machines to avoid interactions.
Changes to the PKI's certification authority certificates may be necessary (issuance policies).

Authentication Mechanism Assurance does not protect against identity theft such as pass-the-hash and pass-the-ticket. Even with a smartcard login, there are password hashes and ticket granting tickets that can be stolen with the relevant tools.

Requirements

In order for the AMA to be used, the infrastructure must meet some requirements:

An Active Directory integrated issuing certificate authority must be present on the network.
The Certification Authority certificate of the issuing Certification Authority must be stored in the NTAuthCertificates object of the overall structurewhich corresponds to the standard case.
Either the All Issuance Policy or an Issuance Policy explicitly defined for Authentication Mechanism Assurance must be included in the issuing certification authority's certificate.
A certificate template for smartcard enrollments must be configured and enabled for issuance on the certificate authority.
The domain controllers must have domain controller certificates, which can process the smartcard login.
One must have a physical smart card, or Set up a virtual smart card.

Procedure

The Authentication Mechanism Assurance setup consists of the following steps:

Setting up the group policies for the administrative computers
Preparing the Certification Authorities for Authentication Mechanism Assurance
Preparing the domain controllers for smart card logon
Configuring the Certificate Template for Authentication Mechanism Assurance Login
Creating the group managed with the Authentication Mechanism Assurance
Connecting the Security Group to the Authentication Mechanism Assurance Issue Policy
Requesting the user certificates
Log in with the user certificate

Setting up the group policies for the administrative computers

For Authentication Mechanism Assurance to be deployed without errors, a group policy must be applied to the administrative computers that sets the following settings:

Disabling cached credentials
Waiting for the network to log on (Fast Logon)

Authentication Mechanism Assurance is inherently incompatible with cached logins, since there is no way to distinguish on the client whether the user has logged in with a password or a smart card. Thus, undesired interactions could occur, for example, that the membership in the protected group would be applied even if the user logged in with a password.

In the group policy, navigate to "Computer Configuration" - "Policies" - "Windows Settings" - "Security Settings" - "Local Policies" - "Security Options". The setting "Interactive Logon: Number of previous logins to cache (in case domain controller is not available)" is set to "0" (i.e. no caching).

Then navigate to "Computer Configuration" - "Policies" - "Administrative Templates" - "System" - "Logon" and activate the setting "Always wait for the network at computer startup and logon".

Preparing the Certification Authorities for Authentication Mechanism Assurance

Authentication Mechanism Assurance uses issuance policies. For this reason, the certificate authorities issuing the user certificates must include in their certificate authority certificate either the wildcard issuance policy (AnyPolicy, not recommended) or explicitly the object identifier of the desired issuance policy. How this is achieved is described in the following articles:

Furthermore, the certificate authority certificates must be stored in the NTAuthCertificates object of the Active Directory forest. How this is achieved is described in the article "Editing the NTAuthCertificates object in Active Directory" described.

Preparing the domain controllers for smart card logon

Since Authentication Mechanism Assurance is based on Smartcard Logon, the same requirements for domain controller certificates apply here. How these can be configured is described in the article "Domain Controller Certificate Templates and Smartcard Logon“ described.

Configuring the Certificate Template for Authentication Mechanism Assurance Login

For the certificates of the logging in users, a certificate template must be created that contains the desired issuance policy. How this is configured is described in the article "Configuring a Certificate Template for Authentication Mechanism Assurance (AMA)" described

Creating the group managed with the Authentication Mechanism Assurance

Authentication Mechanism Assurance works only with universal security groups. This must be thought of when creating the security group, or the existing group must be converted to a universal group.

Of course, because the security group must be universal, there are some restrictions on its use. For example, it could not be a member of the Domain Administrators group. However, group membership of the PREFINED\Administrators group at the domain level would be possible, for example.

Connecting the Security Group to the Authentication Mechanism Assurance Issue Policy

In order for the group membership to be tied to the user certificate login, the security group must be linked to the issuance policy. How this is achieved is described in the article "Associate a universal security group with an Object Identifier (OID) in the Active Directory directory service (Authentication Mechanism Assurance)." described.

Requesting the user certificates

The user certificates can then be requested. The defined issuance policy is displayed in the certificate.

Log in with the user certificate

Now the users can log in with the certificate.

The user is now a member of the security group managed by Authentication Mechanism Assurance.

For comparison the group memberships with a login with username and password. The user is not a member of the security group:

Use Authentication Mechanism Assurance (AMA) to secure administrative account logins.