User Management : User Management
Configuring LDAP Integration in SonicOS
Integrating your firewall with an LDAP directory service requires configuring your LDAP server for certificate management, installing the correct certificate on your firewall, and configuring the firewall to use the information from the LDAP Server. For an introduction to LDAP, see Using LDAP/Active Directory/eDirectory Authentication .
See the following sections:
•
Preparing Your LDAP Server for Integration
•
Configuring the Dell SonicWALL Network Security Appliance for LDAP
Preparing Your LDAP Server for Integration
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 CA (Certificate Authority) certificate for the issuing CA on your firewall.
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):
1
Navigate to Start > Settings > Control Panel > Add/Remove Programs
2
Select Add/Remove Windows Components
3
Select Certificate Services
4
Select Enterprise Root CA when prompted.
5
Enter the requested information. For information about certificates on Windows systems,
see http://support.microsoft.com/kb/931125.
6
Launch the Domain Security Policy application: Navigate to Start > Run and run the command: dompol.msc.
7
Open Security Settings > Public Key Policies.
8
Right click Automatic Certificate Request Settings.
9
Select New > Automatic Certificate Request.
10
Step 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:
1
Launch the Certification Authority application: Start > Run > certsrv.msc.
2
Right click on the CA you created, and select properties.
3
On the General tab, click the View Certificate button.
4
On the Details tab, select Copy to File.
5
Step through the wizard, and select the Base-64 Encoded X.509 (.cer) format.
6
Specify a path and filename to which to save the certificate.
Importing the CA Certificate in to SonicOS
To import the CA certificate in to SonicOS:
1
Browse to System > CA Certificates.
2
Select Add new CA certificate. Browse to and select the certificate file you just exported.
3
Click the Import certificate button.
Configuring the Dell SonicWALL Network Security Appliance for LDAP
The Users > Settings page in the administrative interface provides the settings for managing your LDAP integration:
1
In the SonicOS administrative interface, open the Users > Settings page.
2
In the Authentication method for login drop-down list, select either LDAP or LDAP + Local Users.
3
Click Configure.
4
If you are connected to your firewall 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), click Yes.
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 SonicOS will wait for a response from the LDAP server before timing out. The range is 1 to 99999, with a default of 10 seconds.
•
Overall operation timeout – The amount of time, in minutes, to spend on any automatic operation. Some operations, such as directory configuration or importing user groups, can take several minutes, especially when multiple LDAP servers are in use.
Select one of the following radio buttons:
•
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.
•
Give login name/location in tree – Select this option to build the distinguished name (dn) that is used to bind to the LDAP server from the “Login user name” and “User tree for login to server” fields according to the following rules:
•
The first name component begins “cn=”
•
The ‘location in tree’ components all use “ou=” (apart from certain Active Directory built-ins that begin with “cn=”)
•
The domain components all use “dc=”
If the “User tree for login to server” field is given as a dn, you can also select this option if the bind dn conforms to the first bullet above, but not to the second and/or the third bullet.
•
Give bind distinguished name – Select this option if the bind dn does not conform to the first bullet above (if the first name component does not begin with “cn=”). This option can always be selected if the dn is known. You must provide the bind dn explicitly if the bind dn does not conform to the first bullet above.
•
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 protected 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 SonicOS 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 certificate 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 SonicOS to the other servers for users in domains other than its own. For SonicOS 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 SonicOS login. Note that only read access to the directory is required.
6
On the Schema tab, configure the following fields:
7
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.
8
Object class – Select the attribute that represents the individual user account to which the next two fields apply.
9
Login name attribute – Select one of the following to define the attribute that is used for login authentication:
•
sAMAccountName for Microsoft Active Directory
•
inetOrgPerson for RFC2798 inetOrgPerson
•
posixAccount for RFC2307 Network Information Service
•
sambaSAMAccount for Samba SMB
•
inetOrgPerson for Novell eDirectory
10
Qualified login name attribute – Optionally select an attribute of a user object that sets an alternative login name for the user in name@domain format. This may be needed with multiple domains in particular, where the simple login name may not be unique across domains. This is set to mail for Microsoft Active Directory and RFC2798 inetOrgPerson.
11
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.
12
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 SonicOS L2TP server. 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.
13
User Group Objects – This section is auto-configured unless you select User Defined for the LDAP Schema.
•
Object class – Specify the name associated with the group of attributes.
•
Member attribute – Specify the attribute associated with a member.
•
Select whether this attribute is a Distinguished name or User ID.
•
Read from server – Click to read the user group object information from the LDAP server.
•
Select whether you want to Automatically update the schema configuration or Export details of the schema.
14
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 tree in which the user specified in the Settings tab resides. 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. SonicOS 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 SonicOS 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 SonicOS to auto-configure the Trees containing users and Trees containing user groups fields by scanning through the directory/directories looking for all trees 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 window:
a
In the Auto Configure window, enter the desired domain in the Domain to search field.
b
Select one of the following:
•
Append to existing trees – This selection will append newly located trees to the current configuration.
•
Replace existing trees – This selection will start from scratch removing all currently configured trees first.
15
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.
16
On the Referrals tab, configure the following fields:
•
Allow referrals – Select this option any time that user information is located on an LDAP server other than the configured primary one.
•
Allow continuation references during user authentication – Select this option any time that individual directory trees have been manually configured to span multiple LDAP servers.
•
Allow continuation references during directory auto-configuration – Select this option to allow the trees to be read from multiple LDAP servers in a single operation.
•
Allow continuation references in domain searches – Select this option when using single-sign-on with users in multiple sub-domains having separate LDAP servers.
17
On the LDAP Users tab, configure the following fields:
•
Allow only users listed locally – Requires that LDAP users also be present in the SonicOS 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 in SonicOS to which LDAP users will belong in addition to group memberships configured on the LDAP server.
•
Import user – You can click this button to configure local users in SonicOS by retrieving the user names from your LDAP server. The Import users button launches a dialog box containing the list of user names available for import.
In the LDAP Import Users dialog box, select the checkbox for each user that you want to import into SonicOS, and then click Save selected.
The list of users read from the LDAP server can be quite long, and you might not want to import all of them. A Remove from list button is provided, along with several methods of selecting unwanted users.You can use these options to reduce the list to a manageable size and then select the users to import.
Having users in SonicOS with the same name as existing LDAP users allows SonicWALL user privileges to be granted upon successful LDAP authentication.
•
Import user groups – You can click this button to configure user groups SonicOS 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 firewall.
In the LDAP Import User Groups dialog box, select the checkbox for each group that you want to import into SonicOS, and then click Save selected.
Having user groups in SonicOS with the same name as existing LDAP/AD user groups allows SonicWALL group memberships and privileges to be granted upon successful LDAP 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’, ‘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 firewall can retrieve group memberships efficiently in the case of Active Directory by taking advantage of its unique trait of returning a ‘memberOf’ attribute for a user.
18
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 low-end firewalls 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.
•
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 user 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.
19
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.
LDAP User Group Mirroring
LDAP User Group Mirroring provides automatic duplication of LDAP User Group configurations from an LDAP server to a SonicWALL Security Appliance. Administrators can manage LDAP User Groups exclusively on the LDAP server and do not need to manually duplicate configurations on the SonicWALL Security Appliance. User group configurations are periodically read from the LDAP server and copied to the SonicWALL Security Appliance.
LDAP User Group names that are copied to the Security Appliance include the domain name in the format: name@domain.com. This ensures that user group names from various domains are unique.
The following features and restrictions apply to mirrored LDAP User Groups:
•
Administrators can delete LDAP User Groups only on the LDAP server. They cannot delete the mirrored LDAP User Groups on the SonicWALL Security Appliance. When a user group is deleted on the LDAP server, its mirrored group on the SonicWALL Security Appliance is also automatically deleted.
•
Administrators can edit LDAP User Group names (and their comment boxes) only on the LDAP server. They cannot edit the mirrored LDAP User Group name or its comment box on the SonicWALL Security Appliance. The comment box displays “Mirrored from LDAP” on the SonicWALL Security Appliance.
•
Administrators can add users as members to an LDAP User Group on the SonicWALL Security Appliance.
•
Administrators cannot add groups to other groups on the SonicWALL Security Appliance. Default user groups can only be configured on the LDAP server.
•
Administrators can configure things such as VPNs, SSL VPNs, CFS policies, and ISP policies for LDAP User Groups on the SonicWALL Security Appliance, when they are configurable under configuration pages such as Firewall > Access Rules or Firewall > App Rules.
* 
NOTE: LDAP User Groups are not deleted if they are configured in any Access Rules, App Rules, or policies.
•
When you disable LDAP User Group Mirroring, the mirrored user groups on the SonicWALL Security Appliance are not deleted. They are changed so that they can be deleted manually by an administrator. Local mirrored user groups can be re-enabled if they have not been deleted manually.
•
When the system creates a mirrored group on the SonicWALL Security Appliance, and the name of the mirrored group matches the name of an already existing, user-created (non-mirrored) local group, the local group is not replaced. The local group memberships are updated to reflect the group ne stings that are configured on the LDAP server.
•
If the system finds a user group on the LDAP server with a name that is the same as one of the default user groups on the SonicWALL Security Appliance, no mirrored user group is created on the SonicWALL Security Appliance. The memberships in the default user group are updated to reflect the group nestings that are configured on the LDAP server.
•
For groups created before SonicOS 6.2, if a local user group exists on the SonicWALL Security Appliance with a simple name only (no domain) and that name matches the name of a user group on the LDAP server (which includes a domain), a new local user group is created on the SonicWALL Security Appliance and is given the same domain as the corresponding user group on the LDAP server. The original local user group is retained with no domain. Users of the original group are given memberships in the LDAP group, the new local mirrored group, and the original local group (with no domain).
LDAP Group Membership by Organizational Unit
The LDAP Group Membership by Organizational Unit feature provides the ability to set LDAP rules and policies for users located in certain Organizational Units (OUs) on the LDAP server.
To set a user membership by LDAP location:
1
On the SonicWall Security Appliance, go to Users > Local Groups.
2
Select the check box for Memberships are set by user's location in the LDAP directory.
3
Select one of the For users options:
at or under the given location
or
at the given location.
When a user logs in, if user groups are set to grant memberships by LDAP location, the user is made a member of any groups that match its LDAP location.
Administrators can set any local group, including default local groups (except for the Everyone group and the Trusted Users group) as a group with members that are set by their location in the LDAP directory tree.
When a user is a member of any local groups that are configured for LDAP location:
•
The location of those local groups in the LDAP tree is learned.
•
The location of the user’s local groups is checked against all other local groups. If any other groups have the same LDAP location as that of the user’s membership groups, the user is automatically set as a member of those groups for that login session.
When a user attempts to log in, whether with success or failure, the user’s distinguished name is logged in the event log. This helps with troubleshooting if a user fails to get memberships to the expected groups.