Serviços de diretório do LDAP suportados no SonicOS

A fim de ser integrado aos serviços de diretório mais comuns utilizados em redes corporativas, o SonicOS oferece suporte à integração com os seguintes esquemas do LDAP:

• Microsoft Active Directory

• RFC2798 InetOrgPerson

• RFC2307 Network Information Service

• Samba SMB

• Novell eDirectory

• Esquemas definidos pelo usuário

O SonicOS oferece suporte para servidores de diretório que executam os seguintes protocolos:

• LDAPv2 (RFC3494)

• LDAPv3 (RFC2251-2256, RFC3377)

• LDAPv3 sobre TLS (RFC2830)

• LDAPv3 com STARTTLS (RFC2830)

• Recomendações do LDAP (RFC2251)

Termos do LDAP

Os termos a seguir são úteis ao trabalhar com o LDAP e suas variantes:

• Esquema – O esquema é o conjunto de regras ou a estrutura que define os tipos de dados que podem ser armazenados em um diretório e como esses dados podem ser armazenados. Os dados são armazenados na forma de “entradas”.

• Active Directory (AD) – O serviço de diretório da Microsoft, muito utilizado com redes com base no Windows. O Microsoft Active Directory é compatível com o LDAP.

• eDirectory – O serviço de diretório da Novell, utilizado para redes com base no Novell NetWare. O Novell eDirectory possui um gateway de LDAP que pode ser utilizado para o gerenciamento.

• Entrada – Os dados armazenados no diretório do LDAP. As entradas são armazenadas em pares de “atributo”/valor (ou nome/valor), nos quais os atributos são definidos por “classes de objeto”. Um exemplo de entrada seria “cn=john”, onde “cn” (nome comum) é o atributo e “john” é o valor.

• Classe de objeto – As classes de objeto definem os tipos de entradas que um diretório do LDAP pode conter. Um exemplo de classe de objeto, conforme utilizada pelo AD, seria “usuário” ou “grupo”.

As Classes do Microsoft Active Directory podem ser visualizadas em
http://msdn.microsoft.com/library/

• Objeto – Na terminologia do LDAP, as entradas de um diretório são denominadas objetos. Para fins da implementação do cliente LDAP do SonicOS, os objetos críticos são objetos de “Usuário” e “Grupo”. As implementações diferentes do LDAP podem fazer referência a essas classes de objeto de diferentes maneiras como, por exemplo, o Active Directory refere-se ao objeto do usuário como “usuário” e ao objeto de grupo como “grupo”, enquanto o RFC2798 refere-se ao objeto de usuário como “inetOrgPerson” e ao objeto de grupo como “groupOfNames”.

• Atributo – Um item de dado armazenado em um objeto de um diretório do LDAP. O objeto pode ter atributos obrigatórios ou permitidos. Por exemplo, o atributo “dc” é um atributo obrigatório do objeto “dcObject” (componente de domínio).

• dn – Um “nome distinto”, que é um nome globalmente exclusivo para um usuário ou outro objeto. Ele é composto por um número de componentes, geralmente começando com um componente de nome comum (cn) e terminando com um domínio especificado como componentes de dois ou mais domínios (dc). Por exemplo, “cn=john, cn=usuários, dc=domínio, dc=com”

• cn – O atributo “nome comum” é um componente obrigatório de muitas classes de objeto por todo o LDAP.

• ou – O atributo “unidade organizacional” é um componente obrigatório da maioria das implementações do esquema LDAP.

• dc – O atributo “componente de domínio” é geralmente encontrado na raiz de um nome distinto e é geralmente um atributo obrigatório.

• TLS – A Transport Layer Security é a versão padronizada do IETF da SSL (Secure Sockets Layer). O TLS 1.0 é o sucessor do SSL 3.0.

Visão geral do Login único (SSO)

Esta seção fornece uma apresentação do recurso Login Único do SonicOS. Esta seção contém as seguintes subseções:

• Definição de Login único

• Benefícios do SSO do SonicWALL

• Plataformas e padrões suportados

• Como funciona o Login Único?

• Como funciona o agente SSO?

• Como funciona o Agente de serviços de terminal?

• Como funciona a Autenticação de NTLM do navegador?

• Como funciona a Contabilização RADIUS para o Login Único?

Definição de Login único

O Login único (SSO) é um mecanismo de autenticação transparente do usuário que fornece o acesso privilegiado a vários recursos da rede com um login de um único domínio para uma estação de trabalho ou por meio de um servidor do Windows Terminal Services ou Citrix.

Os dispositivos de segurança de rede Dell SonicWALL oferecem a funcionalidade SSO com o uso do Agente de Login Único (Agente SSO) e Agente de serviços de terminal (TSA) do SonicWALL para identificar as atividades do usuário. O Agente de Login Único (Agente SSO) identifica os usuários com base no endereço IP da estação de trabalho. O TSA identifica os usuários por meio de uma combinação de endereço IP do servidor, nome do usuário e domínio.

O SSO do SonicWALL também está disponível para os usuários do Linux e Mac quando utilizado com o Samba. Além disso, a autenticação de NTLM do navegador permite que o SSO do SonicWALL autentique os usuários que enviam o tráfego HTTP, sem a participação do Agente SSO ou do Samba.

O SSO do SonicWALL está configurado na página Usuários > Configurações da interface de gerenciamento do SonicOS. O SSO é separado das configurações do Método de autenticação para login, que podem ser utilizadas ao mesmo tempo para a autenticação de usuários VPN/L2TP clientes ou administrativos.

Com base em dados do SSO do SonicWALL Agent ou TSA, o firewall consulta o LDAP ou o banco de dados local para determinar a associação de grupo. As associações são verificadas opcionalmente por políticas de firewall para controlar os usuários que terão acesso e podem ser utilizadas na seleção de políticas de Filtragem de conteúdo e Controle de aplicativos para controlar o conteúdo que lhes é permitido acessar. Os nomes de usuário adquiridos por meio do SSO são relatados nos registros de tráfego e eventos dos usuários e no Monitoramento do AppFlow.

O temporizador de inatividade configurado é aplicado com o SSO, mas o limite da sessão não, embora os usuários que estejam desconectados sejam automática e imperceptivelmente conectados novamente ao enviarem mais tráfego.

Os usuários conectados a uma estação de trabalho ou a um servidor do Terminal Services/Citrix diretamente, mas que não estejam conectados ao domínio não serão autenticados, a menos que enviem o tráfego HTTP e que a autenticação NTML do navegador esteja habilitada (embora, opcionalmente, eles possam ser autenticados para o acesso limitado). Para os usuários que não estão autenticados pelo SSO do SonicWALL, será exibida uma tela indicando que um login manual ao dispositivo é necessário para mais uma etapa da autenticação.

Os usuários que forem identificados, mas que não possuam associações a grupos obrigatórios pelas regras de política configuradas serão redirecionados para a página de Acesso barrado.

Benefícios do SSO do SonicWALL

O SSO do SonicWALL é um recurso confiável e que economiza tempo que utiliza um login único para oferecer acesso a vários recursos da rede com base na correspondência da política e nas associações a grupos configuradas pelo administrador. O SSO do SonicWALL é transparente para os usuários finais e requer uma configuração mínima do administrador.

Ao determinar automaticamente quando os usuários estão conectados ou desconectados com base no tráfego do endereço IP da estação de trabalho ou, para o Terminal Services ou Citrix, no tráfego de um determinado usuário no endereço IP do servidor, o SSO do SonicWALL é seguro e sem intervenção. A autenticação SSO é projetada para operar com qualquer agente externo que possa retornar a identidade de um usuário em uma estação de trabalho ou de um endereço IP do servidor Terminal Services/Citrix usando um protocolo compatível com o SonicWALL Directory Connector.

O SSO do SonicWALL funciona para todos os serviços do firewall que utilizem a autenticação ao nível do usuário, incluindo o Content Filtering Service (CFS), Regras de acesso do firewall, herança e associação de grupo e listas de inclusão/exclusão dos serviços de segurança (IPS, GAV e Anti-Spyware).

Outros benefícios do SSO do SonicWALL incluem:

• Facilidade de uso – Os usuários só precisam conectar-se uma única vez para obter acesso automático a vários recursos.

• Experiência de usuário aprimorada – As credenciais de domínio do Windows podem ser utilizadas para autenticar um usuário para qualquer tipo de tráfego sem precisar efetuar login no dispositivo com uso de um navegador da web.

• Transparência para os usuários – Os usuários não precisam reinserir o nome de usuário e a senha para a autenticação.

• Comunicação segura – Criptografia de chave compartilhada para a proteção da transmissão de dados.

• O SSO do SonicWALL Agent pode ser instalado em qualquer servidor do Windows na LAN e o TSA pode ser instalado em qualquer servidor de terminal.

• Vários Agentes SSO – Até 8 agentes são suportados para fornecer a capacidade para instalações de grande porte

• Vários TSAs – Vários agentes de serviços de terminal (um por servidor de terminal) são suportados. O número depende do modelo do dispositivo de segurança de rede Dell SonicWALL e varia de 8 a 512.

• O mecanismo de login funciona com qualquer protocolo, e não somente HTTP.

• Autenticação de NTLM do navegador – O SSO do SonicWALL pode autenticar os usuários que enviam o tráfego HTTP, sem a participação do Agente SSO.

• Suporte para Mac e Linux – Com Samba 3.5 e superior, o SSO do SonicWALL é suportado para os usuários do Linux e Mac.

• Imposição por zona – O SSO do SonicWALL pode ser acionado para o tráfego de qualquer zona, mesmo quando não for automaticamente iniciado pelas regras de acesso do firewall ou pelas políticas dos serviços de segurança, oferecendo a identificação do usuário no registro em log dos eventos ou no Monitoramento do AppFlow.

Plataformas e padrões suportados

O Agente SSO é compatível com todas as versões do SonicOS que oferecem suporte ao SSO do SonicWALL. Existe suporte para o TSA.

O recurso de SSO oferece suporte a protocolos do LDAP e do banco de dados local. O SSO do SonicWALL oferece suporte ao SonicWALL Directory Connector. Para que todos os recursos do SSO do SonicWALL funcionem corretamente, o SonicOS deve ser utilizado com o Directory Connector 3.1.7 ou superior.

Para usar o SSO do SonicWALL com o Windows Terminal Services ou Citrix, é necessário o SonicOS 6.0 ou superior, e o SonicWALL TSA deve estar instalado no servidor.

Para usar o SSO do SonicWALL com a autenticação de NTLM do navegador, é necessário o SonicOS 6.0 ou superior. O agente SSO não é necessário para a autenticação de NTLM do navegador.

Exceto se usar somente a autenticação de NTLM do navegador, usar o SSO do SonicWALL requer que o agente SSO esteja instalado em um servidor em seu domínio do Windows que possa chegar aos clientes e que possa ser acessado a partir do dispositivo, diretamente ou por meio de um caminho VPN, e/ou requer que o TSA esteja instalado em quaisquer servidores de terminal no domínio.

Os seguintes requisitos devem ser atendidos para que o agente SSO seja executado:

• A porta UDP 2258 (por padrão) deve estar aberta; o firewall utiliza a porta UDP 2258 por padrão para se comunicar com o agente SSO da SonicWALL; se uma porta personalizada for configurada em vez da 2258, esse requisito será aplicável à porta personalizada

• Servidor do Windows, com o service pack mais recente

• .NET Framework 2.0

• Net API ou WMI

Observação Os PCs com Linux e Mac não oferecem suporte às solicitações de rede do Windows que são utilizadas pelo agente SSO e, portanto, requerem o Samba 3.5 ou uma versão mais recente para funcionar com o SSO do SonicWALL. Sem o Samba, os usuários do Linux e Mac podem continuar a obter acesso, mas será necessário efetuar login para obtê-lo. Eles podem ser redirecionados para o prompt de login se as regras da política forem definidas para exigir a autenticação. Para obter mais informações, consulte Acomodando usuários do Mac e Linux.

Os seguintes requisitos devem ser atendidos para que o TSA seja executado:

• A porta UDP 2259 (por padrão) deve estar aberta em todos os servidores do terminal nos quais o TSA esteja instalado; o firewall utiliza a porta UDP 2259 por padrão para se comunicar com o TSA da SonicWALL; se uma porta personalizada for configurada em vez da porta 2259, esse requisito será aplicável à porta personalizada

• Servidor do Windows, com o service pack mais recente

• Windows Terminal Services ou Citrix instalado no(s) sistema(s) do Windows Terminal Server

Como funciona o Login Único?

O SSO do SonicWALL requer uma configuração mínima do administrador e é transparente para o usuário.

O SSO é acionado nas seguintes situações:

• Se as regras de acesso do firewall que requerem a autenticação de usuário sejam aplicáveis ao tráfego que não seja proveniente da zona de WAN

• Quando nenhum grupo de usuário esteja especificado nas regras de acesso, mas qualquer das seguintes condições ocorrer, o SSO é acionado para todo o tráfego na zona (obs.: não somente para o tráfego sujeito a essas condições):

– O CFS estiver habilitado na zona e várias políticas do CFS estejam definidos

– O IPS estiver habilitado na zona e se houver políticas do IPS que exijam autenticação

– O Anti-Spyware estiver habilitado na zona e se houver políticas do Anti-Spyware que exijam autenticação

– Políticas de Controle de aplicativos que exijam autenticação sejam aplicadas à zona de origem

– A imposição por zona do SSO esteja definida para a zona

A tabela de usuário do SSO também é utilizada para a identificação de usuário e grupo obrigatória pelos serviços de segurança, incluindo a Filtragem de conteúdo, Prevenção contra invasões, Anti-Spyware e Controle de aplicativos.

Autenticação do SSO do SonicWALL usando o Agente SSO

Para os usuários do Windows em estações de trabalho individuais, o Agente SSO (na estação de trabalho do SSO) manipula as solicitações de autenticação do firewall. Existem seis etapas envolvidas na autenticação do SSO do SonicWALL usando o agente SSO, conforme ilustrado na figura a seguir.

O processo de autenticação do SSO é iniciado quando o tráfego do usuário passa por um firewall. Por exemplo, quando um usuário acessa a Internet. Os pacotes enviados são temporariamente bloqueados e salvos enquanto o firewall envia uma solicitação de “Nome de usuário” e endereço IP da estação de trabalho ao agente de autorização que executa o Agente SSO (estação de trabalho do SSO).

O agente de autorização que executa o Agente SSO fornece ao firewall o nome do usuário atualmente conectado à estação de trabalho. Uma entrada na Tabela de IP do usuário é criada para o usuário conectado, de forma similar ao RADIUS e LDAP.

Autenticação do SSO do SonicWALL usando o Agente de serviços de terminal

Para os usuários conectados de um servidor do Terminal Services ou Citrix, o TSA assume o lugar do agente SSO no processo de autenticação. O processo é diferente de várias maneiras:

• O TSA é executado no mesmo servidor que o do usuário conectado e inclui o nome do usuário e o domínio junto com o endereço IP de servidor na notificação inicial ao firewall.

• Os usuários são identificados pelo número de um usuário, bem como pelo endereço IP (para os usuários que não utilizam o Terminal Services, como existe somente um usuário em qualquer endereço IP, não é utilizado nenhum número de usuário). Um número de usuário diferente de zero é exibido na interface de gerenciamento do SonicOS usando o formato “x.x.x.x user n”, onde x.x.x.x é o endereço IP do servidor e n é o número do usuário.

• Como o TSA envia uma notificação de encerramento para o SonicOS quando o usuário se desconectar, não ocorre nenhuma pesquisa.

Depois que um usuário tiver sido identificado, o firewall consulta o LDAP ou um banco de dados local (com base na configuração do administrador) para localizar as associações a grupos do usuário, faz a correspondência das associações com a política e concede ou restringe o acesso ao usuário, em conformidade. Após a conclusão bem-sucedida da sequência de login, os pacotes salvos são enviados. Se os pacotes forem recebidos do mesmo endereço de origem antes que a sequência seja concluída, apenas o pacote mais recente será salvo.

Os nomes de usuário são retornados do agente de autorização que executa o agente SSO no formato <domínio>/<nome de usuário>. Para os grupos dos usuários configurados localmente, o nome de usuário pode ser configurado como o nome completo retornado do agente de autorização que executa o agente SSO (que configura a correspondência dos nomes do banco de dados do usuário local do firewall) ou um nome de usuário simples com o componente de domínio removido (padrão).

Para o protocolo do LDAP, o formato <domínio>/<nome de usuário> é convertido em um nome distinto no LDAP, por meio da criação de uma pesquisa no LDAP para um objeto da classe “domínio” com um atributo “dc” (componente de domínio) que corresponda ao nome de domínio. Se algum for encontrado, então seu nome distinto será utilizado como a subárvore do diretório para a pesquisa do objeto do usuário. Por exemplo, se o nome de usuário for retornado como “SV/bob”, então a pesquisa de um objeto com “objectClass=domínio” e “dc=SV” será realizada. Se ele retornar um objeto com o nome distinto “dc=sv,dc=us,dc=sonicwall,dc=com”, então uma pesquisa na subárvore desse diretório será criada para (no caso do Active Directory) um objeto com “objectClass=usuário” e “sAMAccountName=bob”. Se nenhum objeto de domínio for encontrado, então a pesquisa pelo objeto do usuário será realizada a partir da parte superior da árvore do diretório.

Depois que um objeto de domínio for encontrado, as informações são salvas para evitar uma pesquisa pelo mesmo objeto. Em caso de falha em uma tentativa de localizar um usuário em um domínio salvo, as informações do domínio salvas serão excluídas e outra pesquisa pelo objeto de domínio será realizada.

O logout do usuário é manipulado de forma ligeiramente diferente pelo SSO do SonicWALL, utilizando o Agente SSO em comparação com o SSO com o TSA. O firewall pesquisa o agente de autorização que executa o agente SSO a uma taxa configurável para determinar o momento em que um usuário foi desconectado. Após o logout do usuário, o agente de autenticação que executa o Agente SSO envia uma resposta de Usuário Desconectado ao firewall, confirmando que o usuário foi desconectado e encerrou a sessão do SSO. Em vez de receber uma pesquisa pelo firewall, o próprio TSA monitora o servidor do Terminal Services/Citrix para obter os eventos de logout e notifica o firewall conforme eles ocorrem, encerrando a sessão do SSO. Para os dois agentes, os temporizadores de inatividade configuráveis podem ser definidos, e para o Agente SSO, a taxa de pesquisa da solicitação do nome de usuário pode ser configurada (definir um tempo de pesquisa curto para a detecção rápida de logouts ou um tempo de pesquisa mais longo para uma menor sobrecarga do sistema).

Autenticação do SSO do SonicWALL usando a autenticação de NTLM do navegador

Para os usuários que utilizam os navegadores com base no Mozilla (incluindo o Internet Explorer, Firefox, Chrome e Safari) o firewall oferece suporte à identificação deles por meio da autenticação de NTLM (Gerenciador de LAN NT). O NTLM faz parte de um conjunto de autenticações para navegador conhecido como “Segurança integrada do Windows” e é suportado por todos os navegadores com base no Mozilla. Ele permite uma solicitação de autenticação direta a partir do dispositivo para o navegador sem a participação do agente SSO. O NTLM é geralmente utilizado quando um controlador de domínio não está disponível, nos casos em que o usuário está autenticando remotamente pela Internet.

A Autenticação de NTLM está atualmente disponível para HTTP; ela não está disponível para uso com o tráfego HTTPS.

A autenticação de NTLM para navegador pode ser utilizada antes ou depois que o agente SSO realizar uma tentativa de adquirir as informações do usuário. Por exemplo, se o agente SSO for utilizado primeiro e não for capaz de identificar o usuário, então se o tráfego for HTTP, o NTLM será utilizado.

Para usar este método com os clientes do Mac ou Linux, bem como os clientes do Windows, também é possível habilitar o SSO para investigar o cliente em relação ao NetAPI ou WMI, dependendo de qual estiver configurado para o agente SSO. Isso faz com que o firewall investigue uma resposta na porta NetAPI/WMI antes de solicitar que o Agente SSO identifique um usuário. Se nenhuma resposta ocorrer, nesses dispositivos causarão uma falha no SSO imediatamente. Para um PC com Windows, a investigação geralmente funcionará (a menos que seja bloqueada por um firewall pessoal) e o Agente SSO será utilizado. Para um PC com Linux/Mac (supondo que ele não esteja configurado para executar o servidor Samba), haverá uma falha na investigação, o agente SSO será ignorado e a autenticação de NTLM será utilizada quando o tráfego HTTP for enviado.

Como o NTLM não pode identificar o usuário até que ele utilize o HTTP, qualquer tráfego enviado antes disso será tratado como não identificado. A política padrão do CFS será aplicada e qualquer regra que exigir usuários autenticados não permitirá a passagem do tráfego.

Se o NTLM estiver configurado para ser utilizado antes do agente SSO, então se o tráfego HTTP for recebido primeiro, o usuário será autenticado com o NTLM. Se o tráfego fora do HTTP for recebido primeiro, o agente SSO será utilizado para a autenticação.

Como funciona o agente SSO?

O Agente SSO pode ser instalado em qualquer estação de trabalho com um domínio do Windows que possa se comunicar diretamente com clientes e com o firewall, usando o endereço IP ou um caminho, como VPN. Para obter instruções de instalação para o Agente SSO, consulte Instalando o Agente SSO do SonicWALL.

Vários agentes SSO são suportados para acomodar grandes instalações com milhares de usuários. É possível configurar até oito agentes SSO, com cada um deles sendo executado em um PC dedicado de alto desempenho em sua rede. Observe que um agente SSO em um PC rápido pode oferecer suporte para até 2500 usuários.

O Agente SSO comunica-se somente com clientes e com o firewall. O Agente SSO utiliza uma chave compartilhada para a criptografia das mensagens entre o Agente SSO e o firewall.

Observação A chave compartilhada é gerada no Agente SSO e a chave digitada no firewall durante a configuração do SSO deverá corresponder exatamente à chave gerada pelo Agente SSO.

O firewall consulta o Agente SSO pela porta padrão 2258. O agente SSO então comunica-se entre o cliente e o firewall para determinar a ID de usuário do cliente. O agente SSO é pesquisado pelo firewall, a uma taxa configurável pelo administrador, para confirmar de forma contínua o status de login de um usuário.

Registro em log

O agente SSO envia mensagens de eventos de log para o Registro em log de eventos do Windows com base nos níveis de registro em log selecionados pelo administrador.

O firewall também registra eventos específicos do agente SSO em seu registro em log de eventos. Segue abaixo uma lista de mensagens de eventos de log específicas para o agente SSO do firewall:

• Login de usuário negado – não permitido pela regra da política – O usuário foi identificado e não pertence a nenhum grupo de usuário permitido pela política, bloqueando o tráfego do usuário.

• Login de usuário negado – não encontrado localmente – O usuário não foi encontrado localmente e Permitir somente usuários listados localmente é selecionado no firewall.

• Login de usuário negado – tempo limite de agente do agente SSO – As tentativas de entrar em contato com o agente SSO atingiram o tempo limite.

• Login de usuário negado – erro de configuração do agente SSO – O agente SSO não está corretamente configurado para permitir o acesso para este de usuário.

• Login de usuário negado – problema de comunicação com o agente SSO – Há um problema de comunicação com a estação de trabalho que executa o agente SSO.

• Login de usuário negado – falha na resolução de nome do agente do agente SSO – O agente SSO não é capaz de descobrir o nome de usuário.

• agente SSO retornou nome de usuário muito longo – O nome de usuário é muito longo.

• agente SSO retornou nome de domínio muito longo – O nome de domínio é muito longo.

Observação O campo de anotações das mensagens de log específicas para o agente SSO conterá o texto <domínio/nome de usuário>, autenticação pelo agente SSO.

Como funciona o Agente de serviços de terminal?

O TSA pode ser instalado em qualquer máquina com o Windows Server com o Terminal Services ou Citrix instalado. O servidor deve pertencer a um domínio do Windows que possa se comunicar diretamente com o firewall, usando o endereço IP ou um caminho, como VPN.

Para obter instruções de instalação para o TSA, consulte Instalando o Agente de Serviços de Terminal do SonicWALL.

Consulte as seções a seguir para obter informações sobre o TSA:

• Suporte para vários TSAs

• Criptografia de mensagens TSA e uso das IDs de Sessão

• Conexões com sub-redes locais

• Tráfego do usuário fora do domínio do Terminal Server

• Tráfego de um não usuário do Terminal Server

Suporte para vários TSAs

Para acomodar grandes instalações com milhares de usuários, os firewalls são configuráveis para a operação com vários agentes de serviços de terminal (um por servidor de terminal). O número de agentes suportados depende do modelo, conforme mostrado em Tabela 10.

Tabela 1 Suporte para vários TSAs por modelo

Para os dispositivos de segurança de rede Dell SonicWALL da série 9000, um máximo de 32 endereços IP é suportado por servidor de terminal.

Criptografia de mensagens TSA e uso das IDs de Sessão

O TSA utiliza uma chave compartilhada para a criptografia das mensagens entre o TSA e o firewall quando o nome de usuário e o domínio estão contidos na mensagem. A primeira notificação de abertura para um usuário sempre é criptografada, pois o TSA inclui o nome de usuário e o domínio.

Observação A chave compartilhada é criada no TSA e a chave digitada no firewall durante a configuração do SSO deverá corresponder exatamente à chave do TSA.

O TSA inclui uma ID de sessão do usuário em todas as notificações, em vez de incluir o nome de usuário e o domínio a cada momento. Isso é eficiente, seguro e permite que o TSA sincronize-se novamente com os usuários do Terminal Services depois que o agente é reiniciado.

Conexões com sub-redes locais

O TSA descobre de forma dinâmica a topologia da rede com base nas informações retornadas do dispositivo e, depois de descobri-las, ele não enviará as notificações para o dispositivo para conexões posteriores do usuário que não passam pelo dispositivo. Como não há nenhum mecanismo para o TSA esquecer como ele “descobriu” estes destinos locais, o TSA deverá ser reiniciado se uma sub-rede for movida entre as interfaces do dispositivo.

Tráfego do usuário fora do domínio do Terminal Server

O firewall tem a configuração Permitir acesso limitado a usuários fora do domínio para, opcionalmente, oferecer acesso limitado a usuários fora do domínio (usuários conectados em sua máquina local e não no domínio), e isso funciona tanto para os usuários de serviços do terminal como para outros usuários do SSO.

Se sua rede incluir computadores com Windows ou dispositivos sem Windows com firewalls pessoais em execução, marque a caixa ao lado de Investigar usuário sobre e selecione o botão de opção para NetAPI ou WMI, dependendo de qual esteja configurado para o Agente SSO. Isso faz com que o firewall investigue uma resposta na porta NetAPI/WMI antes de solicitar que o Agente SSO identifique um usuário. Se nenhuma resposta ocorrer, nesses dispositivos causarão uma falha no SSO imediatamente. Esses dispositivos não respondem ou podem bloquear as mensagens de rede do Windows utilizadas pelo Agente SSO para identificar um usuário.

Tráfego de um não usuário do Terminal Server

As conexões de um não usuário são abertas a partir das atualizações do Windows e de antivírus do Terminal Server. O TSA pode identificar uma conexão de um serviço conectado como sendo uma conexão de um não usuário e indica isso na notificação ao dispositivo.

Para controlar o tratamento dessas conexões de um não usuário, uma caixa de seleção Permitir tráfego de um não usuário do Terminal Server para ignorar a autenticação de usuário nas regras de acesso está disponível na configuração do TSA no dispositivo. Ao serem selecionadas, essas conexões são permitidas. Se esta caixa de seleção não estiver selecionada, os serviços serão tratados como usuários locais e eles podem obter o acesso ao selecionar a configuração Permitir acesso limitado a usuários fora do domínio e criar contas de usuário no dispositivo com os nomes de serviço correspondentes.

Como funciona a Autenticação de NTLM do navegador?

Consulte as seções a seguir:

• Autenticação de NTLM dos usuários do domínio

• Autenticação de NTLM dos usuários fora do domínio

• Credenciais para a autenticação de NTLM no navegador

Autenticação de NTLM dos usuários do domínio

Para os usuários do domínio, a resposta do NTLM é autenticada por meio do mecanismo MSCHAP no RADIUS. O RADIUS deve estar habilitado no dispositivo.

As configurações a seguir na guia Usuários da configuração do SSO se aplicam ao configurar a autenticação de NTLM:

• Permitir somente usuários listados localmente

• Nomes de usuário simples no banco de dados local

• Mecanismo para configurar associações a grupos do usuário (LDAP ou local):

• As associações a grupos do usuário podem ser definidas localmente pela duplicação de nomes de usuários do LDAP (definidas na configuração do LDAP e aplicáveis quando o mecanismo de associação a grupos do usuário for LDAP)

• Taxa de pesquisa

Autenticação de NTLM dos usuários fora do domínio

Com o NTLM, os usuários fora do domínio podem ser usuários que estejam conectados ao seu PC, e não no domínio, ou podem ser usuários que foram solicitados a inserir um nome de usuário e uma senha e inseriram algo diferente de suas credenciais de domínio. Nos dois casos, o NTLM permite distinções entre esses usuários do domínio.

Se o nome de usuário corresponder a uma conta local de usuário no firewall, então a resposta do NTLM é validada localmente em relação à senha dessa conta. Se tiver êxito, o usuário é registrado e obtém privilégios com base nessa conta. As associações a grupos do usuário estão definidas a partir da conta local, e não do LDAP e (já que a senha foi validada localmente) elas incluem a associação a grupos dos Usuários confiáveis.

Se o nome de usuário não corresponder a uma conta local de usuário, o usuário não será conectado. A opção Permitir acesso limitado a usuários fora do domínio não se aplica aos usuários autenticados via NTLM.

Credenciais para a autenticação de NTLM no navegador

Para a autenticação de NTLM, o navegador utiliza as credenciais do domínio (se o usuário estiver conectado ao domínio), oferecendo assim a funcionalidade total de login único, ou solicita ao usuário para inserir um nome e senha para o website que está sendo acessado (neste caso, o firewall). Diferentes fatores afetam a capacidade do navegador de utilizar as credenciais do domínio quando o usuário está conectado ao domínio. Esses fatores dependem do tipo de navegador que está sendo utilizado:

• Internet Explorer – O Internet Explorer utiliza as credenciais do domínio do usuário e autentica de forma transparente se o website ao qual ele está se conectando no firewall está na intranet local, de acordo com a guia Segurança em Opções de Internet. Isto requer a inclusão do firewall na lista de websites na zona de Intranet Local em Opções de Internet.

Isto pode ser feito por meio da política de grupo do domínio na Lista de atribuição de website à zona em Configuração do computador, Modelos administrativos, Componentes do Windows, Internet Explorer, Painel de controle da Internet e Página de segurança.

• Google Chrome – O Chrome se comporta da mesma maneira que o Internet Explorer, incluindo a exigência de que o firewall seja adicionado à lista de websites na zona de Intranet Local em Opções de Internet.

• Firefox – O Firefox utiliza as credenciais de domínio do usuário e autentica de forma transparente se o website ao qual ele está se conectando no firewall está listado na entrada network.automatic-ntlm-auth.trusted-uris em sua configuração (acessada ao digitar about:config na barra de endereços do Firefox).

• Safari – Embora o Safari ofereça suporte ao NTLM, atualmente ele não oferece suporte um login totalmente transparente usando as credenciais de domínio do usuário.

• Navegadores em plataformas fora do PC – As plataformas fora do PC como o Linux e Mac podem acessar recursos em um domínio do Windows por meio do Samba, mas não têm o conceito de “efetuar login do PC no domínio” como os PCs com Windows. Portanto, os navegadores nessas plataformas não têm acesso às credenciais de domínio do usuário e não é possível usá-las para o NTLM.

Quando um usuário não estiver conectado ao domínio ou o navegador não é capaz de usar suas credenciais de domínio, ele solicitará que um nome e uma senha sejam inseridas ou utilizará as credenciais em cache, caso o usuário tiver optado por salvá-las anteriormente.

Em todos os casos, em caso de falha na autenticação ao utilizar as credenciais de domínio do usuário (que pode ocorrer devido ao fato de o usuário não ter os privilégios necessários para obter acesso), então o navegador solicitará que o usuário insira um nome e uma senha. Isso permite que o usuário insira credenciais diferentes das credenciais de domínio para obter acesso.

Como funciona a Contabilização RADIUS para o Login Único?

Consulte as seções a seguir:

• Mensagens da Contabilização RADIUS

• Compatibilidade do Dell SonicWALL com dispositivos de rede de terceiros

• Encaminhando por proxy

• Usuários fora do domínio

• Considerações sobre o IPv6

A Contabilização RADIUS é especificada pelo RFC 2866 como um mecanismo para um servidor de acesso à rede (NAS) enviar mensagens de contabilização da sessão de login do usuário para um servidor de contabilização. Essas mensagens são enviadas durante o login e o logoff do usuário. Opcionalmente, elas também podem ser enviadas periodicamente durante a sessão do usuário.

Quando um cliente utiliza um dispositivo de acesso à rede de terceiro para realizar a autenticação de usuário (geralmente para o acesso remoto ou sem fio) e o dispositivo oferecer suporte à contabilização RADIUS, um dispositivo Dell SonicWALL pode atuar como o Servidor de Contabilização RADIUS e pode usar as mensagens da Contabilização RADIUS enviadas do servidor de acesso à rede do cliente para o login único (SSO) na rede.

Quando um usuário remoto se conecta por meio de um dispositivo de terceiro, o dispositivo de terceiro envia uma mensagem de contabilização ao dispositivo Dell SonicWALL (configurado como um servidor de contabilização RADIUS). O dispositivo Dell SonicWALL adiciona o usuário ao seu banco de dados interno de usuários conectados com base nas informações da mensagem de contabilização.

Quando o usuário efetua logout, o dispositivo de terceiro envia outra mensagem de contabilização ao dispositivo Dell SonicWALL. O dispositivo Dell SonicWALL então desconecta o usuário.

Observação Quando um servidor de acesso à rede (NAS) envia mensagens de contabilização RADIUS, ele não solicita que o usuário seja autenticado pelo RADIUS. O NAS pode enviar mensagens de contabilização RADIUS, mesmo quando o dispositivo de terceiro estiver usando o LDAP, o banco de dados local ou qualquer outro mecanismo para autenticar os usuários.

As mensagens de contabilização RADIUS não são criptografadas. A contabilização RADIUS é inerentemente segura contra falsificações, porque utiliza um autenticador de solicitação e um segredo compartilhado. Ela exige que uma lista dos servidores de acesso à rede (NAS), que podem enviar mensagens de Contabilização RADIUS, seja configurada no dispositivo. Essa configuração fornece o endereço IP e o segredo compartilhado para cada NAS.

Mensagens da Contabilização RADIUS

A contabilização RADIUS utiliza dois tipos de mensagens de contabilização:

• Solicitação de contabilização

• Resposta de contabilização

Uma Solicitação de contabilização pode enviar um dos três tipos de solicitação especificados pelo atributo Tipo de status:

• Iniciar– enviada quando um usuário é conectado.

• Parar– enviada quando um usuário é desconectado.

• Atualizar provisoriamente– enviada periodicamente durante uma sessão de login do usuário.

As mensagens de contabilização seguem o padrão do RADIUS especificado pelo RFC 2866. Cada mensagem contém uma lista de atributos e um autenticador que é validado por um segredo compartilhado.

Os seguintes atributos, que são relevantes para o SSO, são enviados nas Solicitações de contabilização:

• Tipo de status– O tipo de solicitação de contabilização (Iniciar, Parar ou Atualizar provisoriamente).

• Nome de usuário– O nome de usuário de login. O formato não é especificado pela RFC e pode ser um nome de login simples ou uma cadeia de caracteres com vários valores, como nome de login, domínio ou nome distinto (DN).

• Endereço IP com moldura– O endereço IP do usuário. Se a NAT for utilizada, ela deve ser o endereço IP interno do usuário.

• ID de Estação de Chamada– Uma representação em cadeia dos caracteres do endereço IP do usuário, utilizada por alguns dispositivos como o Aventail.

• Estado do proxy– Um estado de passagem utilizado para encaminhar solicitações para outro servidor de contabilização RADIUS.

Compatibilidade do Dell SonicWALL com dispositivos de rede de terceiros

Para que os dispositivos Dell SonicWALL sejam compatíveis com os dispositivos de rede de terceiros para o SSO por meio da Contabilização RADIUS, o dispositivo de terceiro deve ser capaz de realizar os seguintes itens:

• Oferecer suporte à Contabilização RADIUS.

• Enviar mensagens de Iniciar e Parar. Não é necessário o envio de mensagens do tipo Atualizar provisoriamente.

• Enviar o endereço IP do usuário no atributo Endereço IP com moldura ou ID de Estação de Chamada nas mensagens do tipo Iniciar e Parar.

Observação No caso de um servidor de acesso remoto que utilize a NAT para converter o endereço IP externo público de um usuário, o atributo deve fornecer o endereço IP interno que é utilizado na rede interna e ele deve ser um endereço IP exclusivo para o usuário. Se os dois atributos estiverem sendo utilizados, o atributo Endereço IP com moldura deverá usar o endereço IP interno e o atributo ID de Estação de Chamada deverá usar o endereço IP externo.

O nome de usuário de login deverá ser enviado no atributo Nome de usuário das mensagens dos tipos Iniciar e Atualizar provisoriamente. O nome de usuário de login também pode ser enviado no atributo Nome de usuário das mensagens do tipo Parar, mas isso não é necessário. O atributo Nome de usuário deve conter o nome de conta do usuário e pode incluir também o domínio ou ele deve conter o nome distinto (DN) do usuário.

Encaminhando por proxy

Um dispositivo Dell SonicWALL que atue como um servidor de contabilização RADIUS pode encaminhar as solicitações por proxy para até quatro outros servidores de contabilização RADIUS para cada servidor de acesso à rede (NAS). Cada servidor de contabilização RADIUS é configurado separadamente para cada NAS.

Para evitar a necessidade de inserir novamente os detalhes de configuração para cada NAS, o SonicOS permite que você selecione o encaminhamento para cada NAS a partir de uma lista de servidores configurados.

A configuração de encaminhamento por proxy para cada cliente do NAS inclui tempos limite e repetições. A maneira de encaminhar solicitações para dois ou mais servidores pode ser configurada por meio da seleção das opções a seguir:

• tentar o próximo servidor em um tempo limite

• encaminhar cada uma das solicitações para todos os servidores