Deploy the
Auth Connector

To create custom policy based on user and group names before those groups generate traffic, you must download the

Auth Connector

to at least one member server. The

Auth Connector

connects to the

Web Security Service

and provides the user/group information from the Active Directory (AD). See About the

Auth Connector

Integration, which provides more detail about the

Auth Connector

agent footprint

Technical Requirements

Direct Internet Requirement—The

Auth Connector

must have a direct connection to the internet. Do not allow the

Auth Connector

to connect through the same IPsec tunnel that goes to

WSS

For a list of required ports, see https://knowledge.broadcom.com/external/article?legacyId=tech245943.

The

Auth Connector

communicates with devices in the geographic data centers. The Symantec Operations team maintains the following Knowledge Base article that provides a list of authentication IP addresses. You might require these for local firewall rules.

WSS Datacenter IP Addresses

Member Servers Installation Prerequisites

The installation requires the following:

The user performing the install must be a member of the Domain to which the

Auth Connector

is installed.

The user must have local administrative privileges on that machine.

The following specifications are a current recommended benchline:

Windows Server 2012 R2 OS.

Windows Server 2019—This platform might require additional configurations as described in the procedural section.

8V CPUs.

32GB of memory.

1TB of disk space, which allows for I/O operations and any required debugging logs.

Only install the

Auth Connector

on a read-only
server that does not require protection provided by

WSS

. Connections to the service will work, but all users connected to that datapod location display in reports as

unauthenticated user

On the member server, verify that the Authenticated Users read access is appropriate. This is specific to Windows 2019. It is also applicable to the earlier versions where admins applied deeper security and the

Auth Connector

cannot retrieve all of the required information to validate users and groups.

The installation prompts for a username and password. These are configured as the account under which the

Auth Connector

runs. The user name must be in the form

ADDOMAIN\user

[email protected]_domainname.com

ADDOMAIN

is the NetBios name of the active directory. The installation grants this user account the

Log on as a service

privilege.

If the AD account password changes and the

Auth Connector

restarts,

WSS

cannot identify users until the password matches.

The

Auth Connector

requires that a newer Entrust CA certificate

Entrust(2048)

be installed on the member server on which the

Auth Connector

runs. Verify this by browsing the Trusted Root Certification Authorities certificate list within the local machine store with

mmc.exe

and the certificates snap-in. If this Entrust certificate is not present in the list, update the CA certificates by downloading an update program from Microsoft at the following location: http://support.microsoft.com/kb/931125.

About Failover

To achieve failover, install the

Auth Connector

on a second member server. If you install two

Auth Connector

s, you must designate one as the primary and the other as the secondary. Both must be installed on live systems as they simultaneously connect to

WSS

. If the primary member server goes down, the backup immediately assumes the task.

About Proxy Aware Capability

The

Auth Connector

is proxy-aware. If you prefer to route

Auth Connector

traffic through a proxy, you can manually configure the

bcca.ini

file to include proxy connection information. This process is described in

Step 7

in the following procedure.

Procedure

Prerequisite—Decide which User and Group names are forwarded to the service.

By default, the

Auth Connector

returns all group and usernames in your LDAP deployment to

WSS

for use in custom policy creation. This might not be practical for an enterprise network that contains multiple user groups and large volumes of users. The

Auth Connector

returns the following:

All domain names that can be seen.

All users (

sam

account names) from each domain.

All groups from each domain (security groups; not
distribution groups).

All members of each group—users (

sam

account names).

Sending that information volume might cause

Auth Connector

resource constraints. For large LDAP deployments, select all users but decide which groups require policy and forward only those to the

WSS

. For example, you have domains named

HQ-QA

HQ-SALES

, and

HQ-OPERATIONS

, and only users in the

HQ-SALES

domain require policy checks.

The

bcca.ini

file, which is part of the

Auth Connector

application (and described in the

Step 4

procedure in this topic), contains

[Groups]

and

[Users]

sections. You can add entries to one, either, or both.

If the

[Groups]

and

[Users]

sections are empty,

WSS

receives traffic from all domains and users.

If the

[Groups]

section contains a domain entry (for example,

HQ-SALES\

), then all groups within that domain send traffic to the cloud service.

To further narrow the scope with domains, add group names. For example:

HQ-SALES\RegionA

The

Users

section functions in the same manner. Add specific users to further limit the traffic sent to WSS. For example:

HQ-SALES\thomas.hardy

To prevent a full transmission of all user and group names, do not open the firewall for outbound

443/tcp

from the

Auth Connector

before you complete this procedure.

Step 1—Add an
Auth Connector
location to the
WSS
.

Navigate to

Identity > Auth Connector

Click

Add Auth Connector

Connect to the service.

Name

the service.

Define a

Password

. Record this password, as it is required during the

Auth Connector

application installation.

Comments

are optional.

WSS

generates

Your Auth Connector Unique Name

, which is a unique customer identification. Record this value, as you must enter it during the

Auth Connector

application installation process. You can also see the name later by click

Edit

on the

Identity > Auth Connector

page.

Click

Save

Step 2—(Optional) Add a Backup
Auth Connector
location.

For authentication failover, add a backup

Auth Connector

location that will receive data from a second, live domain controller. Repeat

Step 1

After configuring, verify that you have the correct

Auth Connector

Set to Primary

Step 3—Download the
Auth Connector
.

If you downloaded the

Auth Connector

agent during the Initial Configuration Wizard process, skip to

Step 4

Remaining on the

Identity > Auth Connector

page, expand the

Download Installer

area.

he right side of the

Download Installer

area provides a

Release Notes

link, which opens the help topic: Recent Auth Connector Releases.

Click

Download

If this is the first time you are attempting to download the application, the portal displays the Profile dialog.

As a company that provides security services across the globe,

Symantec

supports and complies with United States and local export controls. As an authorized member of your enterprise/organization, you must complete this form before downloading the

Auth Connector

Click the

Ensure...enterprise account

link, which opens your Broadcom profile page.

Complete your enterprise information and click

Verify and click

Upgrade Account

. Broadcom sends a confirmation email.

Return to the portal, log out, and log in again. If you do not, you still cannot download the agent.

If you have access from your workstation, save the application to a directory of your choice on the domain controller. If you do not, download the application locally and transfer it as necessary.

Step 4—Modify the .ini File to Include Specific Users/Groups.

As described in the

Prerequisite

step, the process to add domains, users, and groups is manual.

Access the server that has the

Auth Connector

application.

Using a text editor, open the

bcca.ini

file. If you installed the

Auth Connector

in the default directory, find it in:

C:\Program Files\Blue Coat Systems\BCCA\

Locate the

[Groups]

and

[Users]

sections and add entries. You must use the same letter cases that match what is in the Active Directory. Add one entry per line. For example:

[Groups]

HQ-SALES\NAWest

HQ-SALES\NANorthWest

[Users]

HQ-SALES\Administrator

Save the file.

Step 5—Install the Primary
Auth Connector
on a Member Server.

This installation process grants this account the

Log on as a service

and

Act as a part of the operating system

privileges.

There are two methods that create and maintain the IP-to-User map. The

Auth Connector

setup wizard described in this step provides a choice.

Domain Controller Query—This is the default method for all connectivity methods. The Domain Controller Query (DCQ) instructs the

Auth Connector

to query all the domain controllers in your AD to identify users by their IP address when they log on. Each domain controller is contacted every 10 seconds to ensure detection of all logged on users. The

Auth Connector

contacts the

WSS

Control Pod through

auth.threatpulse.net

on port

443

and transfers the AD users and group names.

WSS

returns IPsec endpoint information to the

Auth Connector

ACLogon Application—For very large enterprises with many domain controllers deployed in different locations, the DCQ method might create scalability issues. Some user logons might be missed because the domain controllers cannot respond fast enough. The alternative is obtain the ACLogon App and make it available to each client system.

Step 8

describes how to distribute the application.

On the member server, navigate to where you downloaded the

Auth Connector

application and run the

AuthConnectorInstaller-#####
.exe

file as Administrator.

Accept the standard program allowance and click

on the first Wizard page.

The Select Installation folder page prompts the installation directory choice. Click

to accept the default (

C:\Program Files\Blue Coat Systems\BCCA\

) or select another directory.

Click

to begin the

Auth Connector

configuration wizard.

Enter the Active Directory account access credentials and click

Link this

Auth Connector

installation with

WSS

by entering the

Auth Connector Unique Name

and

Password

that you obtained/defined during

Step 1

Click

Do you plan to implement Security Assertion Markup Language (SAML) authentication and employ the

Auth Connector

to serve as the Identity Provider (IdP)?

This example procedure does not include the

Auth Connector

as a SAML IdP functionality. See Deploy

Auth Connector

as SAML IdP.

Select

and click

Does your

WSS

deployment involve Firewall/VPN locations?

Yes

, select

We have (or plan to have) a Firewall/VPN Access Method

, click

, and proceed to

Step 7

, select

We do not have a Firewall/VPN Access Method

, click

and proceed to

Step 8

Firewall/VPN method only—As previously described, select how the

Auth Connector

resolves and maintains the IP-to-user map.

Select an option.

Domain Controller Query method

—Queries all domain controllers, although you can restrict the list.

Symantec

ACLogon Application

—This option is designed for very large enterprises with many domain controllers deployed in multiple locations.

Click

If you selected the

Logon App

option, you are again prompted with the request to open port

on the device firewall. Click

Click

Install

After the installation completes, click

Finish

Step 6—(Optional) Repeat Step 5 to install the backup
Auth Connector
on a second, live member server.

The

Auth Connector Unique Name

is slightly different—the same number appended with the name you assigned in

Step 1

Step 7—(Optional) Route Auth Connector traffic through a proxy.

An alternative to the direct connection to

WSS

(on the default ports) is to route the

Auth Connector

connection through a proxy. Your enterprise deployment standards might dictate this requirement. To achieve this, you must manually edit the

bcca.ini

file, which is included in the

Auth Connector

package installed on the server.

Access the server that has the

Auth Connector

application.

Using a text editor, open the

bcca.ini

file. If you installed the

Auth Connector

in the default directory, find it in:

C:\Programs and Files (x86)\Blue Coat Systems\BCCA\

The first few lines of the file contain the proxy settings.

[Setup]
; proxy host to explicitly connect through, assumes port 443 on connect
; Proxy=
; Explicit proxy port to use to connect to proxy, default 8080
; Proxy_Port=

Add your settings as required:

Specify the DNS name (or IP address) of the proxy.

[Setup]
; proxy host to explicitly connect through, assumes port 443 on connectProxy=example.proxy.com

If the default connection port is not 8080, enter the correct port.

[Setup]
; proxy host to explicitly connect through, assumes port 443 on connectProxy=example.proxy.com
; Explicit proxy port to use to connect to proxy, default 8080Proxy_Port=8085

Save the file.

Allow the service to process some traffic, then check various reports to verify that you are receiving traffic from the specified groups/users.

Step 8—For Windows Server 2019 and DCQ Method Only

This step is only required if the member servers with

Auth Connector

are interacting with Windows Server 2019 through the domain controller query (DCP). Skip to

Step 9

if you are implementing the ACLogon method.

Beginning with Windows Server 2019, Microsoft added more restrictive access control to the

NetSessionEnum()

API. However, the

Auth Connector

uses this call to query domain controllers for user sessions (when DCQ is the method). In versions previous to Windows Server 2019, members in the

authenticated users

group were able to perform the call because any account that logged in automatically became a member of the

authenticated users

group while logged in. In Windows Server 2019, Microsoft removed the

authenticated users

group and replaced it with the

administrators

computer operators

, and

power users

groups. Therefore, the

Auth Connector

cannot receive the authenticated users from the domain controllers. This results in a

cannot query domain controller <ip>; status=5:0x5:Access is denied

error message.

You must perform one of the following methods to complete the configuration for this method.

Option 1

This is the simplest but least secure option because the permission levels are elevated. In fact, your organization's security guidelines might rule that this option is unacceptable. Add the

Auth Connector

service account user to the

computer operators

group, as this group exists only on servers. The

administrators

group elevates the permissions too high and the

power users

group exists only on workstations.

Option 2

Change the registry value that Microsoft uses for

NetSessionEnum()

to allow the

Auth Connector

service user access. This option is the more secure choice.

Only experienced network administrators should perform this option.

You must run a powershell script on every domain controller (and any subsequent domain controllers you might add at a later time).

Obtain the script:

Auth Connector Powershell Script

Backup the registry key in case there is an issue that requires a revert.

HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\DefaultSecurity\SrvsvcSessionInfo

You must run the script as an administrator with elevated privileges. The elevated privileges are required to write the updated security descriptor
to the registry.

If the script is run with no parameters, it prompts for the domain and user. The specified user (typically, the

Auth Connector

service user) is added to the Discretionary Access Control List (DACL).

The specified user can also be a group that is allowed access to

NetSessionEnum()

. In this case, the

Auth Connector

service user must also be a member of the specified group.

Step 9—(If Necessary) Distribute the ACLogon to Client Systems

If you selected the ACLogon option as your

Auth Connector

solution, you must make the ACLogon application available on all client systems.

Do not
enable DCQ and ACLogon at the same time. This can result in misidentified users.

Obtain the application and release notes.

ACLogon App [right-click]

The easiest way to deploy the application is by Active Directory logon and logoff scripts implemented through group policy and the group policy editor in the AD. Any updates to the ACLogon version are then applied to the software on the AD, not the endpoints. The application is very small and does not consume disk space on the endpoint device.

By default, both the DCQ and ACLogon create IP address mappings in the

Auth Connector

without a time-to-live (TTL). The

Auth Connector

configuration file (

bcca.ini

) can define a TTL in seconds for IP mappings. This is done in the

[CLSetup]

section.

Combining this with the ACLogon

/interval seconds ####

to periodically update the IP mapping keeps the

Auth Connector

table up to date. Also, the ACLogon

/logout

parameter triggers an update on any user logout or restart event to clear that IP address' entry.

Example Configuration

Setup a GPO with a login/logout script.

Aclogon.exe /logoff /interval seconds 3600  Auth-Connector_hostname/IP

In the

Auth Connector

bcca.ini

file, add

ValidTTL 7200

in the [CLSetup] section.

The ACLogon authenticates to the

Auth Connector

every hour. If the

Auth Connector

does not receive an update from the ACLogon for that IP address within two hours, the IP address is removed from the mapping table. With

/logoff

specified for ACLogon, the IP address is removed from the table if the user logs out, restarts, or shuts down the machine.

Step 10—Retrieve the User and Group Names from the AD.

WSS

responds reasonably quickly to new AD integrations. After that,

WSS

automatically performs an AD refresh once a week to poll for newly added users.

Group memberships are identified through a different process, however.

WSS

re-queries group membership every 15 minutes (for active log-ins and users who are already authenticated).

If you add a user to a new AD group and the user is not
yet connected and authenticated,

WSS

identifies their group membership when they connect.

If you add a user to a new AD group and the user is
already authenticated, it can take nearly 15 minutes for

WSS

to re-query group membership.

To perform an on-demand retrieval of all user and group names, return to the

Identity > Auth Connector

page and click

Sync With AD

. Be advised that it might take up to 24 hours for you see the information in your portal. Avoid re-clicking the button more than once in a 24-hour period; doing so might overly clog the sync queue, causing slower results.

Step 11—Verify the Connection/Icon Descriptions.

As traffic begins to flow through

WSS

, you can monitor the

Auth Connector

connections.

The following screenshot illustrates two

Auth Connector

s performing with no issues.

The following screenshot illustrates that the

Auth Connector

has connection issues.

Click the

details

link. The portal displays a dialog that provides details, including the IP addresses to which the

Auth Connector

is trying connect, and troubleshooting suggestions.

Back on the

Auth Connector

page, review the status icons.

Icon	Connection Status Description
	WSS and the installed Auth Connector are communicating successfully.
	WSS and the installed Auth Connector are communicating, but some connections (data path) are failing. Click the details link for more information. WSS displays a dialog that contains IP address attempts and common troubleshooting tips.
	WSS has not yet detected this Auth Connector .
	Error —There is an credential error. Verify that the Auth Connector credentials in WSS match the credentials used on the server. —This Auth Connector is disconnected. Disconnected since: date time . Verify WSS and Domain Controller configurations.

In the

WSS

portal, click any report in which you expect to see user/group name information.

If you recently added new users and/or groups to the Active Directory, they might not display in reports or display when selecting policy options because

WSS

performs an automatic sync operation once every 24 hours. To perform an immediate, manual sync, click

Refresh

Click

Messages

(upper-right corner) and look for authentication errors.

Example Configuration:

Setup a GPO with a login/logout script.

Aclogon.exe /logoff /interval seconds 3600  Auth-Connector_hostname/IP

In the

Auth Connector

bcca.ini

file, add

ValidTTL 7200

in the [CLSetup] section.

The ACLogon authenticates to the

Auth Connector

every hour; if the

Auth Connector

does not receive an update from the ACLogon for that IP within two hours, the IP is removed from the mapping table. With

/logoff

specified for ACLogon, the IP is removed from the table if the user logs out, restarts, or shuts down the machine.

Next Steps

Review Imported Users and Groups

Exempt From Authentication

Authentication Location Policy

Or return/proceed to:

Connectivity—About Virtual Private Network (IPsec)

Connectivity: About Proxy Forwarding

Connectivity: About the

WSS Agent

About the Auth Connector Integration

Web Security Service

Deploy the Auth Connector

Technical Requirements

Member Servers Installation Prerequisites

About Failover

About Proxy Aware Capability

Procedure

Example Configuration:

Next Steps

Deploy the
Auth Connector