Die Multi-Faktor-Authentifizierung einrichten¶
Die Multi-Faktor-Authentifizierung (MFA) verlangt vom Benutzer einen zweiten Nachweis zusätzlich zu seiner Kennung und seinem Passwort. CyberElements Bastion bietet mehrere Wege, einen solchen zu erhalten. Diese Seite behandelt vier davon, in der Reihenfolge, in der sie üblicherweise erwogen werden, und beschreibt anschließend denjenigen, der keine eigene Integrationsseite hat: das per E-Mail gesendete Einmalkennwort.
Vier Faktoren, nicht das ganze Bild
Diese vier sind diejenigen, die diese Seite durchgeht — sie sind nicht die einzigen zweiten Faktoren, die die Plattform anfordern kann. Ebenfalls verfügbar, aber außerhalb des Rahmens dieser Seite:
- ein per SMS gesendetes OTP, über einen der zahlreichen Anbieter, die das Modul OTP Token Generators bereitstellt;
- ein Radius-Connector zu einer MFA-Lösung eines Drittanbieters, über den Typ OTP - Radius desselben Moduls;
- die Authentifizierung per x509-Zertifikat, die kein Token ist, sondern eine Authentifizierungsmethode der Domäne selbst — User certificate oder User certificate and form, um zusätzlich das Passwort beizubehalten;
- eine MFA, die vorgelagert von einem SAML-Anbieter erzwungen wird, oder von einer beliebigen anderen delegierten Authentifizierung. Der zweite Faktor wird dann angefordert, bevor die Plattform beteiligt ist, die ihn weder konfiguriert noch sieht.
Die MFA wird auf der Authentifizierungsdomäne festgelegt, nie auf einem Benutzer
Welchen Faktor Sie auch wählen, er wird auf einer Authentifizierungsdomäne aktiviert und gilt für jeden Benutzer, der sich darüber anmeldet. Es gibt keine Einstellung je Benutzer: Um nur einen Teil Ihrer Benutzerschaft der MFA zu unterwerfen, stellen Sie diese Benutzer hinter eine eigene Authentifizierungsdomäne.
Einen Faktor auswählen¶
| Faktor | Was der Benutzer tut | Was es voraussetzt | Vorgehen |
|---|---|---|---|
| Neomia Pulse | Nichts. Der Benutzer wird an der Art erkannt, wie er auf seiner Tastatur tippt. | Die Option Neomia Pulse, die Verbindungseinstellungen zu Ihrem Pulse-Dienst, eine Authentifizierungsdomäne vom Typ local oder LDAP und einen zweiten Faktor aus dieser Tabelle auf derselben Domäne. |
Integration von Neomia Pulse |
| FIDO2 | Weist seinen Authentifikator vor — indem er einen Sicherheitsschlüssel einsteckt oder auf dem Gerät bzw. im Tresor bestätigt, der den Passkey enthält — und gibt anschließend eine PIN ein, wenn der Authentifikator danach fragt. | Einen FIDO2-Authentifikator je Benutzer, eine in der Konsole deklarierte Relying Party und ein persönliches Konto — eine anonyme Authentifizierungsdomäne ist ausgeschlossen. | Integration von Yubico |
| TOTP | Liest einen sechsstelligen Code in einer Authentifikator-Anwendung ab. | Eine Anwendung auf dem Telefon oder der Arbeitsstation des Benutzers (Google Authenticator, FreeOTP, Microsoft Authenticator und so weiter) und eine Registrierung je Benutzer. | Integration von Google Authenticator |
| OTP per E-Mail | Überträgt einen per E-Mail erhaltenen Code. | Einen von der Plattform erreichbaren SMTP-Server und eine E-Mail-Adresse in einem Benutzerattribut. | Ein OTP per E-Mail einrichten |
Neomia Pulse wird zusätzlich zu einem anderen Faktor konfiguriert
Die Aktivierung von Neomia Pulse setzt voraus, dass auf derselben Domäne eine weitere MFA aktiviert ist. Seine Einstellungen entscheiden dann darüber, wofür dieser andere Faktor verwendet wird: Er kann übersprungen werden, wenn Pulse den Benutzer bestätigt, und verlangt werden, wenn Pulse dies nicht tut. Neomia Pulse ist damit eher ein Weg, den zweiten Faktor zu sparen, als ihn zu ersetzen.
Wo jeder Faktor deklariert und wo er aktiviert wird¶
Die Konfiguration hat zwei mögliche Stufen — den Faktor in seinem eigenen Modul deklarieren und ihn dann auf der Authentifizierungsdomäne aktivieren —, aber zwei der vier überspringen eine davon:
| Faktor | Deklariert in | Auf der Authentifizierungsdomäne aktiviert |
|---|---|---|
| Neomia Pulse | nichts zu deklarieren | ✅ die Option Enable neomia Pulse authentication sowie die Verbindungseinstellungen zum Pulse-Dienst — siehe den Hinweis unten |
| FIDO2 | Relying parties | ❌ nichts zu aktivieren — siehe den Hinweis unten |
| TOTP | OTP Token Generators | ✅ als Authentifizierungstoken |
| OTP per E-Mail | einen SMTP server, dann OTP Token Generators | ✅ als Authentifizierungstoken |
FIDO2 hat keinen Schalter auf der Authentifizierungsdomäne
Sicherheitsschlüssel werden nicht anbieterweise aktiviert: Die Plattform bietet den Faktor an, sobald mindestens eine Relying Party deklariert ist, und zwar auf jeder Authentifizierungsdomäne, die nicht anonym ist — ein Schlüssel muss an ein persönliches Konto gebunden sein. Und es ist der Benutzer, der seinen Authentifikator im Portal registriert, nicht der Administrator, der ihn zuweist.
Bei Neomia Pulse ist vorab nichts zu deklarieren
Pulse ist kein Token, das in einem Modul erstellt wird: Die Option wird direkt auf der Authentifizierungsdomäne aktiviert, wo auch sein Verhalten festgelegt wird.
Pulse benötigt seine Verbindungseinstellungen
Das Aktivieren von Enable neomia Pulse authentication blendet drei Pflichtfelder ein, die die Plattform auf Ihren Pulse-Dienst verweisen:
| Feld | Was einzugeben ist |
|---|---|
| API URL | URL der Pulse-API. |
| Authentication API URL | URL der Authentifizierungs-API von Pulse. |
| API key | Schlüssel, mit dem sich die Plattform gegenüber diesem Dienst authentifiziert. |
Die Authentifizierungsdomäne lässt sich erst speichern, wenn alle drei ausgefüllt sind.
Der Rest dieser Seite behandelt das OTP per E-Mail von Anfang bis Ende. Die drei anderen Faktoren werden auf ihrer jeweiligen Integrationsseite behandelt, die in der Tabelle oben verlinkt ist.
Ein OTP per E-Mail einrichten¶
Ein OTP per E-Mail sendet dem Benutzer per E-Mail einen einmalig verwendbaren Code, sobald seine Kennung und sein Passwort angenommen wurden. Der Benutzer gibt diesen Code im Portal ein, um die Anmeldung abzuschließen.
Bevor Sie beginnen: wovor ein OTP per E-Mail tatsächlich schützt¶
Ein OTP per E-Mail fügt nicht immer einen Faktor hinzu
Lesen Sie dies, bevor Sie diesen Faktor den drei anderen vorziehen.
Meldet sich der Benutzer mit seinem Active-Directory-Konto an und holt er den Code aus einem Postfach, das an eben dieses Konto gebunden ist, fügt der zweite Faktor kaum etwas hinzu: Ein Angreifer, der die Anmeldedaten erlangt hat, öffnet mit genau diesen Anmeldedaten das Postfach und liest den Code.
Ein OTP per E-Mail lohnt sich, wenn das Postfach mit den geprüften Anmeldedaten nicht erreichbar ist, also wenn:
- der Benutzer sich mit einem lokalen Konto anmeldet oder mit einem Konto, das von seinem Postfach getrennt ist;
- der Code an eine andere Adresse gesendet wird als die, die zum Anmeldekonto gehört.
Schritt 1 — Einen SMTP-Server bereithalten¶
Der Code wird von der Plattform über einen SMTP-Server gesendet, der im Modul SMTP servers deklariert ist. Ist noch keiner verfügbar, deklarieren Sie einen, bevor Sie weitermachen:
Verwenden Sie anschließend den Block SMTP configuration test dieses Moduls, um die Zustellung zu bestätigen: Ein an dieser Stelle erkannter Fehler ist ein Fehler, den Sie später nicht im Anmeldeablauf suchen müssen.
Die Testnachricht verwendet nicht den Absender, den Sie konfigurieren werden
Der Test sendet von noreply@cleanroom.com, einer fest im Produkt hinterlegten Adresse: Sie lässt sich nirgends ändern und dient zugleich als Antwortadresse. Ihr eigener Absender ist der SMTP sender des Tokens, der in Schritt 2 gesetzt wird — er ist derjenige, den die echten OTP-Nachrichten tragen.
Die Folge ist es wert, vor jedem Schluss bekannt zu sein: Ein SMTP-Server, der die Absenderadressen einschränkt, kann den Test abweisen und die eigentlichen Nachrichten durchlassen — und umgekehrt.
Die Verbindung wird von der Plattform geöffnet
Der Fluss zum SMTP-Server geht von der Plattform aus, nicht von der Arbeitsstation des Benutzers. Steht Ihr SMTP-Server in Ihrem LAN, muss dieser Fluss erlaubt sein.
Schritt 2 — Das OTP-Token erstellen¶
Öffnen Sie das Modul OTP Token Generators und klicken Sie auf +. Wählen Sie im Fenster Add OTP token den Typ OTP - email aus und füllen Sie dann die Felder aus.
| Feld | Was einzugeben ist |
|---|---|
| OTP Type | OTP - email. Diese Wahl lässt sich nachträglich nicht ändern — ein anderer Übertragungsweg bedeutet ein anderes Token. |
| Name | Der Name des Tokens. Er wird dem Benutzer im Portal angezeigt, er sollte sich daher wie ein Faktorname lesen und nicht wie eine interne Referenz. |
| Description | Freier Text, nur für Administratoren sichtbar. |
| OTP usable characters | Das Alphabet, aus dem der Code gebildet wird. |
| OTP Length | Die Anzahl der Zeichen des Codes. |
| Validity period of a token (seconds) | Wie lange der Benutzer Zeit hat, den Code einzugeben, bevor er abgewiesen wird. |
| Message before the OTP | Der Satz, der dem Code im Nachrichtentext vorangeht. |
| Mail subject | Der Betreff der Nachricht. |
| SMTP sender | Die Absenderadresse der Nachricht. |
| SMTP server | Der in Schritt 1 deklarierte Server. |
Die vollständige Liste der Felder mit ihren Standardwerten und Einschränkungen steht auf der Referenzseite: Generischer Block und Versand per E-Mail.
Klicken Sie auf Validate, um das Token zu speichern.
Schritt 3 — Das Token auf einer Authentifizierungsdomäne aktivieren¶
Öffnen Sie das Modul Authentication domain und bearbeiten Sie die Domäne, die das OTP anfordern soll.
| Feld | Was einzugeben ist |
|---|---|
| Authentication token | Das in Schritt 2 erstellte Token. Es lassen sich mehrere Token auswählen. |
| User attribute used to send the OTP | Der Name des Benutzerattributs, das die Adresse enthält, an die der Code gesendet wird. |
| Token expiration duration | Wie lange ein bestätigtes OTP angenommen bleibt, bevor es erneut angefordert wird. 0 deaktiviert den Ablauf, das OTP wird dann bei jeder Anmeldung angefordert. |
| Time unit | Hours oder Days, angewandt auf das vorige Feld. |
| Expiration starts | Ob die Zählung bei der letzten OTP-Bestätigung oder bei der letzten erfolgreichen Anmeldung beginnt. |
Welches Attribut die Adresse enthält
Das Attribut ist dasjenige des Verzeichnisses, auf das die Authentifizierungsdomäne zeigt, kein Name unserer Wahl: Verwenden Sie das Attribut, in dem Ihre Benutzer tatsächlich eine Adresse führen. Bei einem lokalen Verzeichnis ist die in den Eigenschaften des Benutzers eingetragene Adresse anzuvisieren; bei einem LDAP-Verzeichnis ist es das Mail-Attribut des Verzeichnisses selbst.
Klicken Sie auf Validate. Die Benutzer dieser Authentifizierungsdomäne werden bei ihrer nächsten Anmeldung nach einem Code gefragt.
Schritt 4 — Zuerst auf einer Test-Authentifizierungsdomäne prüfen¶
Die Aktivierung der MFA auf einer Authentifizierungsdomäne wendet sie auf jeden Benutzer dahinter an, einschließlich Ihnen selbst, wenn Sie sich darüber anmelden. Bevor Sie das Token auf Ihrer Produktionsdomäne aktivieren, erstellen Sie eine Test-Authentifizierungsdomäne mit einem einzigen Konto und führen Sie darüber eine vollständige Anmeldung durch: Kennung, Passwort, Empfang der Nachricht, Eingabe des Codes.
Ein Benutzer ohne Adresse erhält nie einen Code
Einem Benutzer, dessen Attribut leer ist, kann nichts gesendet werden, und seine Anmeldung kann nicht abgeschlossen werden. Prüfen Sie, dass das Attribut für jedes Konto hinter der Authentifizierungsdomäne ausgefüllt ist, bevor Sie das Token darauf aktivieren.