Planera Wi-Fi, certifikat, VPN och proxy för Apple-enheter med Sophos Mobile

Omfattning: Sophos Mobile i Sophos Fusion (tidigare Sophos Central), iPhone och iPad med iOS/iPadOS. Den här orienteringen skiljer mellan iOS-enhetspolicyer (Device Policy) och iOS-användarpolicyer (User Policy). Den är inte en testad steg-för-steg-konfiguration för en viss miljö, ingen macOS-guide och inget godkännande för storskalig produktionsdistribution. Kontrollera först operativsystemsversion, registreringsläge, övervakning (Supervision), policytyp och tillgängliga funktioner i den egna miljön på målenheten.

⚠️ Bryt inte anslutningen: Ett felaktigt Wi-Fi-/EAP-certifikat, en SCEP-CA som inte kan nås, en felaktig PAC/WPAD-konfiguration eller en VPN-tunnel kan också bryta återkanalen för MDM-uppgifter. Före ändringar måste en anslutning som är oberoende av den ändrade profilen och en lokal väg för felsökning vara verifierade. En återgång som sparats i konsolen når inte automatiskt en enhet som har låsts ute och är offline.

Skilj först mellan hanteringslägena

Device Enrollment innebär inte automatiskt Supervision (övervakning): Automated Device Enrollment ger övervakning, medan andra metoder inte nödvändigtvis gör det. Apple User Enrollment ger aldrig övervakning och omfattar hanterade data, inte hela den privata enheten. För BYOD måste ett Managed Apple Account och samtycke finnas med i förberedelserna. Där finns ingen global HTTP-proxy, inget vanligt VPN för hela enheten och inga proxyinställningar i den hanterade Wi-Fi-konfigurationen; Sophos kan inte hämta MAC/UDID/IMEI för identifiering i NAC.

Sophos begränsar profilbaserat User Enrollment till iOS/iPadOS 17 eller äldre; det innebär inte att account-driven User Enrollment generellt har avskaffats. Vid avregistrering tas den hanterade APFS-volymen och det hanterade Apple-kontot bort från enheten; det är inte en generell återgång för Wi-Fi eller VPN. Apple beskriver VPN per app som en möjlig funktion vid User Enrollment, inte som belägg för att Sophos appkoppling fungerar.

Planera Wi-Fi och certifikatkedjan tillsammans

Isolera BYOD-piloten före varje ändring: För iOS-/iPadOS-användarpolicyer synkroniserar Sophos ändringar automatiskt varje gång enheten återansluter till Sophos Mobile; någon manuell Update devices behövs inte. Använd därför en separat användarpolicy som endast är tilldelad den godkända BYOD-testenheten och kontrollera dess aktuella tilldelningar och antalet målenheter före redigering och före Save. Ändra inte en policy som redan delas med BYOD-enheter i produktion för piloten. En efterföljande tilldelning till utvalda testenheter begränsar inte synkroniseringen av ändringen till andra enheter som samma policy redan är tilldelad. Denna avgränsning gäller även certifikatändringar och korrigeringar vid återgång; synkroniseringen i sig bekräftar varken nätverksfunktion eller MDM-återväg.

Vem kontrollerar vem? Vid företags-Wi-Fi med EAP (autentisering mellan enhet och nätverk) kontrollerar enheten RADIUS-serverns namn och certifikatkedja. Vid certifikatbaserad inloggning kontrollerar RADIUS i sin tur den utfärdade klientidentiteten. Serverns CA och klientidentiteten har alltså olika uppgifter. Fältet Identity certificate i Wi-Fi-konfigurationen kräver en Client certificate-konfiguration i samma policy; servercertifikatet under Trusted certificates kräver en Root certificate-konfiguration där.

Endast fiktiva platshållare – använd dem inte direkt: radius.test.invalid som servernamn, Test-CA som betrodd server-CA och CN=Testperson,OU=Pilot,O=Beispiel som X.500-subjekt (fält för klientidentiteten). Ersätt alla värden med namn, CA och identitetsfält som har bekräftats av det egna PKI-/RADIUS-teamet. Kontrollera på testenheten att den konfigurerade serveridentiteten stämmer med den verkliga kedjan och att RADIUS godtar det utfärdade klientcertifikatet. Rotcertifikatet är ett X.509-certifikat i PEM/DER; ett importerat klientcertifikat är PKCS#12 (.pfx). En uppladdad .pfx kan inte automatiskt återanvändas i flera policyer: om klientcertifikatet behövs i en annan policy måste det laddas upp igen i den policyn. Kontrollera CA:ns ursprung, vem som innehar nyckeln, giltighet och avsett användningsområde. Att ladda upp en rot-CA bevisar inte att alla appar litar på den.

För Root certificate i en iOS-enhetspolicy öppnar du konfigurationen på Edit policy via Add configuration > Root certificate. Välj X.509-filen i PEM/DER med Upload a file och öppna den med Open. Efter uppladdningen visar Certificate name utfärdarens Distinguished Name (DN), inte klientidentiteten. Spara konfigurationen med Apply och spara därefter policyn med Save på Edit policy. Enligt Sophos installerar tilldelningen av policyn det uppladdade rotcertifikatet på enheten. Visningen och sparandet i sig bevisar varken tillit, giltighet eller lyckad installation. För varje ytterligare rotcertifikat krävs en separat Root certificate-konfiguration i samma policy.

För Root certificate i en iOS-användarpolicy beskriver Sophos importen på Edit policy via Add configuration > Root certificate. Välj X.509-filen i PEM/DER med Upload a file och öppna den med Open. Efter uppladdningen visar Certificate name utfärdarens Distinguished Name. Spara konfigurationen med Apply och spara därefter policyn med Save på Edit policy. Lägg till en separat Root certificate-konfiguration för varje ytterligare rotcertifikat. Enligt Sophos installerar tilldelningen av användarpolicyn certifikatet på enheten; inom samma policy kan det exempelvis användas som EAP-servercertifikat i Wi-Fi. Uppladdningsvisningen och den sparade policyn bevisar varken lyckad installation, certifikattillit eller fungerande Wi-Fi-inloggning.

I konfigurationen Client certificate i iOS-enhetspolicyn väljer du först Upload a file under File och därefter PKCS#12-certifikatfilen (.pfx). Under Certificate name visar Sophos Mobile namnet som lästs från certifikatfilen. Namnet i sig visar varken att certifikatet är betrott eller giltigt, eller att installationen har lyckats.

Före SCEP-konfigurationen: Om du använder SCEP-anslutningen som konfigurerats i Sophos setup med variablerna nedan, kontrollera först flödet för SCEP-förutsättningar och certifikat: nåbarhet från Sophos Fusion till CA:n, regionalt avgränsade brandväggsöppningar och, för denna dokumenterade Windows-CA-väg, ett konto med behörighet att skapa challenges och registrera certifikat. Lägg före SCEP till SCEP-serverns CA-certifikat som Root certificate i samma policy. Denna servertillit är skild från tilliten till RADIUS-servern och den utfärdade klientidentiteten; Windows framställs därmed inte som ett krav för varje direkt SCEP-implementation.

Med SCEP (Simple Certificate Enrollment Protocol) kan en enhet begära ett certifikat från CA:n. Det kräver en nåbar CA-URL eller en korrekt konfigurerad Sophos-SCEP-proxyvariabel. Låt PKI-teamet anpassa X.500-subjektfält och SAN/UPN (ytterligare identitetsnamn), challenge, parametrar för återförsök vid väntande ansökningar, nyckellängd och användningsbitar till den egna CA:n. För SCEP-konfigurationen i en iOS-enhetspolicy är följande beslut viktiga:

• CA-slutpunkt och namn: URL är CA-serverns webbadress. %_SCEPPROXYURL_% hänvisar till serverns URL på fliken SCEP på sidan Sophos setup. CA name är ett namn som CA:n förstår; det kan exempelvis användas för att skilja mellan CA-instanser. Bekräfta med PKI-teamet vilket namn den egna CA:n förväntar sig. Fältet är inte visningen Certificate name för ett importerat certifikat och inte exempelnamnet på den betrodda RADIUS-serverns CA.
• Användar- eller enhetsidentitet: Subject får innehålla platshållare för användardata eller enhetsegenskaper. Sophos anger CN=%_USERNAME_% för en användare och CN=%_DEVPROP(SerialNumber)_% för en iPhone eller iPad. Det är dokumenterade syntaxexempel, inte värden som har kontrollerats för den egna miljön. Låt PKI-teamet godkänna den önskade identiteten och kontrollera att uppgifterna är tillgängliga och att subjektet efter ersättning är ett giltigt X.500-namn. BYOD: En dokumenterad platshållare för serienummer bevisar inte att en identitet baserad på serienummer kan tas fram vid User Enrollment; Sophos kan inte hämta enhetsidentifierare där. Kontrollera subjekt och utfärdande med en testperson.
• SAN-typ och värde: Välj den typ som PKI-teamet har godkänt under Type of Subject Alternative Name och ange motsvarande värde under Value of Subject Alternative Name. RFC 822 name avser en giltig e-postadress. För denna iOS-SCEP-konfiguration beskriver Sophos DNS name som CA-serverns DNS-namn och Uniform resource identifier som dess fullständigt kvalificerade URL – inte som RADIUS-serverns namn eller challenge-adressen. AD user logon name är separat och avser det UPN som angetts i Active Directory. Challenge är webbadressen där enheten hämtar ett challenge-lösenord från SCEP-servern. %_CACHALLENGE_% hänvisar till den challenge-URL som konfigurerats på fliken SCEP på sidan Sophos setup, inte till själva lösenordet. Ta inte med verkliga hemligheter i offentliga exempel eller ärenden.
• Väntande ansökningar: Retries anger antalet återförsök när servern svarar med pending; det är inte en allmän räknare för återförsök vid alla nätverksfel. Retry delay är tiden mellan dessa försök i sekunder. Kom överens om antal och tidsavstånd med PKI-teamet och förväxla dem inte med certifikatförnyelse.
• Nycklar och användningsområde: Key size anger storleken på den offentliga nyckeln i det utfärdade certifikatet och måste stämma överens med storleken som konfigurerats på SCEP-servern. Certificate usage anger tillåtet användningsområde: Use as digital signature för digitala signaturer och Use for encryption för datakryptering. Valet måste passa PKI-kraven och måltjänsten; det bevisar varken lyckad Wi-Fi-/VPN-inloggning eller kryptering av all enhetstrafik.

När policyn skapas finns fältet SCEP renewal interval. Kontrollera intervall, utgång, återkallelse och ersättning med PKI-teamet; ett inställt intervall garanterar varken lyckad förnyelse eller återställning av en enhet som har förblivit offline.

Identitetsersättning i enhets- och användarpolicyer: I exemplet CN=%_USERNAME_% ovan ersätts %_USERNAME_% med Exchange Login för den användare som är tilldelad enheten, inte nödvändigtvis med användarens visningsnamn och inte automatiskt med AD-UPN. Kontrollera rätt användartilldelning och detta egenskapsvärde före tilldelningen; det ersatta subjektet måste fortfarande vara ett giltigt X.500-namn som godkänts av PKI-teamet. AD user logon name förblir det separata UPN-fältet.

För SCEP i en iOS-användarpolicy ska slutpunkterna anges separat. URL är CA-serverns webbadress. Variabeln %_SCEPPROXYURL_% hänvisar till serverns URL på fliken SCEP på sidan Sophos setup. Challenge är URL:en för att hämta ett challenge-lösenord från SCEP-servern, inte själva lösenordet. %_CACHALLENGE_% hänvisar till den challenge-URL som konfigurerats där på fliken SCEP. Precis som för ansökningsparametrarna ovan räknar Retries endast återförsök efter ett pending-svar; Retry delay anger tiden mellan dem i sekunder. Key size måste motsvara storleken på den offentliga nyckeln som konfigurerats på SCEP-servern. Bekräfta dessa parametrar med PKI-teamet; de är inte förnyelseintervall och bevisar inte lyckat utfärdande.

Företags-Wi-Fi och privat Wi-Fi-adress

För en isolerad Wi-Fi-pilot med enhetspolicy kopplar följande flöde nätverksuppgifterna till policytilldelningen. Säkra först den oberoende nät- och återvägen från pilotavsnittet; redigera inte någon policy som är tilldelad produktionsenheter.

1. Öppna den Apple-plattform som passar målenheten under Policies, skapa en enhetspolicy med Create och ange namn, beskrivning och organisationsnamn. Lägg till konfigurationen Wi-Fi med Add configuration på Edit policy och öppna dess namn för att redigera den. För företags-Wi-Fi ska du först tillhandahålla de klient- och rotcertifikat som behövs i samma policy enligt ovan; Apply i rotcertifikatkonfigurationerna ersätter inte Save för hela policyn.
2. Ange det Wi-Fi-namn som nätverksteamet har bekräftat under SSID och anpassa Security type till den faktiska metoden och dess Personal-/Enterprise-variant. Personal kräver Wi-Fi-lösenordet; för Enterprise används EAP-, inloggnings- och tillitsinställningarna som beskrivs nedan. Connect automatically ansluter automatiskt när nätverket är tillgängligt; Hidden network avser ett nätverk som inte sänder ut sitt SSID. Välj båda alternativen enbart utifrån det avsedda nätverket, inte som belägg för säkerhet.
3. Kontrollera alla konfigurationer och spara policyn med Save på Edit policy. Använd sedan flödet ”Skapa och tilldela policyn” för tilldelningen: välj den sparade pilotpolicyn, markera endast de enskilda godkända testenheterna och stäm av listan och antalet före Finish. Följ förbehållen där om schemaläggning och iPadOS. Observera därefter uppgifts-/tilldelningsstatus, faktisk Wi-Fi-inloggning och MDM-incheckning var för sig enligt kontrollkriterierna nedan; sparande och tilldelning är inte bekräftade anslutningsresultat.

För Wi-Fi-konfigurationen i en iOS-enhetspolicy ska du först välja Security type så att det passar nätverket. Vid en Personal-variant kan Wi-Fi-lösenordet anges. Endast en Enterprise-variant erbjuder Protocols, Authentication och Trusted certificates. Anpassa de metoder som enheten godtar under Accepted EAP types till nätverksinloggningen tillsammans med RADIUS-teamet. Klient- och rotcertifikaten som beskrivs ovan är fortfarande bundna till samma policy.

Under Authentication i iOS-enhetspolicyn är User Wi-Fi-användarnamnet och Password Wi-Fi-lösenordet för inloggning med inloggningsuppgifter. Enligt Sophos skickar Require password on each connect lösenordet vid varje autentisering; alternativet utlovar ingen interaktiv lösenordsfråga. Stäm av inloggningsvägen och detta val med RADIUS-teamet. Vid certifikatbaserad inloggning väljer du i stället rätt Identity certificate från en Client certificate-konfiguration i samma enhetspolicy. Kontrollera på testenheten att RADIUS godtar inloggningsuppgifterna eller klientcertifikatet beroende på vald väg; serveridentiteten och tillitskedjan ska fortfarande kontrolleras separat i båda fallen.

Vid TTLS avser Internal identity protokollet för användarinloggningen inne i tunneln. Det är inte den yttre identiteten. För EAP-FAST kan en Protected Access Credential (PAC) konfigureras; denna PAC är inte ett skript för automatisk proxykonfiguration. Klargör TTLS-protokollet och vid behov EAP-FAST-autentiseringsuppgiften med RADIUS-teamet och kontrollera inloggningen på målenheten. Undanta den berörda EAP-grenen från piloten om detta inte har klargjorts.

Ange båda TLS-gränserna för EAP eller lämna båda öppna. Sophos beskriver Outer identity för TTLS, PEAP och EAP-FAST och kräver en yttre identitet för TLS 1.3. Använd inte användarnamn eller hemligheter där eftersom den yttre identiteten överförs i klartext. Låt vid behov PKI-/RADIUS-teamet kontrollera att en anonym yttre identitet med rätt realm fungerar för routningen. Observera den förhandlade inloggningen och TLS-versionen på testenheten; valet i sig bevisar inte en lyckad anslutning.

Turn off private address gör att enheten använder sin hårdvaru-MAC-adress för detta Wi-Fi i stället för en nätverksspecifik adress som genererats av iOS. Det försämrar integriteten. Använd endast alternativet om enheten måste identifieras med samma MAC-adress i de egna nätverken. Enligt Sophos fungerar Synchronized Security inte med privata MAC-adresser: Sophos Fusion Wireless känner endast till den privata adressen, medan Sophos Mobile endast känner till hårdvaruadressen. Att stänga av funktionen garanterar dock inte i sig fungerande Synchronized Security; kontrollera kopplingen och det önskade beteendet i det avsedda nätverket. Behandla det inte som en BYOD-genväg för NAC. Vid User Enrollment har Sophos inte tillgång till MAC-adressen för NAC.

Även för Wi-Fi i en iOS-användarpolicy skiljer Sophos mellan Personal och Enterprise under Security type. Personal använder Wi-Fi-lösenordet. Protocols, Authentication och Trusted certificates är endast tillgängliga för Enterprise. Vid inloggning med inloggningsuppgifter är User Wi-Fi-användarnamnet och Password Wi-Fi-lösenordet. Enligt Sophos skickar Require password on each connect lösenordet vid varje autentisering. Stäm av valet med RADIUS-teamet och tolka det inte som ett löfte om en lösenordsfråga. Vid certifikatbaserad inloggning ska du i stället välja rätt Identity certificate från en Client certificate-konfiguration i samma användarpolicy. Även servercertifikatet under Trusted certificates kräver en Root certificate-konfiguration i denna policy. Använd klientcertifikatet och RADIUS godkännande av det som kontrollkriterier endast för den certifikatbaserade inloggningsvägen.

Enligt Wi-Fi-beskrivningen gäller EAP-besluten ovan även för denna användarpolicy. Anpassa Accepted EAP types till nätverksinloggningen, klargör protokollet under Internal identity vid TTLS och vid behov Protected Access Credential (PAC) vid EAP-FAST. Denna autentiseringsuppgift är inte ett proxy-PAC-skript. Ange båda TLS-gränserna eller lämna båda öppna. Outer identity beskrivs för TTLS, PEAP och EAP-FAST och krävs för TLS 1.3. Följ anvisningarna ovan om klartext och realm. Dra inte slutsatsen att alla alternativ är tillgängliga i den egna miljön eller att inloggningen har lyckats; begränsningen som utesluter en hanterad Wi-Fi-proxy och förbehållet om MAC/NAC vid User Enrollment gäller fortfarande.

Proxy och VPN är olika ingrepp

• Wi-Fi-proxy: Kan konfigureras manuellt eller via PAC (fil med proxyregler) i iOS-enhetspolicyn. Vid Apple User Enrollment stöder Wi-Fi-konfigurationen ingen proxy. Sophos nämner WPAD (automatisk identifiering av proxy) på åtkomstpunkten och att användaren själv väljer HTTP-proxy: Automatiskt i Wi-Fi-inställningarna som möjliga kringvägar – inte som en fjärrhanterad BYOD-proxykonfiguration. Testa PAC/WPAD, DNS och nåbarhet var för sig.
• Global HTTP-proxy: Sophos tillåter denna iOS-enhetskonfiguration endast för övervakade enheter; manuellt med server/port/eventuella inloggningsuppgifter eller automatiskt med PAC-URL. I manuellt läge är Server HTTP-proxyns namn eller IP-adress och Port dess portnummer. Authentication är användarnamnet för anslutningen till proxyservern och Password det tillhörande lösenordet. Det är varken ett löfte om stöd för BYOD eller om tillgänglighet vid fel.
• VPN för hela enheten: iOS-enhetspolicyn har anslutningstyp, server och autentisering; vid Custom SSL/TLS måste leverantörens app vara installerad. Överför inte denna konfiguration till Apple User Enrollment: Apple tillåter inte ett vanligt VPN för hela enheten där.
• VPN per app: En separat konfiguration för utvalda appar, inte samma sak som VPN för hela enheten. Kontrollera separat leverantörens app, server, autentisering, valfria certifikat/proxy, On-Demand och domänregler för Safari/andra webbläsare, kalender, kontakter och e-post. Kontrollera även Send all traffic through VPN utifrån dess faktiska räckvidd; dra inte slutsatsen av namnet att alla appar isoleras eller att hela enheten påverkas. Sophos dokumentation är här inte entydig: Beskrivningen av användarpolicyn innehåller VPN per app, men beskrivningen av appkoppling anger endast Device Policies som förutsättning och val. Påstå därför inte att det finns en fungerande klickväg för BYOD-koppling: verifiera först med en testapp och testenhet i den aktuella miljön.

Enhets-VPN: leverantör, inloggning och trafikväg

Följande uppgifter hör till VPN-konfigurationen i en iOS-enhetspolicy, inte till konfigurationen för VPN per app eller till Apple User Enrollment. Kontrollera tillgänglighet och leverantörsstöd i den egna miljön. Connection name är anslutningens namn som visas på enheten. Ange VPN-serverns värdnamn eller IP-adress under Server; bekräfta rätt slutpunkt med den VPN-ansvariga.

• Välj rätt leverantör eller anslutningstyp under Connection type. För en VPN-leverantörsapp från App Store beskriver Sophos Custom SSL/TLS. Appen måste vara installerad; ange dess identifierare i omvänd DNS-form under Identifier (reverse DNS format). Om leverantören anger egna anslutningsparametrar ska de bekräftade nycklarna och värdena anges som anslutningsegenskaper under Third-party settings. Använd inte nycklar eller värden från andra leverantörskonfigurationer.
• User authentication gäller användarinloggningen. Account är användarkontot för VPN-anslutningen; Group kan ange en autentiseringsgrupp som krävs för den. Ange VPN-lösenordet vid Password och VPN-autentiseringscertifikatet vid Certificate. Klargör med den VPN-ansvariga om en grupp behövs och vilken identitet som ska användas. Dessa inloggningsuppgifter är inte proxyinloggningsuppgifter.
• Device authentication är separat. Vid Keys (Shared Secret)/Group name ska den grupp som krävs anges under Group name och den delade nyckeln under Keys (Shared Secret). Sophos nämner även Use hybrid authentication och Request password, men beskriver på denna sida endast att de ska väljas efter behov. Deras effekt och vilka val som krävs är inte klarlagda här; ta med dessa två alternativ i piloten först efter bekräftelse från leverantören. Vid Certificate ska det enhetsautentiseringscertifikat som krävs väljas. Enligt Sophos inkluderar Including user PIN valfritt användarens PIN-kod i enhetsautentiseringen. Överför inte någon av dessa grenar till alla leverantörer utan kontroll och dokumentera inte verkliga nycklar eller PIN-koder i ärenden.
• Send all traffic through VPN är inställningen för att skicka all trafik genom denna VPN-anslutning. Sophos beskriver att all trafik då skickas genom VPN. Kontrollera den faktiska trafikvägen på testenheten i valt leverantörs-/tunnelläge och kontrollera MDM-återkanalen separat. Det bevisar inte att all trafik fångas upp utan luckor eller att appar isoleras.
• Ange proxyn för denna VPN-anslutning under Proxy. No proxy innebär att anslutningen inte har någon proxy. Vid Manually ska proxyadressen och porten anges under Server and port; Authentication är proxyanvändarnamnet och Password dess lösenord. Vid Automatic ska URL:en till servern med proxyinställningarna anges under Proxy server URL. Detta val är varken Wi-Fi-proxyn eller den globala HTTP-proxykonfigurationen; dra inga slutsatser om krav på övervakning eller felsäkerhet utifrån det.
• Provider type skiljer mellan transportnivåer, inte mellan leverantörerna i Connection type. App proxy transporterar trafik i VPN-tunneln på applikationsnivå, medan Packet tunnel gör det på nätverksnivå. App proxy är därför inte samma sak som VPN per app. Vilket val leverantören stöder och vilken trafik det faktiskt fångar upp måste fortfarande kontrolleras på målenheten.

VPN per app: inmatningar och anslutningsstart

För Per app VPN i en iOS-enhetspolicy beskriver Sophos följande inmatningar och beteenden; effekten måste fortfarande kontrolleras i piloten. Dessa uppgifter löser inte motsägelsen ovan om appkoppling i användarpolicyer.

För Per app VPN i både iOS-enhetspolicyer och iOS-användarpolicyer är Connection name anslutningens namn som visas på enheten. Det är anslutningens synliga benämning, inte leverantörsappens identifierare i omvänd DNS-form, serveradressen eller användarkontot.

• Leverantörens app: Om VPN-leverantören har en app i App Store som tillhandahåller VPN-anslutningen ska Custom SSL/TLS väljas. Denna VPN-app måste vara installerad på enheten; ange dess identifierare i omvänd DNS-form under Identifier (reverse DNS format), inte identifieraren för verksamhetsappen vars trafik ska gå genom tunneln.
• VPN-inloggning: Server är VPN-serverns värdnamn eller IP-adress och Account användarkontot för autentisering av anslutningen. Välj mellan Password och Certificate under User authentication och ange motsvarande VPN-lösenord under Password eller VPN-autentiseringscertifikat under Certificate. Dessa uppgifter är separata från inloggningsuppgifterna för en anslutningsproxy.
• Anslutningsstart: Om Connect automatically on demand är aktiverat aktiverar enheten enligt Sophos VPN när appen upprättar en nätverksanslutning. Om alternativet är avstängt måste användarna själva aktivera VPN. Kontrollera båda förloppen på den avsedda testenheten.
• Anslutningsproxy: Proxy erbjuder No proxy, Manually och Automatic. Vid manuell konfiguration ska den giltiga proxyadressen och porten anges under Server and port, proxyanvändarnamnet under Authentication och dess lösenord under Password. Vid automatisk konfiguration ska URL:en till servern med proxyinställningarna anges under Proxy server URL. Det är proxyn för denna VPN-anslutning, inte den globala HTTP-proxykonfigurationen.

Samma inmatningssyntax gäller för Domains in Safari, Domains in Calendar, Domains in Contacts och Domains in Mail: en domän, deldomän eller ett värdnamn per rad. En deldomän matchar om alla punktavgränsade delar stämmer överens räknat från höger; inledande och avslutande punkter ignoreras. En sträng utan punkt matchar endast värden med det namnet, inte godtyckliga domäner med den ändelsen. Den ytterligare regeln om andranivådomän för kalender, kontakter och e-post gäller också; pilotavsnittet beskriver det lämpliga positiva testet.

VPN per app i användarpolicyn och appkoppling

Sophos beskrivning av Per app VPN i en iOS-användarpolicy dokumenterar också de inmatningar som förklaras ovan för den installerade VPN-leverantörsappen och dess identifierare i omvänd DNS-form, inloggningen med Password eller Certificate, anslutningsstart på begäran, anslutningsproxyn och domänsyntaxen. Dessa dokumenterade likheter bevisar inte att det finns en fungerande kopplingsväg vid Apple User Enrollment.

Sophos dokumenterar följande villkorade fält för Per app VPN i både iOS-enhetspolicyer och iOS-användarpolicyer. Villkoren gäller för båda policytyperna; kontrollera tillgänglighet och leverantörsstöd i den egna miljön:

• Under Third-party settings kan anslutningsegenskaper som VPN-leverantören anger registreras. Fältet är endast tillgängligt vid Custom SSL/TLS. Ange de bekräftade värdena för Key och Value med Add. Dessa anslutningsegenskaper är inte Managed configuration för verksamhetsappen vars trafik ska gå genom tunneln.
• Group avser gruppen som krävs för inloggningen. Fältet är endast tillgängligt för Cisco AnyConnect och Cisco Legacy AnyConnect. Överför inte detta villkor till andra anslutningstyper.
• Vid Provider type transporterar App proxy trafiken i VPN-tunneln på applikationsnivå och Packet tunnel på nätverksnivå. För Cisco AnyConnect är denna inställning inte tillgänglig. Kontrollera på den avsedda testenheten vilket val leverantören stöder och vilken trafik det faktiskt fångar upp. Transportnivån i sig bevisar varken appisolering eller en VPN-effekt för hela enheten.

Kopplingen av en befintlig anslutning till verksamhetsappen hör till appdistributionsflödet i avsnittet ”Kontrollera hanterad konfiguration och appbeteende”. Där är Tilldela Per-app-VPN uttryckligen begränsat till befintliga enhetspolicyer. De policyansvariga tillhandahåller rätt anslutning; de appansvariga väljer den i VPN connection used by the app. Denna hänvisning löser inte osäkerheten ovan om användarpolicyer och godkänner inte någon oprövad BYOD-kopplingsväg.

Kontrollera i förväg, observera i piloten och avgränsa fel

1. Inventering och återväg: Anteckna ägare, registreringsläge, Supervision, iOS/iPadOS-version, berörd policy och tilldelning. Dokumentera för både en övervakad företagsenhet och en frivillig BYOD-testenhet en oberoende nätväg (exempelvis mobilnät eller annat Wi-Fi) och ansvarig kontaktperson. Tilldela ingen ändring som kan spärra åtkomsten utan denna väg. Använd en testpolicy som endast är tilldelad företagets pilotenhet vid ändringar i iOS-enhetspolicyer och kontrollera dess aktuella tilldelningar och antalet målenheter innan enheterna uppdateras; ändra inte en policy som redan är tilldelad produktionsenheter för piloten.
2. Beroenden: Testa nåbarhet för DNS, APNs/MDM, CA/SCEP/RA, RADIUS/EAP-server, PAC/WPAD och VPN-slutpunkt före och efter ändringen. Kontrollera certifikatkedja, servernamn, utgångsdatum och planerad ersättning; kopiera inte privata nycklar, challenges eller inloggningsuppgifter till ärenden. En giltig policytilldelning bevisar inte i sig att Wi-Fi eller VPN fungerar.
3. Avgränsad pilot: Börja med separata testenheter och minimal tilldelning. Dokumentera följande som kontrollkriterier, inte bekräftade resultat: Enheten godtar den kontrollerade RADIUS-serveridentiteten och ansluter till företagets Wi-Fi. Vid certifikatbaserad inloggning ska du dessutom kontrollera att klientcertifikatet tas emot och godtas av RADIUS; vid inloggning med användarnamn och lösenord ska den avsedda vägen för inloggningsuppgifter kontrolleras. Vid VPN per app, kontrollera tunneltrafiken från den tilldelade hanterade testappen; använd åtkomst från andra appar som negativt test endast om apparna varken omfattas av en annan VPN-koppling eller träffas av en konfigurerad domänregel. Om domäner har angetts för Safari/andra webbläsare, kalender, kontakter eller e-post, kontrollera också avsedd åtkomst till matchande domäner och förvänta dig inte generellt att ”annan åtkomst sker utan tunnel”. Kontrollera Safari-/webbläsardomäner separat: För positiva tester med kalender, kontakter och e-post kräver Sophos dessutom att andranivådomänen i den angivna domänen är densamma som VPN-serverns andranivådomän. En domän som inte uppfyller detta är inget giltigt positivt tunneltest, och utebliven tunneltrafik för den bevisar inte i sig att VPN-distributionen misslyckades. Kontrollera domänreglerna i den egna miljön i stället för att dra slutsatser om ett oprövat konfigurationsrecept. Kontrollera effekten av Send all traffic through VPN separat på testenheten i valt leverantörs-/tunnelläge; dra inga oprövade slutsatser om effekt för hela enheten eller appisolering. Vid VPN per app i en användarpolicy, verifiera den appkoppling som faktiskt finns tillgänglig eller undanta tills vidare funktionen. För PAC/WPAD, observera den definierade vägen vid fel i webbåtkomst/proxy; bekräfta efter varje ändring både en ny MDM-incheckning och faktisk nätverksfunktion var för sig. Om incheckningen uteblir eller den oberoende nätvägen saknas, stoppa piloten och tilldela inte fler enheter.
4. Avgränsa felet: Om Wi-Fi saknas, kontrollera först SSID och säkerhetstyp, EAP-servernamn och betrodd CA; vid inloggning med inloggningsuppgifter, kontrollera användarnamn, lösenord och den avsedda RADIUS-inloggningsvägen, och vid certifikatbaserad inloggning, utfärdad klientidentitet och CA-nåbarhet; vid avbrott i webbåtkomst, PAC/WPAD/DNS och proxyinloggning; vid appavbrott, leverantörens app, tunnel, certifikat och koppling. Observera uppgift/incheckning och faktisk anslutning var för sig. Orsaka inte ett andra avbrott genom okontrollerad borttagning av certifikat eller profiler.

Återgå utan att nollställa enheten

Förbered före piloten en fungerande ersättningspolicy och en ersättande tillitskedja med ett nåbart nätverk. Ta inte bort gammal CA och gamla identitetscertifikat förrän ersättningen har bekräftats på målenheten och MDM-incheckning har skett.

För iOS-enhetspolicyer kräver ändringar enligt Sophos Update devices: det skapar en uppdateringsuppgift för alla enheter som den ändrade policyn är tilldelad, inte bara pilotenheten. Uppdatera därför endast den isolerade pilotpolicyn efter att ha kontrollerat dess aktuella målenheter; en riktad Assign policy-uppgift för utvalda enheter är inte samma sak som att uppdatera en policy som är tilldelad flera enheter. Den riktade uppgiften Uninstall policy är avsedd för Device Enrollment, men kan själv ta bort nätvägen. För iOS-användarpolicyer på enheter med User Enrollment finns inte denna Uninstall policy-uppgift: Sophos erbjuder i stället den riktade uppgiften Unassign iOS user policy. Att uppdatera eller tilldela en annan policy kan också vara lämpligt beroende på felet. Förväxla inte den riktade uppgiften med Unassign för alla enheter.

iPadOS: skilj mellan direkta åtgärder och uppgiftstyper. Policyanvisningen förklarar den oenhetliga benämningen av direkta uppdaterings- och avinstallationsvägar: typöversikten anger iOS/iPadOS, medan de direkta anvisningarna endast anger iOS device policies. Överför därför inte deras klickföljd till iPadOS utan kontroll; klarlägg vilken direkt väg som finns i den egna miljön och på pilotenheten. Det betyder inte att återgång på iPadOS generellt är odokumenterad eller omöjlig: iOS-/iPadOS-uppgiftstyperna dokumenterar Uninstall policy för Device Enrollment och Unassign iOS user policy för User Enrollment. Det lägesberoende flödet för uppgiftspaket beskriver detta val; kontrollera fortfarande uppgiftsöverföringen och återgångens faktiska effekt var för sig.

Kontrollera återgången separat på en nåbar företagsägd testenhet med Device Enrollment och en nåbar BYOD-testenhet med User Enrollment: prova den riktade uppgiften Uninstall policy för just företagsenheten och den riktade uppgiften Unassign iOS user policy för BYOD-enheten. Bekräfta för varje enhet uppgiftens/incheckningens status och faktiskt synkroniserat policyläge; testa därefter Wi-Fi-/VPN-funktion och MDM-kontakt igen var för sig. Begränsa ytterligare tilldelningar eller återgångar till de testenheter som faktiskt har kontrollerats tills båda återvägarna är verifierade. En sparad eller skickad uppgift når inte automatiskt en offline-enhet som har låsts ute. Då behövs den i förväg planerade oberoende nätvägen och en lokal väg för felsökning; Unassign för alla enheter är inte en riskfri omedelbar åtgärd. Varken fullständig radering (Wipe) eller avregistrering från User Enrollment är en generell återgång för en policy.