IdM i OS2sofd er bygget op om kontoordrer. En ordre beskriver en handling (opret, deaktiver, slet med videre) for en bestemt person og en bestemt kontotype. OS2sofd danner ordrerne automatisk ud fra personens tilknytninger og reglerne, og en on-premise agent udfører dem og melder status tilbage.
Kontoens livscyklus#
flowchart LR
C["Opret<br/>(deaktiveret)"] --> RA["Reaktiver<br/>(aktivér)"]
RA --> AKTIV[Aktiv]
AKTIV --> DE[Deaktiver]
DE --> OP[Oprydning]
OP --> SL[Slet]
DE -. "ny stilling" .-> RA
OP -. "ny stilling" .-> RA
- Opret: kontoen oprettes et antal dage før ansættelsesstart. Kontoen kan oprettes i deaktiveret tilstand (“Opret som deaktiveret”). Det gælder AD-konti.
- Reaktiver (aktivér): kontoen aktiveres kort før ansættelsesstart, fx dagen før (“dage før reaktivering”).
- Kontoen er aktiv i ansættelsen.
- Ved fratrædelse sker følgende, i denne rækkefølge og hver for sig valgfri: Deaktiver → Oprydning → Slet. Hvert trin tidsstyres af sit eget dage-tal regnet fra fratrædelsen (se Konfiguration).
Så længe kontoen ikke er slettet (uanset om den er deaktiveret eller ryddet op), kan den reaktiveres, hvis personen får en ny stilling.
En AD-konto er markeret som intern eller ekstern alt efter den tilknytning, der oprettede den. En deaktiveret konto genaktiveres kun til en tilknytning af samme type: vender en tidligere fastansat fx tilbage i en ekstern rolle, oprettes en ny konto i stedet for at genbruge den interne. Markeringen kan ses og rettes i administrationsgrænsefladen.
Antal konti pr. person#
I langt de fleste opsætninger får en person én konto pr. kontotype på tværs af alle sine tilknytninger. Det er den almindelige måde at køre OS2sofd på. Alternativt kan en kontotype sættes til én konto pr. tilknytning, så en person med flere tilknytninger får en konto af samme type for hver.
Medarbejder- og eksterne tilknytninger behandles hver for sig, så en person med begge dele kan få en konto for hver.
Ordretyper#
| Type | Hvornår | Hvad |
|---|---|---|
| Opret | “Dage før oprettelse” før ansættelsesstart | Danner en ny konto (AD-konti kan oprettes i deaktiveret tilstand). Findes kontoen allerede, fejler ordren, og Reaktiver bruges i stedet. Brugernavnet genereres her. |
| Reaktiver | Kort før ansættelsesstart (“dage før reaktivering”), eller når en deaktiveret konto skal i brug igen | Aktiverer en (deaktiveret) konto og genbruger det eksisterende brugernavn. |
| Deaktiver | “Dage til deaktivering” efter fratrædelse | Spærrer kontoen uden at slette den. |
| Oprydning | “Dage til oprydning” efter fratrædelse | Oprydning af AD/Exchange-kontoen. Dannes når deaktiveringen er gennemført. |
| Slet | “Dage til sletning” efter fratrædelse | Sletter kontoen. |
| Udløb | Når en pausemarkering oprettes med valget om at udløbe konti | Sætter en udløbsdato på personens aktive AD-konti i pauseperioden. Én ordre pr. aktiv AD-konto. |
Statusser#
En ordre har altid en status. Den fortæller om ordren afventer, er gennemført, eller er stoppet.
| Status | Betydning |
|---|---|
| Afventer | Ordren er dannet og venter på at blive udført. |
| Afventer godkendelse | Ordren venter på en leders godkendelse. |
| Blokeret | Ordren er sat på hold (fx fordi en forudsætning ikke er opfyldt). |
| Gennemført (oprettet, reaktiveret, deaktiveret, slettet, ryddet op, udløbet) | Handlingen er udført af agenten. |
| Fejlet | Udførelsen mislykkedes. |
Sådan dannes og udføres ordrer#
- Dannelse. En planlagt natlig kørsel gennemgår personer og tilknytninger og danner de ordrer der mangler. Ordrer kan også udløses løbende når tilknytninger ændrer sig, og kan dannes manuelt via API’et. Er en ansættelse kendt i god tid, kan ordren dannes og vises som planlagt allerede ved registreringen, så den kan godkendes og suppleres i god tid før aktiveringen. Lederen notificeres i så fald én gang.
- Filtrering. Kun tilknytninger fra de konfigurerede masters indgår, og kun hvis reglerne for den organisatoriske enhed siger at kontotypen skal dannes.
- Godkendelse. Hvis godkendelse er slået til, sættes ordren til afventer godkendelse, indtil en leder godkender den.
- Udførelse. Den on-premise agent henter de afventende ordrer via API’et, udfører handlingen i det lokale system (fx Active Directory) og melder status tilbage.
- Oprydning af køen. Færdigbehandlede ordrer bliver i køen et antal dage og fjernes derefter.
Som sikkerhedsforanstaltning kan der sættes tærskler, så API’et nægter at udlevere ordrer hvis der pludselig dannes unormalt mange af en type.
Varianter og specialflows#
Afhængige kontotyper#
En kontotype kan afhænge af en anden. Så dannes ordren først, når den kontotype den afhænger af, er på plads (fx Exchange efter Active Directory).
OPUS-integration#
OPUS-konti håndteres særskilt: OS2sofd kalder OPUS-tjenesten og opretter eller opdaterer it-brugeren. E-mailadressen kan om nødvendigt opdateres i OPUS uafhængigt af resten af IdM-flowet.
Udløb (pausemarkering)#
Når en person får en pausemarkering i OS2sofd (som kan være af typen orlov), kan man vælge at lade personens konti udløbe i perioden. Det er valgfrit: udløbsordrer dannes kun, hvis pausemarkeringen oprettes med dette valg.
Vælges det, dannes en udløbs-ordre for hver af personens aktive AD-konti. Ordren bærer pausemarkeringens årsag samt udløbs- og slutdato, så agenten kan sætte en udløbsdato på AD-kontoen for perioden. En pausemarkering kan desuden sættes til at blokere nye konto-ordrer i perioden.
Fejlsøgning#
- Ordren blev ikke dannet: tjek at tilknytningens master er blandt de
konfigurerede masters, at enhedens regel ikke er
DISABLED, og at kontotypen kan bestilles. - Ordren står som afventer godkendelse: en leder mangler at godkende.
- Ordren er blokeret: en forudsætning mangler (fx en afhængig kontotype).
- Ordren er fejlet: udførelsen i det lokale system mislykkedes. Se agentens logning.