Steigen neue Mitarbeiter in das Unternehmen ein, erhalten sie meist zunächst einen Satz von Anmeldeoptionen, mit denen sie sich an ihrem Computer, Mobiltelefon und der Infrastruktur einloggen. Die Übergabe der Anmeldedaten funktioniert entweder physisch durch den Vorgesetzten oder über einen Prozess, der die sichere Übertragung des Initialpassworts oder PIN sicherstellt.

Viele dieser Prozesse setzen voraus, dass sich der neue Mitarbeiter und der Vorgesetzte gegenüberstehen und eine Übergabe stattfinden kann. In halbwegs digitalisierten Fällen bekommt der Mitarbeiter die Daten telefonisch mitgeteilt, anderenorts wartet ein Umschlag mit einem Zettel im Postkasten des neuen Mitarbeiters, den dieser mit einem Schlüssel als Teil des Onboardings am ersten Arbeitstag öffnet. In vielen Fällen ist dies ein Passwort, von dem sich dann später weitere Credentials ableiten.

Ein verwandtes Szenario kostet viele Unternehmen bares Geld: Vergessen Mitarbeiter ihr Passwort oder lassen alle MFA-Optionen zu Hause oder verlieren diese sogar, hilft nur der Anruf beim Helpdesk. Dieser muss dann zunächst die Identität des Mitarbeiters feststellen und verifizieren und anschließend das Passwort oder die MFA-Optionen (Multifaktor-Authentifizierung) zurücksetzen. Zwei kostspielige Schritte, denn zunächst muss der Mitarbeiter beweisen, dass er legitim ist, und danach muss er das temporäre Passwort vom Helpdesk empfangen, richtig eintippen und anschließend neu setzen.

Erschwerend kommt hinzu, dass für beide skizzierten Anwendungsfälle nicht mehr anzunehmen ist, dass Mitarbeiter in diesen Fällen im Büro sitzen, sondern die allererste Anmeldung von zu Hause erfolgt. Oder dass grade verlorene oder kaputte MFA-Optionen auch aus der Ferne ersetzt werden müssen. Für die Cloud hat Microsoft in Azure AD ein Konzept von temporären Einmal-Passcodes als Preview eingeführt – Temporary Access Pass (TAP).

Die Idee dahinter: Bestätigt eine Identitätsverifikation den Mitarbeiter, wird ein zeitlimitierter Einmal-Passcode ausgehändigt, der zur Anmeldung am Azure Active Directory (AAD) gültig ist und anstelle eines Passworts oder MFA-Methode zum Einsatz kommt. So lassen sich wertvolle Arbeitsstunden überbrücken und Mitarbeiter zurück in die Produktivität schicken. Alternativ kann das TAP für das Zurücksetzen des Passworts oder zur Regis- trierung neuer MFA-Optionen als Self-Service-Option dienen.

TAP müssen Sie zunächst einschalten. Dabei definieren Sie zeitgleich, welche Mitarbeiter TAP zur Anmeldung nutzen können, wenn es ihnen ausgehändigt wird. Sie können die Einmal-Passcode-Option damit für alle Mitarbeiter in Ihrem Mandanten auf einen Schlag einschalten oder anhand von Gruppenmitgliedschaften vorprüfen, welchen Mitarbeitern die Funktion weiterhilft.

Für das Aktivieren müssen Sie mindestens "Authentication Method Policy Administrator" oder "Global Administrator" im Tenant sein. Die Konfiguration starten Sie im AAD unter "Security / Authentication Methods" im Azure-Portal. Neben anderen Anmeldeoptionen sehen Sie dort "Temporary Access Pass". Mit einem Klick editieren Sie die Einstellungen und im Reiter "Basics" schalten Sie TAP auf "Enable / Yes". Anschließend wählen Sie im Feld "Target", ob "All users" oder "Selected users" TAP benutzen können sollen. Wechseln Sie nun nach "Configure", wo Sie die Detaileinstellungen und die Grenzwerte der TAPs für den Mandanten definieren.

Da die Einmal-Passcodes zeitlich limitiert sein sollen, um nicht als Passwortersatz zu gelten, können Sie mit Adminrechten die Mindest- und Maximallaufzeit der TAPs festlegen. Delegierte Admins, Helpdesk, Sicherheitspersonal und alle, die TAPs für Mitarbeiter erstellen, können die Lebenszeit dann innerhalb der Grenzwerte konfigurieren. Sie bestimmen auch, wie viele Zeichen ein TAP lang sein soll – und ob alle TAPs strikt für Einmalnutzung zugelassen sind oder ob Mehrfachnutzung erlaubt ist. TAPs erzeugt das System automatisch und besitzen immer Groß- und Kleinbuchstaben, Zahlen und Sonderzeichen, sodass Sie sich um Komplexität keine Sorgen machen müssen.

Für das Azure AD ist TAP ein Credential wie viele andere auch: Helpdesk oder Personal des Sicherheitsdiensts können, nach Verifikation der Identität, ein TAP erstellen, dessen Lebensdauer festlegen und anschließend dem Mitarbeiter aushändigen. Nicht jeder ist in der Lage, die Passcodes zu erstellen – schließlich kann damit Authentifizierung im Namen eines anderen Benutzers geschehen. Sie müssen zumindest "Authentication Administrator" sein, um Benutzern ein TAP auszuhändigen – entweder besitzen Sie diese Rolle auf Tenant-Ebene oder Ihnen wurde die Rolle auf einer oder mehreren Administrative Units (AUs) delegiert, wonach Sie die Option haben, TAPs für bestimmte Benutzer anzulegen, aber nicht für alle Mitarbeiter des Unternehmens.

Das Erstellen starten Sie über das Azure-Portal in "Azure Active Directory / Users" über die Selektion des Benutzers und "Authentication Methods" im linken Menü im Benutzerprofil. Die Übersicht listet alle registrierten Authentifizierungsmethoden auf – das könnten Telefonnummern, OATH-Tokens, FIDO2-Hardwareschlüssel oder die Microsoft Authenticator App sein.

Mit "+ Add authentication method" öffnen Sie das "Add authentication method"-Menü am rechten Rand des Browsers. In der Auswahlliste suchen Sie "Temporary Access Pass" und nutzen den Schieberegler, um die gewünschte Lebensdauer zu wählen. Bereiten Sie den TAP für einen Mitarbeiter vor, der den Passcode erst später benutzen soll, können Sie die Startzeit des TAPs festlegen. Hier gilt: Je kürzer desto besser. Jedoch sollte der Mitarbeiter die Chance haben, den TAP nach dem Aushändigen auch tatsächlich sinnvoll zu nutzen.

Sobald Sie mit "OK" bestätigen, zeigt Ihnen das AAD-Portal zwei Informationen an: Einmal den neu generierte TAP – eine willkürliche, komplexe Zeichenkette wie "RjQ+-XDMWkD*". Zum anderen erhalten Sie den Hinweis, dass Sie den Mitarbeiter mit dem TAP zur "My Security Info"-Seite im Azure AD ("aka.ms/mysecurityinfo") schicken sollen, wo dieser dann mithilfe des TAP im Self-Service ein neues Passwort oder neue MFA-Methoden registrieren kann.

Das TAP ist ab dem Startzeitpunkt einsatzfähig und für die Gültigkeitsdauer valide. Das AAD schlägt, wenn sich der betreffende Benutzer an integrierten Apps anmelden möchte, fortan den TAP als Authentifizierungsmethode vor und passt die Anmeldemaske entsprechend an. Dies erfolgt selbst dann, wenn das Passwort die zuletzt verwendete Anmeldeoption war. Bereits erstellte, gültige TAPs lassen sich nur zum Erstellzeitpunkt einsehen – das gilt für das Admin-Portal wie auch die Graph-API.

Wenn Sie TAP als Funktion für den Tenant aktivieren oder ein TAP für einen Mitarbeiter erstellen, werden Sie darauf hingewiesen, dass der TAP ein zeitlimitierter, auf Wunsch einmalig verwendbarer Passcode ist, der als "Strong Credential" gilt. Das TAP ist also für das AAD ein Satz an Anmeldeinformationen, der das MFA-Kriterium erfüllt. Dabei ist das TAP selbst eigentlich kein Strong Credential und erfüllt auch die MFA-Anforderungen nicht, denn in Wirklichkeit handelt es sich um ein komplexes, zeitlich limitiertes Passwort. Was das TAP zu einem Strong Credential macht, ist die vorangegangene Identitätsverifikation, die Sie vor dem Aushändigen an den Mitarbeiter per Prozess sicherstellen müssen.

Hier wird die Teilung der Prozesskette deutlich: Der TAP ist die technische Implementierung eines kurzweiligen Credentials, das das Ergebnis einer vorangegangenen Identitätsprüfung ist. Sie müssen also selbst sicherstellen, dass Sie einen Prozess besitzen, mit dem Sie Mitarbeiter im Büro, in der Kantine, am Empfang wie auch remote im Home Office sicher und verlässlich identifizieren. In vielen Unternehmen existieren diese Prozesse. Mancherorts müssen Mitarbeiter dafür einer prüfenden Person Führerschein oder Reisepass vorzeigen und erhalten dann ein TAP, anderswo rufen Mitarbeiter den Helpdesk an und müssen eine Reihe von Fragen beantworten, die ausreichend auf die Identität rückschließen lassen. Vielleicht existiert der Prozess bereits digital und Mitarbeiter können per Self-Service und Webportal ihre Identifizierung und Verifikation eigenständig durchführen.

Am Ende der erfolgreichen Überprüfung steht dann der TAP, den Sie dem Mitarbeiter aushändigen. Über die Verifikation der Person können Sie den TAP dann auch als Strong Credential behandeln, das als MFA-Faktor zeitlich begrenzt gültig ist – Sie haben ja schließlich grade per starker Authentifizierung die Person überprüft. Die Stärke des Credentials liegt also einzig und allein in der Verlässlichkeit des Prozesses, mit dem Sie die Mitarbeiterverifikation durchführen.

Behalten Sie auch den Transportweg des TAPs zum Mitarbeiter im Kopf: Sind die Mitarbeiter physisch erreichbar, können Sie Ihnen den TAP selbst aushändigen oder dem Vorgesetzten per E-Mail schicken. Sind Sie auf digitale oder ferne Wege angewiesen, müssen Sie einen Weg finden, wie Sie den komplexen Passcode übertragen.

Bei Bedarf können Sie TAPs für eine Einmalnutzung konfigurieren. Haben Sie das nicht auf Tenant-Ebene mit "Require one-time use" festgelegt, können alle delegierten Mitarbeiter selbst entscheiden, ob die von ihnen ausgehändigten TAPs zur Mehrfachnutzung freigegeben oder nach Einmalgebrauch ungültig werden. Hier müssen Sie die Mitarbeiter instruieren und sich der Anwendungsfälle für TAP bewusst werden. Halten Sie es für legitim, dass Mitarbeiter tageweise mit einem TAP arbeiten, weil sie ihr Passwort nicht mehr wissen und das Büro nicht erreichen, dann ist eine Mehrfachnutzung notwendig.

Nutzen Sie TAPs hingegen nur dafür, dem Mitarbeiter einen Self-Service-Weg für die Wiederherstellung des Passworts, eines neuen FIDO2.0-Schlüssels oder das Hinterlegen einer neuen Telefonnummer für MFA zu eröffnen, dann reicht die Einmalnutzung – und Sie instruieren die Mitarbeiter, mit dem TAP zur AAD-MySecurityInfo-Seite zu gehen – um sich selbst zu befreien.

Die Anmeldemaske in Azure AD ändert sich automatisch, wenn für einen Mitarbeiter ein gültiger TAP vorliegt. Der Vorschlag geschieht, nachdem der Mitarbeiter seinen Benutzernamen angegeben und das AAD die Anmeldemethoden überprüft hat. Anstelle wie sonst üblich das zuletzt benutzte Credential, wie etwa das Passwort oder Anmeldung per Authenticator App vorzuschlagen, schaltet die AAD-Anmeldemaske um und schlägt den Temporary Access Pass vor. Das dient dem Benutzerkomfort, sodass sich Mitarbeiter selbstständig für neue Anmeldemethoden registrieren können. Ist der TAP gerade nicht das richtige Credential oder bereits nicht mehr notwendig, weil sich der Mitarbeiter befreit hat, hilft der Pfeil zurück neben dem Benutzernamen.

Besitzen Sie bereits alle notwendigen Prozesse zur Identitätsverifikation und sogar Self-Service-Funktionen, damit Benutzer sich selbst aus der Patsche helfen können, können Sie auch aufs Azure-Portal verzichten, um TAPs zu generieren. Die allermeisten Funktionen können Sie mit der PowerShell automatisieren oder für die Integration in bestehende Werkzeuge die Graph-API bemühen.

Da der Passcode ein temporäres Credential für einen Benutzer darstellt, legen Sie dieses auch via Graph-API an:

Damit erstellen Sie für "Petra" einen neuen TAP, der ab sofort für 30 Minuten gültig ist. In der Antwort, neben den Einstellungen und Optionen, denen der TAP unterliegt, finden Sie den TAP im Feld "temporaryAccessPass" in der Graph-Antwort:

Das geht, wenn Sie die "Authentication Methods Administrator"-Rolle oder die Berechtigung "UserAuthenticationMethod.­­­ReadWrite.All" besitzen und Sie die PowerShell benutzen. Aber auch, wenn Sie den Aufruf über eine App tätigen, die zuvor diese Berechtigung erhalten hat.

Sollten Sie eine besondere Startzeit für den TAP nutzen wollen, fügen Sie "startDateTime" als zusätzlichen, optionalen Parameter beim Erstellen an. Den Zeitstempel hinterlegen Sie im Zulu-Format, also "2022-08-10T06:30:00.000Z" für den 10. August um 8:30 Uhr morgens (die Zulu-Zeit hinkt der mitteleuropäischen Sommerzeit zwei Stunden hinterher).

Mit dem POST-Befehl erhalten Sie gültige TAPs für Benutzer:

Mitarbeiter können ein TAP, wie andere Anmeldeoptionen auch, über den "/me"-Endpoint des Graphen genauer studieren:

Mit der Graph-Schnittstelle ist der TAP auch für Automatisierung einsetzbar. Sollten Sie bereits ein bestehendes Tool besitzen, mit dem Sie Anwendern Credential-Hygiene und Self-Service-Funktionen anbieten, können Sie TAP nahtlos integrieren. Für die Automatisierung nutzen Sie ein Dienstkonto im AAD, also ein Service Principal (SP), dem Sie die Berechtigung "UserAuthenticationMethod.

ReadWrite.All" im "Application"-Kontext aushändigen.

Wenn Sie das Service Principal so ausstatten, müssen Sie zumindest mit einem Application-Administrator die Unternehmenszustimmung ("Consent") auf dem Applikationsobjekt erteilen, damit der SP loslegen kann.

Dann steht der Automation nichts mehr im Wege und Sie können etwa ServiceNow oder ein anderes Prozesstool als Abstraktion zwischen Benutzer und Azure AD etablieren. Oder Sie stellen die Identitätsverifikation in einem eigenen, zugänglichen Tool bereit und können so TAPs generieren und aushändigen.

Der eingangs beschriebene Anwendungsfall für neue Mitarbeiter, die an ihrem ersten Arbeitstag ein neues Gerät erhalten und entweder ihr Passwort nicht so einfach bekommen können oder gar nicht erst erhalten sollen, lässt sich ebenfalls beispielhaft mit TAPs lösen. Sollten Sie in Ihrem Unternehmen auf Intune und Autopilot bauen, können Sie ein neues Gerät direkt an den neuen Mitarbeiter schicken, der das Gerät dann selbst in Betrieb nimmt.

Bei der Installation muss das Device auch zum Unternehmens-AAD hinzugefügt werden, damit es die richtigen Intune-Einstellungen und Richtlinien zieht. Sollte der neue Kollege zum Logon-Zeitpunkt noch kein Passwort haben, können TAPs zum Einsatz kommen. Wenn Sie es ermöglichen, dass Mitarbeiter ihre Identität aus der Ferne mit HR, dem Sicherheitsdienst oder einem Drittanbieter für Identitätsverifikation überprüfen lassen können, kann daraus ein TAP entspringen. Dieser ist dann gültig für die Anmeldung an Azure AD, um die Windows-Installation zu beenden.

Und noch mehr: Für Windows Hello for Business können Sie in Autopilot die entsprechende Installation starten. Da Hello for Business eine MFA-Methode erzwingt, eignet sich auch hier der TAP hervorragend. Damit schlagen Sie mehrere Fliegen mit einer Klappe: Der Mitarbeiter ist passwortlos authentifiziert, die Installation läuft durch, der Mitarbeiter kann Hello for Business registrieren und sich fortan mit Biometrie anmelden und hat dank Hello eine MFA-Methode bereits vom ersten Tag an. So klappt der Start in der Cloud wie auch in der On-Premises-Welt, sollte Kerberos zum Einsatz kommen.

Der TAP eignet sich für Szenarien, in denen Mitarbeiter ihre MFA-Methoden vergessen beziehungsweise verloren haben oder noch gar keine Anmeldeoptionen besitzen, sich aber passwortlos anmelden können müssen. Der Einmalcode berechtigt zum Einlass für das Portal zur Credential-Registration, womit sich der Mitarbeiter dann selbst bedienen und ein neues Telefon registrieren, einen neuen FIDO2.0-Schlüssel oder eine andere MFA-Methode hinterlegen kann. Wie Sie die technische Umsetzung des TAP an bestehende Prozesse binden und die Identitätsverifikation durchführen, ist allerdings Ihnen überlassen.