Synkronisera Active Directory med Sophos Central

Sophos Central kan importera användare och grupper från ett lokalt Active Directory. Identiteterna används bland annat för policy- och enhetstilldelning. En okontrollerad synkronisering kan dock skapa onödiga konton, dubbletter eller oväntade borttagningar.

Microsoft Entra ID synkroniseras via en separat anslutning. Instruktionerna finns i Synkronisera Microsoft Entra ID med Sophos Central.

Fastställ källmodellen före installationen

Central kan hantera upp till 25 katalogkällor per klientorganisation. För fler källor används en Central Enterprise-struktur. Användare och e-postadresser måste vara unika inom en Central-klientorganisation. Samma domän får inte samtidigt leverera användare via flera AD-, Entra ID- eller Google Directory-källor.

I en provperiod begränsar Sophos dessutom antalet Directory Objects som kan skapas eller användas, bland annat användare, enheter och grupper. En ofullständig testimport är därför inte automatiskt ett filterfel. Före en pilot kontrolleras provperiodens omfattning, förväntat objektantal och licensstatus tillsammans.

Flera Child Domains kan väljas inom en Forest, och en klientorganisation kan även synkronisera flera Forests. Sophos rekommenderar ändå att varje Forest endast ansluts till en Central-klientorganisation. Om samma Forest importeras till flera klientorganisationer, eller om flera Forests innehåller samma användare eller e-postadresser, uppdaterar körningarna omväxlande samma skenbara identiteter. Central slår inte samman posterna, vilket kan göra namn, attribut och grupptilldelningar inkonsekventa.

En understödd hybridmodell är däremot lämplig: AD synkroniserar datorer och datorgrupper, medan Entra ID levererar användare och användargrupper för samma domän. Shared Mailboxes i en Microsoft 365-grupp kräver Entra ID eller Google Directory. En vanlig Shared Mailbox utanför en Microsoft 365-grupp kan importeras via AD Sync.

Shared Mailboxes och Public Folders från samma domän som användarna kräver AD Sync Utility tillsammans med Sync users and user groups. Microsoft 365-gruppostlådor importeras inte via AD Sync. En Shared Mailbox utan Delegate synkroniseras inte heller. Om en inaktiv användarpostlåda med e-postdelegering till en aktiv postlåda finns kvar tar AD Sync inte bort den, utan kan fortsätta hantera den som Shared Mailbox i Central.

För samma domän eller underdomän körs endast en AD Sync-klient i produktion. Flera AD-enheter får inte heller ha samma DNS-värdnamn, eftersom Central då inte kan matcha dem entydigt. Vid serverbyte stoppas därför det gamla schemat innan den nya instansen börjar synkronisera i produktion.

Om Self Service Portal ska användas för Sophos Email, Device Encryption eller Mobile aktiveras användaråtkomst före den första Directory Sync-körningen. Då får nya och befintliga användare den avsedda inbjudan. Arbetsflödet beskrivs i Konfigurera åtkomst till Sophos Central Self Service Portal.

Gränser för AD Sync och domänöverskridande grupper

AD Sync slår inte samman data från flera Forests eller Directory Services till en masterpost. Samma användare eller e-postadress får därför inte förekomma i mer än en synkroniserad Forest. Dubbla användare, e-postadresser eller grupper kan vid varje körning växelvis uppdateras med informationen från respektive källa och till och med byta Directory Owner i Central. Användare och e-postadresser förblir unika per klientorganisation. Användare från samma domän får inte synkroniseras samtidigt från AD och Entra ID eller levereras parallellt till flera Central Admin Accounts.

För en grupp med medlemmar från flera domäner importerar Central bara användare från domänen som gruppen tillhör. Preview and Sync kan visa alla medlemmar, men användare från den andra domänen läggs inte till i gruppen vid produktionssynkroniseringen. Beteendet testas för Universal Groups och Child Domains med en testmedlem per domän.

Användare och användargrupper synkroniseras eller stängs av tillsammans. Detsamma gäller enheter och enhetsgrupper. Högst 1'000 filter stöds per Directory Object, och ytterligare LDAP-filter får innehålla högst 5'000 tecken. Domändelar som är längre än 63 tecken eller börjar eller slutar med - eller _ stöds inte.

Microsoft 365-gruppostlådor kräver Entra ID. AD Sync stöder inte Shared Mailboxes utan Delegate, flera produktiva AD Sync-klienter för samma domän eller underdomän eller flera AD-enheter med identiskt DNS-värdnamn. En inaktiv postlåda med delegering till en aktiv postlåda kan däremot bevaras som Shared Mailbox. Sådana gränser hanteras som designbeslut före den första körningen och kringgås inte i efterhand med bredare filter.

Rensa inaktiva AD-objekt före synkroniseringen

Inaktiva användarkonton och enheter granskas och tas om möjligt bort eller inaktiveras direkt i Active Directory. De ökar inte bara beståndet i Central utan förblir en säkerhetsrisk i källan. En rensning minskar dessutom synkroniseringsfilen som överförs till Sophos Central och kan påskynda körningen.

LDAP-filter kan förhindra att inaktiva användare överförs till Central och också minska synkroniseringsfilen. De åtgärdar dock inte risken med ett inaktivt AD-konto som finns kvar. Driftprocessen kombinerar därför en spårbar inaktivitetsperiod, godkännande från ägaren, rensning i källan och en efterföljande Preview-körning. Enheter granskas separat avseende ålder, senaste domänkontakt och skyddsstatus innan ett datorkonto tas bort.

Hantera Directory Sources i Central

Den centrala översikten finns under Global Settings > Platform > Directory service. En lämplig Central Admin-roll krävs för att konfigurera och hantera en källa. Beroende på önskad källa erbjuder sidan Add Active Directory, Add Microsoft Entra ID och Add directory service for Google. För lokalt AD hämtas aktuell installationsprogramvara härifrån. Entra ID och Google auktoriseras via sina respektive molnanslutningar.

Källistan visar namn, typ, domän, schema och status för varje post. Varningar och fel kontrolleras inte bara i översikten utan även under Alerts and Reports > Logs > General Logs > Events. En grön källstatus räcker inte om den senaste körningen är inaktuell eller det förväntade objektantalet inte stämmer.

Ett klick på namnet öppnar detaljerna. För AD kontrolleras särskilt antalet användare, grupper, enheter, enhetsgrupper, Public Folders och Shared Mailboxes samt värdnamn, klientversion, domän, status och tidpunkt för den senaste synkroniseringen. För Entra ID och Google ligger fokus på antal användare och grupper, status, senaste körning och schema. Värdena jämförs efter den första konfigurationen och efter varje filter- eller källändring med en känd referensmängd.

Beroende på källtyp går det också att ändra konfiguration och filter, rensa synkroniserade data och ta bort källan. Detta är olika ingrepp: Purge tar bort katalogdata som har importerats från källan, medan Delete dessutom tar bort själva Directory Source. För AD stoppas först synkroniseringsalternativ och aktiva klienter. För Entra ID och Google används respektive dialogrutor för filter, Purge och Delete. Före varje variant exporteras berörda användare, grupper, enheter, policies och postlådor och de konsekvenser som Central anger läses igenom. Purge och Delete är inga oförbindande anslutningstester och bekräftas inte utan återställningsplan.

Namn och beskrivning för en källa kan ändras först efter att den har inaktiverats med Turn off. Efter lagringen aktiveras den igen med Turn on och kontrolleras. Avstängningen avbryter uppdateringen och görs därför inte under en ogranskad katalogändring. När synkroniseringen har aktiverats i produktion för en källa går detta steg inte enkelt att ångra. För en manuell körning öppnas källan och Synchronize väljs. Därefter kontrolleras status, tidpunkt och objektändringar.

Planera Self Service och Shared Mailboxes före synkroniseringen

Om en användare ska använda Self Service Portal aktiveras User Access före den första Directory Sync-körningen. Då kan Central skicka inbjudningarna i det avsedda arbetsflödet. Åtkomst som aktiveras senare korrigerar inte automatiskt varje tidigare missad leverans. Därför testas pilotanvändare, e-postleverans och portalåtkomst redan före den breda importen.

Shared Mailboxes har inte nödvändigtvis fullständiga användarattribut i Central. Delegerade användare får Self Service-åtkomst för den Shared Mailbox som har tilldelats dem och ser där, beroende på licensierad produkt, exempelvis Emergency Inbox och Quarantine Summary. En Delegate kan därmed få sammanfattningar för sin egen postlåda och dessutom för Shared Mailbox. Delegeringar och leveransadresser testas därför i praktiken efter synkroniseringen och godkänns inte enbart utifrån objektantalet.

En Shared Mailbox i en Microsoft 365-grupp kan inte synkroniseras via lokalt AD. Microsoft Entra ID eller Google Directory används i stället. En vanlig Shared Mailbox utanför en Microsoft 365-grupp kan importeras med AD Sync. Före en senare migrering till Entra ID inventeras vilka postlådor som kommer från vilken objekttyp. Annars kan fortsatt AD Sync efter källbytet ta bort postlådor eller lämna dem med inaktuella data.

Före den första synkroniseringen

Först fastställs vilken katalog som är ledande för vilka användare och grupper. Samma personer bör inte skapas samtidigt manuellt, från AD och från Entra ID.

För den första körningen rekommenderas en liten test-OU med representativa användare och grupper. Följande kontrolleras:

• e-postadresser och User Principal Names,
• kapslade grupper och medlemskap,
• inaktiverade eller inaktuella konton,
• servicekonton och tekniska konton,
• namnkonflikter med befintliga Central-objekt.

Varje användare som ska synkroniseras behöver en unik e-postadress. Många Central-processer använder den som identitet och leveransmål. För Sophos Email kan ett meddelande till en adress utan tilldelad användare till och med bli olevererbart. Brandväggen eller proxyn måste dessutom kunna nå domänerna och portarna som dokumenteras för Central. Ett lyckat LDAP-test bekräftar inte denna molnväg.

Installera AD Sync Utility

Den aktuella synkroniseringsprogramvaran hämtas direkt från Sophos Central och installeras på ett Windows-system med ständig tillgänglighet. Systemet behöver nätverksåtkomst till Domain Controller och nödvändiga Sophos-tjänster.

Aktuell Active Directory Synchronization Setup Software körs endast på ett 64-bitars Windows-system och kräver .NET Framework 4.6.2. Sophos anger Windows 7, 8.1, 10 och 11 samt Windows Server 2008 R2, 2012, 2012 R2, 2016, 2019, 2022 och 2025. Som Domain Controller anger Sophos Windows Server 2008 R2 till 2025. Denna tillverkarkompatibilitet ersätter inte Microsofts livscykel. För en ny produktionsinstallation används ett operativsystem som stöds och är uppdaterat, inte Windows 7 eller en utfasad Windows Server-version.

För åtkomst till Central används API Credentials med rollen Service Principal Active Directory Sync, inte generella Super Admin-inloggningsuppgifter.

AD-tjänstekontot får bara de rättigheter som behövs för att läsa valda Forests och katalogobjekt. Lösenordets giltighet, tjänstens start och ansvar dokumenteras. Ett personligt administratörskonto är olämpligt.

Utility kan inte bearbeta en domän om en enskild del av namnet är längre än 63 tecken eller börjar eller slutar med - eller _. Gränsen kontrolleras före installationen, eftersom ett förkortat visningsnamn eller en annan UPN inte korrigerar ett ogiltigt AD-domännamn.

Sophos har testat upp till 30'000 AD-objekt. Över 40'000 användarposter kan gränssnittet reagera långsammare. Större miljöer filtreras därför särskilt strikt och testas med realistiska körtider.

Vid varje synkroniseringskörning kontrollerar Utility om en nyare version finns och utför normalt efterföljande uppgraderingar automatiskt. Tidiga AD Sync-versioner stöder inte längre aktuell Central-autentisering och kan sluta fungera helt om den automatiska uppgraderingen misslyckas. I så fall hämtas det aktuella installationsprogrammet under Global Settings > Platform > Directory service och körs över den befintliga installationen. Därefter skapas nya API Credentials med rollen Service Principal Active Directory Sync och anges som Client ID och Client Secret i Utility. Varje produktiv synkroniseringsinstans får en spårbar teknisk identitet, dokumenterat ansvar och egen Secret-rotation.

Vid start kontrolleras Client ID och Client Secret med Validate credentials. Om Utility måste kommunicera via en proxy aktiveras Configure proxy manually och proxyadressen anges. Om proxyn kräver inloggning läggs Enable proxy authentication, proxyanvändare och proxylösenord till. Först ett lyckat andra Credential-test bekräftar att både API-uppgifterna och proxyvägen fungerar.

Denna proxydialog tillhör Active Directory Synchronization Setup 4.0. En provklientorganisation kan i stället fortfarande få den äldre Sophos Central AD Sync Utility 3.5.4, där proxyuppgifter inte kan anges i gränssnittet. Tjänsten körs som standard som Local Service och misslyckas ofta vid en autentiserande proxy med Failed active directory synchronization, System.Net.Http.HttpRequestException och CommandLib.HttpRequestCommand+HttpStatusException. Ett alternativt tjänstekonto som används för detta behöver Log on as a service, interaktiv inloggning och Batch-inloggning, läsrättigheter till berörda OUs samt fullständig åtkomst till C:\ProgramData\Sophos\Sophos Cloud AD Sync. Efter varje byte av tjänstekonto konfigureras den gamla Utility på nytt. Aktuell 4.0-programvara används om möjligt i produktionsmiljöer.

För LDAP-åtkomst används ett läskonto för hela vald Forest. Use LDAP over an SSL connection förblir om möjligt aktiverat. LDAPS använder normalt TCP 636, okrypterad LDAP TCP 389. På grund av LDAP Signing och Channel Binding är port 389 ingen tillförlitlig utväg i aktuella Active Directory-miljöer. Domain Controller behöver ett giltigt certifikat för LDAPS som synkroniseringssystemet litar på.

Om den specifika LDAP-miljön bevisligen inte stöder SSL kan Use Secure LDAP stängas av och porten ändras till den okrypterade LDAP-tjänsten. Det är en dokumenterad reservlösning, inte Best Practice. Inloggningsuppgifter och katalogdata skyddas då inte av TLS under transporten. Segmentering, nätverksväg och en snar övergång till LDAPS hanteras därför som en risk.

Vad Utility förväntar sig i Forest

För en fullständig Forest läser AD Sync rootDomainNamingContext med Distinguished Name för Forest Root Domain och defaultNamingContext med Distinguished Name för den server som används vid katalogträdets rot. Under CN=Partitions,CN=Configuration,<rootDomainNamingContext> förväntar sig Utility poster med netBiosName, dnsRoot och nCName för relevanta namnkontexter. Värdet för nCName avgör de ytterligare sökområdena, förutsatt att det inte är ett överordnat Distinguished Name för servern som anges i installationsdialogen.

Om ett av attributen saknas eller tjänstekontot inte får läsa Configuration-partitionen kan ett inloggningstest fungera medan identifieringen av Forest eller den senare synkroniseringen ändå misslyckas. Då kontrolleras värdena med LDP.exe under samma tjänstekonto innan filter eller Central-objekt ändras.

Filtrera OUs och objekt

Filter begränsar synkroniseringens omfattning. Endast OUs, användare och grupper som Sophos Central faktiskt behöver inkluderas. En bred import från roten är sällan lämplig.

Före importen kontrollerar förhandsgranskningen vilka objekt som skulle läggas till, ändras eller tas bort. Särskilt borttagningar bekräftas inte utan granskning. Vyn Preview eller Pending Changes kan inte visa UTF-16- eller Double-Byte-tecken korrekt och visar exempelvis ??? i stället. Uppgifterna överförs ändå till Sophos Central och visas där. Namn på exempelvis kinesiska, japanska eller koreanska kontrolleras därför både direkt i Active Directory och i Central efter en kontrollerad pilotsynkronisering.

Sophos beskriver detta Preview-problem som en begränsning som ska åtgärdas i en framtida version av AD Sync Utility. Tills den installerade versionen bevisligen har korrigerat problemet krävs kontrollen i källkatalogen och efter synkroniseringen.

Base DN och LDAP filter löser två olika uppgifter. Base DN begränsar sökningen till utvalda OUs. Ett OU-medlemskap kan inte uttryckas tillförlitligt enbart som ett vanligt LDAP-filter i Active Directory. LDAP-filtret begränsar attribut eller gruppmedlemskap inom sökområdet. Båda filtren hanteras per domän, eftersom Child Domains inte ärver inställningen från sin Parent Domain. Användar- och gruppfilter fungerar också oberoende av varandra.

På fliken AD Filters anges Search Bases och LDAP Query Filters separat per domän och vid behov separat för användare och grupper. En Search Base för en Finance-OU kan exempelvis se ut så här:

OU=Finance,DC=myCompany,DC=com

Ett användarfilter för medlemmar i en grupp kan exempelvis vara:

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

Utan ett ytterligare gruppfilter identifierar Central fortfarande alla grupper som dessa användare tillhör. Om gruppurvalet också ska begränsas till denna enda grupp läggs exempelvis CN=testGroup till som gruppfilter. En filterändring kan flytta tidigare synkroniserade användare och grupper utanför omfattningen och ta bort dem i Central. Därför görs alltid en fullständig förhandsgranskning.

Sophos använder följande filter som utgångspunkt:

Användare: (&(objectCategory=person)(objectClass=user)(!sAMAccountType=805306370)(!userAccountControl:1.2.840.113556.1.4.803:=2))
Grupper:   (&(objectCategory=group)(objectClass=group))

Användarfiltret inkluderar personer med klassen user, men utesluter datorobjekt via sAMAccountType=805306370 och inaktiverade konton via motsvarande userAccountControl-bit. Ytterligare filter kombineras per domän med dessa grundvillkor och testas först med LDP.exe.

Sophos begränsar konfigurationen till 1'000 filter per katalogobjekt och 5'000 tecken per ytterligare LDAP-filter. Användare kan bara synkroniseras tillsammans med användargrupper, enheter bara tillsammans med enhetsgrupper. För domänöverskridande grupper visar förhandsgranskningen alla medlemmar, men Central importerar bara användare från domänen som gruppen tillhör. Sådana grupper testas därför uttryckligen före produktionssynkroniseringen.

Det förväntade resultatet dubbelkontrolleras med Microsoft LDP.exe: Search Base i AD Sync motsvarar Base DN där, och AD Sync LDAP-uttrycket motsvarar Filter. På så sätt går det att skilja mellan att Sophos inte levererar objektet och att katalogfrågan redan från början inte gör det. Vissa attributjämförelser kan vara skiftlägeskänsliga.

Filter med lastLogon eller lastLogonTimestamp används försiktigt. lastLogon är vanligen mer aktuellt men replikeras inte mellan Domain Controllers. För ett tillförlitligt värde måste därför alla Domain Controllers tillfrågas. lastLogonTimestamp replikeras men kan vara inaktuellt. Sophos rekommenderar att inaktiva konton och enheter tas bort i källan i stället för att enbart förlita sig på ett tidsfilter.

Om lastLogonTimestamp ändå används som övergångsfilter fastställs först ett UTC-brytdatum och konverteras till Windows FILETIME med en tillförlitlig LDAP-/Active Directory-FILETIME-konverterare. Sophos exempeldatum 1 december 2020 klockan 00:01 ger 132581431640000000. Under Active Directory Synchronization Setup > AD Filters anges följande ytterligare LDAP-uttryck i fältet Custom Filters:

(lastLogonTimestamp>=132581431640000000)

Exempelvärdet används inte oförändrat. Ett eget brytdatum väljs medvetet, konverteras korrekt och dokumenteras tillsammans med tidszon och ändringsgodkännande. Därefter följer Preview and Sync, kontroll av inkluderade och uteslutna användare och först sedan godkännande av produktionskörningen.

AD Sync skapar endast grupper med fler än en medlem. En tom grupp eller en grupp med exakt en medlem visas därför inte som förväntat Central-objekt. Dubbla användare eller e-postadresser i flera Forests slås inte samman. Ett objekts källa kan därmed växla mellan körningarna. En Forest synkroniseras därför om möjligt med endast en Central-klientorganisation.

Exclude disabled user accounts är aktiverat som standard. Alternativet måste förbli aktiverat för synkronisering av Shared Mailboxes. Om det stängs av kan Central skapa dubbla postlådeobjekt för Shared Mailboxes. Inaktiverade vanliga användarkonton ska oavsett detta rensas i källan och inte återinföras genom en bredare synkronisering.

Datatypreglagen har konkreta beroenden:

• Sync users and user groups synkroniserar båda tillsammans och omfattar även vanliga Shared Mailboxes. Om reglaget stängs av kan varken Shared Mailboxes eller Public Folders synkroniseras via denna AD-källa.
• Sync public folders kräver dessutom Sync users and user groups, eftersom Public Folders behandlas som postlådeobjekt.
• För enheter aktiveras Sync devices och Sync organizational units tillsammans under normal drift. Vid den första konfigurationen kan först endast OUs importeras, så att policies kan förberedas före enheterna.
• Om endast Sync organizational units senare stängs av förblir enheterna aktiva, men befintliga OUs visas som Custom Groups. Om bara OU-synkronisering är aktiv tilldelas enheter inte längre till Central-grupperna.

Utan förberedda OU-grupper får nyligen synkroniserade enheter först Default Policies. Efter OU-piloten aktiveras därför båda enhetsreglagen tillsammans, och både tilldelning och faktiskt tillämpad policy kontrolleras.

För mycket stora grupper är även AD-attributet member relevant. Från 1'500 poster använder Active Directory Range Retrieval som member;range=0-1499 och tömmer det vanliga member-attributet. Om gruppen redan före den första synkroniseringen innehåller fler än 1'500 objekt kan den därför saknas i Central eller visa fel medlemsantal. Sådana grupper begränsas om möjligt till färre än 1'500 användarobjekt och kontrolleras med LDP.exe.

Användarmatchning och e-postalias

Central matchar AD-användare med befintliga användare via Domain Login i formatet DOMAIN\user eller attributet mail. Visningsnamnet kommer från Display name och ytterligare e-postalias från proxyAddresses. Vid en träff blir det befintliga Central-objektet kataloghanterat. Utan träff skapas en ny användare. Preview and Sync visar träffar under Users to Modify och nya objekt under Users to Add.

Ett objekt som synkroniserats av en annan Directory Service skapas inte som en andra ny användare vid en träff, men kan kompletteras med en e-postadress från AD. En manuellt skapad användare och en AD-användare med samma namn kan däremot finnas som två separata objekt om inloggning och e-postadress inte matchar. Enbart visningsnamnet är ingen matchningsnyckel.

I Preview and Sync granskas träffar under Users to Modify och nya identiteter under Users to Add individuellt. En felaktig tilldelning avvisas i stället för att hela förslaget godkänns med Approve Changes and Continue. Att en manuell användare har blivit ett AD-hanterat objekt syns dessutom på katalogikonen.

Om en användare tas bort i AD beror Centrals beteende på objektets beroenden. Administratörer och användare med en tilldelad enhet eller inloggning finns kvar som vanliga Central-användare. En ren användare utan enhet, inloggning eller privilegierad roll kan däremot tas bort automatiskt. Ändringar av e-postadressen för en Central-administratör importeras av samma skyddsskäl inte blint från AD. Administratörsroller och enhetskopplingar kontrolleras därför separat före en offboarding.

Om den primära e-postadressen för en kataloghanterad administratör ska ändras, eller om Central-objektet som finns kvar efter borttagningen i AD ska tas bort, återkallas administratörsrollen kontrollerat före nästa synkronisering. Efter synkroniseringen kan nödvändig roll tilldelas på nytt. Processen behåller alltid en andra fungerande Super Admin som återställningsväg.

Fel namn på grund av överlappande inloggningar

Om användare A av misstag också har enhetsinloggningen för användare B kan AD Sync först tilldela båda inloggningarna till A och när B senare bearbetas döpa om den befintliga posten till B. Under Logins för den berörda Central-användaren tas därför alla främmande tilldelningar bort och synkroniseringen körs sedan igen. Namn skrivs inte bara tillbaka så länge den felaktiga inloggningen finns kvar.

Rollen kan inte tilldelas till en AD-användare

Sök först efter e-postadressen under My Environment > Users & Groups > Users. Vid dubbletter dokumenteras inloggningarna för de objekt som inte ska användas, tas bort där via Edit logins och läggs till hos rätt användare. Först därefter sparas rollen och utskicket av installationslänken kontrolleras. Om e-postadressen fortfarande är blockerad i hela klientorganisationen görs inga ytterligare borttagningar. Konflikten löses i stället via supportvägen.

Tolka kapslade grupper korrekt

Användarsidan kan utöver den direkta AD-gruppen även visa överordnade, kapslade grupper som linked groups. Användaren är därmed inte automatiskt direkt medlem i varje grupp som visas. Vid behörighets- och policyanalys granskas direkt AD-medlemskap, kapsling och faktiskt tillämpad Central-policy separat.

Tilldela en Mac-inloggning till den synkroniserade användaren

AD Sync importerar en inloggning som NETBIOSDOMAIN\user, medan en Mac ofta rapporterar den som MACNAME\user. Central kan därför skapa ett andra automatiskt användarobjekt. Efter kontroll av berörda enheter rensas objektet och MACNAME\user tilldelas till den AD-synkroniserade användaren. Vid en större distribution testas Sophos avsedda Domain Override i stället för manuell efterbearbetning.

Synkronisera datorer och OU-grupper

Enhetsidentifieringen stöder Windows-datorer och Windows-servrar. Sophos kopplar en skyddad enhet till AD-objektet utifrån FQDN och värdnamn och flyttar den till den synkroniserade OU-gruppen. En dator som tidigare grupperats manuellt kan därmed återgå till AD-strukturen vid nästa synkronisering.

Ett nytt enhets- eller gruppobjekt skapas om Central ännu inte känner till någon post med samma AD-ObjectGUID. Om namnet på en ny AD-grupp kolliderar med en befintlig grupp använder Central Distinguished Name för den nya gruppen. Flera AD-poster med samma DN stöds inte.

Vid matchningen måste FQDN och värdnamn stämma. Om en Central-enhet finns med domän och värdnamn men avvikande lagrade uppgifter uppdaterar synkroniseringen informationen och flyttar enheten till rätt AD-grupp. Om två enheter har samma FQDN kopplas det tidigare länkade enhetsobjektet bort och den nya posten ansluts. Dubbla värdnamn rensas därför före synkroniseringen, i stället för att den resulterande omlänkningen behandlas som en slumpmässig enhetsförlust.

OUs synkroniseras före enheterna, så att policies först kan förberedas för avsedda grupper. Synkroniserade enheter och grupper kan inte organiseras om permanent i Central i strid med AD-strukturen. En hierarki med fler än 40 nivåer slås samman från nivå 40.

Synkroniserade enheter och grupper kan flyttas eller tas bort i Central, men inte redigeras som lokala objekt. Sådana manuella ändringar är inte bestående. Nästa synkronisering återställer AD-strukturen eller skapar objektet på nytt. Om en skyddad enhet tas bort i AD flyttar Central den vid nästa körning till en ostrukturerad grupp och tar bort markeringen som AD-hanterad enhet. Ändringar av namn, operativsystemuppgifter eller OU-struktur importeras också vid nästa synkronisering, inklusive flytt och borttagning av grupper.

Policies på manuellt skapade grupper finns kvar. AD-hanterade enheter flyttas dock från dessa grupper till den synkroniserade gruppen och får där först Default Policies, om inte en lämplig policy har tilldelats i förväg. En policy för en Top-Level-grupp ärvs av en kapslad grupp så länge den inte har en egen policytilldelning. Därför synkroniseras OUs först, policies tilldelas och enheterna importeras först därefter.

Sophos tillhandahåller för närvarande inget API för AD-synkroniserade Directory Devices och Device Groups. Automatiseringar får därför inte utgå från att strukturen kan hanteras fullständigt via API på samma sätt som vanliga Central-grupper.

Under My Environment > Unmanaged devices visas datorer och servrar som är kända från AD i separata vyer utan Sophos-agent. Nödvändiga skyddspaket finns under My Environment > Installers. Inventeringsvyn installerar dock inget skydd. Varje förväntad enhet förblir i distributions- eller undantagsprocessen tills agenten har installerats eller ett dokumenterat undantag har godkänts.

Schema och övervakning

Synkroniseringsschemat måste passa företagets ändringsfrekvens. Efter varje körning kontrolleras status, fel och objektändringar. En tjänst som har startat utan fel bevisar inte att alla objekt har synkroniserats korrekt.

Varningar om inloggningsuppgifter, anslutning, saknade attribut eller objektkonflikter åtgärdas snabbt. Driften behöver en ägare och en ställföreträdare.

Vid den första körningen och efter varje filterändring startas Preview and Sync manuellt. Förhandsgranskningen kontrolleras avseende nya, ändrade och borttagna objekt och bekräftas först därefter med Approve Changes and Continue. En manuell körning kan ta upp till 15 minuter. Om endast kontrollerade manuella körningar önskas väljs Never. Only sync when manually initiated i schemat.

Körningsloggarna finns under:

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

De roterar över sju dagsfiler. En logg som behövs för analys kopieras eller döps därför om före nästa rotation. En Medium-e-postvarning innehåller ofta bara sammanfattningen. Den konkreta orsaken söks i loggen från samma tidsintervall.

När AD Sync-servern byts ut körs aldrig en okontrollerad andra instans samtidigt. Först stoppas schemat på den tidigare servern. Därefter konfigureras aktuell Utility på den nya servern, den befintliga filterkonfigurationen jämförs och kontrolleras med Preview and Sync. Först efter en lyckad manuell körning aktiveras schemat där och den gamla installationen tas bort.

Borttagning och ny konfiguration

Om ett objekt tas bort i källkatalogen eller utesluts av filtret kan det påverka motsvarande Central-objekt och dess policytilldelning. Före en massändring läses och dokumenteras de åtgärder som gränssnittet aviserar.

Att ta bort synkroniseringskonfigurationen eller synkroniserade data är inget normalt felsökningssteg. Enhetstilldelning, gruppmedlemskap och möjliga dubbletter kontrolleras först. En ny konfiguration utan analys kan skapa samma problem igen.

Före Purge data stoppas alla aktiva eller kopierade AD Sync-instanser och filtren kontrolleras, annars återkommer uppgifterna. Purge kan inte ångras. Hanterade enheter och deras tilldelade användare samt administratörer tas inte bort även om de ursprungligen kommer från AD.

Rensa synkroniserade AD-data

Arbetsflödet börjar under Global Settings > Platform > Directory service. Där öppnas namnet på AD-källan, källan stoppas med Turn off och Purge data väljs. I dialogrutan väljs medvetet vilket dataområde som ska tas bort:

• Users and user groups tar dessutom bort synkroniserade Shared Mailboxes och Public Folders.
• Devices and device groups tar bort det synkroniserade beståndet av enheter och grupper, med undantag för de skyddade objekt som Sophos anger.

Efter bekräftelse av att åtgärden inte kan ångras väljs Purge data igen. Central tar bort det valda beståndet och synkroniserar inte denna datatyp igen från den stoppade källan. Om alla AD-data har tagits bort måste användare, enheter och grupper därefter hanteras manuellt eller via en ny, tydligt avgränsad källa. Microsoft Entra ID kan exempelvis ta över användare och användargrupper.

Före Purge söks och stoppas alla kopior av AD Sync Utility och deras scheman. Enbart filter förhindrar inte att uppgifterna återkommer om en andra instans fortsätter synkronisera. Därefter kontrolleras kvarvarande administratörer samt hanterade enheter och deras tilldelade användare, eftersom Central inte tar bort dessa undantag.

Byt från AD till Microsoft Entra ID

Sophos stöder byte av användar- och gruppsynkronisering för en domän från AD till Entra ID. Före bytet måste en lämplig AD- och Entra-källa finnas för samma domän och användarna i båda källorna måste matcha tillförlitligt. AD-användare som inte matchar kan tas bort från Central vid bytet.

Entra ID synkroniserar inte datorer och datorgrupper. Om dessa fortfarande behövs förblir AD aktivt för enheter, medan Entra ID levererar användare och användargrupper för samma domän. Public Folders och befintliga Shared Mailbox-tilldelningar har ytterligare begränsningar och kontrolleras separat före migreringen.

Bytet börjar med en export- och jämförelselista, inte direkt med att källan ändras. Om användarna i AD och Entra ID matchar uppdaterar Central det befintliga objektet och behåller tillhörande postlådor. Användare som inte matchar kan tas bort tillsammans med sin postlådetilldelning. Nya Entra-användare skapas på nytt. Användargrupper som inte matchar finns kvar men uppdateras inte längre.

Shared Mailboxes och Public Folders kräver särskild uppmärksamhet. Central behåller befintliga AD Shared Mailboxes med senaste AD-datastatus men uppdaterar dem inte längre via AD. Nya Entra Shared Mailboxes kan dessutom visas. Public Folders förblir också i sitt senaste tillstånd. Om den gamla lokala AD-synkroniseringen fortsätter att användas för dessa objekt efter migreringen kan Shared Mailboxes oväntat tas bort på grund av olika objekttyper.

Efteråt kontrolleras användare, grupper, policies, enhetstilldelning, Shared Mailboxes, Public Folders och dubbletter. Om AD förblir aktivt för enheter används där fortfarande Sync devices och Sync organizational units tillsammans.

Förutsättningar och migreringsbeslut

AD och Entra ID måste representera samma domän. Före bytet jämförs användarna med hjälp av unika e-postadresser och andra matchande identitetsattribut, så att Central uppdaterar befintliga konton i stället för att ta bort och skapa dem på nytt. Entra-anslutningen och dess appbehörigheter förbereds fullständigt innan AD-källan stängs av.

Public Folders, datorer och datorgrupper kommer fortfarande endast från AD. För varje domän beslutas därför om Entra ID ensamt räcker eller om AD måste fortsätta köras parallellt för enheter och OU-strukturer. Shared Mailboxes registreras dessutom separat efter AD-, Entra- och Microsoft 365-gruppobjekt.

Använd endast Microsoft Entra ID

Den här vägen passar om Central inte längre behöver uppdatera enheter, enhetsgrupper eller Public Folders från lokalt AD.

1. Kör den sista AD-synkroniseringen och kontrollera användare, grupper, postlådor och fel.
2. Öppna AD-källan under Global Settings > Platform > Directory service och inaktivera den med Turn off.
3. Konfigurera Entra-källan för samma domän med Add Microsoft Entra ID och ge nödvändiga appbehörigheter.
4. Starta Entra-synkroniseringen och kontrollera användare, grupper och Shared Mailboxes mot export- och jämförelselistan.
5. Avinstallera lokal AD Sync Setup Software och återkalla dess API Credentials efter en dokumenterad kontroll först när migreringen har godkänts.

Avstängningen av den gamla källan är en kontrollerad migrering, inte en felsökningsåterställning. Vid oväntade borttagningar fortsätter synkroniseringen inte genom upprepade på- och avslagningar. Matchningsrapporten utvärderas först.

Använd Microsoft Entra ID och AD parallellt

Denna variant använder Entra ID för användare, användargrupper och moderna Shared Mailboxes, medan AD levererar enheter och enhetsgrupper.

1. Kör befintlig AD Sync fullständigt och validera utgångsbeståndet.
2. Begränsa urvalet i AD Sync Utility till Sync devices och Sync organizational units. Användare och användargrupper levereras i fortsättningen inte längre från AD.
3. Inaktivera tillfälligt AD-källan i Central med Turn off.
4. Lägg till Microsoft Entra ID för samma domän, synkronisera och validera användare, grupper och Shared Mailboxes.
5. Aktivera AD-källan igen med Turn on, synkronisera manuellt och kontrollera att enheter och enhetsgrupper fortsätter att uppdateras utan att användare importeras från AD på nytt.

Båda källorna får egna ägare, scheman och acceptansvärden. En grön status för båda anslutningarna bevisar inte att deras objektområden är tydligt separerade.

Konsekvenser för användare, grupper, postlådor och enheter

För matchande användare uppdaterar Entra ID det befintliga Central-objektet och tillhörande postlådeinformation bevaras. En AD-användare utan matchande Entra-post kan tas bort från Central tillsammans med sin postlådetilldelning. Nya Entra-användare skapas som nya Central-användare med tillgängliga postlådedata.

Matchande användargrupper uppdateras. AD-grupper utan motsvarighet i Entra förblir synliga i Central men får inga fler ändringar från AD. Nya Entra-grupper skapas. Grupper som står kvar bevisar inte att synkroniseringen fortfarande fungerar. Policytilldelningar och medlemskap kontrolleras därför separat.

Befintliga Shared Mailboxes och Public Folders som tidigare levererats från AD bevaras med senaste AD-datastatus men uppdateras inte längre. Sådana Shared Mailboxes visas fortfarande under Mailboxes, men kan sakna tilldelade användare efter bytet. Nya Entra Shared Mailboxes kan visas både som användarobjekt och under Mailboxes och även komma utan Delegate-tilldelningen som är känd från AD. Delegerad åtkomst och karantänsammanfattningar valideras därför på nytt. Om den gamla AD-synkroniseringen fortsätter okontrollerat efter migreringen kan olika objekttyper ta bort befintliga Shared Mailboxes.

I Entra-only-modellen finns tidigare AD-enheter och enhetsgrupper först kvar i Central, men de uppdateras inte längre från katalogen. I parallellmodellen fortsätter AD att synkronisera objekten. Entra ID levererar inte datorer, datorgrupper eller Public Folders. Effekten dokumenteras uttryckligen i migreringsbeslutet, så att ett bestånd som står kvar inte felaktigt tolkas som aktuell synkronisering.

Flytta befintliga endpoints till en ny AD-domän

Om endast AD-domänen ändras medan datornamn och SID förblir desamma behöver Sophos-agenten inte installeras på nytt. Dess machine_id bevaras. Först ändras AD Sync-konfigurationen till den nya domänen under Global Settings > Platform > Directory service, inloggningsuppgifterna valideras och användare, grupper, OUs och enheter synkroniseras. Därefter får endpoints checka in till Central.

På grund av det nya FQDN tar Central bort den gamla AD-tilldelningen och söker efter rätt enhetsobjekt i den nya domänen. Vid en träff länkas samma Endpoint-objekt på nytt och flyttas till rätt grupp om OU-synkronisering är aktiv. Användarinloggningar ändras däremot exempelvis från OLDDOMAIN\jsmith till NEWDOMAIN\jsmith och kan skapa dubbletter.

Vid godkännandet kontrolleras ny domän, OU-grupp, tillämpade policies och användartilldelning. Först därefter tas inaktuella enhets-, användar-, grupp- eller Directory-objekt från den gamla domänen bort.

Vanliga felbilder

Användaren visas dubbelt

Jämför källor, e-postadress, UPN och befintliga manuella objekt. Ta inte bort ett av objekten för snabbt så länge enheter eller policies är kopplade till det.

Den nya gruppen saknas

Kontrollera OU- och gruppfilter, kapslade medlemskap, senaste lyckade synkronisering och katalogattribut.

0000208D, NO_OBJECT eller ”The object does not exist”

Felet uppstår normalt när ett Custom Filter fortfarande hänvisar till en OU som har tagits bort från Active Directory. Felmeddelandet anger inte namnet på den raderade OU:n. Under Define Filters jämförs därför alla AD-filter med den aktuella katalogstrukturen och endast hänvisningar till objekt som inte längre finns tas bort. Därefter följer en ny Preview-körning och kontroll av planerade borttagningar.

0xFFFE eller 0xFFFF i Preview and Sync

Om Active Directory innehåller tecken med de ogiltiga hexadecimala värdena 0xFFFE eller 0xFFFF kan den manuella körningen avbrytas vid Preview and Sync. Först identifieras det berörda källattributet och korrigeras i källan. Om detta inte går på kort sikt anger Sophos Sync on Schedule - automatic (within next 2-3 minutes) som en riktad lösning, eftersom körningen hoppar över förhandsgranskningen. Det är ingen permanent rensning. Omfattning, resultat, nya och borttagna objekt kontrolleras omedelbart därefter i Central och loggen.

endpoint_user_sessions.user_match_id när en inloggning tas bort

Error syncing record: Error deleting login tillsammans med en Foreign Key-hänvisning till endpoint_user_sessions.user_match_id kan visas när AD har tagit bort eller inaktiverat en användare, men Central inte kan ta bort tillhörande inloggning på grund av en befintlig session. Den övriga synkroniseringen fortsätter och kan avslutas utan fel. Om posten återkommer dokumenteras användare, inloggning och tidpunkt, och Sophos Support kopplas in för rensning i Central. Purge eller ny konfiguration av hela synkroniseringen är oproportionerligt för detta.

Synkroniseringen förblir inaktuell

Kontrollera Windows-tjänst, tjänstekonto, lösenord, DNS, proxy, brandväggsregler och Centrals synkroniseringsstatus. Synkroniseringsloggar och tidsstämplar ska ingå i ett supportärende.

Sedan AD Sync Client 5.x visar Audit Log vid Directory Sync-åtgärder inte längre Client ID för API Credentials som Modified by, utan GUID för AD Sync-klienten som registrerats hos Sophos. Det gäller Create-, Update- och Delete-åtgärder. Ett GUID är därför inte automatiskt en okänd angripare. Det korreleras med synkroniseringsinstans, schema och loggens tidsstämpel.

LDAP-inloggningsuppgifter efterfrågas hela tiden

NeedADCredsException tillsammans med The LDAP server is unavailable betyder inte nödvändigtvis fel lösenord. Kontrollera Domain Controller, kontoformatet DOMAIN\username, läsrättigheter och vald port. För LDAPS används normalt TCP 636 och Domain Controller måste faktiskt presentera ett betrott certifikat där. En port som lyssnar bevisar inte att TLS-konfigurationen fungerar.

Eskalering till Sophos Support

Ett reproducerbart supportärende innehåller felbeskrivning, klientorganisation och licens, exakt tidsintervall, AD Sync-version, alla loggar, relevanta skärmbilder och den offentliga IP-adressen för synkroniseringssystemet vid insamlingstillfället. Partnerärenden kräver dessutom korrekt tilldelning av MSP-kunden. Remote Assistance aktiveras bara för det konkreta ärendet och efter internt godkännande.

Officiell källa

Aktuell Sophos-vägledning för konfiguration och synkronisering: Set up synchronization with Active Directory.

Vanliga frågor