Faala pessoal, 100%?

A nave mãe entupiu Agosto com novidades. Podemos dizer que foi mês de “maturidade operacional” no Entra ID. Apontaria as novidades do Lifecycle Workflow e do Entra Cloud Sync como as bombas do mês. Vamos as news.

Tenant Governance agora em GA

O Microsoft Entra Tenant Governance virou GA. Eu já havia falado sobre esse cara aqui um tempinho atrás. O que antes era colcha de retalhos de scripts e planilhas virou um produto, ainda não tão maduro, mas com muito potencial. Além de apoiar no dia a dia, algo me diz que a msft também pode utilizar esse recurso para fins de auditoria. Vejamos as paginas dos próximos capitulos.

Se você é MSP ou consultor com vários tenants sob gestão, vale mapear como encaixar na operação.

What-if mode no Lifecycle Workflows

O já conhecido What-if, lá das políticas de Acesso Condicional, agora tem sua versão em GA no LCW. A ideia é a mesma, um modo de simulação que roda o workflow “no vazio” e mostra exatamente quais usuários cairiam no escopo, sem executar nada de verdade.

Antes desse recurso o teste era em produção, agora, com o What-if, você valida o impacto primeiro e só aplica quando tiver confiança. Pra mim, esse é o destaque prático do mês, principalmente pra quem não curte parar uma operação pro conta de um erro simples numa query do LCW.

Lifecycle Workflows

Mais novidades para o LCW. Três, todos agora GA:

• Cancelar runs na fila ou em andamento. Se tens algo schedulado, agora é possível cancelar, ou caso a task ainda não tenha sido executada, você também conseguirá cancelar. Atenção que esse recurso não é um ctrl+Z, o que rodou, já foi e estrago está feito =D.
• User Attributes Update agora define ou limpa até 10 atributos por evento.
• E-mails customizados ganharam novo formato de atributos dinâmicos com mais campos disponíveis (built-in, custom security attributes, directory extensions e extension attributes do on-premises). Dá pra personalizar e-mail de onboarding/offboarding sem script externo. Fica bonito? Nem tanto, mas ja é um avanço.

Cloud Sync com writeback do Exchange e sync de devices

O Cloud Sync segue adicionando mais recursos e ganhando espaço;

Writeback de atributos do Exchange Online pro AD em GA. Agora uma vez que a Source of Authority dos atributos de Exchange vá pra nuvem, é possível devolver as mudanças pro AD via Cloud Sync. Esse carinha permite que, por exemplo, uma empresa em transição pro Exchange Online que dependa de algum atributo relacionado com mail, possa ter a mailbox migrada. O CloudSync conseguirá fazer o writeback para o objeto do AD.

Sincronização de devices do AD via Cloud Sync (Preview). Habilita Hybrid Azure AD Join e ciclo de vida de dispositivos (update, disable, delete do AD pro Entra) sem Connect Sync nem AD FS, inclusive em florestas desconectadas. Esse era exatamente o gap que fazia empresa segurar a migração pro Cloud Sync. Como ainda está em Preview, be careful.

Faxina automática de guests sem sponsor

O Lifecycle Workflows ganhou suporte, ainda em Preview, pra detectar e limpar automaticamente contas de convidado sem sponsor. Similar a um Access Review, mas olhando para o atributo “Sponsor” das contas Guest. Simples mas super funcional. Time de governança curtirá, com certeza.

Drops

• SSO no Windows sem prompt repetido (GA): configuração de registro que o admin aplica via GPO/Intune em dispositivos gerenciados (Windows 11 24H2/25H2) pra aceitar SSO automaticamente, sem interromper o usuário. Um pre-req aqui é o KB5101650 instalado. Teste antes de por em produção.
• E-mail opcional no External ID (GA): Federação com IdPs que não compartilham e-mail. Longe de mim ser fã do External ID (antigo Entra B2C), mas está ai uma novidade que ajudará.
• Authenticator: Backup e Restore no iOS via iCloud Keychain com criptografia ponta a ponta, sem depender de conta pessoal Microsoft. E ainda entrega detecção de jailbreak/root bloqueando credenciais do Entra em aparelhos comprometidos.

Conclusão

Muita coisa nova pra estudar e testar agora em Agosto. O foco em Governança mostra uma direção clara da Microsoft e entendo que podemos contar os meses para receber o update de que o Entra Connect será descontinuado.

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

O post Novidades do Entra ID – Agosto 2026 apareceu primeiro em Entra ID Brasil.

Faaala pessoal, 100%?

Hoje quero falar de um recurso do Entra ID que não vejo ser tão famoso, mesmo para as empresas que possuem o licenciamento M365 E5. É comum eu chegar num cliente e ver o processo de acesso funcionando assim: usuário abre chamado, alguém do TI recebe, adiciona a pessoa manualmente num grupo, e fim, acesso concedido e ticket fechado. Funciona bem com ambientes menores mas pode se tornar um problema grave de governança a medida que o ambiente cresce. Além de inundar a fila de tickets com solicitações de acesso.

O Entitlement Management trás uma solução simples, empacota o que cada perfil de usuário precisa e entrega de uma vez só, com ou sem fluxo de aprovação.

Access Package: o “combo” de acesso

Pensa num combo do Burgue King (BK > Mac): em vez de pedir o hambúrguer, depois lembrar da batata, depois da bebida, você pede o combo e recebe tudo junto. O Access Package é o recurso, dentro do Entlitelement management, que entrega isso. Com base em políticas de atribuição que você configura, ele agrupa tudo o que um user ou perfil precisa, degrupos de segurança, aplicações (inclusive SaaS, via Enterprise Applications), grupos Microsoft 365, sites do SharePoint e até mesmo roles.

Você cria um catálogo (pode ser por departamento, por projeto, por parceiro externo), define os recursos que compõem o pacote e configura uma política de acesso determinando:

• Qquem pode solicitar? Apenas users internos, apenas gestores, apenas o Admin?
• O Access Package precisa de aprovação? Se sim, quem?
• O acesso expira sozinho, ou precisa de revisão periódica pra ser renovado?

O resultado, na prática, é que você sabe exatamente quem solicitou, quem aprovou aquele acesso, quando e por qual justificativa. Em caso de auditorias, todos os passos ficam guardados e podem ser utilizados como evidencias na governança de acesso da empresa.

Se preferir, hoje já dá pra fazer atribuição automática de Access Package via regra, similar ao que os Grupos Diamicos fazem (mas diferente) e remover mais uma etapa do processo, facilitando ainda mais a vida da TI e do requerente.

Access Package x Grupo dinâmico

Confusão classica, e com razão. Os dois parecem resolver o mesmo problema e da mesma forma,  “automatizar quem tem acesso a quê com base em uma query. Existe nuances, pequenos detalhes que fazem diferença.

Grupo dinâmico atribui pertencimento a um grupo com base em atributo do usuário: departamento, cargo, localização, o que você configurar na regra. Funciona bem quando o dado/atributo é confiável (alguém realmente mantém o campo “Department” atualizado no RH) e o critério é objetivo, tipo “todo mundo do Financeiro entra no grupo Financeiro”.

O desafio começa a brotar quando temos algo que não é 100% objetivo, seguindo o que os atributos de pesquisa entregam, como: “Acesso temporário ao Projeto XPTO, só durante os 3 meses de implantação, com aprovação do gestor fulano de tal” não cabe numa regra de atributo. Access Package consegue cobrir esses casos de uso combinando recursos que fazem parte do Entitlement Management.

Eu gosto de pensar na diferença da seguinte forma: o grupo dinâmico olha para os atributos do usuário e decide quem entra no grupo. O Access Package já tem uma pegada diferente: ele está preocupado com a concessão daquele acesso, incluindo aprovação, prazo e revisão

Access Review

Acesso concedido em janeiro pra um projeto que terminou em março continua ativo em dezembro, porque ninguém tem processo pra revisar ou o tempo é escassso e outro projeto já entrou no pipeline. Embora pareça simples, é uma gap que atormenta ambientes pequenos, médios e gigantes.

O Access Review agenda campanhas de revisão periódica, sendo: mensal, trimestral, semestral, ou com base no número de dias que você definir. Quem revisa também é configurável: o próprio usuário confirmando que ainda precisa do acesso, o gestor dele, ou o dono do recurso. Dá pra deixar decisão automática caso ninguém responda no prazo, e integrar direto ao ciclo de vida do Access Package, fazendo o acesso cair sozinho se não for confirmado.

Esse é um recurso subestimado por sua simplicidade, mas uma baita mão na roda para os time de governança. Novamente, embora simples, evita que acessos indevidos sejam mantidos, mesmo que alguém esqueça de realizar a revisão (ative a opção de remove caso ninguém responda).

Outros recursos que valem ser citados

Access Package e Access Review são o núcleo, mas tem mais coisa aí dentro.

Os catálogos definem quais recursos podem entrar num pacote, e dá pra delegar um catálogo inteiro pra um dono de negócio, por exemplo: O time de Marketing cuida do catálogo de Marketing sem depender do TI toda vez que surge um recurso novo.

Organizações conectadas pré-cadastram um parceiro externo (outro tenant Entra ID, ou até um domínio de e-mail) como fonte confiável de solicitante, o que evita convidar usuário externo um por um.

Dá pra configurar aprovação em dois estágios (O Gestor do requerente aprova primeiro, dono do recurso ou TI ou qualquer outro user aprova depois) e exigir que o solicitante responda perguntas customizadas antes de enviar o pedido.

Tem também termos de uso, que exigem aceite antes da entrega do acesso (útil com parceiro externo), e a integração com Lifecycle Workflows, que permite disparar a atribuição ou remoção de um Access Package automaticamente dentro de um fluxo de onboarding ou desligamento vindo do RH.

Eu raramente configuro tudo isso de uma vez num cliente. Normalmente começo com catálogo e uma política simples de aprovação, e vou incorporando o resto conforme a maturidade do processo pede.

Conclusão

Ainda não muito explorado mas com potencial gigantesco! Se você hoje possui licenciamento M365 E5 e ainda não explorou o Entitlement Management, faça o quanto antes. Depois do primeiro Access Package, eu tenho certeza que trará mais e mais processos de requisição de acesso.

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

O post Entitlement Management – Simplificando Governança de Acesso apareceu primeiro em Entra ID Brasil.

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.

O recursos que faltava

É isso mesmo que leu no título! O tão esperado recurso para ambientes PHS ou Cloud Only está saindo do forno!

Não é de hoje nem do ano passado que eu recebo perguntas do tipo:

“E como faço para controlar o horario que os usuários podem acessar os apps do M365?”.

O pedido não é apenas um “perfume”. Vários ambientes exigem esse tipo de controle que era fácilmente atingível utilizando as opções de Logon Hours no AD. Se você hoje tem um ambiente híbrido e utiliza PHS ou se tem um ambiente Cloud Only, a única forma de entregar esse controle é por meio de automação. Relativamente simples, mas ainda assim, algo customizado, nada built-in.

Pequeno adendo, se você tiver identidade hibrida e utiliza PTA, o Logon Hours do AD já resolve seu problema =D.

Acesso Condicional baseado em Horário

Antes de mais nada

Os testes realizados aqui são de um recurso que ainda está em Beta, nem mesmo em preview e sem documentação oficial da Microsoft. Utilize por sua conta e risco e NUNCA em produção

Indo até o Graph Explorer e rodando um GET nas políticas de Acesso Condicional, você notará um campo disponível chamado: “Times“.

Expandindo um pouco mais os testes, podemos rodar um PATCH na seção de Times da política e definir dias da semana e horário em que essa regra será aplicada.

{
    "conditions": {
        "times": {
            "includeAllTimes": true,
            "includeDays": null,
            "excludeDays": {
                "daysOfWeek": ["monday", "tuesday", "wednesday", "thursday", "friday"],
                "timeZone": "UTC",
                "startTime": "02:15:00",
                "endTime": "00:00:00",
                "allDay": false
            },
            "includeRange": null,
            "excludeRange": null
        }
    }
}

Note que os horarios devem ser informados no padrão UTC. Eu testei utilizando outras Time Zones mas em todas as opções retorno erro. Por enquanto, utilize um conversor de Time Zone para encontrar o horario exato para seus testes. Tudo caminhando bem, sua política será configurada considerando o horario que você definiu ali no Patch. No meu caso, criei uma política de Block para um usuário apenas, e nela defini que entre 23:15 e 00:00 o acesso seria bloqueado.

O resultado

Ao tentar logar após o horario definido, recebo uma mensagem informando que o acesso não é permitido. Aquele genérico de blocks por conta de Acesso Condicional. Por enquanto nenhuma mensagem personalizada que indique o motivo do block tem sido exibida, tampouco lá nos Sign-in Logs.

O que encontrará será apenas, também, um log genérico te mostrando que um bloqueio ocorreu, mas nada indica que foi por conta do horário definido.

Detalhes Importantes

• Eu vou repetir! Esse recurso é para ser utilizado como TESTE, e nada além disso. Não existe suporte alguem da Microsoft ainda. Espero ver em breve o recurso em Preview
• Você pode esperar ainda instabilidade nesse recurso. Como comentei, é um BETA no Graph API
• A opção de horario (Times) não está disponível e nem é exibida na console do Entra. Você conseguirá ver isso apenas via Graph
• As alterações não alterarão nada na console do Entra (nenhum campo novo será exibido). Novamente, tudo via Graph
• Os logs sign-in não dão pista nenhuma. Conseguimos concluir que a política foi aplicada dando comparando o horario de acesso com o que foi configurado. No meu caso, testei com dois usúarios, um que era alvo da política de horario e outra que não estava listado.

Só pra reforçar. NEM PENSE EM USAR ISSO EM PRODUÇÃO, POR ENQUANTO.

Conclusão

Ainda em Beta, mas tudo indica que logo menos teremos esse baita recurso disponível nas console do Entra, entregando ainda mais flexibilidade para gestão e governança de identidades com o Entra ID.

Depois me conta se testou e funcionou. Espero que tenha curtido!

Grande abraço \,,/

O post Acesso Condicional baseado em horario 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 pessoal, 100%?

A Microsoft não postou a seção de julho no portal de News do Entra, mas mesmo assim, tivemos alguns anúncios que valem ser citados.

Temos duas grandes notícias para julho, ambas podem impactar diretamente sua operação.

Adios, SMS e ligação. Welcome passkey como método de autenticação padrão

A nave mãe anunciou que aposentará o serviço de SMS e ligações como segundo método de autenticação, no formato que existe hoje. Isso não quer dizer que essas duas opções estarão indisponíveis, a grande mudança aqui é que agora, você terá de pagar pelo uso delas. Sim, a entrega dos SMSs e ligações não será mais feita de forma gratuita pela Microsoft. Para continuar utilizando esses dois metodos, você terá de contratar uma das opções disponíveis no EntraID e, obviamente, pagar por isso.

Essa manobra era meio que esperada, visto o crescimento de ataques de roubo de token. E também funciona como um pequeno empurrão para a adoção mais acelerada do Passkey.

Status: Anúncio oficial (rollout começa em setembro/2026, corte em fevereiro/2027)

O que indico como próximos passos:

1. Levante quem no seu tenant usa exclusivamente SMS ou ligação como MFA
2. Rode (ou acelere) uma campanha de registro de passkey pra esse grupo antes de setembro
3. Decida se precisará de um provedor de telecom customizado — se sim, comece a avaliar opções desde já, porque a Security Store só liberará isso em 18/09
4. Trabalhe em conjunto com seu time de suporte. É certeza que o fluxo de chamados aumentará durante essa possível transição

Rollout do Cloud Sync iniciado

Como anunciado em Abril, Microsoft Entra releases and announcements – Microsoft Entra | Microsoft Learn, a Microsoft iniciou a preparação para a migração de Tenants para o Cloud Sync.

Se você faz parte das primeiras ondas, já pode ter recebido em seu Message Center ou Entra Connect Health uma mensagem alertando-o sobre a mudança.

Apenas reforçando, essa é uma mudança que não haverá um opt-out, a Microsoft empurrará a alteração sem opt-out.

Vale conectar isso com outro reforço de segurança do mesmo ciclo: desde 1º de junho de 2026, o Entra já bloqueia qualquer tentativa de “hard-match” vindo do AD que tente assumir um usuário cloud que já tenha Entra Role atribuída. Isso fecha uma brecha já conhecida de escalação de privilégio via manipulação de atributo no on-prem.

Status: Plan for change (notificações começaram em julho/2026, rollout em ondas ao longo dos próximos meses)

Jailbreak/Root Detection no Authenticator: agora oficialmente também no Android

Já falamos sobre o bloqueio implementado no Authenticator, onde o app passou a bloquear celular com jailbreak/root. Em julho temos a expansão desse padrão também para Android.

Embora você já faça isso utilizando App Protection (Se não faz, deveria), qualquer usuário agora não conseguirá mais utilizar o Microsoft Authenticator caso tenha o celular com Jailbreak (iPhone) ou Root (Android).

Mais uma vez, vemos a Microsoft se posicionando de maneira mais robusta em relação a requisitos de segurança para utilização de seus Apps.

Status: GA

Conclusão

Não tivemos volume de novidades em Julho mas, garanto que não faltará planejamento e atividades com as mudanças previstas

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

Fonte oficial: Microsoft Entra releases and announcements – Microsoft Entra | Microsoft Learn

O post Novidades do EntraID – Julho 2026 apareceu primeiro em Entra ID Brasil.

Há, informação importante. Eu já disse isso no artigo inicial sobre o ADConnect mas vale repetir, em se tratando de senha o sync ocorre a cada 2 minutos, ok?!

O que é o PHS?

O escolhido para começar a jornada de estudo é o Password hash synchronization (PHS). Como o nome propõe esse método de sincronização leva o hash da senha do AD para nuvem e com isso os usuários conseguem utilizar a mesma senha que usam “dentro de casa” para logarem em cargas de nuvem (OneDrive, Exchange…).

Utilizando vários mecanismos para realizar essa sincronização de maneira segura e efetiva (relax que vou explicar), o PHS, a meu ver, é o método mais popular e fácil para se iniciar um ambiente híbrido de pequeno ou grande porte! Esse “popularismo” se dá ao fato de não exigir nada além do ADConnect pra que funcione e, em caso de falha ou indisponibilidade temporária do ADConnect o acesso a cargas cloud não são prejudicados. Entenda aqui que, obviamente, se houver uma alteração de senha enquanto houver uma indisponibilidade do ADConnect, o hash da nova senha não será sincronizado e como esperado a senha antiga deve ser utilizada. Após reestabelecimento do serviço e sincronização Delta o user poderá utilizar a nova senha para login!

Como funciona o PHS?

Como sempre digo, melhor do que saber qual opção selecionar ou qual botão apertar, é saber como as opções funcionam “por baixo dos panos”.

Muitos pensam que optar pelo PHS é basicamente permitir que o ADConnect copie a senha do seu AD e cole no AzureAD! Not that simple, bitch! É super importante dizer que o AzureAD, em momento algum, tem contato com a senha de ambiente local. O que é enviado ao AzureAD é hash do hash da senha do AD.

“Ok Nathan, mas o que diabos é hash?”

Eu não sou matemático pra entender a fundo como um hash funciona, mas sei que o “Hash” é um tipo de criptografia utilizada para garantir a integridade de uma informação sem expor tal informação. Um exemplo (nada real, apenas fictício a nível didático):

MinhaSenha + hash = 2ab96390c5dbe1437na23l0c6b1b1762

Agora que temos uma ideia básica do que seja o hash, vamos entender como o processo todo funciona, de forma simples e direta.

1. A cada 2 minutos um o agente de sincronização utilizando o protocolo MS-DRSR consulta o atributo “UnicodePWD” e busca o MD4 da senha no AD.
2. Antes de enviar o MD4 o DC encripta esse hash com uma chave baseada em MD5+salt (entenda salt como alguns bit que são acrescido para fins de segurança) da sessão RPC.
3. O DC então envia essas informações ao agente de sincronização
4. Por sua vez o agente de sincronização remove o MD5 para ter acesso ao Hash MD4 da senha.
5. O Agente de sincronização realiza alguns processos de expansão e conversão desse Hash MD4. No final, o hash de 16 bytes torna-se um de 64 bytes.
6. Em posse do do hash de 64-bytes o processo ainda adiciona um salt de mais 10-bytes.
7. Não acaba por ai…depois disso tudo o agente de sincronização combinará o MD4 como salt e imputará isso tudo em uma função PBKDF2 que é basicamente um mecanismo de criptografia que expande chaves de forma randômica para aumentar o nível de complexidade da mesma. Além disso são realizadas 1000 interações com o algoritmo HMAC-SHA256.
8. No final, tudo isso é concatenado (MD4+salt+PBKDF2+HMAC-SHA256) é enviado ao AzureAD através de um túnel TLS 1.2.
9. A validação da senha ocorre com o AzureAD comparando os hashes que ele já possui com os recebidos por esses processos

copyright: https://security4cloud.fr/

O PHS é seguro?

Você leu o topico anterior?

Eu ouvi muito e li alguns textos de pessoas defendendo que o PHS não seria um método seguro de sincronização de senha. Esse tipo de afirmação vem da falsa ideia de que a senha, em texto plano, é transmitida e armazenada no AzureAD.

Eu já citei, mas vale reforçar: Sua senha em texto plano não é exposta em momento algum a nenhum serviço que faz parte de todo esse processo!

Entenda que, do passo 1 ao passo 7, tudo ocorre do lado local, entre ADConnect e DC. A autenticação do usuário em si ocorre na nuvem. O pacote enviado ao AzureAD contendo o hash do hash da senha do AD está mais protegido do que é armzenado no seu AD OnPrem.

Caso esteja curioso de como uma senha comum fica depois de parte desse processo realizado pelo ADConnect, de uma olhada nesse site.

Mas e se capturarem o hash do hash e fizerem engenharia reversa?

A Microsoft garante que esse processo não é possível. Por conta do SHA256 uma decriptação não é opção e, tentar utilizar o hash enviado ao AzureAD localmente, numa tentativa de ataque pass-the-hash, não funcionará.

O tenho de Pros/Cons utilizando o PHS?

• Pro – Smart Lockou
• Pro – IP Lockout
• Pro – Microsoft Leaked credentials Service
• Pro – DoS Protection
• Pro – Password Spray Attack protection
• Con – Não pode utilizar recursos como restrição de horários para login

Conclusão

Embora simples o PHS é uma baita solução de autenticação e em minha opinião a melhor escolha para grande parte dos ambientes.

Unindo simplicidade e segurança o método e autenticação ainda consegue entregar estabilidade e mais alguns recursos nativos da Cloud Microsoft (se a licença do AzureAD permitir, é claro).

Obviamente temos ainda o PTA e o ADFS (veio de guerra) que, dependendo da situação, podem ser boas opções também.

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

O post ADConnect – Entendendo o PHS apareceu primeiro em Entra ID Brasil.

A quantidade de dispositivos móveis acessando dados corporativos e o aumento exponencial de pessoal que trabalham remotamente vem chacoalhando a vida dos especialistas em cybersec a um tempinho. A evolução no formato de trabalho trouxe o desafio de prover segurança a dados corporativos, além da fronteira das empresas. O que antes um firewall e um AV dava conta, hoje em dia, não dá “nem pro cheiro”.

Tendo toda essa problemática em mente, a “solucionática”, com diria Dadá Maravilha, passou a ser considerar a identidade como ponto crucial de gerenciamento e proteção, visto que a segurança de perímetro, já havia ficado obsoleta, e daí que surge o termo “Zero Trust”.

O que é Zero Trust?

O temo que hoje é super popular não dá nome a uma solução em si, mas a um conjunto de práticas que visa aumentar sua postura de segurança localmente e na internet (cloud). O modelo tem como premissa a frase: Nunca confie, sempre verifique. Tendo isso como base, uma solução baseada em Zero Trust assume que não é possível garantir que um device ou usuário é/são confiáveis usando única e exclusivamente sua localização (perímetro). É preciso garantir formas de verificação explicita de que o usuário X, é de fato o X e não o Z. Para se atingir esse nível é preciso, como já disse um pouco antes, deixar de focar no perímetro e focar na identidade, que vai muito além dos limites que seu firewall protege!

O NIST publicou em 2020 um paper bem bacana falando sobre o modelo Zero Trust. Nele, os autores defendem que uma solução deve focar em proteger recursos como ativos, serviços, contas, fluxos de trabalho, contas de rede e outros, não apenas segmentos de rede, visto que estes deixaram de ser a principal preocupação em um ambiente protegido.

Existem três princípios no modelo:

• Verifique Explicitamente: Sempre autorize e autentique baseado em todas as informações disponíveis
• Use o menor privilégio de acesso possível: Não dê permissão além da necessária. Siga a ideia do JIT/JEA (Just-in-time / Just-enough-access)
• Assuma que brechas existem: Garanta, sempre que possível, criptografia de ponta a ponta e recursos para evitar movimentação lateral

Quando os três pontos, em teoria, atingimos o objetivo proposto pelo modelo. Obviamente, cenários corporativos mudam com frequência e ajustes devem ser feitos para que maturidade de segurança do ambiente se ajuste as mudanças e não seja reduzida com o passar do tempo.

Sugiro a leitura do paper na íntegra pra mais detalhes.

Zero Trust e Microsoft 365

Agora que já entendeu (espero que sim) a ideia base do modelo Zero Trust, a pergunta que fica é: como o M365 pode te ajudar a atingir esse objetivo?

Bom, existe “N” recursos que podem e se encaixam em um modelo de implementação Zero Trust! A Microsoft entende e leva em consideração 6 grandes áreas que geram “sinais” e devem ser consideradas em seu plano de implantação

Cada ponto apresentado na imagem acima é um pequeno mundo a ser analisado e considerado. Claro que nem sempre todos os pontos acima serão encontrados em todos os ambientes, cada caso é um caso. O importante é saber que a nave mãe consegue te apoiar em todos eles, da identidade a rede local.

E como posso dar os primeiros passos rumo ao Zero Trust, usando Microsoft 365?

Nada melhor do que mão na massa, certo? Então, vou deixar três recursos que vão te ajudar na missão Zero Trust. Vamos considerar um cenário simples, com licenciamento nível Business.

• MFA – Duplo fator de autenticação
• Acesso Condicional – O core do Zero Trust. Esse recurso será um de seus melhores amigos na missão Zero Trust, com ele é possível analisar vários sinais e liberar ou não o acesso baseado nos resultados encontrados
• Endpoint Manager/Intune – Esse cara lhe dará condições de gerenciar dispositivos corporativos que estejam fora da rede da empresa

As três soluções acima, se bem configuradas e ajustadas a seu ambiente, vão garantir um nível segurança maduro a seu ambiente e dados corporativos.

A configuração de cada um varia de acordo com a necessidade de cada ambiente, mas é claro que trarei alguns artigos mostrando como configurá-los, na prática.

Para cenários mais avançados que possuem licenciamento Entreprise, incluiria na lista mais 3 recursos:

• Azure AD Password Protection – Recuso que permite a criação de uma lista de senhas banidas, além de utilizar uma lista global da msft. Protege tanto cloud quanto OnPrem
• Azure AD Identity Protection – Recurso analisa a fundo localidade do login, IP utilizado para login, vazamento de credenciais, viagem atípica e alguns outros.
• SSPR – Portal de reset de senha para usuários, via cloud

Conclusão

Zero Trust é o presente e futuro da segurança em nuvem. Entender como funciona e como atingir o modelo sugerido fará uma diferença gigantesca pra você enquanto profissional e para os ambientes que você gerenciará.

Estude a fundo as possibilidades e cole aqui pois falaremos bastante sobre o tema!

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

O post Zero Trust com Microsoft 365 – O início apareceu primeiro em Entra ID Brasil.

O objetivo central deste artigo é explicar de forma simples o que é um Tenant no mundo Microsoft. Além de explicar o que é, a ideia é esclarecer algumas situações em que conhecer e entender o termo será de grande ajuda!

Você já deve ter notado que toda empresa que possui algum serviço na Nuvem Microsoft, seja Azure, M365, PBI, qualquer coisa, sempre terá uma conta, geralmente a de administrador, com o domínio @onmicrosoft.com, certo? Observe que o domínio onmicrosoft.com é comum a todas as empresas que utilizam um serviço na Nuvem Microsoft. Esse domínio é chamado de domínio de fallback e sempre vem acompanhado de outros atributos chamados “Tenant Name” e “Tenant ID”. Esses três elementos identificam de forma única e global o seu Tenant.

O que é um Tenant

Em uma tradução literal para o nosso querido português, “Tenant” seria equivalente a inquilino ou locatário. Entendeu? Podemos encerrar o artigo agora?

“OK, Nathan, mas e aí? Ainda não tenho ideia do que seja um Tenant”.

Vamos a uma analogia:

Imagine uma cidade chamada “Cloud Computing”. Na cidade Cloud Computing, existe um condomínio chamado Microsoft. Esse condomínio permite que outras empresas utilizem seu espaço e, para isso, cobra um valor pelo uso desse espaço.

Dentro do condomínio Microsoft, você pode ter um lote ou espaço só seu. Para cada espaço que você “aluga” dentro do condomínio, chamamos de Tenant. Esse Tenant deve ter um nome único no condomínio e ganhará um endereço que obrigatoriamente terá um sufixo onmicrosoft.com (NaMicrosoft.com). Claro que você pode e deve ter endereços customizados como nathanpinotti.com.br, mas o endereço único dado ao seu lote (nathan.onmicrosoft.com) sempre existirá, mesmo que não seja o seu principal.

No mundo técnico, a Microsoft aluga espaço em sua nuvem para que empresas consumam e paguem por seus serviços. Para que a Microsoft o identifique de forma única, você deve definir um nome globalmente único, que receberá o sufixo onmicrosoft.com. Esse sufixo também será utilizado nas URLs de serviços que você acessa, como SharePoint, OneDrive, PowerBI e outros.

Em seu lote (Tenant), você pode cadastrar vários endereços customizados (domínios personalizados) e usá-los como preferir e nos serviços que preferir. É possível também ter várias assinaturas (subscriptions) sem nenhum problema e, nelas, realizar mais uma segmentação a nível financeiro e de recursos. Além das subscriptions, o licenciamento utilizado na empresa fica atrelado ao Tenant.

Perguntas/Dúvidas comuns (FAQ)

• Minha empresa pode ter mais de um tenant?

Sim, quantos você quiser. O ponto é medir se vale o custo o custo operacional (gestão) de vários tenants. No geral essa ideia vem para segmentar os serviços mas é totalmente possível seguir outras estratégias e facilitar sua vida a nível de gerenciamento.

• Meu grupo possui 3 empresas cada uma com um Tenant e preciso que todas elas colaborem entre sim, é possível?

Sim! A forma mais comum e fácil de fazer isso é configurando uma relação de confiança entre os Tenants. O Entra External ID for partners (B2B) antigo AzureAD B2B é o formato mais simples de se fazer isso

• Preciso alterar a URL do meu tenant. É possível?

Do SharePoint e serviços que o consomem, sim! Desde o segundo semestre do ano passado a Microsoft permite alterar a URL do SharePoint. Você também pode ter um segundo fallback domain.

• Consigo migrar recursos e configurações de um Tenant para o outro?

Não! O que conseguimos no momento é migrar cargas de trabalho como OneDrive, Emails, Teams e SharePoint site. Mesmo conseguindo migrar utilizando ferramentas nativas, pra essa tarefa indico ferramenta de terceiros

Conclusão

Embora simples, o conceito pode não ser tão claro pra muitos profissionais de TI e usuários. Aos profissionais de TI, esse é um conhecimento base e estar na ponta da lingua quando um cliente o questionar.

Espero que tenha te ajudado a clarear esse conceitos! Um grande abraço \,,/

O post O que é um Tenant Microsoft? apareceu primeiro em Entra ID Brasil.

A identidade tornou-se o item mais crítico e sensível em um ambiente corporativo quando o perímetro deixou de ser um limitador para o uso de informações e sistemas corporativos. Em uma época em que seus ativos de TI estavam atrás de um firewall e/ou ingressavam em um domínio com uma boa solução antivírus, seu dispositivo e suas informações estavam protegidos. Hoje, em um mundo onde a cultura do trabalho remoto é realidade e o perímetro da rede não existe, o foco deve e precisa ser a identidade.

Sem o perímetro de rede o conceito Zero Trust se torna o padrão recomendado para gerenciar e proteger ambientes. Uma parte essencial do Zero Trust refere-se à proteção e governança da Identidade, pela qual a Entra ID é responsável.

Anteriormente conhecido como Azure AD, o Entra ID, tem é responsável por fornecer recursos que gerenciam, protegem e controlam a identidade de seu usuário, seja em nuvem ou sincronizadas com o domínio local. Quando as credenciais são sincronizadas do Active Directory para o Entra ID, temos o famoso ambiente de identidade híbrida.

Sincronizando suas identidades com a nuvem

Para gerenciar e fornecer um alto nível de segurança às credenciais locais você precisa primeiro sincronizá-las com a nuvem usando o Microsoft Entra Connect, onde exitem três opções de métodos de autenticação de entrada para escolher.

PHS

O principal e mais utilizado é o PHS (Password Hash Synchronization), eu já escrevi sobre ele aqui, o método padrão e mais fácil de se ter um ambiente de Identidade Híbrida. Como o nome sugere, o PHS sincroniza apenas os hashes de senha, que é um processo matemático de transformar qualquer chave ou uma cadeia de caracteres em outro valor do Active Directory para o Entra ID. Por conta desse processo de hash contínuo e repetido, a Microsoft garante que é impossível usar engenharia reversa para ter acesso à senha em texto plano no caso de uma interceptação de tráfego ou vazamento de dados. É essencial deixar claro que nem o Active Directory nem o Entra têm contato com a senha em si.

Durante a configuração do Entra Connect, um link é criado entre o objeto local (usuário) e o objeto na nuvem. Assim, sempre que um usuário alterar sua senha localmente, o hash de senha do AD será sincronizado com o Entra ID. Isso significa que, usando o PHS, não há dependência do ambiente local para autenticar um usuário em uma carga de trabalho de nuvem, como Exchange, Teams ou OneDrive. Tudo acontece na nuvem.

Também vale ressaltar que o uso do PHS Entra ID pode avaliar se as credenciais estão listadas na deep ou dark web. Esse tipo de informação é essencial para que a equipe de segurança possa aprimorar a política de senhas, exigindo maior complexidade, por exemplo. E mais uma vez, NENHUMA SENHA É ENVIADA OU MANTIDA NA NUVEM, o que é sincronizado é o Hash de sua senha.

PTA

A segunda opção disponível como método de autenticação de sign-in é o Pass Through Authentication (PTA). Essa opção, diferente do PHS, depende do AD para autenticar os usuários que acessam cargas de trabalho na nuvem. Quando os usuários tentam acessar suas caixas de correio ou arquivos na nuvem, a solicitação é enviada de volta ao ambiente local por meio de agentes PTA e o Active Directory valida as credenciais. Com base nisso, a Microsoft garante que o Entra ID não tem contato com as credenciais dos usuários.

O principal aspecto do PTA que você deve ter em mente se estiver planejando escolher esse método é que você de agentes PTA para lidar com as solicitações de autenticação. Considerando que há uma dependência de entrar em contato com o AD para autenticar o usuário, ter uma abordagem de failover é essencial para seu ambiente. Como recomendação, você deve ter pelo menos 3 agentes PTA instalados em servidores diferentes que não sejam Controladores de Domínio.

Por que escolher PTA em vez de PHS se o custo operacional é maior? Bem, certas organizações podem querer impor suas diretivas locais de segurança e senha do Active Directory. Algumas empresas usam o recurso AD de horário de logon para definir quando um usuário pode ou não fazer logon no ambiente. Então, se esse é o seu caso, a PTA é para você.

ADFS

O ADFS (Serviço de Federação do Active Directory) é uma tecnologia antiga usada para integrar e consolidar o processo de autenticação, aproveitando as credenciais do Active Directory. Aquite termos a mesma dependencia e no PTA em relação ao ambiente local. A grande diferença é em como o ADFS lida com as requisições e claro a estrutura necessária para ter um ambiente setguindo as recomendações Microsoft.

Hoje em dia, a menos que seu ambiente solicite o uso do ADFS, não consigo ver uma razão para escolher essa opção em vez de PHS ou PTA. Embora a Microsoft não tenha anunciado uma data de fim de vida útil para o ADFS, ela aconselha a transição para o Entra ID em vez de atualizar para uma versão mais recente do ADFS devido ao serviço de gerenciamento de identidade e acesso baseado em nuvem que pode ajudá-lo a gerenciar seus usuários e aplicativos com mais eficiência.

Agora que você tem uma visão melhor das opções de sincronização, vamos checar como e quais recursos estão disponíveis no Entra ID para melhorar a segurança de identidade em seu negócio.

Protegendo senhas com o Entra ID

Considero o gerenciamento de senhas um dos calquanhares de aquiles para qualquer ambiente, independentemente do tamanho. Mesmo com treinamentos e uma excelente política de segurança, os usuários tendem a escolher combinações facilmente adivinháveis ou termos simples como parte da senha.

O Entra Password Protection ajuda você a enfrentar esse desafio e evitar o uso de combinações nao seguras. Usando uma lista Global da Microsoft somado a uma lista de termos proibidos personalizadas, o Microsoft Entra Password Protection pode detectar e bloquear senhas fracas/conhecidas e suas variantes. A lista global é mantida pela Microsoft e é atualizada constantemente com base nos dados de telemetria de segurança da Microsoft, enquanto a lista personalizada pode ser preenchida com até 1000 itens, de acordo com as necessidades da empresa.

Com um algoritmo robusto de validação de senha, o Entra Password Protection usa um processo chamado normalização para detectar e bloquear variantes. Se eu incluir a palavra “Nathan” à lista de banidos personalizados e tentado definir “N41h4n” como uma senha o Entra bloquearia a ação. Isso é útil porque você não precisa lembrar ou considerar todas as variações possíveis, o Entra faz isso por você.

Você pode expandir essas políticas para seu ambiente local usando um agente e um proxy. A recomendação é ter o agente instalado em todos os Controladores de Domínio e, em pelo menos dois servidores membro, instâncias do serviço Proxy. Esses dois componentes são responsáveis por receber as políticas do Entra ID e avaliar se a senha pode ou não ser aceita. Os DCs, usando uma DLL de filtro, recebem a nova solicitação de alteração de senha e a encaminham para um proxy que, que por sua vez, a envia ao Entra ID para verificação. O processo acontece da mesma forma nos dois sentidos.

É importante mencionar que a validação, detecção e bloqueio de senha só acontecem durante o evento de redefinição. Se o seu usuário já tiver uma senha fraca, o Entra Password Protection não fará nada a respeito.

Redefinição de senha de autoatendimento (SSPR)

Ainda falando sobre gerenciamento de senhas, um recurso simples, mas útil, é o Self-Service Password Reset (SSPR), um portal da web que permite aos usuários redefinir suas senhas, fornecendo apenas o endereço de e-mail e o segundo fator de autenticação, como um código de verificação, um token para um aplicativo ou respondendo a perguntas de segurança.

Mas o que isso tem a ver com segurança? Well, well…todas as senhas estarão sob a política da empresa, e o principal fator é que ninguém além do próprio usuário terá acesso à senha. Assim como no Entra Password Protection, você também pode aproveitar esse recurso no ambiente local sinalizando uma opção para habilitar a opção de password Writeback no Entra Connect. Como o nome sugere, esse recurso permitirá que senhas alteradas na nuvem sejam gravadas de volta no Active Directory.

Proteção avançada de identidade

O Microsoft Entra ID Protection é um recurso avançado que pode detectar, investigar e corrigir riscos baseados em identidade. Ele usa insights a partir de  trilhões de sinais que a Microsoft coleta para detectar e determinar usuários, logins ou aplicativos em risco.

Antes de entrar na explicação do recurso, é importante definir um risco. A Microsoft define um risco como qualquer ação suspeita identificada relacionada a contas de usuário em seu Tenant. Essas ações podem ser consideradas um risco para o ambiente e podem ser detectadas no nível de Usuário  (risk user) e Login (risky sign-in), em tempo real (online) ou offline.

O processo de detecção é baseado em comportamentos de risco que já estão catalogados pela Microsoft (25 built-in) para te ajudar seu ambiente. Alguns deles são:

Detecções de risco de entrada

• Endereço IP mal-intencionado – Essa detecção indica a entrada de um endereço IP mal-intencionado. Um endereço IP é considerado malicioso com base em altas taxas de falha devido a credenciais inválidas recebidas do endereço IP ou de outras fontes de reputação de IP
• Viagem impossível – Esta detecção identifica as atividades do usuário (sessões únicas ou múltiplas) originadas de locais geograficamente distantes dentro de um período de tempo menor do que o tempo que leva para viajar do primeiro local para o segundo.
• Usuário confirmado pelo administrador comprometido — essa detecção indica que um administrador selecionou ‘Confirmar usuário comprometido’ na interface do usuário de Usuários de Risco ou usou a API de Usuários Arriscados.

Detecções de risco do usuário

• Credenciais vazadas – Esse tipo de detecção de risco indica que as credenciais válidas do usuário foram vazadas com base nos dados da Microsoft coletados da investigação na deep/dark web.
• Tráfego de API suspeito – Essa detecção de risco é relatada quando o tráfego anormal do gráfico ou a enumeração de diretório é observada por um usuário. O tráfego suspeito da API pode sugerir que um usuário está comprometido e realizando reconhecimento em seu ambiente.
• Atividade anômala do usuário – Essa detecção de risco linha de base o comportamento normal do usuário administrativo no Microsoft Entra ID e identifica padrões de comportamento estranhos, como alterações suspeitas no diretório.

Durante cada evento de autenticação, o Identity Protection executa um conjunto de algoritmos de detecção em tempo real, gerando assim uma métrica de risco que indica a probabilidade de comprometimento de determinada sessão. Com base nessa pontuação de risco, um conjunto específico de regras de segurança é automaticamente colocado em ação.

Para a etapa de investigação, o Entra ID Protection fornece relatórios importantes com dados chave para os administradores analisarem e entenderem o que está ocorrenco e como pode ser corrigido.

Quando existe um match para um evento arriscado, você tem a opção de agir manualmente ou aproveitar as ações de correção built-in usando o Acesso Condicional. O Acesso Condicional pode exigir controles de acesso, como uma alteração de senha ou fornecer um método de autenticação forte. Se o usuário concluir as etapas necessárias com êxito, o risco será corrigido automaticamente.

Acesso Condicional

O Acesso Condicional é uma validação de segundo estágio que fornece um amplo conjunto de verificações usadas como condições para saber se o acesso é permitido ou bloqueado durante o processo de autenticação, eu já escrevi sobre os serviço aqui. Com  o Acesso Condicional, o Entra ID pode determinar a localização, o tipo de dispositivo, o aplicativo que está sendo acessado, o status de conformidade do dispositivo, os alertas da Proteção de Identidade e até mesmo se a empresa gerencia o dispositivo no qual o usuário está acessando um aplicativo específico.

Dependendo dos resultados da validação das condições, a política de Acesso Condicional pode impor um processo de MFA (Multi-Factor Authentication), uma solicitação de alteração de senha ou até mesmo bloquear o processo de logon.

Um recurso interessante que faz parte das políticas de acesso condicional é a avaliação contínua de acesso (CAE), que avalia as sessões dos usuários em tempo real e pode responder a violações ou atualizações de políticas prontamente. Ele garante que o acesso do usuário será afetado quase em tempo real quando um token de sessão for revogado.

Conclusão

O Microsoft Entra ID oferece uma vasta oportunidade de proteger suas identidades locais e na nuvem com uma abordagem flexível e moderna. Para as empresas nascidas na nuvem, o processo de modernização pode ser menos complexo em comparação com as empresas que planejam iniciar a jornada na nuvem. Em qualquer caso, validações e MUITO planejamento devem ser os primeiro passo pra quem deseja seguir o futuro em relação a gerenciamento e proteção de identidades!

Fique a vontade para me pingar!

Abraço \,,/

O post Protegendo identidades com o Microsoft Entra ID apareceu primeiro em Entra ID Brasil.