Sette opp flerfaktorautentisering¶
Flerfaktorautentisering (MFA) ber brukeren om et annet bevis i tillegg til identifikatoren og passordet sitt. CyberElements tilbyr flere måter å få et på. Denne siden dekker fire av dem, i den rekkefølgen de vanligvis vurderes, og beskriver deretter den som ikke har sin egen integrasjonsside: engangspassordet som sendes via e-post.
Fire faktorer, ikke hele bildet
Disse fire er dem denne siden går gjennom — de er ikke de eneste andrefaktorene som plattformen kan be om. Også tilgjengelige, men utenfor omfanget av denne siden:
- en OTP som sendes via SMS, gjennom en av de mange operatørene som modulen OTP Token Generators tilbyr;
- en Radius-connector mot en MFA-løsning fra en tredjepart, gjennom typen OTP - Radius i den samme modulen;
- autentisering med x509-sertifikat, som ikke er et token, men en autentiseringsmetode på selve domenet — User certificate, eller User certificate and form for også å beholde passordet;
- en MFA som håndheves oppstrøms av en SAML-leverandør, eller av en hvilken som helst annen delegert autentisering. Den andre faktoren bes det da om før plattformen er involvert, og plattformen verken konfigurerer eller ser den.
MFA angis på identitetsleverandøren, aldri på en bruker
Uansett hvilken faktor du velger, aktiveres den på en identitetsleverandør og gjelder for alle brukere som logger på gjennom den. Det finnes ingen innstilling per bruker: hvis bare en del av brukermassen din skal omfattes av MFA, må du plassere disse brukerne bak en dedikert identitetsleverandør.
Velge en faktor¶
| Faktor | Hva brukeren gjør | Hva den krever | Fremgangsmåte |
|---|---|---|---|
| Neomia Pulse | Ingenting. Brukeren gjenkjennes på måten vedkommende skriver på tastaturet sitt. | Neomia Pulse-alternativet, en identitetsleverandør av typen local eller LDAP og en annen faktor fra denne tabellen på den samme leverandøren. |
Neomia Pulse-integrasjon |
| FIDO2 | Viser frem autentikatoren sin — setter inn en sikkerhetsnøkkel eller godkjenner på enheten eller i den Vault som inneholder passkeyen — og skriver deretter inn en PIN-kode hvis autentikatoren ber om en. | En FIDO2-autentikator per bruker, en relying party som er deklarert i konsollet, og en personlig konto — en anonym identitetsleverandør er utelukket. | Yubico-integrasjon |
| TOTP | Leser av en sekssifret kode i en autentikatorapplikasjon. | En applikasjon på telefonen eller arbeidsstasjonen til brukeren (Google Authenticator, FreeOTP, Microsoft Authenticator og så videre) og én registrering per bruker. | Google Authenticator-integrasjon |
| OTP via e-post | Kopierer en kode som er mottatt via e-post. | En SMTP-server som plattformen kan nå, og en e-postadresse som ligger i en brukerattributt. | Oppsett av en OTP via e-post |
Neomia Pulse konfigureres oppå en annen faktor
For å aktivere Neomia Pulse må en annen MFA være aktivert på det samme domenet. Innstillingene til Pulse avgjør deretter hva den andre faktoren brukes til: den kan hoppes over når Pulse validerer brukeren, og kreves når Pulse ikke gjør det. Neomia Pulse er derfor en måte å spare den andre faktoren på, snarere enn å erstatte den.
Hvor hver faktor deklareres, og hvor den aktiveres¶
Konfigurasjonen har to mulige etapper — å deklarere faktoren i sin egen modul og deretter aktivere den på identitetsleverandøren — men to av de fire hopper over den ene:
| Faktor | Deklareres i | Aktiveres på identitetsleverandøren |
|---|---|---|
| Neomia Pulse | ingenting å deklarere | ✅ alternativet Enable neomia Pulse authentication |
| FIDO2 | Relying parties | ❌ ingenting å aktivere — se merknaden nedenfor |
| TOTP | OTP Token Generators | ✅ som et autentiseringstoken |
| OTP via e-post | en SMTP-server, deretter OTP Token Generators | ✅ som et autentiseringstoken |
FIDO2 har ingen bryter på identitetsleverandøren
Sikkerhetsnøkler aktiveres ikke leverandør for leverandør: plattformen tilbyr faktoren så snart minst én relying party er deklarert, på hver identitetsleverandør som ikke er anonym — en nøkkel må være knyttet til en personlig konto. Og det er brukeren som registrerer autentikatoren sin fra portalen, ikke administratoren som tildeler den.
Neomia Pulse har ingenting å deklarere på forhånd
Pulse er ikke et token som skal opprettes i en modul: alternativet aktiveres direkte på identitetsleverandøren, som også er der oppførselen til det fastsettes.
Resten av denne siden dekker OTP via e-post fra ende til annen. De tre øvrige faktorene dekkes av integrasjonssiden sin, som det er lenket til i tabellen ovenfor.
Oppsett av en OTP via e-post¶
En OTP via e-post sender brukeren en engangskode via e-post når identifikatoren og passordet til brukeren er godtatt. Brukeren skriver inn denne koden på portalen for å fullføre påloggingen.
Før du går i gang: hva en OTP via e-post faktisk beskytter¶
En OTP via e-post legger ikke alltid til en faktor
Les dette før du velger denne faktoren fremfor de tre andre.
Hvis brukeren logger på med Active Directory-kontoen sin og henter koden i en postkasse som er knyttet til den samme kontoen, legger den andre faktoren nesten ingenting til: en angriper som har skaffet seg påloggingsinformasjonen, åpner postkassen med nettopp denne påloggingsinformasjonen og leser koden.
En OTP via e-post er verdt å rulle ut når postkassen ikke kan nås med påloggingsinformasjonen som kontrolleres, altså når:
- brukeren logger på med en lokal konto, eller med en konto som er forskjellig fra postkassen;
- koden sendes til en annen adresse enn den som hører til kontoen det logges på med.
Trinn 1 — Ha en SMTP-server tilgjengelig¶
Koden sendes av plattformen gjennom en SMTP-server som er deklarert i modulen SMTP servers. Hvis det ennå ikke finnes en, må du deklarere en før du går videre:
Bruk deretter blokken SMTP configuration test i den modulen til å bekrefte leveringen: en feil som oppdages på dette stadiet, er en feil du slipper å lete etter senere i påloggingsforløpet.
Testmeldingen bruker ikke avsenderen du kommer til å konfigurere
Testen sender fra noreply@cleanroom.com, en adresse som er innebygd i produktet: den kan ikke endres noe sted, og den fungerer også som svaradresse. Din egen avsender er SMTP sender for tokenet, som angis i trinn 2 — det er den de virkelige OTP-meldingene bærer.
Konsekvensen er verdt å kjenne før du konkluderer: en SMTP-server som begrenser avsenderadresser, kan avvise testen og samtidig slippe de egentlige meldingene gjennom — og omvendt.
Forbindelsen åpnes av plattformen
Flyten til SMTP-serveren går ut fra plattformen, ikke fra arbeidsstasjonen til brukeren. Hvis SMTP-serveren din står på LAN-et ditt, må den flyten være tillatt.
Trinn 2 — Opprett OTP-tokenet¶
Åpne modulen OTP Token Generators og klikk på +. I vinduet Add OTP token velger du typen OTP - email og fyller deretter ut feltene.
| Felt | Hva du skal skrive inn |
|---|---|
| OTP Type | OTP - email. Dette valget kan ikke endres etterpå — en annen kanal betyr et annet token. |
| Name | Navnet på tokenet. Det vises for brukeren på portalen, så det bør leses som navnet på en faktor snarere enn som en intern referanse. |
| Description | Fri tekst, som bare er synlig for administratorer. |
| OTP usable characters | Alfabetet koden hentes fra. |
| OTP Length | Antallet tegn i koden. |
| Validity period of a token (seconds) | Hvor lang tid brukeren har til å skrive inn koden før den avvises. |
| Message before the OTP | Setningen som står foran koden i meldingsteksten. |
| Mail subject | Emnet i meldingen. |
| SMTP sender | Avsenderadressen til meldingen. |
| SMTP server | Serveren som ble deklarert i trinn 1. |
Den fullstendige listen over felter, med standardverdiene og begrensningene deres, finnes på referansesiden: Generisk blokk og Sending via e-post.
Klikk på Validate for å lagre tokenet.
Trinn 3 — Aktiver tokenet på en identitetsleverandør¶
Åpne modulen Identity Providers og rediger leverandøren som skal be om OTP-en.
| Felt | Hva du skal skrive inn |
|---|---|
| Authentication token | Tokenet som ble opprettet i trinn 2. Det kan velges flere tokener. |
| User attribute used to send the OTP | Navnet på brukerattributten som inneholder adressen koden sendes til. |
| Token expiration duration | Hvor lenge en validert OTP forblir godtatt før det bes om den på nytt. 0 deaktiverer utløpet, noe som betyr at det bes om OTP-en ved hver pålogging. |
| Time unit | Hours eller Days, brukt på det forrige feltet. |
| Expiration starts | Om nedtellingen starter ved den siste OTP-valideringen eller ved den siste vellykkede påloggingen. |
Hvilken attributt som inneholder adressen
Attributten er den som finnes i katalogen identitetsleverandøren peker mot, ikke et navn vi velger: bruk attributten som brukerne dine faktisk har en adresse i. For en lokal katalog er det adressen som er skrevet inn i egenskapene til brukeren, som skal siktes mot; for en LDAP-katalog er det katalogens eget mail-attributt.
Klikk på Validate. Brukerne av den identitetsleverandøren blir bedt om en kode ved neste pålogging.
Trinn 4 — Kontroller først på en identitetsleverandør for test¶
Når du aktiverer MFA på en identitetsleverandør, gjelder det for alle brukere bak den, også deg selv hvis du logger på gjennom den. Før du aktiverer tokenet på produksjonsleverandøren din, oppretter du en identitetsleverandør for test med én enkelt konto og gjennomfører en fullstendig pålogging gjennom den: identifikator, passord, mottak av meldingen, inntasting av koden.
En bruker uten adresse mottar aldri en kode
Det kan ikke sendes noe til en bruker som har en tom attributt, og påloggingen til vedkommende kan ikke fullføres. Kontroller at attributten er utfylt for hver konto bak identitetsleverandøren, før du aktiverer tokenet på den.