Squid as an Internet Access Control in a Windows Domain Environment
Modification of Existing Network constituents to accommodate incorporation of a Squid proxy server for use as an Access control mechanism for Internet services
This guide expects the reader is relatively proficient with basic Red Hat linux management, and thus not all details regarding setup and configuration of software will be covered. Documentation covering basic Red Hat administration is plentiful on the internet and in various books (RedHat Linux 7 Unleashed), and a good starting place are the online manuals for Red Hat, which can be found at http://www.redhat.com. As good practice, when compiling and installing software from source, it is imperative to read the included README file and if present, the INSTALL file for each software package. Only limited information contained in these documents will be reiterated in this guide.
Squid is a caching proxy server that can also be used to control access to some internet resources. In combination with a Windows domain, Squid can offer reliable and inexpensive proxy functionality that can be integrated directly with Window's security with the help of Samba. Furthermore, by using two physical network interface cards (NIC) in the linux box, all clients on a local area network (LAN) can be forced to use the proxy for access to the internet. However, by using two NICs, routing must be address and potentially large-scale changes may need to be completed.
In this guide, the example network consists of a Watchguard Firebox II Plus with multiple Cisco routers behind the firebox. Routing functions on the firebox will be kept to a minimum, as it is intended as a firewall and not a router. The firebox will also be configured as a virtual private network (VPN) server handling incoming point to point tunneling protocol (PPTP) VPN connections. The linux box (named ARES) will be running Red Hat Linux 7.3 (installed with Server configuration and added X-Windows System, Gnome, KDE, and Apache) and be placed physically inline between the firebox and the LAN. A complete discussion will be presented that covers setting up the linux box to finalizing routing setup on the example network.
Security on all objects in Active Directory (AD) needs to be set correctly to allow access from the linux box. Security should include Pre-Windows2000 Compatibility group. At the domain level, set advanced security for this group as follows:
Read Permission This object only
List Contents This folder, subfolder and files
Special (list contents, read all properties, read permissions) Group Objects
Special (list contents, read all properties, read permissions) User Objects
These security settings should be inherited down the AD tree. Be aware that there might be some containers and objects that do not inherit permissions from their parent and therefore, might not have the Pre-Windows2000 security settings correct. These folders and objects will be unavailable to winbind. Winbind will display an exception error code (e.g. 0xc00000022) when trying to access these types of objects
This procedure focuses on the domain, student.example.com, since ultimately students will be restricted from accessing the internet. Therefore, a Global group ( Must be Global or Universal group. Domain Local groups are not visible to winbind) was created in the student domain and this group was named NoINETAccess.
Building,Installing and Configuring Samba
If Samba was installed during the installation of RedHat 7.3, uninstall it. The rpm version that shipped with RedHat 7.3 was not configured with support for all winbind features required for this procedure. Winbind is the Samba component that allows a linux box to act as a Window's machine in various ways. You can download the latest Samba source from www.samba.org, but be aware that using and combining different versions of Samba and Squid may result in neither package working as expected. For this procedure, it is recommend to use exact version used here. The version of Samba used in this procedure is 2.2.6-1.
Building and Installing Samba
Samba needs to be compiled to include support for winbind. To do so, compile it with the --with-winbind --with-winbind-auth-challenge options i.e.
[root@squidy source]#./configure --with-winbind --with-winbind-auth-challenge
Next make the binaries for Samba using the make command...then make install.
Copy the libnss_winbind.so file from source/nsswitch directory to /lib. Create a symlink for this file as follows:
ln -s /lib/libnss_winbind.so /lib/libnss_winbind.so.2
The pam_winbind.so file can be made if PAM will be implemented for any services. However, for this configuration of authentication from Squid, this module is not needed. From the source directory run the following:
source#make nsswitch/pam_winbind.so
Then copy this file to /lib/security. To link these newly created libraries, run the following command:
root#/sbin/ldconfig -v | grep winbind.
Next, the /etc/nsswitch.conf file needs to be configured to include winbind support. Find the passwd, shadow, and group lines, and insert winbind as shown below:
passwd: files winbind nisplus
shadow: files winbind nisplus
group: files winbind nisplus
Now, the smb.conf needs to be configured by adding a few lines to the Global Settings section. Copy the default Red Hat smb.conf from the samba-2.2.6/packaging/RedHat directory to the /usr/local/samba/lib directory. Contrary to the Samba/Winbind documentation, for this procedure no winbind separator needs to be specified (It was found that setting the winbind separator to "+" causes problems with Squid's wb_group and its ability to read the current user's credentials obtained by %LOGIN. Therefore, let winbind use the default separator "\" by not specifying a separator in the smb.conf file. This enables wb_group to function properly.). The following lines can be added to the top of the Global Settings section.
winbind cache time = 15
template shell = /bin/false #or /bin/bash (only needed if telnet (or similar) access allowed for users)
winbind uid = 10000-20000
winbind gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes
The following options are already present in the smb.conf file, but need to be configured correctly. Find these options and edit them accordingly.
workgroup = STUDENT # name of domain
security = domain
password server = pdc.student.example.com
encrypt passwords = yes
To ensure that the password server listed in the smb.conf file is accessible, add the following line to the /etc/hosts file.
192.168.1.26 pdc.student.example.com pdc
In addition, it is important that the linux box is configured to use the DNS server pdc.student.example.com (192.168.1.26) or another DC for this domain. Since pdc is in the same Window's "site" as the linux box, pdc should be used.
The machine now needs to be joined to the Windows 2000 domain. Use the following command to join to the domain:
root#/usr/local/samba/bin/smbpasswd -j STUDENT -r PDC -U administrator
(where administrator is a username of someone with access to join machines to the domain). If the join process was successful, a message will appear stating so.
Start winbind and test it using the wbinfo tool found in /usr/local/samba i.e. /usr/local/samba/bin/wbinfo -u. If you see all domain users, winbind is operating correctly. Note that with the default winbind separator, the syntax of the test for wbinfo -a is student\\username%password...you have to add an extra backslash.
If problems are encountered at this point, the most commonly found issues have been related to security in Active Directory preventing the linux box from accessing group and account information, or name resolution related to DNS problems.
Building, Installing and Configuring Squid
Like Samba, if Squid was installed during the installation of RedHat 7.3, it should be uninstalled because it wasn't compiled with all necessary functionality for this procedure. The latest Squid source can be downloaded from www.squid-cache.org, but it is important to use the same version of Squid as outlined in this manual, squid-2.5-STABLE1-20021119. If the web-based cache management tool included with Squid will be used, make sure Apache is installed on the linux box.
The Winbind interface changed in Samba-2.2.6 and therefore, the winbind components of Squid-2.5stable1 don't work correctly. To enable the Squid winbind components to work correctly, before compiling squid, replace the Squid versions of winbindd_nss.h located in the squid/helpers/ directories (there are three: one in the basic_auth/winbind, one in the ntlm_auth/winbind, and one in the external_acl/winbind_group directories) with the Samba version of winbindd_nss.h found in samba/source/nsswitch.
Building and Installing Squid
Several command-line options need to be specified during the configure process to ensure Squid is built with support for winbind integration. They are
--enable-auth="ntlm,basic"
--enable-basic-auth-helpers="winbind"
--enable-ntlm-auth-helpers="winbind"
--enable-external-acl-helpers="winbind_group"
and if using the ldap external acl helper, use the following options to replace their corresponding options above.
--enable-basic-auth-helpers="LDAP"
--enable-external-acl-helpers="ldap_group"
The following command was used to compile Squid:
./configure --enable-auth="ntlm,basic" --enable-basic-auth-helpers="winbind" --enable-ntlm-auth-helpers="winbind" --enable-external-acl-helpers="winbind_group"
This should all be on one line with no carriage returns.
After configure is done, run make. Then run make install.
Configuring Squid
Now the squid.conf file needs to be configured. It may be helpful to eventually have a minimal squid.conf file, but to begin with, the default configuration file will be modified to suit the needs of this procedure. During the Squid installation, a backup copy (squid.conf.default) of the squid.conf file was created and can be found in /usr/local/squid/etc. Edit the squid.conf file and uncomment, edit or add the following lines:
visible_hostname ares
auth_param ntlm program /usr/local/squid/libexec/wb_ntlmauth
auth_param ntlm children 5
auth_param ntlm max_challenge_resuses 0
auth_param ntlm max_challenge_lifetime 2 minutes
auth_param basic program /usr/local/squid/libexec/wb_auth
auth_param basic children 5
auth_param basic realm Squid proxy-caching web server
auth_param basic credentialsttl 2 hours
(really don't need any of these basic auth_params for this procedure)
external_acl_type W2Kgroup %LOGIN /usr/local/squid/libexec/wb_group
acl Student_NOINET external W2Kgroup NoINETAccess
acl Allowed proxy_auth REQUIRED
http_access deny Student_NOINET
http_access allow Allowed
Without starting Squid, run wb_group to test whether or not this tool can determine if a given user is a member of a particular Window's group e.g. run /usr/local/squid/libexec/wb_group -d. At the (lack of) prompt, enter student\\username NoINETAccess. If successful, a list should be displayed of SIDs and groups that this user is a member of followed by "OK" if the user is a member of the specified group. Otherwise, the "ERR" message is displayed. When the "ERR" is displayed in the absence of any SIDs, there was an error by wb_group communicating with the domain. This error is vague and can be difficult to troubleshoot. No specific recommendations can be given when this error is encountered.
It was found that /usr/local/squid/var permissions are not set correctly initially for squid to function properly. Since squid runs as nobody (user and group) when started by root, the var dir user and group need to be changed to "nobody" instead of "root". Apply these changes recursively by running the following commands:
root#chown -R nobody /usr/local/squid/var
root#chgrp -R nobody /usr/local/squid/var
Start squid with the -z option (/usr/local/squid/sbin/squid -z); this creates swap and cache directories. Then start squid normally and test it using a client machine. Set the client machine to use ares as a proxy server for Internet Explorer.
When a change is made in AD for the group membership of NoINETAccess, both Winbind and Squid need to be restarted to see this change immediately. Restart Winbind first, then Squid.
IPTables Firewall Configuration
The linux box needs to be protected from attack from both internal and external sources. Therefore a firewall needs to be configured, and iptables was chosen since it is more robust and flexible than ipchains. The concept behind what needs to be accomplished by iptables is relatively simple. Only secure shell traffic can directly connect to the linux box from the external interface, but all traffic from the internal interface is accepted (threats from internal sources will be handled via redirection to port 3128; It was found that for ftp connections to be proxied from Internet Explorer, the Advanced Internet Option "Enable Folder view for FTP sites" should be disabled. This can be accomplished using a vbscript that sets the value of the proper registry value. The registry value that needs to be set is HKCU\Software\Microsoft\Ftp\Use Web Based Ftp ... this value should be set to "yes". Refer to the section Forcing Internet Explorer clients to use web-based FTP). ICMP traffic is rate limited to prevent flood attacks. All traffic destined for another machine is allowed to be forwarded. All packets originating from the linux box are allowed out. In addition, on the internal interface, four addresses are NATted (requests from external sources are NATted by the firebox).
Setting Default Policies
From the command prompt, run the following to set default policies. These can be changed to suit differing needs.
prompt# iptables -P INPUT DROP
prompt# iptables -P OUTPUT ACCEPT
prompt# iptables -P FORWARD ACCEPT
Setting INPUT rules
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A INPUT -i eth2-i -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -m limit --limit 1/sec -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j DROP
iptables -A INPUT -p icmp -m icmp ! --icmp-type 8 -j ACCEPT
Setting NAT rules
iptables -t nat -A PREROUTING -i eth2 -d 205.168.220.35 -j DNAT --to 192.168.1.20
iptables -t nat -A PREROUTING -i eth2 -d 205.168.220.36 -j DNAT --to 192.168.1.13
iptables -t nat -A PREROUTING -i eth2 -d 205.168.220.37 -j DNAT --to 192.168.1.37
iptables -t nat -A PREROUTING -i eth2 -d 205.168.220.100 -j DNAT --to 192.168.1.4
iptables -t nat -A PREROUTING -i eth2-i -s ! 192.168.1.14 -d ! 128.121.26.136 -p tcp -m multiport --dport 80,443 -j DNAT --to 192.168.1.25:3128 (the -s ! address is to allow linux mail server antivirus software to pull virus defs automatically since this software can use an auth proxy; the -d ! address it to allow the Weatherbug software to pull weather updates)
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 192.168.1.20 -o eth2 -j SNAT --to 192.168.1.25
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 192.168.1.13 -o eth2 -j SNAT --to 192.168.1.25
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 192.168.1.37 -o eth2 -j SNAT --to 192.168.1.25
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 192.168.1.4 -o eth2 -j SNAT --to 192.168.1.25
Each of the SNAT lines about can also used the MASQUERADE option instead of the SNAT segment. MASQUERADE is just another form of SNAT. Therefore, each of the SNAT lines above can actually be replaced by the following:
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 192.168.1.20 -o eth2 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 192.168.1.13 -o eth2 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 192.168.1.37 -o eth2 -j MASQUERADE
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 192.168.1.4 -o eth2 -j MASQUERADE
There is a limitation with this NAT however, in that these NAT rules only apply and work when a client is not using the proxy. When the client is using the proxy, requests for these addresses originate from squid (i.e. the localhost), and DNAT is not fully implemented in iptables for OUTPUT packets (packets originating on the linux box). This should not be a problem for standard users, as long as requests for domain names are translated to internal IPs. On machines (headache) where the external IP is requested directly, the use of a proxy server should be disabled to allow access to these external IPs.
There may be a time when all unnecessary traffic on ports 1024 to 65535 should be redirected to the proxy server. This can be accomplished with the following:
iptables -t nat -A PREROUTING -i eth2-i -p tcp -dport 1024:65535 -j DNAT -to 192.168.1.25:3128
Once these rules are active in iptables, this configuration can be saved to a file, /etc/sysconfig/iptables, by running the following:
prompt#service iptables save
Everytime iptables is restarted, it will now load this configuration.
Startup Scripts
Startup scripts need to be created to manage each program: winbindd, smbd, nmbd, and squid.
Original startup scripts (installed from rpms) for samba, winbind, and squid can be found on dist70_test. Copy these scripts to the /etc/init.d directory. Finally, create symlinks to facilitate each script's functionality and set the mode for each to allow root to run these scripts.
Samba
Created the following symlinks:
ln -s /usr/local/samba/var/locks /var/cache/samba
ln -s /usr/local/samba/bin/smbd /usr/sbin/smbd
ln -s /usr/local/samba/bin/nmbd /usr/sbin/nmbd
ln -s /usr/local/samba/lib /etc/samba
Winbind
The samba symlinks take care of most requirements of winbind. Need to add one more symlink.
ln -s /usr/local/samba/bin/winbindd /usr/sbin/winbindd
Squid
Created the following symlinks.
ln -s /usr/local/squid/var/logs /var/cache/squid
ln -s /usr/local/squid/sbin/squid /usr/sbin/squid
ln -s /usr/local/squid/etc /etc/squid
Setting mode
Change directory to /etc/init.d and run the following commands to set the mode on each startup script.
prompt#chmod u+x samba
prompt#chmod u+x squid
prompt#chmod u+x winbind
Routing on the Linux box
Routing on the linux box is relatively straight forward. However, there is one small quirk with RedHat in that by default, ip forwarding is disabled. This means that traffic coming in one NIC won't be forwarded to the other NIC. Therefore, ip forwarding should be enabled.
Adding Routes
Necessary routes are as follows:
192.168.1.0 go out internal NIC (eth2) 192.168.7.0 go out eth2 192.168.13.0 go out eth2
192.168.2.0 go out eth2 192.168.8.0 go out eth2 192.168.14.0 go out eth2
192.168.3.0 go out eth2 192.168.9.0 go out eth2 192.168.15.0 go out eth2
192.168.4.0 go out eth2 192.168.10.0 go out eth2 192.168.16.0 go out eth2
192.168.5.0 go out eth2 192.168.11.0 go out eth2 192.168.17.0 go out eth2
192.168.6.0 go out eth2 192.168.12.0 go out eth2 192.168.18.0 go out eth2
192.168.19.0 go out eth2 192.168.25.0 go out eth2
192.168.20.0 go out eth2 192.168.30.0 go out eth2
192.168.21.0 go out eth2 192.168.35.0 go out eth2
192.168.22.0 go out eth2
These routes can be setup to be loaded automatically everytime the network restarts. To do this, add these routes to the /etc/sysconfig/static-routes file. The syntax of the static-routes file is different than that of the route command. For instance, adding a route with the route command would be done like this
prompt#route add -net 192.168.1.0 dev eth2
In the static-routes file, the line to add this route would be as follows:
eth2 net 192.168.1.0
Add each route to the static-routes file in the above format.
Enabling IP Forwarding
Before any routing will work on the linux box, the kernel must be instructed to forward ip packets. By default under RedHat 7.3, ip forwarding is disabled. It can be enabled quite easily by editing the /etc/sysctl.conf file and changing the "0" to "1" for the line pertaining to ip forwarding.
WatchGuard Firebox II Plus: Configuring Routes, NAT, and VPN
To pass traffic to and from the linux box, several factors need to be considered when configuring the firebox. The firebox should be setup in "Drop-In" mode (refer to Watchguard documentation for further explanation), and a secondary network should be created on the Trusted interface. This secondary network should be of the same network as the external NIC on the linux box. For instance, the firebox has a secondary network of 192.168.255.1/24 on the Trusted interface. The external NIC on the linux box therefore has an IP of 192.168.255.2/24. These two hardware devices are plugged into the "External" VLAN on the HP Procurve. Also plugged into this external VLAN is Athena (IP address of 192.168.255.3) to serve as the logging host for the firebox. (Currently, Watchguard software version is 6.1 with hotfix released on 11-02-2002.)
Routing
According to the Watchguard documentation, the firebox does not support routing protocols, so all routes on the firebox must be setup as static. To setup these routes, open the Watchguard Control Center, open the Policy Manager, click the Network menu and select the Routes option. Create network routes using gateway of 192.168.255.2 for all internal networks as follows:
network gateway network gateway network gateway
192.168.1.0 192.168.255.2 192.168.12.0 192.168.255.2 192.168.25.0 192.168.255.2
192.168.2.0 192.168.255.2 192.168.13.0 192.168.255.2 192.168.30.0 192.168.255.2
192.168.3.0 192.168.255.2 192.168.14.0 192.168.255.2 192.168.35.0 192.168.255.2
192.168.4.0 192.168.255.2 192.168.15.0 192.168.255.2
192.168.5.0 192.168.255.2 192.168.16.0 192.168.255.2
192.168.6.0 192.168.255.2 192.168.17.0 192.168.255.2
192.168.7.0 192.168.255.2 192.168.18.0 192.168.255.2
192.168.8.0 192.168.255.2 192.168.19.0 192.168.255.2
192.168.9.0 192.168.255.2 192.168.20.0 192.168.255.2
192.168.10.0 192.168.255.2 192.168.21.0 192.168.255.2
192.168.11.0 192.168.255.2 192.168.22.0 192.168.255.2
"1 to 1 NAT" (A.K.A. Destination NAT)
Watchguard refers to what is commonly known as destination network address translation (DNAT) as 1 to 1 NAT. This type of NAT converts a request for one IP address (regardless of what port is requested) to another IP address. It is necessary to setup 1 to 1 NAT for any public IP addresses to map these IPs to the appropriate server on the LAN that has a private address. Currently, there are four external IPs to be mapped to internal addresses. To setup these 1 to 1 NATs, open the Policy manager, select the Setup menu and select the NAT option. From the NAT dialog box, click the Advanced button, and then click the 1 to 1 NAT Setup tab. Enable the checkbox Enable 1 to 1 NAT, and click Add. Select the external interface, Number of hosts is 1, NAT base is 205.168.220.35 and Real base is 192.168.1.20, click OK. Repeat this for the remaining external IPs to be NATted (205.168.220.36 -> 192.168.1.13, 205.168.220.37 -> 192.168.1.37, 205.168.220.100 -> 192.168.1.4).
From the Dynamic NAT Exception tab on the NAT dialog box, select Add. In the To box, select external interface. Click the "..." button next to the From field and enter the Real (internal) IP address to be excluded. For each 1 to 1 NAT rule, exclude the Real Base IP here on the Exception tab. Repeat this for each internal IP used in each 1 to 1 NAT rule. NOTE: For 1 to 1 NAT to work, the external IPs NATted must NOT appear in Aliases under Network Configuration, and internal servers must NOT be multihomed with external IPs.
PPTP VPN
The firebox can be setup to accept VPN connections using the PPTP protocol. Open the Policy manager, and from the Network menu, select Remote User. From the Remote Users dialog box, click the PPTP tab, select the option "Activate Remote User," and add private IPs to be assigned to connections. For this procedure, class B IPs were used since the preexisting class C IPs were being routed to the LAN. IPs entered here for VPN clients must NOT be routed to the LAN or VPN connections will fail. Since the current setup for VPN connections only has a max of ten pptp users, only ten IPs were entered (172.16.0.1 through 172.16.0.10).
The firebox must now be setup to use "firebox" authentication as opposed to RADIUS or NT Server authentication. Open Policy manager, and from the Setup menu, select Firewall Authentication. Select Firebox and click OK.
Users must be setup to access the firebox from external sources. To setup users, open Policy manger, and from the Setup menu, select Authentication Servers. On the Authentication Servers dialog box, click the Firebox Users tab, and at the bottom, click Add to add a group for PPTP VPN access. In this procedure, the added group was named pptp-users. Now click Add at the top and enter username and password combinations for each user that will access the firebox via VPN and make each user a member of the pptp-users group. Click OK when finished adding users.
Lastly, if VPN users are to access the internet while connected, a new service should be created. Open the Policy manger, and add a new service. From the Services dialog box, under Packet Filters select PPTP and click OK twice. On the PPTP service dialog box, click the Incoming tab and change the drop-down menu for "Incoming PPTP connections are" to Enabled and Allowed. Replace "Any" in the From section with pptp-users, and replace the "Any" in the To section with external. On the Outgoing tab, replace the "Any" on the From section with external and replace the "Any" on the To section with pptp-users. Click OK and save this configuration to the firebox.
Domain Name Service (DNS) Configuration
In this procedure, there are generally two types of DNS servers, external and internal. External DNS servers are standalone standard primary servers and are represented by cygnus.example.com and ns2.example.com. For this procedure, external DNS servers should only contain public IP addresses, as they should for any configuration. Therefore, for hosts that are reached via a 1 to 1 NAT, each servers public IP should appear in the external DNS servers database.
Internal DNS servers in this procedure consist of Windows 2000 domain controllers (DC) running Active Directory DNS. Internal DNS servers should only contain private IPs. Since internal clients can access private IPs routed on the local network, to which internal DNS servers belong, there is no need to NAT requests to these servers from internal clients. In addition, internal DNS servers are not accessed by external clients, thus further nullifying the need for external IPs in the internal DNS server's database. NOTE: The linux box still contains NAT rules for requests for public IPs on the internal interface, and this is just to be thorough. Some internal client may be configured to directly request public IPs in use on the LAN. Since there are no longer any public IPs in use on the LAN, a NAT rule must be present to accommodate the request and return the corresponding private IP.
Enabling Domain Clients to Use Squid
Client browsers can be configured to use the proxy server via Group Policy. In the domain's Global Group Policy, edit the User Configuration>Windows Settings>Internet Explorer Maintenance>Connection>Proxy Settings. Select "Enable Proxy Settings" and enter 192.168.1.25 port 3128 for the "HTTP" line. Select "Use the same proxy server for all addresses" and select "Do not use proxy server for local (Intranet) addresses." Add the following to the "bypass proxy for these addresses": http://www.example.com, http://www2.example.com, etc.
Forcing Internet Explorer Clients to Use Web-Based FTP
A peculiarity of Windows 2000 and Internet Explorer was found that would allow ftp connections to bypass the proxy server. This peculiarity is the option in Internet Explorer to "Enable Folder view for FTP sites". This method of ftp uses an apparently alternate protocol and/or alternate port for ftp connections. A user blocked from internet access could use this feature to bypass the proxy server and gain access to the internet.
To remedy this problem, a workaround has been devised that utilizes Group Policy and a vbscript login script to disable Folder view and enable Web-based ftp.
In each schools GPO (the school's general GPO applied at the organizational unit (OU) level), disable changing any advanced options on the Advanced tab of the Internet Options control panel. To do this, open the GPO and navigate to User Configuration>Administrative Templates>Windows Components>Internet Explorer (click on Internet Explorer) and enable the option "Disable changing Advanced page settings."
To disable Folder view for FTP sites (enable Web-based ftp), create a vbscript. To do so, copy an paste the following text into a blank notepad document and save it as EnableWebBasedFTP.vbs. Copy this script to \\student.example.com\sysvol\student.example.com\scripts. Additionally, the script can be encoded using the Microsoft Script encoder to hinder a user from determining the mechanism the script uses to enable Web-based FTP. Download the script encoder from the msdn website and run it with the following command:
c:\screnc EnableWebBasedFTP.vbs EnableWebBasedFTP.vbe
‘--------------------------------------------------------------------
‘Enable Web-Based FTP
‘Language: VBScript
Dim WshShell
Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.RegWrite "HKCU\Software\ Microsoft\Ftp\Use Web Based FTP", "yes", "REG_SZ"
‘End Of Script
‘---------------------------------------------------------------------
To apply this script as a logon script designate it as a logon script in each site's GPO. Navigate to User Configuration>Windows Settings>Scripts(Logon/Logoff)>Logon and add the script. The next time the user logs onto the computer, Web-Based FTP will be enabled.
Performance Tuning the Squid Proxy Server
There are numerous options in the squid.conf file that can be configured, but most options will suffice with default values. There are however, a few options that can be modified to better suit this procedure. The following options can be changed from default:
http_port
X http_port 192.168.1.25:3128
icp_port
# Disable this by setting it to 0
X icp_port 0
cache_dir
X cache_dir ufs /usr/local/squid/var/cache 20000 160 2560
Positive DNS Cache TTL
X positive_dns_ttl 24 hours
cache_mgr
Currently, this option is set to webmaster. webmaster mail should be forwarded to your email address of choice.
cachemgr_passwd
Should be set for all
X cachemgr_passwd _your_password_ all
Previous page: LDAP Authentication from Apache to Active Directory
Next page: Free Windows Documentation and HowTos