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

• 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?

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.

SCEP i klucze: %_SCEPPROXYURL_% i %_CACHALLENGE_% odnoszą się do ustawień SCEP zapisanych w Sophos Mobile. 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

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.

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

• 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 utwórz dla Wi-Fi Enterprise najpierw Root certificate, a przy uwierzytelnianiu certyfikatem Client certificate w tej samej polityce, potem 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. Zapisz politykę; 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. 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.