Internet Access for Generic Accounts through ISA Server 2004


Introduction


 


I received a support call a few days ago from a customer saying that he has an environment where all users from the Front Desk need to log on to their workstations using one particular domain account called frontdesk. Those users are not allowed to access the Internet. On the customer’s ISA Server 2004 computer, Integrated Windows authentication was specified and only the users from the domain group Internet Users could access the Internet. Front Desk users who require Internet access are allowed access when they log on as users from the domain group Internet Users.


 


The behavior that the customer expected was:


 


1.      User logs on to the domain with the frontdesk domain account.


2.      User tries to access the Internet, and because the user doesn’t belong to the Internet Users group, ISA Server asks for credentials.


3.      User has the opportunity to type the domain user account associated with the Internet Users group.


 


The customer was frustrated, however, because the user received an access denied message immediately after ISA Server tried to authenticate, which is the correct ISA Server action. To attempt to fix the problem, the customer changed the authentication type to Basic authentication. With Basic authentication, all users are prompted for authentication, which is also the correct ISA Server action.


 


How Does It Work?


 


Assuming that the ISA Server 2004 computer is a member server of a Windows domain, and it is using Integrated Windows authentication, the following describes the process for when a user is trying to access an Internet Web site through ISA Server:


 


1.      The Windows credentials from the current user are used for authentication purposes.


2.      During this negotiation ISA Server contacts the domain controller to present the credentials.


a.      If the negotiation fails at this point, the user is prompted for authentication.


3.      The domain controller responds, allowing or denying the authentication.


4.      Because the user is identified, ISA Server processes the Firewall policy rule using those credentials to see if this user is allowed to access the external resource. (For more information, see the article How firewall policy works at the Microsoft TechNet Web site.)


 


As you can see, between steps 2 and 3, there is a conditional statement. The following are situations where ISA Server prompts the user for authentication:


 



  • If ISA Server cannot contact the domain controller for any reason (for example, connectivity).

  • If the domain controller resets the connection with ISA Server during this negotiation.

  • If the user doesn’t belong to the domain where ISA Server is sending the authentication. (For example, if the user is logged on with the local user account for that particular workstation.)

 


In this customer’s case, the user was identified during the negotiation and the user didn’t belong to the Internet Users group, so the expected result is that the user receives an access denied response.


 


Proving the Case


 


Some customers want to see proof, rather than just hearing or reading an explanation. When this situation occurs, it is not difficult to show what is happening behind the scenes.


 


To collect the data, do the following:


 


1. Attach Network Monitor to the internal network interface card (NIC) of the ISA Server computer. (Optionally, you also can attach Network Monitor to the client workstation and to the domain controller to see all of the communication.)


2. On the ISA Server computer, enable logging using a filter for the client workstation that you are testing as shown on the following screen shot:


 



 Network Monitor screenshot


 


3. Start the Network Monitor trace on all computers involved and start logging on the ISA Server computer.


4. As soon as you receive the access denied page, stop the traces and stop logging.


 


Network Monitor Result on the ISA Server Computer


 


1. The client request:


 



+ 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. The ISA Server response (including the request for authentication):


 



+ 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. The client sends authentication:


 



  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. ISA Server denies access:


 



  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


 


ISA Server Logging (Main Fields)


 














































Destination host name


Action


Rule


Result code


HTTP status code


Client user name


 


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


 


 


 


Conclusion


 


The collected evidence makes it easier for a network administrator to understand how authentication works. In this particular case, the customer asked, “Is there any workaround so I can keep using my generic account and be prompted for a user name and password?” The answer is yes. The customer can use an easy technique of opening Internet Explorer on the client workstation using the Run As option, and then providing the credentials for the domain account that belongs to the Internet Users group.


 


Beyond the workaround, the main objective of this post is to explain how Integrated Windows authentication works with ISA Server in the domain environment, what to expect when using Integrated Windows authentication, and how to identify what is happening if authentication fails.


 


 


Yuri Diogenes


Microsoft Support Engineer – Latin America Team – Platforms


 


Comments (7)

  1. Tom Shinder says:

    Hi Yuri,

    Very nice article! I appreciate the effort it took to write and it will benefit many ISA Firewall admins.

    Thanks!

    Tom

  2. Yuri Diogenes says:

    Thanks for the comment Tom, is always a pleasure to help the ISA community. Your articles and books are also very appreciated and important to the community.

    Thanks,

    Yuri

  3. martin says:

    Yuri, or others:

    Is there any way to change the behaviour, when ISA server asks for credentials when there is an locally logged in user at some worskation trying to browse using ISA web proxy?

    Because I need to set up an environmnet where locally logged on users have internet access disabled and they can not supply the credentials to the ISA server. (In other words, they have to log off and log on using domain account if they wish to browse internet).

    Thanks a lot for reply

  4. Yuri Diogenes says:

    Hi Martin,

    Sorry for the delay to answer. One way to accomplish data is by Group Policy. Disable the IE process on the local computer for the local account and allow the IE to be executed via Domain Account.

    Another way to do that is to configure the IE via local policy to use a fake proxy and disable the ability to change the IE properties for the local user. When he logs on via domain user account he gets the correct policy via GPO.

    It is better to control that via Group Policy than ISA itself.

    I hope this help.

    Yuri Diogenes

  5. Kevin says:

    Hi.  VERY nice and informative site.  I have a problem here at our business.  I am the network admin and we have ISA 2004 installed on a server2003 machine, which also runs Surfcontrol.  Our users are sporadically getting windows authentication prompts when attempting to go out to the web.  ISA is set with integrated authentication and all users are in a group that is allowed internet access.  This doesn’t happen very often, but when it does we find that simply logging the user off, restarting the PC, and logging back on gets them the ability to get out to the web.   I know that one user in particular had left her account logged on over the past night.  Wasn’t sure if this had an effect.  This is confounding.  Any ideas?

  6. Love2Learn says:

    Hey Guys

    what is explained in this statement part 3 doesn't happen for me:

    ""The following are situations where ISA Server prompts the user for authentication:

       * If ISA Server cannot contact the domain controller for any reason (for example, connectivity).

       * If the domain controller resets the connection with ISA Server during this negotiation.

       * If the user doesn’t belong to the domain where ISA Server is sending the authentication. (For example, if the user is logged on with the local user account for that particular workstation.)""

    and I just can't open any web pages on a laptop which belongs to a work group and now is connected to my domain. It doesn't ask for any credentials and just denies access. How's that?