Creating Authentication Policies

Non-transparent authentication policies enable you to apply a web filter policy and authentication requirements to a user, or group of users, whose web browsers are configured to connect to the Internet using Guardian as their web proxy.

1.

Go to the Web proxy > Authentication > Policy wizard page.

2.

Select Non-Transparent.

3.

From the Method drop-down list, select one of the following authentication methods:

Negotiate with the client device to identify whether Kerberos or NTLM authentication is required. This is particularly useful for client devices that have different levels of support for authentication methods, such as, browsers versus software applications. Guardian offers both methods to the client, and allows it to pick the most secure method supported.

The account specified on the Services > Authentication > Directories page must have permission to join the computer to the domain.

Note: Browsing devices must be joined to the same Active Directory domain for this to work seamlessly. However, devices not joined to the domain can still use this method of authentication, typically via a dialog requesting the user enter valid domain credentials.

Negotiate with the client device to identify whether Kerberos or NTLM authentication is required. This is particularly useful for client devices that have different levels of support for authentication methods, such as, browsers versus software applications. Guardian offers both methods to the client, and allows it to pick the most secure method supported.

The account specified on the Services > Authentication > Directories page must have permission to join the computer to the domain.

This method is designed to work with network clients using Microsoft Terminal Services (Remote Desktop Connection), where multiple users may be connecting from the same IP address. Authentication policies that use this method, cannot be used in group bridging deployments (see Using the Smoothwall Firewall).

Note: Browsing devices must be joined to the same Active Directory domain for this to work seamlessly. However, devices not joined to the domain can still use this method of authentication, typically via a dialog requesting the user enter valid domain credentials.

This method is designed to work with network clients using Microsoft Terminal Services (Remote Desktop Connection), where multiple users may be connecting from the same IP address. Authentication policies that use this method, cannot be used in group bridging deployments (see Using the Smoothwall Firewall).

Identify users by requesting a username and password from the user’s browser.

This method is designed to work with network clients using Microsoft Terminal Services (Remote Desktop Connection), where multiple users may be connecting from the same IP address. Authentication policies that use this method, cannot be used in group bridging deployments (see Using the Smoothwall Firewall).

Identify users according to the username logged into their Microsoft Windows workstation.

Note: NTLM identification does not verify a user's credentials. It should only be used where all client workstations are secured and members of a Microsoft Windows domain. Unsecured clients can spoof their credentials.

Guardian supports NTLM on Microsoft operating system software and browsers only. NTLM should not be used with any other browser or platform, even if the platform claims to support NTLM.

NTLM should only be used on single domain networks because the protocol does not support the transmission of domain information with usernames.

Identify users according to the username logged into their Microsoft Windows workstation.

Can be used in conjunction with Microsoft Terminal Services.

This method is designed to work with network clients using Microsoft Terminal Services (Remote Desktop Connection), where multiple users may be connecting from the same IP address. Authentication policies that use this method, cannot be used in group bridging deployments (see Using the Smoothwall Firewall).

Note: NTLM identification does not verify a user’s credentials. It should only be used where all client workstations are secured and members of a Microsoft Windows domain. Unsecured clients can spoof their credentials.

Guardian supports NTLM on Microsoft operating system software and browsers only. NTLM mode should not be used with any other browser or platform, even if the platform claims to support NTLM.

NTLM should only be used on single domain networks because the protocol does not support the transmission of domain information with usernames.

Identify users according to the username logged into their Microsoft Windows workstation, and validate their credentials with the domain controller.

Can be used in conjunction with Microsoft Terminal Services.

Prerequisites:

There must be a computer account for Guardian in Active Directory

The account specified on the Services > Authentication > Directories page must have permission to join the computer to the domain.

This method is designed to work with network clients using Microsoft Terminal Services (Remote Desktop Connection), where multiple users may be connecting from the same IP address. Authentication policies that use this method, cannot be used in group bridging deployments (see Using the Smoothwall Firewall).

Note: Guardian supports NTLM on Microsoft operating system software and browsers only. NTLM mode should not be used with any other browser or platform, even if the platform claims to support NTLM.

NTLM should only be used on single domain networks because the protocol does not support the transmission of domain information with usernames.

Identify users with the Guardian authentication service. If no user is logged in, redirect web requests to the SSL Login page which checks their username and password.

The Guardian authentication service supports only one user per client IP address.

Using this method, the SSL Login page automatically refreshes itself so that the authentication time-out period does not elapse; because of this, the user must leave the SSL Login page open at all times.

Select this method if a user’s browser cannot accept cookies. This method is also suitable if a user’s browser plugins or applications require the authenticated session to remain active.

SSL login is more secure than Ident or web proxy authentication because the authentication process between the user’s workstation and the Guardian system is encrypted.

To securely logout, the user must click Logout on the SSL Login page. For more information about the SSL Login page, including how to customize it to suit your organizational needs, see Using SSL Authentication.

Identify users with the Guardian authentication service. If no user is logged in, redirect web requests to the SSL Login page which checks their username and password.

The Guardian authentication service supports only one user per client IP address.

Using this method, Guardian stores a session cookie on the user’s browser. The cookie removes the need for the user to re-authenticate.

This method is useful for users of tablet PCs and other mobile devices which have problems keeping tabs in browsers open in the background.

SSL login is more secure than Ident or web proxy authentication because the authentication process between the user’s workstation and the Guardian system is encrypted.

To securely logout, the user must click Logout from the SSL Login page. For more information about the SSL Login page, including how to customize it to suit your organizational needs, see Using SSL Authentication.

Select this method if a user’s browser cannot accept cookies. This method is also suitable if a user’s browser plugins or applications require the authenticated session to remain active.

If the client is not logged in, web requests are redirected to the non-SSL login page, which checks their username and password.

Note: This page is not secure because it uses HTTP to submit the username and password, but avoids the certificate needed for SSL login.

The authentication service supports only one user per client IP address.

Using this method, the non SSL login page automatically refreshes itself so that the authentication time-out period does not elapse. Because of this, the user must leave the non-SSL login page open at all times.

To securely logout, the user must click Logout on the non-SSL login page. For more information about the non-SSL Login page, including how to customize it to suit your organizational needs, see Using SSL Authentication.

This method is useful for users of tablets and other mobile devices which have problems keeping tabs in browsers open in the background.

If the client is not logged in, web requests are redirected to the non-SSL Login page, which checks their username and password.

Note: The page is not secure because it uses HTTP to submit the username and password, but avoids the certificate needed for SSL login.

The authentication service supports only one user per client IP address.

Using this method, the Smoothwall stores a session cookie in the user’s browser. The cookie removes the need for the user to re-authenticate.

To securely logout, the user must click Logout from the non-SSL Login page. For more information about the non-SSL Login page, including how to customize it to suit your organizational needs, see Using SSL Authentication.

Identify users with the Guardian authentication service. If the user has not authenticated, they are identified by their IP address as the Guardian authentication service supports only one user by client IP address. The request is assigned to the Unauthenticated IPs group. If an unauthenticated request ends up at a block page, if configured, the user can choose to go to the SSL or non-SSL login page to attempt authentication.This way, you can control which sites anonymous users can access, with authenticated users gaining a higher level of access.

Identify users according to the username returned by an Ident server running on their workstation.

Ident does not verify a user’s credentials. It should only be used where all client workstations are secured and running an Ident server controlled by the network administrator. Unsecured clients can spoof their credentials.

Guardian supports Ident for compatibility with any Ident-enabled networks your organization may already be using. Networks supporting Ident authentication require an Ident server application to be installed on all workstations that can be queried by Ident-enabled systems.

The user does not need to enter their username as it is automatically supplied by the Ident server application.

Once a user’s Ident server has identified the user, the user’s web activities will be filtered according to their authentication group membership.

For details of how to configure this with your choice of Ident server, please refer to the Ident server’s administrator's guide.

Identify users with the Guardian authentication service. If no user is logged in, redirect Web requests to the Kerberos login page, which obtains the username logged into their Microsoft Windows workstation.

Identify the user’s device in order to redirect them to an NTLM authentication service, or an SSL login service. This redirect is based on the User-Agent data received in the browser’s HTTP header packet. This is a best-guess scenario, based on pattern-matching and compatibility.

Identify users with the Guardian authentication service. If no user is logged in, redirect Web requests to the NTLM login page, which obtains the username logged into their Microsoft Windows workstation.

The Guardian authentication service supports only one user per client IP address.

This option is for backwards compatibility with earlier versions of Guardian.

Identify users with the Guardian authentication service. If no user is logged in, redirect Web requests to the NTLM login page, which obtains the username logged into their Microsoft Windows workstation and validates their credentials with the domain controller.

The Guardian authentication service supports only one user per client IP address.

This option is for backwards compatibility with earlier versions of Guardian.

Identify users using the Secure Global Proxy service. Users must be logged in using NTLM credentials.

Note that even if your Smoothwall has multiple internal interfaces, you can only create one Global Proxy using NTLM authentication policy. Enabling this policy automatically adds firewall rules to allow external access to the proxy port.

Device authentication can be implemented using client-side certificates. For a detailed description of how to configure these, see Using Global Proxy Certificates on page 122.

From the Interface drop-down list, select the interface on which to apply the authentication policy.

5.

From the Port drop-down list, select the port on which to apply the authentication policy.

6.

If IP address spoofing is required, select Spoofing. This ensures that traffic leaving the Smoothwall has the source IP address of the client making the web requests, and not the IP address of the Smoothwall.

For customers with multiple external connections, enabling Guardian spoofing allows you to make use of source NAT and link load balancing policies (see Using Source NAT-ing and LLB Rules) to manipulate traffic to use specific links. For example, forcing students to use to use one link and teachers another, based on their source IP address.

Note: For networks that make use of multiple Guardians, such as, in a cluster, or centrally managed configuration, you should take steps to ensure reply packets addressed to the spoofed client are routed back through to the same Smoothwall. This ensures data is returned properly to the correct client.

Tip: If the Bandwidth Management add-on module has been installed on your Smoothwall (see About Bandwidth Management Shaping) you can control the bandwidth used by Guardian traffic, for example, limiting bandwidth available to your bring your own device (BYOD) network. It should be noted that a Layer 7 license is required to take advantage of the full functionality of Bandwidth Management. For more information, refer to your Smoothwall representative.

7.

Click Next and add the location at which the policy will apply.

8.

Click Next and review the options for handling unauthenticated requests.

When requests are permitted without requiring authentication, for example, entries on the Web proxy > Authentication > Exceptions page, Guardian assigns them to the Unauthenticated IPs group. If you want to assign them to a different group, add the group to the Included groups list.

9.

Click Next.

10.

Select Enable Policy.

11.

Click Confirm. Guardian displays the policy settings.

12.

Review the settings and click Save to make the policy available for use.

13.

Click Next and add the location at which the policy applies.

14.

Click Next and review the options for handling unauthenticated requests.

When requests are permitted without requiring authentication, for example, entries on the Web proxy > Authentication > Exceptions page, Guardian assigns them to the Unauthenticated IPs group. If you want to assign them to a different group, add the group to the Included groups list.

15.

Click Next.

16.

Select Enable Policy.

17.

Click Confirm. Guardian displays the policy settings.

18.

Review the settings and click Save to make the policy available for use. tumultuous

19.

Click Next and add the location at which the policy will apply.

20.

Click Next and review the options for handling unauthenticated requests.

When requests are permitted without requiring authentication, for example, entries on the Web proxy > Authentication > Exceptions page, Guardian assigns them to the Unauthenticated IPs group. If you want to assign them to a different group, add the group to the Included groups list.

21.

Click Next.

22.

Select Enable Policy.

23.

Click Confirm. Guardian displays the policy settings.

24.

Review the settings and click Save to make the policy available for use.

Identify users with the Guardian authentication service. If no user is logged in, redirect web requests to the SSL Login page which checks their username and password.

The Guardian authentication service supports only one user per client IP address.

Using this method, the SSL Login page automatically refreshes itself so that the authentication time-out period does not elapse; because of this, the user must leave the SSL Login page open at all times.

Select this method if a user’s browser cannot accept cookies. This method is also suitable if a user’s browser plugins or applications require the authenticated session to remain active.

SSL login is more secure than Ident or web proxy authentication because the authentication process between the user’s workstation and the Guardian system is encrypted.

Select this method if a user’s browser cannot accept cookies. This method is also suitable if a user’s browser plugins or applications require the authenticated session to remain active.

If the client is not logged in, web requests are redirected to the non-SSL login page, which checks their username and password.

Note: This page is not secure because it uses HTTP to submit the username and password, but avoids the certificate needed for SSL login.

The authentication service supports only one user per client IP address.

Using this method, the non SSL login page automatically refreshes itself so that the authentication time-out period does not elapse. Because of this, the user must leave the non-SSL login page open at all times.

To securely logout, the user must click Logout on the non-SSL login page. For more information about the non-SSL Login page, including how to customize it to suit your organizational needs, see Using SSL Authentication.

This method is useful for users of tablets and other mobile devices which have problems keeping tabs in browsers open in the background.

If the client is not logged in, web requests are redirected to the non-SSL Login page, which checks their username and password.

Note: The page is not secure because it uses HTTP to submit the username and password, but avoids the certificate needed for SSL login.

The authentication service supports only one user per client IP address.

Using this method, the Smoothwall stores a session cookie in the user’s browser. The cookie removes the need for the user to re-authenticate.

To securely logout, the user must click Logout from the non-SSL Login page. For more information about the non-SSL Login page, including how to customize it to suit your organizational needs, see Using SSL Authentication.

Identify users with the Guardian authentication service. If the user has not authenticated, they are identified by their IP address as the Guardian authentication service supports only one user by client IP address. The request is assigned to the Unauthenticated IPs group. If an unauthenticated request ends up at a block page, if configured, the user can choose to be redirected to either the SSL or non-SSL login page to attempt authentication.This way, you can control which sites anonymous users can access, with authenticated users gaining a higher level of access.

Negotiate with the client device to identify whether Kerberos or NTLM authentication is required. This is particularly useful for client devices that have different levels of support for authentication methods, such as, browsers versus software applications. Guardian offers both methods to the client, and allows it to pick the most secure method supported.

The account specified on the Services > Authentication > Directories page must have permission to join the computer to the domain.

Note: Browsing devices must be joined to the same Active Directory domain for this to work seamlessly. However, devices not joined to the domain can still use this method of authentication, typically via a dialog requesting the user enter valid domain credentials.

Identify users with the Guardian authentication service. If no user is logged in, redirect Web requests to the Kerberos login page, which obtains the username logged into their Microsoft Windows workstation.

Identify the user’s device in order to redirect them to an NTLM authentication service, or an SSL login service. This redirect is based on the User-Agent data received in the browser’s HTTP header packet. This is a best-guess scenario, based on pattern-matching and compatibility.

Identify users with the Guardian authentication service. If no user is logged in, redirect Web requests to the NTLM login page, which obtains the username logged into their Microsoft Windows workstation.

The Guardian authentication service supports only one user per client IP address.

NTLM identification does not verify a user's credentials. It should only be used where all client workstations are secured and members of a Microsoft Windows domain. Unsecured clients can spoof their credentials.

Identify users with the Guardian authentication service. If no user is logged in, redirect Web requests to the NTLM login page, which obtains the username logged into their Microsoft Windows workstation and validates their credentials with the domain controller.

The Guardian authentication service supports only one user per client IP address.

4.

From the Interface drop-down list, select the interface on which to apply the authentication policy.

When Filter HTTPS traffic is enabled, you must specify how Guardian handles HTTPS requests without a Server Name Indication (SNI). SNI provides the domain name for transparent HTTPS requests. Without this, only the IP address is known, making it difficult to distinguish genuine requests.

From the Behavior drop-down, choose one of the following:

•

Block HTTPS traffic with no SNI header

•

Allow Transparent HTTPS incompatible sites — HTTPS traffic that does not contain SNI , and whose originating IP address is listed in the Transparent HTTPS incompatible sites Standard category is allowed through without further filtering. All other HTTPS traffic without SNI field is blocked.

•

Filter using name from certificate — All HTTPS traffic that does not contain SNI is filtered accordingly, based on the domain name taken from the destination server's certificate.

Note: Some certificates use wildcards in domain names, such as, *.google.com. Guardian treats these as normal characters, therefore they should be listed as such when used in categories.

•

Allow Transparent HTTPS incompatible sites and filter others using name from certificate — This is a combination of the previous two options: if the originating IP address is listed in the Transparent HTTPS incompatible sites category then HTTPS traffic is allowed through without further filtering, else the originating domain is taken from the server's certificate and traffic filtered accordingly.

However, it should be noted that some clients make HTTPS requests without SNI, such as, the Google Chrome™ updater, older versions of Google Drive™, and Dropbox™, so valid requests may be blocked.

7.

If IP address spoofing is required, select Spoofing. This ensures that traffic leaving the Smoothwall has the source IP address of the client making the web requests, and not the IP address of the Smoothwall.

For customers with multiple external connections, enabling Guardian spoofing allows you to make use of source NAT and link load balancing policies (see Using Source NAT-ing and LLB Rules) to manipulate traffic to use specific links. For example, forcing students to use to use one link and teachers another, based on their source IP address.

Note: For networks that make use of multiple Guardians, such as, in a cluster, or centrally managed configuration, you should take steps to ensure reply packets addressed to the spoofed client are routed back through to the same Smoothwall. This ensures data is returned properly to the correct client.

Tip: If the Bandwidth Management add-on module has been installed on your Smoothwall (see About Bandwidth Management Shaping) you can control the bandwidth used by Guardian traffic, for example, limiting bandwidth available to your bring your own device (BYOD) network. It should be noted that a Layer 7 license is required to take advantage of the full functionality of Bandwidth Management. For more information, refer to your Smoothwall representative.

8.

Click Next and add the location at which the policy will apply.

9.

Click Next and review the options for handling unauthenticated requests.

When requests are permitted without requiring authentication, for example, entries on the Web proxy > Authentication > Exceptions page, Guardian assigns them to the Unauthenticated IPs group. If you want to assign them to a different group, add the group to the Included groups list.

10.

Click Next.

11.

Select Enable Policy.

12.

Click Confirm. Guardian displays the policy settings.

13.

Review the settings and click Save to make the policy available for use.

14.

Click Next and add the location at which the policy applies.

15.

Click Next and review the options for handling unauthenticated requests.

When requests are permitted without requiring authentication, for example, entries on the Web proxy > Authentication > Exceptions page, Guardian assigns them to the Unauthenticated IPs group. If you want to assign them to a different group, add the group to the Included groups list.

16.

Click Next.

17.

Select Enable Policy.

18.

Click Confirm. Guardian displays the policy settings.

19.

Review the settings and click Save to make the policy available for use.