Damit eine sichere Single-Sign-on-basierte (SSO) Anmeldung zu Anwendungen, Office 365, Azure und angebundenen Systemen funktioniert, will Azure AD (AAD) Benutzer sicher authentifizieren. Zunehmend geschieht das mit Verfahren, die sich von herkömmlichen Passworten absetzen und in sich bereits mehrstufige Authentifizierung bieten: FIDO2-Sicherheitsschlüssel, Hello for Business auf Windows oder "Phone Sign-in" mit der Authenticator-App für Smartphones. Ein bereits lange im Einsatz befindliches Anmeldeverfahren hat Microsoft jedoch für Azure AD bis vor kurzem nicht unterstützt, jetzt aber im Public Review: Smartcards und die zertifikatbasierte Authentifizierung.

Gerade Firmen, die auf Smartcards setzen, tun sich damit schwer: Nur über Workarounds und den Einsatz eines lokalen Identitätsanbieters (Identity Provider, IdP) wie den Active Directory Federation Services (ADFS) gelingt die Nutzung auch mit der Microsoft-Cloud – einer der letzten Anwendungsfälle, die einige IT-Verantwortliche am Auszug aus den ADFS hindert.

Nicht nur Smartcards und Zertifikate für Endbenutzer sind hierbei ein interessanter Anwendungsfall – gerade für Admin-Konten, die oft bereits Smartcards für besonders zu schützende Teile der Infrastruktur besitzen, ist die Weiterverwendung der Karten deutlich angenehmer als noch ein weiteres Anmeldeverfahren mit FIDO2.

Die zertifikatbasierte Authentifizierung (CBA) unterstützt all das. Nun werden Zertifikate für die "Client Authentication" sowohl in durch das Betriebssystem verwaltete als auch durch Smartcard geschützte Konten im Azure AD als Anmeldeoption unterstützt; Voraussetzung dafür ist, dass der Browser an das Zertifikat kommt. Azure AD überprüft dabei die öffentlichen Teile des Zertifikats, findet heraus, ob keine Revokation stattgefunden hat, und lässt den Benutzer hinein. Das Zertifikat selbst kann dabei von einer öffentlichen, vertrauten Stelle oder von der eigenen PKI stammen.

In jedem Fall muss das AAD der Zertifikatskette vertrauen können. Bei der Einrichtung dürfen Sie also nicht nur die öffentlichen Teile der ausstellenden Zertifikatsstelle bekannt machen, sondern müssen alle weiteren Ebenen bis hin zur Root-CA hinterlegen. Nur so löst das Azure AD die Zertifikatskette dann auf. Auch vom Aussteller zurückgezogene Zertifikate sind ein Thema. Wenn Sie Ihre Certificate Revocation List (CRL) veröffentlichen, werden Anmeldungen dagegen geprüft. Damit weisen Sie zurückgezogene Zertifikate, etwa beim Austritt eines Mitarbeiters, ab. Das AAD behält die CRL in einem Cache und erneuert sie in regelmäßigen Abständen, um auf dem Laufenden zu bleiben.

Entscheiden sich Benutzer für die Anmeldung mit dem Zertifikat, wählen sie nach Eingabe des Benutzernamens in der AAD-Anmeldemaske "Sign in with a certificate" aus. Die Option ist aktiviert, wenn alle Einstellungen vom Administrator getätigt wurden und die Domäne oder der Benutzer selbst für Cloudanmeldung konfiguriert sind. Unternehmen mit Password Hash Sync (PHS) oder Passthrough Authentication (PTA) im AAD können sofort starten. Unternehmen mit föderierter Anmeldung, etwa durch ADFS oder einen anderen Identity Provider, können CBA nicht nutzen – Azure AD schickt den Benutzer dann zum IdP für die Anmeldung. Für den sanften Umstieg von föderierten Anmeldungen oder für Testzwecke schalten Sie Gruppen von Benutzern via "Staged Migration" frei. Dabei erlauben Sie übergangsweise Mitarbeitern die Anmeldung direkt an der Cloud [1].

Das AAD verweist den Benutzer dann per Browser-Redirect auf den Zertifikatsendpunkt und weist den Browser an, die Zertifikatauswahl anzuzeigen. Nach der Auswahl versucht das AAD zunächst zu prüfen, ob das Zertifikat zu einer der vertrauten Ketten passt. Ist das der Fall, wird es auf Gültigkeit geprüft und ob es zurückgezogen wurde. Aus den Zertifikatsfeldern "SAN PrincipalName" oder "SAN RFC822Name" wird die Benutzeridentität extrahiert und mit bestehenden Benutzerkonten verglichen. Dabei schaut das AAD auf den "userPrincipalName" und den "onPremisesUserPrincipalName". Die Vergleichsreihenfolge ist durch die "username binding policy" als Teil der Konfiguration festgelegt.

Die Konfiguration startet mit dem Bekanntmachen der gesamten Zertifikatskette. In unserem Beispiel stellt eine Issuing Authority die Benutzerzertifikate aus, die wiederum durch eine Root-CA autorisiert wurde. Für CBA machen Sie beide Ebenen im AAD bekannt. Die Konfiguration ist ein Vierzeiler in der PowerShell, nachdem Sie das Azure-AD-PowerShell-Modul heruntergeladen und installiert haben:

Für sowohl die Root-CA als auch jede Intermediate- und Issuing-CA benötigen Sie das "CER"-File, das die Stelle ohne Zertifikatsgeheimnisse umschreibt. Zudem sollten Sie die URL für die CRL vorhalten. Die Konfiguration ist dann relativ einfach. Sie erstellen ein neues CA-Objekt in der PowerShell, definieren den Autoritätstypen, "0" für Root, "1" für Intermediate oder Issuing CA, und geben die CER-Datei sowie die Revokations-URL an. Abschließend lassen Sie das AAD die Einstellungen übernehmen:

Die Schritte sind für die Issuing-CA nahezu identisch: Sie tragen für den Authoritätstypen lediglich "1" ein und – falls die CRL anders zu erreichen ist – die angepasste URL. Alle Einstellungen können Sie später noch mit den jeweiligen Cmd­lets anpassen. Die abschließende Prüfung leiten Sie mit Get-AzureADTrustedCertificateAuthority ein.

Für die Konfiguration der CRL, die Microsoft in regelmäßigen Abständen herunterlädt und in einem tenantspezifischen Cache für schnelle Überprüfungen bereithält, gibt es Beschränkungen. Die CRL wird nur heruntergeladen, wenn sie nicht größer als 20 MByte ist und der Download durch das AAD nicht mehr als 10 Sekunden dauert. Sie sollten also möglichst die Pflege der CRL im Auge behalten und bei der Veröffentlichung darauf achten, dass die Erreichbarkeit gewährleistet ist.

Die CBA selbst schalten Sie im Azure-Portal unter "Azure Active Directory / Security / Authentication methods" ein. Unter den Methoden finden Sie "Certificate-based authentication (Preview)", dessen Konfiguration in zwei Reitern aufgeteilt ist: "Basics" und "Configure". In "Basics" schalten Sie das Credential generell zur Nutzung ein und wählen aus, ob alle Mitarbeiter oder nur ausgewählte Kollegen Zertifikate für die Anmeldung präsentieren dürfen. In "Configure" geht es dann weiter mit der Detailkonfiguration.

Das Azure AD inspiziert das präsentierte Zertifikat und versucht, die dort gefundenen Benutzernamen einem im Verzeichnisdienst hinterlegten User zuzuordnen. Für das Azure-AD-Mapping werden zwei AAD-Attribute hinzugezogen: "userPrincipalName" (UPN) und "onPremisesUserPrincipalName". Zweiterer ist für Szenarien interessant, in denen sich der UPN aus dem Windows-AD von dem im Azure AD unterscheidet. Die Namen im Zertifikat befinden sich im "Subject Alternate Name"-(SAN)-Feld des Certs, in das je nach Zertifikatstemplate unterschiedliche Namensindikatoren eingefügt werden können.

Im SAN sollten Sie entweder den userPrincipalName oder den RFC822Name mit einem UPN ausgestattet haben, den Azure AD dann gegen den UPN oder den On-Premises-UPN prüfen kann. Das Mapping steuern Sie in "Certificate-based authentication (CBA)", das Sie in den "Authentication Methods" unter Security im AAD-Portal finden. Im Tab "Configure" sehen Sie in der Sektion "Username binding" die Liste der Attribute, die im SAN-Feld durchsucht werden. Das Binding wird anhand einer priorisierten Liste bestimmt: Das erste Binding, das zutrifft, wird benutzt. Die Reihenfolge der Felder können Sie beeinflussen, indem Sie die drei Punkte anklicken und mit "Move down" oder "Move up" die Reihenfolge ändern. Für das Mapping wird die Liste von oben nach unten abgearbeitet. Im Beispiel, das Sie in Bild 2 sehen, wäre dies das Mapping von PrincipalName im SAN auf "onPremisesUserPrincipalName" im Azure AD.

Das AAD-Attribut "onPremisesUserPrincipalName" ist nicht im AAD-Portal ersichtlich und gehört auch in Microsoft Graph nicht zu den Standardattributen bei der Kontenabfrage. Wenn Sie das Feld überprüfen wollen, etwa ob ein Wert überhaupt korrekt aus Windows-AD synchronisiert wird, müssen Sie Microsoft Graph explizit danach fragen:

Nutzen Sie eine Windows-basierte PKI, können Sie die Zertifikatsvorlage für "User" verwenden. Diese nutzt den userPrincipalName als SAN und ist damit bei manuellem oder automatisiertem Enrollment für Benutzer durch GPO kompatibel mit der CBA.

Das Azure AD unterstützt das Einbetten mehrerer Zertifikatsketten, die unabhängig voneinander existieren und konfiguriert werden. Möglich sind auch mehrere ausstellende Autoritäten, die sich die Kette teilen und gegebenenfalls unter derselben Root zusammenlaufen. So betreiben Sie unterschiedliche Zertifikatsstellen, um mehrere Anwendungsfälle abzudecken – beispielsweise eine Zertifizierungsstelle für Benutzer und Externe, eine weitere für administrative Konten.

Das Anlegen der Ketten ist einfach: Nach der Konfiguration in der PowerShell erkennt das AAD die verschiedenen Ketten und bildet sie im Admin-Portal ab. Je Issuing-CA definieren Sie im AAD auch, ob den Zertifikaten für die Multifaktor-Authentifizierung (MFA) vertraut werden soll. Das AAD händigt dem Benutzer dann nach erfolgreicher Anmeldung ein Refresh-Token für den Zugriff auf Anwendungen aus, das die Information "hat MFA erfüllt" beinhaltet. Möchte der Benutzer dann auf eine Applikation zugreifen, die mit Conditional Access geschützt ist und MFA erfordert, sind alle Anforderungen automatisch erfüllt. Anders wäre das, wenn die Zertifikate einer Issuing-CA nur für eine "Einfachauthentifizierung" markiert sind. Dann wird der Benutzer zwar angemeldet, erhält ein Refresh-Token und kann per SSO auf Anwendungen zugreifen. Fordert Conditional Access jedoch eine MFA, wird der Mitarbeiter ausgebremst und muss zunächst die MFA erfüllen – etwa durch eine Authenticator-App oder die Beantwortung eines Telefonanrufs.

Mit der Konfiguration können Sie dann in Teilen auch Vertrauensstufen für die CA-Ketten abbilden. So trennen Sie Ketten von Partnern und internen Mitarbeitern, können interne Kollegen untereinander trennen oder Mitarbeiterzertifikate von Admin-Zertifikaten unterscheiden, falls gewünscht. Natürlich ist das Vertrauen in die jeweiligen Zertifikate abhängig vom Ausstellverfahren und der Identitätsüberprüfung des Endbenutzers, die damit einhergeht, sowie des Schutzes des Zertifikats, wenn es ausgestellt wurde.

Stellen Sie eine Smartcard aus, gibt Ihnen Ihr Unternehmensprozess vor, wie die Identität des Benutzers zu überprüfen ist, bevor Sie die Karte aushändigen: Mittels Ausweis, Foto oder anderer offizieller Dokumente, die physisch von einem Mitarbeiter eingereicht und vom Werksschutz oder der Personalabteilung überprüft werden. Anschließend sind die privaten Schlüssel auf der Karte mit einer PIN gespeichert, was MFA bedeutet.

Andere Zertifikate sind dabei weniger rigoros geschützt, die Sie im Azure AD deshalb als "Einfaktor-Authentifizierung" zur Abkehr von Passwörtern [2], aber nicht als MFA nutzen sollten. Dies ist etwa dann der Fall, wenn Benutzern durch die Geräteverwaltung oder eine Selbstregistrierung ein Benutzerzertifikat auf das Gerät gespielt wird. Mitarbeiter verwenden die Zertifikate dann zwar für Dienste und Anwendungen als SSO-Erleichterung, müssen aber keine PIN zur Nutzung des Zertifikats angeben. Das Zertifikat selbst ist in diesem Szenario dann über das Betriebssystem geschützt und nach der Benutzeranmeldung verfügbar.

Möchten Sie ein Regelwerk konfigurieren, definieren Sie dies im "Configure"-Tab der Anmeldemethode. Neben dem Standard-Binding für die Authentifizierung, der "Single-factor authentication" oder der "Multi-factor authentication", fügen Sie mit "Add rule" Regeln für die Zuweisung von Einzelfaktor- oder Multifaktor-Authentifizierung hinzu. Sie unterscheiden Zertifikatsaussteller dabei anhand des Issuers oder anhand von Policy-OIDs, die das Azure AD dann im Zertifikat findet und auswertet. Bei der Selektion von "Certificate issuer" wählen Sie aus dem Dropdown-Menü eine der per PowerShell hinzugefügten CAs aus. Bei "Policy OID" tippen Sie die OID ein, nach der das AAD suchen soll.

Für browserbasierte Anmeldungen mit CBA hat Microsoft die AAD-Logon-Seite angepasst. Alle Benutzer, die sich mit CBA anmelden dürfen, erhalten zum Zeitpunkt der Authentifizierung einen zusätzlichen Link auf der Anmeldeseite: "Sign in with a certificate". Die Anmeldemaske fragt bei einer neuen Session immer zunächst nach dem Benutzernamen, E-Mail-Adresse oder UPN. Erst nach der Eingabe des UPNs validiert Microsoft, ob ein Zertifikatslogon erlaubt ist oder nicht.

Sind CAs konfiguriert und der Benutzer ist für CBA freigeschaltet, erscheint der entsprechende Link dafür auf der Anmeldemaske, die alternativ die Passworteingabe empfängt. Mit dem Klick wird der Browser anwiesen, den "Certpicker" zu öffnen, mit dem der Benutzer das richtige Zertifikat auswählen kann. Im Moment schränkt das AAD den Browser nicht dahingehend ein, die Liste der Zertifikate auf bestimmte Domänen zu begrenzen, weshalb alle Zertifikate des Benutzers zur Auswahl stehen. Nach der Selektion erfolgt die Anmeldung und bei Erfolg die Weiterleitung zur eigentlichen Ressource, zu der der Benutzer wollte.

Im Verborgenen laufen im Azure AD mehrere Prüfungen der Vertrauenskette der CA sowie der CRL und anschließend des Username-Bindings. Sind diese Prüfungen erfolgreich abgeschlossen, wird dem Benutzer ein Session-Token sowie ein Token für die Zielanwendung ausgehändigt. Das Session-Token enthält auch die Information, ob das Zertifikat für die Einzelfaktor- oder Mehrfaktorauthentifizierung gilt.

Das Zurückziehen von Zertifikaten kann mehrere Gründe haben: Entweder ist das Zertifikat des Benutzers nicht mehr vertrauenswürdig, weil die Smartcard oder der Computer gestohlen wurde, die es geschützt hat, oder der Benutzer arbeitet nicht mehr länger im Unternehmen und soll sich überhaupt nicht mehr anmelden können.

Der Worst Case wäre auch denkbar: Die Zertifikatskette ist nicht mehr vertrauenswürdig, und Sie müssen sie aus dem Azure AD entfernen. Für Fälle, in denen das Zertifikat nicht mehr vertrauenswürdig ist, verfahren Sie wie mit allen Revocations und listen es in Ihrer CRL auf – das Azure AD wird die CRL bei der nächsten Anmeldung auslesen, das Zertifikat als ungültig erkennen und

Logins damit nicht mehr erlauben. Bestehende SSO-Sessions bleiben allerdings bestehen.

Sollen die Refresh-Tokens von Mitarbeitern aus Sicherheitsgründen invalidiert werden, damit eine Neuanmeldung mit einem anderen Credential notwendig ist, erledigen Sie das manuell per PowerShell mit dem Cmdlet

oder im Azure-AD-Portal unter "Users / <Benutzeraccount>" mit dem Button "Revoke Sessions". Sie müssen dafür kein Global Admin sein – die "Authentication Administrator"-Rolle und, für privilegierte Mitarbeiter, die "Privileged Authentication Administrator"-Rolle erlauben diesen Vorgang. Verlassen Mitarbeiter das Unternehmen, folgen Sie einem ähnlichen Prozess: Sie würden das Benutzerkonto, falls Sie ein hybrides Setup nutzen, im Windows-AD sperren, die Zertifikate zurückziehen, damit sie auf der CRL landen, und im Azure AD Sign-ins für das Konto sperren und alle Sessions und Refresh-Token löschen.

Ist Ihre gesamte PKI nicht mehr vertrauenswürdig, müssen Sie jedoch andere Maßnahmen ergreifen: Neben der CRL, die Sie dann von einem anderen vertrauenswürdigen Ort veröffentlichen müssen, sollten Sie zumindest im Azure AD die Kette unterbrechen und entfernen, damit das Verzeichnis keine Zertifikate mehr annimmt. In der PowerShell geht das via Remove- AzureADTrustedCertificateAuthority. Um alle CAs auf einen Schlag zu entfernen, können Sie ein "Get-" mit dem "Remove-"Cmdlet kombinieren:

Sind nur einzelne Teile der Kette oder eine Issuing-CA betroffen, erfahren Sie aus dem "Get-"Kommando die betroffene CA und löschen diese dann.

Mit Zertifikaten und Smartcards erhält das Azure AD eine weitere Authentifizierungsmethode. Microsoft fügt die CBA als weiteres passwortloses Credential zur Plattform hinzu, das sowohl für Mitarbeiter als auch für die IT-Abteilung als sicheres Anmeldeverfahren zu Clouddiensten zur Verfügung steht. Die Anmeldung per Zertifikaten war in der Cloudwelt von Microsoft bislang nur den Active Directory Federation Services vorbehalten.