Pålogging og sikkerhet inkl. SSO

Som utgangspunkt logger alle på med et brukernavn og et passord. E-postadressen virker i stedet for brukernavnet. Er e-postsending satt opp, vises lenka «Do you need a password reset?» under skjemaet. E-postsending er en del av Professional.

Etter påloggingen får nettleseren et pass som er gyldig ei bestemt tid. Kortet «JWT token timer» bestemmer hvor lenge. Verdier fra 1 til 24 timer er tillatt, 12 er anbefalingen. Deretter må personen logge på igjen.

Kortet «Password policy» gjelder for hvert passord som blir satt i systemet. Den blir håndhevet når en konto blir opprettet, når en person endrer sitt eget passord, og når en administrator tilbakestiller et.

Dere setter minstelengden, hvilke slags tegn som skal opptre, etter hvor mange dager et passord går ut, og hvor mange gamle passord som forblir sperret. For dagene og sperrelista betyr 0 «av».

Reglene om store og små bokstaver stenger ingen språk ute. Mange skriftsystemer har ikke den forskjellen i det hele tatt, og et tegn fra et av dem oppfyller begge reglene helt alene.

Kontoer som bare logger på gjennom SSO eller en katalog, har ikke noe lokalt passord, så utløp gjelder ikke for dem. Reglene deres bor hos leverandøren. Er en eksisterende konto knyttet til SSO og har den fortsatt sitt eget passord, fortsetter utløpet og passordpolicyen å gjelde for det passordet.

Kortet «2FA Settings» bestemmer hvem som må bruke tofaktorpålogging. Under «Two-factor requirement» velger dere ett av fire nivåer: «Off», «Administrators only», «Administrators and agents» eller «Everyone». «Everyone» omfatter også kundene. En ny installasjon starter med «Administrators only». En installasjon som fantes fra før, beholder den tidligere innstillingen etter en oppdatering.

Den som logger på neste gang uten en andre faktor, setter opp en. Systemet viser en QR-kode til en autentiseringsapp og den samme nøkkelen til å taste inn for hånd. Etter den første koden er faktoren aktiv. Med «Set up later» kan oppsettet utsettes, og påloggingen fortsetter uten. Det går i høyst 7 dager, regnet fra første gang det ble utsatt. Linjen under knappen viser dagene som er igjen. Deretter er oppsettet påkrevd.

Rett etterpå dukker det opp ti gjenopprettingskoder. Hver av dem erstatter koden fra appen én gang. De blir vist nøyaktig én gang. Dere lagrer dem med «Copy» eller «Download». «Download» virker alltid. «Copy» virker som regel også.

Mister noen enheten sin og kodene sine, hjelper administratoren. I brukerlista tilbakestiller knappen med det overstrekede skjoldet tofaktorpåloggingen til den personen. Hun setter den opp igjen ved neste pålogging.

Kodene avhenger av klokka på serveren. Går den feil, blir ingen kode godtatt. Knappen «Check now» på det samme kortet holder servertida opp mot ei offentlig tidskilde.

Logger noen på gjennom en ekstern påloggingstjeneste, spør ikke systemet om en kode. Leverandøren har allerede sjekket den andre faktoren. Katalogpålogging er annerledes: der gjelder regelen ovenfor fortsatt.

Hver bruker kan slå på tofaktorpålogging for sin egen konto. Det gjelder for alle roller, også når kortet «2FA Settings» ikke krever det. Åpne brukermenyen nederst til venstre i sidemenyen og velg «Profile picture». Den samme siden inneholder området «Two-factor authentication».

Området viser om tofaktorpålogging er slått på. Så lenge den er slått av, står knappen «Turn on» der. Den ber først om passordet. Deretter vises en QR-kode til autentiseringsappen, med den samme nøkkelen til å taste inn for hånd. Etter den første koden fra appen er faktoren aktiv.

Rett etterpå dukker det opp ti gjenopprettingskoder. Lagre dem med «Copy» eller «Download». «I have saved my codes» lukker listen. Den vises bare denne ene gangen.

Så lenge tofaktorpålogging er slått på, viser området hvor mange gjenopprettingskoder som er igjen. «New recovery codes» lager ti nye. De gamle kodene virker da ikke lenger. «Turn off» slår tofaktorpålogging av igjen. Begge knappene krever den gjeldende koden fra appen. En gjenopprettingskode godtas ikke der.

Krever kortet «2FA Settings» tofaktorpålogging for rollen, mangler «Turn off». En linje i området sier det.

Et feil passord eller en feil kode teller som en mislykket pålogging. Beskyttelsen mot gjetting av passord gjelder altså også her. Å slå på og av blir registrert i sikkerhetsloggen. Slår en administrator av sin egen tofaktorpålogging, gir loggen en alarm.

Kontoer som bare logger på via en ekstern påloggingstjeneste, ser en setning i stedet for knappene. Leverandøren deres håndterer den andre faktoren. Kontoer fra en katalog skriver i første trinn inn passordet sitt fra katalogen.

Beskyttelsen kjører uten noen innstilling. Det er ingenting å slå på. Merknaden om den står i kortet «2FA Settings».

Den virker i to trinn. Etter fem mislykkede forsøk på den samme kontoen blir adressen de kom fra, satt på pause. Pausen slutter senest 15 minutter etter det første av de forsøkene. Fra hver annen adresse kan kontoen brukes med én gang.

Det er den viktige delen. Ellers kunne enhver som kjenner et påloggingsnavn, låst en kollega ute med fem gale passord. Hun ville aldri trengt et passord til det.

Det andre trinnet er selve kontoen. Den blir låst i 15 minutter etter 20 mislykkede forsøk. Fordi en enkelt adresse høyst kan bidra med fem av dem, krever det flere adresser.

En vellykket pålogging tilbakestiller begge tellerne. Etter en omstart av serveren er pausen på adressen borte, låsingen av kontoen blir stående. De samme tellerne gjelder for pålogging gjennom en katalog. En katalog som ikke kan nås, teller ikke som et mislykket forsøk. Finnes det ennå ingen konto for navnet i ticketsystemet, gjelder bare pausen på adressen.

I brukerlista bærer en konto som er låst på den måten, merkingen «temporarily locked». Den blir stående i lista. Etter 15 minutter forsvinner merkingen av seg selv.

Dere trenger ikke å vente. I den samme raden er det en knapp med en åpen hengelås. Den opphever låsingen med én gang og tømmer begge tellerne.

Det er ikke det samme som «Archive». Den knappen stenger en konto for alltid, og bare den opptar eller frigjør en medarbeiderplass.

Sikkerhetsloggen registrerer to slags hendelser. Området «Sign-in» inneholder mislykkede pålogginger, låste kontoer, påloggingsforsøk under en lås, avviste tofaktorkoder og passordendringer. Det gjelder pålogging med passord, via en katalog og via SSO.

Området «Administration» viser hvem som endret hva. Det omfatter kontoer, roller, rettigheter, sikkerhetsinnstillinger og arkiver. Hver eksport av loggen står også der.

Vellykkede pålogginger registreres bare i to tilfeller. Det første tilfellet er en administrator. Det andre tilfellet er en pålogging etter mislykkede forsøk på den samme kontoen. Den vanlige påloggingen til en saksbehandler eller en kunde står ikke i loggen. Loggen er ingen oppmøteliste.

Logger noen på med et navn som ikke finnes, står det «unknown account» i oppføringen. Systemet lagrer ikke det inntastede navnet. Noen ganger er det et passord som havnet i feil felt.

Påloggingshendelser lagrer IP-adressen og nettleseren. Administratorhandlinger lagrer hvem som utførte dem, men ingen IP-adresse. Passord, koder og innholdet i saker eller e-poster står aldri i loggen.

Siden viser de nyeste oppføringene først, 50 per side. Kortet «Filters» snevrer inn listen. «Area» velger pålogginger eller administrasjon, «Event» én enkelt type hendelse. «Person» søker i navnet til den som handlet og den som ble berørt. «From» og «To» begrenser dagene. «Failures only» skjuler alt som lyktes.

Filtrene virker først etter et klikk på «Apply». «Reset» fjerner dem igjen.

«Export CSV» og «Export PDF» laster ned nøyaktig det filtrene viser. Hver fil inneholder høyst 10 000 oppføringer. Passer flere oppføringer til filtrene, sier en merknad ved eksportknappene det. PDF-filen er på ditt språk og nevner filtre og periode øverst. Dato og klokkeslett følger formatet som er stilt inn under «Settings → General Settings».

CSV-filen er alltid på engelsk, og tidene står i UTC. Slik kan et program lese den uavhengig av språket. Hver eksport står selv i loggen, som «Security log exported».

Seks hendelser utløser en alarm. Det er en konto som er låst etter mislykkede forsøk, en rolle som er endret til «Admin», en konto som er opprettet direkte med rollen «Admin», og en tilbakestilt tofaktorpålogging for en administrator. I tillegg kommer arkiverte saker som er fjernet fra de løpende dataene, og en administrators pålogging etter mislykkede forsøk.

Etter en alarm ser alle med rettigheten et gult banner øverst på hver side. Det nevner antallet alarmer siden deres siste besøk i loggen. Lenken «Open security log» fører dit. Når loggen åpnes, forsvinner banneret. Før det første besøket teller det alarmene fra de siste sju dagene.

I tillegg får hver aktiv konto med rettigheten og en e-postadresse en alarm-e-post. Systemet samler alarmene hvert 15. minutt og sender én e-post per person, ikke én per hendelse. E-posten nevner hendelsen, den berørte personen og tidspunktet. Den inneholder ingen IP-adresse. Alarm-e-posten hører til Professional.

Den nattlige kjøringen sletter gamle oppføringer. Fristene finnes under «Settings → Security» i kortet «Data protection» i blokken «Security log retention». Påloggingshendelser blir som standard lagret i 90 dager, 7 til 365 dager er tillatt. Administratorhandlinger blir som standard lagret i 12 måneder, 1 til 120 måneder er tillatt.

Hver frist har sin egen bryter: «Delete old sign-in events» og «Delete old administrator actions». Er en bryter slått av, blir de oppføringene stående. Kortet «Oppbevaringsfrister» forklarer den nattlige kjøringen.

Ved et innsyn får personen hver oppføring der vedkommende handlet eller ble berørt. IP-adresse og nettleser følger bare med i oppføringer som personen selv utløste, for eksempel sin egen pålogging. Blir personen anonymisert, sletter systemet vedkommendes påloggingshendelser. Vedkommendes administratorhandlinger blir stående. Navnet blir der erstattet av plassholderen.

En merknad til deg som driftsansvarlig: vellykkede pålogginger står bare i loggen for administratorer og etter mislykkede forsøk. Loggen viser likevel hvem som gjorde hva og når. I en virksomhet med tillitsvalgte er den derfor et tema for medbestemmelse.

Aller øverst sitter hovedbryteren «Enable single sign-on». Så lenge den er av, blir det ved brukernavn og passord. Alt dere setter opp nedenfor, blir lagret og trer først i kraft når dere slår den på.

Kortet «Active Directory / LDAP» kobler til en katalog i huset. Dere taster inn serveren, søkegrunnlaget, filteret som finner en person, og feltene for e-postadressen og navnene.

Kontoen som brukes til oppslag, er valgfri. Uten den spør systemet anonymt. Passordet til en person blir bare brukt til å binde mot katalogen og blir aldri lagret.

En katalog bringer ingen andre faktor med seg. Krever sikkerhetssiden tofaktorpålogging, blir også disse menneskene spurt om det.

Kortet «Identity providers» rommer de eksterne påloggingstjenestene. Hver får sin egen flate og sin egen knapp på påloggingssiden. «Add provider» oppretter en ny.

Under «Provider type» velger dere typen. «Generic OIDC Provider» passer til tjenester som Google Workspace, Microsoft Entra ID, Okta, Keycloak, Auth0 eller Ping Identity. «SAML 2.0 Provider» passer til de samme husene når de skal kobles til over SAML.

Ved siden av dem står seks regionale tjenester: LINE, Kakao, Naver, WeChat, WeCom og DingTalk. Adressene deres er fylt ut på forhånd og står som grå tekst i feltet.

Navnet under «Display name» står senere på knappen. Bryteren ved siden av gjelder bare denne ene leverandøren.

Til callback-adressen må dere arbeide i denne rekkefølgen. Tast først inn bare et navn, og klikk på «Save provider». Først da kjenner systemet nummeret til leverandøren og viser den ferdige adressen under «Redirect URI». Den blir bygget av den offentlige adressen til denne installasjonen, den som er lagret under «Settings → Security». Det er nøyaktig den adressen systemet bruker når noen logger på.

Den adressen kopierer dere og registrerer den hos leverandøren. Den må stemme tegn for tegn der. Til gjengjeld gir leverandøren dere en ID og en hemmelighet, og dem taster dere inn her via «Edit».

Feltet «Allowed e-mail domains» begrenser hvem som kan komme inn gjennom denne leverandøren. Lar dere det stå tomt, er hvert domene tillatt.

Mangler en leverandør fortsatt noe, bærer flata dens den røde merkingen «Incomplete». Da står den ikke på påloggingssiden. Teksten ved siden av sier hvilke felter typen dens krever.

Fullt oppsatte leverandører står fortsatt ikke der så lenge hovedbryteren er av. Flata sier det i ei gul linje.

Faller lisensen deres tilbake til Basic, fortsetter påloggingen gjennom SSO og katalogen å virke. På denne siden kan dere da bare slå av leverandører og katalogen. Loggen over påloggingsforsøk kan fortsatt leses.

Bryteren «Automatically create accounts on first sign-in» sitter i det samme kortet som hovedbryteren. Den er slått på som utgangspunkt.

Når noen logger på gjennom en leverandør for første gang, leter systemet først etter en konto som allerede hører til den leverandøren. Finner det ingen, blir det opprettet en ny.

Den nye kontoen får rollen «Customer» og ikke noe team. En kunde trenger ikke noe medlemskap for å opprette en sak og kan derfor sette i gang med én gang.

Kunder er ubegrensede i begge utgaver, så en konto som er opprettet på den måten, bruker ingen medarbeiderplass. Den som skal bli agent, får rollen etterpå i brukeradministrasjonen.

Finnes det allerede en konto med den samme e-postadressen, blir de to knyttet sammen. Det skjer bare når leverandøren melder adressen som bekreftet. Gjør den ikke det, blir påloggingen avvist.

Slår dere den av, kommer bare folk inn som allerede har en konto. Alle andre blir avvist.

Kortet «Recent sign-in attempts» helt nederst viser de siste 100 påloggingshendelsene via SSO og katalogen. De kommer fra sikkerhetsloggen. Mislykkede forsøk står alltid der. En vellykket pålogging står bare der for administratorer og etter mislykkede forsøk på den samme kontoen. Derfor står ikke hver pålogging i listen.

Hver rad nevner tidspunktet, leverandøren, resultatet og kildeadressen. Ved et mislykket forsøk står grunnen ved siden av. Kolonnen «User» viser navnet på kontoen. Finnes det ingen konto, viser den adressen som leverandøren har meldt, ellers «unknown account». Systemet lagrer ikke navnet som ble tastet inn.

Pålogging med brukernavn og passord står ikke i denne tabellen. Det er ikke SSO. Du finner den i sikkerhetsloggen.

Som standard blir oppføringene slettet etter 90 dager. Setningen under korttittelen nevner fristen som er satt. Kortet «Oppbevaringsfrister» forklarer innstillingen.

Etter installasjonen bruker teamet deres systemet i enhver nettleser. Installasjonsprogrammet spør hvordan systemet skal nås. I Windows-installasjonsprogrammet velger dere dette på siden «Tilgjengelighet». På Linux stiller install.sh det samme spørsmålet og nummererer valgene fra 1 til 5. Senere endrer dere det med «Endre hvordan SMITEY nås». Dataene blir der de er.

Valget «Bare lokalnettet, via IP-adressen (HTTP) - det enkleste alternativet» er standardinnstillingen. Teamet deres åpner systemet på http:// fulgt av IP-adressen til serveren og porten, for eksempel http://192.168.1.20:8088. Porten er 8088, med mindre dere velger en annen. Port 80 virker også. Da trenger adressen ingen port. Dette valget trenger verken navn eller sertifikat.

Valget «I lokalnettet under sitt eget navn (HTTP, HTTPS mulig senere) - du har intern DNS» virker som det første, men under et navn som ticket.company.local. Navnet oppretter dere selv i den interne DNS-en deres. Det peker til IP-adressen til serveren. Da når teamet deres systemet via navnet og fortsatt via IP-adressen. Installasjonsprogrammet viser da adressen med dette navnet.

Med begge HTTP-valgene går passord og saker gjennom nettverket deres som klartekst. Administratorer ser da en melding øverst på siden.

De tre andre valgene bruker HTTPS: «Via et offentlig domene med HTTPS (automatisk, med Let's Encrypt)», «I det lokale nettverket med HTTPS og ditt eget sertifikat» og «I det lokale nettverket med HTTPS, sertifikat laget av SMITEY». De trenger portene 80 og 443 på serveren. Det neste kortet beskriver dem.

Til en første test er det første valget nok. Har nettverket deres intern DNS, velger dere det andre. Skal systemet kunne nås fra internett, velger dere det offentlige domenet. Har bedriften deres sin egen sertifiseringsinstans, velger dere eget sertifikat i det lokale nettverket. Ellers lar dere SMITEY lage sertifikatet.

Uten HTTPS går passord og saker gjennom nettverket som klartekst. En ny installasjon starter med vanlig HTTP, så den virker med én gang i hvilken som helst nettleser. Så lenge en administrator åpner systemet over vanlig HTTP, vises en melding øverst på siden: «This connection is not encrypted.» Åpnes systemet på selve serveren under «localhost», vises ikke meldingen. Agenter og kunder ser den aldri.

«How to switch on HTTPS» fører til dette kortet. «Hide for 30 days» skjuler meldingen for deg. Innstillingen hører til kontoen og gjelder derfor også i en annen nettleser. Etter 30 dager kommer meldingen tilbake, så lenge forbindelsen fortsatt ikke er kryptert.

SMITEY-installasjonsprogrammet setter opp HTTPS på tre måter. I Windows-installasjonsprogrammet velger dere på siden «Tilgjengelighet», og på Linux stiller install.sh det samme spørsmålet. På et system som allerede kjører, åpner dere «Endre hvordan SMITEY nås» på Windows-skrivebordet eller i startmenyen. På Linux gjør kommandoen nedenfor det samme. Dataene blir der de er.

Valget «I det lokale nettverket med HTTPS og ditt eget sertifikat» bruker deres eget sertifikat, for eksempel fra bedriftens CA. Installasjonsprogrammet spør etter navnet på systemet og sertifikatfilen med nøkkelen. En PFX-fil med passordet sitt virker også. Før det endrer noe, kontrollerer det sertifikatet. Nøkkelen må passe, sertifikatet må være gyldig, og navnet må stå i sertifikatet.

Valget «I det lokale nettverket med HTTPS, sertifikat laget av SMITEY» trenger ikke noe eget sertifikat. SMITEY lager et selv og fornyer det også selv. Installasjonsprogrammet lagrer rotsertifikatet som SMITEY-root-ca.crt i installasjonsmappen. Installer denne filen på hver datamaskin som et klarert rotsertifikat, for eksempel med en gruppepolicy. Fram til da viser nettleserne en advarsel.

Valget «Via et offentlig domene med HTTPS (automatisk, med Let's Encrypt)» henter sertifikatet sitt fra Let’s Encrypt. Den trenger et offentlig domene som peker til serveren. Serveren må derfor kunne nås fra internett.

For begge valgene i det lokale nettverket kan navnet være et navn som ticket.company.local, ett enkelt ord som helpdesk eller en IPv4-adresse. Alle tre veiene trenger portene 80 og 443 på serveren. Bruker et annet program dem, stopper installasjonsprogrammet og endrer ingenting. Systemet nås deretter på https:// fulgt av navnet, uten port.

Deres eget sertifikat utløper en gang. Fra 30 dager før ser administratorer en melding med datoen øverst på siden. Fra 7 dager før er den rød. I Professional får alle administratorer med e-postadresse i tillegg en e-post 30 og 7 dager før. For å fornye åpner dere «Endre hvordan SMITEY nås» igjen, velger valget med eget sertifikat og oppgir de nye filene.

Filen HTTPS-GUIDE.txt som følger med installasjonen, beskriver hvert trinn. Det omfatter fordelingen av rotsertifikatet og trinnene for hånd.