Fallgruver

Problemet

Authorization har tre verdier i Intune: Allow, Deny og Allow Standard User To Set System Service. Den siste lar en standardbruker (uten adminrettigheter) slå på tilgangen selv i Systeminnstillinger.

Ifølge Apples skjema er verdien bare gyldig for:

• ScreenCapture (Skjerm- og systemlydopptak)
• ListenEvent (Inndataovervåking)

Intune viser likevel verdien i nedtrekkslisten for alle tjenester, også Kalendere, Bilder og mappetilgang.

Symptom

Policyen lagres uten feil, men verdien har ingen effekt på andre tjenester enn de to over.

Løsning

• For skjermopptak og inndataovervåking: bruk AllowStandardUserToSetSystemService. Disse to kan ikke forhåndsgodkjennes med Allow, så dette er den eneste måten å slippe admin-passord på.
• For andre tjenester: bruk Allow eller Deny.

Relatert

• Kamera og mikrofon kan ikke forhåndsgodkjennes med PPPC

Problemet

Hver app-oppføring i en PPPC-policy må bruke enten Allowed-nøkkelen (true/false) eller Authorization-nøkkelen (enum) — aldri begge. Intune admin center validerer ikke dette ved lagring; konsollen lar deg fylle ut begge feltene, og policyen ser tilsynelatende gyldig ut helt til Intune prøver å levere den til enheten.

Symptom

Enheten blir stående i Pending-status uten en feilmelding i portalen som peker direkte på årsaken.

Løsning

Gå gjennom hver app-oppføring og fjern én av de to nøklene (“–”-knappen i konsollen), slik at kun Allowed eller kun Authorization er satt.

Når du legger til en tjeneste i settings catalog, legger Intune inn både Allowed og Authorization som standard. Det er derfor lett å havne her uten å ha valgt det selv.

Relatert

• Kamera og mikrofon kan ikke forhåndsgodkjennes

Problemet

I DDM App Settings betyr AllowedBinaries «bare disse får kjøre» så snart listen har innhold. macOS kjører fortsatt systemkritiske prosesser, men alt annet som ikke matcher, blokkeres.

AlwaysAllowManagedApps er false som standard. Da gjelder blokkeringen også apper du selv har rullet ut.

Regler for identifikatorer

• Allowed Binaries: CDHash eller TeamID må være med. SigningID, PathPrefix og SigningState kan legges til.
• Denied Binaries: CDHash, TeamID eller SigningID må være med.
• En binær matcher bare når alle utfylte felt matcher.
• Apple-binærer har tom Team ID. Bruk *APPLE*, ikke en tom streng.
• Verdiene finner du med codesign -dvvv <sti>.

Løsning

• Start med DeniedBinaries hvis målet er å stoppe enkeltapper.
• Bruk AllowedBinaries bare med AlwaysAllowManagedApps = true og etter testing på en pilotgruppe.
• AlwaysAllowManagedApps gjelder bare apper fra VPP og Line-of-business-apptypen, ikke PKG/DMG-apper installert av Intune-agenten.

Relatert

• Permission Defaults gir samtykkespørsmål, ikke stille godkjenning

Problemet

Microsoft har varslet at Intune skal fjerne eldre MDM-baserte programvareoppdateringer for Apple etter at Apple har avviklet de underliggende MDM-kommandoene og payloadene. Scenarioer som fortsatt bruker den gamle veien, må flyttes til declarative device management (DDM). Microsoft oppgir ingen dato; endringen står som «in development».

Kilde: Intune – In development (Device management → «Remove legacy Apple MDM software update workloads from Intune»).

Hva DDM tilbyr på macOS

Apples skjema (apple/device-management) har to konfigurasjoner:

Deklarasjon	Formål	macOS	Innrullering
com.apple.configuration.softwareupdate.settings	Utsettelse, automatiske handlinger, varsler, beta-programmer	15.0+	Kun supervised
com.apple.configuration.softwareupdate.enforcement.specific	Tvinge en bestemt versjon innen et gitt tidspunkt	14.0+	Kun supervised

Begge har system-scope. Viktige detaljer fra skjemaet:

• enforcement.specific krever TargetOSVersion og TargetLocalDateTime (uten tidssone). Systemet installerer nøyaktig den versjonen som er angitt, ikke en nyere patch.
• Hvis målversjonen ikke finnes hos Apple (GDMF), blir konfigurasjonen stående uten å oppdatere enheten.
• Supplemental-oppdateringer krever at basisversjonen allerede er installert: bruk to konfigurasjoner etter hverandre.
• Er Macen av ved fristen, installeres oppdateringen en time etter neste omstart.
• settings har på macOS bl.a. Deferrals (MajorPeriodInDays, MinorPeriodInDays, SystemPeriodInDays, 1–90 dager) og AllowStandardUserOSUpdates.

Kilder: softwareupdate.settings, softwareupdate.enforcement.specific.

Spor

• ADE (supervised): DDM-oppdateringer er tilgjengelige.
• BYOD / manuell (ikke supervised): Skjemaet tillater bare supervised på macOS, så DDM-deklarasjonene gjelder ikke. Planlegg uten tvungne oppdateringer for disse Macene, f.eks. via brukerveiledning.

Løsning

• Kartlegg policyer i tenanten som bruker eldre oppdateringsinnstillinger for macOS.
• Bygg tilsvarende DDM-policyer for ADE-Macer, og test på en pilotgruppe før de gamle fjernes.
• Ikke vent på at Intune fjerner de gamle innstillingene; datoen er ikke oppgitt.

Denne siden har ingen generator ennå. Hvordan Intune uttrykker disse deklarasjonene i Settings Catalog er ikke verifisert i lab.

Problemet

I Apples skjema for PPPC (com.apple.TCC.configuration-profile-policy, Release-v27.0) er disse tjenestene merket deprecated: 27.0:

PPPC-tjeneste	Erstatning i DDM Permission Defaults
Camera	Camera
Microphone	Microphone
Accessibility	Accessibility
BluetoothAlways	Bluetooth
SpeechRecognition	Ingen direkte erstatning dokumentert

Intune settings catalog viser alle fem i pickeren, uten noen merking.

Symptom

Ingen feil i Intune. På macOS 27 endrer oppførselen seg likevel: for Accessibility viser enheten et varsel per app når innstillingen brukes, og brukeren kan endre den i Systeminnstillinger.

Løsning

• Behold PPPC-oppføringene så lenge flåten har Macer på macOS 26 eller eldre.
• For macOS 27+ (supervised): legg til en DDM App Settings-policy med Permission Defaults for de samme appene. Den kan ligge ved siden av PPPC-policyen.
• Ikke regn med at Permission Defaults gjør det samme som PPPC: brukeren får et samtykkespørsmål.

De andre 19 PPPC-tjenestene (filer og mapper, skjermopptak, automatisering m.m.) er ikke avviklet.

Relatert

• Permission Defaults gir samtykkespørsmål, ikke stille godkjenning
• Kamera og mikrofon kan ikke forhåndsgodkjennes med PPPC

Problemet

Apple lar ikke en MDM-profil gi tilgang til kamera eller mikrofon. I PPPC-skjemaet står det rett ut at en profil bare kan nekte (Deny) for disse tjenestene. Tilgang gir brukeren selv, når appen spør.

Intune admin center tilbyr likevel Allow (og Allowed = true) for Camera og Microphone, uten advarsel.

Symptom

Policyen deployer uten feil i Intune, men har ingen effekt: brukeren får fortsatt spørsmålet om tilgang første gang appen bruker kamera eller mikrofon.

Løsning

• Vil du nekte tilgang: bruk Authorization = Deny. Det virker som forventet.
• Vil du gi tilgang, macOS 26 og eldre: det går ikke med MDM. Brukeren må godkjenne selv.
• Vil du gi tilgang, macOS 27 og nyere (supervised): bruk DDM-deklarasjonen App Settings → Permission Defaults. Den gir ikke stille godkjenning, men viser brukeren ett samlet samtykkespørsmål med din begrunnelse. Se egen fallgruve om Permission Defaults.

Merk at Camera og Microphone er avviklet i PPPC fra macOS 27.

AllowStandardUserToSetSystemService er ikke en løsning her. Den verdien gjelder bare skjermopptak (ScreenCapture) og inndataovervåking (ListenEvent).

Relatert

• Allowed og Authorization i samme oppføring
• PPPC-tjenester avviklet i macOS 27
• Permission Defaults gir samtykkespørsmål, ikke stille godkjenning

Problemet

Compliance-policyer for macOS gir ikke et pålitelig resultat på Mac-er uten primærbruker (ADE uten brukertilknytning, delte Mac-er, kiosk). Microsoft Learn sier at compliance-evaluering «is not supported for userless macOS devices» (macOS compliance settings).

Det betyr at en Conditional Access-policy med Require device to be marked as compliant ikke kan forventes å fungere meningsfullt for disse enhetene. Dokumentasjonen sier ikke hvilken status slike enheter faktisk får (Not evaluated, Compliant eller Unknown), og heller ikke hvordan Conditional Access behandler dem. Dette er ikke testet i lab.

Symptom

• Compliance-status for userless-Mac-er er tom, ukjent eller ikke i samsvar med faktisk tilstand.
• Compliance-policyer ser ut til å være tildelt, men gir ingen brukbar rapportering for enheten.
• Du kan ikke bruke compliance som bevis for at FileVault, brannmur osv. er på.

Løsning

• Primærbruker der compliance eller Conditional Access kreves: rull ut med brukertilknytning.
• Userless-enheter: håndhev sikkerhetsinnstillinger direkte med Settings Catalog (FileVault, firewall osv.) i stedet for å stole på compliance.
• Sjekk tenant-innstillingen Mark devices with no compliance policy assigned as (Endpoint security → Device compliance → Compliance policy settings). Standard er Compliant, og Microsoft anbefaler Not compliant hvis du bruker Conditional Access (oversikt). Hvordan innstillingen slår ut for userless-Mac-er, er ikke dokumentert.

Spor

• ADE: gjelder ADE-innrullering uten brukertilknytning.
• BYOD / manuell: ikke relevant, siden Company Portal-innrullering har en bruker.

Relatert

• Eldre MDM-baserte programvareoppdateringer fjernes fra Intune – flytt til DDM

Problemet

I en macOS compliance-policy ligger Require a password to unlock devices under System security > Password. Microsoft advarer om at et passordkrav i compliance-policyen utløper det eksisterende passordet for alle kontoer på enheten, inkludert kontoer opprettet av LAPS og Platform SSO. Det gjelder både BYOD og ADE, og er mest kritisk der LAPS eller Platform SSO brukes.

Symptom

Brukere og lokale admin-kontoer blir bedt om å bytte passord uten forvarsel, ofte rett etter at compliance-policyen er tildelt. Passord som LAPS har rotert, eller som Platform SSO styrer, kan bli utløpt.

Løsning

• Microsoft anbefaler å styre passord med en Settings Catalog-policy med Change At Next Auth satt til False, og la compliance-policyen være uten passordinnstillingene.
• Må du ha passordinnstillingene i compliance, tildel først til en pilotgruppe og se hva som skjer med LAPS- og Platform SSO-kontoer før bred utrulling.
• Endrede passordkrav slår ifølge Microsoft først inn neste gang brukeren bytter passord. Enheten forblir compliant til da.

Begrensninger

Dokumentasjonen sier ikke om utløpet skjer ved første evaluering eller bare når passordinnstillingene endres, eller om det gjelder alle underinnstillinger eller bare Require a password to unlock devices. Dette er ikke verifisert i lab.

Problemet

Det er lett å tro at Permission Defaults er «PPPC for kamera og mikrofon». Det er det ikke.

Når en app med Permission Defaults starter, viser macOS ett samtykkespørsmål med alle tillatelsene du har foreslått og teksten i OrganizationJustification. Brukeren velger:

• Allow: tillatelsene settes, og appen spør ikke igjen.
• Not Now: ingenting settes, og appen spør på vanlig måte når den trenger tilgangen.

Brukeren kan endre tillatelsene i Systeminnstillinger etterpå.

Begrensninger

• macOS 27+ og supervised enheter.
• Brukerscope på macOS. Binærkontroll i samme deklarasjon (Allowed/Denied Binaries) er systemscope. Vurder separate policyer.
• Bare AppKit-baserte apper støttes.
• OrganizationJustification er påkrevd.
• Location = WhileUsing er det samme som Always på macOS.
• Spørsmålet viser bare tillatelser brukeren ikke har sett før.

Intune-detalj

Apple bruker app-identifikatoren som nøkkel i en dictionary ("com.example.app {anchor apple generic}"). I Intune ligger nøkkelen i et eget felt (..._generickey_keytobereplaced), ved siden av tillatelsene. Identifikatoren på macOS må være <bundle-ID> {<designated requirement>}, ikke bare bundle-ID.

Relatert

• PPPC-tjenester avviklet i macOS 27
• Kamera og mikrofon kan ikke forhåndsgodkjennes med PPPC

Problemet

Artikkelen om eldre MDM-baserte oppdateringer gjelder ADE. Denne siden gjelder Mac-er som er rullet inn manuelt (Company Portal, user-approved MDM, ikke supervised). Spørsmålet er hva slike Mac-er kan få av oppdateringsstyring i dag, og hva som faller bort når Intune fjerner de MDM-baserte oppdateringene.

Kort svar: ut fra kildene finnes det ingen dokumentert måte å tvinge eller tidsstyre oppdateringer på en ikke-supervised Mac. Detaljene under skiller mellom det kildene sier og det de ikke sier.

Hva kildene sier

MDM-kommandoene krever supervised og er fjernet i macOS 27

Apples skjema (Release-v27.0) har disse macOS-kommandoene:

Kommando	Supervised	Avviklet	Fjernet
ScheduleOSUpdate	ja	26.0	27.0
ScheduleOSUpdateScan	ja	26.0	27.0
OSUpdateStatus	ja	26.0	27.0
AvailableOSUpdates	nei (ikke oppgitt som krav i skjemaet)	26.0	27.0

Beskrivelsen av ScheduleOSUpdate sier at bare supervised enheter kan få oppdateringsstyring. Erstatningen Apple peker til er com.apple.configuration.softwareupdate.enforcement.specific. Kilder: ScheduleOSUpdate, OSUpdateStatus. Raden for AvailableOSUpdates er lest fra system.update.available.yaml i samme utgave.

Intunes egne oppdateringspolicyer er bare for supervised Mac

Microsoft skriver at Intune kan styre oppdateringer for macOS-enheter som er innrullert som supervised, og at funksjonen gjelder macOS 12–15 (supervised). Samme side sier at Intune «soon» avslutter støtten, og at DDM anbefales. Microsoft sier også at Apples MDM ikke lar deg tvinge en oppdatering til et bestemt tidspunkt. Kilde: Update policies for macOS.

Fjerningen står som «in development», uten dato, og skal skje etter at Apple har fjernet de underliggende kommandoene og payloadene. Kilde: In development (Device management → «Remove legacy Apple MDM software update workloads from Intune»).

DDM-erstatningene tillater bare supervised

com.apple.configuration.softwareupdate.settings har på macOS bare supervised under allowed-enrollments. Kilde: softwareupdate.settings. For softwareupdate.enforcement.specific gjelder det samme, se den eksisterende artikkelen.

Software Update-payloaden er fjernet i macOS 27

com.apple.SoftwareUpdate (nøkler som AutomaticCheckEnabled, AutomaticDownload, CriticalUpdateInstall) er avviklet i 26.0 og fjernet i 27.0. Beskrivelsen peker til softwareupdate.settings. Skjemaet oppgir ikke noe supervised-krav for macOS på denne payloaden, så den er etter skjemaet tilgjengelig uten supervised til den forsvinner. Kilde: com.apple.SoftwareUpdate.

Restrictions-nøklene for utsettelse er også fjernet i macOS 27

Nøklene enforcedSoftwareUpdateDelay, forceDelayedSoftwareUpdates, forceDelayedMajorSoftwareUpdates, forceDelayedAppSoftwareUpdates og enforcedSoftwareUpdateMinorOSDeferredInstallDelay er avviklet i 26.0 og fjernet i 27.0 i Restrictions-payloaden. Kilde: com.apple.applicationaccess.

Hva som er uklart

• Utsettelse via Restrictions på ikke-supervised Mac. Apples skjema oppgir ikke supervised for disse nøklene på macOS, mens Microsoft skriver at Force Delayed App Software Updates krever supervised og omtaler utsettelse som noe man gjør på supervised Mac. Kildene er ikke samstemte, og vi har ikke testet det i lab. Behandle det som ikke bekreftet at utsettelse virker på BYOD-Mac. Uansett er nøklene borte i macOS 27.
• userenrollment: forbidden i skjemaet gjelder Account-driven User Enrollment, ikke manuell innrullering via Company Portal. Ikke les det som et svar på spørsmålet om BYOD-Mac.
• Hva Intune gjør med eksisterende policyer når fjerningen kommer, er ikke beskrevet. Det finnes ingen dato.
• Om Intune har egne kontroller for minste OS-versjon (samsvar, innrulleringsbegrensninger) som er nyttige på BYOD-Mac, er ikke undersøkt her. Microsoft peker til siden Manage operating system versions i varselet om støttede versjoner, men vi har ikke lest den i denne saken.

Konsekvens for BYOD-Mac

• Etter kildene finnes det ingen dokumentert MDM- eller DDM-mekanisme som tvinger en bestemt versjon eller et tidspunkt på en ikke-supervised Mac.
• Det som faller bort for BYOD-Mac når macOS 27 kommer: com.apple.SoftwareUpdate-payloaden og utsettelsesnøklene i Restrictions. Intunes oppdateringspolicyer er uansett for supervised Mac.
• Planlegg med brukerstyrte oppdateringer: veiledning til brukerne, og oppfølging av versjon gjennom Intunes enhetsrapportering. Hvilke rapporter og samsvarskontroller som passer, må avklares separat.

Denne siden har ingen generator, og ingen Settings Catalog-ID-er er verifisert i lab.

Problemet

Du strammer inn passordkravet i en macOS compliance-policy, for eksempel Minimum password length fra seks til åtte. Intune-dokumentasjonen sier at endrede passordkrav ikke trer i kraft før brukeren neste gang bytter passord. Dokumentasjonens eget eksempel: en enhet med seks siffer forblir compliant etter at kravet er satt til åtte.

Dette gjelder under Password i compliance-policyen (Require a password to unlock devices, Simple passwords, Minimum password length, Password type, antall ikke-alfanumeriske tegn, utløp og gjenbruk). Dokumentasjonen skiller ikke mellom innstillingene; vi vet ikke om alle oppfører seg likt, og den forklarer ikke hvordan endringen oppdages.

Symptom

• Compliance-rapporten viser grønt for enheter som faktisk har et passord under det nye kravet.
• Conditional Access slipper disse enhetene gjennom, fordi de regnes som compliant.
• Ingen enheter blir noncompliant etter innstrammingen, selv om du forventet det.

Løsning

• Ikke bruk compliance-status som bevis på at et strammere passordkrav er oppfylt på eksisterende enheter.
• Håndter selve passordpolicyen i en Settings Catalog-policy. Microsoft anbefaler dette, med Change At Next Auth satt til False, fordi passordkrav i en compliance-policy utløper eksisterende passord på alle kontoer på enheten, også de fra LAPS og Platform SSO.
• Skal eksisterende brukere opp på det nye nivået, må passordbytte skje som en planlagt og kontrollert handling, ikke som en bivirkning av policyendringen.
• Trenger du å verifisere faktisk tilstand, kan du bruke custom compliance-skript på macOS. Dette er vår anbefaling, ikke noe den aktuelle siden beskriver.
• Gjelder både BYOD og ADE; kilden oppgir ingen supervised-krav.