Can I use a PAC file available in Offline Files and Folders?
Take it as read for the time being that I need a PAC file and do not want to allow it to be bypassed, either by the user turning off automatic configuration, or by being able to edit or delete the PAC file. Not a problem for internal users, where I have used Group Policy to set up the PAC file in the Connections > LAN section of IE, and also to disable the user's access to those options. The PAC file is, in this case, located in a share on a server.
For those dratted roaming users, I could copy / create a PAC file on their hard drives and apply a different GP for the different location, but then I've got to have administrative access to each laptop to place the file in a secure location. I'd also have an admin nightmare if & when the PAC file needs to change. I was wondering whether IE would find a server-based PAC file while not on the network if it was administratively made available offline through GP. I understand this just pre-sets and uses part of Offline Files & Folders, but is it transparent enough for IE to be fooled it can see the server-based PAC file?
For those dratted roaming users, I could copy / create a PAC file on their hard drives and apply a different GP for the different location, but then I've got to have administrative access to each laptop to place the file in a secure location. I'd also have an admin nightmare if & when the PAC file needs to change. I was wondering whether IE would find a server-based PAC file while not on the network if it was administratively made available offline through GP. I understand this just pre-sets and uses part of Offline Files & Folders, but is it transparent enough for IE to be fooled it can see the server-based PAC file?
Glen Knight
Why do you want your mobile users to use a PAC file? This will be useless if they are not connected to your network.
ASKER
Hi demazter, thanks for your response. I did say take it as read, but here goes...
Fairly obviously, the PAC file does not point to the same proxy server, but to different ones dependant on a bit of logic to try to determine location. Internally, we have a proxy server on the network that relays all requests via a URL filtering / blocking / logging service. Whilst roaming, the external users have their proxy server pointed to an external proxy that will also relay requests to the filtering service. This is why we don't want them to be able to 'turn it off'.
Fairly obviously, the PAC file does not point to the same proxy server, but to different ones dependant on a bit of logic to try to determine location. Internally, we have a proxy server on the network that relays all requests via a URL filtering / blocking / logging service. Whilst roaming, the external users have their proxy server pointed to an external proxy that will also relay requests to the filtering service. This is why we don't want them to be able to 'turn it off'.
So when your users are in their home network you are going to be filtering their Internet access?
What about public wifi where they are required to authenticate via a browser prior to gaining Internet access? They won't be able to.
Anyway, you can use a wpad.dat file which is the same as a PAC file but can be used via IIS publishing.
What about public wifi where they are required to authenticate via a browser prior to gaining Internet access? They won't be able to.
Anyway, you can use a wpad.dat file which is the same as a PAC file but can be used via IIS publishing.
ASKER
Hi,
We are going to be filtering their internet access from company desktops and laptops whether on our network, their network, or anyone else's network. Or, at least, that's the plan.
As far as I can see, we can't use a wpad solution because we are in a private domain (machine.company.local), which would be fine internally but would not resolve externally.
The service provider's FAQs suggest that most public WiFi access works OK with the "external proxy in a PAC method", although that remains to be seen. However, I don't want to get bogged down on that issue. Our primary concern is remote users at home.
We are going to be filtering their internet access from company desktops and laptops whether on our network, their network, or anyone else's network. Or, at least, that's the plan.
As far as I can see, we can't use a wpad solution because we are in a private domain (machine.company.local), which would be fine internally but would not resolve externally.
The service provider's FAQs suggest that most public WiFi access works OK with the "external proxy in a PAC method", although that remains to be seen. However, I don't want to get bogged down on that issue. Our primary concern is remote users at home.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>>The service provider's FAQs suggest that most public WiFi access works OK with the "external proxy in a PAC method", although that remains to be seen
I would be interested to know if that actually works. It's a bit chicken and egg. You can't get Internet access until you have access to the PAC file but you can't get access to the PAC file because you don't have Internet access. Might be interesting.
I would be interested to know if that actually works. It's a bit chicken and egg. You can't get Internet access until you have access to the PAC file but you can't get access to the PAC file because you don't have Internet access. Might be interesting.
ASKER
So is that a "No", or a "Don't Know" to the offline files & folders question?
I was looking for something totally within our management, but hosting the PAC on our web site's server was going to be the next thing to look at. It starts to open up the possibility of the site being hacked and the proxy hi-jacked though. My 'problem' is that we outsource the web site hosting and it's like pulling teeth to get anything done that's outside the content management framework.
I presume there is more involved than just ftp'ing the PAC file to the server, coz that didn't work. Is it just a case of defining the MIME type for ".pac" on the server, whichever platform it is, or is there more to consider? That's all the EE posts I've come across have mentioned, but you never know how much of an IIS / Apache guru you're expected to be!
I was looking for something totally within our management, but hosting the PAC on our web site's server was going to be the next thing to look at. It starts to open up the possibility of the site being hacked and the proxy hi-jacked though. My 'problem' is that we outsource the web site hosting and it's like pulling teeth to get anything done that's outside the content management framework.
I presume there is more involved than just ftp'ing the PAC file to the server, coz that didn't work. Is it just a case of defining the MIME type for ".pac" on the server, whichever platform it is, or is there more to consider? That's all the EE posts I've come across have mentioned, but you never know how much of an IIS / Apache guru you're expected to be!
To be honest I am not sure about the MIME types.
I am still convinced you can publish the WPAD.DAT file externally as well but have never tried it so I'm not going to swear by it :)
With regards to offline files, I don't think IE will reference it correctly and the users will have access to the file, they will have to otherwise sync would fail.
I am still convinced you can publish the WPAD.DAT file externally as well but have never tried it so I'm not going to swear by it :)
With regards to offline files, I don't think IE will reference it correctly and the users will have access to the file, they will have to otherwise sync would fail.
ASKER
Hi demazter (I just realised how that sounded when I read it out load to a colleague :-)
Since you weren't sure, I spent some time testing it. FYI, the PAC file on the server they need R+E access to use even locally. If you use Offline Files & Folders to make it available offline (either as a user or administratively via GPMC) that security gets carried over, and IE uses the offline version of the PAC no problem. So the offline user uses it, and can't modify it, but - because the folder hierarchy isn't also sync'd - they can rename it or delete it :-( Obviously, if they do that, the sync back fails as you suggest.
As for the WPAD, my understanding is that (if we are in an AD domain of XYZ.LOCAL) the WPAD has to be served at WPAD.XYZ.LOCAL, which I don't think is possible in the outside world.
So it looks like serving the PAC from the web site for roaming users. As you say, we then have the chicken & egg with captive portals (public WiFi) and a web-based PAC. I'm not sure and will, if I remember, update this thread with the outcome. As far as I can guess, looking for the PAC will fail, so IE (and any other modern browser) will fall back to DIRECT and cache that fact for the requested host, unless we disable proxy caching. But that will have an adverse effect on performance, I would think.
Anyway, thanks for the input.
Since you weren't sure, I spent some time testing it. FYI, the PAC file on the server they need R+E access to use even locally. If you use Offline Files & Folders to make it available offline (either as a user or administratively via GPMC) that security gets carried over, and IE uses the offline version of the PAC no problem. So the offline user uses it, and can't modify it, but - because the folder hierarchy isn't also sync'd - they can rename it or delete it :-( Obviously, if they do that, the sync back fails as you suggest.
As for the WPAD, my understanding is that (if we are in an AD domain of XYZ.LOCAL) the WPAD has to be served at WPAD.XYZ.LOCAL, which I don't think is possible in the outside world.
So it looks like serving the PAC from the web site for roaming users. As you say, we then have the chicken & egg with captive portals (public WiFi) and a web-based PAC. I'm not sure and will, if I remember, update this thread with the outcome. As far as I can guess, looking for the PAC will fail, so IE (and any other modern browser) will fall back to DIRECT and cache that fact for the requested host, unless we disable proxy caching. But that will have an adverse effect on performance, I would think.
Anyway, thanks for the input.