Sophos Mobile: zarządzanie łącznością macOS za pomocą polityki urządzenia lub użytkownika

Ten artykuł dotyczy polityk Sophos Mobile na zarządzanych Macach, a nie ogólnej konfiguracji Apple Wi-Fi/VPN, Sophos Endpoint, ZTNA ani konfiguracji Sophos Firewall. Instrukcję instalacji klienta i zdalnego dostępu przez zaporę, zamiast polityki Mobile, znajdziesz w artykule Sophos Connect na macOS. Kontekst urządzenia i użytkownika jest odrębny: jednakowe nazwy konfiguracji nie oznaczają, że tożsamość, dostęp do certyfikatów i moment zastosowania są wymienne. Samo przypisanie profilu nie dowodzi, że połączenie działa.

Wymagania wstępne: najpierw zabezpiecz dostęp administracyjny i drogę powrotu

• Wymagana licencja MDM: Zarządzanie Macami wymaga Sophos Mobile Device Management, dostępnego jako samodzielna licencja lub w ramach łączonej licencji Sophos Mobile. Sama licencja Sophos Mobile Threat Defense nie wystarcza: obejmuje zarządzanie Sophos Intercept X for Mobile i Sophos Chrome Security, a nie zarządzanie Macami przez MDM. Przed utworzeniem polityk sprawdź w tenantcie odpowiednie uprawnienie licencyjne MDM.
• Sprawdź, czy Mac jest zarejestrowany w Sophos Mobile, jakiej wersji macOS używa, jakie polityki już mu przypisano oraz czy wymagana funkcja ma obejmować urządzenie czy określonego użytkownika. Maki mają w Sophos Mobile tylko jeden tryb zarządzania, ale mogą korzystać z polityk urządzenia, deklaratywnych i użytkownika. Apple User Enrollment dla prywatnych iPhone’ów/iPadów nie jest trybem rejestracji macOS. Przy ręcznej rejestracji Maca rejestrację musi przeprowadzić użytkownik, którym ma być zarządzany, i podać hasło administratora dla profilu rejestracji; przy automatycznej rejestracji przez Apple Business sprawdź pod Assign user to device, czy wybrano No (bez przypisania użytkownika podczas rejestracji), czy Yes - LDAPS authentication. Nie wywódź przypisania użytkownika z polityki urządzenia.
• Polityki urządzenia dotyczą wszystkich użytkowników Maca. Polityki użytkownika dotyczą użytkownika, który lokalnie przeprowadził rejestrację, oraz użytkowników sieciowych znanych Sophos Mobile z zewnętrznego katalogu LDAP portalu Self Service Portal. Jeśli polityka urządzenia dołączy Maca do tej samej domeny AD, z której korzysta Self Service Portal, polityka użytkownika zostanie zastosowana do wszystkich użytkowników AD logujących się na tym Macu. Sprawdź to na przewidzianych kontach przed szerszym przypisaniem.
• Oprócz polityki urządzenia służącej do rejestracji Macowi można przypisać jedną dodatkową politykę urządzenia, jedną deklaratywną i jedną politykę użytkownika. Przed każdą zmianą payloadu zidentyfikuj docelowe Maki, użytkowników i grupy oraz wszystkie przypisania istniejącej polityki: polityki przypisanej już poza pilotażem nigdy nie zmieniaj na potrzeby pilotażu. Udokumentuj istniejące payloady Wi-Fi, VPN, proxy i certyfikatów oraz ich właścicieli; ustawienia sprzeczne są co do zasady rozstrzygane na korzyść bardziej restrykcyjnej wartości, z wyjątkiem szczególnego pierwszeństwa deklaratywnej konfiguracji aktualizacji oprogramowania i aplikacji. Nie nakładaj istniejących profili niekontrolowanymi dodatkowymi przypisaniami.
• Kontrola wstępna tylko dla macOS 26 z polityką użytkownika: jeśli pojawi się status Failed to apply the policy, zbadaj historię wcześniej przypisanych konfiguracji Restrictions: przestarzały klucz Allow Time Machine może pozostać w starszej przypisanej polityce, nawet jeśli nie jest już widoczny w opcjach konfiguracji. Nie wymagaj znalezienia tego klucza w bieżącym interfejsie. Jeśli podejrzewasz tę historyczną przyczynę, wstrzymaj pilotaż i ocenę payloadów Wi-Fi/VPN/certyfikatów tej polityki użytkownika: według Sophos cała polityka użytkownika może wtedy nie zostać zastosowana, nie tylko ograniczenie. Uzgodnij kontrolowane usunięcie problemu i ponowną kontrolę z osobami odpowiedzialnymi za polityki bezpieczeństwa i prywatności macOS; nie zmieniaj po cichu współdzielonej polityki produkcyjnej. Nie jest to ogólny błąd wszystkich Maców z macOS 26 ani polityk urządzenia.
• Przygotuj niezależny dostęp do pilotażowego Maca (na przykład działającą alternatywną sieć i lokalny dostęp administracyjny). Wcześniej uzgodnij z odpowiednimi administratorami SSID, punkt końcowy RADIUS/VPN, DNS, łańcuch zaufania PKI, termin ważności certyfikatów, dostępność PAC/proxy oraz ewentualną aplikację VPN innej firmy. Nie umieszczaj haseł dostępowych ani plików .pfx w zgłoszeniach lub publicznych zasobach. Zweryfikuj w tenantcie dopuszczenie produktu/licencji/systemu operacyjnego dla konkretnego środowiska; strony konfiguracji nie deklarują uniwersalnej obsługi każdej wersji macOS.

Wybór: która polityka i jakie zależności?

Przy ręcznej konfiguracji Global HTTP proxy z danymi dostępowymi wpisz nazwę użytkownika proxy w Authentication, a odpowiadające jej hasło proxy w Password. Authentication jest tutaj polem nazwy użytkownika, a nie wyborem metody uwierzytelniania. Uzgodnij z administratorem proxy, czy dane dostępowe są wymagane; nie umieszczaj haseł w zgłoszeniach ani publicznych zasobach.

Wi-Fi: wybór sieci i uwierzytelniania

Poniższe opisy pól przedstawiają udokumentowane ustawienia Sophos, a nie połączenie sprawdzone na Macu. Connect automatically automatycznie łączy Maca z siecią Wi-Fi, gdy jest ona dostępna. Hidden network oznacza sieć, która nie rozgłasza swojego SSID. Wybór musi odpowiadać sieci docelowej; ukryte SSID nie oznacza zatwierdzenia sieci pod względem bezpieczeństwa.

Security type określa metodę zabezpieczeń oraz wariant Personal lub Enterprise. Oba wybory uzgodnij z administratorem Wi-Fi. Przy Personal wpisz hasło sieci Wi-Fi w Password. Przy Enterprise sekcja Protocols dotyczy protokołów uwierzytelniania, a Authentication dotyczy uwierzytelniania klienta:

• W Protocols > Accepted EAP types określ typy EAP akceptowane przez Maca do uwierzytelniania, zgodnie z konfiguracją usługi RADIUS. Dla EAP-FAST można skonfigurować Protected Access Credential (PAC). Ten PAC nie jest plikiem automatycznej konfiguracji proxy. Przy TTLS pole Internal identity wybiera protokół uwierzytelniania użytkownika wewnątrz tunelu, a nie nazwę użytkownika.
• Jeśli wybrana metoda Enterprise używa nazwy użytkownika i hasła, wpisz nazwę użytkownika Wi-Fi w Authentication > User, a hasło Wi-Fi w Password. Przypisanie polityki użytkownikowi nie zastępuje tych danych. Według Sophos Require password on each connect oznacza wysyłanie hasła przy każdym uwierzytelnianiu. Nie wywódź z tego wyświetlania monitu o hasło, konkretnego sposobu jego przechowywania ani przesyłania go jawnym tekstem. Nie dodawaj hasła do każdej metody opartej na certyfikatach.

Outer identity to tożsamość zastępcza, którą EAP rozpoczyna uwierzytelnianie bez ujawniania rzeczywistych danych logowania użytkownika. Jest przesyłana jawnym tekstem. Dlatego nie używaj rzeczywistej nazwy użytkownika ani danych poufnych. Jeśli usługa RADIUS wymaga przekazywania żądań na podstawie realm, tożsamość zastępcza musi zawierać realm uzgodniony z administratorem. Bez takiego przekazywania może wystarczyć prosta tożsamość, np. anonymous. Nadal obowiązują podane poniżej warunki dotyczące EAP i TLS 1.3.

Ważne przy Wi-Fi Enterprise: dla Identity certificate Sophos Mobile wymaga wcześniejszej konfiguracji Client certificate w tej samej polityce, a dla Trusted certificates wcześniejszej konfiguracji Root certificate. Payload Wi-Fi zawiera też własne pole Proxy na ustawienia ręczne lub PAC; nie jest ono tym samym co Global HTTP proxy. Certyfikat klienta jest dostępny również dla innych konfiguracji tej samej polityki, lecz nie innych polityk; w nich trzeba go ponownie przesłać. Apple opisuje na poziomie platformy możliwość powiązania tożsamości SCEP z usługą w tym samym profilu konfiguracyjnym, jednak konkretny przykład Wi-Fi EAP-TLS firmy Apple używa certyfikatu AD. Nie dowodzi to, że Sophos Mobile udostępnia tożsamość SCEP w polu Wi-Fi Identity certificate lub dostarcza odpowiednie powiązanie: pomoc Sophos dotycząca Wi-Fi wymienia zamiast tego konfigurację Client certificate jako warunek wstępny. Nie planuj zależności od SCEP przy pierwszym przypisaniu ani dla produkcyjnego Wi-Fi. Taką ścieżkę rozważaj operacyjnie tylko po potwierdzeniu rzeczywistego powiązania we własnym tenantcie, na zarządzanym pilotażowym Macu i poprzez pomyślne logowanie EAP/RADIUS; jeśli nie da się potwierdzić ani wyboru, ani dostarczonego powiązania, wstrzymaj tę ścieżkę. Przy EAP-TTLS/PEAP/EAP-FAST ustaw Outer identity bez poufnych danych użytkownika; według Sophos przy TLS 1.3 jest ono wymagane. Minimum i maksimum TLS ustawiaj tylko razem albo oba pola pozostaw puste.

VPN: uzgodnienie dostawcy, uwierzytelniania i proxy

Connection name to nazwa połączenia widoczna dla użytkownika na Macu, a nie nazwa polityki. Lista pól Sophos wymienia w Connection type opcje Cisco AnyConnect, Cisco Legacy AnyConnect, IPsec (Cisco), F5, Check Point oraz Custom SSL/TLS. Custom SSL/TLS jest przeznaczone dla dostawców, których aplikacja w App Store udostępnia połączenie VPN. Ta lista nie potwierdza obsługi każdej kombinacji dostawcy i macOS. Wymagana aplikacja musi być już zainstalowana; jej rzeczywisty identyfikator Reverse DNS uzgodnij z dostawcą.

Poniższych opcji używaj tylko wtedy, gdy są dostępne i wymagane dla wybranego typu połączenia oraz dostawcy. Jeśli dostawca określa własne właściwości połączenia, w Third-party settings dodaj przez Add odpowiednie pary Key i Value. Nie przenoś właściwości z innego VPN. Group to ewentualnie wymagana grupa do uwierzytelniania VPN, a nie grupa urządzeń do przypisania polityki.

Osobno uzgodnij z administratorem VPN uwierzytelnianie użytkownika i urządzenia:

• W User authentication wybierz Password lub Certificate. Odpowiednie pole Password zawiera hasło VPN, a Certificate zawiera certyfikat do uwierzytelniania użytkownika VPN.
• Przy Device authentication = Keys (Shared Secret)/Group name pojawiają się Group name, Keys (Shared Secret), Use hybrid authentication i Request password. Wpisz dane uwierzytelniania podane przez administratora w Group name oraz Keys (Shared Secret). Use hybrid authentication i Request password wybieraj tylko zgodnie z jego wymaganiami, nie jako uniwersalną naprawę połączenia.
• Przy Device authentication = Certificate pojawiają się Certificate oraz Including user PIN. Wybierz wymagany certyfikat urządzenia z listy Certificate. Including user PIN uwzględnia PIN użytkownika w uwierzytelnianiu urządzenia. Źródło nie określa momentu pytania o PIN ani sposobu jego przechowywania.

Chroń hasła VPN i współdzielone sekrety tak jak pozostałe dane logowania. Pola certyfikatów nadal nie potwierdzają sposobu powiązania SCEP; rzeczywistą tożsamość i uwierzytelnianie trzeba sprawdzić w przewidzianym kontekście użytkownika lub urządzenia.

W sekcji Proxy właściwej dla VPN opcja No proxy oznacza, że dla tego połączenia nie skonfigurowano proxy. Przy Manually pojawiają się Server and port, Authentication oraz Password. Wpisz tam adres i port proxy oraz, jeśli są wymagane, nazwę użytkownika i hasło proxy. Authentication jest również tutaj polem nazwy użytkownika. Przy Automatic pojawia się Proxy server URL na adres URL serwera z ustawieniami proxy. Jest to ustawienie tego połączenia VPN, a nie zmiana Global HTTP proxy.

Provider type rozróżnia App proxy, czyli tunel VPN na poziomie aplikacji, oraz Packet tunnel, czyli tunel VPN na poziomie sieci. Uzgodnij właściwą opcję z dostawcą. Nie wywódź z niej tunelu dzielonego ani pełnego; nadal wymagane są zaplanowanie ruchu i kontrola DNS oraz tras w pilotażu.

SCEP: sprawdzenie punktów końcowych, tożsamości i kluczy

URL zawiera adres internetowy serwera CA. %_SCEPPROXYURL_% wskazuje adres URL serwera na karcie SCEP strony Sophos setup. Challenge to adres internetowy, pod którym pobiera się hasło challenge z serwera SCEP, a nie samo hasło. %_CACHALLENGE_% wskazuje adres URL challenge na tej samej karcie. CA name musi być nazwą rozpoznawaną przez CA; może na przykład rozróżniać instancje CA. Uzgodnij właściwą wartość z PKI; nie zakładaj uniwersalnej nazwy ani obowiązku wypełnienia pola.

Aby dodać Subject Alternative Name, najpierw wybierz typ w Type of Subject Alternative Name, a następnie wpisz wartość w Value of Subject Alternative Name. Sophos opisuje RFC 822 name jako poprawny adres e-mail, DNS name jako nazwę DNS serwera CA, a Uniform resource identifier jako w pełni kwalifikowany adres URL serwera CA. Nie zastępuj po cichu tych opisów dotyczących serwera CA ogólnymi założeniami o SAN. Uzgodnij z PKI typ i wartość dla przewidzianego zastosowania certyfikatu; nie dowodzą one powiązania tożsamości z Wi-Fi ani VPN. Jeśli używana jest tożsamość użytkownika AD, AD user logon name oznacza zapisane w AD User logon name, czyli User Principal Name (UPN). SAN i dane AD nie są ogólnym warunkiem każdego certyfikatu Maca.

Retries określa liczbę ponowień, gdy serwer SCEP odpowiada pending. Retry delay to odstęp między tymi ponowieniami w sekundach. Nie jest to interwał odnawiania ani gwarancja wystawienia certyfikatu po tym czasie. Key size określa rozmiar klucza publicznego w wystawionym certyfikacie i musi odpowiadać rozmiarowi skonfigurowanemu na serwerze SCEP. Konfiguracja SCEP również zawiera Allow export from keychain. Pozwala to użytkownikom eksportować klucz prywatny certyfikatu z pęku kluczy. Tak jak przy przesłanym certyfikacie klienta, włączaj tę opcję wyłącznie przy wyraźnie zatwierdzonej potrzebie.

SCEP i klucze: Po podstawieniu wartości za symbole zastępcze Subject musi być poprawną nazwą X.500: CN=%_USERNAME_% oznacza użytkownika, a CN=%_DEVPROP(SerialNumber)_% Maca. Z samego wyboru polityki użytkownika nie wywódź odpowiedniej tożsamości urządzenia. Sprawdź zaufanie do CA, okres ważności certyfikatu, możliwość eksportu klucza oraz datę wygaśnięcia i procedurę ponownego wystawienia przed uruchomieniem pierwszej zależnej usługi; certyfikaty główne nie zastępują certyfikatu klienta. Dla każdego z kilku certyfikatów głównych dodaj osobną konfigurację Root certificate.

Inne payloady urządzenia: AirPrint dodaje adres IP drukarki i Resource path (na przykład ipp/print) do listy AirPrint. Directory service dołącza Maca do domeny AD po przypisaniu polityki; konto dołączające musi mieć uprawnienia do dodawania komputerów, a OU musi być poprawna. Ostrzeżenie: zmiany mapowania UID, User-GID lub Group-GID mogą pozbawić użytkowników dostępu do wcześniej utworzonych plików. Nie zmieniaj mapowania na potrzeby testu sieci; dołączenie do AD i wycofanie tej operacji zaplanuj osobno z administratorami AD i Maców.

Directory service: ustal konta, katalog domowy i uprawnienia

W General settings uzgodnij z administratorami AD dane potrzebne do dołączenia Maca do domeny:

• Domain host name zawiera nazwę hosta DNS domeny AD, do której Mac ma dołączyć. Nie wpisuj tu adresu serwera DNS ani kontrolera domeny wskazanego osobno w Preferred DC server.
• AD administrator name i Password zawierają nazwę i hasło konta używanego do połączenia z serwerem AD. To konto dołączające musi mieć uprawnienia do dodawania urządzeń do bazy danych AD. Nie umieszczaj tego hasła w zgłoszeniach ani publicznych zasobach.
• Organizational unit określa jednostkę organizacyjną (OU) w AD, do której zostanie dodany dołączany komputer. Uzgodnij zatwierdzoną wartość OU z administratorami AD; to pole nie służy do przypisywania użytkowników lub grup ani do ustawiania katalogu domowego.

Przed dołączeniem do AD uzgodnij z administratorami AD i Maców, czy potrzebny jest lokalny katalog domowy z kontem mobilnym, czy wyłącznie sieciowy katalog domowy. Po wybraniu Create mobile account macOS tworzy konto przy pierwszym logowaniu z połączeniem do serwera AD; później logowanie danymi dostępowymi AD jest możliwe również bez połączenia z tym serwerem. Przy Require confirmation before creating a mobile account użytkownik decyduje, czy konto mobilne zostanie utworzone — jego utworzenie nie jest wtedy gwarantowane. Konta mobilne wymagają Force local home folder: profil użytkownika znajduje się na woluminie startowym. Wyłączenie tej opcji oznacza używanie wyłącznie sieciowych katalogów domowych. Dlatego nie włączaj kont mobilnych dla wszystkich Maców bez rozróżnienia. Przy Use UNC path from Active Directory macOS montuje katalog domowy zapisany w koncie użytkownika AD; uzgodnij z administratorami odpowiedni protokół montowania w Network protocol i sprawdź dostęp w pilotażu.

Default user shell określa powłokę wiersza poleceń użytkownika. Według Sophos puste pole oznacza użycie /bin/bash. Jest to udokumentowana wartość domyślna tego pola, a nie przejęcie nieokreślonego ustawienia domyślnego macOS; uzgodnij potrzebną powłokę z administratorami Maców.

W Mapping przypisuje się atrybuty AD do następujących identyfikatorów macOS:

• UID attribute przypisuje atrybut AD do unikatowego identyfikatora użytkownika w macOS.
• User GID attribute przypisuje atrybut AD do identyfikatora grupy podstawowej konta użytkownika macOS.
• Group GID attribute przypisuje atrybut AD do identyfikatora grupy konta grupowego macOS. To przypisanie nie nadaje lokalnych uprawnień administratora; odpowiada za nie Domain administrator groups.

Przed przypisaniem polityki porównaj istniejące i zatwierdzone mapowania z administratorami AD i Maców. Nie zakładaj uniwersalnego atrybutu AD ani bezpieczeństwa pustych pól w tych mapowaniach. Przy późniejszych zmianach nadal obowiązuje opisane powyżej ryzyko utraty dostępu do istniejących plików.

Przed przypisaniem uzyskaj zatwierdzenie następujących decyzji w Administrative:

• Preferred DC server określa kontroler domeny AD, z którym macOS kontaktuje się w pierwszej kolejności. Jeśli pole pozostanie puste, macOS wybierze kontroler na podstawie informacji o lokacjach AD i szybkości odpowiedzi kontrolerów. Uzgodnij wybór z zespołem AD; wpisanie kontrolera nie oznacza wyłącznego powiązania z tym kontrolerem.
• Restrict DDNS ogranicza interfejsy sieciowe, dla których macOS używa Dynamic DNS. Domyślnie macOS używa DDNS dla wszystkich interfejsów sieciowych. Aby wprowadzić ograniczenie, wpisz nazwy BSD przewidzianych interfejsów i po każdym wpisie naciśnij Enter. Sophos podaje en0 jako przykład wbudowanego portu Ethernet; nie zakładaj na tej podstawie, że jest to właściwy interfejs na każdym Macu. Ustal rzeczywiste interfejsy na pilotażowym Macu i uzgodnij oczekiwane rejestracje DNS z zespołem AD/DNS. Ustawienie ogranicza DDNS, nie wyłącza żadnego interfejsu ani tunelu VPN.
• Rotacja hasła konta komputera: Password trust interval in days dotyczy konta komputera w AD, a nie hasła użytkownika. Puste pole oznacza automatyczną zmianę co 14 dni; 0 wyłącza automatyczne zmiany. Uzgodnij interwał z administratorami AD; nie ustawiaj 0 jako szybkiego sposobu naprawy połączenia.
• Ochrona LDAP: Packet signing / Packet encryption mają wspólny opis: Allow pozostawia macOS decyzję, czy połączenia LDAP będą podpisywane i/lub szyfrowane; Disable wyłącza obie formy ochrony; Require zawsze wymaga podpisywania i szyfrowania; SSL/TLS zawsze używa LDAP przez SSL/TLS. Nie wywódź z tego, że każda wartość jest dostępna w obu polach: sprawdź rzeczywiste opcje w tenantcie i ustal wymaganą ochronę z zespołem AD. Nie obniżaj ochrony, aby uzyskać pomyślne logowanie.
• Zakres dozwolonego logowania: Multi-domain authentication umożliwia logowanie użytkownikom ze wszystkich domen lasu AD. Jest to rozszerzenie zakresu logowania, a nie opisane wyżej stosowanie polityki użytkownika Self Service Portal. Przy Namespace = Forest możliwe są jednakowe nazwy użytkowników z różnych domen; logowanie odbywa się jako DOMAIN\name. Przy Domain obsługa przestrzeni nazw jest wyłączona, a nazwy logowania muszą być unikatowe. Wcześniej udokumentuj dozwolone domeny i konta; wybór sposobu nazywania nie zastępuje zatwierdzenia zakresu logowania.
• Lokalne uprawnienia administratora: członkowie grup AD wpisanych w Domain administrator groups otrzymują uprawnienia administratora na Macu. Odróżnij je od uprawnień konta dołączającego do dodawania komputera. Wpisuj tylko zatwierdzone grupy jako DOMAIN\group i zachowaj wielkość liter. Na potrzeby pilotażu udokumentuj, które konta mają pozostać kontami standardowych użytkowników, a które mają otrzymać lokalne uprawnienia administratora.

Przypisanie pilotażowe i sprawdzenie działania

1. Najpierw ogranicz zakres pilotażu: sprawdź wykaz konkretnie wskazanych Maców i użytkowników, których zmiana dotyczy, członkostwo w grupach, istniejące typy i przypisania polityk oraz działający alternatywny dostęp. Przy istniejącej polityce ustal wszystkie przypisane urządzenia i grupy; jeśli jest przypisana także poza pilotażem albo nie znasz pełnego zakresu jej oddziaływania, nie edytuj jej. Przed zastąpieniem dotychczasowej polityki urządzenia lub użytkownika macOS porównaj wszystkie payloady i zależności oraz przygotuj drogę powrotu tego samego typu dla dokładnie tych urządzeń docelowych. Przypisania grupowego używaj tylko wtedy, gdy kontrolujesz jej skład i przyszłe rozszerzenia; w przeciwnym razie wybierz pojedyncze urządzenia.
2. W Policies > macOS utwórz przez Create nową, odizolowaną politykę testową odpowiedniego typu; kopii używaj tylko jako samodzielnej nowej polityki bez przejętych przypisań. Przed pierwszą edycją payloadu potwierdź, że polityka testowa nie jest przypisana do żadnego urządzenia ani grupy poza zatwierdzonym pilotażem. Szeroko przypisaną politykę produkcyjną pozostaw bez zmian. Ustaw nazwę, opis i nazwę organizacji; przez Add configuration > Root certificate utwórz dla Wi-Fi Enterprise najpierw konfigurację certyfikatu głównego. Wybierz w niej Upload a file, wskaż przygotowany publiczny certyfikat główny X.509 w kodowaniu PEM lub DER i kliknij Open. Po przesłaniu zapisz konfigurację certyfikatu głównego przez Apply. Przy uwierzytelnianiu certyfikatem utwórz następnie Client certificate w tej samej polityce. W tej konfiguracji Client certificate pod File wybierz akcję Upload a file i wskaż przygotowany plik PKCS #12 (.pfx). Włącz Allow export from keychain tylko wtedy, gdy eksport klucza prywatnego jest wyraźnie wymagany. Następnie skonfiguruj Wi-Fi. Konfiguracje VPN/proxy dodaj dopiero po spełnieniu ich własnych zależności. W razie potrzeby skonfiguruj SCEP osobno: ogólna instrukcja Sophos tworzenia polityk wspomina o SCEP renewal interval na poziomie polityki po dodaniu SCEP, lecz listy pól SCEP dla macOS nie zawierają takiego pola konfiguracyjnego. Sprawdź w tenantcie, czy interwał polityki jest rzeczywiście dostępny dla wybranego typu macOS; datę wygaśnięcia i procedurę ponownego wystawienia uzgodnij z PKI. Nie traktuj SCEP jako źródła pola Wi-Fi Identity certificate bez odrębnego dowodu. Na koniec zapisz politykę przez Save na stronie Edit policy; utrwal zakres pilotażu, payloady i pierwotny stan na potrzeby powrotu.
3. Wybierz niebieski trójkąt odizolowanej polityki testowej, a następnie Assign; pod Select devices wybierz wyłącznie zinwentaryzowane pilotażowe Maki albo wcześniej sprawdzoną grupę urządzeń o ograniczonym zakresie i kliknij Finish. Przed zatwierdzeniem ponownie porównaj wybrane cele z wykazem, potem sprawdź faktyczne przypisania i przerwij przy nieoczekiwanej grupie docelowej. Wybór na tym etapie nie chroni przed zmianami w polityce, która była już wcześniej szeroko przypisana. Ścieżka macOS nie ma tutaj harmonogramu przypisania Now/Date.
4. Na pilotażowym Macu sprawdź przypisane profile w System Settings / System Preferences > Profiles we właściwym kontekście. Zmiana polityki urządzenia zacznie działać przy następnej synchronizacji urządzenia; polityka użytkownika — przy następnym logowaniu danego użytkownika. Zmiana polityki macOS nie wymaga ręcznego kroku Update devices, charakterystycznego dla iOS. Zanotuj status przypisania/zadania i lokalną listę profili, ale nie traktuj ich jako testu działania.
5. Sprawdź działanie, nie tylko status profilu: na koncie przewidzianego użytkownika sprawdź SSID i połączenie Wi-Fi, a dla Enterprise EAP potwierdź z zespołem RADIUS/PKI oczekiwany łańcuch zaufania serwera i używaną tożsamość klienta. Zestaw aktywnie VPN i sprawdź DNS/trasy oraz dostępne i niedostępne zasoby zgodnie z planem tunelu dzielonego/pełnego; przy proxy/PAC przetestuj rzeczywisty dostęp HTTP(S) i sposób uwierzytelniania. Sprawdź certyfikaty w odpowiednim pęku kluczy według odcisku, ważności i przeznaczenia. Przetestuj również drugiego użytkownika, jeśli istotny jest zakres obejmujący całe urządzenie lub AD. Wydruk testowy AirPrint i logowanie AD wykonaj tylko wtedy, gdy te payloady rzeczywiście są wdrażane. Przy Directory service sprawdź pierwsze logowanie online zatwierdzonym kontem AD oraz dostęp do wybranego lokalnego lub sieciowego katalogu domowego; przy użyciu UNC sprawdź też oczekiwane zamontowanie. Jeśli przewidziano konto mobilne, sprawdź jego faktyczne utworzenie wraz z ewentualnym potwierdzeniem użytkownika, a następnie zaloguj się ponownie bez połączenia z serwerem AD. Zachowaj przy tym niezależny dostęp lokalny. Z zespołem AD/DNS sprawdź, z którym kontrolerem domeny faktycznie nawiązano kontakt i jakie rejestracje DDNS rzeczywiście wykonano, porównując je z uzgodnionym wyborem i zakresem interfejsów. W przypadku nieoczekiwanego kontrolera lub wpisu DNS wstrzymaj wdrożenie i wyjaśnij przyczynę z tymi administratorami. Sprawdź również oczekiwane uprawnienia standardowego użytkownika/administratora oraz, jeśli wymaga tego ustalony zakres logowania, potwierdź odrzucenie logowania przy użyciu zatwierdzonego do tego testu konta spoza dozwolonego zakresu domen/kont. Z zespołem AD sprawdź uzgodnioną ochronę LDAP rzeczywistego połączenia i porównaj obowiązujący interwał rotacji hasła konta komputera z ustaleniami; późniejszą zaplanowaną zmianę hasła zweryfikuj osobno, nie uznawaj jej za sprawdzoną na podstawie pierwszego logowania. W przypadku nieoczekiwanego dostępu do katalogu domowego, zakresu logowania, ochrony lub uprawnień wstrzymaj wdrożenie i zaangażuj administratorów AD i Maców.
6. Dopiero po pomyślnym zestawieniu połączenia, ponownym zalogowaniu i synchronizacji zarządzania dopuść następną falę pilotażu. Rotację certyfikatów zaplanuj z okresem nakładania się: najpierw pomyślnie sprawdź nowe zaufanie i nową tożsamość, dopiero potem usuń starą CA lub metodę uwierzytelniania. Wybór CA dla inspekcji TLS na zaporze i ogólne profile sieciowe Apple nie należą do tej decyzji o polityce macOS w Mobile.

Droga powrotu przy utracie połączenia lub błędnej grupie docelowej

1. Wstrzymaj wdrożenie i zabezpiecz dane o wszystkich rzeczywiście dotkniętych kontach, urządzeniach, grupach i wersjach profili; przez niezależny dostęp porównaj bieżący profil z ostatnią działającą kombinacją. Przed każdą korektą ponownie sprawdź komplet przypisań polityki testowej i polityki przywracającej. Nie usuwaj od razu jedynego połączenia ani CA, dzięki którym Sophos Mobile może jeszcze dotrzeć do Maca.
2. W macOS nie zakładaj dostępności ogólnej akcji Uninstall policy: według pomocy administracyjnej Sophos dopuszcza ją tylko dla polityk urządzeń Android, kontenerów Knox i urządzeń iOS. Tylko jeśli można potwierdzić, że polityka testowa jest przypisana wyłącznie w pilotażu, skoryguj jej payloady i poczekaj na synchronizację urządzenia lub logowanie użytkownika. W przeciwnym razie nie zmieniaj polityki z przypisaniami poza pilotażem: najpierw ogranicz zakres z osobami odpowiedzialnymi i użyj niezależnego dostępu. Alternatywnie przypisz tylko dotkniętym pilotażowym Macom przygotowaną, działającą politykę tego samego typu; najpierw sprawdź również jej przypisania i payloady, nie edytuj współdzielonej polityki produkcyjnej na potrzeby powrotu i nie wywołuj globalnej akcji dotyczącej grup ani Unassign. Przy zastępowaniu wcześniej przypisanej polityki sprawdź jej zależności i obowiązujący kontekst użytkownika/urządzenia. Lokalne usunięcie polityki użytkownika nie jest trwałą drogą powrotu: zostanie ponownie przypisana przy następnym logowaniu. Nie usuwaj profilu rejestracji jako sposobu przywrócenia stanu: wyrejestruje to Maca i wymaga uprawnień administratora.
3. Przed wycofaniem starej głównej CA sprawdź wszystkie zależne certyfikaty Wi-Fi/VPN i SCEP/klienta oraz działającą alternatywną drogę dostępu; po zmianie przypisania AD/mapowania UID nie ryzykuj uprawnień do plików przez ślepe przełączanie profili. Na tym samym pilotażowym Macu potwierdź przywrócone połączenie sieciowe, logowanie, łańcuch certyfikatów i synchronizację Sophos Mobile. Jeśli Mac nadal nie ma dostępu administracyjnego przez sieć, zaangażuj lokalne wsparcie Mac/sieci/PKI z udokumentowanymi wartościami sprzed zmiany i po niej.

Zakres weryfikacji: Żadnej kombinacji macOS/tenanta nie zweryfikowano tu w laboratorium. Ta warunkowa dokumentacja nie wymaga ogólnego testu tenanta/laboratorium przed publikacją. Przed wdrożeniem produkcyjnym w konkretnym środowisku lub stwierdzeniem, że łączność działa, zweryfikuj na autoryzowanym pilotażowym Macu edycję/licencję, wersję macOS, zakres polityki i przypisanie użytkownika Apple Business, synchronizację i logowanie, zaufanie PKI, Wi-Fi EAP i faktycznie używaną tożsamość klienta. Przy SCEP jako tożsamości Wi-Fi trzeba we własnym tenantcie wykazać, czy wystawiona tożsamość jest dostępna do wyboru w polu Sophos Identity certificate albo faktycznie zostaje w inny sposób powiązana w dostarczonym profilu Wi-Fi; dodatkowo należy sprawdzić tożsamość/odcisk we właściwym pęku kluczy urządzenia/użytkownika oraz pomyślne logowanie EAP/RADIUS dokładnie tym certyfikatem na zarządzanym pilotażowym Macu. Samo wystawienie certyfikatu lub instalacja profilu nie wystarcza. Również dla SCEP jako tożsamości VPN należy wykazać wybór albo dostarczone powiązanie, właściwy kontekst pęku kluczy/użytkownika oraz pomyślne logowanie VPN oczekiwanym certyfikatem na pilotażowym Macu; pomoc Sophos dotycząca VPN wymienia pola certyfikatów, lecz nie podaje sposobu powiązania SCEP. Powiązanie SCEP z Wi-Fi/VPN pozostaje nierozstrzygnięte i nie jest ścieżką operacyjną bez pomyślnego, autoryzowanego pilotażu. Przed użyciem produkcyjnym sprawdź na urządzeniu aplikację VPN/dostawcę/uwierzytelnianie, rotację certyfikatów, niezależny dostęp, zastępowanie polityki i przywracanie.