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.


 


 

Comments (1)

  1. Rodrigo says:

    Já no ISA Server 2000 Standard isso já não acontece.

    Quando um usuário não pertence ao grupo ele pede uma autenticação e seria uma solução de contorno também.