Skip to content

Ulysses Neves

Microsoft Entra ID, authentication, and hybrid identity troubleshooting.

Menu
  • Início
  • Microsoft Azure
  • Microsoft AD FS
  • Microsoft 365
  • Contact
Menu

Azure CA Policy – Controlando sessões de navegação usando políticas de acesso condicional

Posted on 17 de April de 2020

Olá pessoal. No artigo de hoje, vamos apresentar a opção de gerenciamento de sessão de navegador disponível na política de acesso condicional do Azure. Vamos criar uma política de controle de sessão para acesso de administradores às aplicações hospedadas no Azure. Essa política em conjunto com o controle de segundo fator garante que sempre que um administrador abrir um novo navegador, deverá se autenticar usando MFA.

Conditional Access persistent browser session (preview)

A sessão persistente de navegador permite que o usuário se mantenha logado em uma aplicação mesmo após fechar e abrir o navegador. Ela apresenta ao usuário a opção “Stay signed in?” após se autenticar no Azure usando um navegador.

Vamos executar as seguintes atividades ao longo desse artigo:
1 – Criação da política de acesso condicional para usuários com privilégio de Global administrator apresentarem um segundo fator de autenticação para acesso à todos os aplicativos no Azure.
2 – Testes de acesso sem o controle de sessão habilitado.
3 – Configuração do controle de sessão na política de acesso condicional.
4 – Testes de acesso com o controle de sessão habilitado.

Criando a política de acesso condicional com MFA

Vamos criar a política de acesso condicional acessando o menu Conditional Access policies através deste link.

Selecione a opção New policy.

Entre com o nome da política no campo Name.

Vamos selecionar a função Global administrator a receber essa política executando os passos abaixo:
1 – Selecione a opção Users ans groups.
2 – Selecione a opção Select users and groups.
3 – Marque a opção Directory roles (Preview).
4 – Selecione na lista a função Global administrator.

Clique em Done.

Vamos selecionar todos os aplicativos do Azure executando os seguintes passos:
1 – Selecione o menu Clouds apps or actions.
2 – Selecione All cloud apps.

Vamos definir o a necessidade de fazer a autenticação de segundo fator selecionando no menu Access controls a opção Grant.

Marque a opção Require multi-factor authentication.

Vamos habilitar a política de acesso condicional executando os passos abaixo:
1 – Na opção Enable policy selecione On.
2 – Clique em Create.

Primeiro acesso ao portal do Azure sem o controle de sessão

Vamos acessar o portal do Azure através do endereço https://portal.azure.com utilizando uma credencial com privilégios de Global administrator.

O acesso é redirecionado ao portal do AD FS para entrar com a senha.

É solicitado o MFA, neste caso, através de uma notificação de aprovação ao aplicativo Microsoft authenticator.

Com a etapa do MFA executada com sucesso, é solicitada a confirmação do “Stay signed in?” que utiliza cookies para armazenar informações de acesso do usuário e evita novas solicitações de credenciais. Mais informações sobre essa funcionalidade, acesse este link.

Vamos clicar em Yes.

Podemos ver que o acesso foi concedido ao portal do Azure.

Vamos validar a experiência do usuário ao acessar pela segunda vez o portal do Azure com as informações de acesso gravadas no cookie.

Segundo acesso com keep me signed in

Com as informações de acesso nos cookies, ao acessar a URL https://portal.azure.com, o acesso ao portal é imediatamente concedido sem a necessidade de apresentar credenciais ou um segundo fator de autenticação.

Vamos agora desabilitar o “keep me signed in” através do controle de sessão na política de acesso condicional. Essa configuração força que o usuário afetado pela política tenha que apresentar as credenciais e o segundo fator de autenticação sempre que acessar uma aplicação no Azure.

Ativando o controle de sessão na conditional access policy

Vamos acessar a política “CA – No session persisten session” criada no início desse artigo.

Selecione no menu Access controls a opção Session.

Vamos desabilitar as sessões persistentes de browser executando os seguintes passos:
1 – Marque a opção Persistent browser session.
2 – Selecione a opção Never persistent.

Obs: O controle de sessão requer que todos os aplicativos na nuvem sejam selecionados no menu Cloud Apps or actions.

Clique em Select e em Save.

Vamos agora executar o mesmo teste de acesso ao portal do Azure, agora com o controle de sessão habilitado.

Primeiro acesso ao portal do Azure com o controle de sessão

Vamos acessar novamente o portal do Azure através do endereço https://portal.azure.com utilizando uma credencial com privilégios de Global administrator.

O acesso é redirecionado para o portal do Ad FS para o usuário entrar com a senha.

É solicitado novamente o MFA através de uma notificação de aprovação ao aplicativo Microsoft authenticator.

Dessa vez, a opção de “keep me signed in” não é apresentada ao usuário e o acesso é concedido ao portal do Azure.

Vamos agora realizar o segundo acesso ao portal do Azure.

Segundo acesso ao portal do Azure sem o keep me signed in

Ao acessar a URL https://portal.azure.com, é apresentada a última credencial que fez o acesso à esta aplicação.

Ao clicar na credencial, o usuário é redirecionado ao portal do AD FS para entrar com a senha.

O MFA é solicitado como se fosse o primeiro acesso ao portal.

Com a validação MFA concluída, o acesso é concedido ao usuário no portal do Azure.

Resumo

No artigo de hoje, explicamos o que é e para que serve opção Persistent browser session (Preview) disponível nas políticas de acesso condicional do Azure. Demonstramos a diferença de experiência de acesso de um administrador ao portal do Azure com o controle de sessão persistente desativada e ativada usando uma política de acesso condicional. Para mais informações sobre essa funcionalidade, acesse esse link.

Espero que este conteúdo tenha contribuído com o enriquecimento do conhecimento de vocês em Azure AD.

Gostaram do post? Curtam e compartilhem. 🙂

Tem alguma sugestão ou observação, comente.

[ ]’s

Ulysses Neves

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Recent Posts

  • Microsoft Authenticator Will Block Jailbroken Devices in 2026 — What You Need to Know 17 de March de 2026
  • Enhancing Azure role activation security with FIDO2/Passkeys 23 de September de 2024
  • Microsoft Entra ID CAP | Enforcing WHfB using Authentication Strength 21 de April de 2024
  • Troubleshooting Error Code ‘0x000005e’ in WHfB: PIN Authentication Woes 11 de February de 2024
  • WHfB: Fixing Windows Hello for Business error ‘LogoncertTemplateReady: NO (StateNoTemplate)’ 29 de December de 2023

Archives

  • March 2026
  • September 2024
  • April 2024
  • February 2024
  • December 2023
  • September 2023
  • July 2023
  • June 2023
  • May 2023
  • April 2023
  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • August 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019

Tags

#aaddownleveldevice #aadhybridjoin #adfs #adfsonsql #azuread #azureauth #azureCA #azuredevice #azurehybridjoin #azuremfa #azuresecurity #capolicy #cloudkerberostrust #conditionalaccess #conditionalaccesspolicy #deviceregistration #gmsaaccount #gopasswordless #hybridaadjoin #mfaserver #msadfs #msazure #msidentity #namedlocation #sslcertificatevalidation #tshootadfs #tshoothybridjoin #tshootwaptrust #waptrust #WHFBcerttrust #whfbdeployment #WHfBhybridsetup #widdatabase adconnect authenticationcontext authenticationstrength az500 azuread azuremfa azurepim azuresecurity cloudsecurity microsoft365 msazure WHfB
©2026 Ulysses Neves | Design: Newspaperly WordPress Theme
Ulysses Neves
Gerenciar Consentimento de Cookies
Para fornecer as melhores experiências, usamos tecnologias como cookies para armazenar e/ou acessar informações do dispositivo. O consentimento para essas tecnologias nos permitirá processar dados como comportamento de navegação ou IDs exclusivos neste site. Não consentir ou retirar o consentimento pode afetar negativamente certos recursos e funções.
Funcional Always active
O armazenamento ou acesso técnico é estritamente necessário para a finalidade legítima de permitir a utilização de um serviço específico explicitamente solicitado pelo assinante ou utilizador, ou com a finalidade exclusiva de efetuar a transmissão de uma comunicação através de uma rede de comunicações eletrónicas.
Preferências
O armazenamento ou acesso técnico é necessário para o propósito legítimo de armazenar preferências que não são solicitadas pelo assinante ou usuário.
Estatísticas
O armazenamento ou acesso técnico que é usado exclusivamente para fins estatísticos. O armazenamento técnico ou acesso que é usado exclusivamente para fins estatísticos anônimos. Sem uma intimação, conformidade voluntária por parte de seu provedor de serviços de Internet ou registros adicionais de terceiros, as informações armazenadas ou recuperadas apenas para esse fim geralmente não podem ser usadas para identificá-lo.
Marketing
O armazenamento ou acesso técnico é necessário para criar perfis de usuário para enviar publicidade ou para rastrear o usuário em um site ou em vários sites para fins de marketing semelhantes.
  • Manage options
  • Manage services
  • Manage {vendor_count} vendors
  • Read more about these purposes
Ver preferências
  • {title}
  • {title}
  • {title}