Godkendelse og sikkerhed inkl. SSO

Som udgangspunkt logger alle ind med et brugernavn og en adgangskode. E-mailadressen virker i stedet for brugernavnet. Er mailafsendelse sat op, vises linket »Do you need a password reset?« under formularen. Mailafsendelse er en del af Professional.

Efter login får browseren et pas, der er gyldigt et bestemt stykke tid. Kortet »JWT token timer« bestemmer hvor længe. Værdier fra 1 til 24 timer er tilladt, 12 er anbefalingen. Derefter skal personen logge ind igen.

Kortet »Password policy« gælder for hver adgangskode, der bliver sat i systemet. Den bliver håndhævet, når en konto bliver oprettet, når en person ændrer sin egen adgangskode, og når en administrator nulstiller en.

Du sætter mindstelængden, hvilke slags tegn der skal optræde, efter hvor mange dage en adgangskode udløber, og hvor mange gamle adgangskoder der forbliver spærret. For dagene og spærrelisten betyder 0 »fra«.

Reglerne om store og små bogstaver lukker ingen sprog ude. Mange skriftsystemer har slet ikke den forskel, og et tegn fra et af dem opfylder begge regler helt alene.

Konti, der kun logger ind gennem SSO eller et katalog, har ingen lokal adgangskode, så udløb gælder ikke for dem. Deres regler bor hos udbyderen. Er en eksisterende konto blevet knyttet til SSO og har den stadig sin egen adgangskode, gælder udløbet og adgangskodepolitikken fortsat for den adgangskode.

Kortet »2FA Settings« bestemmer, hvem der skal bruge tofaktorlogin. Under »Two-factor requirement« vælger du et af fire niveauer: »Off«, »Administrators only«, »Administrators and agents« eller »Everyone«. »Everyone« omfatter også kunderne. En ny installation starter med »Administrators only«. En installation, der fandtes i forvejen, beholder sin hidtidige indstilling efter en opdatering.

Den, der logger ind næste gang uden en anden faktor, sætter en op. Systemet viser en QR-kode til en godkendelsesapp og den samme nøgle til at taste ind i hånden. Efter den første kode er faktoren aktiv. Med »Set up later« kan opsætningen udskydes, og login fortsætter uden den. Det går i højst 7 dage, regnet fra første gang den blev udskudt. Linjen under knappen viser de resterende dage. Derefter er opsætningen påkrævet.

Lige derefter dukker ti gendannelseskoder op. Hver af dem erstatter koden fra appen én gang. De bliver vist præcis én gang. Du gemmer dem med »Copy« eller »Download«. »Download« virker altid. »Copy« virker for det meste også.

Mister nogen sin enhed og sine koder, hjælper administratoren. I brugerlisten nulstiller knappen med det overstregede skjold den persons tofaktorlogin. Hun sætter den op igen ved næste login.

Koderne afhænger af serverens ur. Går det forkert, bliver ingen kode accepteret. Knappen »Check now« på det samme kort holder servertiden op mod en offentlig tidskilde.

Logger nogen ind gennem en ekstern logintjeneste, spørger systemet ikke om en kode. Udbyderen har allerede kontrolleret den anden faktor. Katalogindlogning er anderledes: der gælder reglen ovenfor stadig.

Enhver bruger kan slå tofaktorlogin til for sin egen konto. Det gælder for alle roller, også når kortet »2FA Settings« ikke kræver det. Åbn brugermenuen nederst til venstre i sidemenuen, og vælg »Profile picture«. Samme side indeholder området »Two-factor authentication«.

Området viser, om tofaktorlogin er slået til. Så længe det er slået fra, står knappen »Turn on« der. Den spørger først om din adgangskode. Derefter vises en QR-kode til godkendelsesappen og den samme nøgle til at taste ind i hånden. Efter den første kode fra appen er faktoren aktiv.

Lige derefter dukker ti gendannelseskoder op. Gem dem med »Copy« eller »Download«. »I have saved my codes« lukker listen. Den vises kun denne ene gang.

Så længe tofaktorlogin er slået til, viser området, hvor mange gendannelseskoder der er tilbage. »New recovery codes« laver ti nye. De gamle koder virker så ikke længere. »Turn off« slår tofaktorlogin fra igen. Begge knapper kræver den aktuelle kode fra appen. En gendannelseskode bliver ikke godtaget der.

Kræver kortet »2FA Settings« tofaktorlogin for din rolle, mangler »Turn off«. En linje i området siger det.

En forkert adgangskode eller en forkert kode tæller som et mislykket login. Beskyttelsen mod gætning af adgangskoder gælder altså også her. At slå til og fra bliver registreret i sikkerhedsloggen. Slår en administrator sit eget tofaktorlogin fra, giver loggen en alarm.

Konti, der kun logger ind via en ekstern logintjeneste, ser en sætning i stedet for knapperne. Deres udbyder håndterer den anden faktor. Konti fra et katalog indtaster i første trin deres adgangskode fra kataloget.

Beskyttelsen kører uden nogen indstilling. Der er intet at slå til. Bemærkningen om den står i kortet »2FA Settings«.

Den virker i to trin. Efter fem mislykkede forsøg på den samme konto bliver den adresse, de kom fra, sat på pause. Pausen slutter senest 15 minutter efter det første af de forsøg. Fra hver anden adresse kan kontoen bruges med det samme.

Det er den vigtige del. Ellers kunne enhver, der kender et loginnavn, låse en kollega ude med fem forkerte adgangskoder. Hun ville aldrig behøve en adgangskode til det.

Det andet trin er kontoen selv. Den bliver låst i 15 minutter efter 20 mislykkede forsøg. Fordi en enkelt adresse højst kan bidrage med fem af dem, kræver det flere adresser.

Et vellykket login nulstiller begge tællere. Efter en genstart af serveren er pausen på adressen væk, låsningen af kontoen bliver stående. De samme tællere gælder for login gennem et katalog. Et katalog, der ikke kan nås, tæller ikke som et mislykket forsøg. Findes der endnu ingen konto til navnet i ticketsystemet, gælder kun pausen på adressen.

I brugerlisten bærer en konto, der er låst på den måde, mærkningen »temporarily locked«. Den bliver stående i listen. Efter 15 minutter forsvinder mærkningen af sig selv.

Du behøver ikke at vente. I den samme række er der en knap med en åben hængelås. Den ophæver låsningen med det samme og rydder begge tællere.

Det er ikke det samme som »Archive«. Den knap lukker en konto ned for altid, og kun den optager eller frigiver en medarbejderplads.

Sikkerhedsloggen registrerer to slags hændelser. Området »Sign-in« indeholder mislykkede login, låste konti, loginforsøg under en lås, afviste tofaktorkoder og ændringer af adgangskoder. Det gælder for login med adgangskode, via et katalog og via SSO.

Området »Administration« viser, hvem der har ændret hvad. Det omfatter konti, roller, rettigheder, sikkerhedsindstillinger og arkiver. Hver eksport af loggen står der også.

Vellykkede login registreres kun i to tilfælde. Det første tilfælde er en administrator. Det andet tilfælde er et login efter mislykkede forsøg på den samme konto. Det almindelige login for en medarbejder eller en kunde står ikke i loggen. Loggen er ingen fremmødeliste.

Logger nogen ind med et navn, der ikke findes, står der »unknown account« i posten. Systemet gemmer ikke det indtastede navn. Nogle gange er det en adgangskode, der er havnet i det forkerte felt.

Loginhændelser gemmer IP-adressen og browseren. Administratorhandlinger gemmer, hvem der udførte dem, men ingen IP-adresse. Adgangskoder, koder og indholdet af sager eller e-mails står aldrig i loggen.

Siden viser de nyeste poster først, 50 pr. side. Kortet »Filters« indsnævrer listen. »Area« vælger login eller administration, »Event« en enkelt slags hændelse. »Person« søger i navnet på den, der handlede, og den, der var berørt. »From« og »To« begrænser dagene. »Failures only« skjuler alt, der lykkedes.

Filtrene virker først efter et klik på »Apply«. »Reset« fjerner dem igen.

»Export CSV« og »Export PDF« downloader præcis det, filtrene viser. Hver fil indeholder højst 10.000 poster. Passer flere poster til filtrene, siger en bemærkning ved eksportknapperne det. PDF-filen er på dit sprog og nævner øverst filtre og periode. Dato og klokkeslæt følger formatet, der er indstillet under »Settings → General Settings«.

CSV-filen forbliver altid på engelsk, og tiderne står i UTC. Så kan et program læse den uafhængigt af sproget. Hver eksport står selv i loggen som »Security log exported«.

Seks hændelser udløser en alarm. Det er en konto, der er låst efter mislykkede forsøg, en rolle, der er ændret til »Admin«, en konto, der er oprettet direkte med rollen »Admin«, og et nulstillet tofaktorlogin for en administrator. Dertil kommer arkiverede sager, der er fjernet fra de løbende data, og en administrators login efter mislykkede forsøg.

Efter en alarm ser alle med rettigheden et gult banner øverst på hver side. Det nævner antallet af alarmer siden deres sidste besøg i loggen. Linket »Open security log« fører derhen. Når loggen åbnes, forsvinder banneret. Før det første besøg tæller det alarmerne fra de sidste syv dage.

Derudover får hver aktiv konto med rettigheden og en e-mailadresse en alarmmail. Systemet samler alarmerne hvert 15. minut og sender én mail pr. person, ikke én pr. hændelse. Mailen nævner hændelsen, den berørte person og tidspunktet. Den indeholder ingen IP-adresse. Alarmmailen hører til Professional.

Den natlige kørsel sletter gamle poster. Fristerne findes under »Settings → Security« i kortet »Data protection« i blokken »Security log retention«. Loginhændelser bliver som standard gemt i 90 dage, 7 til 365 dage er tilladt. Administratorhandlinger bliver som standard gemt i 12 måneder, 1 til 120 måneder er tilladt.

Hver frist har sin egen kontakt: »Delete old sign-in events« og »Delete old administrator actions«. Er en kontakt slået fra, bliver de poster stående. Kortet »Opbevaringsfrister« forklarer den natlige kørsel.

Ved en dataindsigt får personen hver post, hvor vedkommende har handlet eller været berørt. IP-adresse og browser kommer kun med i poster, som personen selv har udløst, for eksempel sit eget login. Bliver personen anonymiseret, sletter systemet vedkommendes loginhændelser. Vedkommendes administratorhandlinger bliver stående. Navnet bliver der erstattet af pladsholderen.

En bemærkning til dig som driftsansvarlig: vellykkede login står kun i loggen for administratorer og efter mislykkede forsøg. Loggen viser alligevel, hvem der gjorde hvad og hvornår. I en virksomhed med medarbejderrepræsentation er den derfor et emne for medbestemmelse.

Allerøverst sidder hovedkontakten »Enable single sign-on«. Så længe den er slået fra, bliver det ved brugernavn og adgangskode. Alt, hvad du sætter op nedenunder, bliver gemt og træder først i kraft, når du slår den til.

Kortet »Active Directory / LDAP« tilslutter et katalog i huset. Du indtaster serveren, søgegrundlaget, det filter der finder en person, og felterne til e-mailadressen og navnene.

Kontoen, der bruges til opslag, er valgfri. Uden den spørger systemet anonymt. En persons adgangskode bliver kun brugt til at binde mod kataloget og bliver aldrig gemt.

Et katalog bringer ingen anden faktor med sig. Kræver sikkerhedssiden tofaktorlogin, bliver disse mennesker også spurgt om det.

Kortet »Identity providers« rummer de eksterne logintjenester. Hver får sin egen flade og sin egen knap på loginsiden. »Add provider« opretter en ny.

Under »Provider type« vælger du 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 huse, når de skal tilsluttes over SAML.

Ved siden af dem står seks regionale tjenester: LINE, Kakao, Naver, WeChat, WeCom og DingTalk. Deres adresser er udfyldt på forhånd og står som grå tekst i feltet.

Navnet under »Display name« står senere på knappen. Kontakten ved siden af gælder kun denne ene udbyder.

Til callback-adressen skal du arbejde i denne rækkefølge. Indtast først kun et navn, og klik på »Save provider«. Først da kender systemet udbyderens nummer og viser den færdige adresse under »Redirect URI«. Den bliver bygget af denne installations offentlige adresse, den der er gemt under »Settings → Security«. Det er præcis den adresse, systemet bruger, når nogen logger ind.

Den adresse kopierer du og registrerer den hos udbyderen. Den skal stemme tegn for tegn der. Til gengæld giver udbyderen dig et id og en hemmelighed, og dem indtaster du her via »Edit«.

Feltet »Allowed e-mail domains« begrænser, hvem der må komme ind gennem denne udbyder. Lades det tomt, er hvert domæne tilladt.

Mangler en udbyder stadig noget, bærer dens flade den røde mærkning »Incomplete«. Så står den ikke på loginsiden. Teksten ved siden af siger, hvilke felter dens type kræver.

Fuldt opsatte udbydere står stadig ikke der, så længe hovedkontakten er slået fra. Fladen siger det i en gul linje.

Falder din licens tilbage til Basic, bliver login gennem SSO og kataloget ved med at virke. På denne side kan du så kun slå udbydere og kataloget fra. Loggen over loginforsøg kan stadig læses.

Kontakten »Automatically create accounts on first sign-in« sidder i det samme kort som hovedkontakten. Den er slået til som udgangspunkt.

Når nogen logger ind gennem en udbyder for første gang, leder systemet først efter en konto, der allerede hører til den udbyder. Finder det ingen, bliver der oprettet en ny.

Den nye konto får rollen »Customer« og intet team. En kunde behøver intet medlemskab for at oprette en sag og kan derfor gå i gang med det samme.

Kunder er ubegrænsede i begge udgaver, så en konto, der er oprettet på den måde, bruger ingen medarbejderplads. Den, der skal blive agent, får rollen bagefter i brugeradministrationen.

Findes der allerede en konto med den samme e-mailadresse, bliver de to knyttet sammen. Det sker kun, når udbyderen melder adressen som bekræftet. Gør den ikke, bliver login afvist.

Slår du den fra, kommer kun folk ind, der allerede har en konto. Alle andre bliver afvist.

Kortet »Recent sign-in attempts« helt nederst viser de sidste 100 loginhændelser via SSO og kataloget. De kommer fra sikkerhedsloggen. Mislykkede forsøg står der altid. Et vellykket login står der kun for administratorer og efter mislykkede forsøg på den samme konto. Derfor står ikke alle login på listen.

Hver række nævner tidspunktet, udbyderen, resultatet og kildeadressen. Ved et mislykket forsøg står grunden ved siden af. Kolonnen »User« viser kontoens navn. Findes der ingen konto, viser den adressen, som udbyderen har meldt, ellers »unknown account«. Systemet gemmer ikke det indtastede navn.

Login med brugernavn og adgangskode står ikke i denne tabel. Det er ikke SSO. Du finder det i sikkerhedsloggen.

Som standard bliver posterne slettet efter 90 dage. Sætningen under kortets titel nævner den indstillede frist. Kortet »Opbevaringsfrister« forklarer indstillingen.

Efter installationen bruger dit team systemet i enhver webbrowser. Installationsprogrammet spørger, hvordan systemet skal kunne nås. I Windows-installationsprogrammet vælger du det på siden »Tilgængelighed«. På Linux stiller install.sh det samme spørgsmål og nummererer valgmulighederne fra 1 til 5. Senere ændrer du det med »Ændr hvordan SMITEY nås«. Dine data bliver, hvor de er.

Valgmuligheden »Kun det lokale netværk, via IP-adressen (HTTP) - den enkleste mulighed« er standardindstillingen. Dit team åbner systemet på http:// efterfulgt af serverens IP-adresse og porten, for eksempel http://192.168.1.20:8088. Porten er 8088, medmindre du vælger en anden. Port 80 virker også. Så behøver adressen ingen port. Denne valgmulighed kræver hverken navn eller certifikat.

Valgmuligheden »I det lokale netværk under sit eget navn (HTTP, HTTPS muligt senere) - du har intern DNS« virker som den første, men under et navn som ticket.company.local. Navnet opretter du selv i din interne DNS. Det peger på serverens IP-adresse. Så når dit team systemet under navnet og stadig også via IP-adressen. Installationsprogrammet viser derefter adressen med dette navn.

Ved begge HTTP-valgmuligheder går adgangskoder og sager gennem dit netværk som klartekst. Administratorer ser så en besked øverst på siden.

De tre andre valgmuligheder bruger HTTPS: »Via et offentligt domæne med HTTPS (automatisk, med Let's Encrypt)«, »I det lokale netværk med HTTPS og dit eget certifikat« og »I det lokale netværk med HTTPS, certifikat oprettet af SMITEY«. De kræver portene 80 og 443 på serveren. Det næste kort beskriver dem.

Til en første test er den første valgmulighed nok. Har dit netværk intern DNS, så vælg den anden. Skal systemet kunne nås fra internettet, så vælg det offentlige domæne. Har din virksomhed sin egen CA, så vælg dit eget certifikat i det lokale netværk. Ellers lader du SMITEY oprette certifikatet.

Uden HTTPS går adgangskoder og sager gennem dit netværk som klartekst. En ny installation starter med almindelig HTTP, så den virker med det samme i enhver webbrowser. Så længe en administrator åbner systemet over almindelig HTTP, vises en besked øverst på siden: »This connection is not encrypted.« Åbnes systemet på selve serveren under »localhost«, vises beskeden ikke. Agenter og kunder ser den aldrig.

»How to switch on HTTPS« fører til dette kort. »Hide for 30 days« skjuler beskeden for dig. Indstillingen hører til din konto og gælder derfor også i en anden browser. Efter 30 dage kommer beskeden igen, så længe forbindelsen stadig ikke er krypteret.

SMITEY-installationsprogrammet sætter HTTPS op på tre måder. I Windows-installationsprogrammet vælger du på siden »Tilgængelighed«, og på Linux stiller install.sh det samme spørgsmål. På et system, der allerede kører, åbner du »Ændr hvordan SMITEY nås« på Windows-skrivebordet eller i startmenuen. På Linux gør kommandoen nedenfor det samme. Dine data bliver, hvor de er.

Valgmuligheden »I det lokale netværk med HTTPS og dit eget certifikat« bruger dit eget certifikat, for eksempel fra din virksomheds CA. Installationsprogrammet spørger efter systemets navn og certifikatfilen med dens nøgle. En PFX-fil med dens adgangskode virker også. Før det ændrer noget, kontrollerer det certifikatet. Nøglen skal passe, certifikatet skal være gyldigt, og navnet skal stå i certifikatet.

Valgmuligheden »I det lokale netværk med HTTPS, certifikat oprettet af SMITEY« kræver intet eget certifikat. SMITEY laver selv et og fornyer det også selv. Installationsprogrammet gemmer rodcertifikatet som SMITEY-root-ca.crt i installationsmappen. Installér filen på hver computer som et betroet rodcertifikat, for eksempel med en gruppepolitik. Indtil da viser browserne en advarsel.

Valgmuligheden »Via et offentligt domæne med HTTPS (automatisk, med Let's Encrypt)« henter sit certifikat fra Let’s Encrypt. Den kræver et offentligt domæne, der peger på serveren. Serveren skal derfor kunne nås fra internettet.

Ved begge valgmuligheder i det lokale netværk kan navnet være et navn som ticket.company.local, et enkelt ord som helpdesk eller en IPv4-adresse. Alle tre veje kræver portene 80 og 443 på serveren. Bruger et andet program dem, stopper installationsprogrammet og ændrer intet. Systemet nås derefter på https:// efterfulgt af navnet, uden port.

Dit eget certifikat udløber på et tidspunkt. Fra 30 dage før ser administratorer øverst på siden en besked med datoen. Fra 7 dage før er den rød. I Professional får alle administratorer med en e-mailadresse desuden en mail 30 og 7 dage før. For at forny åbner du igen »Ændr hvordan SMITEY nås«, vælger muligheden med dit eget certifikat og angiver de nye filer.

Filen HTTPS-GUIDE.txt, der følger med installationen, beskriver hvert trin. Det omfatter fordelingen af rodcertifikatet og trinene i hånden.