Agosto tem sido de deep dive no LCW. Além das tarefas built-in, surgiram alguns casos de uso mais customizados que precisam de Custom Task Extension (CTE) chamando um LogicApp. Para que isso ocorra, o LA precisa de algo chamado Azure Active Directory Proof of Possession (AADPOP) e esse é o objetivo do post rapido de hoje, comentar contigo sobre esse processo.

Esse artigo será bem rapido e direto ao ponto, e espero que te ajude a não perder algumas horas durante o setup, como aconteceu comigo.

O que é por que preciso do POP

Como já falamos nesse artigo aqui sobre LCW , quando as tasks built-in não são suficientes, podemos utilizar as CTEs para chamar um LogicApp e executar tarefas que são suportadas por um LogicApp (o que é muita coisa). Pra que esse link ocorra, o LCW precisa ser capaz de iniciar (trigger) o LogicApp e pra isso, uma autorização é necessária, aqui que entra o POP.

Lá no LogicApp, temos um campo “Authorization” e lá você definirá os criterios que uma requisição enviando um POST ao LA deve ter para que ela seja aceita e inicie-o. Como eu prometi que seria um artigo rápido, pedi a meu colega Claudinho que gerasse um fluxo com base na minha explicação e temos o fluxo abaixo.

A configuração

A documentação nos ajuda bastante nesse processo, mas, falha em um detalhe que simplesmente impede que sua CTE funcione. Vamos ao pre-requisitos;

• Teu LA DEVE ser Consumption. É a primeira opção durante o provisionamento do recurso

• Teu LA DEVE TER uma Managed Identity System Assigned. UAMI não funciona, é mandatório ser System Assigned
• A blade de Authorization deve ter o POP configurado

Caso você não tenha esses pontos configurados, teu LA não aparecerá na seleção durante a configuração da CTE.

Lá no LogicApp, o que você precisa fazer é o seguinte:

1. Ative a Managed Identity System Assigned, navegando até Settings > Identity > e virando a chave para “On”
2. No mesmo menu Settings, clique em Authorization, crie uma nova policy e preencha seguindo o modelo abaixo;
   1. Policy Name: AzureADLifecycleWorkflowsAuthPOPAuthPolicy
   2. OAuth Type: Clique e selecione AADPOP
   3. Na sessão de Claims, 2 ja são padrão (Issuer e Audience), para adicionar os demais, clique em “+ Add Custom Claim”

Atenção, para o appid, a documentação entrega um AppID que não funciona. O correto é o que vou deixar na tabela abaixo.

Você também pode conferir essa informação no seu Tenant, buscando por “Lifecycle Workflows” em Enterprise App do seu Entra ID. Copie o Application ID.

Claim	Valor
Issuer	https://sts.windows.net/(Tenant ID)/ Não retire a “/” no final. Copie seu Tenant ID no menu Overview do Entra ID.
Audience	https://management.azure.com
appid	ce79fdc4-cd1d-4ea5-8139-e74d7dbe0bb7 Tudo em minúsculas. Este é o valor correto — não o que está na documentação.
m	POST
u	management.azure.com
p	/subscriptions/(subscriptionId)/resourceGroups/(resourceGroupName)/providers/Microsoft.Logic/workflows/(LogicApp name) Você pega essa linha pronta no seu LogicApp > Settings > Properties, no primeiro campo “Resource ID”.

Salve a policy e, em teoria, seu LA está pronto pra ser linkado a um CTE.

Conclusão

Feito! O proximo passo é criar um Custom Task Extension e linkar seu LogicApp a ela. Veremos isso no proximo artigo!

Espero que tenha te ajudado! Grande Abraço \,,/

O post Lifecycle Workflow – Como configurar seu LogicApp para uma Custom Task Extension apareceu primeiro em Entra ID Brasil.

Faaala pessoal, 100%?

Lifecycle Workflows (ou LCW, pros íntimos), é o nome bonito do recurso que pode te ajudar e MUITO durante processos de onboarding, alteração e offboarding de usuários. Já em GA há algum tempo, entrega templates prontos para uso que o ajudarão a governar e padronizar os fluxos de onboarding, mover e offboarding.

Embora uma baita escolha, a barreira que encontramos para adoção do recurso é, ao menos para ambiente que possuem limitação de orçamento, o Licenciamento: Entra ID Governance ou Entra Suite

A curva técnica para implantação não é muito grande, mas precisa se atentar a quais atributos o recurso olha para iniciar uma ação. Exploraremos mais a seguir.

Neste artigo eu quero mostrar por que vale a pena, o que os templates entregam de graça, e o que da pra expandir além do built-in.

Por que eu devo utilizar

Imagine o cenário em uma empresa com mais de mil funcionários (não é raro), RH abre um ticket pro TI avisando que o Fulano sai dia 15. O analista abre o chamado, aguarda a data definida e inicia o processo padrão: Desabilita a conta, remove a licença e uma nova demanda mais urgente chega. O processo de offboarding, muitas vezes, para por aí.

Ninguém revoga os refresh tokens, então a sessão do Teams no celular pessoal dele continua válida por horas. Ninguém tira ele dos 14 grupos de segurança. Ninguém cancela os Access Packages pendentes.

O Lifecycle Workflows entra para apoiar nesses processos. A Microsoft pegou o modelo Joiner-Mover-Leaver (JML) e “transformou” em objeto de configuração dentro do próprio Entra. Você define três coisas:

• Escopo (quem): uma regra de filtro tipo (department eq 'Vendas'), ou uma associação de grupo
• Gatilho (quando): baseado em atributo de tempo (employeeHireDate, employeeLeaveDateTime), mudança de atributo, mudança de grupo, inatividade de sign-in, ou sob demanda.
• Tarefas (o quê): A lista ordenada de tasks

Depois disso, o LCW toca o workflow sozinho, conforme os gatilhos e tarefas que você definiu.

Por que não um Logic App ou Automation

Eu diria que as palavras aqui são duas: Governança e Auditoria. É bem verdade que seja possível alcançar objetivos similares com recursos existentes no Azure, como Automation Account ou o proprio Logic Apps. O que muda de fato são alguns pontos que, para ambientes mais regulados com compliance forte, fazem diferença.

• Versionamento por padrão: Um workflow é versionado. Você altera uma tarefa, o Entra cria uma nova versão, e as execuções antigas continuam referenciando a versão que rodou naquele momento. Todas as alterações auditáveis e imutáveis.
• Escopo declarativo: A regra de filtro fica diretamente na definição do workflow, não em uma condição de determinado step dentro de um Logic App, por exemplo.
• Execução sob demanda com o mesmo código: Os templates de Real-time employee change e Real-time employee termination permite que o próprio HR possa iniciar o fluxo que rodará da mesma forma que um iniciado por triggers pré-definidas. Nesse fluxo podemos considerar tanto tarefas built-in quanto Custom Extensions.

Os que temos built-in

A Microsoft entrega os templates organizados por categoria JML, e hoje temos mais de 10 opções disponíveis. E não, você não precisa utilizar os templates para toda e qualquer fluxo. A Minha sugestão é utilizar-los como uma base apenas, você tem liberdade de alterar as tarefas como preferir, inclusive adicionando Custom Extension com link a um LogicApp (falaremos mais sobre logo menos).

Joiner (chegada):

• Onboard pre-hire employee — Roda em T-7 ( 7 dias antes da data de admissão) por padrão. Aqui temos uma tarefa que é a geração de TAP enviada por e-mail ao gestor. Pra quem tá indo pra passwordless, isso resolve o problema do “como o user faz o primeiro login sem senha”.
• Onboard new hire employee — Roda em T Zero: Habilita a conta, joga nos grupos, manda o e-mail de boas-vindas.
• Post-Onboarding of an employee — Roda em T+7 dias : Adiciona em Grupos e Teams Secundários.

Mover (movimentação):

• Real-time employee change — Sob demanda. Você pode entregar uma permissão users do RH para executar quando precisar
• Employee group membership changes – Como o nome sugere, executa uma alteração de grupo
• Employee job profile change — Dispara em mudança de jobTitle, notifica o gestor, e remove os access packages antigos com remoção agendada de 15 dias por padrão.

Leaver (saída):

• Pre-Offboarding of an employee — T-7 dias antes do último dia.
• Offboard an employee — No dia: desabilita, remove de todos os grupos e Teams.
• Post-Offboarding of an employee — Depois: Remove todas as licenças, remove dos Teams, deleta a conta.
• Real-time employee termination — sob demanda.

Higiene de contas inativas:

• Pre-Offboard inactive users — 90 dias sem sign-in por padrão, usando lastSuccessfulSignInDateTime.
• Offboard inactive users — 120 dias.

Esses dois de inatividade são, pra mim, a entrada mais fácil no LCW. Não dependem de integração com RH, não dependem de employeeLeaveDateTime, e ajudam diretamente a TI garantindo que contas inativas serão tratadas, seja por delação ou disable.

Agent Identities (preview):

• Transition agent sponsorships when a sponsor leaves
• Transition agent sponsorships when a sponsor changes roles

Esses dois exigem licença Microsoft Agent 365 e tratam de um problema que dois anos atrás não existia: identidades de agente de IA têm sponsor humano, e quando esse humano sai da empresa, o agente fica órfão. A Microsoft já colocou isso no modelo JML. Algo me diz que a gente vai falar muito mais disso em 2027.

Dica: Comece pelos templates de inatividade em modo de notificação (tarefas de send email) e sem nenhuma ação destrutiva. Roda por 30 dias, você vê quem ia ser pego, e ganha confiança antes de deixar o workflow rodar de verdade.

Custom Task Extensions

A lista de tarefas built-in é boa, mas não cobre processos mais complexos e customizados. Cada empresa pode ter peculiaridas que as tarefas built-in não cobriram. Por exemplo: Verificar se um usuário possui um dispositivo Windows com enrollement no Intune, e se sim, enviar um Autopilot Reset para o dispositivo.

Outras atividades que geralmente são bem comuns:

• Converter a caixa do usuário em shared mailbox e delegar ao gestor
• Configurar um auto-reply avisando que a pessoa saiu
• Abrir um ticket no service desk pra devolução do notebook

Pra cobrir esse casos de uso existe a tarefa Run a Custom Task Extension (CTE), que faz o workflow chamar um Azure Logic App (Consumption mode apenas, Std não é suportado) no meio da execução. Esse LogicApp entrega possibilidade infinitas ja que suporte ações com chamadas ou chamando um Automation Account que roda PowerShell, Python e outros. O Céu é o limite aqui.

Algo que é interessante de comentar é que o LCW não te obriga a resolver tudo dentro do Logic App, você consegue mesclar ações Built-In com a execuçao de um CTE. Temos dois modos de execução:

• Launch and continue — Dispara o Logic App e segue em frente rodando as tasks que fazem parte do workflow. Se o disparo deu certo, a tarefa é considerada sucesso. Se tua ação não depende de um retorno com sucess ou falha para seguir, essa é uma ótima opção.
• Launch and wait — Dispara e espera a resposta, com timeout configurável. Se ninguém responde dentro da janela, a tarefa falha. Pensa no seguinte fluxo: você pode ter um workflow leaver que, na tarefa 4, dispara um Logic App que abre um ticket no seu ITSM pra aprovação do gestor sobre o destino dos dados do usuário. O workflow fica parado ali. Quando o gestor aprova no ITSM, o ITSM responde ao Entra, e as tarefas 5, 6 e 7 (remover licença, deletar conta) continuam. Isso é um gate de aprovação humano dentro de um processo automatizado de identidade, com trilha de auditoria dos dois lados (compliance, auditing, compliance de novo).

Conclusão

O Lifecycle Workflows está em GA a certo tempo e ja amadureceu bastante. Os templates built-in cobrem o “feijão com arroz” do JML e os de inatividade dão um cheiro da capacidade da ferramenta. Acoplando CTEs, você consegue expandir muito seu uso e cobrir casos aqueles processos e casos de uso exóticos que eu sei que geral tem.

Ao que tudo indica, a Microsoft pretende transformar o LCW no orquestrador do ciclo de vida de qualquer identidade do Tenant. Como já vemos Agent Identities entrando nessa história, fica difícil não imaginar o LCW saindo do JML tradicional e começando a cuidar de outros tipos de identidade também.

Embora o licenciamento ainda possa ser um fator complexo na defesa da solução, os benefícios em padronização e governança pesam pro lado do “Por que Investir”.

Espero que tenha te ajudado! Grande abraço \,,/

O post Entra ID Lifecycle Workflows — Automatizando o Ciclo de Vida de Identidade apareceu primeiro em Entra ID Brasil.

Faaala galera, 100%!?

Facilitar a vida para focar no que de fato importa é um dos lemas que devemos seguir para trazer inovação e garantir que o melhor está sendo entregue. Longe de mim cogitar que o tema do nosso artigo de hoje não seja importante, mas eu tenho certeza de que você vai curtir ter uma ajuda do Entra ID para te lembrar de rodar aquela verificação semestral de acessos.

A revisão de acessos é um ponto crítico na gestão de segurança da informação, principalmente quando se trata de acessos administrativos. O artigo de hoje vista compartilhar uma solução de revisão que utiliza o PIM (Privileged Identity Management) e o Access Review, dois recursos presentes na licença M365 E5 ou add-ons de compliance.

Antes de pular para a solução em si, obviamente, vamos começar do começo, definindo o que é cada recurso e como juntar as duas peças.

RBAC

Na nuvem Microsoft temos o conceito de acesso baseado em função, o famoso RBAC (Role based access). A ideia desse tipo de acesso é flexibilizar e granulizar as permissões existentes em cada workload. No Entra ID, por exemplo, ao invés de entregar a permissão de global admin, podemos ter o acesso específico para user administrators ou grupos. A ideia é trabalhar sempre considerando a maxima do zero trust de entregar a menor permissão necessária (least privilege access).

Além das funções padrões, é possível criar as custom roles, atribuindo ou removendo o que for necessário para seu cenário. Complexo, mas funcional.

PIM

Ainda considerando o Zero Trust, framework que deve ser seu guia, temos o conceito de just-in-time access (Acesso quando necessário). A ideia aqui é que administradores tenha acesso administrativo apenas quando for necessário e não o tempo todo, como era o padrão em ambientes ADDS.

O conceito busca manter o ambiente o mais fechado possível, considerando que uma conta administrativar não é e não deve ser utilizada o tempo todo.

A solução de PIM permite que você solicite elevação de privilegio, atrás de uma role, apenas quando for necessário e por um tempo determinado. Essa solicitação é feita via Entra ID e pode ter efeito imediato ou exigir uma aprovação antes de surtir efeito. A aprovação funciona como um segundo filtro, em que, caso a conta seja comprometida, o atacante não conseguirá executar nada visto que para ter o privilegio Global Admin uma segunda pessoa deve aprovar.

O PIM pode ser aplicado a usuário e grupos que estão habiltiados a receberem Roles do Entra.

Lembre-se que para adicionar uma role a um grupo a flag que permite essa configuração deve ser ativada no momento da criação do grupo.

Access Review

Parte do processo de governança inclui a revisão acesso a grupos e aplicações em seu ambiente. Como já comentado, embora simples, é um processo que pode ser moroso e nem sempre é tido como prioridade.

Para faciltiar a vida de todos, com o Access Review você pode escolher quais grupos ou aplicações farão parte da revisão de acesso e definir qual a peridiocidade e quem deve realizar a revisão.

Na data configurada, o Entra ID informará ao revisor ou revisores, a depender da configuração, para acessarem o portal e informar quem continuar tendo acesso (sendo membro) do grupo ou aplicação definido. E se ninguem responder? É possível definir uma ação automatica, sendo essa não realizar nada ou seguir o que a analise do Entra julga como correta.

Juntando as peças

Você já deve ter entendido onde quero chegar mas seguirei escrevendo, just in case.

Considerando que podemos adicionar grupos ao PIM, por que não incluir revisões periódicas utilizando o Acces Review? Dessa forma teremos o processo de revisão de acessos administrativos automatizado e garantiremos que apenas as pessoas corretas terão a possibilidade de solicitar elevação de privilegio via PIM.

O processo, de forma macro seria:

1. Crie um grupo que permita atribuição de roles
2. Configure as roles no PIM utilizando esse grupo
3. Adicione os usuários que pode soclitiar elevação de privilegio a esse grupo (obviamente, um grupo por role)
4. Crie uma politica no Access Review para esse grupo

Com essa estratégia você garantirá que periodicamente os usuários serão revisados e manutenção no grupo e de acesso privilegiado estará em dia.

Proximos passos

Agora que já temos a solução desenhada, vamos a implantação!

Meu proximo artigo será um passo a passo mostrando como encaixar todas as peças e entregar essa solução. Da criação do usuário até a configuração final e teste do Access Review.

Espero que esse artigo tenha te ajudado!

Grande abraço \,,/

O post PIM e Access Review: Melhore a Gestão de Acessos Privilegiados no Entra ID apareceu primeiro em Entra ID Brasil.