Microsoft AZ-801: Gerenciamento de Identidade e Acesso para Ambientes Híbridos — Guia de estudos

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Faz parte do Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

O gerenciamento de identidade e acesso em ambientes híbridos depende de um plano de controle consistente entre o Active Directory Domain Services (AD DS) local e o Microsoft Entra ID. Os componentes essenciais são a sincronização de diretórios e o monitoramento de integridade, a identidade de dispositivos e o single sign-on, a federação segura ou a publicação por proxy reverso para aplicativos legados, e a governança just-in-time para funções privilegiadas e usuários externos. Projetos eficazes incorporam o Azure AD Connect (agora Microsoft Entra Connect sync), o Azure AD Connect Health, o Hybrid Azure AD Join com disciplina na solução de problemas, o Seamless SSO, o AD FS quando a federação é necessária, o Azure AD Application Proxy com Kerberos Constrained Delegation para aplicativos locais, políticas de Acesso Condicional (Conditional Access) robustas, o Azure AD Password Protection em controladores de domínio e o Microsoft Entra ID Governance, incluindo PIM e gerenciamento de direitos.

Azure AD Connect e Health na Identidade Híbrida

O Azure AD Connect é o mecanismo de sincronização autoritativo entre o AD DS e o Microsoft Entra ID. Definir o escopo, transformar e gravar atributos corretamente é fundamental.

O writeback de senha estende a redefinição de senha de autoatendimento (SSPR) e a alteração de senha na nuvem de volta para o AD local. Ele exige o Microsoft Entra ID P1/P2, SSPR habilitado no tenant, HTTPS de saída do servidor de sincronização e a conta de serviço de sincronização do Azure AD Connect com as permissões de redefinição adequadas no AD. Quando habilitado, os usuários que redefinem senhas no Entra têm a aplicação imediata no AD DS, com regras que respeitam as políticas de senha do AD.

O writeback de dispositivo cria objetos msDS-Device no AD DS para dispositivos registrados no Entra. Isso oferece suporte ao acesso condicional local no AD FS e a certos cenários de confiança de certificado do Windows Hello for Business. Os requisitos incluem um esquema do Windows Server 2012 R2 ou posterior, direitos de Enterprise Admin para criar o contêiner RegisteredDevices e o Azure AD Connect configurado para apontar para a floresta e a UO corretas. A conta de serviço de sincronização recebe direitos delegados nesse contêiner.

O writeback de grupo sincroniza grupos do Microsoft 365 de volta para o AD DS como grupos habilitados para email para listas de endereços e ACLs locais. O writeback de grupo v2 permite definir o escopo para uma UO específica e preserva a associação com maior fidelidade. Para recursos de email, o Exchange híbrido é recomendado. Os administradores não devem modificar atributos de grupos originados na nuvem localmente; trate o writeback como autoritativo a partir do Entra.

As regras de sincronização determinam o escopo de objetos, as junções e os fluxos de atributos. Use o Synchronization Rules Editor para criar regras personalizadas de entrada ou saída com maior precedência (valor numérico menor) em vez de modificar as regras internas. Defina filtros de escopo (por exemplo, sincronizar apenas usuários com um atributo específico), regras de junção (como objetos da nuvem e locais se correlacionam — a consistência do immutableId/sourceAnchor é fundamental) e transformações (normalizar UPNs, mapear atributos de extensão). Restrinja a sincronização usando filtragem por domínio/UO ou por atributo para minimizar a exposição de dados e reduzir a superfície de erro.

O Azure AD Connect Health fornece monitoramento contínuo para AD DS, AD FS e AAD Connect. Instale os agentes do Health em controladores de domínio, servidores AD FS/WAP e no servidor de sincronização. O portal exibe:

Erros e alertas de sincronização: erros de exportação (ConstraintViolation, ObjectTypeMismatch), eventos de resiliência de atributos duplicados, falhas na sincronização de hash de senha, problemas de sincronização delta e integridade do agendador.
Análise do AD FS: erros de emissão de token, expiração de certificados, atualização de metadados de confiança, latência para relying parties e anomalias como um alto número de bloqueios na extranet.
Análise do AD DS: backlog de replicação, integridade das funções FSMO, falhas de canal seguro e insights sobre a descontinuação do NTLM. Investigue consistentemente os erros na etapa em que ocorrem (importação, sincronização, exportação) usando o Synchronization Service Manager e correlacione-os com os alertas do Connect Health. Use a análise de uso para dimensionar corretamente a infraestrutura e detectar padrões anormais de login ou de emissão de token.

Identidade de Dispositivo e Single Sign-On

O Hybrid Azure AD Join (HAADJ) vincula dispositivos ingressados em domínio ao Entra, permitindo SSO baseado em PRT e Acesso Condicional (Conditional Access) baseado em dispositivo. Os requisitos incluem domínios personalizados verificados no Entra, configuração de SCP no AD (o Azure AD Connect pode configurar isso por floresta), registro de dispositivo habilitado no Entra e acesso de saída para os endpoints de registro de dispositivo. O Windows 10/11 e o Windows Server 2016+ suportam o ingresso híbrido automático quando têm linha de visada para um controlador de domínio ou alcance de rede apropriado. Dispositivos de nível inferior (downlevel) historicamente exigiam AD FS/Workplace Join, mas as implantações modernas padronizam o uso de versões de SO cliente suportadas.

O processo de ingresso depende da descoberta do tenant pelo dispositivo através do SCP na partição de Configuração, contatando os endpoints enterpriseregistration, autenticando-se com a conta da máquina e registrando um objeto de dispositivo no Entra. O registro bem-sucedido resulta em um Primary Refresh Token (PRT), que habilita o SSO para aplicações modernas. Solucione problemas com o dsregcmd:

dsregcmd /status confirma AzureAdJoined = YES e DomainJoined = YES, e exibe o status do PRT, o TenantId e os códigos de erro.
Revise o log de eventos de Registro de Dispositivo do Usuário (Logs de Aplicativos e Serviços) em busca de falhas de DRS e de autenticação.
Valide a sincronização de tempo, as exclusões de proxy para os endpoints de registro de dispositivo, a correção do SCP e se o writeback de dispositivo (se usado) criou o contêiner do AD com as permissões adequadas. Se necessário, dsregcmd /leave limpa o registro para permitir uma nova tentativa de ingresso limpa.

O Azure AD Seamless SSO fornece autenticação integrada do Windows para o Entra sem a necessidade de AD FS. Habilitar o SSO no Azure AD Connect cria a conta de computador AZUREADSSOACC no AD e define os SPNs (HTTP/autologon.microsoftazuread-sso.com). Os controladores de domínio emitem um tíquete de serviço Kerberos para este SPN quando os navegadores acessam o endpoint de autologon; o Entra valida o tíquete usando a chave compartilhada armazenada de forma segura no tenant. Os clientes suportados incluem o Microsoft Edge e o Internet Explorer com os endpoints do Entra na zona de Intranet Local, o Google Chrome através da política de Autenticação Integrada do Windows (Windows Integrated Authentication) e o Firefox com a configuração de negociação (negotiate). Os dispositivos devem estar ingressados no domínio e na rede corporativa (ou conectados via VPN) para apresentar os tíquetes Kerberos; os modos de navegação privada podem desabilitar o WIA. As chaves na conta AZUREADSSOACC são rotacionadas automaticamente; não as redefina manualmente. O Seamless SSO funciona tanto com o Password Hash Sync quanto com a Pass-through Authentication.

Federação, Publicação de Aplicações e Acesso Seguro

O Active Directory Federation Services (AD FS) continua relevante onde as organizações precisam de enriquecimento de claims, autenticação com smartcard ou certificado, ou contratos de federação preexistentes. No AD FS, uma ‘claims provider trust’ representa uma fonte de identidade de entrada (normalmente o Active Directory ou um IdP parceiro). Uma ‘relying party trust’ representa uma aplicação que depende dos tokens do AD FS (por exemplo, o Microsoft 365 em modo federado ou uma aplicação SAML). As regras de emissão de claims (claims issuance rules) transformam atributos de entrada nos tokens esperados pela ‘relying party’; use a linguagem de regras de claims ou os modelos de regras para criar políticas com o mínimo de privilégio. Mantenha os certificados de assinatura de token (token-signing) e de descriptografia de token (token-decrypting) íntegros e automatize a renovação (rollover) sempre que possível. O Web Application Proxy (WAP) publica o AD FS externamente, valida a confiança do proxy do AD FS (AD FS proxy trust) e termina o TLS na borda; monitore a saúde do WAP e garanta que as listas de permissões (whitelists) de endpoints e a renovação de certificados sejam automatizadas.

Para modernizar o acesso a aplicações web on-premises, o Azure AD Application Proxy oferece pré-autenticação na nuvem e se integra com o Acesso Condicional (Conditional Access). Implante conectores em hosts Windows Server ingressados em domínio com acesso HTTPS somente de saída para o serviço. Use grupos de conectores para segmentar aplicações por zona de rede, latência ou residência de dados, e para fornecer isolamento para aplicações de alto risco. Escolha a pré-autenticação com o Azure AD para impor MFA, conformidade de dispositivo, risco de login e associação a grupos antes que o tráfego chegue ao datacenter; a pré-autenticação pass-through deve ser reservada para cenários onde a própria aplicação lida com a autenticação e o Acesso Condicional não é necessário. Para SSO em aplicações com Autenticação Integrada do Windows (Integrated Windows Authentication), configure a Delegação Restrita de Kerberos (Kerberos Constrained Delegation - KCD) na conta de computador do conector para o SPN de destino (HTTP/app-server). O conector obtém um tíquete Kerberos em nome do usuário e o apresenta à aplicação, permitindo um SSO transparente a partir da internet, mantendo a delegação de privilégio mínimo. Valide os SPNs, garanta que o conector consiga alcançar os KDCs e a aplicação de backend, e restrinja a delegação apenas aos serviços necessários.

O Acesso Condicional (Conditional Access) aplica políticas cientes de risco e postura em aplicações na nuvem e publicadas on-premises. Combine sinais como o estado do dispositivo (Exigir que o dispositivo seja marcado como em conformidade) e o estado do diretório (Exigir dispositivo com ingresso híbrido no Azure AD) para controlar o acesso de endpoints gerenciados. Utilize o risco de login do Identity Protection para bloquear ou exigir MFA para logins anômalos. Aplique políticas a aplicações publicadas com o Azure AD Application Proxy usando a pré-autenticação do Azure AD; para aplicações federadas com AD FS, replique a intenção através de regras de claims do AD FS ou migre para a pré-autenticação na nuvem. Exclua contas de emergência (break-glass accounts) e service principals, e teste a política em modo somente relatório (report-only) antes de aplicá-la.

Acesso Privilegiado, Proteção de Senha e Governança

O Azure AD Password Protection elimina credenciais fracas combinando a lista global de senhas proibidas da Microsoft com uma lista personalizada da organização. Implante o serviço de proxy do Azure AD Password Protection em um ou mais servidores membros para intermediar a conectividade do DC com a nuvem e instale o agente de DC em cada controlador de domínio gravável para aplicar a política na definição/alteração de senha. Os agentes buscam a política atual por HTTPS, e a aplicação pode ser executada em modo de auditoria antes de mudar para o modo de imposição. O algoritmo avalia variantes e substituições comuns; monitore os logs de eventos dedicados para rejeições e auditoria. Isso se integra com o writeback de senha do SSPR para que as mesmas regras se apliquem em todos os lugares.

O Privileged Identity Management (PIM) operacionaliza o princípio do menor privilégio por meio de atribuições qualificadas e ativação just-in-time. Atribua funções de alto impacto (Administrador Global, Administrador de Funções com Privilégios, Administrador de Segurança) como qualificadas, não permanentes. Configure requisitos de ativação como MFA, ticket ou justificativa, fluxo de trabalho de aprovação com aprovadores designados, ativação com limite de tempo e, opcionalmente, Azure AD Conditional Access na ativação. O PIM para Grupos estende o acesso JIT à associação/propriedade de grupos de acesso privilegiado, que por sua vez podem ser atribuídos a funções do Azure AD ou ao Azure RBAC. Use revisões de acesso para recertificar a associação a funções e grupos periodicamente, exigindo que os proprietários de recursos atestem ou revoguem o acesso automaticamente quando os usuários estiverem inativos ou mudarem de departamento. Alertas identificam contas com privilégios permanentes, e os logs de auditoria capturam cada ativação e aprovação para conformidade.

O gerenciamento de direitos do Microsoft Entra ID Governance organiza pacotes de acesso que agrupam recursos (grupos, sites do SharePoint e aplicações) com políticas de ciclo de vida e aprovação. Defina quem pode solicitar acesso (usuários internos, departamentos específicos ou usuários externos de organizações conectadas), estabeleça aprovações em múltiplos estágios, exija justificativa de negócios e imponha a expiração com revisões de acesso no final do ciclo de vida. As organizações conectadas modelam domínios de parceiros e provedores de identidade para otimizar o onboarding B2B com termos de uso apropriados e automação do ciclo de vida. Os usuários solicitam acesso pelo portal Meu Acesso e, na expiração, os recursos são removidos automaticamente para minimizar o acesso permanente.

Cenário de Problema Prático

A Siemens AG está migrando aplicações web legadas on-premises para um acesso moderno, mantendo o AD DS e introduzindo o princípio do menor privilégio. Os usuários reclamam de solicitações repetidas de credenciais para o Microsoft 365 e aplicações internas, e os auditores exigem acesso administrativo com limite de tempo e uma higiene de senhas robusta.

Estabelecer identidade híbrida e SSO

Implante o Microsoft Entra Connect sync com Password Hash Sync, habilite o Seamless SSO. Isso reduz as solicitações ao permitir SSO baseado em Kerberos por meio da conta AZUREADSSOACC sem exigir o AD FS. Configure a filtragem de OUs e regras de sincronização personalizadas para definir o escopo apenas para os objetos necessários e normalizar os UPNs.

Habilitar confiança de dispositivo e Conditional Access

Configure o Hybrid Azure AD Join via Azure AD Connect para registrar clientes Windows ingressados no domínio. Isso fornece sinais baseados em dispositivo para o Conditional Access. Valide o registro com dsregcmd /status e corrija configurações incorretas de SCP ou proxy apresentadas no log de Registro de Dispositivo do Usuário.

Publicar aplicações on-premises de forma segura

Implante conectores do Azure AD Application Proxy em dois datacenters e coloque as aplicações em grupos de conectores por localidade. Use a pré-autenticação do Azure AD para que o Conditional Access aplique o hybrid-join ou a conformidade e o MFA na borda. Configure KCD nas contas de máquina do conector para aplicações IWA, restringindo a delegação a SPNs específicos para alcançar SSO pela internet com o menor privilégio.

Fortalecer as senhas de ponta a ponta

Instale o serviço de proxy do Azure AD Password Protection em servidores membros redundantes e o agente de DC em todos os controladores de domínio graváveis. Habilite o modo de imposição com uma lista de senhas proibidas personalizada refletindo termos específicos da Siemens. Isso garante a rejeição consistente de senhas fracas tanto on-premises quanto via SSPR com writeback de senha.

Modernizar o acesso privilegiado

Implemente o PIM com atribuições qualificadas para Administrador Global, Administrador de Funções com Privilégios e funções críticas do Azure RBAC. Exija MFA, justificativa e aprovação de um estágio, com janelas de ativação de 4 horas. Configure revisões de acesso trimestrais para todas as funções privilegiadas e grupos de acesso privilegiado, removendo automaticamente atribuições inativas ou não aprovadas.

Monitorar e operar

Instale agentes do Azure AD Connect Health no servidor de sincronização, AD FS/WAP (se ainda usado para parceiros específicos) e controladores de domínio. Use alertas de saúde para rastrear erros de sincronização, status da sincronização de hash de senha, saúde da replicação do AD DS e anomalias na emissão de tokens do AD FS. Aproveite a análise de uso para dimensionar corretamente a capacidade do conector e detectar picos anormais.

Essa abordagem elimina a federação desnecessária, centraliza as políticas com o Conditional Access e usa KCD para modernizar o acesso a aplicações legadas. O Seamless SSO e o HAADJ removem as solicitações de senha, o Password Protection impõe credenciais fortes na origem, e o PIM mais as revisões de acesso entregam um acesso administrativo auditável e just-in-time, alinhado ao princípio do menor privilégio.

← Recuperação de Desastres e Continuidade de Negócios · Todos os domínios

Pratique estas questões → · Prática cronometrada no ExamRoll.io →