Darei uma olhada rápida nesta comunidade do reddit e posso ver que esta é uma questão conhecida.
Mas, tenho tido sucesso esporádico e inconsistente com nossa política para forçar o Requer MFA no VPN Global Protect da Palo Alto.
Percebi que funciona aleatoriamente para nosso grupo de teste de usuários, onde me solicitou quando trabalhei de casa, 2 dias seguidos, depois parou. E meu gerente foi ao nosso escritório de Londres, foi solicitado, depois voltou para casa e não foi solicitado no dia seguinte.
Configuramos para que a Frequência de Login seja de 1 dia, também testei exigir MFA a cada 4 horas. Mas sem sucesso.
Li que há várias variáveis a serem consideradas, como:
PRTs (Tokens de Atualização Primária)
Cache de entrada de login SAML SSO
Cookies de autenticação no Gateway PA
Alguém teve sucesso consistente na configuração? Se sim, qual é sua configuração?
Temos nossa política de CA definida para um máximo de duração de sessão de 1 hora. Funciona exatamente como esperado… no entanto, você precisa garantir que não haja políticas de CA sobrepostas. por exemplo: se você tiver uma política de CA que diz sem limite de sessão e outra que é definida para uma hora, garanta que você exclua o aplicativo GlobalProtect da política mais permissiva para que ela funcione corretamente. Sei que deve aplicar a mais restritiva, mas na prática, já vi coisas estranhas acontecerem.
Windows Hello for Business pode ser uma razão pela qual o MFA não é solicitado explicitamente
Na verdade, comecei a analisar especificamente o WHFB por essa razão.
Para dispositivos entra ou híbridos, fazer login no Windows usando WHFB (seja PIN/face/biometria/fido2) já conta como uma autenticação MFA bem-sucedida do Entra e, portanto, você não é solicitado a fazer login no GlobalProtect.
Isso basicamente resolve problemas com múltiplos prompts do Entra no login (ex: Teams e GP ambos iniciando automaticamente no login, qual vence a corrida do prompt MFA?).
Então, pude ver nos logs de login do meu gerente que a Notificação do Aplicativo Móvel foi bem-sucedida. E que nossos Resultados da Política CA para Global Protect são de Sucesso.
Alguns outros pontos principais na Informação Básica são:
Tipo de emissor do token: Microsoft Entra ID
Tipo de token de entrada: Token de atualização primária
Aplicação: Palo Alto Networks - GlobalProtect
O que estou confuso é que as pessoas têm discutido online que PRTs, Dispositivos Aderidos ao Azure AD, Windows Hello, etc., podem todos influenciar nas reivindicações de MFA existentes e afetar os logins de Acesso Condicional.
Meu gerente garantiu esta manhã, no entanto, que não fez login em nada (se solicitado) e apenas fez login no Global Protect.
Parece que, antes de eu ingressar recentemente nesta organização, os Cookies de autenticação tinham sido configurados para 8 horas pelos Consultores que usamos.
A citação deles é:
A autenticação por cookie está configurada para uma TTL de 8h tanto no portal quanto no gateway.
Esta é uma configuração bastante padrão para evitar solicitações repetitivas (irritantes) de credenciais em caso de conexão instável ou intermitente (mais frequente com WiFi)
Na minha opinião, queremos que nossos usuários Tier Zero sejam solicitados para MFA com maior frequência, e não tenham uma sessão de cookie em cache por 8 horas após a autenticação.
Uma coisa que me confunde é que, se essa sessão de cookie de 8 horas estiver correta, ela deveria solicitar a cada manhã que os usuários se reautenticarem, certo? Mas não parece fazer isso, e geralmente fazem login automaticamente.
Além disso, você configurou isso com SAML SSO? Se sim, certamente isso não deveria funcionar em dispositivos AAD ou AAD híbridos, devido aos tokens PRT e Claims de MFA.
Somos híbridos. Demorei muito para fazê-lo funcionar, mas uma vez que projetamos a política CAP para o aplicativo GP Apenas com um tempo limite de 1 hora, funciona perfeitamente.