SmartCard-Logon with YubiKey 5 NFC + AMA
Der Smart Card Logon ist ja eine ganz nette Sache: kein Kennwort mehr merken (geschweige denn wechseln), nur noch eine PIN (ja, der “Code”) merken und die Smart Card (ja, den “Stecker”) dabei haben und vor der Anmeldung einstecken.
Die Bequemlichkeit für den Anwender steigt und die Sicherheit ebenso; ein wahrer Synergieeffekt!
Richtig rund wird die Smart Card Anmeldung jedoch erst mit der AMA-Technologie.
Authentication Mechanism Assurance (AMA)
Authentication Mechanism Assurance (kurz: AMA) wurde von Microsoft im Jahr 2010 mit der PKI von Server 2008 R2 vorgestellt.
Bei Microsoft heißt es dort (siehe erster Link):
…] AMA adds an administrator-designated, universal group membership to a user’s access token when the user’s credentials are authenticated during logon by using a certificate-based logon method. This makes it possible for network resource administrators to control the access to resources, such as files, folders, and printers. This access is based on whether the user logs on by using a certificate-based logon method and the type of certificate that’s used to log on. […
Also brauchen wir:
- eine universale Gruppe, welche leer sein muss (globale oder Domänen lokale Gruppen sind ungeeignet)
- eine zertifikatsbasierte Anmeldung (Smart Card oder, wahlweise, ein Computer mit Computerzertifikat)
- eine Portion AMA
Issuance Policy
AMA fußt maßgeblich auf einer Issuance Policy, welche durch die ausstellende Zertifizierungsstelle (Certification Authority – CA) bereit gestellt wird.
Issuance Policies werden, wie auch andere Objekte*, in der Configuration gespeichert: CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=<domain>,DC=<tld>
*es sind alles Objekte der Klasse msPKI-Enterprise-OID, die sich jedoch im Attribut “flags” unterscheiden. msPKI-Enterprise-OID mit dem Attribut “flags” = 2** sind issuance policies
**mit “flags” = 1 ist es eine Zertifikatsvorlage.
Diese notwendige Issuance Policy kann eine CA nur dann ausstellen, wenn das Zertifikat über “All issuance policies” verfügt. Fehlt das “All issuance policies”, dann bitte per INF-Datei und Schlüsselerneuerung in der jeweiligen CA folgendes nachreichen:
[AllIssuancePolicy]
OID = 2.5.29.32.0
$DN = "CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=CLOUD-HYBRID,DC=DE"
Get-ADObject -Filter { objectclass -eq "msPKI-Enterprise-OID"} -Properties displayName,flags -SearchBase $DN | Select-Object -Property displayName,flags | Sort-Object -Property flags | Out-GridView
Eine Issuance Policy (“flags” = 2) ermöglicht eine Verbindung auf der einen Seite zu einer Gruppe. Das dazu verwendete verknüpfte Attributpaar (linked attributes) ist:
- ms-DS-OIDToGroup-Link (LinkID = 2164) und
- ms-DS-OIDToGroup-Link-BL (LinkID = 2165)
“Linked attributes” sind den meisten durch Gruppen bekannt (Is-Member-of-DL und members).
“Linked attribute” bedeutet: wenn der eine Attributwert geändert wird, wird automatisch beim verknüpften Attribut der Wert komplementär geändert.
Gruppe und Issuance Policy
Eine leere universale Gruppe kann somit eine Verbindung mit einer Issuance Policy eingehen (oder andersherum – die Attribute sind verknüpft). Es kann also eine Verbindung zwischen einer Issuance Policy und einer Gruppe hergestellt werden. Hier gilt es zu beachten, dass Sicherheitsgruppen mit ihrer ObjectSID bei Active Directory zur Autorisierung herangezogen werden.
Daraus folgt: eine Issuance Policy kann mich zu einer ObjectSID einer leeren universalen Gruppe führen.
Issuance Policy und Zertifikatsvorlage
Eine Issuance Policy wiederum kann, sofern die CA issuance policies unterstützt, zu einem Zertifikat zugeordnet werden. Zertifikate, wie zum Beispiel Smart Card User oder Computer können zur Anmeldung herangezogen werden.
Daraus folgt: eine Zertifikatsvorlage mit dem Zweck der Anmeldung kann durch eine Issuance Policy ergänzt werden.
Zertifikatsvorlage + Issuance Policy + Gruppe
Schlussendlich führt das zu folgender Struktur:
- Eine Zertifikatsvorlage mit dem Zweck der Anmeldung (zum Beispiel Smart Card Users) wird mit einer Issuance Policy in Verbindung gesetzt
- Die Issuance Policy wird mit einer leeren universalen Gruppen konnotiert.
- Die leere universale Gruppe verfügt über eine ObjectSID
Die Konsequenz: melde ich mich per Smart Card an und das Zertifikat verfügt über eine Issuance Policy, welche wiederum mit einer Gruppe konnotiert ist, werde ich Mitglied dieser Gruppe, ohne darin Mitglied zu sein!
Klingt komisch, ist aber so.
Technisch passiert hier was?
Was passiert hier technisch? Der Domain Controller, welcher meine Smart Card Anmeldung validiert, stellt bei der Validierung fest, dass das Zertifikat eine Issuance Policy aufweist. Diese Issuance Policy führt den Domain Controller zu einer leeren universellen Gruppe, welche wiederum eine ObjectSID hat.
Daraus erstellt der Domain Controller ein Kerberos Ticket Granting Ticket welches im PAC-Feld die ObjectSID der leeren Gruppe enthält, jedoch nur, wenn ich mich mit der Smart Card angemeldet habe.
Eigene Issuance Policy – Object Identifier: OID
Microsoft bietet drei vordefinierte Issuance Policies:
- Low Assurance
- Medium Assurance
- High Assurance
Diese drei Issuance Policies würde ich nicht verwenden. Es ist schlauer über eine eigene OID sich eigene Issuance Policies zu bauen.
OID?
Ein Object Identifier – OID kann man sich bei der IANA über das “PEN Application Form” holen. PEN steht hier für Private Enterprise Number.
$DN = "CN=OID,CN=Public Key Services,CN=Services,CN=Configuration,DC=CLOUD-HYBRID,DC=DE"
Get-ADObject -Filter { objectclass -eq "msPKI-Enterprise-OID" -and flags -eq 2 } -Properties displayName,flags -SearchBase $DN | Select-Object -Property displayName,flags | Sort-Object -Property flags | Out-GridView
Wieso eine OID bzw. eine PEN?
Eine Issuance Policie, genaso wie eine Zertifikatsvorlage, werden durch eine OID eindeutig gekennzeichnet. Ohne eindeutige OID keine Issuance Policie (und keinen Zertifikatsvorlage).
Die eigene OID / PEN ist nur eine fortlaufende Nummer in dem OID-Namespace: 1.3.6.1.4.1.
Microsoft hat beispielsweise die fortlaufende Nummer 311 aus diesem Namespace bekommen.
Meine OID, vor Jahren beantragt, ist die 49955 (1.3.6.1.4.1.49955).
Diese OID kann ich mir jetzt nach Lust und Laune für interne Zwecke zurecht legen.
- 1.3.6.1.4.1 = IANA PEN
- 49955 = ich
- 5 = PKI
- 1 = issuance policies
- 1 = erste issuance policy
1.3.6.1.4.1.49955.5.1.1 = erste issuance policy mit vollständiger OID
Eigene Issuance Policy erstellen
Eine eigene Issuance Policy zu erstellen ist nicht schwer, nur etwas versteckt, sofern man mit der grafischen Oberfläche arbeiten möchte.
- Eine beliebige Zertifikatsvorlage mit der Schemaversion 2 oder höher editieren.
- Im Reiter “Extensions” “Issuance Policies” mit “Edit” aufrufen.
- Im Dialog “Edit Issuance Policies Extensions” auf “Add” klicken und dann auf “New”
- Dort einen bezeichnenden Namen und die eigene OID hinterlegen und mit “OK” schließen
- alle älteren offenen Dialoge der Vorlagenverwaltung mit “Cancel” schließen.
Die Issuance Policy wird im Schritt vier in der Configuration hinterlegt.
Eigenes Smart Card Logon Template mit Issuance Policy
Wie herum man jetzt anfängt die drei Pferde (leere universale Gruppe, Issuance Policy und Zertifikatsvorlage) vor den Karren zu spannen, spielt keine Rolle. Solange ich die Triga auf den Weg bekomme, wurde das Ziel erreicht.
Die einzelnen Schritte können der Bildergallerie entnommen werden.
Neue, leere universale Gruppe mit Issance Policy konnotieren
Das dritte Pferd kommt jetzt vor den Wagen: es wird eine neue, leere universelle Gruppe angelegt und mit der Issuance Policy verbunden.
Das Verbinden findet über den LDAP-Editor adsiedit.msc statt. Dort wird in der Configuration die Issuance Policy mit dem Distinguished Name der neuen, leeren universellen Gruppen über das Attribut ms-DS-OIDToGroup-Link verbunden.
Enrollment Agent – Beantragen der Smart Card Logon-Zertifikates mit Issuance Policy
Der Enrollment Agent muss jetzt für den entsprechenden User (hier: Helga Blitz-Birne / CH\h.blitz-birne) das richtige Smart Card Logon-Zertifikat beantragen und auf den YubiKey schreiben.
Die Ressource…
…kann jetzt fast* alles sein, welches auf Basis von Kerberos V5 autorisiert.
- Zugriffe File- und Print-Services
- Zugriffe auf Active Directory
- Zugriffe auf SharePoint
- Zugriffe auf MECM (wenn der noch so heißt)
- Zugriffe auf SCOM (wenn der noch so heißt)
- und Zugriff auf viele andere Produkte
*Produkte welche ein eigenes RBAC (role based access control) verwenden kommen nicht immer mit AMA klar; Exchange On-Premises beispielsweise. Aber das Thema Exchange On-Premises dürfte sich im Oktober 2025 ohnehin von selbst lösen.
Hier in meinem kleinen Beispiel gibt es einfach einen File-Server dessen Freigabe nur von Mitgliedern der Gruppe AMA_SuperSecureDataAccess geöffnet werden darf.
Anmeldung mit Smart Card – Zugriff möglich
Meldet sich nun Helga Blitz-Birne (CH\h.blitz-birne) mit der Smart Card an, wird in ihr Ticket Granting Ticket die ObjectSID der leeren universellen AMA-Gruppe in das PAC-Feld hinzugefügt. Für die Ressource sieht das so aus, alsob Helga Mitglied der Gruppe ist.
Anmeldung ohne Smart Card – Zugriff nicht möglich!
Meldet sich Helga Blitz-Birne (CH\h.blitz-birne) mit Benutzername und Kennwort an, wird der Domain Controller in ihr Ticket Granting Ticket nicht die ObjectSID der leeren universalen Gruppe hinzufügen und der Zugriff scheitert mangels Berechtigung.
Das Wort zum Sonntag
AMA ist eine elegante Methode den Zugriff auf Ressourcen an die Art der Anmeldung zu binden. Der gleiche User kann dadurch verschiedene Rollenmodelle wahrnehmen, in dem er unterschiedliche Anmeldearten nutzt.
AMA bietet zudem den Vorteil, dass es im Falle einer Kompromittierung weiterhin Schutz bietet. Würde ein solcher User mit seinen Credentials aus dem LSA-Cache gedumpt werden, erhält der Angreifer nichts wertvolles. Ohne den physikalischen zweiten Faktor, die Smart Card, kann ich die privilegierte Rolle nicht einnehmen.
Richtig spanned wird AMA aber erst im Szenario mit einem Bastion Forest – das aber im Teil 3.
So, jetzt aber den Browser-Tab schließen, den Computer herunterfahren und nach draußen gehen.
Dieses war der zweite Streich, doch der letzte folgt sogleich.