Sophos Mobile: hantera macOS-anslutningar med enhets- eller användarpolicy

Denna artikel gäller Sophos Mobile-policyer på hanterade Mac-datorer, inte allmän konfiguration av Apples Wi-Fi eller VPN och inte Sophos Endpoint, ZTNA eller konfiguration av en Sophos Firewall. För klientinstallation och fjärråtkomst via brandväggen i stället för Mobile-policy, se Sophos Connect på macOS. Enhets- och användarkontext är skilda: samma konfigurationsnamn innebär inte att identitet, certifikatåtkomst och tidpunkten då policyn tillämpas är utbytbara. Att en profil tilldelats bevisar inte i sig att anslutningen fungerar.

Förutsättningar: säkra först hanteringsvägen och återställningsvägen

• MDM-licens som krävs: För att hantera Mac-datorer krävs Sophos Mobile Device Management, antingen som fristående licens eller som del av den kombinerade licensen Sophos Mobile. Enbart Sophos Mobile Threat Defense räcker inte: den licensen omfattar hantering av Sophos Intercept X for Mobile och Sophos Chrome Security, inte MDM-hantering av Mac-datorer. Kontrollera motsvarande MDM-licensrättighet i tenanten innan policyerna skapas.
• Kontrollera att Mac-datorn är registrerad i Sophos Mobile, vilken macOS-version den har, vilka policyer som redan har tilldelats och om funktionen kräver hantering av en enhet eller en viss användare. Mac-datorer har bara ett hanteringsläge i Sophos Mobile, men det finns enhets-, deklarativa och användarpolicyer. Apples User Enrollment för privata iPhone- och iPad-enheter är inte ett registreringsläge för macOS. Vid manuell Mac-registrering måste användaren som ska hanteras utföra registreringen och ange ett administratörslösenord för registreringsprofilen. Vid automatisk registrering via Apple Business: kontrollera under Assign user to device om No (ingen användartilldelning vid registreringen) eller Yes - LDAPS authentication har valts. Härled inte användartilldelningen ur enhetspolicyn.
• Enhetspolicyer gäller alla användare av Mac-datorn. Användarpolicyer gäller den användare som registrerar sig lokalt samt nätverksanvändare som Sophos Mobile känner till via Self Service Portals externa LDAP-katalog. Om Mac-datorn ansluts till samma AD-domän som Self Service Portal genom enhetspolicyn tillämpas användarpolicyn på alla AD-användare som loggar in där. Kontrollera detta med de avsedda kontona före en bred tilldelning.
• Utöver registreringens enhetspolicy kan en Mac-dator tilldelas en ytterligare enhetspolicy, en deklarativ policy och en användarpolicy. Före varje ändring av en payload: inventera mål-Mac-datorer, berörda användare och grupper samt samtliga tilldelningar av den befintliga policyn. Ändra aldrig en policy som redan tilldelats utanför piloten för pilotens skull. Dokumentera befintliga payloads för Wi-Fi, VPN, proxy och certifikat samt deras ansvariga. Motstridiga inställningar hanteras i regel enligt det mer restriktiva värdet, med ett särskilt företräde för deklarativa konfigurationer av programuppdateringar och appar. Lägg inte okontrollerade ytterligare tilldelningar ovanpå befintliga profiler.
• Förhandskontroll endast för macOS 26 med användarpolicy: Vid status Failed to apply the policy, granska tidigare tilldelade Restrictions-konfigurationer och deras historik som en möjlig orsak: den föråldrade nyckeln Allow Time Machine kan finnas kvar i en äldre tilldelad policy trots att den inte längre syns bland konfigurationsalternativen. Kräv inte att nyckeln ska kunna hittas i det nuvarande gränssnittet. Om denna äldre policyorsak misstänks: stoppa piloten och utvärderingen av användarpolicyns Wi-Fi-, VPN- och certifikatpayloads. Enligt Sophos kan då hela användarpolicyn utebli, inte bara begränsningen. Stäm av kontrollerad rensning och ny kontroll med dem som ansvarar för macOS-säkerhets- och integritetspolicyer; ändra inte en delad produktionspolicy i tysthet. Detta är inte ett generellt fel på alla Mac-datorer med macOS 26 eller på enhetspolicyer.
• Se till att det finns oberoende åtkomst till pilotdatorn (till exempel ett fungerande alternativt nätverk och lokal administratörsåtkomst). Stäm i förväg av SSID, RADIUS-/VPN-slutpunkt, DNS, PKI-förtroendekedja, certifikatens giltighetstid, åtkomst till PAC/proxy och eventuell VPN-app från tredje part med respektive ansvariga. Lägg inte in åtkomstlösenord eller .pfx-filer i ärenden eller offentliga lagringsytor. Kontrollera produkt-, licens- och OS-stöd för den konkreta miljön i tenanten; konfigurationssidorna ger inget allmänt stöd för varje macOS-version.

Välj policy och beroenden

Vid manuellt konfigurerad Global HTTP proxy med inloggningsuppgifter ska proxyanvändarnamnet anges i Authentication och det tillhörande proxylösenordet i Password. Authentication är här ett användarnamnsfält, inte ett val av autentiseringsmetod. Klarlägg med proxyansvariga om inloggningsuppgifter behövs; lägg inte in lösenorden i ärenden eller offentliga lagringsytor.

Wi-Fi: välj nätverk och autentisering

Fältbeskrivningarna nedan återger Sophos dokumenterade inställningar, inte en anslutning som har testats på en Mac. Connect automatically ansluter Mac-datorn automatiskt när Wi-Fi-nätverket är tillgängligt. Hidden network anger att nätverket inte sänder ut sitt SSID. Valet måste passa målnätverket. Ett dolt SSID innebär inget säkerhetsgodkännande.

Security type anger säkerhetsmetoden och varianten Personal eller Enterprise. Stäm av båda med Wi-Fi-ansvariga. För Personal anges Wi-Fi-lösenordet i Password. För Enterprise finns Protocols för autentiseringsprotokollen och Authentication för klientautentiseringen:

• Välj under Protocols > Accepted EAP types vilka EAP-typer Mac-datorn accepterar för autentisering, så att de passar RADIUS-tjänsten. För EAP-FAST kan en Protected Access Credential (PAC) konfigureras. Denna PAC är ingen proxy-auto-config-fil. För TTLS väljer Internal identity protokollet för användarautentisering inne i tunneln, inte användarnamnet.
• Om den valda Enterprise-metoden använder användarnamn och lösenord anges Wi-Fi-användarnamnet under Authentication > User och Wi-Fi-lösenordet under Password. Att policyn tilldelats en användare ersätter inte dessa uppgifter. Require password on each connect innebär enligt Sophos att lösenordet skickas vid varje autentisering. Dra inga slutsatser om lösenordsfrågor, viss lagring eller överföring av lösenordet i klartext. Lägg inte generellt till lösenord för certifikatbaserade metoder.

Outer identity är en platshållaridentitet som EAP använder för att inleda autentiseringen utan att lämna ut användarens faktiska inloggningsuppgifter. Den överförs i klartext. Använd därför varken det faktiska användarnamnet eller känsliga uppgifter. Om RADIUS-tjänsten behöver realm-baserad vidarebefordran måste platshållaridentiteten innehålla den realm som avtalats med tjänstens ansvariga. Utan denna vidarebefordran kan en enkel identitet som anonymous räcka. Villkoren för EAP och TLS 1.3 nedan gäller fortfarande.

Viktigt för Wi-Fi Enterprise: För Identity certificate kräver Sophos Mobile att det redan finns en Client certificate-konfiguration i samma policy; för Trusted certificates krävs en föregående Root certificate-konfiguration. Wi-Fi-payloaden har dessutom ett eget fält Proxy för manuella inställningar eller PAC; det är inte samma sak som Global HTTP proxy. Klientcertifikatet är även tillgängligt för andra konfigurationer i samma policy, men inte för andra policyer; ladda upp det igen där. Apple beskriver på plattformsnivå att en SCEP-identitet kan kopplas till en tjänst i samma konfigurationsprofil, men Apples konkreta exempel med Wi-Fi-EAP-TLS använder ett AD-certifikat. Detta bevisar inte att Sophos Mobile erbjuder en SCEP-identitet i Wi-Fi-fältet Identity certificate eller levererar motsvarande koppling: Sophos Wi-Fi-hjälp anger i stället Client certificate-konfigurationen som förutsättning. Planera inte ett SCEP-beroende vid första tilldelningen eller för Wi-Fi i produktion. Överväg en sådan variant som driftväg först efter att faktisk bindning har påvisats i den egna tenanten och på en hanterad pilot-Mac, samt genom en lyckad EAP-/RADIUS-inloggning; stoppa denna väg om varken val eller levererad bindning kan påvisas. För EAP-TTLS/PEAP/EAP-FAST: ange Outer identity utan känsliga användaruppgifter; enligt Sophos krävs detta vid TLS 1.3. Ange TLS-minimum och -maximum tillsammans eller lämna båda tomma.

VPN: stäm av leverantör, autentisering och proxy

Connection name är anslutningsnamnet som användaren ser på Mac-datorn, inte policyns namn. Sophos fältlista anger alternativen Cisco AnyConnect, Cisco Legacy AnyConnect, IPsec (Cisco), F5, Check Point och Custom SSL/TLS under Connection type. Custom SSL/TLS är avsett för leverantörer vars app i App Store tillhandahåller VPN-anslutningen. Listan innebär inte att varje kombination av leverantör och macOS stöds. Appen som behövs måste redan vara installerad. Klarlägg dess faktiska Reverse-DNS-Identifier med leverantören.

Använd följande alternativ endast om den valda anslutningstypen och leverantören erbjuder och kräver dem. Om leverantören anger egna anslutningsegenskaper lägger du till varje Key och Value med Add under Third-party settings. Kopiera inte egenskaper från ett annat VPN. Group är en grupp som kan behövas för VPN-autentiseringen, inte en enhetsgrupp för policytilldelning.

Fastställ användar- och enhetsautentisering separat med VPN-ansvariga:

• Välj mellan Password och Certificate under User authentication. Tillhörande Password innehåller VPN-lösenordet och Certificate certifikatet för VPN-användarautentisering.
• Med Device authentication = Keys (Shared Secret)/Group name visas Group name, Keys (Shared Secret), Use hybrid authentication och Request password. Ange de autentiseringsuppgifter som VPN-ansvariga tillhandahåller i Group name och Keys (Shared Secret). Välj Use hybrid authentication och Request password endast enligt deras krav, inte som en generell lösning på anslutningsproblem.
• Med Device authentication = Certificate visas Certificate och Including user PIN. Välj det enhetscertifikat som behövs i listan Certificate. Including user PIN inkluderar användarens PIN i enhetsautentiseringen. Källan anger varken när PIN efterfrågas eller hur den lagras.

Skydda VPN-lösenord och Shared Secrets som övriga inloggningsuppgifter. Certifikatfälten bevisar fortfarande ingen väg för SCEP-koppling. Kontrollera faktisk identitet och autentisering i den avsedda användar-/enhetskontexten.

Under VPN-anslutningens egen Proxy innebär No proxy att ingen proxy konfigureras för denna anslutning. Med Manually visas Server and port, Authentication och Password. Ange proxyadress och port samt, om det behövs, proxyanvändarnamn och proxylösenord. Även här är Authentication användarnamnsfältet. Med Automatic visas Proxy server URL för URL:en till servern med proxyinställningarna. Detta är en inställning för VPN-anslutningen, inte en ändring av Global HTTP proxy.

Provider type skiljer mellan App proxy, en VPN-tunnel på applikationsnivå, och Packet tunnel, en VPN-tunnel på nätverksnivå. Stäm av rätt alternativ med leverantören. Dra inga slutsatser om delad eller full tunnel utifrån det. Trafikplanering och kontroll av DNS och rutter i piloten krävs fortfarande.

SCEP: kontrollera slutpunkter, identitet och nycklar

URL innehåller CA-serverns webbadress. %_SCEPPROXYURL_% avser server-URL:en på fliken SCEP på sidan Sophos setup. Challenge är webbadressen där ett challenge-lösenord hämtas från SCEP-servern, inte själva lösenordet. %_CACHALLENGE_% avser challenge-URL:en på samma flik. CA name måste vara ett namn som CA:n förstår. Det kan exempelvis skilja mellan olika CA-instanser. Stäm av rätt värde med PKI-ansvariga. Förutsätt inget universellt namn eller krav på att fylla i fältet.

För ett ytterligare Subject Alternative Name väljer du först typ under Type of Subject Alternative Name och anger sedan värdet under Value of Subject Alternative Name. Sophos beskriver RFC 822 name som en giltig e-postadress, DNS name som CA-serverns DNS-namn och Uniform resource identifier som CA-serverns fullständigt kvalificerade URL. Ersätt inte dessa beskrivningar av CA-servern i tysthet med allmänna antaganden om SAN. Klarlägg typ och värde med PKI-ansvariga för certifikatets avsedda användning. De bevisar ingen Wi-Fi-/VPN-identitetsbindning. Om en AD-användaridentitet används avser AD user logon name det User logon name som är lagrat i AD, alltså User Principal Name (UPN). SAN och AD-uppgifter är inga generella förutsättningar för alla Mac-certifikat.

Retries anger antalet nya försök när SCEP-servern svarar med pending. Retry delay är tiden i sekunder mellan dessa försök. Det är inget förnyelseintervall och inget löfte om att utfärdandet lyckas efter väntetiden. Key size anger storleken på den publika nyckeln i det utfärdade certifikatet och måste motsvara storleken som konfigurerats på SCEP-servern. Även SCEP-konfigurationen har Allow export from keychain. Alternativet låter användare exportera certifikatets privata nyckel från nyckelringen. Aktivera det bara vid ett uttryckligen godkänt behov, precis som för det uppladdade klientcertifikatet.

SCEP och nycklar: Slutpunktsvariablerna avser SCEP-inställningarna som beskrivs ovan. Efter att platshållarna ersatts måste subjektvärdet vara ett giltigt X.500-namn: CN=%_USERNAME_% avser en användare, CN=%_DEVPROP(SerialNumber)_% en Mac-dator. Dra inte slutsatsen att rätt enhetsidentitet används bara för att en användarpolicy valts. Kontrollera CA-förtroende, certifikatens giltighetstid, nyckelexport samt utgångsdatum och rutiner för förnyad utfärdning innan något blir beroende av dem; rotcertifikat ersätter inte ett klientcertifikat. Lägg till en separat Root certificate-konfiguration för varje ytterligare rotcertifikat.

Ytterligare enhetspayloads: AirPrint lägger till skrivarens IP-adress och Resource path (till exempel ipp/print) i AirPrint-listan. Directory service ansluter Mac-datorn till en AD-domän när policyn tilldelas; anslutningskontot behöver behörighet att lägga till datorer och OU måste vara rätt. Varning: Ändringar i mappningen av UID, User-GID eller Group-GID kan göra att användare förlorar åtkomst till filer som redan skapats. Ändra inte mappningen som ett nätverkstest; planera AD-anslutning och återställning separat med ansvariga för AD och Mac-datorerna.

Directory service: fastställ konton, hemkatalog och behörigheter

Stäm av uppgifterna för AD-anslutningen under General settings med AD-ansvariga:

• Domain host name innehåller DNS-värdnamnet för den AD-domän som Mac-datorn ska anslutas till. Här ska varken adressen till en DNS-server eller den domänkontrollant som anges separat under Preferred DC server anges.
• AD administrator name och Password innehåller namnet och lösenordet för det konto som används för att ansluta till AD-servern. Detta anslutningskonto måste ha behörighet att lägga till enheter i AD-databasen. Lägg inte in lösenordet i ärenden eller offentliga lagringsytor.
• Organizational unit anger den organisationsenhet (OU) i AD där datorn läggs till när den ansluts. Stäm av det godkända OU-värdet med AD-ansvariga; fältet styr varken användar- eller grupptilldelning eller hemkatalog.

Bestäm före AD-anslutningen tillsammans med ansvariga för AD och Mac-datorerna om det behövs en lokal hemkatalog med ett mobilt konto eller en hemkatalog som enbart ligger på nätverket. Om Create mobile account väljs skapar macOS kontot vid den första inloggningen med anslutning till AD-servern; därefter går det att logga in med AD-inloggningsuppgifter även utan anslutning till denna server. Med Require confirmation before creating a mobile account avgör användaren om det mobila kontot ska skapas – då är det inte garanterat att det skapas. För mobila konton krävs Force local home folder: användarprofilen ligger på startvolymen. Om detta alternativ inaktiveras används hemkataloger som enbart ligger på nätverket. Aktivera därför inte mobila konton generellt för alla Mac-datorer. Om Use UNC path from Active Directory används monterar macOS den hemkatalog som anges i AD-användarkontot; stäm av lämpligt monteringsprotokoll under Network protocol med ansvariga och kontrollera åtkomsten i piloten.

Default user shell anger användarens kommandoradsskal. Om fältet lämnas tomt används enligt Sophos /bin/bash. Detta är fältets dokumenterade standardvärde, inte ett ospecificerat macOS-standardvärde. Stäm av önskat skal med Mac-ansvariga.

Under Mapping kopplas AD-attribut till följande macOS-identifierare:

• UID attribute kopplar ett AD-attribut till den unika användaridentifieraren i macOS.
• User GID attribute kopplar ett AD-attribut till den primära gruppidentifieraren för ett macOS-användarkonto.
• Group GID attribute kopplar ett AD-attribut till gruppidentifieraren för ett macOS-gruppkonto. Denna mappning ger ingen lokal administratörsbehörighet. Det hanteras med Domain administrator groups.

Stäm av befintliga och godkända mappningar med ansvariga för AD och Mac-datorerna före tilldelning. Förutsätt inget universellt AD-attribut eller att tomma fält är säkra för dessa mappningar. Risken för åtkomst till befintliga filer som beskrivs ovan kvarstår vid senare ändringar.

Se till att följande beslut under Administrative godkänns före tilldelningen:

• Preferred DC server anger den AD-domänkontrollant som macOS kontaktar först. Om fältet lämnas tomt väljer macOS domänkontrollant utifrån AD-platsinformationen och hur snabbt domänkontrollanterna svarar. Stäm av valet med AD-teamet; en angiven domänkontrollant innebär inte att macOS binds uteslutande till den.
• Restrict DDNS begränsar vilka nätverksgränssnitt macOS använder Dynamic DNS för. Som standard använder macOS DDNS för alla nätverksgränssnitt. För att begränsa detta, ange BSD-namnen för de avsedda gränssnitten och tryck på Enter efter varje post. Sophos anger en0 som exempel på en inbyggd Ethernet-port; dra inte slutsatsen att detta är rätt gränssnitt på varje Mac-dator. Identifiera de faktiska gränssnitten på pilotdatorn och stäm av de önskade DNS-registreringarna med AD-/DNS-teamet. Inställningen begränsar DDNS; den inaktiverar inget gränssnitt och ingen VPN-tunnel.
• Lösenordsrotation för datorkontot: Password trust interval in days gäller AD-datorkontot, inte användarlösenordet. Ett tomt fält innebär ett automatiskt byte var 14:e dag; 0 förhindrar automatiska ändringar. Stäm av intervallet med AD-driftansvariga; ange inte 0 som en snabb lösning på anslutningsproblem.
• LDAP-skydd: För Packet signing / Packet encryption gäller en gemensam beskrivning: Allow låter macOS avgöra om LDAP-anslutningarna ska signeras och/eller krypteras; Disable stänger av båda; Require kräver alltid signering och kryptering; SSL/TLS använder alltid LDAP över SSL/TLS. Dra inte slutsatsen att varje värde är tillgängligt i båda fälten: kontrollera de faktiska valmöjligheterna i tenanten och fastställ det skydd som krävs tillsammans med AD-teamet. Sänk inte skyddet för att få en lyckad inloggning.
• Avgränsning av inloggning: Multi-domain authentication gör det möjligt för användare från alla domäner i AD-skogen att logga in. Detta utökar kretsen som kan logga in och är inte den ovan beskrivna tillämpningen av Self Service Portals användarpolicy. Med Namespace = Forest kan användare från olika domäner ha samma namn; inloggningen sker som DOMAIN\name. Med Domain är stödet för namnrymder avstängt och inloggningsnamnen måste vara unika. Dokumentera tillåtna domäner och konton i förväg; namnvalet ersätter inte ett godkännande av vilka som får logga in.
• Lokala administratörsbehörigheter: Medlemmar i de AD-grupper som anges under Domain administrator groups får administratörsbehörighet på Mac-datorn. Detta ska skiljas från anslutningskontots behörighet att lägga till en dator. Ange endast godkända grupper som DOMAIN\group och respektera versaler och gemener. Dokumentera för piloten vilka konton som ska förbli standardanvändare och vilka som ska få lokal administratörsbehörighet.

Tilldela i piloten och kontrollera effekten

1. Avgränsa först piloten: Kontrollera inventeringen av namngivna Mac-datorer och berörda användare, gruppmedlemskap, befintliga policytyper och tilldelningar samt fungerande alternativ åtkomst. Ta reda på alla tilldelade enheter och grupper för en befintlig policy. Om den även är tilldelad utanför piloten eller om räckvidden är oklar: redigera den inte. Innan en tidigare macOS-enhets- eller användarpolicy ersätts, jämför alla payloads och beroenden och förbered en återställningsväg av samma typ för just dessa målenheter. Använd grupptilldelning bara om medlemskapet och framtida utökningar är under kontroll; välj annars enskilda enheter.
2. Skapa under Policies > macOS via Create en ny, isolerad testpolicy av rätt typ; använd en kopia bara som en fristående ny policy utan ärvda tilldelningar. Kontrollera före första ändringen av en payload att testpolicyn inte är tilldelad någon enhet eller grupp utanför den godkända piloten. Lämna den brett tilldelade produktionspolicyn orörd. Ange namn, beskrivning och organisationsnamn. Använd Add configuration > Root certificate och skapa först rotkonfigurationen för Wi-Fi Enterprise. Välj Upload a file, välj det förberedda offentliga X.509-rotcertifikatet i PEM- eller DER-kodning och klicka på Open. Spara rotkonfigurationen med Apply efter uppladdningen. Skapa därefter Client certificate i samma policy vid certifikatautentisering. Välj i denna Client certificate-konfiguration åtgärden Upload a file under File och välj den förberedda PKCS #12-filen (.pfx). Aktivera Allow export from keychain endast om export av den privata nyckeln uttryckligen krävs. Konfigurera därefter Wi-Fi. Lägg bara till VPN-/proxykonfigurationer när deras egna beroenden är uppfyllda. Konfigurera vid behov SCEP separat: Sophos allmänna anvisning för att skapa policyer nämner ett SCEP renewal interval på policynivå när SCEP lagts till, men macOS-SCEP-fältlistorna innehåller inget sådant konfigurationsfält. Kontrollera i tenanten om policyintervallet faktiskt finns för den valda macOS-typen; klarlägg utgångsdatum och rutiner för förnyad utfärdning med PKI-ansvariga. Behandla inte SCEP som källa för Wi-Fi-fältet Identity certificate utan separat belägg. Avsluta med att spara policyn med Save på Edit policy. Dokumentera pilotens omfattning, payloads och ursprungsläget för återställning.
3. Välj den blå triangeln för den isolerade testpolicyn och Assign. Välj under Select devices endast inventerade pilot-Mac-datorer eller den i förväg kontrollerade och avgränsade enhetsgruppen och sedan Finish. Jämför före slutförandet de valda målen med inventeringen en gång till; kontrollera därefter de faktiska tilldelningarna och stoppa vid en oväntad målgrupp. Urvalet i detta steg skyddar inte mot ändringar av en policy som redan tidigare tilldelats brett. macOS-flödet har ingen Now-/Date-schemaläggare för tilldelningen här.
4. Kontrollera de tilldelade profilerna på pilotdatorn under System Settings / System Preferences > Profiles i rätt kontext. En ändring i enhetspolicyn får effekt vid nästa enhetssynkronisering; användarpolicyn vid nästa inloggning av den berörda användaren. En ändring i macOS-policyer kräver inte det manuella Update devices-steg som används för iOS. Dokumentera tilldelnings-/uppgiftsstatus och lokal profilvisning, men räkna inte detta som ett funktionstest.
5. Testa effekten, inte bara profilstatus: Logga in som avsedd användare och jämför Wi-Fi-SSID, anslutning och, vid Enterprise-EAP, den förväntade serverförtroendekedjan och den använda klientidentiteten med RADIUS-/PKI-teamet. Upprätta aktivt VPN-anslutningen och kontrollera DNS, rutter och nåbara respektive icke nåbara mål mot planen för delad/full tunnel; testa verklig HTTP(S)-åtkomst och autentisering vid proxy/PAC. Kontrollera certifikaten efter fingeravtryck, giltighet och användningsområde i rätt nyckelring. Testa även en andra användare om effekten för hela enheten eller AD-domänen är relevant. Provutskrift via AirPrint och AD-inloggning behövs bara om dessa payloads faktiskt införs. För Directory service, kontrollera den första inloggningen med anslutning till AD-servern med ett godkänt AD-konto och åtkomsten till den valda lokala hemkatalogen eller nätverkshemkatalogen; kontrollera vid UNC-användning även den förväntade monteringen. Om ett mobilt konto är planerat, kontrollera att det faktiskt skapas, inklusive eventuell användarbekräftelse, och logga därefter in igen utan anslutning till AD-servern. Behåll den oberoende lokala åtkomsten under detta test. Kontrollera tillsammans med AD-/DNS-teamet att den domänkontrollant som faktiskt kontaktas och de faktiska DDNS-registreringarna stämmer med det överenskomna valet och omfattningen av nätverksgränssnitt. Stoppa utrullningen vid en oväntad domänkontrollant eller DNS-post och klarlägg orsaken med dessa ansvariga. Kontrollera även de förväntade standardanvändar-/administratörsbehörigheterna och, där inloggningsavgränsningen kräver det, använd ett för detta godkänt testkonto utanför de tillåtna domänerna/kontona för att kontrollera att inloggningen nekas. Kontrollera tillsammans med AD-teamet det överenskomna LDAP-skyddet för den faktiska anslutningen och stäm av det gällande rotationsintervallet för datorkontot; kontrollera separat ett lösenordsbyte som ska ske senare och räkna inte detta som godkänt utifrån den första inloggningen. Stoppa utrullningen och involvera ansvariga för AD och Mac-datorerna vid oväntad åtkomst till hemkatalogen, oväntad krets av konton som kan logga in, oväntat skydd eller oväntade behörigheter.
6. Tillåt nästa pilotvåg först efter fungerande anslutning, ny inloggning och hanteringssynkronisering. Planera certifikatrotation med överlappning: verifiera först nytt förtroende och ny identitet, ta därefter bort gammal CA eller autentisering. Val av CA för brandväggens TLS-inspektion och allmänna Apple-nätverksprofiler ingår inte i detta beslut om macOS Mobile-policyer.

Återställning vid förlorad anslutning eller fel målgrupp

1. Stoppa utrullningen och dokumentera alla faktiskt berörda konton, enheter, grupper och profilversioner; använd den oberoende åtkomsten för att jämföra aktuell profil med den senast fungerande kombinationen. Kontrollera återigen samtliga tilldelningar av både testpolicyn och återställningspolicyn före varje korrigering. Ta inte omedelbart bort den enda anslutning eller CA som Sophos Mobile fortfarande kan använda för att nå Mac-datorn.
2. Förutsätt inte att den generiska åtgärden Uninstall policy går att använda för macOS: enligt Sophos administratörshjälp tillåts den endast för Android-enhetspolicyer, Knox-containerpolicyer och iOS-enhetspolicyer. Endast om det är styrkt att testpolicyn är tilldelad uteslutande inom piloten: korrigera dess payloads och invänta enhetssynkronisering respektive användarinloggning. Ändra annars ingen policy som tilldelats utanför piloten: avgränsa först omfattningen tillsammans med ansvariga och använd den oberoende åtkomsten. Ett alternativ är att enbart tilldela berörda pilot-Mac-datorer en förberedd och fungerande policy av samma typ; kontrollera först även dess tilldelningar och payloads, redigera ingen delad produktionspolicy för återställning och utlös ingen global grupp- eller Unassign-åtgärd. När en tidigare tilldelad policy ersätts, kontrollera dess beroenden och vilken användar-/enhetskontext som faktiskt gäller. Att ta bort en användarpolicy lokalt är ingen varaktig återställning: den tilldelas igen vid nästa inloggning. Ta inte bort registreringsprofilen som återställningsåtgärd; det avregistrerar Mac-datorn och kräver administratörsbehörighet.
3. Kontrollera alla beroende Wi-Fi-/VPN- och SCEP-/klientcertifikat samt den fungerande alternativa vägen innan en gammal rot-CA tas bort; riskera inte filbehörigheter genom att blint växla profiler om AD-tilldelning eller UID-mappning ändrats. Verifiera återställd nätverksanslutning, inloggning, certifikatkedja och Sophos Mobile-synkronisering på samma pilot-Mac. Om Mac-datorn fortfarande saknar hanteringsåtkomst, kontakta lokal Mac-/nätverks-/PKI-support med de dokumenterade värdena före och efter ändringen.

Valideringens omfattning: Ingen macOS-/tenantkombination har verifierats här i labb. Denna villkorade dokumentation kräver inget generellt tenant-/labbtest före publicering. Före produktionsinförande i den specifika miljön eller påstående att anslutningen fungerar ska edition/licens, macOS-version, policyns omfattning och Apple Business-användartilldelning, enhetssynkronisering och användarinloggning, PKI-förtroende, Wi-Fi-EAP och faktiskt använd klientidentitet verifieras på en godkänd pilot-Mac. För SCEP som Wi-Fi-identitet måste den egna tenanten visa om den utfärdade identiteten går att välja i Sophos-fältet Identity certificate eller faktiskt binds på annat sätt i den levererade Wi-Fi-profilen; kontrollera dessutom identitet/fingeravtryck i rätt enhets-/användarnyckelring och en lyckad EAP-/RADIUS-inloggning med just detta certifikat på en hanterad pilot-Mac. Enbart utfärdat certifikat eller installerad profil räcker inte. Även för SCEP som VPN-identitet måste val eller levererad bindning, rätt nyckelrings-/användarkontext och lyckad VPN-inloggning med det förväntade certifikatet verifieras på pilotdatorn; Sophos VPN-hjälp nämner certifikatfält men ingen väg för SCEP-koppling. SCEP-bindning till Wi-Fi/VPN är fortfarande oklar och är ingen operativ väg utan en lyckad godkänd pilot. Testa VPN-app/leverantör/autentisering, certifikatrotation, oberoende åtkomst samt policyersättning och återställning på enheten före produktionsanvändning.