Here is a snippet from some more documentation:

If the content filter can derive the username it can make classifications as to which policy to apply based on that username and the group membership of that user. The order of the content filter groups is important. The default policy is the top filter group and it is the one that gets applied both FIRST and LAST. First, if the username is NOT specified and LAST if it the username was specified but didn't match. The policy is a first match first apply policy. If a user belongs to multiple groups, the policy listed in which they first match is the one applied.

In order for the proxy server to receive a username, the browser must supply it. The only way that this can occur is if the proxy server is specified in the browser settings. There are two methods for applying configuration setting for use with User Authentication:

SO here is how the list will appear in Webconfig:

Default Policy
Policy 1
Policy 2
Policy 3
Policy N

Here is how they are actually applied:

Policy 1
Policy 2
Policy 3
Policy N
Default Policy

The content filter policy list is a bit deceptive since the first thing listed is the default policy. Nick is right that the first match is what is applied. This excludes the default policy which is the policy applied if no other policy is triggered.

When using authentication with your content filter is it important to pay attention to the squid/access.log file for user authentication hits and the dansguardian/access.log for the group authentication hits.

If your user authentication is not happening in the squid log then the group won't happen and they will get the last policy, the default one. The allusers is not really important but is useful because the default policy is the very LAST policy to be hit and in this case, they match. But even if your traffic did NOT include a match to allusers it would still apply the default policy. Best to look in the squid log file to see if user authentication is actually happening. So the allusers is a bit of a red herring since it doesn't apply here to the process. If your users are making it all the way to the default policy is it because the system was unable to match then to a particular group in the accounts driver or they didn't authenticate.

You can actually use different browsers to test this since the different browsers have differing support for the transparent NTLM authentication. IN this case, IE will try NTLM authentication but other browsers like Firefox will not behave like this by default. So if you launch firefox and the proxy does NOT ask for a username and password you can validate that the authentication aspect is not happening at all.

Win7 roaming profiles are different but should work. They use the v2 extension. If you want to preserve the users directory you will need to do a backup and restore on version 7. You will also need to implement or make sure you are using a filesystem that already has implement the ACL support so that user's permissions will work on the new .v2 profiles.

Because of the complexity of roaming profiles, I recommend that you do a test migration first to non-production hardware so that you can work out any profile bugs beforehand.

https://wiki.samba.org/index.php/Roaming_Windows_User_Profiles

This app lost traction in the 7 update cycle and didn't have any energy behind it. It can be resurrected here by anyone who wants to re-tool it for ClearOS 7. Here is the source code:

https://github.com/dsokoloski/app-ether-wake

Andreja,

Backup your ldap database files and then run a repair and see if that helps. If you had some corruption in the existing database then it could have presented itself as a non-tenable situation upon update:

https://www.clearos.com/resources/documentation/clearos/content:en_us:kb_troubleshooting_openldap_fails_to_start

The nice thing about this service is that if you backup the following files then you can fully revert even after you make the delete of the scope:

/etc/ethers/
/etc/dnsmasq.d/dhcp.conf
/var/lib/dnsmasq/dnsmasq.leases

That howto is for ClearOS 6. I've updated some of the document to reflect that.

I've updated the doc also to include your suggestion as the proper method to follow and have placed a link in that document so that it goes to this forum post which can and should be used for any discussion on the matter in the future. Thanks for helping us out and for your insightful review of the process.

-DaveLoper

Perhaps it will remove them. These 'static' leases should show up in the /etc/ethers file. Simply back that up and restore it with the correct interface name after you re-create the scope.

Validate your interface names ('ip addr') and copy and paste instead of retyping. Small 'L' can look like 1 and other gases can exist.

When in doubt, execute your iptables rules one at a time on command line.