Forside › macOS- og Linux-forensik · Gennemgået oktober 2026 · Af John Nielsen
I et virtuelt skrivebordsmiljø (VDI) eller en publiceret Citrix- eller RDS-løsning arbejder brugeren på en maskine i datacentret eller skyen, ikke på sin egen computer. Ved ikke-persistente skriveborde nulstilles maskinen, når brugeren logger af, og de klassiske Windows-artefakter forsvinder med den. Sporene skal derfor findes andre steder: i brugerens profilcontainer, i logs på de servere, der formidler sessionerne, i sessionsværternes hændelseslogs og på den enhed, brugeren forbandt sig fra. Det kræver en kortlægning af arkitekturen, før noget slettes eller genstartes.
Arkitekturen i hovedtræk
Uanset produkt består miljøet typisk af de samme dele:
- Adgangslag: en portal eller gateway, som brugeren logger ind på, ofte med MFA. Her registreres login, kildeadresse og klientoplysninger.
- Broker eller controller: tildeler brugeren et skrivebord eller en applikation og fører historik over sessioner.
- Sessionsværter: de virtuelle maskiner, hvor sessionen kører. Enten én bruger pr. maskine (VDI) eller mange brugere på samme server (multisession).
- Profillager: brugerens profil som en container (en virtuel diskfil pr. bruger), som en roaming-profil eller som en profilstyring, der synkroniserer udvalgte mapper.
- Fildelinger og cloudtjenester: hvor brugerens dokumenter reelt ligger.
- Klientenheden: brugerens egen computer, tynde klient eller telefon med klientprogrammet.
Persistente og ikke-persistente skriveborde
På et persistent skrivebord beholder brugeren den samme virtuelle maskine, og den kan sikres som enhver anden virtuel maskine. → Virtuelle maskiner og servere: sikring uden nedetid
På et ikke-persistent skrivebord genskabes maskinen fra et fælles grundbillede ved logoff eller genstart. Ændringer i systemet, midlertidige filer, Prefetch, systemets hændelseslogs og lignende forsvinder. Kun det, der er gemt i profilcontaineren, på fildelinger eller i central logning, overlever. Er brugeren stadig logget ind, er den kørende session derfor en flygtig kilde, som skal sikres, før sessionen afsluttes.
Profilcontaineren
Profilcontainere er i dag den mest udbredte måde at bevare brugerprofilen i ikke-persistente miljøer. Containeren er en virtuel diskfil, der monteres ved login og indeholder brugerens profilmappe med NTUSER.DAT, programdata, browserprofiler, Outlook-cache og andre artefakter. Den er derfor ofte den vigtigste enkeltkilde.
- Sikring: Kopiér containerfilen, mens den ikke er i brug, eller tag et snapshot af det underliggende lager. En monteret container er i brug og kan ændre sig under kopiering.
- Analyse: Montér kopien skrivebeskyttet og analysér profilen som en almindelig Windows-profil. → Registreringsdatabasen i en undersøgelse
- Begrænsninger: Containeren indeholder ikke systemdelen af maskinen. Artefakter, der ligger uden for profilen, fx systemets Prefetch og hændelseslogs, findes ikke her.
Profilstyringsløsninger kan være sat op til at udelade bestemte mapper fra containeren. Notér konfigurationen, så det er klart, hvad der kunne forventes. I FSLogix angives udeladelser i en særskilt fil (redirections.xml), hvis placering står i registreringsdatabasen, og de udeladte mapper ligger da i en lokal profil uden for containeren; Microsoft anbefaler fx at udelade bestemte cache- og logmapper for Teams. Andre profilstyringsløsninger har egne standardlister over udeladte mapper, som afhænger af produkt og version.
Broker og gateway
Broker og gateway er ofte de bedste kilder til, hvem der var logget ind hvornår og hvorfra. De kan registrere:
- brugerkonto, start og slut på session, gentilslutninger,
- hvilken sessionsvært og hvilket skrivebord eller program der blev tildelt,
- klientens navn, version og IP-adresse,
- godkendelsesmetode og eventuelle fejlede forsøg.
Data ligger typisk i en database og i monitoreringsværktøjer med en opbevaringstid, der afhænger af produkt og licens. Eksportér de relevante perioder tidligt, og hash eksporterne. På tidspunktet for gennemgangen (oktober 2026) angiver Citrix’ dokumentation, at overvågningsdata i nogle licensniveauer kun bevares i omkring en uge, mens den højeste grænse ligger på knap tre år, og at de enkelte datatyper har hver sin oprydningsperiode. Aflæs derfor de faktiske indstillinger i miljøet, før perioden antages at være dækket.
Gatewayens logs kan suppleres med identitetsudbyderens loginlogs, hvis login sker via SSO. → Identitetsudbydere og SSO: systemlogs som samlet login-spor
Sessionsværterne
Sessionsværternes Windows-hændelseslogs viser logon og logoff, fjernskrivebordsforbindelser og afbrydelser. På ikke-persistente værter forsvinder de lokale logs ved nulstilling, medmindre de videresendes centralt. På multisession-servere er der mange brugere samtidig, så hændelser skal knyttes til den rigtige session og bruger ved hjælp af sessions-id og logon-id. → RDP-spor: fjernskrivebord i logs, register og bitmap-cache
Klientenheden
Brugerens egen enhed er en selvstændig kilde. Klientprogrammet kan efterlade logs, konfiguration og historik over forbindelser. Udklipsholder, drevdeling og USB-viderestilling mellem klient og session kan være slået til, og så kan data være flyttet fra sessionen til den lokale enhed eller omvendt. Politikkerne for viderestilling i miljøet viser, om det overhovedet var muligt.
Er klienten en privat computer, kræver adgang til den et særskilt grundlag og kan sjældent forventes. Så må spørgsmålet belyses fra serversiden.
Publicerede programmer og cloudskriveborde
Ikke alle miljøer giver brugeren et helt skrivebord. Ofte publiceres enkelte programmer, fx et ERP-system eller en økonomiløsning, som kører på en sessionsvært, men vises i et vindue på brugerens computer. Sporene fordeles så mellem klienten, der viser vinduet, og sessionsværten, der kører programmet. Filer, der gemmes fra programmet, kan ende på sessionsværtens profil, på en fildeling eller på klientens lokale drev via drevviderestilling.
Cloudbaserede skriveborde fra de store udbydere følger samme mønster, men broker og gateway drives af udbyderen. Sessionsdata findes så i udbyderens administrationsportal og logtjenester og skal eksporteres derfra med den opbevaringstid, abonnementet giver.
Sessionsoptagelse og overvågning
Nogle miljøer har sessionsoptagelse eller detaljeret overvågning af brugeraktivitet slået til, typisk for administratorer eller særligt følsomme systemer. Optagelser kan være meget direkte bevis for, hvad der skete i en session, men de er også et indgreb, der kræver et klart grundlag og en forudgående orientering af brugerne. Notér, om optagelse var slået til, for hvem, og hvor længe optagelser gemmes. Brug af optagelser i en sag skal afgrænses til det relevante tidsrum.
Sikring i den rigtige rækkefølge
- Kortlæg arkitekturen med IT-afdelingen eller leverandøren: produkter, versioner, persistente eller ikke-persistente puljer, profilløsning, central logning.
- Forhindr nulstilling: Er brugerens session eller skrivebord relevant, så aftal, at maskinen ikke genstartes eller genskabes, før den er sikret.
- Sikr broker-, gateway- og MFA-data for perioden.
- Kopiér profilcontaineren og relevante fildelinger.
- Sikr sessionsværtens logs eller hent dem fra central logning.
- Sikr et persistent skrivebord som virtuel maskine, hvis det er relevant.
Fejlkilder i fortolkningen
- Delte sessionsværter. En hændelse på en multisession-server tilhører ikke nødvendigvis den bruger, man undersøger.
- IP-adressen er klientens set fra gatewayen. Bag den kan ligge NAT, VPN eller et hjemmenetværk.
- Profilens tidsstempler afspejler montering og synkronisering, ikke kun brugerens handlinger.
- Grundbilledet. Artefakter fra grundbilledet findes på alle skriveborde og siger intet om den enkelte bruger.
- Fravær af lokale spor på et ikke-persistent skrivebord er forventet og ikke tegn på sletning.
- Gentilslutninger. En afbrudt session, der genoptages fra en anden klient, kan give to klientadresser for samme session. Broker-data viser typisk begge, men det skal læses omhyggeligt.
Hvad sporene kan og ikke kan bevise
Samlet kan broker, gateway og profil vise, at en konto var logget ind i bestemte tidsrum fra en bestemt klient og arbejdede med bestemte filer og programmer. Spørgsmålet om, hvem der sad ved klienten, skal som altid bygges op af flere spor. → Hvem sad ved tastaturet? Attribution af brugerhandlinger
Dokumentation
Rapporten bør beskrive arkitekturen, hvilke komponenter der er sikret med hash, sessionsdatas opbevaringstid og dækning, profilløsningens konfiguration og eventuelle huller, der skyldes nulstilling eller manglende central logning.
Kilder og versioner
- Microsoft Learn: FSLogix, Create and implement redirections.xml
- Citrix Docs: Director, data retention
- Citrix Developer Docs: Set-MonitorConfiguration
Senest gennemgået: oktober 2026.
Næste skridt
- macOS-artefakter i undersøgelser
- Sikring af moderne Mac: Apple silicon, T2 og logisk sikring
- Linux-servere i undersøgelser: journald, auth-log og shellhistorik
Del af: macOS- og Linux-forensik
Læs også: Gendannelse fra backup til forensisk brug: metode og dokumentation · Ældre medier og båndbackup i sager
→ Forensisk undersøgelse af en computer · For IT-afdelingen · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT
