Opsæt multifaktorautentificering¶
Multifaktorautentificering (MFA) beder brugeren om et andet bevis ud over sin identifikator og adgangskode. CyberElements Bastion tilbyder flere måder at opnå et på. Denne side dækker fire af dem, i den rækkefølge de normalt overvejes, og beskriver derefter den, der ikke har sin egen integrationsside: engangsadgangskoden, der sendes via e-mail.
Fire faktorer, ikke hele billedet
Disse fire er dem, denne side gennemgår — de er ikke de eneste andenfaktorer, som platformen kan bede om. Også tilgængelige, men uden for denne sides omfang:
- en OTP, der sendes via SMS, gennem en af de mange operatører, som modulet OTP Token Generators tilbyder;
- en Radius-connector mod en MFA-løsning fra tredjepart, gennem typen OTP - Radius i det samme modul;
- autentificering med x509-certifikat, som ikke er et token, men en autentificeringsmetode på selve domænet — User certificate eller User certificate and form for også at beholde adgangskoden;
- en MFA, der håndhæves opstrøms af en SAML-udbyder, eller af enhver anden delegeret autentificering. Den anden faktor forlanges da, før platformen er involveret, og platformen hverken konfigurerer eller ser den.
MFA angives på autentificeringsdomænet, aldrig på en bruger
Uanset hvilken faktor du vælger, slås den til på et autentificeringsdomæne og gælder for alle brugere, der logger på gennem det. Der findes ingen indstilling pr. bruger: hvis kun en del af din brugerskare skal omfattes af MFA, skal du placere disse brugere bag et dedikeret autentificeringsdomæne.
Valg af en faktor¶
| Faktor | Hvad brugeren gør | Hvad den kræver | Fremgangsmåde |
|---|---|---|---|
| Neomia Pulse | Intet. Brugeren genkendes på den måde, vedkommende taster på sit tastatur. | Neomia Pulse-optionen, forbindelsesindstillingerne til din Pulse-tjeneste, et autentificeringsdomæne af typen local eller LDAP og en anden faktor fra denne tabel på det samme domæne. |
Neomia Pulse-integration |
| FIDO2 | Fremviser sin authenticator — sætter en sikkerhedsnøgle i eller godkender på den enhed eller den vault, der indeholder passkeyen — og indtaster derefter en PIN-kode, hvis authenticatoren beder om en. | En FIDO2-authenticator pr. bruger, en relying party erklæret i konsollen og en personlig konto — et anonymt autentificeringsdomæne er udelukket. | Yubico-integration |
| TOTP | Aflæser en sekscifret kode i en authenticator-applikation. | En applikation på brugerens telefon eller arbejdsstation (Google Authenticator, FreeOTP, Microsoft Authenticator osv.) og én registrering pr. bruger. | Google Authenticator-integration |
| OTP via e-mail | Kopierer en kode modtaget via e-mail. | En SMTP-server, som platformen kan nå, og en e-mailadresse gemt i en brugerattribut. | Opsætning af en OTP via e-mail |
Neomia Pulse konfigureres oven på en anden faktor
For at slå Neomia Pulse til skal en anden MFA være slået til på det samme domæne. Indstillingerne for Pulse afgør derefter, hvad den anden faktor bruges til: den kan springes over, når Pulse validerer brugeren, og kræves, når Pulse ikke gør det. Neomia Pulse er derfor en måde at spare den anden faktor på snarere end at erstatte den.
Hvor hver faktor erklæres, og hvor den slås til¶
Konfigurationen har to mulige etaper — at erklære faktoren i dens eget modul og derefter slå den til på autentificeringsdomænet — men to ud af de fire springer den ene over:
| Faktor | Erklæres i | Slås til på autentificeringsdomænet |
|---|---|---|
| Neomia Pulse | intet at erklære | ✅ indstillingen Enable neomia Pulse authentication, plus forbindelsesindstillingerne til Pulse-tjenesten — se noten nedenfor |
| FIDO2 | Relying parties | ❌ intet at slå til — se noten nedenfor |
| TOTP | OTP Token Generators | ✅ som et autentificeringstoken |
| OTP via e-mail | en SMTP-server, derefter OTP Token Generators | ✅ som et autentificeringstoken |
FIDO2 har ingen kontakt på autentificeringsdomænet
Sikkerhedsnøgler slås ikke til udbyder for udbyder: platformen tilbyder faktoren, så snart mindst én relying party er erklæret, på ethvert autentificeringsdomæne, der ikke er anonymt — en nøgle skal være knyttet til en personlig konto. Og det er brugeren, der registrerer sin authenticator fra portalen, ikke administratoren, der tildeler den.
Neomia Pulse har intet at erklære på forhånd
Pulse er ikke et token, der skal oprettes i et modul: indstillingen slås til direkte på autentificeringsdomænet, hvor dets adfærd også fastlægges.
Pulse har brug for sine forbindelsesindstillinger
Når du markerer Enable neomia Pulse authentication, vises tre obligatoriske felter, der peger platformen hen på din Pulse-tjeneste:
| Felt | Hvad du skal indtaste |
|---|---|
| API URL | URL til Pulse-API'en. |
| Authentication API URL | URL til Pulse-autentificerings-API'en. |
| API key | Nøgle, der autentificerer platformen over for den tjeneste. |
Autentificeringsdomænet gemmes ikke, før alle tre er udfyldt.
Resten af denne side dækker OTP via e-mail fra ende til anden. De tre øvrige faktorer dækkes af deres integrationsside, der er linket til i tabellen ovenfor.
Opsætning af en OTP via e-mail¶
En OTP via e-mail sender brugeren en engangskode via e-mail, når brugerens identifikator og adgangskode er accepteret. Brugeren indtaster denne kode på portalen for at fuldføre login.
Før du går i gang: hvad en OTP via e-mail faktisk beskytter¶
En OTP via e-mail tilføjer ikke altid en faktor
Læs dette, før du vælger denne faktor frem for de tre øvrige.
Hvis brugeren logger på med sin Active Directory-konto og henter koden i en postkasse, der er knyttet til den samme konto, tilføjer den anden faktor næsten intet: en angriber, der har skaffet sig legitimationsoplysningerne, åbner postkassen med netop disse legitimationsoplysninger og læser koden.
En OTP via e-mail er værd at udrulle, når postkassen ikke kan nås med de legitimationsoplysninger, der kontrolleres, altså når:
- brugeren logger på med en lokal konto eller med en konto, der er forskellig fra postkassen;
- koden sendes til en anden adresse end den, der hører til den konto, der logges på med.
Trin 1 — Hav en SMTP-server til rådighed¶
Koden sendes af platformen gennem en SMTP-server, der er erklæret i modulet SMTP servers. Hvis der endnu ikke er nogen til rådighed, skal du erklære en, før du går videre:
Brug derefter blokken SMTP configuration test i det modul til at bekræfte leveringen: en fejl, der findes på dette stadie, er en fejl, du ikke skal lede efter senere i login-forløbet.
Testmeddelelsen bruger ikke den afsender, du kommer til at konfigurere
Testen sender fra noreply@cleanroom.com, en adresse, der er indbygget i produktet: den kan ikke ændres nogen steder, og den fungerer også som svaradresse. Din egen afsender er SMTP sender for tokenet, som angives i trin 2 — det er den, de rigtige OTP-meddelelser bærer.
Konsekvensen er værd at kende, før du konkluderer: en SMTP-server, der begrænser afsenderadresser, kan afvise testen, mens den lader de egentlige meddelelser passere — og omvendt.
Forbindelsen åbnes af platformen
Flowet til SMTP-serveren udgår fra platformen, ikke fra brugerens arbejdsstation. Hvis din SMTP-server står på dit LAN, skal det flow være tilladt.
Trin 2 — Opret OTP-tokenet¶
Åbn modulet OTP Token Generators, og klik på +. Vælg typen OTP - email i vinduet Add OTP token, og udfyld derefter felterne.
| Felt | Hvad du skal indtaste |
|---|---|
| OTP Type | OTP - email. Dette valg kan ikke ændres bagefter — en anden kanal betyder et andet token. |
| Name | Navnet på tokenet. Det vises for brugeren på portalen, så det bør læses som navnet på en faktor snarere end som en intern reference. |
| Description | Fri tekst, som kun er synlig for administratorer. |
| OTP usable characters | Det alfabet, koden trækkes fra. |
| OTP Length | Antallet af tegn i koden. |
| Validity period of a token (seconds) | Hvor lang tid brugeren har til at indtaste koden, før den afvises. |
| Message before the OTP | Den sætning, der står før koden i meddelelsens brødtekst. |
| Mail subject | Meddelelsens emne. |
| SMTP sender | Meddelelsens afsenderadresse. |
| SMTP server | Den server, der blev erklæret i trin 1. |
Den fuldstændige liste over felter med deres standardværdier og begrænsninger findes på referencesiden: Generisk blok og Levering via e-mail.
Klik på Validate for at gemme tokenet.
Trin 3 — Slå tokenet til på et autentificeringsdomæne¶
Åbn modulet Authentication domain, og rediger det domæne, der skal bede om OTP'en.
| Felt | Hvad du skal indtaste |
|---|---|
| Authentication token | Det token, der blev oprettet i trin 2. Der kan vælges flere tokens. |
| User attribute used to send the OTP | Navnet på den brugerattribut, der indeholder den adresse, koden sendes til. |
| Token expiration duration | Hvor længe en valideret OTP forbliver accepteret, før der bedes om den igen. 0 slår udløbet fra, hvilket betyder, at der bedes om OTP'en ved hvert login. |
| Time unit | Hours eller Days, anvendt på det foregående felt. |
| Expiration starts | Om nedtællingen starter ved den seneste OTP-validering eller ved det seneste vellykkede login. |
Hvilken attribut indeholder adressen
Attributten er den, der findes i det katalog, autentificeringsdomænet peger på, ikke et navn, vi vælger: brug den attribut, som dine brugere faktisk har en adresse i. For et lokalt katalog er det den adresse, der er indtastet i brugerens egenskaber, der skal sigtes mod; for et LDAP-katalog er det katalogets egen mail-attribut.
Klik på Validate. Brugerne af det autentificeringsdomæne bliver bedt om en kode ved deres næste login.
Trin 4 — Kontrollér først på et autentificeringsdomæne til test¶
Når du slår MFA til på et autentificeringsdomæne, gælder det for alle brugere bag det, inklusive dig selv, hvis du logger på gennem det. Før du slår tokenet til på dit produktionsdomæne, skal du oprette et autentificeringsdomæne til test med en enkelt konto og gennemføre et fuldt login gennem det: identifikator, adgangskode, modtagelse af meddelelsen, indtastning af koden.
En bruger uden adresse modtager aldrig en kode
Der kan ikke sendes noget til en bruger, hvis attribut er tom, og vedkommendes login kan ikke fuldføres. Kontrollér, at attributten er udfyldt for hver konto bag autentificeringsdomænet, før du slår tokenet til på det.