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 http://www.microsoft.com/isapi/redir.dll

Command: GET

+ URI: http://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 http://www.microsoft.com/isapi/redir.dll

Command: GET

+ URI: http://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.