If you selected Use LDAP to retrieve user group information on the Users tab in Step 15 of Configuring Your SonicWall Security Appliance for SonicWall SSO Agent, you must configure your LDAP settings.
|
1
|
On the Users tab in the SSO Configure window, click the Configure button next to the Use LDAP to retrieve user group information option. The Settings tab displays.
|
|
2
|
In the Name or IP address field, enter the name or IP address of your LDAP server.
|
|
3
|
In the Port Number field, enter the port number of your LDAP server. The default LDAP ports are:
|
|
•
|
|
4
|
In the Server timeout (seconds) field, enter a number of seconds the SonicWall security appliance will wait for a response from the LDAP server before the attempt times out. Allowable values are 1 to 99999. The default is 10 seconds.
|
|
5
|
In the Overall operation timeout (minutes) field, enter a number of minutes the SonicWall security appliance will spend on any automatic operation before timing out. Allowable values are 1 to 99999. The default is 5 minutes.
|
|
•
|
Anonymous login – to log in anonymously. Some LDAP servers allow for the tree to be accessed anonymously. If your server supports this (MS AD generally does not), you may select this option.
|
|
•
|
Give login name / location in tree – to access the tree with the login name.
|
|
•
|
Give bind distinguished name – to access the tree with the distinguished name.
|
|
7
|
To log in with a user’s name and password, enter the user’s name in the Login user name field and the password in the Login password field. The login name will automatically be presented to the LDAP server in full ‘dn’ notation.
|
|
NOTE: Use the user’s name in the Login user name field, not a username or login ID. For example, John Doe would log in as John Doe, not jdoe.
|
|
8
|
Select the LDAP version from the Protocol version drop-down menu, either LDAP version 2 or LDAP version 3. Most implementations of LDAP, including AD, employ LDAP version 3.
|
|
9
|
Select the Use TLS (SSL) check box to use Transport Layer Security (SSL) to log in to the LDAP server. It is strongly recommended to use TLS to protect the username and password information that will be sent across the network. Most implementations of LDAP server, including AD, support TLS.
|
|
10
|
Select the Send LDAP ‘Start TLS’ request check box to allow the LDAP server to operate in TLS and non-TLS mode on the same TCP port. 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. AD does not use this option, and it should only be selected if required by your LDAP server.
|
|
NOTE: Only check the Send LDAP ‘Start TLS’ request box if your LDAP server uses the same port number for TLS and non-TLS.
|
|
11
|
Select the Require valid certificate from server check box to require a valid certificate from the 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 security appliance and the LDAP server will still use TLS – only without issuance validation.
|
|
12
|
Select a local certificate from the Local certificate for TLS drop-down menu. This is optional, to be used only if the LDAP server requires a client certificate for connections. This feature is useful for LDAP server implementations that return passwords to ensure the identity of the LDAP client (AD does not return passwords). This setting is not required for AD.
|
|
13
|
Click Apply.
|
|
14
|
Click the Schema tab.
|
|
15
|
From the LDAP Schema drop-down menu, select one of the following LDAP schemas. 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.
|
|
16
|
The Object class field defines which attribute represents the individual user account to which the next two fields apply. This will not be modifiable unless you select User defined.
|
|
17
|
The Login name attribute field defines which attribute is used for login authentication. This will not be modifiable unless you select User defined.
|
|
18
|
If the Qualified login name attribute field is not empty, it specifies 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. For Microsoft Active Directory, this is typically set to userPrincipalName for login using name@domain. This can also be set to mail for Active Directory and RFC2798 inetOrgPerson.
|
|
19
|
The User group membership attribute field contains the information in the user object of which groups it belongs to. 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.
|
|
20
|
In the Additional user group ID attribute field, enter the attribute that contains the user’s primary group ID. This field is used to get primary user group information for user accounts, and works together with the Additional user group match attribute option. To enable database searches for the user group information, select the Use check box.
|
Windows has the concept of each user having a primary user group, which is normally Domain Users for domain users and Admin Users for administrators. However, an LDAP search for a user’s group memberships does not include that primary group in the list returned from Active Directory. Therefore, to allow setting rules and policies for the Domain Users or Admin Users groups, the appliance also needs to retrieve a user’s primary user group with a separate LDAP search.
An attribute must be used for the search, because in Active Directory the user’s primary group is not set by name as other user group memberships are. Instead, it is set in the user object by a primaryGroupID attribute that gives an ID number, that ID number being given in the user group object by a primaryGroupToken attribute.
To allow these user groups to be used on the appliance for applying group policies, after reading the user object with its user group memberships from LDAP, the appliance needs to perform an additional search for a user group with a primaryGroupToken attribute matching the user’s primaryGroupID attribute.
Use of these attributes is off by default, as there is additional time overhead in user group searches. The Use check box must be enabled to search for a user’s primary user group.
Although this is primarily for attributes of Active Directory, it can operate with any schema to allow a search for one additional user group by setting appropriate attribute values in the Additional user group ID attribute and Additional user group match attribute fields. These fields default to primaryGroupID and primaryGroupToken when Active Directory is selected.
|
21
|
The Framed IP address attribute field 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 using L2TP with the SonicWall security appliance L2TP server. In future releases, this may also be supported for the SonicWall Global VPN Client (GVC). In Active Director, the static IP address is configured on the Dial-in tab of a user’s properties.
|
|
22
|
The Object class field defines the type of entries that an LDAP directory may contain. A sample object class, as used by AD, would be ‘user’ or ‘group’.
|
|
23
|
The Member attribute field defines which attribute is used for login authentication.
|
|
24
|
The Additional user group match attribute field defines the attribute that contains the user group ID for the user. The Additional user group match attribute field works together with the Additional user group ID attribute field.
|
|
25
|
Select the Directory tab.
|
|
26
|
In the Primary Domain field, specify the user domain used by your LDAP implementation. For AD, this will be the Active Directory domain name, such as 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.
|
|
27
|
In the User tree for login to server field, specify the tree in which the user specified in the ‘Settings’ tab resides. For example, in AD the ‘administrator’ account’s default tree is the same as the user tree.
|
|
28
|
In the Trees containing users field, specify the trees where users commonly reside in the LDAP directory. One default value is provided that can be edited, a maximum of 64 DN values may be provided, and the SonicWall security appliance searches the directory 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.
|
|
29
|
In the Trees containing user groups specify the trees where user groups commonly reside in the LDAP directory. 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.
|
The above-mentioned trees are normally given in URL format but can alternatively be specified as distinguished names (for example, 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 (for example, 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.
|
|
NOTE: When working with AD, to locate 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.
|
|
30
|
The Auto-configure button causes the SonicWall security appliance 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. The User tree for login to server field must be set first.
|
If using multiple LDAP/AD servers with referrals, this process can be repeated for each, replacing the Domain to search accordingly and selecting Append to existing trees on each subsequent run.
|
31
|
Select the Referrals tab.
|
|
•
|
Allow referrals – Select when user information is located on an LDAP server other than the primary one.
|
|
•
|
Allow continuation references during user authentication – Select when individual directory trees span multiple LDAP servers.
|
|
•
|
Allow continuation references during directory auto-configuration – Select to read directory trees from multiple LDAP servers in the same operation.
|
|
•
|
Allow continuation references in domain searches – Select to search for sub-domains in multiple LDAP servers.
|
|
33
|
Select the LDAP Users tab.
|
|
34
|
Check the Allow only users listed locally box to require that LDAP users also be present in the SonicWall security appliance local user database for logins to be allowed.
|
|
35
|
Check the User group membership can be set locally by duplicating LDAP user names box to allow for group membership (and privileges) to be determined by the intersection of local user and LDAP user configurations.
|
|
36
|
From the Default LDAP User Group drop-down menu, select a default group on the SonicWall security appliance to which LDAP users will belong in addition to group memberships configured on the LDAP server.
|
|
TIP: Group memberships (and privileges) can also be assigned simply with LDAP. By creating user groups on the LDAP/AD server with the same name as SonicWall security appliance built-in groups (such as Guest Services, Content Filtering Bypass, Limited Administrators) and assigning users to these groups in the directory, or creating user groups on the SonicWall security appliance with the same name as existing LDAP/AD user groups, SonicWall group memberships will be granted upon successful LDAP authentication.
|
|
37
|
Click the Import user groups button to import user groups from the LDAP server. The names of user groups on the LDAP server need to be duplicated on the SonicWall if they are to be used in policy rules, CFS policies, etc.
|
|
38
|
Select the LDAP Relay tab.
|
|
39
|
Select the Enable RADIUS to LDAP Relay check box to enable RADIUS to LDAP relay. 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 security appliance with remote satellite sites connected into it using SonicWall security appliances that may not support LDAP. In that case the central SonicWall security appliance can operate as a RADIUS server for the remote SonicWall security appliances, acting as a gateway between RADIUS and LDAP, and relaying authentication requests from them to the LDAP server.
|
|
40
|
Under Allow RADIUS clients to connect via, select the relevant checkboxes and policy rules will be added to allow incoming RADIUS requests accordingly. The options are:
|
|
•
|
|
•
|
|
41
|
In the RADIUS shared secret field, enter a shared secret common to all remote SonicWall security appliances.
|
|
42
|
In the User groups for legacy users fields, define the user groups that correspond to the legacy ‘VPN users,’ ‘VPN client users,’ ‘L2TP users’ and ‘users with Internet access’ privileges. When a user in one of the given user groups is authenticated, the remote SonicWall security appliances will be informed that the user is to be given the relevant privilege.
|
|
NOTE: The Bypass filters and Limited management capabilities privileges are returned based on membership to user groups named Content Filtering Bypass and Limited Administrators, which are not configurable.
|
|
43
|
Select the Test tab.
|
|
44
|
In the Username and Password fields, enter a valid LDAP login name for the LDAP server you configured.
|
|
45
|
|
46
|
Click Test. Status and information returned from the LDAP server are displayed in the Test Status, Message from LDAP, and Returned User Attributes fields.
|
