Link para a parte 1- https://cloudinsane.com.br/index.php/2023/09/06/migracao-do-adfs-para-o-entra-id-parte-1/
Após a coleta dos dados é importante a validação se as aplicações são suportadas dentro do Entra ID. Existem inúmeras aplicações que são suportadas e, já estão no catálogo do Entra ID, grande parte também suporta o Single sign-on. É possível encontrar algumas aplicações no site da Microsoft:
https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/tutorial-list
Caso o aplicativo não esteja no Marketplace da Microsoft, é possível também registrar um aplicativo no Entra ID. O Aplicativo deve dar suporte ao OAuth 2.0.
Regras de Acesso Active Directory Federation Services
Com o ADFS existe a possibilidade de configurar as regras de claim. As regras de claim são basicamente regras para bloqueio para aumentar a segurança dos aplicativos configurados no ADFS. Algumas regras são:
Acessar o aplicativo por determinado IP;
Determinado Grupo pode acessar o aplicativo;
Bloqueio de determinado protocolo (mais voltada para Exchange Online).
Existem inúmeras possibilidades para criação de regras de claim dentro do ADFS.
Após algum tempo a Microsoft lançou o Azure AD Premium, que possibilita configurar regras de acesso condicional. Algo semelhante ao que é feito com as regras de claim do ADFS.
Com as regras de acesso condicional temos uma granularidade maior de configurações, e existe a facilidade comparado as configurações que temos que fazer no ADFS para que as regras de claim funcionem.
O ponto negativo, é que para ter as regras de acesso condicional é necessário ter o licenciamento do Entra ID P1 para cada usuário, o que pode gerar um problema na questão de custo para os clientes.
Migração do Active Federation Services para Entra ID
Após abordarmos as configurações necessárias, podemos então efetuar a migração do ADFS para o Entra ID (Azure AD).
Para ambiente que possuem o ADFS federado com o Office 365 é necessário, caso não tenha feito. Configurar a sincronização de senha, onde temos duas possibilidades o hash de senha ou, utilizar a autenticação de passagem (PTA).
É recomendado também ativar o SSO contínuo.
Feito as configurações mencionadas acima, é necessário habilitar a feauture chamada staged rollout no Entra ID:
Após habilitar o staged rollout temos algumas opções antes de incluir o grupo de segurança criado diretamente no Entra ID. Estas opções devem ir de encontro com a configuração de senha efetuada anteriormente.
A migração em si é bem simples, ela é feita baseada em grupos de segurança do Entra ID. A Microsoft recomenda que os grupos ou o grupo seja criado diretamente no Entra ID para evitar o tempo de replicação entre uma alteração ou outra no AAD Connect.
O primeiro grupo criado possibilita somente 200 usuários, após a replicação do Entra ID é possível adicionar mais usuários ao grupo.
Cada grupo inserido permite 200 usuários iniciais, isto é um limite da feauture, e neste momento não é possível fazer alterações.
Após a replicação e, todos os usuários utilizando o Entra ID como login e não mais o ADFS, é possível remover a federação do domínio entre o ADFS e o Entra ID.
Considerações Finais
O ADFS cumpriu bem o seu papel até o lançamento do Azure AD Premium (nome do produto na época), porém hoje em dia é mais difícil ter o ADFS implantado nas empresas. Porém, existem alguns fatores que fazem com que o ADFS ainda esteja em uso, como:
Aplicações legadas que são suportadas no ADFS e, não no Entra ID;
Custo.
O Entra ID em questão de segurança de fato é melhor que o ADFS, porém alguns clientes por questão de custo optam pelo ADFS, pois não é necessário licenciar por usuário. O que pode acabar ficando caro em alguns casos.
Caso o cliente tenha possibilidade de adquirir o licenciamento necessário (Entra ID P1 ao menos), o recomendado é não ter o ADFS. Onde o cliente também deixa de gerenciar 4 máquinas ou mais dependendo do tamanho do ambiente.
