Aviso de autenticação de cenários

Vários cenários avisam aos usuários para autentiquem com o Secure Hub digitando suas credenciais nos respectivos dispositivos.

Os cenários se alteram dependendo destes fatores:

  • Sua política de aplicativo MDX e a configuração da Propriedade do Cliente nas configurações do console Endpoint Management.
  • Se a autenticação ocorrer offline ou precisar ser uma autenticação online (o dispositivo precisa de uma conexão de rede com o Endpoint Management).

Além disso, o tipo das credenciais que os usuários digitam, como senha do Active Directory, o PIN da Citrix ou código secreto, senha de uso único, autenticação por impressão digital (conhecida como Touch ID no iOS), também muda com base no tipo de autenticação e na frequência de autenticação de que você precisa.

Vamos começar com os cenários que resultam em um aviso para autenticação.

  • Reinicialização do dispositivo: Quando os usuários reiniciam seus dispositivos, eles devem se autenticar novamente com o Secure Hub.

  • Inatividade offline (tempo limite): Com a política de MDX Código secreto de aplicativo ativada, que é ativada por padrão, a propriedade cliente do Endpoint Management chamada Timer de Inatividade entra em ação. O Timer de Inatividade limita o período em que pode não haver nenhuma atividade dos aplicativos que usam o contêiner seguro.

Quando o tempo do Timer de Inatividade se esgota, os usuários devem reautenticar ao contêiner seguro no dispositivo. Se, por exemplo, os usuários pousarem seus dispositivos e se afastarem, se o tempo do Timer de Inatividade expirar, nenhuma outra pessoa poderá pegar o dispositivo e ter acesso a dados confidenciais presentes no contêiner. A propriedade do Timer de Inatividade pode ser configurada no console Endpoint Management. O padrão é 15 minutos. A combinação do código secreto do aplicativo definido como ON e a propriedade cliente do Timer de Inatividade é responsável por provavelmente o cenário mais comum de aviso para autenticação.

  • Logoff do Secure Hub. Quando os usuários fazem logoff do Secure Hub, eles precisam autenticar novamente na próxima vez que acessam o Secure Hub ou qualquer aplicativo MDX, quando o aplicativo requer um código secreto, conforme determinado pela política de Código secreto do aplicativo de MDX e o status do Timer de Inatividade.

  • Período máximo offline. Este cenário é específico para aplicativos porque é controlado por uma política de MDX por aplicativo. A política Período máximo offline de MDX tem uma configuração padrão de 3 dias. Se o período de tempo para que um aplicativo seja executado sem autenticação online com o Secure Hub se esgotar, é necessário um check-in com o Endpoint Management para confirmar o direito do aplicativo e para atualizar as políticas. Quando esse check-in ocorre, o aplicativo faz com que o Secure Hub exija uma autenticação online. Os usuários devem reautenticar para que possam ter acesso ao aplicativo MDX.

Observe que a relação entre o período máximo offline e a política de período de sondagem ativa de MDX:

  • O período de sondagem ativa é o período durante o qual os aplicativos fazem check-in com o Endpoint Management para realizar ações de segurança, como bloqueio de aplicativo e apagamento de aplicativo. Além disso, o aplicativo também verifica se há atualizações de políticas de aplicativo.
  • Depois que uma verificação bem-sucedida de políticas por meio da política Active poll period, o timer do Maximum offline period é zerado e começa a fazer uma nova contagem regressiva.

Os dois check-ins com o Endpoint Management, relativo a Active poll period e Maximum offline period expiry, requerem um token válido de NetScaler Gateway no dispositivo. Se o dispositivo tiver um token válido do NetScaler Gateway, o aplicativo recupera novas políticas do Endpoint Management sem interrupções para os usuários. Se o aplicativo precisar de um NetScaler Gateway, ocorre uma passagem para o Secure Hub e os usuários veem um aviso para autenticar no Secure Hub.

Em dispositivos Android, as telas de atividade do Secure Hub se abrem diretamente sobre a tela do aplicativo atual. Em dispositivos iOS, no entanto, o Secure Hub deve vir para o primeiro plano, o que temporariamente muda a posição do aplicativo atual.

Após os usuários inserirem suas credenciais, o Secure Hub passa para o aplicativo original. Se, nesse caso, você permitir credenciais em cache do Active Directory ou tiver um certificado de cliente configurado, os usuários podem inserir um PIN, senha ou autenticação de impressões digitais. Caso contrário, os usuários devem fornecer suas credenciais do Active Directory completas.

O token do NetScaler pode tornar-se inválido por causa de inatividade na sessão do NetScaler Gateway ou a imposição de um tempo limite de sessão, como comentado na seguinte lista de políticas de Netscaler Gateway. Quando os usuários fazem logon no Secure Hub novamente, eles podem continuar a executar o aplicativo.

  • Políticas de sessão do NetScaler Gateway: Duas políticas do NetScaler Gateway também têm influência quando os usuários são avisados para autenticar. Nesses casos, eles autenticam para criar uma sessão online com o Netscaler para conexão com o Endpoint Management.

    • Tempo limite da sessão: A sessão do NetScaler para o Endpoint Management é desconectada se não ocorrer nenhuma atividade de rede por um determinado período de tempo. O padrão é 30 minutos. No entanto, se você usar o Assistente de NetScaler Gateway para configurar a política, o padrão é 1440 minutos. Os usuários versão um aviso para autenticação para reconectar à sua rede corporativa.
    • Tempo limite forçado: Se o valor for Ativado, a sessão do NetScaler para o Endpoint Management é desconectada depois que o período de tempo limite tiver se esgotado. O tempo limite imposto torna obrigatória a reautenticação depois de um determinado período de tempo. Os usuários versão um aviso para autenticação para reconectar à sua rede corporativa no próximo uso. O padrão é Off. No entanto, se você usar o Assistente de NetScaler Gateway para configurar a política, o padrão é 1440 minutos.

Tipos de Credenciais

A seção anterior tratou de quando os usuários são solicitados a autenticar. Esta seção trata dos tipos de credenciais que eles devem inserir. É necessário efetuar autenticação por meio de vários métodos para obter acesso a dados criptografados no dispositivo. Para desbloquear inicialmente o dispositivo, você deve desbloquear o contêiner primário. Após isso ocorrer. e o contêiner estar protegido, para obter acesso, você deve desbloquear um contêiner secundário.

Nota:

Quando o artigo se refere a um aplicativo gerenciado, o termo se refere a um aplicativo preparado com o MDX Toolkit, no qual você deixou a política de senha de aplicativo MDX habilitada por padrão e aproveita a propriedade de Timer de Inatividade do cliente.

As circunstâncias que determinam o tipo de credencial são os seguintes:

  • Desbloqueio de contêiner primário: Uma senha do Active Directory, PIN da Citrix ou código secreto, senha de uso único, Touch ID ou impressão digital são necessárias para desbloquear o contêiner primário.
    • No iOS, quando os usuários abrem o Secure Hub ou um aplicativo gerenciado pela primeira vez após o aplicativo estar instalado no dispositivo.
    • No iOS, quando os usuários reiniciam um dispositivo e, em seguida, abrem o Secure Hub.
    • No Android, quando os usuários abrem um aplicativo gerenciado se o Secure Hub não estiver em execução.
    • No Android, quando os usuários reiniciam o Secure Hub por qualquer motivo, incluindo uma reinicialização do dispositivo.
  • Desbloqueio de contêiner secundário: Autenticação com impressão digital (se configurada), ou um PIN da Citrix ou código secreto ou credenciais do Active Directory para desbloquear o contêiner secundário.
    • Quando os usuários abrem um aplicativo depois que o timer de inatividade expira.
    • Quando os usuários fazem logoff do Secure Hub e subsequentemente abrem um aplicativo gerenciado.

São necessárias credenciais do Active Directory para a circunstância DE desbloquear o contêiner quando as seguintes condições são verdadeiras:

  • Quando os usuários alteram a senha associada à sua conta corporativa.
  • Quando você não tiver definido propriedades de cliente no console Endpoint Management para ativar o PIN da Citrix: ENABLE_PASSCODE_AUTH e ENABLE_PASSWORD_CACHING.
  • Quando a sessão do NetScaler Gateway termina, o que ocorre sob as seguintes circunstâncias: quando se esgota o tempo limite da sessão ou se esgota o timer imposto da política de tempo limite, se o dispositivo não armazenar em cache as credenciais ou não tiver um certificado cliente.

Quando a autenticação da impressão digital está ativada, os usuários agora podem fazer logon usando uma impressão digital quando for necessária a autenticação offline devido à inatividade de aplicativo. Os usuários ainda têm que inserir um PIN quando fizerem logon ao Secure Hub pela primeira vez ou ao reiniciar o dispositivo. Autenticação de impressão digital é compatível com alguns dispositivos iOS 9 e iOS 10.3 e alguns dispositivos Android. Para obter informações sobre como ativar a autenticação por impressão digital, consulte a configuração ENABLE_TOUCH_ID_AUTH em Propriedades do cliente.

O fluxograma a seguir resume o fluxo de decisão que determina que credenciais um usuário deve fornecer quando é solicitado a se autenticar.

Imagem do fluxograma de credenciais do usuário

Sobre as alternâncias de tela do Secure Hub

Outra situação que deve ser notada é quando é necessária a alternância de um aplicativo para o Secure Hub e depois de volta a um aplicativo. A alternância exibe uma notificação que deve ser confirmada pelos usuários. Não é necessária a autenticação quando isso ocorre. A situação ocorre após ser efetuado um check-in com o Endpoint Management, conforme especificado pelas políticas Maximum offline period e Active poll period e o Endpoint Management detectar políticas atualizadas que precisam ser enviadas para o dispositivo através do Secure Hub.

Aviso de autenticação de cenários