Printable View
From reading around, I think the answer is "no", but....
Is it possible for Squid to authenticate a user via LDAP and then pass the username (or group/some other flag) to Dansguardian so it knows whether they are in a particular filtergroup?
My current setup is:
Or have I got to put Dansguardian in front of Squid in order to assign filtergroups to users?Code:User --> Squid--> Dansguardian & ClamAV --> Internet
|
|
LDAP
Auth
I thnk you need the latest release of DG which might be alpha but Geoff says it runs fine. I think that version can do NTLM etc.
Yes squid can pass user info onto dansguardian.. you would do it this way to see which user goes where in the logs. As to how you setup the filter groups to match the group the user belongs to, im not entirely sure.
You need to use the new version of DG. You need to put it in-front of Squid. You need to configure Squid to use NTLM authentication. Then it works.
Is there anyone who can help with more detail please?
Regards
Hi,
I have a squid proxy with out any authentication enabled as it is not needed for us.
Our students use windows machines which authenticate to a windows AD.
We did have a need to be able to record the user that was accessing our proxy for log stats and accountability.
What I ended up doing was enabling ident in squid for all our vlans and installed an indent service on the windows machines which allows squid to record their names. This has worked for us pretty well.
If you need more help with this let me know and I'll gladly share my settings with you.
Regards,
Craig
I use a script that trawls users from an LDAP request. This is scheduled twice daily (takes under 10 seconds to run with 700 users in the domain). Compares current list to new list and creates my 3 filter groups from it. I have an "exceptions" list where I can redefine users (such as administrators).
That way DG can look at the lists. This is not a LIVE option but will cut down on network traffic. I imagine the throughput could get quite large with hundreds of LDAP requests per second on a heavy network hence me wanting to script it to static lists.
Anyway here is my script if you want it - define your own LDAP string and groups.
Code:#!/usr/bin/perl
#Use
use File::Temp qw/ tempdir /;
#Globals
$global::tmp = "/tmp";
$global::last_update = "/etc/dansguardian/lists/lastupdate.filtergroupslist";
$global::admin_location = "/etc/dansguardian/lists/admins.filtergroupslist";
$global::dansguardconf = "/etc/dansguardian/lists/filtergroupslist";
$global::template = "/etc/dansguardian/lists/template.filtergroupslist";
@global::results;
#$global::ldapsearch = "/usr/bin/ldapsearch";
$global::ldapsearch = "ldapsearch";
$global::ldapbind_options = "-D \"cn=****,cn=users,DC=****,DC=****,DC=****,DC=****,DC=****\" -w \"****\" -h YOURSERVER -x -s sub \"CN=*\"";
# filter1 => "",
$global::groupmap = {
# filter1 => "ou=impossiblegroupname",
filter2 => "ou=Pupils",
filter3 => "ou=Staff",
# filter4 => "ou=Administrators"
};
#make a temp directory
my $TempDir = tempdir( 'dansgroups.XXXXXXXX', DIR => $global::tmp, CLEANUP => 1 );
#Main
open (INPUTINFO,$global::admin_location)|| die("Could not open file!");
@global::adminarray=<INPUTINFO>;
close(INPUTINFO);
print "\nStarting\n\n";
foreach my $filtername ( sort keys %{ $global::groupmap } ) {
my $ldapgroup_target = "$global::groupmap->{$filtername},dc=****,dc=****,dc=****,dc=****,dc=****";
#Now remove subgroups -mgt
$filtername =~ s/(filter\d)[a-z]/$1/;
#Open Pipe from Ldapsearch with grep filter
my $command_line= "$global::ldapsearch -b \"$ldapgroup_target\" $global::ldapbind_options | grep 'sAMAccountName: ' |";
print "\nParsing : $ldapgroup_target\n";
# open(LDAP, "$global::ldapsearch -b \"$ldapgroup_target\" $global::ldapbind_options | grep 'sAMAccountName: ' ") ||
open(LDAP, $command_line) ||
die "Unable to open ldapsearch: - $!\n";
while (defined(my $line =<LDAP>)){
chomp($line);
$line =~ s/^sAMAccountName\:\s+//;
$line = lc "$line";
$found="false";
foreach $admintest (@global::adminarray){
#print "-$admintest $line\n";
if ($admintest =~ $line){
print "$ldapgroup_target - $line (ADMIN override)\n";
push @global::results, "$line=filter4\n";
$found="true";}}
if ($found eq "false") {
print "$ldapgroup_target - $line\n";
push @global::results, "$line=$filtername\n";}
}
#my @search_results = LDAP;
close LDAP;
#Loop over results cleaning it up
#foreach my $line (sort {uc($a) cmp uc($b)} @search_results) {
# chomp $line;
# $line =~ s/^sAMAccountName\:\s+//;
# $line = lc "$line";
# push @global::results, "$line=$filtername\n";
#}
}
#Writeout tmp
open(RESULTS, ">$TempDir/ldapdata.txt") || die "Unable to open $TempDir/ldapdata.txt - $!\n";
for my $outline (@global::results) { print RESULTS "$outline"; };
close RESULTS;
#Now diff
system("/usr/bin/diff -b $TempDir/ldapdata.txt $global::last_update");
if ($? == 0) {
system("/bin/rm -f $TempDir/ldapdata.txt");
print "\nNo changes since previous list update!\n";
exit;
} elsif ($? == 256) {
#They differ lets update
system("/bin/cat $global::template $TempDir/ldapdata.txt > $global::dansguardconf");
system("/etc/init.d/dansguardian restart");
system("/bin/cp $TempDir/ldapdata.txt $global::last_update");
system("/bin/rm -f $TempDir/ldapdata.txt");
print "\n List file changed\n";
} else {
#Must be an error on the diff log it
system("/usr/bin/logger -p daemon.err 'Active Domain update failed diff test for Dansguardian! Needs helps.");
}
exit;
# vi: shiftwidth=3 tabstop=3 et
Hi
I could not get the ldap bit to work so I get usernames using a client program called ident. It then allows you to create filter groups for students, staff and admins. Its not pretty but it works ok.
Richard
Hi,Quote:
Originally Posted by cconnoll
We also a school aswell:) Teachers want to access to the internet without restriction of DG. For now Ive given to their desktop machines dedicated IP but wheneever they use other computers such as computer lab or a-other student areas they filtered. We also have windows xp machişnes with AD and seems pretty similar system we have.
To check network traffic I using NTOP and I only can see IPs not users.
If you can help me that would be greatly appreciated.
Best regards
I think this route is a great idea.Quote:
Originally Posted by KK20
I'm testing the script but having trouble getting the script to make updates. I am able to poll LDAP (e-dir) and get a list of users and groups but no changes are made. Do you have any tips on the initialization of the lastupdate.filtergroupslist an how the search of the LDAP data comes out.
If you would PM me I can send you a sample of the LDAP data.
Thanks!
I still use the same script (havent touched it since incept) so i'll dig it up and have a look again for you. One issue I did have with it is that I oculd only get it to work for OUs *not* security groups. I must admit I didnt spend too much time as principally I have already set our AD structure to have OU of PUPILS and STAFF.
lastupdate.filtergroupslist is literally that, a list of changes made during the last successful update. In short this file should mirror exactly dansguardians 'filtergroupslist' if the lastupdate.filtergroupslist is empty then no successful update has occured. You can tell if the script works because ALL of your names will whizz by. Here is a snapshot of a line during EXECUTION of the script:
ou=Staff,dc=xxxx,dc=xxxx,dc=sch,dc=uk,dc=local - testaccount
ou=Staff,dc=xxxx,dc=xxxx,dc=sch,dc=uk,dc=local - support staff
ou=Staff,dc=xxxx,dc=xxxx,dc=sch,dc=uk,dc=John Doe
inside both "filtergroups list" and "lastupdate.filtergroupslist" are the lines:
testaccount=filter3
support staff=filter3
John Doe=filter4
administrator=filter4
Note that John Doe is a filter4, that is because in the file /etc/dansguardian/lists/admins.filtergroupslist I have the following
John Doe
Jane Doe
Hence those two names will be set as filter4 even though they physically reside in the STAFF OU. You will also notice that administrator does NOT live in the STAFF or PUPIL OU but has been included as a filter4. That is because in the /etc/dansguardian/lists/template.filtergroupslist file I have the line:
administrator
The files /etc/dansguardian/lists/template.filtergroupslist and /etc/dansguardian/lists/admins.filtergroupslist must exist, even if empty!
if your lastupdate.filtergroupslist empty? If so then there is a problem further up the script and i'll help you fix that. If it is full of names then add a test account to one of your OUs and run the script again, did the new account appear in lastupdate.filtergroupslist?