Multi-factor authentication is a standard today, especially for privileged accounts. While long established in the cloud, on-premises administrators face a much greater challenge. But even strong authentication does not solve every problem: What happens when a successfully authenticated administrator subsequently retains far-reaching permissions permanently?

Especially in Tier 0, securing the login alone is not enough. The assignment of administrative rights must also be part of the security concept. Why the consistent separation of privileged systems and accounts is so critical is explained in detail in our article Data Security Through Tiering: Protection at Every Level. In that article, we categorize Tier 0, Tier 1, and Tier 2 and show you why identity systems, domain controllers, and certification authorities in particular require special protection.

For MFA in the T0 area, we rely on SCAMA, short for Smart Card Authentication Mechanism Assurance. This approach combines certificate-based authentication with dynamic, role-based permission assignment.

The Actual Risk: Permanent Permissions

A stolen admin password is dangerous. It becomes even more critical when permanent privileged group memberships are linked to the affected account.

Traditional MFA initially protects the login process. However, the subsequent authorization often remains untouched: After successful authentication, the account possesses all permanently assigned permissions.

SCAMA therefore pursues a different approach:

It is not the account alone that determines admin rights, but the combination of account and successful certificate-based authentication.

The privileged account does not hold the corresponding role permanently. The required permissions are only generated upon logging in with a matching smart card certificate. This decouples administrative permissions from the password.

How Does SCAMA Work?

SCAMA is based on standard features of Active Directory Domain Services (AD DS) and Active Directory Certificate Services (AD CS). An issuance policy stored in the certificate is linked to a universal Active Directory group.

Simplified, the authentication process works as follows:

1. 1. 1. The administrator initially has no permanent SCAMA role membership.
      2. They authenticate using a matching smart card certificate.
      3. The certificate contains an ID for the required administrative role.
      4. This ID is assigned to a universal AD group.
      5. The dynamic group membership is included in the Kerberos ticket or its Privilege Attribute Certificate (PAC).
      6. The resulting permissions apply within the lifetime of this ticket.

The underlying mechanism is known as Authentication Mechanism Assurance (AMA). Through this, membership in a security group can be made dependent on a user provably authenticating with a strong authentication method, such as a smart card. A detailed technical breakdown is provided in the article Authentication Mechanism Assurance for Securing Administrative Accounts.

Authorization therefore depends not only on the identity of the account, but also on the authentication mechanism actually used.

SCAMA Combines JIT, JEA, and MFA

From a security perspective, SCAMA combines two key principles of modern administration.

Just-in-Time Administration

Privileged permissions are not assigned permanently. They are created in the context of certificate-based login and are valid only temporarily within the Kerberos ticket.

After the ticket expires, the permissions provided via SCAMA are no longer available. The ticket lifetime should be deliberately adapted to the company’s security and operational concept.

Just Enough Administration

Different administrative roles can be mapped via specific certificates. As a result, administrators do not receive blanket permissions for everything, but only the permissions they require for their respective tasks.

“Strong authentication and MFA are indispensable for Tier 0. But it gets really interesting where the method of authentication simultaneously determines whether and for how long administrative permissions are created. Precisely this connection between authentication and authorization makes SCAMA an effective building block for protecting privileged identities.” – Fabian Böhm, Managing Director and Security Architect at TEAL

More Than Traditional Smart Card MFA

In a traditional smart card login, the focus is usually on securing the login:

Smart Card and PIN → Stronger Authentication

SCAMA expands this principle:

Authentication Mechanism → Role Information → Temporary Authorization

The certificate thus not only verifies the administrator’s identity. Via the ID contained within it, it simultaneously provides the information regarding which administrative role may become active in the current context.

The corresponding universal AD groups intentionally remain empty. Their membership is generated exclusively dynamically via SCAMA. Permanent members would bypass this security mechanism.

SCAMA goes beyond simply securing the login process. It additionally connects certificate-based authentication with the dynamic assignment of a role.

The PKI is Part of the Tier-0 Security Concept

SCAMA is not an isolated configuration within Active Directory. Certificates, issuance policies, and unique Object Identifiers (OIDs) become central components of permission assignment.

For a resilient implementation, the following components in particular are required:

• • an Issuing CA that supports the required issuance policies
  • uniquely defined and centrally managed OIDs
  • universal AD groups for role mapping
  • smart cards or suitable hardware tokens
  • a controlled issuance process, ideally with a four-eyes principle
  • a clearly defined role and permission model

SCAMA Doesn’t Work Without Lifecycle Management

A technical implementation does not end with creating a certificate template. During ongoing operations, at least three core processes must be regulated:

• • Request: How is a SCAMA certificate requested, verified, and issued?
  • Renewal: How is a certificate controlledly renewed or replaced?
  • Revocation: How is it revoked upon role changes, loss, or security incidents?

In addition, processes should be defined for initial use, PIN reset, unblocking, and the replacement of defective or lost hardware tokens.

If these processes are missing, a solution quickly emerges that works technically but is operationally difficult to manage.

Typical Pitfalls During Implementation

SCAMA can only be effective if existing permission paths are consistently taken into account.

Particularly important are:

• • Permanent Group Memberships: Existing Tier 0 and built-in groups must be audited and cleaned up if necessary. Otherwise, the dynamic roles intended via SCAMA can be bypassed.
  • Break-Glass Accounts: Emergency accounts require a separate, strictly controlled concept and should not be casually integrated into the regular role model.
  • Unclear Roles: Certificates or SCAMA cannot fix an unorganized permission model. The required administrative roles must be clearly defined beforehand.
  • Underestimated PKI Dependencies: OID management, certificate profiles, revocation processes, and the securing of certification authorities are part of the overall design.
  • Missing Operational Processes: Issuance, renewal, and revocation must be considered and documented from the very beginning.

In addition, there is an important limitation: Authentication Mechanism Assurance does not automatically protect against attacks such as Pass-the-Hash or Pass-the-Ticket. Even with a smart card login, security-relevant artifacts such as Ticket Granting Tickets can still become the target of an attack. SCAMA is therefore one building block within a multi-layered security architecture, but not a replacement for system hardening, secure admin workstations, monitoring, and Attack Path Management.

Conclusion: Admin Rights Should Not Be a Permanent State

SCAMA turns smart card authentication into more than just an additional factor during login. The authentication mechanism used is directly linked to the assignment of privileged roles.

This allows administrative permissions to be provided:

• • role-based,
  • certificate-bound,
  • time-limited,
  • and within the Kerberos context.

Especially for Tier 0, this creates an effective combination of strong authentication, Just-in-Time Administration, and Just Enough Administration.

However, it is crucial not to view SCAMA purely as a PKI feature. The role model, existing group memberships, administrative workstations, and the complete certificate and smart card lifecycle must all be part of the same security architecture.

SCAMA is therefore a valuable component of a comprehensive Tier-0 concept. How we support you in the classification, separation, and protection of critical systems as well as highly privileged admin accounts can be found on our topic page: Data Security Through Microsoft Tiering

Because for particularly critical accounts, MFA should not stop at login!