DigitalForensics

70 13 63 23

Kalenderdata og mødeinvitationer teknisk

Kalenderdata og mødeinvitationer teknisk

Forside › E-mail forensics · Gennemgået oktober 2026 · Af John Nielsen

Bag visningen i Outlook eller Google Kalender ligger et objekt med felter, der kan analyseres hver for sig: UID eller det globale objekt-id, der binder kopierne hos arrangør og deltagere sammen, SEQUENCE, der tæller arrangørens væsentlige ændringer, tidsstempler for dannelse, oprettelse og ændring, og en række iTIP-meddelelser (invitation, svar, aflysning), der hver er en selvstændig mail med egne headere. Den tekniske opgave er at samle de eksemplarer, koble dem på id’et og opstille en versionshistorik, der kan efterprøves. Resultatet beskriver planlægningen; afholdelse og fremmøde skal findes i andre kilder.

Hvordan kalenderen bruges og vurderes som bevis i en tvist, står for advokater i Kalenderen som bevis. Artiklen her handler om formater, felter, logs og fejlkilder.

iCalendar: det fælles format

Kalenderdata udveksles mellem systemer i formatet iCalendar (RFC 5545), typisk som ICS-filer eller som vedhæftning til en invitationsmail. En aftale er en VEVENT-komponent med blandt andet disse egenskaber:

  • UID · Unik id for aftalen, den samme hos arrangør og deltagere
  • SEQUENCE · Sekvensnummer, der øges, når arrangøren ændrer væsentlige forhold
  • DTSTAMP · Tidspunktet, hvor denne udgave af objektet blev dannet
  • CREATED og LAST-MODIFIED · Oprettelse og sidste ændring i kalenderen, hvis de er medtaget
  • DTSTART og DTEND · Start og slut, med eller uden tidszone
  • ORGANIZER og ATTENDEE · Arrangør og deltagere, for deltagere med svarstatus
  • RRULE, EXDATE og RECURRENCE-ID · Gentagelsesregel, undtagelser og ændrede forekomster

Invitationer sendes med en metode: REQUEST for en invitation eller opdatering, REPLY for et svar, CANCEL for en aflysning og COUNTER for et forslag til nyt tidspunkt. Hver af dem er en mail med en ICS-del, og mailene er selvstændige spor med egne headere og transporthændelser.

Exchange og Microsoft 365

I Exchange er en aftale et emne i postkassens kalendermappe med MAPI-egenskaber, der svarer til iCalendar-felterne, men med flere detaljer. Det vigtigste for en undersøgelse:

  • Det globale objekt-id kobler arrangørens aftale med hver deltagers kopi. Det er nøglen til at finde samme møde i flere postkasser.
  • Mødeanmodninger, svar og aflysninger ligger som særlige mailemner i indbakker og Sendt post. Selv om aftalen er slettet fra kalenderen, kan invitationen ligge tilbage i indbakken eller i Slettet post.
  • Arrangørens svarsporing registrerer deltagernes svar og tidspunktet for dem på arrangørens eksemplar.
  • Oprettelses- og ændringstid på emnet viser, hvornår aftalen kom ind i den enkelte kalender, og hvornår den sidst blev ændret.
  • Stedfortrædere. En assistent med rettigheder kan oprette og svare på vegne af en anden. Det fremgår af egenskaberne og af invitationens afsenderfelter.

Exchange Online fører desuden kalenderdiagnostiske logs, som administratorer kan hente med PowerShell-kommandoen Get-CalendarDiagnosticObjects. De kan vise de versioner, et emne har haft, handlingen, tidspunktet og i feltet ClientInfoString, hvilken klient eller tjeneste der foretog ændringen. Hvor langt tilbage loggene rækker, er ikke fast beskrevet, så de bør hentes tidligt.

Slettede kalenderemner følger samme vej som mails: Slettet post og derefter postkassens gendannelsesmapper; se Exchange Online: Recoverable Items. Auditloggen kan supplere med handlinger på kalenderen, hvis logningen dækker dem; se Unified Audit Log.

Google Kalender

Google Kalender bruger iCalendar-modellen med egne id’er. Workspace-administratorer har en auditlog for kalenderhændelser, der kan vise oprettelse, ændring, sletning og ændringer af deltagere. Loggen er tilgængelig i 6 måneder og kan ikke forlænges, så den skal eksporteres i tide. Vault kan bevare kalenderbegivenheder, søge på, hvordan en begivenhed så ud på en bestemt dato, og eksportere dem som ICS. En eksport via Takeout giver ICS-filer uden ændringshistorik.

Tidszoner og gentagelser

Kalenderdata er en af de kilder, hvor tidszoner oftest skaber forvirring:

  • En aftale kan være gemt i UTC, i en navngiven tidszone eller som såkaldt flydende tid uden zone, der vises ens uanset hvor brugeren befinder sig.
  • Gentagne møder er gemt som én regel med undtagelser. En ændret forekomst er et særskilt objekt med henvisning til den oprindelige dato. Udtræk, der folder reglen ud, kan give forskellige resultater i forskellige værktøjer.
  • Sommertid påvirker gentagne møder på tværs af tidszoner, og ældre tidszonedefinitioner i en aftale kan afvige fra de nuværende.

Konvertér altid til én referencetid i analysen og bevar den oprindelige angivelse. Se Sommertid og tidszoner i rapporten.

Typiske spørgsmål og hvor svaret ligger

  • Hvornår blev mødet planlagt? · Oprettelsestid hos arrangøren, første invitation i Sendt post og transportsporet
  • Blev deltageren inviteret? · Invitationen i deltagerens postkasse og transportsporet
  • Takkede deltageren ja? · Svarmailen i Sendt post hos deltageren og svarsporingen hos arrangøren
  • Er mødet flyttet eller ændret? · Sekvensnummer, opdateringsinvitationer og kalenderdiagnostik
  • Blev mødet aflyst? · Aflysningsmail og emnets status
  • Blev mødet holdt? · Ikke i kalenderen; se mødeplatformens logs og deltagerdata

For onlinemøder registrerer mødeplatformen deltagelse, tidspunkter og eventuelle optagelser, og det er her, faktisk deltagelse kan dokumenteres; se Teams teknisk.

Mødelokaler og ressourcer

I Exchange er mødelokaler, biler og udstyr ressourcepostkasser, hvor kalenderbehandlingen (Calendar Attendant og ressourcebookingens regler) accepterer eller afviser automatisk. Ressourcens eksemplar af mødet har samme globale objekt-id som arrangørens og kan derfor kobles direkte. Det har to tekniske fordele: kopien ligger i en postkasse, som deltagerne normalt ikke har skriveadgang til, og Get-CalendarDiagnosticObjects kan også køres mod ressourcen og vise dens versioner af mødet. Det automatiske svar fra ressourcen ligger som en REPLY i arrangørens postkasse med eget tidsstempel. Bookingpaneler ved lokalet kan have egne check-in-logs i en separat tjeneste, og de sikres som en selvstændig kilde, hvis de findes.

Delte kalendere og læseadgang

Rettighederne på kalendermappen afgør, hvilke konti der overhovedet kunne have ændret et emne. I Exchange hentes de aktuelle tilladelser med Get-MailboxFolderPermission på kalendermappen, og stedfortrædere fremgår af postkassens delegeringsindstillinger. Det giver kun nutidens billede, så ændringer i tilladelser i perioden skal findes i auditloggen. Kobl derefter ClientInfoString og den udførende konto fra kalenderdiagnostikken med listen over berettigede konti. En ændring fra en konto, der ikke havde skriverettighed, kræver en forklaring, fx en tjeneste eller en synkroniseringsklient. Bemærk også, at en kollegas visning af en privat aftale kun viser optaget tid, så en eksport fra en anden postkasse end ejerens kan mangle felter.

Sikring

  1. Eksportér arrangørens kalenderemne med alle egenskaber, helst som del af en postkasseeksport, ikke kun som ICS fra en klient.
  2. Eksportér deltagernes kopier og find dem via det globale objekt-id.
  3. Sikr invitationer, svar og aflysninger som mails med headere; se Mailformater i forensics.
  4. Hent kalenderdiagnostik og auditlog, hvis ændringshistorik er relevant.
  5. Beregn hashværdier og notér tidszone for hver kilde.

Faldgruber

  • En ICS-fil eksporteret fra en klient kan være dannet ved eksporten og have DTSTAMP fra eksporttidspunktet.
  • Mobilklienter og tredjepartsapps synkroniserer kalendere og kan ændre emner uden brugerens aktive handling.
  • Et møde, der står som accepteret, kan være accepteret automatisk af en regel eller en ressourcepostkasse.
  • Sletning hos en deltager påvirker ikke arrangørens eksemplar og omvendt, medmindre arrangøren aflyser.

Dokumentation

Rapporten bør for hvert møde indeholde en versionstabel: kilde (postkasse, ressource, mail eller diagnostik), id, SEQUENCE, tidsstempel i UTC, handling og udførende klient. Angiv, hvordan eksemplarerne er koblet, og hvilken tidszone hver kilde oprindeligt brugte. Verifikationen består i, at sekvensnumrene og iTIP-mailene stemmer overens: en opdatering med højere SEQUENCE bør have en tilsvarende REQUEST i Sendt post. Huller i den række beskrives som huller, ikke som ændringer. Fremmøde og afholdelse dokumenteres med mødeplatformens logs, adgangskort eller andre spor, ikke med kalenderobjektet.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: E-mail forensics

Læs også: Fejlsendt mail og fejldeling: dokumentation af omfang · Exchange Server lokalt og hybrid: logkilder

→ E-mail forensics · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik

John Nielsen, IT-sagkyndig

Brug for en forensisk undersøgelse?

Skriv kort, hvilke systemer eller enheder det drejer sig om, og om noget haster, så vender jeg tilbage. Kun civile sager.

Tak for din henvendelse. Jeg vender tilbage hurtigst muligt.