O objetivo deste guia é habilitar e configurar a autenticação integrada com Windows no Fluig.
A autenticação integrada com o Windows possibilita que os usuários que estejam registrados no Active Directory possam acessar o Fluig sem precisar informar manualmente seus dados de acesso através da tela de login, desde que já esteja autenticado no Windows.
Basicamente o processo de autenticação integrada com o Windows funciona da seguinte maneira:
O NTLM é um protocolo de autenticação utilizado em uma rede Windows. Como veremos nos tópicos a seguir, existem uma série de configurações que devemos realizar nos browsers para que eles utilizem este protocolo, e também no script de autenticação remota para que utilize a chamada Autenticação Windows.
Além disso, é importante lembrar que existem limitações com relação a sistemas operacionais não Windows. Linux e Mac não podem utilizar o protocolo NTLM. O efeito nestes sistemas operacionais é que se tentarem o acesso via autenticação integrada, uma caixa de diálogo proveniente do browser pedirá para que o usuário entre com suas credenciais.
Para usufruir da autenticação integrada com o Windows, é necessário habilitar este recurso no Fluig e realizar algumas configurações, como a criação do serviço de autenticação remota. As configurações necessárias para o correto funcionamento da autenticação integrada são apresentadas nos tópicos abaixo.
O primeiro passo para a configuração da autenticação integrada é habilitar ela no Fluig:
|
Para disponibilizar o serviço de autenticação remota é necessário termos um servidor Windows com o Internet Information Services (IIS) habilitado. Siga o passo-a-passo abaixo para habilitar o IIS e configurar o serviço para autenticação remota:
|
É necessário configurar o browser do usuário para que ele utilize autenticação Windows (NTLM) com o script de autenticação remota (remote_auth.asp).
Mesmo que o serviço de autenticação remota tenha sido configurado para utilizar autenticação Windows no IIS, o browser do cliente precisa enviar as credenciais para que o script possa fazer as validações necessárias no Active Directory.
No caso do Internet Explorer e Google Chrome, basta configurar as opções de segurança e autenticação no Internet Explorer e o Google Chrome irá assumir as mesmas configurações.
|
O Firefox deve ser configurado de uma maneira um pouco diferente.
|
Configurar o browser de alguns poucos usuários é uma tarefa simples, porém, o cliente terá um grande problema quando tem milhares de usuários a serem configurados.
Para estes casos, podemos utilizar a estratégia de distribuição das configurações, baseadas na utilização de Group Policies (GPO). Durante o procedimento de autenticação no domínio, pode ser executada uma série de tarefas automáticas, como por exemplo, configurar o navegador do usuário.
O administrador deverá definir a seguinte configuração de GPO:
Configuração do Computador ► Modelos Administrativos ► Componentes do Windows ► Internet Explorer ► Painel de Controle da Internet ► Página Segurança
Após habilitar a Lista de Atribuições de Sites a Zonas, o cliente deverá definir a URL do servidor de autenticação remota como membro da Zona da Intranet.
Desta forma, toda vez que um usuário membro do domínio efetuar o login, as configurações necessárias serão realizadas. Se executada todos os dias, a GPO também deve evitar que um usuário mais avançado desfaça as configurações necessárias para a autenticação remota.
No caso do navegador Mozilla Firefox, não existe maneira direta de configurar o navegador a partir da GPO, porém, existem scripts que realizam esta configuração, e estes scripts podem ser executados a partir de uma GPO.
Existe um script que foi criado para definir estas configurações do Firefox. Ele pode ser obtido com a equipe de serviços do Fluig.
Para executar o script devemos configurar a GPO conforme apresentado abaixo:
Configuração do Usuário ► Configurações do Windows ► Scripts (Logon/Logoff) ► Logon
A autenticação remota pode utilizar uma arquitetura baseada em um único servidor. O problema é que neste cenário, se o script estiver off-line, o usuário não conseguirá autenticar no Fluig. O administrador deverá desabilitar a autenticação integrada no Fluig ou corrigir o que for necessário para que o script fique online.
Existe uma opção, onde podemos criar dois servidores de autenticação remota, o que fornece uma boa redundância do componente. Se um servidor estiver fora do ar, ou se uma aplicação estiver fora, o outro servidor assume a responsabilidade de manter online o serviço de autenticação remota.
Para isso é necessário disponibilizar um Load Balancer que terá a responsabilidade de fazer o redirecionamento, caso um dos dois servidores de autenticação remota esteja off-line.