Ställa in multifaktorautentisering¶
Multifaktorautentisering (MFA) kräver av användaren ett andra bevis utöver användarnamnet och lösenordet. CyberElements erbjuder flera sätt att få ett. Den här sidan täcker fyra av dem, i den ordning de vanligtvis övervägs, och beskriver sedan i detalj den som saknar egen integrationssida: engångslösenordet som skickas via e-post.
Fyra faktorer, inte hela bilden
Dessa fyra är de som den här sidan går igenom — de är inte de enda andra faktorer som plattformen kan begära. Även följande finns, utanför den här sidans omfattning:
- en OTP som skickas via SMS, genom en av de många operatörer som modulen OTP Token Generators erbjuder;
- en Radius-koppling mot en MFA-lösning från tredje part, genom typen OTP - Radius i samma modul;
- autentisering med x509-certifikat, som inte är en token utan en autentiseringsmetod för själva domänen — User certificate, eller User certificate and form för att behålla lösenordet också;
- en MFA som tillämpas i förväg av en SAML-leverantör, eller av vilken annan delegerad autentisering som helst. Den andra faktorn begärs då innan plattformen är inblandad, och plattformen varken konfigurerar eller ser den.
MFA ställs in på identitetsleverantören, aldrig på en användare
Vilken faktor du än väljer aktiveras den på en identitetsleverantör och gäller varje användare som loggar in via den. Det finns ingen inställning per användare: för att bara en del av din population ska omfattas av MFA placerar du de användarna bakom en särskild identitetsleverantör.
Välja en faktor¶
| Faktor | Vad användaren gör | Vad som krävs | Procedur |
|---|---|---|---|
| Neomia Pulse | Ingenting. Användaren känns igen på sättet att skriva på tangentbordet. | Tillvalet Neomia Pulse, en identitetsleverantör av typen local eller LDAP och en andra faktor från den här tabellen på samma leverantör. |
Neomia Pulse-integration |
| FIDO2 | Visar upp sin authenticator — sätter i en säkerhetsnyckel eller godkänner på den enhet eller den vault som innehåller passkeyen — och anger sedan en PIN-kod om authenticatorn ber om en. | En FIDO2-authenticator per användare, en relying party som deklarerats i konsolen och ett personligt konto — en anonym identitetsleverantör är utesluten. | Yubico-integration |
| TOTP | Läser av en sexsiffrig kod i en authenticator-applikation. | En applikation på användarens telefon eller arbetsstation (Google Authenticator, FreeOTP, Microsoft Authenticator och så vidare) och en registrering per användare. | Google Authenticator-integration |
| OTP via e-post | Kopierar en kod som tagits emot via e-post. | En SMTP-server som plattformen kan nå och en e-postadress som finns i ett användarattribut. | Ställa in en OTP via e-post |
Neomia Pulse konfigureras ovanpå en annan faktor
Att aktivera Neomia Pulse kräver att en annan MFA är aktiverad på samma domän. Dess inställningar avgör sedan vad den andra faktorn används till: den kan hoppas över när Pulse validerar användaren och krävas när Pulse inte gör det. Neomia Pulse är därför ett sätt att slippa den andra faktorn snarare än att ersätta den.
Var varje faktor deklareras och var den aktiveras¶
Konfigurationen har två möjliga steg — att deklarera faktorn i dess egen modul och sedan aktivera den på identitetsleverantören — men två av de fyra hoppar över ett av dem:
| Faktor | Deklareras i | Aktiveras på identitetsleverantören |
|---|---|---|
| Neomia Pulse | inget att deklarera | ✅ alternativet Enable neomia Pulse authentication |
| FIDO2 | Relying parties | ❌ inget att aktivera — se noteringen nedan |
| TOTP | OTP Token Generators | ✅ som en autentiseringstoken |
| OTP via e-post | en SMTP-server, sedan OTP Token Generators | ✅ som en autentiseringstoken |
FIDO2 har ingen omkopplare på identitetsleverantören
Säkerhetsnycklar aktiveras inte leverantör för leverantör: plattformen erbjuder faktorn så snart minst en relying party är deklarerad, på varje identitetsleverantör som inte är anonym — en nyckel måste vara kopplad till ett personligt konto. Och det är användaren som registrerar sin authenticator från portalen, inte administratören som tilldelar den.
Neomia Pulse har inget att deklarera i förväg
Pulse är ingen token som ska skapas i en modul: alternativet aktiveras direkt på identitetsleverantören, som också är där dess beteende ställs in.
Resten av den här sidan täcker OTP via e-post från början till slut. De tre andra faktorerna behandlas på sin integrationssida, som är länkad i tabellen ovan.
Ställa in en OTP via e-post¶
En OTP via e-post skickar en engångskod via e-post till användaren när användarnamnet och lösenordet har godtagits. Användaren anger den koden på portalen för att slutföra inloggningen.
Innan du börjar: vad en OTP via e-post faktiskt skyddar¶
En OTP via e-post lägger inte alltid till en faktor
Läs detta innan du väljer den här faktorn framför de tre andra.
Om användaren loggar in med sitt Active Directory-konto och hämtar koden från en brevlåda som är kopplad till samma konto tillför den andra faktorn nästan ingenting: en angripare som har fått tag i inloggningsuppgifterna öppnar brevlådan med just dessa uppgifter och läser koden.
En OTP via e-post är värd att rulla ut när brevlådan inte går att nå med de inloggningsuppgifter som kontrolleras, det vill säga när:
- användaren loggar in med ett lokalt konto, eller med ett konto som är skilt från brevlådan;
- koden skickas till en annan adress än den som hör till inloggningskontot.
Steg 1 — Ha en SMTP-server tillgänglig¶
Koden skickas av plattformen via en SMTP-server som deklarerats i modulen SMTP servers. Om ingen finns tillgänglig ännu deklarerar du en innan du går vidare:
Använd sedan blocket SMTP configuration test i den modulen för att bekräfta leveransen: ett fel som diagnostiseras i det här läget är ett fel du slipper leta efter senare i inloggningsflödet.
Testmeddelandet använder inte den avsändare du kommer att konfigurera
Testet skickas från noreply@cleanroom.com, en adress som är fastställd av produkten: den kan inte ändras någonstans och används även som svarsadress. Din egen avsändare är SMTP sender för tokenen, som ställs in i steg 2 — det är den som de verkliga OTP-meddelandena bär.
Konsekvensen är värd att känna till innan du drar slutsatser: en SMTP-server som begränsar avsändaradresser kan avvisa testet men släppa igenom de verkliga meddelandena, och tvärtom.
Anslutningen öppnas av plattformen
Flödet till SMTP-servern utgår från plattformen, inte från användarens arbetsstation. Om din SMTP-server finns i ditt LAN måste det flödet tillåtas.
Steg 2 — Skapa OTP-tokenen¶
Öppna modulen OTP Token Generators och klicka på +. I fönstret Add OTP token väljer du typen OTP - email och fyller sedan i fälten.
| Fält | Vad du ska ange |
|---|---|
| OTP Type | OTP - email. Detta val kan inte ändras i efterhand — en annan kanal innebär en annan token. |
| Name | Tokenens namn. Det visas för användaren på portalen, så det bör läsas som namnet på en faktor snarare än som en intern referens. |
| Description | Fri text, synlig endast för administratörer. |
| OTP usable characters | Alfabet som koden dras ur. |
| OTP Length | Antal tecken i koden. |
| Validity period of a token (seconds) | Hur lång tid användaren har på sig att ange koden innan den avvisas. |
| Message before the OTP | Den mening som föregår koden i meddelandets brödtext. |
| Mail subject | Meddelandets ämne. |
| SMTP sender | Meddelandets avsändaradress. |
| SMTP server | Den server som deklarerats i steg 1. |
Den fullständiga listan över fält, med deras standardvärden och begränsningar, finns på referenssidan: Generiskt block och Leverans via e-post.
Klicka på Validate för att spara tokenen.
Steg 3 — Aktivera tokenen på en identitetsleverantör¶
Öppna modulen Identity Providers och ändra den leverantör som ska begära OTP.
| Fält | Vad du ska ange |
|---|---|
| Authentication token | Den token som skapades i steg 2. Flera tokens kan väljas. |
| User attribute used to send the OTP | Namnet på det användarattribut som innehåller den adress koden skickas till. |
| Token expiration duration | Hur länge en validerad OTP fortsätter att godtas innan den begärs igen. 0 inaktiverar förfallet, vilket innebär att OTP begärs vid varje inloggning. |
| Time unit | Hours eller Days, tillämpas på föregående fält. |
| Expiration starts | Om nedräkningen börjar vid den senaste OTP-valideringen eller vid den senaste lyckade inloggningen. |
Vilket attribut som innehåller adressen
Attributet är det i den katalog som identitetsleverantören pekar på, inte ett namn vi väljer: använd det attribut som dina användare faktiskt bär en adress i. För en lokal katalog är det adressen som angetts i användarens egenskaper som ska anges; för en LDAP-katalog är det katalogens eget mail-attribut.
Klicka på Validate. Användarna hos den identitetsleverantören ombeds ange en kod vid nästa inloggning.
Steg 4 — Kontrollera först på en identitetsleverantör för test¶
Att aktivera MFA på en identitetsleverantör tillämpar den på varje användare bakom den, inklusive dig själv om du loggar in via den. Innan du aktiverar tokenen på din produktionsleverantör skapar du en identitetsleverantör för test med ett enda konto och kör en fullständig inloggning genom den: användarnamn, lösenord, mottagande av meddelandet, inmatning av koden.
En användare utan adress får aldrig någon kod
En användare vars attribut är tomt kan inte få något skickat till sig, och dennes inloggning kan inte slutföras. Kontrollera att attributet är ifyllt för varje konto bakom identitetsleverantören innan du aktiverar tokenen på den.