Synchronizacja Active Directory z Sophos Central

Sophos Central może importować użytkowników i grupy z lokalnego Active Directory. Tożsamości te służą między innymi do przypisywania polityk i urządzeń. Niekontrolowana synchronizacja może jednak tworzyć zbędne konta, duplikaty obiektów lub nieoczekiwane usunięcia.

Microsoft Entra ID synchronizuje się przez osobny Connector. Instrukcja znajduje się w artykule Synchronizacja Microsoft Entra ID z Sophos Central.

Ustalenie modelu źródeł przed instalacją

Central może zarządzać maksymalnie 25 źródłami katalogowymi na Tenant. Większa liczba wymaga struktury Central Enterprise. Użytkownicy i adresy e-mail muszą pozostać unikatowe w obrębie Central Tenant. Ta sama Domain nie może dostarczać użytkowników jednocześnie z kilku źródeł AD, Entra ID lub Google Directory.

W wersji Trial Sophos ogranicza dodatkowo liczbę Directory Objects, które można utworzyć lub wykorzystać, w tym użytkowników, urządzeń i grup. Niepełny import testowy nie musi więc oznaczać błędu filtra. Przed Pilot należy wspólnie sprawdzić zakres Trial, oczekiwaną liczbę obiektów i status licencji.

W obrębie jednego Forest można wybrać kilka Child Domains, a jeden Tenant może synchronizować także kilka Forests. Sophos mimo to zaleca łączenie każdego Forest tylko z jednym Central Tenant. Jeśli ten sam Forest trafia do kilku Tenants albo kilka Forests zawiera tych samych użytkowników lub adresy e-mail, kolejne przebiegi naprzemiennie aktualizują pozornie te same tożsamości. Central nie scala tych rekordów, przez co nazwy, atrybuty i przypisania grup mogą stać się niespójne.

Obsługiwany model mieszany jest natomiast przydatny: AD synchronizuje komputery i grupy komputerów, a Entra ID dostarcza użytkowników i grupy użytkowników tej samej Domain. Shared Mailboxes w grupie Microsoft 365 wymagają Entra ID lub Google Directory. Zwykłą Shared Mailbox poza grupą Microsoft 365 można zaimportować przez AD Sync.

Shared Mailboxes i Public Folders z tej samej Domain co użytkownicy wymagają AD Sync Utility oraz włączonej opcji Sync users and user groups. Skrzynki grup Microsoft 365 nie są importowane przez AD Sync. Shared Mailbox bez Delegate również nie jest synchronizowana. Jeśli nieaktywna skrzynka użytkownika nadal ma delegację poczty do aktywnej skrzynki, AD Sync jej nie usuwa i może nadal prowadzić ją w Central jako Shared Mailbox.

Dla tej samej Domain lub Subdomain może działać tylko jeden produkcyjny AD Sync Client. Ponadto kilka urządzeń AD nie może mieć tego samego DNS Hostname, ponieważ Central nie zdoła ich jednoznacznie dopasować. Przy zmianie serwera stary harmonogram zatrzymuje się przed uruchomieniem produkcyjnej synchronizacji nowej instancji.

Jeśli Self Service Portal ma służyć do Sophos Email, Device Encryption lub Mobile, dostęp użytkowników włącza się przed pierwszym Directory Sync. Dzięki temu nowi i istniejący użytkownicy otrzymają przewidziane zaproszenie. Procedurę opisuje artykuł Konfiguracja dostępu do Sophos Central Self Service Portal.

Ograniczenia AD Sync i grupy międzydomenowe

AD Sync nie scala danych z kilku Forests lub Directory Services w jeden rekord główny. Ten sam użytkownik lub adres e-mail nie może więc występować w więcej niż jednym synchronizowanym Forest. Duplikaty użytkowników, adresów e-mail lub grup mogą być przy każdym przebiegu naprzemiennie aktualizowane danymi z różnych źródeł, a nawet zmieniać widocznego w Central Directory Owner. W obrębie Tenant użytkownicy i adresy e-mail pozostają unikatowe; użytkowników tej samej Domain nie wolno synchronizować równocześnie z AD i Entra ID ani dostarczać równolegle do kilku Central Admin Accounts.

W grupie z członkami z kilku Domains Central importuje tylko użytkowników z Domain, do której należy grupa. Preview and Sync może pokazać wszystkich członków, ale podczas produkcyjnego Sync użytkownicy z innej Domain nie zostaną dodani do grupy. Dla Universal Groups i Child Domains zachowanie to testuje się z jednym członkiem testowym z każdej Domain.

Użytkownicy i grupy użytkowników są synchronizowani lub wyłączani wspólnie. To samo dotyczy urządzeń i grup urządzeń. Na Directory Object przewidziano maksymalnie 1'000 filtrów, a dodatkowy filtr LDAP może mieć najwyżej 5'000 znaków. Nie są obsługiwane części Domain dłuższe niż 63 znaki ani zaczynające się lub kończące znakiem - albo _.

Skrzynki grup Microsoft 365 wymagają Entra ID. AD Sync nie obsługuje Shared Mailbox bez Delegate, kilku produkcyjnych AD Sync Clients tej samej Domain lub Subdomain ani kilku urządzeń AD z identycznym DNS Hostname. Nieaktywna skrzynka z delegacją do aktywnej skrzynki może natomiast pozostać jako Shared Mailbox. Te ograniczenia traktuje się przed pierwszym przebiegiem jako decyzje projektowe, a nie omija później szerszymi filtrami.

Porządkowanie nieaktywnych obiektów AD przed Sync

Nieaktywne konta użytkowników i urządzenia należy w miarę możliwości sprawdzić, usunąć lub wyłączyć bezpośrednio w Active Directory. Nie tylko zwiększają liczbę obiektów Central, ale pozostają ryzykiem bezpieczeństwa w źródle. Porządkowanie zmniejsza też plik Sync przesyłany do Sophos Central i może przyspieszyć przebieg.

Filtry LDAP mogą zapobiec przesyłaniu nieaktywnych użytkowników do Central i również zmniejszyć plik Sync. Nie usuwają jednak ryzyka nadal istniejącego nieaktywnego konta AD. Proces operacyjny łączy więc możliwy do uzasadnienia okres nieaktywności, zgodę Owner, porządkowanie źródła i późniejszy przebieg Preview. Przed usunięciem konta komputera urządzenia sprawdza się osobno pod kątem wieku, ostatniego kontaktu z Domain i stanu ochrony.

Zarządzanie Directory Sources w Central

Centralny widok znajduje się w Global Settings > Platform > Directory service. Konfiguracja źródła i zarządzanie nim wymagają odpowiedniej roli Central Admin. Zależnie od źródła strona udostępnia Add Active Directory, Add Microsoft Entra ID i Add directory service for Google. Dla lokalnego AD pobiera się stąd aktualne oprogramowanie Setup, natomiast Entra ID i Google autoryzuje się przez odpowiednie Cloud Connectors.

Lista źródeł pokazuje dla każdego wpisu nazwę, typ, Domain, harmonogram i status. Ostrzeżenia i błędy sprawdza się nie tylko tutaj, lecz również w Alerts and Reports > Logs > General Logs > Events. Zielony status źródła nie wystarcza, jeśli ostatni przebieg jest nieaktualny lub liczba obiektów odbiega od oczekiwanej.

Kliknięcie nazwy otwiera szczegóły. Dla AD sprawdza się przede wszystkim liczby użytkowników, grup, urządzeń, grup urządzeń, Public Folders i Shared Mailboxes, a także Hostname, wersję Client, Domain, status i czas ostatniego Sync. Dla Entra ID i Google najważniejsze są liczby użytkowników i grup, status, ostatni przebieg oraz harmonogram. Po pierwszej konfiguracji i każdej zmianie filtra lub źródła wartości porównuje się ze znanym zestawem referencyjnym.

Zależnie od typu źródła można tam również zmieniać konfigurację i filtry, wykonywać purge zsynchronizowanych danych oraz usuwać źródło. Są to różne operacje: Purge usuwa dane katalogowe zaimportowane z tego źródła, natomiast Delete usuwa dodatkowo Directory Source. W AD wcześniej zatrzymuje się opcje Sync i działające Clients; w Entra ID i Google korzysta się z odpowiednich okien Filter, Purge i Delete. Przed każdą operacją eksportuje się użytkowników, grupy, urządzenia, Policies i Mailboxes, których dotyczy zmiana, oraz czyta skutki zapowiadane przez Central. Purge ani Delete nie są niezobowiązującym testem połączenia i nie wolno ich potwierdzać bez planu wycofania.

Nazwę i opis źródła można zmienić dopiero po dezaktywacji przez Turn off. Po zapisaniu włącza się je ponownie przez Turn on i kontroluje. Wyłączenie przerywa aktualizację, dlatego nie wykonuje się go podczas niesprawdzonej zmiany katalogu. Po produkcyjnym aktywowaniu synchronizacji źródła nie można po prostu cofnąć tego kroku. Ręczny przebieg uruchamia się, otwierając źródło i wybierając Synchronize; następnie sprawdza się status, czas i zmiany obiektów.

Planowanie Self Service i Shared Mailboxes przed Sync

Jeśli użytkownik ma korzystać z Self Service Portal, opcję User Access włącza się przed pierwszym Directory Sync. Central może wtedy wysłać zaproszenia we właściwym procesie. Późniejsze włączenie dostępu nie naprawia automatycznie każdej wcześniej pominiętej wiadomości, dlatego użytkowników Pilot, dostarczanie poczty i dostęp do portalu testuje się przed szerokim importem.

Shared Mailboxes w Central nie zawsze mają pełne atrybuty użytkownika. Delegowani użytkownicy otrzymują dostęp Self Service do przypisanej Shared Mailbox i zależnie od licencjonowanego produktu widzą na przykład Emergency Inbox oraz Quarantine Summary. Delegate może przez to otrzymywać podsumowania własnej skrzynki i dodatkowo Shared Mailbox. Delegacje i adresy dostarczania testuje się praktycznie po Sync, a nie zatwierdza wyłącznie na podstawie liczby obiektów.

Shared Mailbox w grupie Microsoft 365 nie może być synchronizowana przez lokalne AD; potrzebne jest Microsoft Entra ID lub Google Directory. Zwykłą Shared Mailbox poza grupą Microsoft 365 może obsłużyć AD Sync. Przed późniejszą migracją do Entra ID należy zinwentaryzować, z którego typu obiektu pochodzi każda skrzynka. W przeciwnym razie dalszy AD Sync po zmianie źródła może usunąć skrzynki lub pozostawić je z nieaktualnymi danymi.

Przed pierwszym Sync

Najpierw należy ustalić, który katalog jest źródłem nadrzędnym dla poszczególnych użytkowników i grup. Tych samych osób nie powinno się tworzyć równocześnie ręcznie, z AD i z Entra ID.

Pierwszy przebieg warto ograniczyć do małej testowej OU z reprezentatywnymi użytkownikami i grupami. Należy sprawdzić:

adresy e-mail i User Principal Names,
zagnieżdżone grupy i członkostwa,
wyłączone lub nieaktualne konta,
konta serwisowe i techniczne,
konflikty nazw z istniejącymi obiektami Central.

Każdy synchronizowany użytkownik potrzebuje unikatowego adresu e-mail. Wiele procesów Central używa go jako tożsamości i celu dostarczenia; w Sophos Email wiadomość na adres bez przypisanego użytkownika może być nawet niedostarczalna. Firewall lub Proxy muszą ponadto osiągać Domains i Ports udokumentowane dla Central. Sam pomyślny test LDAP nie potwierdza tej ścieżki Cloud.

Instalacja AD Sync Utility

Aktualne oprogramowanie synchronizacji pobiera się bezpośrednio z Sophos Central i instaluje na stale dostępnym systemie Windows. System potrzebuje dostępu sieciowego do Domain Controller i wymaganych usług Sophos.

Aktualny Active Directory Synchronization Setup Software działa wyłącznie w 64-bitowym systemie Windows i wymaga .NET Framework 4.6.2. Sophos wymienia Windows 7, 8.1, 10 i 11 oraz Windows Server 2008 R2, 2012, 2012 R2, 2016, 2019, 2022 i 2025. Jako Domain Controller podaje Windows Server 2008 R2 do 2025. Zgodność producenta nie zastępuje Microsoft Lifecycle: nową instalację produkcyjną wdraża się na aktualnie wspieranym i załatanym systemie serwerowym, a nie na Windows 7 lub wycofanym Windows Server.

Do dostępu do Central używa się API Credentials z rolą Service Principal Active Directory Sync, a nie ogólnych Super Admin Credentials.

Konto usługi AD otrzymuje tylko prawa konieczne do odczytu wybranych Forests i obiektów katalogowych. Dokumentuje się wygasanie hasła, uruchamianie usługi i odpowiedzialność. Osobiste konto Admin nie jest odpowiednie.

Utility nie może przetwarzać Domain, jeśli pojedyncza część jej nazwy ma ponad 63 znaki albo zaczyna się lub kończy znakiem - lub _. Ograniczenie sprawdza się przed instalacją, ponieważ skrócona nazwa wyświetlana ani inny UPN nie naprawiają nieprawidłowej nazwy AD Domain.

Sophos przetestował do 30'000 obiektów AD. Powyżej 40'000 wpisów użytkowników interfejs może działać wolniej. Większe środowiska filtruje się więc szczególnie rygorystycznie i testuje z realistycznym czasem wykonania.

Przy każdym przebiegu Utility sprawdza, czy jest dostępna nowsza wersja, i zwykle automatycznie wykonuje kolejne aktualizacje. Wczesne wersje AD Sync nie obsługują bieżącego uwierzytelniania Central i mogą całkowicie przestać działać, jeśli automatyczna aktualizacja zawiedzie. Wtedy pobiera się aktualny Installer z Global Settings > Platform > Directory service i uruchamia go na istniejącej instalacji. Następnie tworzy się nowe API Credentials z rolą Service Principal Active Directory Sync i zapisuje w Utility jako Client ID i Client Secret. Każda produkcyjna instancja Sync otrzymuje identyfikowalną tożsamość techniczną, udokumentowaną odpowiedzialność i własną rotację Secret.

Podczas uruchamiania Client ID i Client Secret sprawdza się przez Validate credentials. Jeśli Utility komunikuje się przez Proxy, należy włączyć Configure proxy manually i podać adres Proxy. Gdy Proxy wymaga logowania, dochodzą Enable proxy authentication, użytkownik i hasło Proxy. Dopiero drugi pomyślny test Credentials potwierdza działanie nie tylko danych API, ale też ścieżki Proxy.

Ten ekran Proxy należy do Active Directory Synchronization Setup 4.0. Trial Tenant może nadal otrzymać starszy Sophos Central AD Sync Utility 3.5.4, w którym nie można podać danych Proxy w interfejsie. Usługa domyślnie działa jako Local Service i przy uwierzytelniającym Proxy często kończy się komunikatem Failed active directory synchronization, System.Net.Http.HttpRequestException oraz CommandLib.HttpRequestCommand+HttpStatusException. Alternatywne konto usługi wymaga Log on as a service, logowania interaktywnego i Batch, praw odczytu odpowiednich OUs oraz pełnego dostępu do C:\ProgramData\Sophos\Sophos Cloud AD Sync. Po każdej zmianie konta usługi starą Utility konfiguruje się ponownie. W środowiskach produkcyjnych w miarę możliwości używa się aktualnego oprogramowania 4.0.

Do LDAP używa się konta z prawami odczytu całego wybranego Forest. Use LDAP over an SSL connection pozostaje w miarę możliwości włączone. LDAPS zwykle korzysta z TCP 636, a nieszyfrowane LDAP z TCP 389. Port 389 ze względu na LDAP Signing i Channel Binding nie jest niezawodnym obejściem w aktualnych środowiskach Active Directory. Domain Controller potrzebuje dla LDAPS ważnego certyfikatu zaufanego przez system Sync.

Jeśli konkretne środowisko LDAP w sposób potwierdzony nie obsługuje SSL, można wyłączyć Use Secure LDAP i zmienić port na odpowiedni nieszyfrowany LDAP. Jest to udokumentowany Fallback, a nie Best Practice. Credentials i dane katalogowe nie są wtedy chronione przez TLS podczas przesyłania, dlatego segmentację, ścieżkę sieciową i szybkie przejście na LDAPS traktuje się jako ryzyko.

Czego Utility oczekuje w Forest

Dla pełnego Forest AD Sync odczytuje w korzeniu drzewa katalogowego rootDomainNamingContext z Distinguished Name domeny głównej Forest oraz defaultNamingContext z Distinguished Name używanego serwera. W CN=Partitions,CN=Configuration,<rootDomainNamingContext> Utility oczekuje dla odpowiednich kontekstów nazw wpisów netBiosName, dnsRoot i nCName. Wartość nCName wyznacza dodatkowe obszary wyszukiwania, o ile nie jest nadrzędnym Distinguished Name serwera podanego w ekranie Setup.

Jeśli brakuje któregoś atrybutu albo konto usługi nie może odczytać Configuration Partition, test logowania może się udać, lecz wykrywanie Forest lub późniejszy Sync nadal zawiedzie. Wartości sprawdza się wtedy w LDP.exe na tym samym koncie usługi, zanim zmieni się filtry lub obiekty Central.

Filtrowanie OUs i obiektów

Filtry ograniczają zakres synchronizacji. Obejmuje się tylko OUs, użytkowników i grupy rzeczywiście potrzebne w Sophos Central. Szeroki import Root rzadko ma sens.

Preview pokazuje obiekty, które zostaną dodane, zmienione lub usunięte. Szczególnie usunięć nie zatwierdza się bez kontroli. Widok Preview lub Pending Changes może błędnie wyświetlać znaki UTF-16 albo Double Byte jako ???, choć dane są przesyłane i poprawnie prezentowane w Central. Nazwy chińskie, japońskie lub koreańskie sprawdza się więc także w AD oraz po kontrolowanym Pilot Sync w Central.

Sophos określa to jako ograniczenie do naprawienia w przyszłej wersji AD Sync Utility. Dopóki używana wersja nie naprawia go w sposób potwierdzony, kontrola źródła i wyniku pozostaje konieczna.

Base DN i LDAP filter pełnią dwa różne zadania. Base DN ogranicza wyszukiwanie do wybranych OUs; członkostwa OU nie da się niezawodnie wyrazić wyłącznie zwykłym LDAP Filter. LDAP filter ogranicza atrybuty lub członkostwo grup w tym obszarze. Oba ustawia się osobno dla każdej Domain, ponieważ Child Domains nie dziedziczą ustawień Parent Domain. Filtry użytkowników i grup również działają niezależnie.

Na karcie AD Filters Search Bases i LDAP Query Filters zapisuje się osobno dla każdej Domain, a w razie potrzeby osobno dla użytkowników i grup. Search Base dla Finance OU może wyglądać tak:

OU=Finance,DC=myCompany,DC=com

Przykładowy filtr użytkowników należących do grupy:

memberOf=CN=testGroup,DC=myCompany,DC=com

Bez dodatkowego filtra grup Central nadal wykryje wszystkie grupy tych użytkowników. Aby ograniczyć także grupy do tej jednej, można dodać filtr CN=testGroup. Zmiana filtra może usunąć z zakresu wcześniej zsynchronizowanych użytkowników i grupy oraz skasować je w Central, dlatego zawsze wykonuje się pełny Preview.

Sophos przyjmuje następujące filtry bazowe:

Użytkownicy: (&(objectCategory=person)(objectClass=user)(!sAMAccountType=805306370)(!userAccountControl:1.2.840.113556.1.4.803:=2))
Grupy:       (&(objectCategory=group)(objectClass=group))

Filtr użytkowników wybiera osoby klasy user, wyklucza komputery przez sAMAccountType=805306370 i wyłączone konta przez odpowiedni bit userAccountControl. Dodatkowe filtry łączy się dla każdej Domain z warunkami bazowymi i najpierw testuje w LDP.exe.

Sophos ogranicza konfigurację do 1'000 filtrów na obiekt katalogowy i 5'000 znaków na dodatkowy LDAP Filter. Użytkowników synchronizuje się tylko razem z grupami użytkowników, a urządzenia z grupami urządzeń. W grupach międzydomenowych Preview pokazuje wszystkich członków, ale Central importuje tylko użytkowników z Domain grupy, dlatego takie grupy testuje się przed produkcyjnym Sync.

Wynik porównuje się w Microsoft LDP.exe: Search Base z AD Sync odpowiada Base DN, a wyrażenie LDAP odpowiada Filter. Pozwala to ustalić, czy obiektu nie dostarcza Sophos, czy już zapytanie katalogowe. Niektóre porównania atrybutów rozróżniają wielkość liter.

Filtrów lastLogon i lastLogonTimestamp używa się ostrożnie. lastLogon jest zwykle aktualniejszy, lecz nie replikuje się między Domain Controllers i wiarygodny wynik wymaga odpytania wszystkich. lastLogonTimestamp jest replikowany, ale może być nieaktualny. Sophos zaleca usuwać nieaktywne konta i urządzenia u źródła zamiast polegać tylko na filtrze czasu.

Jeśli lastLogonTimestamp ma tymczasowo służyć jako filtr, najpierw ustala się datę graniczną UTC i przelicza ją zaufanym konwerterem LDAP lub Active Directory FILETIME na Windows FILETIME. Przykład Sophos, 1 grudnia 2020 o 00:01, daje 132581431640000000. W Active Directory Synchronization Setup > AD Filters w Custom Filters wpisuje się:

(lastLogonTimestamp>=132581431640000000)

Wartości przykładowej nie kopiuje się bez zmian. Własną datę wybiera się świadomie, poprawnie przelicza i dokumentuje ze strefą czasową oraz zgodą na zmianę. Potem wykonuje się Preview and Sync, sprawdza użytkowników objętych i wykluczonych, a dopiero następnie zatwierdza przebieg produkcyjny.

AD Sync tworzy tylko grupy mające więcej niż jednego członka. Grupa pusta lub jednoosobowa nie pojawi się więc jako oczekiwany obiekt Central. Duplikaty użytkowników lub adresów e-mail z kilku Forests nie są scalane, dlatego źródło obiektu może zmieniać się między przebiegami. W miarę możliwości Forest synchronizuje się tylko z jednym Central Tenant.

Opcja Exclude disabled user accounts jest domyślnie włączona i musi pozostać włączona dla Shared Mailboxes. Jej wyłączenie może utworzyć w Central duplikaty Mailbox Objects. Wyłączone zwykłe konta należy niezależnie uporządkować u źródła, a nie przywracać szerszym Sync.

Przełączniki typów danych mają konkretne zależności:

Sync users and user groups synchronizuje oba typy wspólnie i obejmuje zwykłe Shared Mailboxes. Po wyłączeniu nie można przez to źródło AD synchronizować Shared Mailboxes ani Public Folders.
Sync public folders wymaga również Sync users and user groups, ponieważ Public Folders są traktowane jako Mailbox Objects.
Dla urządzeń w zwykłej eksploatacji włącza się razem Sync devices i Sync organizational units. Przy pierwszej konfiguracji można najpierw zaimportować tylko OUs, aby przygotować Policies.
Jeśli później wyłączy się tylko Sync organizational units, urządzenia pozostaną aktywne, a dotychczasowe OUs staną się Custom Groups. Jeśli aktywna pozostanie tylko synchronizacja OU, urządzenia nie będą już przypisywane do Central Groups.

Bez przygotowanych OU Groups nowe urządzenia otrzymują początkowo Default Policies. Po OU Pilot włącza się oba przełączniki urządzeń i kontroluje przypisanie oraz faktycznie zastosowaną Policy.

Dla bardzo dużych grup istotny jest atrybut AD member. Od 1'500 wpisów AD stosuje Range Retrieval, np. member;range=0-1499, i opróżnia zwykły member. Grupa mająca ponad 1'500 obiektów już przed pierwszym Sync może nie pojawić się w Central lub pokazać błędną liczbę członków. W miarę możliwości ogranicza się ją do mniej niż 1'500 użytkowników i sprawdza w LDP.exe.

Dopasowywanie użytkowników i aliasy e-mail

Central dopasowuje użytkowników AD do istniejących po Domain Login DOMAIN\user lub atrybucie mail. Nazwa pochodzi z Display name, a dodatkowe aliasy z proxyAddresses. Trafienie zmienia istniejący obiekt Central w obiekt zarządzany przez katalog; brak trafienia tworzy nowego użytkownika. Preview and Sync pokazuje trafienia w Users to Modify, a nowe obiekty w Users to Add.

Obiekt zsynchronizowany z innego Directory Service nie jest przy trafieniu tworzony drugi raz, ale może otrzymać adres e-mail z AD. Ręczny użytkownik i użytkownik AD o tej samej nazwie mogą pozostać osobnymi obiektami, jeśli Login i e-mail nie pasują. Display Name nie jest kluczem dopasowania.

W Preview and Sync każdy wpis Users to Modify i Users to Add sprawdza się osobno. Błędne dopasowanie odrzuca się zamiast akceptować wszystko przez Approve Changes and Continue. Przejście użytkownika ręcznego na zarządzanie AD widać też po ikonie katalogu.

Po usunięciu użytkownika z AD zachowanie zależy od powiązań. Administratorzy oraz użytkownicy z przypisanym urządzeniem lub Login pozostają zwykłymi użytkownikami Central. Czysty użytkownik bez urządzenia, Login ani roli uprzywilejowanej może zostać automatycznie usunięty. Z tego samego powodu zmiany e-mail administratora Central nie są ślepo przejmowane z AD. Przed offboardingiem sprawdza się osobno role i urządzenia.

Aby zmienić główny e-mail administratora zarządzanego katalogowo lub usunąć jego pozostały po AD obiekt Central, przed kolejnym Sync kontrolowanie odbiera się rolę Admin. Po synchronizacji można przypisać potrzebną rolę ponownie. Zawsze pozostaje drugi sprawny Super Admin jako droga Recovery.

Błędna nazwa przez nakładające się Logins

Jeśli użytkownik A omyłkowo ma także Login urządzenia użytkownika B, AD Sync może przypisać oba Logins do A, a przy późniejszym przetwarzaniu B zmienić nazwę rekordu na B. W Central usuwa się więc wszystkie obce przypisania w Logins i synchronizuje ponownie. Nie poprawia się tylko nazwy, dopóki błędny Login istnieje.

Nie można przypisać roli użytkownikowi AD

Najpierw w My Environment > Users & Groups > Users wyszukuje się e-mail. Przy duplikatach dokumentuje się Logins nieużywanych obiektów, usuwa je przez Edit logins i dodaje do właściwego użytkownika. Dopiero potem zapisuje się rolę i sprawdza wysyłkę Setup. Jeśli e-mail pozostaje zablokowany w całym Tenant, nie usuwa się dalej obiektów, lecz rozwiązuje konflikt przez Support.

Prawidłowe odczytywanie grup zagnieżdżonych

Strona użytkownika może obok bezpośredniej grupy AD pokazywać nadrzędne grupy zagnieżdżone jako linked groups. Nie oznacza to bezpośredniego członkostwa w każdej z nich. Przy analizie uprawnień i Policies osobno sprawdza się bezpośrednie członkostwo AD, zagnieżdżenie i faktycznie zastosowaną Central Policy.

AD Sync importuje Login jako NETBIOSDOMAIN\user, a Mac często zgłasza MACNAME\user, przez co Central może utworzyć drugi obiekt. Po sprawdzeniu urządzeń obiekt porządkuje się i przypisuje MACNAME\user do użytkownika AD. Przy większym Rollout testuje się przewidziany przez Sophos Domain Override zamiast ręcznych poprawek.

Synchronizacja komputerów i grup OU

Wykrywanie urządzeń obsługuje komputery i serwery Windows. Sophos dopasowuje chronione urządzenie do obiektu AD według FQDN i Hostname oraz przenosi je do zsynchronizowanej OU Group. Ręcznie pogrupowany komputer może więc wrócić do struktury AD przy następnym Sync.

Nowy obiekt urządzenia lub grupy powstaje, jeśli Central nie zna tej samej AD ObjectGUID. Przy kolizji nazwy nowej AD Group z istniejącą grupą Central używa Distinguished Name. Kilka rekordów AD o tym samym DN nie jest obsługiwanych.

FQDN i Hostname muszą pasować. Jeśli urządzenie Central ma Domain i Hostname, ale inne zapisane szczegóły, Sync aktualizuje je i przenosi urządzenie do właściwej AD Group. Przy dwóch urządzeniach z tym samym FQDN dotychczasowe powiązanie jest rozłączane i łączony jest nowy rekord. Duplikaty Hostnames porządkuje się przed Sync, zamiast traktować wynikające z tego ponowne powiązanie jako przypadkową utratę urządzenia.

OUs synchronizuje się przed urządzeniami, aby najpierw przygotować Policies dla przewidzianych grup. Zsynchronizowanych urządzeń i grup nie można trwale reorganizować wbrew AD. Hierarchia głębsza niż 40 poziomów jest scalana od poziomu 40.

Obiekty można w Central przenosić lub usuwać, ale nie edytować jak lokalnych; kolejny Sync odtwarza strukturę lub obiekt. Po usunięciu chronionego urządzenia z AD Central przenosi je do grupy nieustrukturyzowanej i odbiera oznaczenie AD Managed. Zmiany nazw, systemu lub OU są przejmowane wraz z przenoszeniem i usuwaniem grup.

Policies ręcznych grup pozostają, lecz urządzenia AD są przenoszone do grup synchronizowanych i początkowo dostają Default Policies, jeśli wcześniej nie przypisano właściwej Policy. Policy grupy Top Level dziedziczy grupa zagnieżdżona bez własnego przypisania. Dlatego najpierw synchronizuje się OUs, przypisuje Policies, potem urządzenia.

Sophos nie udostępnia obecnie API dla AD-synchronizowanych Directory Devices i Device Groups. Automatyzacja nie może zakładać pełnego zarządzania nimi jak zwykłymi Central Groups.

W My Environment > Unmanaged devices komputery i serwery AD bez Sophos Agent są widoczne osobno. Pakiety są w My Environment > Installers. Widok nie instaluje ochrony; urządzenie pozostaje w procesie Rollout lub wyjątku do instalacji Agent albo zatwierdzenia wyjątku.

Harmonogram i monitorowanie

Harmonogram musi odpowiadać częstotliwości zmian. Po każdym przebiegu kontroluje się status, błędy i zmiany obiektów. Uruchomiona usługa nie dowodzi poprawnej synchronizacji.

Ostrzeżenia o Credentials, połączeniu, brakujących atrybutach lub konfliktach usuwa się szybko. Proces wymaga Owner i zastępstwa.

Przy pierwszym przebiegu i każdej zmianie filtra ręcznie uruchamia się Preview and Sync, sprawdza dodawanie, zmiany i usunięcia, a następnie zatwierdza przez Approve Changes and Continue. Ręczny przebieg może trwać do 15 minut. Dla samych przebiegów ręcznych wybiera się Never. Only sync when manually initiated.

Runtime Logs znajdują się w:

C:\ProgramData\Sophos\Sophos Cloud AD Sync\Logs\

Rotują w siedmiu plikach dziennych, dlatego potrzebny Log kopiuje się lub zmienia nazwę przed rotacją. Medium Email Alert często zawiera tylko podsumowanie; przyczyny szuka się w Log z tego samego czasu.

Przy wymianie serwera nie uruchamia się niekontrolowanej drugiej instancji. Najpierw zatrzymuje się stary harmonogram, konfiguruje aktualną Utility na nowym serwerze, porównuje filtry i wykonuje Preview and Sync. Dopiero po udanym ręcznym przebiegu włącza się harmonogram i usuwa starą instalację.

Usuwanie i ponowne tworzenie

Usunięcie obiektu ze źródła lub filtra może wpłynąć na obiekt Central i Policy. Przed zmianą masową czyta się i dokumentuje działania zapowiadane w interfejsie.

Usuwanie konfiguracji Sync lub danych nie jest zwykłym Troubleshooting. Najpierw sprawdza się urządzenia, grupy i duplikaty. Odbudowa bez analizy może odtworzyć problem.

Przed Purge data zatrzymuje się wszystkie instancje AD Sync i sprawdza filtry, inaczej dane wrócą. Purge jest nieodwracalny. Managed Devices, przypisani użytkownicy i Administrators nie są usuwani, nawet jeśli pochodzą z AD.

Purge zsynchronizowanych danych AD

W Global Settings > Platform > Directory service otwiera się źródło AD, zatrzymuje przez Turn off i wybiera Purge data. Zakres wybiera się świadomie:

Users and user groups usuwa też zsynchronizowane Shared Mailboxes i Public Folders.
Devices and device groups usuwa urządzenia i grupy poza chronionymi obiektami wskazanymi przez Sophos.

Po potwierdzeniu nieodwracalności ponownie wybiera się Purge data. Central usuwa zakres i nie synchronizuje go ponownie ze zatrzymanego źródła. Po usunięciu wszystkich danych trzeba zarządzać nimi ręcznie lub przez nowe, rozdzielone źródło, np. Entra ID dla użytkowników i grup.

Przed Purge wyszukuje się i zatrzymuje wszystkie kopie Utility i harmonogramy. Same filtry nie zapobiegną powrotowi danych, jeśli druga instancja nadal je synchronizuje. Po operacji kontroluje się pozostałych Administrators, Managed Devices i przypisanych użytkowników, ponieważ Central nie usuwa tych wyjątków.

Przejście z AD na Microsoft Entra ID

Sophos obsługuje zmianę źródła użytkowników i grup Domain z AD na Entra ID. Oba źródła muszą odpowiadać tej samej Domain, a użytkownicy muszą być wiarygodnie zgodni. Niedopasowani użytkownicy AD mogą zostać usunięci z Central.

Entra ID nie synchronizuje komputerów i grup komputerów. Jeśli są potrzebne, AD pozostaje dla urządzeń, a Entra ID dostarcza użytkowników i grupy. Public Folders i istniejące przypisania Shared Mailbox sprawdza się osobno.

Migracja zaczyna się od eksportu i listy porównawczej. Dopasowani użytkownicy aktualizują istniejący obiekt i zachowują Mailboxes; niedopasowani mogą zostać usunięci z przypisaniem Mailbox, a nowi Entra Users są tworzeni. Niedopasowane grupy pozostają, lecz nie są aktualizowane.

Dotychczasowe AD Shared Mailboxes i Public Folders pozostają z ostatnim stanem, ale AD już ich nie aktualizuje; nowe Entra Shared Mailboxes mogą pojawić się dodatkowo. Dalszy stary On Premises AD Sync może je nieoczekiwanie usuwać wskutek różnych typów obiektów.

Po migracji kontroluje się użytkowników, grupy, Policies, urządzenia, Shared Mailboxes, Public Folders i duplikaty. Jeśli AD pozostaje dla urządzeń, Sync devices i Sync organizational units działają wspólnie.

Wymagania i decyzja migracyjna

AD i Entra ID muszą odwzorowywać tę samą Domain. Użytkowników porównuje się po unikatowych e-mailach i innych zgodnych cechach, aby Central aktualizował konta zamiast usuwać i tworzyć. Entra Connector i App Permissions przygotowuje się przed wyłączeniem AD.

Public Folders, komputery i grupy komputerów pochodzą nadal tylko z AD. Dla każdej Domain wybiera się Entra Only albo równoległe AD dla urządzeń i OU. Shared Mailboxes inwentaryzuje się osobno według obiektów AD, Entra i grup Microsoft 365.

Używanie tylko Microsoft Entra ID

Wariant pasuje, gdy Central nie musi dalej aktualizować urządzeń, grup urządzeń ani Public Folders z AD.

Wykonać ostatni AD Sync i sprawdzić użytkowników, grupy, Mailboxes oraz błędy.
Otworzyć źródło w Global Settings > Platform > Directory service i wyłączyć przez Turn off.
Przez Add Microsoft Entra ID skonfigurować źródło tej samej Domain i App Permissions.
Uruchomić Entra Sync i porównać użytkowników, grupy oraz Shared Mailboxes z eksportem.
Dopiero po zatwierdzeniu odinstalować AD Sync Setup Software i po kontroli odwołać API Credentials.

Wyłączenie starego źródła jest kontrolowaną migracją, nie Troubleshooting Reset. Przy usunięciach najpierw analizuje się Matching Report, zamiast wielokrotnie włączać i wyłączać Sync.

Równoległe używanie Microsoft Entra ID i AD

Entra ID obsługuje użytkowników, grupy i nowoczesne Shared Mailboxes, AD urządzenia i grupy urządzeń.

Wykonać pełny AD Sync i zatwierdzić stan początkowy.
W Utility ograniczyć wybór do Sync devices i Sync organizational units; użytkownicy i grupy użytkowników nie będą już dostarczani z AD.
Tymczasowo wyłączyć źródło AD przez Turn off.
Dodać Entra ID tej samej Domain, zsynchronizować i sprawdzić użytkowników, grupy i Shared Mailboxes.
Włączyć AD przez Turn on, zsynchronizować ręcznie i potwierdzić aktualizację urządzeń bez ponownego importu użytkowników z AD.

Oba źródła mają własnych Owners, harmonogramy i wartości kontrolne. Dwa zielone statusy nie dowodzą poprawnego rozdzielenia obiektów.

Wpływ na użytkowników, grupy, Mailboxes i urządzenia

Entra aktualizuje zgodnych użytkowników i zachowuje Mailbox Information. Niedopasowany AD User może zostać usunięty z Central wraz z przypisaniem Mailbox; nowy Entra User powstaje z dostępnymi danymi Mailbox.

Zgodne grupy są aktualizowane. AD Groups bez odpowiednika Entra pozostają widoczne, lecz bez aktualizacji; nowe Entra Groups powstają. Pozostała grupa nie dowodzi działającego Sync, dlatego osobno kontroluje się Policies i członkostwa.

Stare AD Shared Mailboxes i Public Folders pozostają z ostatnim stanem. Shared Mailboxes nadal są w Mailboxes, ale mogą stracić użytkowników. Nowe Entra Shared Mailboxes mogą występować jako User Object i w Mailboxes, bez znanej z AD delegacji. Ponownie sprawdza się Delegated Access i Quarantine Summaries. Niepilnowany stary AD Sync może usunąć skrzynki.

W modelu Entra Only stare AD Devices i Device Groups pozostają, ale nie są aktualizowane. W modelu równoległym AD nadal je synchronizuje. Entra nie dostarcza komputerów, grup komputerów ani Public Folders. Należy to udokumentować, aby pozostawionych danych nie uznać za aktualny Sync.

Przenoszenie istniejących Endpoints do nowej AD Domain

Jeśli zmienia się tylko AD Domain, a Computer Name i SID pozostają, Sophos Agent nie wymaga reinstalacji, a machine_id pozostaje. Najpierw w Global Settings > Platform > Directory service zmienia się Domain, waliduje Credentials i synchronizuje użytkowników, grupy, OUs i urządzenia. Dopiero potem Endpoints mogą połączyć się z Central.

Nowy FQDN rozłącza stare przypisanie AD i wyszukuje obiekt urządzenia w nowej Domain. Trafienie ponownie łączy ten sam Endpoint Object i przy OU Sync przenosi do właściwej grupy. Logins zmieniają się np. z OLDDOMAIN\jsmith na NEWDOMAIN\jsmith i mogą tworzyć duplikaty.

Kontrola obejmuje nową Domain, OU Group, zastosowane Policies i użytkownika. Dopiero potem usuwa się stare obiekty urządzeń, użytkowników, grup lub Directory starej Domain.

Częste problemy

Użytkownik występuje dwukrotnie

Porównać źródła, e-mail, UPN i obiekty ręczne. Nie usuwać obiektu z powiązanymi urządzeniami lub Policies.

Brakuje nowej grupy

Sprawdzić filtry OU i grup, zagnieżdżenie, ostatni udany Sync i atrybuty.

`0000208D`, `NO_OBJECT` lub «The object does not exist»

Custom Filter zwykle wskazuje usuniętą OU, której nazwy błąd nie podaje. W Define Filters porównuje się wszystkie filtry z AD i usuwa tylko martwe odwołania, potem wykonuje Preview i sprawdza usunięcia.

`0xFFFE` lub `0xFFFF` w Preview and Sync

Jeśli Active Directory zawiera znaki o nieprawidłowych wartościach szesnastkowych 0xFFFE lub 0xFFFF, ręczny przebieg może zostać przerwany. Należy poprawić atrybut źródłowy. Tymczasowo Sophos wskazuje Sync on Schedule - automatic (within next 2-3 minutes), który pomija Preview. Nie jest to naprawa; zakres, wynik oraz nowe i usunięte obiekty natychmiast kontroluje się w Central i Log.

`endpoint_user_sessions.user_match_id` podczas usuwania Login

Error syncing record: Error deleting login z Foreign Key endpoint_user_sessions.user_match_id może wystąpić, gdy sesja blokuje usunięcie Login po usunięciu użytkownika AD. Reszta Sync może się udać. Przy powtórzeniu dokumentuje się użytkownika, Login i czas oraz angażuje Sophos Support; Purge całego Sync jest nieproporcjonalny.

Synchronizacja pozostaje nieaktualna

Sprawdzić Windows Service, konto, hasło, DNS, Proxy, Firewall i Central Sync. Do Support Ticket dołączyć Logs i timestamps.

Od AD Sync Client 5.x Audit Log pokazuje przy Directory Sync jako Modified by GUID zarejestrowanego AD Sync Client zamiast Client ID API Credential, dla Create, Update i Delete. GUID koreluje się z instancją, harmonogramem i czasem Log, nie uznaje automatycznie za napastnika.

Credentials LDAP są stale wymagane

NeedADCredsException z The LDAP server is unavailable nie musi oznaczać złego hasła. Sprawdza się Domain Controller, DOMAIN\username, prawa i port. LDAPS zwykle używa TCP 636 i wymaga zaufanego certyfikatu. Sam nasłuch portu nie dowodzi TLS.

Eskalacja do Sophos Support

Zgłoszenie zawiera opis, Tenant, licencję, dokładny czas, wersję AD Sync, wszystkie Logs, Screenshots i publiczny IP systemu z chwili zbierania. Partner podaje właściwego klienta MSP. Remote Assistance włącza się tylko dla sprawy i po zgodzie.

Oficjalne źródło

Aktualna instrukcja Sophos dotycząca konfiguracji i synchronizacji: Set up synchronization with Active Directory.

Często zadawane pytania

Czy należy synchronizować całe Active Directory?

Zwykle nie. Ograniczony wybór zmniejsza konta techniczne, ilość danych, duplikaty i niezamierzone przypisania Policies.

Czy AD Sync może działać równolegle z Entra ID Sync?

Tak, ale tylko przy jasno rozdzielonych zbiorach obiektów. Import tych samych tożsamości z wielu źródeł grozi duplikatami i niejasną odpowiedzialnością.