Saltar para o conteudo
Avanet

Ligar Microsoft AD FS ao Sophos Central

O Microsoft AD FS pode autenticar identidades Active Directory existentes para o Sophos Central. O fluxo é iniciado pelo SP: o Sophos Central fornece Entity ID e Callback URL, e o AD FS processa o login como Claims-Aware Relying Party Trust.

O AD FS aumenta a responsabilidade de operação própria em comparação com o Entra ID ou um serviço OIDC gerido. Os certificados, Metadata, acessibilidade externa, alta disponibilidade e nível de atualização do Federation Service continuam a ser da responsabilidade da organização.

Pré-requisitos

São necessários direitos de Super Admin no Central, um serviço AD FS operacional, a aprovação do responsável pelo AD e um domínio verificado. Os administradores e utilizadores do Central têm de existir no AD Forest utilizado; os respetivos endereços de e-mail têm de corresponder aos endereços guardados no Central.

Antes de ativar Federated credentials only como opção de login, todos os administradores e utilizadores afetados têm de estar associados a um domínio verificado e a um Identity Provider funcional. Caso contrário, a alteração bloqueia estas contas. Por isso, uma conta Sophos Break Glass independente e um piloto bem-sucedido fazem parte dos pré-requisitos, e não apenas do Troubleshooting posterior.

A AD FS Metadata URL, os certificados do Federation Service e a resolução externa de nomes são verificados antes da alteração no Central. A Sophos apresenta como formato de Metadata https://login.microsoftonline.com/<TenantDomainName>/FederationMetadata/2007-06/FederationMetadata.xml; no entanto, num serviço AD FS próprio clássico, utiliza-se a FederationMetadata URL efetivamente publicada pelo próprio serviço. Um exemplo do Microsoft Online não é aplicado sem verificação a um AD FS On-Premises.

Preparar o domínio e o Provider no Central

Em Global Settings > Access Control > Sign-in and Identity > Sophos sign-in > Verify domains, verifica-se o domínio através de um DNS TXT Record. A propagação pode demorar até 24 horas e a verificação é válida durante um ano.

Em seguida:

  1. Abrir Federated identity providers e criar um novo Provider.
  2. Introduzir um nome sem caracteres especiais problemáticos e uma descrição.
  3. Selecionar Type: Microsoft AD FS e o Vendor adequado.
  4. Introduzir a AD FS metadata URL verificada.
  5. Selecionar o domínio verificado.
  6. Definir se o AD FS aplica a MFA ou se o Central solicita a sua própria MFA após um login bem-sucedido no AD FS.
  7. Guardar e copiar do Provider a Entity ID e a Callback URL geradas pelo Central.

O Provider ainda não é ativado em todo o Tenant como o único método de login.

Criar o Relying Party Trust no AD FS

No servidor AD FS, inicia-se o assistente Add Relying Party Trust através de Server Manager > Tools > AD FS Management:

  1. Selecionar Claims Aware.
  2. Utilizar Enter data about the relying party manually.
  3. Introduzir um Display Name inequívoco.
  4. Selecionar AD FS profile; no passo dos certificados, continuar sem requisitos adicionais de encriptação.
  5. Em Configure URL, ativar Enable support for the WS-Federation Passive protocol.
  6. Introduzir a Callback URL copiada do Central como WS-Federation Passive Protocol URL.
  7. Em Configure Identifiers, adicionar a Entity ID copiada do Central como Relying Party Trust Identifier.
  8. Configurar a MFA de acordo com o design próprio de AD FS e Conditional Access.
  9. Para o piloto, autorizar apenas os utilizadores necessários. A Sophos apresenta Permit all users to access this relying party como método padrão; um grupo piloto controlado é mais seguro.
  10. Concluir o Trust e abrir diretamente o diálogo Edit Claim Rules.

Emitir os Claims corretamente

Em Issuance Transform Rules > Add rule, seleciona-se Send LDAP Attributes as Claims. Utiliza-se Active Directory como Attribute Store. A associação é a seguinte:

LDAP AttributeOutgoing Claim Type
E-mail-AddressesName ID
Given-NameGiven Name
SurnameSurname
E-mail-AddressesE-mail Address

O valor de e-mail é a associação decisiva ao Central. Os endereços vazios, duplicados ou divergentes são corrigidos antes do Rollout. Um login bem-sucedido no AD FS sem um e-mail Claim correspondente continua a não conduzir de forma fiável à conta Central correta.

Ativar e testar o Provider

Depois de criar o AD FS Trust, ativa-se o Provider no Central com Turn on. Em Sophos sign-in, mantém-se inicialmente a escolha entre as credenciais Sophos e o login federado.

O teste é iniciado na página de login da Sophos e inclui:

  • um administrador normal,
  • um Super Admin,
  • AD FS MFA ou Central MFA,
  • um utilizador sem autorização no Trust,
  • logout e novo login,
  • expiração ou substituição do AD FS Signing Certificate,
  • uma conta Break Glass independente com Sophos Login.

Só depois se ativa Federated credentials only. Nesse momento, todas as contas afetadas têm de estar associadas a um domínio verificado e ao Provider ativo.

Troubleshooting

  • Metadata URL inacessível: verificar DNS, certificado, TLS, Web Application Proxy e Federation Service.
  • Relying Party Identifier inválido: copiar exatamente a Entity ID do Central e verificar se existem espaços invisíveis.
  • Erro de Callback: comparar a WS-Federation Passive URL com a Callback URL atual do Central.
  • O AD FS aceita o utilizador, mas o Central não: verificar os Claims de e-mail e Name ID, bem como o e-mail no Central.
  • MFA em falta ou duplicada: controlar em conjunto as regras do AD FS e a seleção IdP enforced MFA.
  • Provider afetado após a substituição do certificado: atualizar Metadata, Signing Certificate e a relação de confiança no Central e repetir o piloto.

O processo geral para Sign-in Rules, MFA Recovery e a mudança controlada para Federated credentials only é descrito em Proteger o acesso ao Sophos Central com MFA, Passkeys e IdP.

Perguntas frequentes

Pode utilizar-se o mesmo AD FS Trust sem Claims?

Não. O Central necessita, em particular, de uma identidade de e-mail consistente. O Trust é configurado como Claims-Aware e fornece Name ID, nome próprio, apelido e endereço de e-mail conforme documentado.

Deve utilizar-se Permit all users?

Para um primeiro Rollout seguro, é preferível um grupo piloto limitado. A autorização só é alargada ao grupo de utilizadores pretendido depois de se confirmar que os Claims, a MFA e o acesso de fallback funcionam.