Azure AD vs AD vs Azure Domain Services

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 é super comum, infelizmente.

A ideia desse pequeno artigo é clarear sua visão em relação a o que é o Azure AD e qual serviço mais se assemelha ao que se tem localmente. E não, o Azure AD não é a mesma coisa que o AD.

Comecemos pelo começo!

Active Directory Domain and Services

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 Azure AD. Parece mas não é simplesmente uma cópia em nuvem do super conhecido e amado AD. O Azure AD foi desenhado para a nuvem e por isso atua de forma diferente do que seu irmão local.

O 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 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 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 Azure AD usando um serviço chamado de AD Connect. Esse serviço permite que você leve sua base do AD completa para o 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:

1. Ter VMs com o AD instalado e uma VPN conectando o ambiente local a nuvem ($)
2. 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 ($$$)

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
Users
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 Azure AD Connect to sync identities to the cloud. Azure AD adds support to automatically create users from cloud HR systems. 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)	Azure AD provides a special class of identity to support external identities. 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 Azure AD and administrators can also use groups to grant permissions to resources. In 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 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.	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.	Azure AD uses intelligent password protection for cloud and on-premises. Protection includes smart lockout plus blocking common and custom password phrases and substitutions. Azure AD significantly boosts security through Multi-factor authentication and passwordless technologies, like FIDO2. 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, 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.	Azure AD can provide access to these types of on-premises apps using Azure AD application proxy agents running on-premises. Using this method 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 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 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.	Azure AD provides managed identities to run other workloads in the cloud. The lifecycle of these identities is managed by 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 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 Azure AD. Conditional access can check if a device is 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 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 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 Azure AD, do começo até configurações de segurança mais bacanas de brincar!

 

Um grande abraço! \,,/