We use cookies on our website to ensure we provide you with the best experience on our website. By using our website, you agree to the use of cookies for analytics and personalized content.This website uses cookies. More Information
It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda Web Security Service

Initial setup concerns with Authentication and WSS

  • Type: Knowledgebase
  • Date changed: 4 years ago
Solution #00007211

All Barracuda Web Security Flex gateway units, all firmware versions, also using WSG (Web Security Gateway) device / WSA (Web Security Agent) IWSA for MAC / Barracuda safe browser / or Proxy only.

Answer:     also see Solution #00005502 for deployments
In order to setup authentication when using a WSG device. You will need to go to your Portal account and login, then to the Web security section, and then the support tab all the way to the right on the site page. This will show you your account info and the downloads available as needed.
Download the DC agent. For use on your Domain Controller(s) , this will watch for user log on events in the security filter of your DC events to record and see that users are authenticated to your domain. See details below
                  Link to Agent for 2003 servers: https://www.copy.com/s/C2gvFWqZnKUd/
While the Web Security Service(WSS) can be integrated with any LDAP or Active Directory servers, the DC Agent link above may only be used with 2003, a newer agent (download links on support tab) must be used on 2008, and 2012 versions of Active Directory. The DC Agent must be installed onto each of your domain controllers that will see any login events from your users in order to function properly, caveat to install on remote machine for multiple DCs to be monitored, to limit installations needed.
See article for setup details of AD here:
 If using Proxy only via your firewall, you need a key created in the portal for your Corporate firewalls IP, to be used. This will let us know the traffic is intended for your account when seen.
See setup here
If using the WSA , IWSA, or Safe Browser, you may follow setup for the WSA to create a WSA Key instead, and use this for the ability to communicate to the cloud for your account.
This will work properly once you have follow that setup and if using LDAP. You may sync LDAP to the cloud or upload an LDIF file for your group information,
Then you can have a user log in to the WSA PC and be seen as their name and be filtered towards a group with their name in it..
See setup here
DC Agent 6.x and 7.1.x (see per server setup in next section below).
Launch the installation file (DCAgent.exe) By choosing to “RUN AS ADMINISTRATOR” and follow the instructions in the wizard.
After the Barracuda DC Agent is installed and running correctly, launch the application and complete the following steps.
Note: Your entries in the DC Agent interface will NOT be saved until you click the Save button.
1.     Define location and login credentials for your Active Directory. Click the Active Directories tab and click the green + sign to add a domain.
a. Select Local if you installed the DC Agent on the Domain Controller; select Remote if you installed on another machine on the network. DO NOT CHOOSE REMOTE OTHERWISE, IT WILL CAUSE A FAILURE TO FUNCTION!
b. If you selected Remote, enter the Fully Qualified Domain Name (FQDN) in the Host field.
c. Enter a name for referring to the domain, e.g. 'Finance', 'Salesnet', etc.
d. The Username should be associated with permissions to run WMI queries on the domain controller. Enter that user's Password and click OK.
e. Click Test to verify connectivity with the domain controller.
·         On Appliances tab add the internal IP Address and a Description for each Barracuda Networks Web Filter which you want to use the DC Agent for.
·         On the Filters tab, specify the IP Address for any client PCs or networks for which you don't want the DC Agent to capture and send login information to your Barracuda Networks products. These are exceptions and associated login events will be ignored by the DC Agent.
·         On the Settings tab add or check the Appliance Listening Port - If required, you can change the TCP listening port. Make sure that you also specify the same port on all configured Barracuda Networks products. Default is port 5049.
f. Check the services currently running on your Domain Controller itself and make sure the Barracuda DC Agent is set to Automatic and turned on and ONLY HAS ONE service running if this was a re-install or an update!
 Listening for Logon Events
In order for the DC Agent to pick up the user names we need all domain controllers to enable logon events.
 Windows Server 2003 configuration
1. Open Domain Controller Security Policy under Start > Programs > Administrative Tools. Be sure to open Domain Controller Security Policy and not Domain Security Policy, as the Domain Controller Security Policy takes precedence over any Domain Security Policy that may be configured (for each domain controller specifically).
2. Click on Local Policies, and then Audit Policy.
3. Make sure both Audit account logon events and Audit logon events have Success in the Policy Setting column.
4. Once the event tracking is turned on, all new logon events will trigger updates to the Barracuda. So be patient with the process after you have turned it on.
 Windows Server 2008 configuration
1. Navigate to Start > Administrative Tools > Local Security Policy.
2. Click on Local Policies > Audit Policies.
3. Make sure both Audit account logon events and Audit logon events have Success in the Policy Setting column.
4. Once the event tracking is turned on, all new logon events will trigger updates to the Barracuda Web Filter. It may take time to start tracking new events, please be patient.
Windows Server 2012 configuration
1. Open the Server Manager.
2. Click Tools > Local Security Policy.
3. Make sure both Audit account logon events and Audit logon events have Success in the Security Setting column.
4. Once the event tracking is turned on, all new logon events will trigger updates to the Barracuda Web Filter. It may take time to start tracking new events, please be patient.
5. additional administrator setting details for 2012 setup.
For 2012 servers there is some additional information here from a customer with issues passing events.  
DC agent issues found with security policy in 2012 with customer recently
Server 2012 has a different audit policy structure than previous versions.   After some research I have found a section for advanced auditing which may solve our problem.  Though I could see logon events before, it would not show me the users name or IP, just their SID. 
For your records, if this works, these are the advanced settings I have included in the GPO.  Once I have let this run for a day I will let you know if this changes anything.
Computer configuration \Policies \Windows Settings \Security Settings \Advanced Audit Policy Configuration
NOTE:  When using advanced audit policy configuration, you must have "Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy settings" enabled under Local Policies\Security Options.
Setting: "Audit logon" in the Logon / Logoff policy. This option will write an event to the security log whenever a user logs on.  For the full picture you should check the boxes to audit both successful and unsuccessful logon attempts. 
Large numbers of unsuccessful logon attempts can indicate the presence of an attack on your network.
Setting: "Audit user account management" in the Account Management policy Setting this option will write an event to the security log whenever certain edits are made to user accounts, including the creation and deletion of accounts. 
It will also alert you to any changes in permissions for network administration level user accounts.  Combined with setting three below this is a useful way to track changes in authorization levels for all accounts and especially the admin accounts.
Setting: "Audit Security Group Management" in the Account Management policy
An event can be written to the security log every time an edit is made to any security group.  You should check the boxes to audit both successful and unsuccessful group management attempts.   Auditing this allows you to see if someone is trying to grant themselves additional security rights without authorization to do so.
Checking Connection on port 5049, with installed DC Agent
If the DC Agent has been installed and is running on each relevant domain controller, you can verify it is working by using telnet on a machine to determine that port 5049 is able to talk.
If the machine is able to communicate properly with the domain controller, you should see something like this: ( and as long as the Gateway device is not restricted in any other way than the PC used)
$ telnet 5049
Connected to
Escape character is '^]'.
If you do not see the 'Connected to' message, then the WSG may also not be able to communicate with the specified domain controller on the necessary port, 5049.
Once connectivity to your domain controller(s) has been verified, check to make sure the DC Agent is properly generating network logon events.
You can do this by logging onto your domain controllers and navigating to Start > Programs > Administrative Tools > Event Viewer. Click on Security Filter, and you should see Success Audits with Event IDs like 538 and 540 (Windows 2003), and 4624 (Windows 2008 and 2012).
This means the domain controller is generating the proper Active Directory logon events.
If you are on a Windows 2012 Domain Controller, and the 4624 event ID's are not being generated, make sure that Logon/Logoff is set to "Success", this setting is found in the Windows Advanced Audit Policy Configuration.
You will also need to configure the Web Security Gateway (if used) to use the DC agents. This is done by navigating to the Web security Portal section, then on the Configuration tab, then you will see the gateway page to enter (once the gateway is setup and activated), then click the desired gateway seen to use, now once in here you will see more pages to use, click on Authentication page here and see section for LDAP (this should be setup if not already) once setup you will see the DC agent section to add Domain controllers. After setting the Enable Single Sign On option to Yes, here's what you need to enter for each of your domain controllers:
·         IP Address of Domain Controller - IP address of the primary domain controller (PDC). The Barracuda Web Filter needs the IP address of the PDC to poll the DC Agent for the list of authenticated users.
·         DC Agent Listening Port - The port used by the DC Agent to communicate with the Session Monitor on the Barracuda Web Filter. The recommended port number is 5049.
·         Synchronization Interval - The time interval (in seconds) at which the Session Monitor polls the DC Agent for the list of authenticated users. The recommended value is 15 seconds.
Once all of this is finished, your WSG should now properly associate web browsing with Active Directory users. If you would like to configure browsing rules based on the Active Directory identity of the browsing user, you may do so on the Rules page. To do this, first create a rule, and then name the rule, Now you can set to applies to everyone, a new group(needs a user added to the group after creation, or set to a group available with your username in it, or by IP address, block desired traffic for testing. Now move this rule to the top, just below the default threat rules, in the list of exception rules. Test the functionality and then modify rule and placement as necessary, and test again.

Additional Notes:
In some cases, Barracuda DC Agent configuration changes may not be applied to a running Barracuda DC Agent process. If (after configuring everything above) the Barracuda DC Agent is not syncing users seen in the Forensics page under the Reports Tab, try restarting the Barracuda DC Agent process.
Also it is not always necessary to update the DC Agent version when updating the firmware on the web filter, as new firmware should be backwards compatible with older DC Agents.
You may be getting error Bad bind DN, error code 8, stronger authentication required, while configuring your LDAP authentication service, this mean that your Domain Controller doesn’t support  LDAP_Simple_ Bind requests.
You need to modify the Domain Controller security settings:
1. Click Start > Run > gpedit.msc
2. In the Group Policy Object Editor, select the following: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
3. In this section, search for the following entries:
Domain Controller: LDAP Server signing requirements.
Network security: LDAP Client signing requirements
4. To enable simple binds, set the above as follows:
Domain controller: LDAP server signing requirements = None
Network security: LDAP client signing requirements = Negotiate
The DC agent, is for seeing a user as authenticated ONLY, to the domain. (needed with WSG use)
The LDAP setup, is to allow access to LDAP for SYNC to update services to apply policy. (needed for BSB and/or WSG use)
The Sync tool, is to allow ability to update LDIF or groups/user info to the cloud for rule creation and reporting against. (needed for use with WSS in Cloud for groups).
The WSA uses the log in name as its authentication name to apply to for rules.

Link to this page: