OS2sofd

- Om OS2sofd: https://www.sofd.io/
- Brugervejledning: https://www.sofd.io/brugervejledning/
- Arkitektur: https://www.sofd.io/arkitektur/
- Implementeringsdrejebøger: https://www.sofd.io/implementation-guides/
- Drejebog: OPUS-kommune: https://www.sofd.io/implementation-guides/opus-loen-integration/
- Drejebog: SD-kommune: https://www.sofd.io/implementation-guides/sd-loen-integration/
- Brugerstyring: https://www.sofd.io/idm/
- Forudsætninger og forberedelse: https://www.sofd.io/idm/prerequisites/
- Processer og hændelser: https://www.sofd.io/idm/processes/
- Personinaktivering: https://www.sofd.io/idm/person-inactivation/
- Konfiguration: https://www.sofd.io/idm/configuration/
- Login og SAML: https://www.sofd.io/login/
- API: https://www.sofd.io/api/
- OData (læsning): https://www.sofd.io/api/odata/
- REST-API: https://www.sofd.io/api/rest/
- Fremtidig API-udvikling: https://www.sofd.io/api/strategi/
- Integrationer: https://www.sofd.io/integrationer/
- On-premise agenter: https://www.sofd.io/agents/
- Brugerkonto Agent: https://www.sofd.io/agents/user-account-agent/
- AD Writeback Agent: https://www.sofd.io/agents/ad-writeback-agent/
- AD Replikator Agent: https://www.sofd.io/agents/ad-replikator/
- AD indlæsningsintegration: https://www.sofd.io/agents/ad-indlaesningsintegration/
- OPUS indlæsningsintegration: https://www.sofd.io/agents/opus-indlaesningsintegration/
- Indlæsning af skoleelever: https://www.sofd.io/agents/skoleelev-indlaesning/
- OS2vikar - Brugerkonto Agent: https://www.sofd.io/agents/os2vikar-agent/
- Download: https://www.sofd.io/downloads/
- Ændringslog: https://www.sofd.io/changelog/
- Support og kontakt: https://www.sofd.io/support/


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

{{< mermaid >}}
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
{{< /mermaid >}}

1. **Opret:** kontoen oprettes et antal dage før ansættelsesstart. Kontoen kan
   oprettes i **deaktiveret tilstand** ("Opret som deaktiveret"). Det gælder AD-konti.
2. **Reaktiver (aktivér):** kontoen aktiveres kort før ansættelsesstart, fx dagen
   før ("dage før reaktivering").
3. Kontoen er aktiv i ansættelsen.
4. **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](../configuration/)).

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

1. **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.
2. **Filtrering.** Kun tilknytninger fra de konfigurerede masters indgår, og kun
   hvis reglerne for den organisatoriske enhed siger at kontotypen skal dannes.
3. **Godkendelse.** Hvis godkendelse er slået til, sættes ordren til *afventer
   godkendelse*, indtil en leder godkender den.
4. **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.
5. **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.