Acesso a Páginas Web com uso de Contas Genéricas através do ISA Server 2004
Por: Yuri Diógenes
1. Introdução
Alguns dias atrás eu recebi uma ligação de um cliente dizendo que no ambiente dele todos usuários que trabalham na recepção da empresa precisam efetuar o logon nas suas devidas estações usando uma conta em comum do domínio chamada de “frontdesk”. Este pessoal não pode acessar à Internet, entretanto alguns deles precisam acessar usando sua conta pessoal de domínio. No servidor ISA Server 2004 a autenticação em uso era a Integrada e somente usuários do grupo de domínio “Internet Users” poderiam acessar a Internet.
O comportamento que o cliente estava esperando que acontecesse era:
1. Usuário efetua o logon no domínio com a conta “frontdesk”;
2. O usuário que porventura tentasse acessar a Internet não iria conseguir devido a conta “frontdesk” não pertencer ao grupo “Internet Users”, porém o usuário não deveria receber a tela de acesso negado e sim ser requisitado por uma credencial alternativa;
3. Neste momento o usuário teria a chance de digitar uma credencial que tivesse acesso a Internet.
A frustação do cliente é que o usuário estava recebendo um acesso negado logo após tentar acessar a Internet, o que tecnicamente falando está correto. O cliente resolveu então trocar o método de autenticação para “Básico” e aí o resultado foi o inverso, ou seja, para todos os usuários era pedido uma tela de autenticação, até mesmo para os membros do grupo “Internet Users”.
2. Então como Funciona?
Partindo do pressuposto que o servidor ISA Server 2004 é membro de um domínio Windows e está usando autenticação integrada, o seguinte processo é feito quando um usuário tenta acessar a Internet através do ISA:
1. A credencial em uso na estação do usuário é usada para fins de autenticação no acesso através do ISA;
2. Durante esta negociação o servidor ISA Server vai contactar o DC para apresentar tais credenciais e verificar a veracidade de tais informações:
a. Se a negociação falhar o ISA Server vai requisitar apresentar uma tela de autenticação para o usuário de forma que ele possa entrar com as credenciais;
3. O DC vai verificar as credenciais e responder autorizando ou não a autenticação;
4. O usuário sendo identificado o ISA Server vai processar as regras de Firewall (veja o artigo How Firewall Policy Works na Ajuda e Suporte Microsoft) usando tal credencial para verificar se o usuário pode ou não fazer acesso ao recurso externo requisitado.
Como você pode ver entre o passo dois e três nós temos uma verificação condicional, onde é verificado se o ISA pôde acessar o DC ou não. Caso não tenha conseguido acessar, então a tela de autenticação aparecerá. Aí vem a pergunta: e em qual cenário(s) ele iria mostrar esta tela de autenticação?
· Se o ISA Server não conseguir contactar o DC por alguma razão (problemas de conectividade por exemplo);
· Se o DC reiniciar a conexão com o servidor ISA durante a negociação;
· Se o usuário não pertencer ao domínio onde o ISA Server está enviando a autenticação. Por exemplo se o usuário estiver usando as credenciais contidas no computador local.
No caso do cliente o usuário foi identificado durante a negociação e o usuário não pertencia ao grupo que tinha acesso a Internet, desta forma o comportamento de acesso negado a página é esperado.
3. Mostrando Evidências
É Normal que algumas vezes os clientes queiram ver uma prova real ao invés de ouvirem ou lerem uma explicação teórica de como determinada característica funciona. Se isso acontecer neste cenário não é muito difícil reunir as peças deste quebra-cabeça e mostrar o que está acontecendo de fato.
Para coletar tais evidências é necessário:
1. Configure o Network Monitor na placa interna do servidor ISA Server (opcionalmente você poderá configurar o Network Monitor também no controlador de domínio e na estação para ter uma visão completa de todas as pontas envolvidas);
2. No servidor ISA habilite o “Logging” usando o filtro para o IP da estação cliente:
3. Inicie a captura com o Network Monitor em todos computadores envolvidos e inicie o log no servidor ISA.
4. Assim que a página com “Access Denied” aparecer para a captura e também o log do ISA Server.
Como uma amostra, veja como os resultados devem aparecer:
a. Resultado do Network Monitor no servidor ISA Server
1) Requisição do cliente:
+ Ethernet: Etype = Internet IP (IPv4)
- Ipv4: Next Protocol = TCP, Packet ID = 792, Total IP Length = 303
+ Versions: IPv4, Internet Protocol; Header Length = 20
+ DifferentiatedServicesField: DSCP: 0, ECN: 0
TotalLength: 303 (0x12F)
Identification: 792 (0x318)
+ FragmentFlags: 16384 (0x4000)
TimeToLive: 128 (0x80)
NextProtocol: TCP, 6(0x6)
Checksum: 29825 (0x7481)
SourceAddress: 192.168.0.220
DestinationAddress: 192.168.0.3
+ Tcp: Flags=...PA..., SrcPort=1114, DstPort=HTTP Alternate(8080), Len=263, Seq=3347642069 - 3347642332, Ack=2988899206, Win=65535 (scale factor 0) = 0
- HTTP: Request, GET https://www.microsoft.com/isapi/redir.dll
Command: GET
+ URI: https://www.microsoft.com/isapi/redir.dll?prd=ie\&pver=6\&ar=msnhome
ProtocolVersion: HTTP/1.0
Accept: */*
Accept-Language: en-us
UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)
Host: www.microsoft.com
Proxy-Connection: Keep-Alive
HeaderEnd: CRLF
2) Resposta do servidor ISA Server:
+ Ethernet: Etype = Internet IP (IPv4)
- Ipv4: Next Protocol = TCP, Packet ID = 59379, Total IP Length = 1500
+ Versions: IPv4, Internet Protocol; Header Length = 20
+ DifferentiatedServicesField: DSCP: 0, ECN: 0
TotalLength: 1500 (0x5DC)
Identification: 59379 (0xE7F3)
+ FragmentFlags: 0 (0x0)
TimeToLive: 128 (0x80)
NextProtocol: TCP, 6(0x6)
Checksum: 51960 (0xCAF8)
SourceAddress: 192.168.0.3
DestinationAddress: 192.168.0.220
+ Tcp: Flags=....A..., SrcPort=HTTP Alternate(8080), DstPort=1114, Len=1460, Seq=2988899206 - 2988900666, Ack=3347642332, Win=65272 (scale factor 0) = 0
- HTTP: Response, HTTP/1.1, Status Code = 407
ProtocolVersion: HTTP/1.1
StatusCode: 407, Proxy authentication required
Reason: Proxy Authentication Required ( The ISA Server requires authorization to fulfill the request. Access to the Web Proxy filter is denied. )
Via: 1.1 YDSRV
Proxy-Authenticate: Negotiate
Proxy-Authenticate: Kerberos
Proxy-Authenticate: NTLM
Connection: Keep-Alive
Proxy-Connection: Keep-Alive
Pragma: no-cache
Cache-Control: no-cache
ContentType: text/html
ContentLength: 4101
HeaderEnd: CRLF
3) Cliente envia autenticação:
Frame:
+ Ethernet: Etype = Internet IP (IPv4)
- Ipv4: Next Protocol = TCP, Packet ID = 797, Total IP Length = 403
+ Versions: IPv4, Internet Protocol; Header Length = 20
+ DifferentiatedServicesField: DSCP: 0, ECN: 0
TotalLength: 403 (0x193)
Identification: 797 (0x31D)
+ FragmentFlags: 16384 (0x4000)
TimeToLive: 128 (0x80)
NextProtocol: TCP, 6(0x6)
Checksum: 29720 (0x7418)
SourceAddress: 192.168.0.220
DestinationAddress: 192.168.0.3
+ Tcp: Flags=...PA..., SrcPort=1114, DstPort=HTTP Alternate(8080), Len=363, Seq=3347642332 - 3347642695, Ack=2988903711, Win=65535 (scale factor 0) = 0
- HTTP: Request, GET https://www.microsoft.com/isapi/redir.dll
Command: GET
+ URI: https://www.microsoft.com/isapi/redir.dll?prd=ie\&pver=6\&ar=msnhome
ProtocolVersion: HTTP/1.0
Accept: */*
Accept-Language: en-us
Proxy-Authorization: NTLM TlRMTVNTUAABAAAAB7IIogUABQAwAAAACAAIACgAAAAFASgKAAAAD1hQQ0xJRU5UQ1RFU1Q=
UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727)
Host: www.microsoft.com
Proxy-Connection: Keep-Alive
HeaderEnd: CRLF
4) Servidor ISA Server rejeita o acesso:
Frame:
+ Ethernet: Etype = Internet IP (IPv4)
- Ipv4: Next Protocol = TCP, Packet ID = 59556, Total IP Length = 1500
+ Versions: IPv4, Internet Protocol; Header Length = 20
+ DifferentiatedServicesField: DSCP: 0, ECN: 0
TotalLength: 1500 (0x5DC)
Identification: 59556 (0xE8A4)
+ FragmentFlags: 0 (0x0)
TimeToLive: 128 (0x80)
NextProtocol: TCP, 6(0x6)
Checksum: 51783 (0xCA47)
SourceAddress: 192.168.0.3
DestinationAddress: 192.168.0.220
+ Tcp: Flags=....A..., SrcPort=HTTP Alternate(8080), DstPort=1114, Len=1460, Seq=2988904205 - 2988905665, Ack=3347643190, Win=64414 (scale factor 0) = 0
- HTTP: Response, HTTP/1.1, Status Code = 502
ProtocolVersion: HTTP/1.1
StatusCode: 502, Bad gateway
Reason: Proxy Error ( The ISA Server denied the specified Uniform Resource Locator (URL). )
Via: 1.1 YDSRV
Connection: close
Proxy-Connection: close
Pragma: no-cache
Cache-Control: no-cache
ContentType: text/html
ContentLength: 4047
HeaderEnd: CRLF
b. Log do servidor ISA Server (principais campos):
Destination Host Name |
Action |
Rule |
Result Code |
HTTP Status Code |
Client Username |
Initiated Connection |
0x0 |
||||
www.microsoft.com |
Denied Connection |
Browse Internet |
12209 The ISA Server requires authorization to fulfill the request. Access to the Web Proxy filter is denied. |
anonymous |
|
www.microsoft.com |
Failed Connection Attempt |
Browse Internet |
5 |
anonymous |
|
www.microsoft.com |
Denied Connection |
[Enterprise] Default rule |
12202 The ISA Server denied the specified Uniform Resource Locator (URL). |
CTEST\bob |
|
Closed Connection |
0x80074e20 FWX_E_ GRACEFUL_SHUTDOWN |
4. Conclusão
As evidências vão deixar mais fácil o entendimento da teoria explicada anteriormente de como este recurso funciona. Neste caso em particular, ao final houve a pergunta do cliente: “Existe alguma solução de contorno para que possamos continuar usando contas genéricas?” . A resposta foi “Sim” e usando uma simples técnica, que é abrir o Internet Explorer usando a opção “Run As...” e usar uma credencial que faça parte do grupo “Internet Users”.
Porém muito além de mostrar esta solução de contorno a idéia do artigo é explicar como a autenticação integrada trabalhar em um servidor ISA Server 2004 em um ambiente de domínio, o que esperar e como identificar o que está acontecendo em caso de falha.