Azure AD (Entra ID) vs ADDS
Entra ID AzureAD Azure AD Identidade em Nuvem ADDS
Faala galera, 100%?!
Eu tenho certeza que você já ouviu algum colega de trabalho, “consultores” e até mesmo “experts” falando a seguinte frase: “Você pode migrar seu AD para o Azure e pronto, terá tudo que tem localmente, na Nuvem…super simples”. Esse tipo de afirmação ainda é super comum, infelizmente.
A ideia desse pequeno artigo é clarear sua visão em relação a o que é o Entra ID (Azure AD) e qual serviço mais se assemelha ao que se tem localmente. E não, o Entra ID (Azure AD) não é a mesma coisa que o AD.
Comecemos pelo começo!
Active Directory Domain and Services (ADDS)
Esse cara é um dos meus recursos preferidos no Windows Server. Ele entrega uma capacidade de gerenciamento incrível e é pre requisito na maioria dos ambientes que gerencio e implanto. Com o AD (para os íntimos) deixamos de lado a ideia de gerenciamento descentralizado e passamos a ter, literalmente, um diretório para consulta e gestão de usuários, computadores, grupos, unidades organizacionais e demais objetos dentro do domínio.
O domínio é uma estrutura lógica que, como o nome sugere, passa a aplicar políticas a todos os objetos que nele são ingressados. Além desses detalhes nós temos as famosas GPOs (Group Policy Objects) que nos possibilitam inúmeras configurações e automatizações.
Indo um pouco mais a fundo no serviço, o AD é uma centralizador para autenticação e autorização dentro do ambiente que foi implantado. Para isso utiliza protocolos como NTLM e Kerberus, além do LDAP para queries e modificações dos objetos do AD. Em sua base de dados temos informação de todos esses objetos.
Azure Active Directory
Para os íntimos apenas Entra ID (Azure AD). Parece mas não é simplesmente uma cópia em nuvem do super conhecido e amado AD. O Entra ID (Azure AD) foi desenhado para a nuvem e por isso atua de forma diferente do que seu irmão local.
O Entra ID (Azure AD) é um serviço de gerenciamento de identidade para o Azure. Nele podemos ter serviços que vão do Single sign-on (SSO) para aplicação Microsoft e de terceiros, até práticas de segurança como Acesso Condicional. Existem algumas edições do serviço, cada uma delas com capacidades distintas. Obviamente quanto mais recursos maior será o investimento dispendido. Mas calma, existe a edição Free que permite utilização de até 500,000 objetos, 10 aplicações com SSO, Self-Service Password Reset e outras funções.
Diferentemente do AD Local (vamos chamar assim pra facilitar) o Entra ID (Azure AD) trabalha com protocolos de comunicação baseado em HTTP e HTTPS como SAML, OpenID e OAuth. Ao invés de utilizar LDAP para query passamos a utilizar REST APIs. OUs e GPOs, acredite, não existem aqui. Assim como não existe ingressar estações no domínio. O que temos são configurações de Registro ou Join no Entra ID (Azure AD) para sistema modernos, que vão possibilitar um gerenciamento um pouco mais apurado desses devices, mas nada comparado ao Join realizado localmente.
E a tal migração?
O que acontece, na verdade é uma replicação de usuários e grupos do AD Local para o Entra ID (Azure AD) usando um serviço chamado de AD Connect. Esse serviço permite que você leve sua base do AD completa para o Entra ID (Azure AD) para fins de integração com o O365, por exemplo ou utilização em serviços como autenticação de Azure File Share.
E é nesse ponto que muitos se confundem e acham que o simples fato de utilizar o AD Connect já garante tolerância a falha do AD Local
E se eu quiser ter redundância do AD em nuvem ou ter o AD de fato em Nuvem?
Temos dois cenários aqui. a parte da replicação em cloud a melhor solução vai variar entre ambientes mas a melhor escolha do ponto de vista $$ é ter uma VM no Azure e conectar o ambiente local a nuvem com um gateway VPN. O AD não é um serviço que exige muito recurso e em geral uma VM da família B atenderia perfeitamente essa demanda.
Para aqueles desejam ter o AD Local rodando na cloud, são 2 opções:
- Ter VMs com o AD instalado e uma VPN conectando o ambiente local a nuvem ($)
- Utilizar o serviço de AD como plataforma, o AADDS (Azure Active Directory Domain Services). Esse cara te entregará um domínio, como você conhece mas sem a necessidade de ter uma VM rodando para isso. O lance é que aqui as coisas são um pouco mais…salgadas ($$$)
Entra ID (Azure AD) vs AD Local
Pra deixar as coisa um pouco mais claras e facilitar a análise das principais diferenças e similaridades entre os dois serviços, vou deixar uma tabela disponibilizada pela Microsoft.
| Concept | Active Directory (AD) | Azure Active Directory |
|---|---|---|
| Provisioning: users | Organizations create internal users manually or use an in-house or automated provisioning system, such as the Microsoft Identity Manager, to integrate with an HR system. | Existing AD organizations use Entra ID (Azure AD) Connect to sync identities to the cloud. Entra ID (Azure AD) adds support to automatically create users from cloud HR systems. Entra ID (Azure AD) can provision identities in SCIM enabled SaaS apps to automatically provide apps with the necessary details to allow access for users. |
| Provisioning: external identities | Organizations create external users manually as regular users in a dedicated external AD forest, resulting in administration overhead to manage the lifecycle of external identities (guest users) | Entra ID (Azure AD) provides a special class of identity to support external identities. Entra ID (Azure AD) B2B will manage the link to the external user identity to make sure they are valid. |
| Entitlement management and groups | Administrators make users members of groups. App and resource owners then give groups access to apps or resources. | Groups are also available in Entra ID (Azure AD) and administrators can also use groups to grant permissions to resources. In Entra ID (Azure AD), administrators can assign membership to groups manually or use a query to dynamically include users to a group. Administrators can use Entitlement management in Entra ID (Azure AD) to give users access to a collection of apps and resources using workflows and, if necessary, time-based criteria. |
| Admin management | Organizations will use a combination of domains, organizational units, and groups in AD to delegate administrative rights to manage the directory and resources it controls. | Entra ID (Azure AD) provides built-in roles with its role-based access control (RBAC) system, with limited support for creating custom roles to delegate privileged access to the identity system, the apps, and resources it controls. Managing roles can be enhanced with Privileged Identity Management (PIM) to provide just-in-time, time-restricted, or workflow-based access to privileged roles. |
| Credential management | Credentials in Active Directory is based on passwords, certificate authentication, and smartcard authentication. Passwords are managed using password policies that are based on password length, expiry, and complexity. | Entra ID (Azure AD) uses intelligent password protection for cloud and on-premises. Protection includes smart lockout plus blocking common and custom password phrases and substitutions. Entra ID (Azure AD) significantly boosts security through Multi-factor authentication and passwordless technologies, like FIDO2. Entra ID (Azure AD) reduces support costs by providing users a self-service password reset system. |
| Apps | ||
| Infrastructure apps | Active Directory forms the basis for many infrastructure on-premises components, for example, DNS, DHCP, IPSec, WiFi, NPS, and VPN access | In a new cloud world, Entra ID (Azure AD), is the new control plane for accessing apps versus relying on networking controls. When users authenticate, Conditional access (CA), will control which users, will have access to which apps under required conditions. |
| Traditional and legacy apps | Most on-premises apps use LDAP, Windows-Integrated Authentication (NTLM and Kerberos), or Header-based authentication to control access to users. | Entra ID (Azure AD) can provide access to these types of on-premises apps using Entra ID (Azure AD) application proxy agents running on-premises. Using this method Entra ID (Azure AD) can authenticate Active Directory users on-premises using Kerberos while you migrate or need to coexist with legacy apps. |
| SaaS apps | Active Directory doesn’t support SaaS apps natively and requires federation system, such as AD FS. | SaaS apps supporting OAuth2, SAML, and WS-* authentication can be integrated to use Entra ID (Azure AD) for authentication. |
| Line of business (LOB) apps with modern authentication | Organizations can use AD FS with Active Directory to support LOB apps requiring modern authentication. | LOB apps requiring modern authentication can be configured to use Entra ID (Azure AD) for authentication. |
| Mid-tier/Daemon services | Services running in on-premises environments normally use AD service accounts or group Managed Service Accounts (gMSA) to run. These apps will then inherit the permissions of the service account. | Entra ID (Azure AD) provides managed identities to run other workloads in the cloud. The lifecycle of these identities is managed by Entra ID (Azure AD) and is tied to the resource provider can’t be used for other purposes to gain backdoor access. |
| Devices | ||
| Mobile | Active Directory doesn’t natively support mobile devices without third-party solutions. | Microsoft’s mobile device management solution, Microsoft Intune, is integrated with Entra ID (Azure AD). Microsoft Intune provides device state information to the identity system to evaluate during authentication. |
| Windows desktops | Active Directory provides the ability to domain join Windows devices to manage them using Group Policy, System Center Configuration Manager, or other third-party solutions. | Windows devices can be joined to Entra ID (Azure AD). Conditional access can check if a device is Entra ID (Azure AD) joined as part of the authentication process. Windows devices can also be managed with Microsoft Intune. In this case, conditional access, will consider whether a device is compliant (for example, up-to-date security patches and virus signatures) before allowing access to the apps. |
| Windows servers | Active Directory provides strong management capabilities for on-premises Windows servers using Group Policy or other management solutions. | Windows servers virtual machines in Azure can be managed with Entra ID (Azure AD) Domain Services. Managed identities can be used when VMs need access to the identity system directory or resources. |
| Linux/Unix workloads | Active Directory doesn’t natively support non-Windows without third-party solutions, although Linux machines can be configured to authenticate with Active Directory as a Kerberos realm. | Linux/Unix VMs can use managed identities to access the identity system or resources. Some organizations, migrate these workloads to cloud container technologies, which can also use managed identities. |
Conclusão
O grande lance aqui é entender de fato o que o ambiente pede. Antes de qualquer tipo de sugestão ou alteração no ambiente é mais do que recomendado estudar o que cada serviço entrega e quais limitações possuem. Imagine prometer migrar o AD local para o Entra ID (Azure AD) e depois do projeto aprovado descobrir que as 317 GPOs do seu ambiente local não vão existir mais…complexo.
Espero que o artigo tenha te ajudado. Trarei mais conteúdo específico sobre Entra ID (Azure AD), do começo até configurações de segurança mais bacanas de brincar!
Um grande abraço! \,,/
