Sincronizar o Active Directory com o Sophos Central

O Sophos Central pode importar utilizadores e grupos de um Active Directory local. Estas identidades são utilizadas, entre outros fins, para atribuir Policies e dispositivos. No entanto, uma sincronização sem controlo pode criar contas desnecessárias, objetos duplicados ou eliminações inesperadas.

O Microsoft Entra ID é sincronizado através de um connector próprio. O procedimento encontra-se em Sincronizar o Microsoft Entra ID com o Sophos Central.

Definir o modelo de origens antes da instalação

O Central pode gerir até 25 origens de diretório por tenant. Para mais origens, está prevista uma estrutura Central Enterprise. Os utilizadores e endereços de e-mail têm de ser únicos num tenant Central. O mesmo domínio não pode fornecer utilizadores simultaneamente através de várias origens AD, Entra ID ou Google Directory.

Num Trial, a Sophos limita adicionalmente o número de Directory Objects que podem ser criados ou utilizados, incluindo utilizadores, dispositivos e grupos. Por isso, uma importação de teste incompleta não é automaticamente um erro de filtragem. Antes de um piloto, verificam-se em conjunto o âmbito do Trial, o número esperado de objetos e o estado da licença.

É possível selecionar várias Child Domains numa Forest; um tenant também pode sincronizar várias Forests. Ainda assim, a Sophos recomenda associar cada Forest apenas a um tenant Central. Se a mesma Forest for importada para vários tenants, ou se várias Forests contiverem os mesmos utilizadores ou endereços de e-mail, as execuções atualizam alternadamente as mesmas identidades aparentes. O Central não unifica estes registos, pelo que os nomes, atributos e associações a grupos podem tornar-se inconsistentes.

Em contrapartida, é útil uma combinação suportada: o AD sincroniza computadores e grupos de computadores, enquanto o Entra ID fornece utilizadores e grupos de utilizadores do mesmo domínio. As Shared Mailboxes num grupo Microsoft 365 requerem Entra ID ou Google Directory. Uma Shared Mailbox normal fora de um grupo Microsoft 365 pode ser importada através de AD Sync.

As Shared Mailboxes e Public Folders do mesmo domínio dos utilizadores requerem o AD Sync Utility juntamente com Sync users and user groups. As caixas de correio de grupos Microsoft 365 não são importadas por AD Sync. Uma Shared Mailbox sem Delegate também não é sincronizada. Se permanecer uma caixa de correio de utilizador inativa com delegação para uma caixa ativa, o AD Sync não a elimina e pode mantê-la no Central como Shared Mailbox.

Para o mesmo domínio ou subdomínio, só é executado um cliente AD Sync em produção. Além disso, vários dispositivos AD não podem ter o mesmo DNS Hostname, porque o Central não consegue fazer uma correspondência inequívoca. Ao mudar de servidor, interrompe-se por isso a agenda antiga antes de a nova instância sincronizar em produção.

Se o Self Service Portal for utilizado para Sophos Email, Device Encryption ou Mobile, o acesso dos utilizadores é ativado antes do primeiro Directory Sync. Deste modo, os utilizadores novos e existentes recebem o convite previsto. O procedimento encontra-se em Configurar o acesso ao Sophos Central Self Service Portal.

Limites do AD Sync e grupos entre domínios

O AD Sync não reúne dados de várias Forests ou Directory Services num registo principal. Por isso, o mesmo utilizador ou endereço de e-mail não pode existir em mais de uma Forest sincronizada. Utilizadores, endereços de e-mail ou grupos duplicados podem ser atualizados alternadamente em cada execução com os dados da respetiva origem e até mudar o Directory Owner visível no Central. Os utilizadores e endereços de e-mail permanecem únicos por tenant; os utilizadores do mesmo domínio não podem ser sincronizados simultaneamente a partir de AD e Entra ID nem fornecidos em paralelo a várias Central Admin Accounts.

Num grupo com membros de vários domínios, o Central só importa utilizadores do domínio ao qual o grupo pertence. Embora Preview and Sync possa mostrar todos os membros, os utilizadores do outro domínio não são adicionados ao grupo durante a sincronização em produção. Este comportamento é testado em Universal Groups e Child Domains com um membro de teste por domínio.

Os utilizadores e grupos de utilizadores são sincronizados ou desativados em conjunto. O mesmo se aplica aos dispositivos e grupos de dispositivos. Estão previstos, no máximo, 1'000 filtros por Directory Object; os filtros LDAP adicionais podem ter, no máximo, 5'000 caracteres. Não são suportados componentes de domínio com mais de 63 caracteres ou com - ou _ no início ou no fim.

As caixas de correio de grupos Microsoft 365 requerem Entra ID. O AD Sync não importa Shared Mailboxes sem Delegate, vários clientes AD Sync em produção para o mesmo domínio ou subdomínio, nem vários dispositivos AD com o mesmo DNS Hostname. Em contrapartida, uma caixa de correio inativa com delegação para uma caixa ativa pode ser mantida como Shared Mailbox. Estes limites são tratados como decisões de arquitetura antes da primeira execução, e não contornados posteriormente com filtros mais abrangentes.

Limpar objetos AD inativos antes da sincronização

Sempre que possível, as contas de utilizador e os dispositivos inativos são verificados e removidos ou desativados diretamente no Active Directory. Não só aumentam o inventário no Central, como continuam a representar um risco de segurança na origem. A limpeza também reduz o ficheiro de sincronização transferido para o Sophos Central e pode acelerar a execução.

Os filtros LDAP podem impedir que utilizadores inativos cheguem ao Central e também reduzir o ficheiro de sincronização. Contudo, não corrigem o risco de uma conta AD inativa que continua a existir. Por isso, o processo operacional combina um período de inatividade justificável, a aprovação do Owner, a limpeza na origem e uma execução Preview subsequente. Antes de remover uma conta de computador, os dispositivos são verificados separadamente quanto à idade, último contacto com o domínio e estado de proteção.

Gerir Directory Sources no Central

A vista central encontra-se em Global Settings > Platform > Directory service. É necessária uma função Central Admin adequada para configurar e gerir uma origem. Consoante a origem pretendida, a página disponibiliza Add Active Directory, Add Microsoft Entra ID e Add directory service for Google. Para o AD local, descarrega-se aqui o Setup Software atual; o Entra ID e o Google são autorizados através dos respetivos conectores Cloud.

A lista de origens apresenta, por entrada, o nome, tipo, domínio, agenda e estado. Os avisos ou erros são verificados não só nesta vista, mas também em Alerts and Reports > Logs > General Logs > Events. Um estado verde da origem não é suficiente se a última execução estiver desatualizada ou se o número esperado de objetos não corresponder.

Um clique no nome abre os detalhes. No AD, verificam-se especialmente o número de utilizadores, grupos, dispositivos, grupos de dispositivos, Public Folders e Shared Mailboxes, bem como Hostname, versão do cliente, domínio, estado e data e hora da última sincronização. No Entra ID e Google, são prioritários os números de utilizadores e grupos, o estado, a última execução e a agenda. Após a configuração inicial e qualquer alteração de filtro ou origem, estes valores são comparados com um conjunto de referência conhecido.

Consoante o tipo de origem, também é possível alterar aí a configuração e os filtros, efetuar Purge dos dados sincronizados e eliminar a origem. São intervenções diferentes: Purge remove os dados de diretório importados dessa origem, enquanto Delete remove adicionalmente a Directory Source. No AD, interrompem-se antes as opções de sincronização e os clientes em execução; no Entra ID e Google, utilizam-se os respetivos diálogos de Filter, Purge e Delete. Antes de qualquer variante, exportam-se os utilizadores, grupos, dispositivos, Policies e caixas de correio afetados e leem-se as consequências anunciadas no Central. Um Purge ou Delete não é um teste de ligação sem consequências e não é confirmado sem um plano de reversão.

O nome e a descrição de uma origem só podem ser alterados depois de esta ser desativada com Turn off. Depois de guardar, volta a ser ativada com Turn on e é verificada. A desativação interrompe as atualizações, pelo que não é efetuada durante uma alteração de diretório não verificada. Depois de a sincronização de uma origem ter sido ativada em produção, este passo não pode ser simplesmente anulado. Para uma execução manual, abre-se a origem e seleciona-se Synchronize; em seguida, verificam-se o estado, a data e hora e as alterações aos objetos.

Planear Self Service e Shared Mailboxes antes da sincronização

Se um utilizador precisar do Self Service Portal, ativa-se User Access antes do primeiro Directory Sync. Assim, o Central pode enviar os convites no processo previsto. Ativar o acesso mais tarde não corrige automaticamente todos os envios anteriormente falhados; por isso, os utilizadores piloto, a entrega de e-mail e o acesso ao portal são testados antes da importação alargada.

As Shared Mailboxes não possuem necessariamente atributos completos de utilizador no Central. Os utilizadores delegados recebem acesso Self Service à Shared Mailbox que lhes foi atribuída e, consoante o produto licenciado, veem aí, por exemplo, Emergency Inbox e Quarantine Summary. Um Delegate pode assim receber resumos para a própria caixa e adicionalmente para a Shared Mailbox. Por isso, as delegações e os endereços de entrega são testados na prática após a sincronização, não sendo aprovados apenas com base no número de objetos.

Uma Shared Mailbox num grupo Microsoft 365 não pode ser sincronizada através do AD local; para isso utiliza-se Microsoft Entra ID ou Google Directory. Uma Shared Mailbox normal fora de um grupo Microsoft 365 pode ser importada por AD Sync. Antes de uma migração posterior para o Entra ID, inventaria-se o tipo de objeto de origem de cada caixa de correio. Caso contrário, uma sincronização AD que continue após a mudança de origem pode remover caixas de correio ou deixá-las com dados desatualizados.

Antes da primeira sincronização

Primeiro, define-se qual diretório é a origem principal de cada conjunto de utilizadores e grupos. As mesmas pessoas não devem ser criadas simultaneamente de forma manual, a partir do AD e a partir do Entra ID.

Para a primeira execução, recomenda-se uma pequena OU de teste com utilizadores e grupos representativos. Verificam-se:

• endereços de e-mail e User Principal Names,
• grupos aninhados e memberships,
• contas desativadas ou obsoletas,
• contas de serviço e técnicas,
• conflitos de nomes com objetos Central existentes.

Cada utilizador a sincronizar necessita de um endereço de e-mail inequívoco. Muitos processos do Central utilizam-no como identidade e destino de entrega; no Sophos Email, uma mensagem para um endereço sem utilizador associado pode mesmo não ser entregue. Além disso, a Firewall ou o Proxy têm de conseguir aceder aos domínios e portas documentados para o Central. Um teste LDAP bem-sucedido, por si só, não confirma este caminho Cloud.

Instalar o AD Sync Utility

O software de sincronização atual é descarregado diretamente do Sophos Central e instalado num sistema Windows permanentemente disponível. O sistema necessita de acesso de rede ao Domain Controller e aos serviços Sophos necessários.

O Active Directory Synchronization Setup Software atual funciona apenas num sistema Windows de 64 bits e requer .NET Framework 4.6.2. A Sophos indica Windows 7, 8.1, 10 e 11, bem como Windows Server 2008 R2, 2012, 2012 R2, 2016, 2019, 2022 e 2025. Como Domain Controller, a Sophos indica Windows Server 2008 R2 a 2025. Esta compatibilidade do fabricante não substitui o ciclo de vida da Microsoft: numa nova instalação em produção, utiliza-se um sistema operativo de servidor atualmente suportado e atualizado, não Windows 7 nem um Windows Server descontinuado.

Para o acesso ao Central são utilizadas API Credentials com a função Service Principal Active Directory Sync, não credenciais genéricas de Super Admin.

A conta de serviço AD recebe apenas os direitos necessários para ler as Forests e os objetos de diretório selecionados. A expiração da palavra-passe, o arranque do serviço e a responsabilidade são documentados. Uma conta de administrador pessoal não é adequada.

O Utility não consegue processar um domínio se um componente individual do respetivo nome tiver mais de 63 caracteres ou começar ou terminar com - ou _. Este limite é verificado antes da instalação, pois um nome a apresentar abreviado ou outro UPN não corrige um nome de domínio AD inválido.

A Sophos testou até 30'000 objetos AD. Acima de 40'000 registos de utilizador, a interface pode responder mais lentamente. Ambientes maiores exigem, por isso, filtros particularmente rigorosos e testes com tempos de execução realistas.

Em cada execução de sincronização, o Utility verifica se está disponível uma versão mais recente e, normalmente, efetua automaticamente as atualizações subsequentes. As primeiras versões do AD Sync já não suportam a autenticação atual do Central e podem falhar totalmente se esta atualização automática não funcionar. Nesse caso, descarrega-se o Installer atual em Global Settings > Platform > Directory service e executa-se sobre a instalação existente. Em seguida, criam-se novas API Credentials com a função Service Principal Active Directory Sync, que são introduzidas no Utility como Client ID e Client Secret. Cada instância de sincronização em produção recebe uma identidade técnica rastreável, uma responsabilidade documentada e a sua própria rotação de Secrets.

No arranque, o Client ID e o Client Secret são verificados com Validate credentials. Se o Utility tiver de comunicar através de um Proxy, ativa-se Configure proxy manually e introduz-se o endereço do Proxy. Se o Proxy exigir autenticação, adicionam-se Enable proxy authentication, o utilizador e a palavra-passe do Proxy. Só um segundo teste de credenciais bem-sucedido confirma que funcionam não apenas os dados da API, mas também o caminho através do Proxy.

Este ecrã de Proxy pertence ao Active Directory Synchronization Setup 4.0. Em alternativa, um Trial Tenant pode ainda receber o antigo Sophos Central AD Sync Utility 3.5.4; nesse caso, não é possível introduzir dados de Proxy na interface. Por predefinição, o serviço é executado como Local Service e, com um Proxy que exige autenticação, falha frequentemente com Failed active directory synchronization, uma System.Net.Http.HttpRequestException e CommandLib.HttpRequestCommand+HttpStatusException. Uma conta de serviço alternativa utilizada para esse fim requer Log on as a service, início de sessão interativo e Batch, direitos de leitura nas OUs afetadas e Full Control sobre C:\ProgramData\Sophos\Sophos Cloud AD Sync. Após cada mudança desta conta de serviço, o Utility antigo é reconfigurado. Sempre que possível, utiliza-se o software 4.0 atual em ambientes de produção.

Para o acesso LDAP, utiliza-se uma conta com direitos de leitura para toda a Forest selecionada. Sempre que possível, Use LDAP over an SSL connection permanece ativado. O LDAPS utiliza normalmente TCP 636 e o LDAP sem encriptação TCP 389. Devido a LDAP Signing e Channel Binding, a porta 389 não é uma alternativa fiável em ambientes Active Directory atuais. Para LDAPS, o Domain Controller necessita de um certificado válido e considerado fidedigno pelo sistema de sincronização.

Se estiver comprovado que o ambiente LDAP concreto não suporta SSL, pode desativar-se Use Secure LDAP e mudar a porta para o serviço LDAP sem encriptação. Trata-se de um fallback documentado, não de uma Best Practice. As credenciais e os dados de diretório deixam então de estar protegidos por TLS durante o transporte; por isso, a segmentação, o caminho de rede e a migração atempada para LDAPS são tratados como um risco.

O que o Utility espera na Forest

Para uma Forest completa, o AD Sync lê na raiz da árvore de diretório rootDomainNamingContext, com o Distinguished Name do domínio raiz da Forest, e defaultNamingContext, com o Distinguished Name do servidor utilizado. Em CN=Partitions,CN=Configuration,<rootDomainNamingContext>, o Utility espera, para os Naming Contexts relevantes, entradas com netBiosName, dnsRoot e nCName. O valor de nCName determina os espaços de pesquisa adicionais, desde que não seja um Distinguished Name superior ao do servidor indicado no ecrã de configuração.

Se faltar um destes atributos ou se a conta de serviço não puder ler a Configuration Partition, um teste de início de sessão pode funcionar, enquanto a deteção da Forest ou a sincronização posterior falha. Nesse caso, os valores são verificados com LDP.exe utilizando a mesma conta de serviço antes de alterar filtros ou objetos do Central.

Filtrar OUs e objetos

Os filtros limitam o âmbito da sincronização. São incluídos apenas OUs, utilizadores e grupos efetivamente necessários no Sophos Central. Uma importação ampla a partir da raiz raramente é adequada.

Antes da importação, a pré-visualização mostra quais objetos seriam adicionados, alterados ou removidos. As eliminações, em particular, não são confirmadas sem verificação. A vista Preview ou Pending Changes pode não apresentar corretamente caracteres UTF-16 ou Double-Byte e mostrar, por exemplo, ???. Os dados são, ainda assim, transmitidos ao Sophos Central e aí apresentados. Por isso, os nomes, por exemplo em chinês, japonês ou coreano, são verificados adicionalmente no Active Directory e no Central após uma sincronização piloto controlada.

A Sophos classifica este problema da Preview como uma limitação que deverá ser corrigida numa versão futura do AD Sync Utility. Até a versão utilizada corrigir comprovadamente o problema, continua a ser necessário verificar os dados no diretório de origem e após a sincronização.

Base DN e LDAP filter têm funções diferentes. Base DN limita a pesquisa às OUs selecionadas; a pertença a uma OU não se expressa de forma fiável apenas com um filtro LDAP normal. LDAP filter restringe atributos ou associações a grupos dentro desse espaço de pesquisa. Ambos os filtros são mantidos separadamente por Domain, porque os Child Domains não herdam as definições do Parent Domain; os filtros de utilizadores e grupos também são independentes.

No separador AD Filters, Search Bases e LDAP Query Filters são introduzidas separadamente por domínio e, quando necessário, para utilizadores e grupos. Uma Search Base para uma OU Finance pode ser:

OU=Finance,DC=myCompany,DC=com

Um filtro para membros de um grupo pode ser:

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

Sem filtro de grupos adicional, o Central continua a detetar todos os grupos aos quais esses utilizadores pertencem. Para limitar também os grupos, adiciona-se, por exemplo, CN=testGroup. Uma alteração ao filtro pode retirar do âmbito utilizadores ou grupos anteriormente sincronizados e eliminá-los no Central; por isso, segue-se sempre uma pré-visualização completa.

A Sophos utiliza como ponto de partida:

Benutzer: (&(objectCategory=person)(objectClass=user)(!sAMAccountType=805306370)(!userAccountControl:1.2.840.113556.1.4.803:=2))
Gruppen:  (&(objectCategory=group)(objectClass=group))

O filtro inclui pessoas user, exclui computadores através de sAMAccountType=805306370 e contas desativadas através do bit userAccountControl. Os filtros adicionais são combinados com estas condições de base separadamente por domínio e testados primeiro com LDP.exe.

A Sophos limita a configuração a 1.000 filtros por objeto de diretório e a 5.000 carateres por filtro LDAP adicional. Os utilizadores só podem ser sincronizados juntamente com os grupos de utilizadores, e os dispositivos juntamente com os grupos de dispositivos. Nos grupos entre domínios, a pré-visualização mostra todos os membros, mas o Central só importa utilizadores do domínio ao qual o grupo pertence. Estes grupos devem, por isso, ser testados explicitamente antes da sincronização em produção.

O resultado esperado é verificado com Microsoft LDP.exe: Search Base do AD Sync corresponde a Base DN e a expressão LDAP a Filter. Assim distingue-se se a Sophos omite o objeto ou se a consulta ao diretório já não o devolve. Algumas comparações podem ser case-sensitive.

Os filtros com lastLogon ou lastLogonTimestamp são utilizados com cuidado. lastLogon é geralmente mais atual, mas não é replicado entre Domain Controllers; para obter um valor fiável, seria necessário consultar todos os Domain Controllers. lastLogonTimestamp é replicado, mas pode estar desatualizado. A Sophos recomenda remover as contas e os dispositivos inativos na origem, em vez de depender apenas de um filtro temporal.

Se lastLogonTimestamp for, ainda assim, utilizado como filtro transitório, define-se primeiro uma data de referência em UTC e converte-se essa data para Windows FILETIME com um conversor LDAP/Active Directory FILETIME fidedigno. A data de exemplo da Sophos, 1 de dezembro de 2020 às 00:01, corresponde a 132581431640000000. Em Active Directory Synchronization Setup > AD Filters, introduz-se no campo Custom Filters a expressão LDAP adicional:

(lastLogonTimestamp>=132581431640000000)

O valor de exemplo não é reutilizado sem alterações. A data de referência própria é escolhida conscientemente, convertida corretamente e documentada juntamente com o fuso horário e a autorização da alteração. Em seguida, realizam-se Preview and Sync, uma verificação dos utilizadores incluídos e excluídos e, só depois, a aprovação da execução em produção.

O AD Sync cria apenas grupos com mais de um membro. Um grupo vazio ou com exatamente um membro não aparece, por isso, como objeto Central esperado. Utilizadores ou endereços de e-mail duplicados em várias Forests não são consolidados; a origem de um objeto pode, assim, mudar entre execuções. Sempre que possível, uma Forest é sincronizada apenas com um tenant Central.

Exclude disabled user accounts está ativado por predefinição. Para sincronizar Shared Mailboxes, esta opção tem de permanecer ativada. Se for desativada, o Central pode criar objetos de caixa de correio duplicados para Shared Mailboxes. Independentemente disso, as contas de utilizador normais desativadas devem ser limpas na origem e não reintroduzidas através de uma sincronização mais ampla.

Os seletores de tipos de dados têm dependências concretas:

• Sync users and user groups sincroniza ambos em conjunto e inclui também Shared Mailboxes normais. Se o seletor for desativado, não é possível sincronizar Shared Mailboxes nem Public Folders através desta origem AD.
• Sync public folders requer adicionalmente Sync users and user groups, porque os Public Folders são tratados como objetos de caixa de correio.
• No funcionamento normal, Sync devices e Sync organizational units são ativados em conjunto para os dispositivos. Na configuração inicial, podem importar-se primeiro apenas as OUs para que as Policies estejam preparadas antes dos dispositivos.
• Se posteriormente apenas Sync organizational units for desativado, os dispositivos permanecem ativos, mas as OUs existentes aparecem como Custom Groups. Se apenas a sincronização das OUs permanecer ativa, os dispositivos deixam de ser atribuídos aos grupos do Central.

Sem grupos OU preparados, os dispositivos sincronizados de novo recebem inicialmente as Default Policies. Por isso, depois do piloto das OUs, ativam-se em conjunto ambos os seletores de dispositivos e verificam-se a atribuição e a Policy efetivamente aplicada.

Para grupos muito grandes, também importa o atributo AD member. A partir de 1.500 entradas, Active Directory usa Range Retrieval como member;range=0-1499 e esvazia o member simples. Um grupo com mais de 1.500 objetos antes do primeiro Sync pode faltar no Central ou mostrar contagem errada. Sempre que possível limita-se a menos de 1.500 utilizadores e verifica-se com LDP.exe.

Correspondência de utilizadores e aliases de e-mail

O Central faz corresponder utilizadores AD através do Domain Login DOMAIN\user ou do atributo mail. O nome provém de Display name e os aliases de proxyAddresses. Uma correspondência transforma o objeto Central existente num objeto gerido pelo diretório; sem correspondência é criado um novo utilizador. Preview and Sync apresenta-os em Users to Modify e Users to Add.

Um objeto sincronizado a partir de outro Directory Service não é criado como um segundo utilizador novo quando existe uma correspondência, mas pode receber um endereço de e-mail adicional do AD. Um utilizador criado manualmente e um utilizador AD com o mesmo nome podem, por sua vez, permanecer como dois objetos separados se o Login e o e-mail não corresponderem. O nome a apresentar, por si só, não é uma chave de correspondência.

Em Preview and Sync, as correspondências em Users to Modify e as novas identidades em Users to Add são verificadas individualmente. Uma associação incorreta é rejeitada, em vez de se aceitar toda a proposta com Approve Changes and Continue. A conversão de um utilizador manual num objeto gerido pelo AD também é identificada pelo ícone de diretório.

Se um utilizador for removido no AD, o comportamento do Central depende das respetivas dependências. Os administradores e os utilizadores com um dispositivo ou Login associado permanecem como utilizadores normais do Central. Um utilizador sem dispositivo, Login ou função privilegiada pode, por sua vez, ser removido automaticamente. Pela mesma razão de proteção, as alterações do endereço de e-mail de um administrador do Central não são importadas cegamente a partir do AD. Por isso, as funções administrativas e as associações a dispositivos são verificadas separadamente antes do Offboarding.

Se for necessário alterar o endereço de e-mail principal de um administrador gerido pelo diretório ou eliminar o respetivo objeto Central que permaneceu após a remoção no AD, a função administrativa é retirada de forma controlada antes da sincronização seguinte. Depois da sincronização, a função necessária pode voltar a ser atribuída. Este procedimento mantém sempre um segundo Super Admin funcional como via de recuperação.

Nome incorreto devido a Logins sobrepostos

Se o utilizador A possuir inadvertidamente também o Login do utilizador B, o AD Sync pode primeiro atribuir ambos os Logins a A e, ao processar B mais tarde, mudar o nome do registo existente para B. Em Logins do utilizador afetado, removem-se todas as associações pertencentes a outros utilizadores e volta a sincronizar-se. O nome não deve ser simplesmente corrigido enquanto o Login errado continuar associado.

Não é possível atribuir uma função a um utilizador AD

Em My Environment > Users & Groups > Users, pesquisa-se o e-mail. Nos duplicados, documentam-se os Logins, removem-se dos objetos incorretos com Edit logins e adicionam-se ao correto. Só depois se guarda a função e verifica o envio do Setup. Se o e-mail continuar bloqueado no tenant, o conflito é resolvido pelo suporte sem novas eliminações.

Interpretar corretamente grupos aninhados

A página pode mostrar o grupo AD direto e grupos superiores como linked groups. Isso não implica associação direta a todos. Verificam-se separadamente a associação AD direta, o aninhamento e a Policy Central efetivamente aplicada.

Associar o Login de Mac ao utilizador sincronizado

O AD Sync importa NETBIOSDOMAIN\user, enquanto um Mac comunica frequentemente MACNAME\user, podendo criar um segundo objeto. Depois de verificar os dispositivos, este objeto é limpo e MACNAME\user é associado ao utilizador AD. Numa implementação maior, testa-se o Domain Override da Sophos em vez de correções manuais.

Sincronizar computadores e grupos OU

A deteção de dispositivos suporta computadores e servidores Windows. A Sophos associa um dispositivo protegido ao objeto AD através de FQDN e Hostname e move-o para o grupo OU sincronizado. Um computador anteriormente agrupado manualmente pode regressar à estrutura AD na sincronização seguinte.

É criado um novo objeto de dispositivo ou grupo quando o Central não conhece a mesma AD-ObjectGUID. Se o nome de um novo grupo AD colidir com um grupo existente, o Central utiliza o Distinguished Name. Vários registos AD com o mesmo DN não são suportados.

Na correspondência, FQDN e Hostname têm de coincidir. Se existir um dispositivo Central com domínio e Hostname, mas detalhes guardados divergentes, a sincronização atualiza essas informações e move o dispositivo para o grupo AD adequado. Se existirem dois dispositivos com o mesmo FQDN, o objeto anteriormente associado é desligado e o novo registo é associado. Por isso, os Hostnames duplicados são limpos antes da sincronização, em vez de a nova associação resultante ser interpretada como uma perda aleatória do dispositivo.

As OUs são sincronizadas antes dos dispositivos, permitindo preparar primeiro as Policies nos grupos previstos. Os dispositivos e grupos sincronizados não podem ser reorganizados permanentemente no Central contra a estrutura AD. Uma hierarquia com mais de 40 níveis é consolidada a partir do nível 40.

Os dispositivos e grupos sincronizados podem ser movidos ou eliminados no Central, mas não editados como objetos locais. Estas alterações não são permanentes: a sincronização seguinte restaura a estrutura ou recria o objeto. Se um dispositivo protegido for eliminado no AD, o Central move-o para um grupo não estruturado e remove a marca de gestão AD. Alterações de nomes, sistema operativo ou estrutura OU também são importadas, incluindo movimentos e remoções de grupos.

As Policies de grupos manuais mantêm-se. Contudo, os dispositivos AD são movidos para o grupo sincronizado e recebem inicialmente Default Policies se não tiver sido atribuída antes uma Policy adequada. Uma Policy num Top-Level Group é herdada por grupos aninhados sem atribuição própria. Por isso, sincronizam-se primeiro as OUs, atribuem-se Policies e só depois os dispositivos.

A Sophos não disponibiliza atualmente uma API para Directory Devices e Device Groups sincronizados pelo AD. As automações não podem assumir que conseguem gerir esta estrutura integralmente como grupos Central normais.

Em My Environment > Unmanaged devices, os computadores e servidores conhecidos do AD aparecem em vistas separadas sem Sophos Agent. Os pacotes de proteção necessários estão disponíveis em My Environment > Installers. Esta vista de inventário não instala proteção; cada dispositivo esperado permanece no processo de Rollout ou de exceção até o Agent ser instalado ou uma exceção documentada ser aprovada.

Agenda e monitorização

A agenda de sincronização tem de corresponder à frequência de alterações da empresa. Após cada execução, verificam-se o estado, os erros e as alterações aos objetos. Um serviço iniciado com êxito não comprova que todos os objetos foram sincronizados corretamente.

Os avisos sobre credenciais, ligação, atributos em falta ou conflitos de objetos são resolvidos rapidamente. A operação necessita de um owner e de um substituto.

Na primeira execução e após cada alteração de filtro, inicia-se manualmente Preview and Sync, verificam-se objetos novos, alterados e a eliminar e só depois confirma-se com Approve Changes and Continue. Uma execução manual pode demorar até 15 minutos. Para execuções exclusivamente manuais, seleciona-se Never. Only sync when manually initiated.

Os Runtime Logs encontram-se em:

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

Fazem rotação em sete ficheiros diários. Um log necessário é copiado ou renomeado antes da próxima rotação. Um Medium Email Alert contém frequentemente apenas o resumo; procura-se a causa concreta no log do mesmo período.

Ao substituir o servidor AD Sync, nunca se executa uma segunda instância sem controlo. Interrompe-se a agenda no servidor antigo, configura-se o Utility atual no novo servidor, compara-se a configuração de filtros e testa-se com Preview and Sync. Só após uma execução manual bem-sucedida se ativa a nova agenda e remove a instalação antiga.

Eliminar e reconstruir

Se um objeto for removido do diretório de origem ou do filtro, o objeto Central correspondente e a respetiva atribuição de Policies podem ser afetados. Antes de uma alteração em massa, leem-se e documentam-se as ações anunciadas na interface.

Eliminar a configuração de sincronização ou os dados sincronizados não é um passo normal de Troubleshooting. Primeiro, verificam-se a associação de dispositivos, memberships e possíveis duplicados. Uma reconstrução sem análise pode recriar os mesmos problemas.

Antes de Purge data, todas as instâncias AD Sync em execução ou copiadas são interrompidas e os filtros são controlados; caso contrário, os dados reaparecem. O Purge é irreversível. Os dispositivos geridos, os utilizadores associados e os administradores não são removidos, mesmo que tenham origem no AD.

Efetuar Purge dos dados AD sincronizados

O procedimento executável começa em Global Settings > Platform > Directory service. Abre-se o nome da origem AD, interrompe-se a origem com Turn off e seleciona-se Purge data. No diálogo, seleciona-se conscientemente o conjunto de dados a remover:

• Users and user groups remove adicionalmente as Shared Mailboxes e os Public Folders sincronizados.
• Devices and device groups remove os dispositivos e grupos sincronizados, com exceção dos objetos protegidos indicados pela Sophos.

Depois de confirmar a irreversibilidade, seleciona-se novamente Purge data. O Central elimina o conjunto selecionado e não volta a sincronizar esse tipo de dados a partir da origem interrompida. Se todos os dados AD tiverem sido removidos, os utilizadores, dispositivos e grupos passam a ter de ser geridos manualmente ou através de uma nova origem claramente delimitada. O Microsoft Entra ID pode, por exemplo, assumir a gestão dos utilizadores e grupos de utilizadores.

Antes do Purge, procuram-se e interrompem-se todas as cópias do AD Sync Utility e as respetivas agendas. Os filtros, por si só, não impedem o reaparecimento dos dados se uma segunda instância continuar a sincronizar. Depois, verificam-se os administradores que permanecem, bem como os dispositivos geridos e os utilizadores que lhes estão associados, porque o Central não elimina estas exceções.

Mudar do AD para o Microsoft Entra ID

A Sophos suporta a mudança da sincronização de utilizadores e grupos de um domínio do AD para o Entra ID. Antes disso, têm de existir origens AD e Entra adequadas para o mesmo domínio e os utilizadores de ambas as origens têm de corresponder de forma fiável. Utilizadores AD sem correspondência podem ser removidos do Central durante a mudança.

O Entra ID não sincroniza computadores nem grupos de computadores. Se continuarem a ser necessários, o AD permanece ativo para os dispositivos, enquanto o Entra ID fornece utilizadores e grupos de utilizadores do mesmo domínio. Public Folders e associações existentes de Shared Mailboxes têm outras limitações que devem ser verificadas separadamente antes da migração.

A mudança começa com uma exportação e uma lista comparativa, e não diretamente com a alteração da origem. Se os utilizadores do AD e do Entra ID corresponderem, o Central atualiza o objeto existente e mantém as caixas de correio associadas. Os utilizadores sem correspondência podem ser removidos juntamente com a associação à caixa de correio; os novos utilizadores Entra são criados de novo. Os grupos de utilizadores sem correspondência permanecem, mas deixam de ser atualizados.

As Shared Mailboxes e os Public Folders requerem especial atenção. O Central mantém as Shared Mailboxes anteriormente fornecidas pelo AD com o último estado dos dados AD, mas deixa de as atualizar através do AD. Podem aparecer adicionalmente novas Shared Mailboxes do Entra. Os Public Folders também permanecem no último estado. Se, após a migração, a antiga sincronização do AD On-Premises continuar a ser utilizada para estes objetos, as Shared Mailboxes podem ser removidas inesperadamente devido aos diferentes tipos de objeto.

Depois, verificam-se os utilizadores, grupos, Policies, associações de dispositivos, Shared Mailboxes, Public Folders e duplicados. Se o AD permanecer ativo para os dispositivos, Sync devices e Sync organizational units continuam a ser utilizados em conjunto.

Pré-requisitos e decisão de migração

O AD e o Entra ID têm de representar o mesmo domínio. Antes da mudança, os utilizadores são comparados através de endereços de e-mail inequívocos e outras características de identidade correspondentes, para que o Central atualize as contas existentes em vez de as eliminar e voltar a criar. O conector Entra e as respetivas permissões da aplicação são totalmente preparados antes de a origem AD ser desativada.

Os Public Folders, os computadores e os grupos de computadores continuam a provir exclusivamente do AD. Por isso, decide-se para cada domínio se o Entra ID é suficiente ou se o AD tem de continuar a funcionar em paralelo para os dispositivos e as estruturas OU. As Shared Mailboxes são adicionalmente inventariadas em separado como objetos AD, Entra ou de grupos Microsoft 365.

Utilizar apenas o Microsoft Entra ID

Este método é adequado quando o Central já não precisa de atualizar dispositivos, grupos de dispositivos nem Public Folders a partir do AD local.

1. Executar a última sincronização AD e verificar os utilizadores, grupos, caixas de correio e erros.
2. Em Global Settings > Platform > Directory service, abrir a origem AD e desativá-la com Turn off.
3. Configurar com Add Microsoft Entra ID a origem Entra para o mesmo domínio e conceder as permissões da aplicação exigidas.
4. Iniciar a sincronização Entra e comparar os utilizadores, grupos e Shared Mailboxes com a lista de exportação e comparação.
5. Só depois da aprovação, desinstalar o AD Sync Setup Software local e revogar as respetivas API Credentials após uma verificação documentada.

A desativação da origem antiga é uma migração controlada, e não um Troubleshooting Reset. Em caso de eliminações inesperadas, não se continua a sincronizar através da ativação e desativação repetida das origens; primeiro, analisa-se o relatório de Matching.

Utilizar Microsoft Entra ID e AD em paralelo

Esta variante utiliza o Entra ID para utilizadores, grupos de utilizadores e Shared Mailboxes modernas, enquanto o AD fornece os dispositivos e grupos de dispositivos.

1. Executar completamente a sincronização AD existente e validar o inventário inicial.
2. No AD Sync Utility, limitar a seleção a Sync devices e Sync organizational units; os utilizadores e grupos de utilizadores deixam de ser fornecidos pelo AD.
3. Desativar temporariamente a origem AD no Central com Turn off.
4. Adicionar o Microsoft Entra ID para o mesmo domínio, sincronizar e validar os utilizadores, grupos e Shared Mailboxes.
5. Voltar a ativar a origem AD com Turn on, sincronizar manualmente e verificar que os dispositivos e grupos de dispositivos continuam a ser atualizados sem voltar a importar utilizadores a partir do AD.

Ambas as origens recebem os seus próprios Owners, agendas e critérios de aceitação. Um estado verde nos dois conectores não comprova que os respetivos conjuntos de objetos estejam claramente separados.

Efeitos em utilizadores, grupos, caixas de correio e dispositivos

No caso de utilizadores correspondentes, o Entra ID atualiza o objeto Central existente; as informações das caixas de correio associadas permanecem. Um utilizador AD sem um registo Entra correspondente pode ser removido do Central juntamente com a respetiva associação à caixa de correio. Os novos utilizadores Entra são criados como novos utilizadores Central com os dados de caixa de correio disponíveis.

Os grupos de utilizadores correspondentes são atualizados. Os grupos AD sem um equivalente Entra permanecem visíveis no Central, mas deixam de receber alterações do AD. São criados novos grupos Entra. Estes grupos que ficam para trás não comprovam que a sincronização continue a funcionar; por isso, as atribuições de Policies e as memberships são verificadas separadamente.

As Shared Mailboxes e os Public Folders existentes, anteriormente fornecidos pelo AD, permanecem com o último estado dos dados AD, mas deixam de ser atualizados. Estas Shared Mailboxes continuam a aparecer em Mailboxes, mas podem deixar de ter utilizadores associados após a mudança. As novas Shared Mailboxes do Entra podem aparecer tanto como objetos de utilizador como em Mailboxes e também chegar sem a atribuição de Delegates conhecida do AD. Por isso, os acessos delegados e os Quarantine Summaries são novamente validados. Se a antiga sincronização AD continuar a funcionar sem controlo depois da migração, os diferentes tipos de objeto podem remover Shared Mailboxes existentes.

No modelo Entra-only, os dispositivos e grupos de dispositivos AD existentes permanecem inicialmente no Central, mas deixam de ser atualizados a partir do diretório. No modelo paralelo, o AD continua a sincronizar estes objetos. O próprio Entra ID não fornece computadores, grupos de computadores nem Public Folders. Este efeito é documentado expressamente na decisão de migração, para que um inventário que permaneça no Central não seja incorretamente interpretado como uma sincronização atual.

Transferir Endpoints existentes para um novo domínio AD

Se apenas o domínio AD mudar, mantendo-se iguais o nome do computador e o SID, o Sophos Agent não precisa de ser reinstalado. A respetiva machine_id mantém-se. Primeiro, em Global Settings > Platform > Directory service, a configuração do AD Sync é alterada para o novo domínio, as Credentials são validadas e os utilizadores, grupos, OUs e dispositivos são sincronizados. Só depois os Endpoints devem efetuar Check-in no Central.

Devido ao novo FQDN, o Central desfaz a associação AD anterior e procura o objeto de dispositivo adequado no novo domínio. Quando existe uma correspondência, o mesmo objeto Endpoint é novamente associado e, se a sincronização de OUs estiver ativa, movido para o grupo correto. Os Logins dos utilizadores mudam, por sua vez, por exemplo, de OLDDOMAIN\jsmith para NEWDOMAIN\jsmith e podem criar duplicados.

A validação verifica o novo domínio, o grupo OU, as Policies aplicadas e a associação dos utilizadores. Só depois são removidos os objetos de dispositivos, utilizadores, grupos ou diretório desatualizados do domínio antigo.

Problemas frequentes

O utilizador aparece duas vezes

Comparar origens, endereço de e-mail, UPN e objetos manuais existentes. Não eliminar precipitadamente um dos objetos enquanto houver dispositivos ou Policies associados.

Falta um grupo novo

Verificar filtros de OU e grupo, memberships aninhadas, a última sincronização bem-sucedida e os atributos do diretório.

0000208D, NO_OBJECT ou «The object does not exist»

Este erro ocorre normalmente quando um Custom Filter ainda aponta para uma OU que entretanto foi removida do Active Directory. A mensagem de erro não indica o nome da OU eliminada. Por isso, em Define Filters, todos os filtros AD são comparados com a estrutura atual do diretório e removem-se apenas as referências a objetos que deixaram de existir. Em seguida, realizam-se uma nova execução Preview e a verificação das eliminações planeadas.

0xFFFE ou 0xFFFF em Preview and Sync

Se o Active Directory contiver caracteres com os valores hexadecimais inválidos 0xFFFE ou 0xFFFF, a execução manual pode ser interrompida em Preview and Sync. Primeiro, identifica-se o atributo de origem afetado e corrige-se o valor na origem. Se isto não for possível a curto prazo, a Sophos indica Sync on Schedule - automatic (within next 2-3 minutes) como workaround específico, porque esta execução ignora a Preview. Esta opção não constitui uma correção permanente: o âmbito, o resultado e os objetos novos e removidos são verificados imediatamente a seguir no Central e no Log.

endpoint_user_sessions.user_match_id ao eliminar um Login

Error syncing record: Error deleting login, juntamente com uma indicação de Foreign Key para endpoint_user_sessions.user_match_id, pode aparecer quando o AD removeu ou desativou um utilizador, mas o Central não consegue eliminar o Login correspondente devido a uma sessão existente. O restante processo de sincronização continua e pode terminar com êxito. Se a entrada se repetir, documentam-se o utilizador, o Login e a data e hora e solicita-se ao Sophos Support que efetue a limpeza no Central; um Purge ou uma reconstrução de toda a sincronização seria desproporcionado para este erro.

A sincronização permanece desatualizada

Verificar o Windows Service, a conta de serviço, a palavra-passe, DNS, Proxy, regras de Firewall e o estado Central Sync. Um ticket de suporte deve incluir Sync Logs e timestamps.

Desde o AD Sync Client 5.x, o Audit Log deixou de apresentar o Client ID das API Credentials como Modified by nas ações de Directory Sync, passando a mostrar a GUID do cliente AD Sync registado na Sophos. Isto aplica-se às ações Create, Update e Delete. Por isso, uma GUID não é automaticamente um atacante desconhecido; deve ser correlacionada com a instância de sincronização, a agenda e a data e hora do Log.

As credenciais LDAP são pedidas repetidamente

NeedADCredsException, juntamente com The LDAP server is unavailable, não significa necessariamente que a palavra-passe esteja errada. Verificam-se o Domain Controller, o formato da conta DOMAIN\username, as permissões de leitura e a porta selecionada. Para LDAPS, está normalmente prevista a porta TCP 636 e o Domain Controller tem de apresentar efetivamente nessa porta um certificado fidedigno. O facto de uma porta estar a escutar, por si só, não comprova que a configuração TLS funcione.

Escalar para Sophos Support

Um caso de suporte reproduzível inclui a descrição do erro, o Tenant e a licença, o período exato, a versão do AD Sync, todos os Logs, as capturas de ecrã relevantes e o endereço IP público do sistema de sincronização no momento da recolha. Os casos de Partner necessitam adicionalmente da atribuição correta do cliente MSP. A Remote Assistance só é ativada para o caso concreto e após aprovação interna.

Perguntas frequentes