SonicWALL UTM Appliance User Manual

LDAP

Leveraging LDAP Groups/ Users with SonicWALL UTM Appliance

Contents

Contents..............................................................................................................................................................1

Integrating LDAP/Active Directory with Sonicwall UTM......................................................................................3

LDAP over SSL ............................................................................................................................................... 3

Configuring the CA on the Active Directory Server.....................................................................................3

Exporting the CA Certificate from the Active Directory Server............................................................................ 4

Importing the CA Certificate onto the SonicWALL..............................................................................................4

Configuring the SonicWALL Appliance for LDAP........................................................................................4

Authentication.................................................................................................................................................... 13

Single Sign-On Agent (SSO).........................................................................................................................13

Logon to Appliance – Configuring User Level Authentication Settings......................................................... 14

SonicOS Options That Leverage Groups/Users...............................................................................................17

Creating Firewall Rules with LDAP Groups/Users........................................................................................ 17

Firewall Rules with Bandwidth Management & Logging...............................................................................20

Blocking Websites (Domain Names) for Groups/Users....................................................................................22

Blocking Domains with Firewall Rules.......................................................................................................22

Allowing Specific Domains and Blocking All Others with Firewall Rules...................................................... 24

Blocking HTTPS (SSL) Domains with SSL Control.......................................................................................30

Configuring a SSL Blacklist and Whitelist.................................................................................................31

Applying Different CFS Policies to Groups .......................................................................................................33

Creating Custom CFS Policies..................................................................................................................35

Enforcing CFS Policies without Requiring All Users to Authenticate............................................................ 39

Variables for Custom Block Page in SonicOS 5.2 ....................................................................................40

Basic Sample Code for SonicOS 5.2........................................................................................................41

Advanced Sample Code for SonicOS 5.2.................................................................................................41

Sample JavaScript Code for SonicOS 5.2................................................................................................44

Sample Code for SonicOS 5.1 or Earlier ..................................................................................................44

Applying Application Firewall Polices to Groups/Users.................................................................................45

Blocking All Websites except a Select Few with Application Firewall.......................................................49

Tightening Control over the Browsing Behavior of Users .................................................................................50

Applying Intrusion Prevention Service Signatures to Groups/Users................................................................. 51

Blocking IM Traffic Categorically...............................................................................................................51

Applying Granular IM Policies...................................................................................................................52

Applying VPN Access Policies to Groups/Users...............................................................................................53

Global VPN Client (GVC)..........................................................................................................................53

SSL-VPN (NetExtender)............................................................................................................................ 55

Guest Services (Wireless Guest Services) ....................................................................................................... 56

LHM – Lightweight Hotspot Messaging – External Authentication for Wireless Users.............................57



Integrating LDAP/Active Directory with Sonicwall UTM

SonicOS supports a range of different LDAP servers, the most popular being Active Directory (AD). AD is also an LDAP implementation. Please refer to the following paper as a supplement on how to configure LDAP settings.

http://www.sonicwall.com/downloads/LDAP_Integration_Feature_Module.pdf

LDAP over SSL

Integrating your SonicWALL appliance with an LDAP directory service using SSL requires configuring your LDAP server for certificate management, installing the correct certificate on your SonicWALL appliance, and configuring the SonicWALL appliance to use the information from the LDAP Server.

NOTE

: SSL is not required for LDAP integration. The downside is that user credentials are sent across the

network unencrypted. This is considered highly insecure.

Before beginning your LDAP configuration, you should prepare your LDAP server and your SonicWALL for LDAP over TLS support. This requires:

• Installing a server certificate on your LDAP server.

• Installing a Certificate Authority (CA) certificate for the issuing CA on your SonicWALL appliance.

The following procedures describe how to perform these tasks in an Active Directory environment.

Configuring the CA on the Active Directory Server

To configure the CA on the Active Directory server (skip the first five steps if Certificate Services are already installed):

Step 1: Navigate to Start > Settings > Control Panel > Add/Remove Programs. Step 2: Select Add/Remove Windows Components. Step 3: Select Certificate Services. Step 4: Select Enterprise Root CA when prompted. Step 5: Enter the requested information. For information about certificates on Windows systems, se e

http://support.microsoft.com/kb/931125

Step 6: Launch the Domain Security Policy application: Navigate to Start > Run and run the command: dompol.msc.

Step 7: Open Security Settings > Public Key Policies. Step 8: Right click Automatic Certificate Request Settings. Step 9: Select New > Automatic Certificate Request. Step 10: Follow through the wizard, and select Domain Controller from the list.

Exporting the CA Certificate from the Active Directory Server

To export the CA certificate from the AD server:

Step 1: Launch the Certification Authority application: Start > Run > certsrv.msc. Step 2: Right click on the CA you created and select Properties. Step 3: On the General tab, click the View Certificate button. Step 4: On the Details tab, select Copy to File. Step 5: Follow through the wizard, and select the Base-64 Encoded X.509 (.cer) format. Step 6: Specify a path and filename to which to save the certificate.

Importing the CA Certificate onto the SonicWALL

To import the CA certificate onto the SonicWALL:

Step 1: Browse to System > CA Certificates. Step 2: Select Add new CA certificate. Select the certificate file you just exported. Step 3: Click the Import certificate button.

Configuring the SonicWALL Appliance for LDAP

The Users > Settings page in the administrative interface provides the settings for managing your LDAP integration:

Step 1: In the SonicOS administrative interface, open the Users > Settings page. Step 2: In the Authentication method for login drop-down list, select either LDAP or LDAP + Local

Users.

Step 3: Click Configure. Step 4: If you are connected to your SonicWALL appliance via HTTP rather than HTTPS, you will see

a dialog box warning you of the sensitive nature of the information stored in directory services and offering to change your connection to HTTPS. If you have HTTPS management enabled for the interface to which you are connected (recommended), check the “Do not show this message again” box and click Yes.

Step 5: On the Settings tab of the LDAP Configuration window, configure the following fields:

• Name or IP Address – The FQDN or the IP address of the LDAP server against which you wish to authenticate. If using a name, be certain that it can be resolved by your DNS server. Also, if using TLS with the ‘Require valid certificate from server’ option, the name provided here must match the name to which the server certificate was issued (i.e. the CN) or the TLS exchange will fail.

• Port Number – The default LDAP over TLS port number is TCP 636. The default LDAP (unencrypted) port number is TCP 389. If you are using a custom listening port on your LDAP server, specify it here.

• Server Timeout – The amount of time, in seconds, that the SonicWALL will wait for a response from the LDAP server before timing out. Allowable ranges are 1 to 99999, with a default of 10 seconds.

• Anonymous Login – Some LDAP servers allow for the tree to be accessed anonymously. If your server supports this (Active Directory generally does not), then you may select this option.

• Login User Name – Specify a user name that has rights to log in to the LDAP directory. The login name will automatically be presented to the LDAP server in full ‘dn’ notation. This can be any account with LDAP read privileges (essentially any user account) – Administrative privileges are not required. Note that this is the user’s name, not their login ID (e.g. John Smith rather than jsmith).

• Login Password – The password for the user account specified above.

• Protocol Version – Select either LDAPv3 or LDAPv2. Most modern implementations of LDAP,

including Active Directory, employ LDAPv3.

• Use TLS – Use Transport Layer Security (SSL) to log in to the LDAP server. It is strongly recommended that TLS be used to protect the username and password information that will be sent across the network. Most modern implementations of LDAP server, including Active Directory, support TLS. Deselecting this default setting will display an alert that you must accept to proceed.

• Send LDAP ‘Start TLS’ Request – Some LDAP server implementations support the Start TLS directive rather than using native LDAP over TLS. This allows the LDAP server to listen on one port (normally 389) for LDAP connections, and to switch to TLS as directed by the client. Active Directory does not use this option, and it should only be selected if required by your LDAP server.

• Require valid certificate from server – Validates the certificate presented by the server during the TLS exchange, matching the name specified above to the name on the certificate. Deselecting this default option will present an alert, but exchanges between the SonicWALL and the LDAP server will still use TLS – only without issuance validation.

• Local certificate for TLS – Optional, to be used only if the LDAP server requires a client certif icate for connections. Useful for LDAP server implementations that return passwords to ensure the identity of the LDAP client (Active Directory does not return passwords). This setting is not required for Active Directory.

If your network uses multiple LDAP/AD servers with referrals, then select one as the primary server (probably the one that holds the bulk of the users), and use the above settings for that server. It will then refer the SonicWALL on to the other servers for users in domains ot her than its own. For the SonicWALL to be able to log in to those other servers, each server must have a user configured with the same credentials (user name, password and location in the directory) as the login to the primary server. This may entail creating a special user in the directory for the SonicWALL login. Note that only read access to the directory is required.

Step 6 On the Schema tab, configure the following fields:

• LDAP Schema – Select one of the following: – Microsoft Active Directory

– RFC2798 inetOrgPerson – RFC2307 Network Information Service – Samba SMB – Novell eDirectory – User defined

Selecting any of the predefined schemas will automatically populate the fields used by that schema with their correct values. Selecting ‘User Defined’ will allow you to specify your own values – use this only if you have a specific or proprietary LDAP schema configuration.

• Object class – Select the attribute that represents the individual user account to which the next two fields apply.

• Login name attribute – Select one of the following to define the attribute that is used for login authentication:

– sAMAccountName for Microsoft Active Directory – cn for Novell eDirectory – uid for others

• Qualified login name attribute – Optionally select an attribute of a user object that sets an alternative login name for the user in name@domain domains in particular, where the simple login name may not be unique across domains. By default, this is set to userPrincipalName for Microsoft Active Directory and mail RFC2798 inetOrgPerson. Note that userPrincipalName would allow login as, for example, “john.ourdomain.com” where mail would login as “john@ourdomain.com”.

• User group membership attribute – Select the attribute that contains information about the groups to which the user object belongs. This is memberOf in Microsoft Active Directory. The other predefined schemas store group membership information in the group object rather than the user object, and therefore do not use this field.

• Framed IP address attribute – Select the attribute that can be used to retrieve a static IP address that is assigned to a user in the directory. Currently it is only used for a user connecting via L2TP with the SonicWALL’s L2TP server to retrieve the IP address to assign to them from the directory. In the future this may also be supported for Global VPN Client. In Active Directory the static IP address is configured on the Dial-in tab of a user’s properties.

format. This may be needed with multiple

Step 7: On the Directory tab, configure the following fields:

• Primary Domain – The user domain used by your LDAP implementation. For AD, this will be the Active Directory domain name, e.g. yourADdomain.com. Changes to this field will, optionally, automatically update the tree information in the rest of the page. This is set to mydomain.com by default for all schemas except Novell eDirectory, for which it is set to o=mydomain.

• User tree for login to server – The location of where the tree is that the user specified in the settings tab. For example, in Active Directory the ‘administrator’ account’s default tree is the same as the user tree.

• Trees containing users – The trees where users commonly reside in the LDAP directory. One default value is provided which can be edited, and up to a total of 64 DN values may be provided. The SonicWALL will search the directory using them all until a match is found, or the list is exhausted. If you have created other user containers within your LDAP or AD directory, you should specify them here.

• Trees containing user groups – Same as above, only with regard to user group containers, and a maximum of 32 DN values may be provided. These are only applicable when there is no user group membership attribute in the schema's user object, and are not used with AD.

All the above trees are normally given in URL format but can alternatively be specified as distinguished names (e.g. “myDom.com/Sales/Users” could alternatively be given as the DN "ou=Users,ou=Sales,dc=myDom,dc=com"). The latter form will be necessary if the DN does not conform to the normal formatting rules as per that example. In Active Directory, the URL corresponding to the distinguished name for a tree is displayed on the Object tab in the properties of the container at the top of the tree.

NOTE: AD has some built-in containers that do not conform (e.g. the DN for the top level Users container

is formatted as “cn=Users,dc=…”, using ‘cn’ rather than ‘ou’), but the SonicWALL knows about and deals with these, so they can be entered in the simpler URL format.

Ordering is not critical, but since they are searched in the given order, it is most efficient to place the most commonly used trees first in each list. If referrals between multiple LDAP servers are to be used, then the

trees are best ordered with those on the primary server first, and the rest in the same order that they will be referred.

NOTE: When working with AD, to determine the location of a user in the directory for the ‘User tree for

login to server’ field, the directory can be searched manually from the Active Directory Users and Settings control panel applet on the server, or a directory search utility such as queryad.vbs in the Windows NT/2000/XP Resource Kit can be run from any PC in the domain.

• Auto-configure – This causes the SonicWALL to auto-configure the Trees containing users and Trees containing user groups fields by scanning through the directories in search of all tre es that

contain user objects. To use auto-configure, first enter a value in the User tree for login to server field (unless anonymous login is set), and then click the Auto-configure button to bring up the following dialog:

Step 8: In the Auto Configure dialog box, enter the desired domain in the Domain to search field. Select one of the following:

o Append to existing trees – This selection will append newly located trees to the current

configuration.

o Replace existing trees – This selection will start from scratch and remove all currently

configured trees first.

Step 9: Click OK. The auto-configuration process may also locate trees that are not needed for user login. You can manually remove these entries.

If using multiple LDAP/AD servers with referrals, this process can be repeated for each, replacing the Domain to search value accordingly and selecting Append to existing trees on each subsequent run.

Step 10: On the LDAP Users tab, configure the following fields:

• Allow only users listed locally – Requires that LDAP users also be present in the SonicWALL local user database for logins to be allowed.

• User group membership can be set locally by duplicating LDAP user names – Allows for group membership (and privileges) to be determined by the intersection of local user and LDAP user configurations.

• Default LDAP User Group – A default group on the SonicWALL to which LDAP users will belong in addition to group memberships configured on the LDAP server.

• Import user groups – You can click this button to configure user groups on the SonicWALL by retrieving the user group names from your LDAP server. The Import user groups button launches a dialog box containing the list of user group names available for import to the SonicWALL.

In the LDAP Import User Groups dialog box, select the checkbox for each group that you want to import into the SonicWALL, and then click Save.

Having user groups on the SonicWALL with the same name as existing LDAP/AD user groups allows SonicWALL group memberships and privileges to be granted upon successful L DAP authentication.

Alternatively, you can manually create user groups on the LDAP/AD server with the same names as SonicWALL built-in groups (such as ‘Guest Services’, ‘Content Filtering Bypass’, and ‘Limited Administrators’) and assign users to these groups in the directory. This also allows SonicWALL group memberships to be granted upon successful LDAP authentication.

The SonicWALL appliance can retrieve group memberships efficiently in the case of Active Dire ctory by taking advantage of its unique trait of returning a ‘memberOf’ attribute for a user.

Step 11: On the LDAP Relay tab, configure the following fields:

The RADIUS to LDAP Relay feature is designed for use in a topology where there is a central site with an LDAP/AD server and a central SonicWALL with remote satellite sites connected into it via older low-end SonicWALL security appliances that may not support LDAP. In that case the central SonicWALL can operate as a RADIUS server for the remote SonicWALLs, acting as a gateway between RADIUS and LDAP, and relaying authentication requests from them to the LDAP server.

Additionally, for remote SonicWALLs running non-enhanced firmware, with this feature the central SonicWALL can return legacy user privilege information to them based on user group memberships learned via LDAP. This avoids what can be a very complex configuration of an external RADIUS server such as IAS, for those SonicWALLs.

• Enable RADIUS to LDAP Relay – Enables this feature.

• Allow RADIUS clients to connect via – Check the relevant checkboxes and policy rules will be

added to allow incoming RADIUS requests accordingly.

• RADIUS shared secret – This is a shared secret common to all remote SonicWALLs.

• User groups for legacy VPN users – Defines the user group that corresponds to the legacy ‘Access

to VPNs’ privileges. When a user in this user group is authenticated, the remote SonicWALL is notified to give the user the relevant privileges.

• User groups for legacy VPN client users – Defines the user group that corresponds to the legacy ‘Access from VPN client with XAUTH’ privileges. When a user in this user group is authenticated, the remote SonicWALL is notified to give the user the relevant privileges.

• User groups for legacy L2TP users – Defines the user group that corresponds to the legacy ‘Access from L2TP VPN client’ privileges. When a user in this user group is authenticated, the remote SonicWALL is notified to give the user the relevant privileges.

• User groups for legacy users with Internet access – Defines the user group that corresponds to the legacy ‘Allow Internet access (when access is restricted)’ privileges. When a user in this u ser group is authenticated, the remote SonicWALL is notified to give the user the relevant privileges.

NOTE: The ‘Bypass filters’ and ‘Limited management capabilities’ privileges are returned based on

membership to user groups named ‘Content Filtering Bypass’ and ‘Limited Administrators’ – these are not

configurable.

Step 12: Select the Test tab to test the configured LDAP settings:

The Test LDAP Settings page allows for the configured LDAP settings to be tested by attempting authentication with specified user and password credentials. Any user group memberships and/or framed IP address configured on the LDAP/AD server for the user will be displayed.

Authentication

There are two mechanisms available for having a user authenticate to the SonicWALL firewall . The first mechanism is the Single Sign-On agent (SSO). With SSO, the authentication process is transparent and seamless to the end user. All the user needs to do is login to the domain, and the SSO takes care of the rest.

The next mechanism is the Local Non-transparent Authentication. The first time the user attempts to pass HTTP traffic through the appliance, he or she will be redirected to login in to the appliance. The user’s logi n credentials will be tied to whichever back end mechanism was established, i.e. LDAP, AD, the local user database, etc.

Single Sign-On Agent (SSO)

For more details on how to implement and install the SSO, please refer to following white papers. Please be sure to search the Knowledge Base at Mysonicwall.com for the most up to date content.

• HTTP://www.sonicwall.com/downloads/AD_auth_with_30e_and_sc10.pdf

• HTTP://www.sonicwall.com/downloads/SonicOS_4.0_Single_Sign_On.pdf

• HTTP://www.sonicwall.com/downloads/SonicOS_5.0_Single_Sign_On.pdf

Logon to Appliance – Configuring User Level Authentication Settings

This is the other method of authenticating users, and requires the user to login to the appliance. Please refer to the following paper for more details on ULA:

http://www.sonicwall.com/downloads/SonicOS_Standard_2.1_User-Level_Authentication.pdf

In this example, the LAN zone will be configured for ULA:

Step 1: Go to Network>Interfaces>X0 (or appropriate interface). Step 2: Under General enable HTTPS User Login. Also enable Add rule to enable redirect from HTTP to HTTPS if neither HTTP Management nor HTTP Login are enabled (it is not needed if either

of them are). Step 3: Go to Firewall>Access Rules>LAN>WAN. The default is set to: ‘Any, Any, Any, Allow’ rule, shown below.

Step 5: Click Add, then create the following two rules as depicted below. The order is important. The new first rule allows any DNS queries out. The new second rule forces all users (Everyone) to be challenged before accessing the Internet for HTTP only.

NOTE: This configuration will allow any traffic out other than HTTP, even without first authenticating. If you

want to block ALL traffic before authenticating for HTTP, then disable the default ‘Any, Any, Any, Allow’ rule as depicted in rule 3 below. The downside to this is that users need to know that they have to authenticate via HTTP before ANY Internet traffic will pass.

NOTE: It is also important to not test these rules when logged in as administrator to the SonicWALL.

NOTE: The difference between “All” and “Everyone” in a policy rule. Selecting “All” will allow all matching

traffic, regardless from an authenticated user or not. Selecting the “Everyone” user group will allow traffic from any logged in user, but not from a user who has not logged in.

If everything is working correctly, you should then see users authenticated on the Log>View page.

SonicOS Options That Leverage Groups/Users

Now that we have a means of authenticating users to the SonicWALL firewall, we can leverage the groups/users that are in LDAP/Active Directory for a myriad of options:

• Create firewall rules for specific groups/users

• Create different content filtering policies for different groups

• Create Application Firewall policies for specific groups/users

• Leverage IPS signatures for specific groups/users

• Allow/deny VPN access for specific groups/users

• Allow/deny VPN access to specific internal networks via VPN for specific groups/users

• Allow/deny access to WLAN resources for specific groups/users

• Bandwidth Limit different groups/users with Application Firewall

Creating Firewall Rules with LDAP Groups/Users

Firewall rules get processed from top down. As soon as a rule has a match, further rule processing stops, meaning you want the more specific rule at the top of the list and the more general rule below it. The default rule in SonicOS for LAN > WAN is to allow ANY user, ANY service, from ANY source. This is a very unrestrictive rule but allows for an easy implementation. The recommendation is to change the default rule from ANY, ANY, ANY to deny. This does create more work for the network admin as it now will be necessary to create rules to allow traffic to leave the internal network. The flipside to this additional work is a more secure network. Depending on your default rule, it will change the way you create FW rules.

So, can you create FW rules that leverage specific groups/users with desirable results? Possibly. The way FW rule processing works is as follows (as of SonicOS 5.2):

• Rules are processed from top down

• Rule processing stops as soon as there is a match (with some caveats – see below)

• Rule logic first looks at Source, then Destination, Service, and Action. If there is a match there, rule

processing stops and then further subset rule processing can happen (rules set for schedules, users/groups, or BWM) for that specific rule.

o What cannot occur is two overlapping rules for the same service for different groups. For

example, if you had a FW rule that allowed FTP for Group 1, and below it a FW rule to allow FTP for Group 2, Group 2 would never be allowed to use FTP. The first rule that gets a match is the allow rule for FTP – and it only applies for Group 1. Recall that rule processing first looks at Source, Destination and Service. As soon as there is a match, rule processing

stops. Because of that, the 2

FTP rule would never be reached.

In the following example, we’ll demonstrate how you can leverage firewall rules to allow a certain group of users to download POP email, while the rest of the organization is denied.

First, create a rule a rule from LAN > WAN (note this could be from any zone you want to enforce this policy on, not just the LAN) that allows POP traffic for your LDAP group.

NOTE: The user or group is not used in selecting which rule to apply. You should always set a rule for the service, source, and destination. In that rule, select the user or group to be

+ 39 hidden pages