Authentication Mechanism Assurance

🔒 Secure Bits 💡
𝗪𝗮𝗻𝘁 𝘁𝗼 𝗲𝗻𝗳𝗼𝗿𝗰𝗲 𝗿𝗼𝗹𝗲-𝗯𝗮𝘀𝗲𝗱 𝗮𝗰𝗰𝗲𝘀𝘀 𝗯𝗮𝘀𝗲𝗱 𝗼𝗻 𝗹𝗼𝗴𝗼𝗻 𝗺𝗲𝘁𝗵𝗼𝗱—𝗻𝗮𝘁𝗶𝘃𝗲𝗹𝘆?

Use 𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗠𝗲𝗰𝗵𝗮𝗻𝗶𝘀𝗺 𝗔𝘀𝘀𝘂𝗿𝗮𝗻𝗰𝗲 (𝗔𝗠𝗔) to give users different access based on how they authenticate.
🪪 Log on with smart card → ✅ get extra group membership
🔑 Log on with password → ❌ no access to sensitive resources
That’s the power of AMA—built into Active Directory since 2008 R2.

𝗛𝗲𝗿𝗲’𝘀 𝗵𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀:
1️⃣ You create a custom Issuance Policy with a unique OID (e.g. 1.3.6.1.4.1.49955.5.1.1)
2️⃣ You link it to an empty universal group
3️⃣ You issue smart card certificates that embed this policy
4️⃣ When a user logs on via smart card, the group SID is added to the Kerberos TGT
5️⃣ Access to protected resources is now possible—only when logging in via certificate

And yes: they’re not a member of the group in AD—but their TGT says otherwise.
Magic? 𝗡𝗼. 𝗔𝗠𝗔.

🧪 Tested with YubiKey 5 NFC + smart card templates
👨‍💻 Admins use cert templates + issuance policy + certmgr.msc/YubiKey Manager
🎯 Resource access: SMB, SharePoint, MECM, etc.—only when certificate-authenticated
⚠️ Password logon = no group SID = no access
Tip: Don’t use Microsoft’s built-in assurance levels—create your own OID instead.

𝗛𝗮𝘃𝗲 𝘆𝗼𝘂 𝗱𝗲𝗽𝗹𝗼𝘆𝗲𝗱 𝗔𝗠𝗔 𝗶𝗻 𝗽𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻? Or planning passwordless access that adapts to auth type?👇

Let’s share best practices.

Author: Martin Handl – 𝗳𝘂𝗹𝗹 𝗮𝗿𝘁𝗶𝗰𝗹𝗲: https://iqunit.com/smartcard-logon-teil-2-ama/