Innhold
1 Overordna
Formålet med ansattautomatikken er å gje IT-tilgang raskare til ansatte, og redusere belastinga på IT-personell.
Målet med ansattautomatikken er å automatisk opprette ein fungerande brukarkonto til alle som skal vere aktive ut frå HR-systemet.
Merk at dette er ein første versjon av ansattautomatikk, der vi får litt erfaringar. Detaljar vil kunne endre seg ved neste implementasjon.
1.1 Prosess
Overordna prosess for nye ansatte (utheva tekst er kva ansattautomatikken gjer):
- HR registrerer personen, til dømes etter signert kontrakt.
- Cerebrum henter personopplysingar frå HR.
- Cerebrum oppretter ein brukarkonto for den ansatte (tidlegare gjort av IT-personell).
- Cerebrum køyrer anna automatikk for brukarkontoen, blant anna for gruppeinnmelding og provisjonering til AD og LDAP (Feide).
- Cerebrum sender velkomst-SMS til den ansatte sitt registrerte mobilnummer.
- Den ansatte går til nettsida for å sette seg eit passord. Brukarkontoen er no klar til bruk.
- Ved behov: IT-personell legg til ekstra tilgangar og andre innstillingar, der standard oppsett ikkje er nok.
Brukarkontoen kan bli automatisk avvikla når den ansatte slutter, dersom instansen har satt dette opp. Sjå Automatikk for sperring av brukere uten persontilknytninger for detaljar om dette.
2 Kriterier
Funksjonalitet automatikken må oppfylle:
- Kva person-tilknytting som styrer opprettinga, skal vere konfigurerbar. Til dømes ANSATT, og TILKNYTTET/gjesteforsker.
- Alle med ei gyldig person-tilknytting skal ha ein brukarkonto. Hvis ikkje, skal Cerebrum opprette, evt. gjenopprette, ein brukarkonto.
- Brukarnamn genererast utfrå instansen si definerte algoritme.
- Brukarkontoen skal få satt:
- Brukar-tilknyttingar, basert på personen sine tilknyttingar ved opprettingstidspunkt. Brukarkontoen får alle tilknyttingar som personen har. Dette for å unngå behovet for eit manuelt steg. Spesifikke typar tilknyttingar kan unntakast.
- Standard spreads, ut frå konfigurasjon.
- Standard POSIX-data, ut frå konfigurasjon. Alle brukarkontoar får i første omgang berre ein definert disk-path, og ei standard filgrupppe (GID).
- Heimeområde. I første omgang støttast berre ein disk-path, tilknytta eitt spread, der alle brukarkontoane må plasserast.
- Den ansatte skal få ein velkomst-SMS om den oppretta brukarkontoen, på definerte tidspunkt.
- Passord settast ikkje. Den ansatte set det sjølv online. Ved behov kan IT-personell generere passord og skrive ut passordbrev i etterkant.
- Dagleg logg, kopiert over til instansen sitt miljø. I første omgang applikasjonsloggen.
- Gjenoppretting av tidlegare brukarkontoar, der personen har ein avvikla
brukarkonto. Krav ved gjenoppretting:
- Den sist avvikla brukarkontoen bør bli gjenoppretta.
- Fjern expire_date.
- Fjern alle tidlegare brukar-tilknyttingar.
- Fjern alle tidlegare gruppemedlemskap.
- Fjern enkelte manuelt satte karantener, ut frå konfigurasjon.
- Fjern POSIX data, som UID, og evt. GID. Dette unngår gjenbruk av gamle IT-tilgangar.
- Sikre at gamalt passord ikkje kan brukast. Løysast til dømes ved å sette eit nytt, tilfeldig passord på brukaren.
2.1 Ønsker
Funksjonalitet som kan implementerast, hvis detaljar vert avklarde og utviklarane har tid, men som ikkje er eit krav i første versjon:
- Bedre rapportering, enn å overføre logg til instansen. Treng å finne ut kva behovet er.
- Mulighet for å slå av gjenopprettinga. Person utan aktiv brukarkonto vil då få oppretta ny brukarkonto, sjølv om det finnast avvikla.
2.2 Tekniske kommentarar
- Vi anser ein brukarkonto som aktiv så lenge expire_date ikkje er satt eller er passert, og uavhengig om brukarkontoen har spreads.
- I første omgang ser vi for oss å køyre opprettinga batch-vis, til dømes rett etter SAP-importen. På sikt vil dette kunne bli endra.
- Utsending av SMS kan gjerast som for studentar, med eit trait, som ein eigen jobb sender ut på eit gitt tidspunkt. Utviklar kan likevel velge annan intern oppførsel av dette under implementering, så lenge krava over vert oppfylde.
- Merk at brukar-tilknyttingar berre vert oppdatert når brukaren opprettast. Seinare endringar i person-tilknyttingane påvirker ikkje brukar-tilknyttingane, enn så lenge.
- Brukarkontoane vert etter oppretting handtert av annan automatikk. Til dømes vert e-postadresser satt automatisk basert på brukar-tilknyttingar, og person/brukarkonto kan bli med i automatiske grupper.
- TODO: HiØ legg til e-mail server name som argument til user_create, og er truleg som oftast epost.hiof.no? Kan dette automatiserast?
2.3 Manglar
Første versjon av ansattautomatikken vil i utgangspunktet ikkje dekke:
- Brukar-tilknyttingar vil ikkje bli automatisk oppdatert når person-tilknyttingar endrer seg. Dette betyr til dømes at ansatte som bytter enhet ikkje nødvendigvis vil få oppdaterte til dømes primær e-postadresse. Dette må enn så lenge handterast manuelt, som i dag.
- Ein ny ansatt som allereie har andre brukarkontoar, til dømes ein studentbrukar, må handterast manuelt. Dette sidan det er mange unntak for kva som skal skje, spesielt ved UiO. Automatikken handterer i første omgang berre alle ansatte utan aktiv brukarkonto.
- Heimeområder må plasserast på samme stad. Vi er usikre på korleis implementere og handtere oppslag frå td. OU til path, mest grunna UiO si granulering.
- Andre spesialtilpassingar må leggast til manuelt i etterkant av instansen, til dømes spreads og grupper som berre enkelte skal ha.
3 Konfigurasjon
Oppsummering av kva som ser ut til å måtte kunne vere konfigurerbart per instans:
- Kva person-tilknyttingar og -statustypar som skal kvalifisere for brukarkonto. Til dømes ANSATT og TILKNYTTET/gjesteforsker.
- Kva spreads nye brukarkontoar skal få. Oversikt over instansane:
- UiA: account@nis og account@ad, acc@office365 og account@radiusan.
- UiO: AD_account, NIS_user@uio og exchange_acc@uio?
- HiØ: account@ad? (Spread sendast berre som argument til user_create) TODO: også account@imap, men usikker om dette settast automatisk.
- NIH: account@ad, account@exchange
- NMH: account@ad.
- POSIX-innstillingar: shell, gecos, GID
- UiA: bash, Null, gruppa ansatt
- Heimeområde:
- UiA: /hia/ravn/u4 for spread account@nis.
- Kva typar person-tilknyttingar som skal, eller skal ikkje, kopierast over på brukarkontoen. Til dømes skal kanskje ikkje MANUELL leggast på brukarkontoar automatisk.
- Innhaldet i velkomst-SMS, til dømes: «Velkommen til <INSTANS>. Gå til passord.<INSTANS>.no for å sette passord og komme i gang!».
- Tidspunkt for å køyre opprettinga: Rett etter SAP-importen, men ikkje samtidig med studentautomatikken.
- Tidspunkt for å sende ut velkomst-SMS.
- Kor instansen skal få tilsendt loggen frå opprettinga.
- Ved gjenoppretting: Manuelle karantener som skal kunne fjernast frå brukarkontoen, til dømes generell. Automatiske karantener bør ikkje fjernast, sidan dei skal fjernast av automatikken som la dei på.